• 0. 论文信息
• 1. 先说结论
• 2. 它在解决什么问题？
• 3. 核心思路一句话
• 4. 方法拆解（按可复现视角写）
  • 4.1 总体结构：两级 critic
    • A) Milestone Verification Module（MVM）
    • B) Verdict Calibration Module（VCM）
  • 4.2 为什么不是单 judge？
  • 4.3 可复现的数据流（高层）
    • Step 1：准备 trajectory 表示
    • Step 2：Selector 抽关键里程碑
    • Step 3：给每个里程碑配验证目标
    • Step 4：Reviewer 审计证据链
    • Step 5：Judge 输出最终 reward
  • 4.4 OGRBench：他们顺手补了一个 benchmark
• 5. 实验（任务 / 指标 / 关键数字）
  • 5.1 OGRBench 上的 critic 表现
    • 作者声称
    • 正文可见关键数字
    • 表格可见的代表性数字
    • 我的判断
  • 5.2 AndroidWorld 在线 RL
    • 任务设定
    • Table 2 关键数字
      • Qwen3-VL-4B backbone
      • Qwen3-VL-8B backbone
    • 结论
    • 我的判断
  • 5.3 在线 RL 扩展实验
    • 关键结果
    • 我的判断
  • 5.4 自进化数据过滤 / SFT
    • 作者声称
    • 正文可见数字
    • 这意味着什么？
• 6. Ablation / 分析
  • 6.1 去掉不同角色会怎样？
    • 怎么读这张表？
  • 6.2 Assignment goal 很重要
  • 6.3 测试时投票（test-time scaling）
• 7. 局限与适用边界
  • 作者自己承认的方向
  • 我的判断
• 8. 复现清单（Checklist）
  • 8.1 数据
  • 8.2 系统模块
  • 8.3 Prompt / 规则
  • 8.4 训练 / 推理配置（正文可确认部分）
  • 8.5 评测
  • 8.6 我认为复现时最容易踩坑的点
• 9. 我的判断：值不值得深读？怎么用？
  • 值不值得深读？
  • 我最认可的点
  • 我保留的地方
  • 如果你要把它用进自己的系统
    • 方向 A：先别急着做 full RL，先做 trajectory filter
    • 方向 B：把“assignment-bound verification”学过去
• 10. 为什么今天选它，而不是其他候选？

0. 论文信息

• 标题：OS-Themis: A Scalable Critic Framework for Generalist GUI Rewards
• 中文意译：OS-Themis：面向通用 GUI 奖励的可扩展 Critic 框架
• 链接：https://arxiv.org/abs/2603.19191
• PDF：https://arxiv.org/pdf/2603.19191
• 时间：2026-03-19（v1）
• 作者机构：上海 AI Lab、USTC、CUHK MMLab、HKUST、NUS 等
• 代码：文中称代码见 OS-Copilot/OS-Themis（本文写作时未进一步核对仓库实现细节）
• 备注：本文原文可访问；下文实验数字优先来自 arXiv 正文可见内容。个别实现细节若正文未完全展开，我会明确标注“未披露/待代码确认”。

1. 先说结论

今天我选这篇。

不是因为它又做了一个“更会点屏幕的 agent”，而是因为它抓住了一个更基础的问题： 如果 GUI agent 的 reward judge 本身不可靠，后面的 RL、自训练、数据过滤都会被带偏。

我的判断：

• 作者声称：OS-Themis 通过“里程碑验证 + 证据链复核”把 GUI trajectory 的 outcome reward 做得更稳，尤其更能压制假阳性。
• 实验观察：在新提出的 OGRBench 上，作者报告 OS-Themis 相比 DigiRL 平均 accuracy +18.8%、precision +29.6%、recall +16.9%、F1 +26.2%；在 AndroidWorld 在线 RL 上，Qwen3-VL-8B 从 47.6 提到 54.7，相对 baseline +7.1；扩展训练到 1024 个任务时，Qwen3-VL-4B 达到 55.6%，较 baseline +10.3。
• 我的判断：这篇最有价值的点不是“多 agent critic”这个包装，而是它明确把 GUI 奖励建模拆成了一个可工程化的高精度判别系统。如果你真想做 browser/computer-use agent 的 RL 或自进化数据闭环，这篇比很多“再换个 backbone”式论文更值得读。

2. 它在解决什么问题？

GUI agent 的成功判定，比文本 QA 难得多。因为：

• 轨迹长，截图多，最终成败依赖少数关键步骤；
• 单看最后一帧，容易漏掉过程性失败；
• 单看全轨迹，又容易被无关上下文淹没；
• 在 RL 里，假阳性（错轨迹被判对） 比漏掉一些真阳性更伤，因为它会直接把错误行为强化进去。

作者想解决的核心痛点是：

如何为通用 GUI agent 提供既可扩展、又高精度的 outcome reward，让它能支撑在线 RL、轨迹过滤和自进化训练？

作者在文中反复强调两类失败模式：

1. contextual information loss：只看局部步骤或少量采样帧，关键信息丢了；
2. evidence dilution：把长轨迹整段喂给 judge，真正决定成败的证据被淹没，导致判定变松、假阳性上升。

3. 核心思路一句话

先让 Selector 把长 GUI 轨迹拆成“可验证里程碑”，再让 Verifier 逐个核查、Reviewer 挑错补漏、Judge 汇总裁决，从而把 reward 建立在一条被审计过的证据链上，而不是让单个 judge 直接拍脑袋。

4. 方法拆解（按可复现视角写）

4.1 总体结构：两级 critic

OS-Themis 由两个模块组成：

A) Milestone Verification Module（MVM）

目标：从长轨迹里找出关键子目标，并验证这些子目标是否真的完成。

包含两个角色：

• Selector Agent：从整段 GUI trajectory 中挑选“关键步骤 / 关键里程碑”
• Verifier Agent：逐个检查这些里程碑是否满足验证条件

B) Verdict Calibration Module（VCM）

目标：对 MVM 的输出做第二轮严格审计，降低假阳性。

包含两个角色：

• Reviewer Agent：批判性复核。检查里程碑集合是否完整、是否有定义不清、是否存在证据不足
• Judge Agent：基于“轨迹 + 里程碑集合 + 验证结果 + reviewer 反馈”给出最终 reward verdict

4.2 为什么不是单 judge？

作者的逻辑很直接：

• 单 judge 要么看最后状态，漏过程；
• 要么看全轨迹，但长上下文会稀释关键信号；
• RL 场景里最怕的不是 recall 略低，而是 precision 太差导致错奖励。

所以 OS-Themis 的设计目标不是一味追 recall，而是：

在 recall 仍足够高的前提下，优先压低 false positive rate。

论文 Appendix A 还给了一个简化推导：当 recall 已足够支撑学习时，适度牺牲 recall、换取更大幅度的假阳性下降，会提升 precision，并带来更可靠的 policy-gradient 学习信号。

4.3 可复现的数据流（高层）

如果你要自己复现一个 OS-Themis 风格系统，最关键的数据流大概是：

Step 1：准备 trajectory 表示

每条轨迹至少包含：

• 用户任务指令 / assignment
• 按时间顺序排列的截图序列
• agent 的动作/思考/输出（如果有）
• 终止状态
• benchmark 原生 evaluator 给的最终 True/False（训练 critic 时可作为监督或校准参考）

正文可确认：OGRBench 的轨迹表示至少包含全序列截图 + agent 模型输出，标签来自各 benchmark 的内置评测规则。

Step 2：Selector 抽关键里程碑

Selector 不应该机械等距抽帧，而要找“会决定成败的步骤”。 文中 case 说明与提示词原则表明，优先选：

• 读取权威答案来源的步骤
• 真正完成关键动作的步骤
• 输入最终答案/提交结果的步骤
• 容易造成真假分歧的转折点

如果没有“绝对确定”的关键点，Selector 仍必须给出“最可能关键”的步骤，而不是空返回。

Step 3：给每个里程碑配验证目标

Verifier 不是泛泛问“这步是不是看起来差不多”，而是要拿着assignment goal / success criteria 去验。 这点在 ablation 里非常关键：

• 不给 assignment goal，Verifier 会明显更宽松；
• 宽松会带来更多假阳性；
• 假阳性会拖坏 RL reward 质量。

Step 4：Reviewer 审计证据链

Reviewer 的职责不是再判一次真假，而是问：

• 这些里程碑够不够覆盖必要子目标？
• 某些里程碑是否定义模糊、成功标准不清？
• 是否遗漏了某个决定性步骤？
• 某条负面/正面结论是否缺证据？

而且 reviewer 被要求 strict evidence-grounding：提出的问题必须能在轨迹里找到可观察证据支撑。

Step 5：Judge 输出最终 reward

Judge 最终不是只看“最后留下几个通过的里程碑”，而是看整个 deliberation 过程：

• 原始 trajectory
• 初始/修订后的 milestone 集合
• verification 结果
• reviewer 的问题与反馈

论文明确声称：用完整 refinement process，而不只看最终 milestone outcome，可以显著减少 false positives，同时保持较高 recall。

4.4 OGRBench：他们顺手补了一个 benchmark

作者还提出了 OmniGUIRewardBench（OGRBench），定位是跨平台 GUI outcome reward benchmark。

正文可确认的构成：

• 平台来源：
  • AndroidWorld
  • OSWorld（Ubuntu）
  • WindowsAgentArena
  • macOSArena
  • WebArena-Lite-v2
• 标签：二分类 True / False
• 标签来源：各 benchmark 内置评测规则自动生成
• 数据规模（Table 8）：
  • Ubuntu: 393 positive / 348 negative
  • Android: 98 / 90
  • Windows: 94 / 119
  • macOS: 16 / 61
  • Web: 99 / 91
  • Total: 700 positive / 709 negative

这个 benchmark 本身就有实用价值： 它不是评 agent 本身，而是评“谁更会判 agent 有没有完成任务”。这对做 reward model / evaluator 的人很重要。

5. 实验（任务 / 指标 / 关键数字）

5.1 OGRBench 上的 critic 表现

作者声称

在所有测试 backbone 上，OS-Themis 都给出了最好的框架表现；平均来看，相比 DigiRL 与 ZeroGUI 都有显著提升。

正文可见关键数字

论文正文明确写到：

• 相比 DigiRL，OS-Themis 平均提升：
  • Accuracy +18.8%
  • Precision +29.6%
  • Recall +16.9%
  • F1 +26.2%
• 相比 ZeroGUI，平均提升：
  • Accuracy +7.7%
  • Precision +5.1%
  • Recall +13.0%
  • F1 +13.4%

表格可见的代表性数字

从正文抽到的 Table 1 / Table 6 片段里，可以看到一些具体值：

• DigiRL + Qwen3-VL-8B：Overall Acc 64.4 / Prec 62.2 / Rec 72.1 / F1 66.8
• 在单 agent scaling（Table 10）中，OS-Themis base（all 8B）已经达到：
  • Acc 79.4 / Prec 86.3 / Rec 69.4 / F1 77.0
• 把 Judge 升到 Qwen3-VL-235B：
  • Acc 82.4 / Prec 84.5 / Rec 79.1 / F1 81.7
• 把 Verifier 升到 Qwen3-VL-235B：
  • Acc 82.5 / Prec 88.9 / Rec 74.1 / F1 80.8
• 把 Reviewer 升到 Qwen3-VL-235B：
  • Acc 79.3 / Prec 89.1 / Rec 66.4 / F1 76.1

我的判断

这里最值得注意的不是“多了几个点”，而是：

• Reviewer 升级主要推高 precision，符合它“挑错、压假阳性”的角色；
• Judge / Verifier 升级更决定 overall effectiveness；
• 这说明 OS-Themis 不是简单集成投票，而是真的有角色分工。

5.2 AndroidWorld 在线 RL

任务设定

正文可确认：

• 在线 RL 在交互式 Android 环境里做；
• 基座 policy 用 Qwen3-VL-4B / 8B；
• 对比 reward source 包括 baseline、SEAgent、ZeroGUI、OS-Themis；
• 每个配置从同一初始化独立训练。

Table 2 关键数字

Qwen3-VL-4B backbone

• Baseline：45.3
• SEAgent：47.8
• ZeroGUI (Qwen3-VL-235B)：46.1
• OS-Themis (Qwen3-VL-8B)：50.9
• OS-Themis (Qwen3-VL-235B)：51.3

Qwen3-VL-8B backbone

• Baseline：47.6
• SEAgent：50.0
• ZeroGUI (Qwen3-VL-235B)：51.7
• OS-Themis (Qwen3-VL-8B)：53.4
• OS-Themis (Qwen3-VL-235B)：54.7

结论

• 对 4B：相对 baseline +6.0（45.3 → 51.3）
• 对 8B：相对 baseline +7.1（47.6 → 54.7）
• 对 8B，相比 ZeroGUI 也还有 +3.0 的优势

我的判断

这组结果比较有说服力，因为它不是“静态离线判分更准一点”，而是 reward judge 真的影响了 RL 后的策略表现。

5.3 在线 RL 扩展实验

作者还做了一个更接近“能不能规模化”的 pilot：

• 使用 Qwen3-VL-4B 做 policy
• 用 OS-Themis 框架中的 Qwen3-VL-235B 负责轨迹打分
• 从模板生成并筛选出任务，实例化 1024 个训练任务
• 每个任务 rollout 4 条轨迹
• 用 GRPO 做 1 epoch 在线强化学习
• 使用 low_var_kl，kl_coef = 0.005

关键结果

• 当训练扩展到 1024 tasks 时，Qwen3-VL-4B 在 AndroidWorld 上达到 55.6%
• 相比 baseline 提升 10.3%

我的判断

这组结果还称不上“工业级大规模 RL 已经跑通”，但足够说明： OS-Themis 不只是一个静态 evaluator，也能作为 RL reward function 工作。

5.4 自进化数据过滤 / SFT

作者声称

用 OS-Themis 过滤轨迹再做 SFT，可以比基线更好，也比直接用未过滤原始数据更好。

正文可见数字

• 在 Qwen3-VL-4B / 8B 上，使用 OS-Themis 过滤的数据做 SFT，分别带来 +6.9% 和 +5.0% 提升
• 若直接用全部未过滤数据，模型性能反而下降，说明原始采集轨迹噪声很大

这意味着什么？

OS-Themis 不只适合作为训练时 reward，还适合作为：

• 数据清洗器
• 轨迹筛选器
• 自进化闭环里的“质量门”

6. Ablation / 分析

6.1 去掉不同角色会怎样？

Table 3 给了一个很关键的 ablation：

• OS-Themis Full：Acc 88.0 / Prec 92.8 / Rec 82.3
• w/o Selector：Acc 83.3 / Prec 79.7 / Rec 88.9
• w/o Verifier：Acc 81.9 / Prec 77.2 / Rec 90.1
• w/o Reviewer：Acc 86.9 / Prec 85.7 / Rec 88.4
• w/o Judge：Acc 52.5 / Prec 89.7 / Rec 5.0

怎么读这张表？

• 去掉 Selector 或 Verifier，precision 明显掉，recall 反而更高：说明系统变“松”了，更容易误判成功。
• 去掉 Reviewer，精度也掉，说明 reviewer 的确在压假阳性。
• 去掉 Judge 最夸张：precision 看起来还高，但 recall 只剩 5.0，几乎不敢判成功。这说明最后的 calibrated aggregation 非常关键。

6.2 Assignment goal 很重要

作者在 ablation 里明确指出：

• 没有 assignment goal，Verifier 更容易“过于宽松”，批准错误轨迹；
• 加入 assignment goal 后，precision 明显改善。

这其实给了一个很实用的工程启发：

evaluator 不是只看轨迹本身，而是必须绑定“任务成功条件”。

如果你的 success criterion 没写清，critic 很容易被“看起来差不多”的 GUI 状态骗过去。

6.3 测试时投票（test-time scaling）

作者还分析了三种 voting：

• Majority：默认最稳，accuracy 相对稳定，但 recall 会受阈值影响波动
• All：precision 随 k 增加而提升，recall 近线性下降；适合极度怕假阳性的场景
• Any：recall 提升明显，但 precision 会掉；适合初筛

这个分析是有工程指导意义的：

• 做 RL reward / 高质量指令数据筛选：更偏向 All / 高 precision
• 做候选召回 / 初筛：可以考虑 Any / 高 recall

7. 局限与适用边界

作者自己承认的方向

正文 limitations 段能确认几件事：

• 当前结果主要证明初步可扩展性与稳定性，不是把 online RL scaling 问题彻底解决了；
• 还有训练规模、系统开销、长期稳定性等后续空间；
• 评估本身有额外算力成本，不过作者认为相对 rollout 时间占比不高。

文中还给了一个开销量级：

• 采一个 batch trajectory 平均约 3420s
• OS-Themis 评估平均约 117.6s
• 约为 rollout 时间的 3%
• 且评估与在线环境解耦，不阻塞后续 rollout

我的判断

这篇的局限也很明确：

1. 它主要解决“怎么判 reward”，不是直接解决“agent 怎么行动”。如果 policy backbone 很弱，critic 再强也救不了全部问题。
2. 多 agent critic 的实现成本不低。尤其如果全用大模型做 judge/reviewer/verifier，推理预算会明显上升。
3. 复现门槛不低。需要 GUI 环境、轨迹采集、评测规则、并行 rollout 基础设施。
4. 目前最强证据集中在 AndroidWorld / OGRBench 这类环境，跨更多真实桌面/浏览器生产任务的泛化，还得继续看。
5. 正文给出的是系统级思路和不少关键数字，但底层 prompt、消息格式、失败重试细则、缓存/裁剪策略等实现细节还需要看代码。

8. 复现清单（Checklist）

下面按“如果我要复现一个 OS-Themis 风格最小系统”来列。

8.1 数据

• GUI 任务集：至少先接 AndroidWorld；若要做完整 benchmark，可再接 OSWorld / Windows / macOS / WebArena-Lite-v2
• 每条样本需要：
  • assignment / task goal
  • trajectory 全部截图
  • agent 输出/动作轨迹
  • benchmark 内置 evaluator 给的真值标签

8.2 系统模块

• Selector
• Verifier
• Reviewer
• Judge
• 统一的 milestone 数据结构
• 统一的 verification record / review feedback schema

8.3 Prompt / 规则

至少要显式规定：

• Selector 如何定义关键步骤
• Verifier 如何绑定 assignment goal
• Reviewer 必须 evidence-grounded
• Judge 如何融合 review chain 与 milestone verdict

8.4 训练 / 推理配置（正文可确认部分）

• Online RL 算法：GRPO
• 一个 scaling pilot 配置：
  • 1024 training tasks
  • 每任务 4 rollouts
  • 1 epoch online RL
  • low_var_kl
  • kl_coef = 0.005
• AndroidWorld policy backbone：Qwen3-VL-4B / 8B
• Reward backbone：文中多处使用 Qwen3-VL-8B / 235B

8.5 评测

• critic 评测：Accuracy / Precision / Recall / F1
• policy 评测：AndroidWorld built-in evaluation accuracy/score
• 数据过滤验证：SFT 后 AndroidWorld 表现

8.6 我认为复现时最容易踩坑的点

• milestone 抽取太稀：漏关键失败点
• milestone 抽取太密：上下文又爆炸
• verification criteria 不具体：precision 会塌
• review 环节不强制证据约束：会变成“第二个空谈 judge”
• reward pipeline 和 rollout pipeline 串行耦合太重：吞吐会很差

9. 我的判断：值不值得深读？怎么用？

值不值得深读？

值得。 尤其如果你关心的是：

• browser/computer use agent
• GUI agent 的在线 RL
• trajectory filtering / self-improving agents
• evaluator / reward model 设计

这篇比“单纯换大模型 backbone 再刷分”的工作更值得跟。

我最认可的点

1. 把 reward judge 当成第一等公民来做，这是对的。
2. 强调 precision-first 的 RL reward 观，非常工程化。
3. 里程碑验证 + reviewer 审计，属于真的能落地的系统分解。
4. OGRBench 让这个方向至少有了一个更像样的离线评测面板。

我保留的地方

1. 还要看代码，才能确认它到底有多少“prompt engineering”成分、多少是稳定可迁移设计。
2. 目前 strongest evidence 主要还是作者自建 benchmark + AndroidWorld，外部复现还没看到。
3. 如果没有足够强的底层 VL model，多 agent critic 框架的上限会受限。

如果你要把它用进自己的系统

我会建议两条最现实的落地方向：

方向 A：先别急着做 full RL，先做 trajectory filter

先拿它做：

• browser/computer-use 轨迹自动筛选
• 高质量 SFT 数据清洗
• 离线 evaluator

这是最容易出收益、也最容易验证的路线。

方向 B：把“assignment-bound verification”学过去

就算你不照搬四 agent，也至少要做：

• 任务目标显式化
• 关键步骤抽取
• 逐点验证
• 最终 verdict 前的反事实/挑错审计

这套思想很可能比“直接把整段轨迹塞给一个 judge”稳得多。

10. 为什么今天选它，而不是其他候选？

今天我粗筛到的候选里，和 agent / LLM 主线更相关的大概包括：

• OS-Themis（GUI rewards / online RL / self-evolving agents）
• Box Maze（LLM reasoning 控制架构）
• Nemotron-Cascade 2（post-training + agentic capabilities）
• NavTrust（embodied navigation trustworthiness benchmark）

最终选 OS-Themis，原因是：

1. 主线相关性强：它直接打在 GUI agent / computer-use / RL reward 这个热点交叉点上；
2. 方法不是换壳 benchmark：它有明确系统拆解，而不是只发一个分数榜；
3. 证据相对完整：有 benchmark、有 RL、有 scaling、有 filtering、有 ablation；
4. 可落地性高：就算不全复现，也能把其中的 critic 设计思想迁到自己的 agent pipeline。

如果只想看一篇“今天最可能对 agent 实战有用”的，我会给它。

• Previous
  obra/superpowers 深入解读：一个面向可落地的 Agent Skills 框架
• Next
  claude-hud 深入解读