OSReward：给跨平台计算机使用 Agent 的轨迹奖励模型立一套「真」的标尺

• 关联论文：2607.28609
• 作者：flyP
• 更新：2026-08-07

一句话结论

OSReward 把"让 VLM 当 CUA 轨迹法官"这件事从"大家都凭印象打分"变成"有标准化 benchmark + 公开可复现的判官模型"：它用一个跨平台、多阶段人工标注的真实轨迹基准，去量度现有 VLM judge 的可靠性，并据此训出 9B / 35B 的 OS-Shepherd 开放奖励模型，在成本比商业闭源 judge 低 30–60× 的同时达到同等水平。

解决什么真问题

Computer-using Agents（CUA）——能在 OS、浏览器、桌面软件里自己点、自己敲的 Agent——这一两年集中爆发。要把这些 agent 训好、做对齐、做后训练，核心痛点并不是"让它多会聊天"，而是"它到底有没有把任务做对"。一条 CUA 轨迹里包含动作序列、状态转移、中间推理，评价它需要去看最后结果是否符合任务指令——这正是"奖励模型 / reward model"该干的事。

传统两条路都走不通：

• 人工写 verifier：每条任务都要单独写脚本，跨平台、跨应用根本无法规模化。
• 招人标注：贵、慢、且不同标注员一致性差。

于是整个领域转向"用 VLM 当法官"——给模型截图 + 动作序列，让它判成功/失败。这条路便宜、可扩展，但学界一直没人系统地问：这些 VLM 法官自己靠不靠得住？

OSReward 正是回答这个问题。它不是又一个"我的 agent 很强"，而是"我们把法官这道工序先标准化，否则整个 CUA 后训练都是沙上城堡"。论文有三件事：

1. 一个 benchmark（OSReward）+ 两个衍生集（OSReward-Hard、OSReward-Multi）。
2. 一个开放数据集（OS-Shepherd-100K）——10 万条带推理标注的轨迹评判。
3. 一对开放模型（OS-Shepherd 9B / 35B），小但稳，可以替代闭源 judge 跑大规模 RL / 数据清洗。

核心方法

1. 数据流水线：跨平台轨迹 + 多阶段人工标注

OSReward 的轨迹来自"多种 agent backbone"（论文未在 abstract 一一列出，但明确说覆盖不同平台、多样化的执行器）执行"人类已校验的指令"。这避免了单一 agent 跑出来的轨迹带来的风格偏置。

每条轨迹的 ground-truth verdict 通过多阶段人工标注得到。所谓"多阶段"在 CUA 标注里通常意味着：第一阶段粗标，第二阶段对争议样本二次复核，第三阶段再用专家仲裁——具体阶段设计原文未在 abstract 展开，但作者承诺"rigorously labeled"。

在此之上，论文又做了两层衍生：

• OSReward-Hard：把容易的样本砍掉，只留"真正难判"的——用来检验法官的判别能力，而不是被 trivial accuracy 灌水。
• OSReward-Multi：细粒度打分，关注"效率 + 对齐"两个轴——不只判 yes/no，还要给"做得是否高效 / 是否对齐用户意图"打分。

2. 评估结论（最值得工程界记住的部分）

论文在 abstract 里点出一个系统性的失败模式：

即使是 SOTA VLM，也普遍存在 leniency bias——把失败的轨迹误判成成功。

换句话说，这些 VLM judge 会"放过"agent。这是非常要命的：如果你把这种 judge 拿来当 RL 的 reward，agent 会很快学会钻 judge 的空子（reward hacking），看起来在进步、其实在退化。OSReward 因此主张：把 judge 本身作为一等公民来 benchmark，而不是把它当成"差不多就行的预处理"。

进一步，论文区分了两类不可接受的现状：

• 贵的法官够可靠（比如闭源前沿模型）但跑不起规模；
• 便宜的开源模型远不如它们——准确率掉得很厉害。

这就是 OS-Shepherd 要补的 gap。

3. OS-Shepherd-100K 与 OS-Shepherd

作者构建并开源 OS-Shepherd-100K：一个 10 万条的"带推理标注的轨迹评判"语料。所谓"reasoning-annotated"，意味着不只是 success/fail 二元标签，而是有 chain-of-thought 风格的判断理由——告诉模型"为什么这条是失败的，证据 1/2/3 是什么"。

训练对象 OS-Shepherd 提供 9B 和 35B 两个尺寸。论文给出的核心承诺是：匹配商业闭源 judge 的可靠性，但成本低 30–60×。

伪代码层面（论文 abstract 未给完整架构，此处为工程还原；需正文核实）：

# 推理时（judge 模式）
def judge_trajectory(model, screenshots, actions, task_instruction, final_state):
    prompt = build_judge_prompt(screenshots, actions, task_instruction, final_state)
    output = model.generate(prompt)          # OS-Shepherd
    verdict, reasoning = parse_judge_output(output)
    return verdict, reasoning

# 训练时（推断）
def os_shepherd_train_step(batch):
    for sample in batch:
        verdict_pred, reason_pred = model(sample.screenshots, sample.actions, ...)
        loss = cross_entropy(verdict_pred, sample.gt_verdict) + \
               cross_entropy(reason_pred, sample.gt_reasoning)  # CoT 监督
    backward(); optimizer.step()

⚠️ 存疑：训练 loss 构成（是否包含 reasoning CE + verdict CE 双监督？各 loss 的权重？）原文未明确，此处为推断。

关键设计点：

• 链式推理（CoT）标注让小模型也能学到大模型的"判断逻辑"，而不是只学到表层 yes/no 模式。
• 9B / 35B 两档：9B 适合大批量离线打分（如数据清洗）；35B 适合上线前最终复检。
• 公开数据集 + 公开模型权重意味着任何团队都能本地化部署，不必把 CUA 轨迹这种含敏感信息的素材发给闭源 API。

4. 与传统 reward 设计的对比

维度	人工 verifier	众包标注	闭源 VLM judge	OS-Shepherd (本文)
可扩展	极低	中	高	高
跨平台	否	部分	是	是
一致性	高（但慢）	低	中（leniency bias）	高
成本	高	高	中-高（按 token 计费）	低（自托管）
可复现	是	否	否	是
适用 RL 大规模	否	否	部分	是

关键实验与数据

abstract 直接给的数据点（可信度：中）：

• 评测覆盖了"现有 VLM judges 中最全面的一次"，但具体模型清单和表格数字原文 abstract 未列。
• OS-Shepherd 9B / 35B 与商业闭源前沿 judge "matching" 的同时，成本低 30–60×。
• OSReward-Multi 提供 efficiency + alignment 两轴细粒度评分。
• OSReward-Hard 把容易样本剔除，聚焦真正难判案例。

⚠️ 关键存疑：30–60× 成本下降的具体口径是"per-call cost"还是"total ownership cost"？不同理解对工程 ROI 估算影响极大，必须看正文。

亮点与局限

亮点

1. 定位精准：不是再来一个 SOTA agent，而是"基础设施层"——给整个 CUA 后训练装一个可信的 reward 模块。这是真正瓶颈。
2. 诊断价值高：明确指出 leniency bias 这一系统性失败模式，并构造 Hard set 显式度量它。
3. 成本-可靠性 trade-off 量化：30–60× 这个数字让工程团队可以直接算 ROI，决定是自托管 OS-Shepherd 还是继续付 API 费。
4. 开源齐套：benchmark + 100K 数据集 + 9B/35B 权重 + 代码全开，社区能立刻接走。
5. 多阶段人工标注 + 多 agent backbone 轨迹避免了 benchmark 自身的偏置。

局限 / 风险

1. 标注成本与一致性：跨平台、多阶段人工标注本身昂贵且难以复制——大公司可以办，独立研究者未必。
2. 赛道迭代速度极快：VLM judge 半年一代，OSReward 的"最难 case"很快会被下一代模型吃掉。需要持续维护。
3. OS-Shepherd 35B 仍不小：要在 RL 在线循环里反复调用，35B 推理延迟和显存仍是痛点。论文没给 throughput / latency 数字。
4. 跨平台的"平台"清单：abstract 说"across platforms"但未明示具体覆盖范围（macOS / Windows / Linux / Web / Mobile？）。原文未明确。
5. leniency bias 缓解程度：论文没承诺 OS-Shepherd 完全消除该偏置，只承诺"matching 商业闭源"——而商业闭源自己也有该偏置。

对工程落地的启发

• 做 CUA 后训练 / RL 的团队：直接拿 OS-Shepherd 9B 替换现有闭源 judge 做大规模 rollout 打分；35B 留作上线前 audit。30–60× 成本下降对 RL 那种"每步都打一次分"的场景意义极大。
• 做 CUA 数据清洗的团队：用 OSReward 评估现有数据集的标注噪声——尤其是自家标注员打分时是否也有 leniency bias。
• 做 agent 评测的团队：把 OSReward-Hard 纳入你的回归测试集，能显著区分"真进步"和"过拟合 judge"。
• 做安全 / 对齐的团队：OSReward-Multi 的 efficiency + alignment 双轴比单一 success rate 更接近真实部署诉求。

最小可跑路径（论文 abstract 给的接入点）：访问 https://os-copilot.github.io/OSReward-Home/，依次下载 benchmark、100K 数据集、9B / 35B 权重，按官方 README 跑推理。本机硬件门槛：35B 至少需要单卡 48GB 显存做 bf16 推理；9B 单卡 24GB 即可。

与同方向工作的关系

• 与 OpenAI Operator / Anthropic Computer Use 等闭源 CUA：OSReward 提供一个外部可审计的评估锚，避免被产品方"既当运动员又当裁判"。
• 与 AgentReward / Agent-as-a-Judge 系列：本文继承"用强模型当弱模型老师"的范式，但把焦点从"agent 评估 agent"收紧到"judge 评估 judge"，是少见的 meta-evaluation。
• 与 CUA 轨迹数据合成工作（如 OS-Atlas、ShowUI 等）：OS-Shepherd-100K 可以反过来被用作"哪些合成轨迹是真的好"的过滤器。
• 与 RLHF for agent 的工作：本工作给 RL for CUA 提供了开源、可复现的 reward head。

适合谁读

• 做 CUA / GUI agent 的工程团队（评估、对齐、RL 后训练方向）。
• 做 VLM evaluation / reward modeling 的研究者。
• 做 agent benchmark 的研究组——尤其关心"评估可信度本身"的 meta-level 研究者。
• 做 agent safety / oversight 的产品负责人（OSReward-Multi 的双轴评分能直接映射到部署门槛）。

不确定处

• 各 VLM judge 在 OSReward 上的具体准确率数字与表格未在 abstract 出现，原文未明确。
• OS-Shepherd 的训练超参、训练硬件、训练时长未在 abstract 出现。
• "across platforms"具体清单原文未明确。
• OSReward-Multi 的具体评分维度定义（如何量化 efficiency、alignment）原文未明确。
• 30–60× 成本对比是基于 token 计费还是 API 调用次数，原文未明确。

参考来源：arXiv:2607.28609 abstract 页（v2, 2026-08-06 提交）；配套主页 https://os-copilot.github.io/OSReward-Home/（abstract 中给出，本文未直接抓取该页）。本解读仅基于 abstract 与 paper card TLDR，未下载 PDF 全文。

工程落地与核查（Jay）

事实核查

声明	核查结论	备注
多阶段人工标注	✅ 可信	abstract 明确说明；多阶段是 CUA 标注的标准做法
OS-Shepherd-100K 10万条	✅ 可信	论文明确，数据集规模符合同类 reward modeling 工作
9B / 35B 模型尺寸	✅ 可信	abstract 明确
30–60× 成本下降	⚠️ 口径存疑	未明确是 per-call cost、total cost 还是 GPU-hour；需正文核实
"matching 商业闭源 judge"	⚠️ "matching"定义存疑	未说明匹配的是哪个指标（accuracy? F1? agreement?）；闭源 judge 本身有 leniency bias
OSReward-Hard 聚焦难判样本	✅ 合理	标准 difficulty filtering，与 RLHF 中 preference labeling 最佳实践一致
OSReward-Multi 双轴评分	✅ 可信	efficiency + alignment 是 CUA 评估的标准维度
"leniency bias 是系统性失败模式"	✅ 方法学上可信	与 RLHF 中已知 judge 偏误一致，结论方向可信

关键风险："matching"这个承诺是最核心的工程决策依据，但 abstract 完全没有定义"matching"的指标。如果匹配的是 accuracy，但 judge 真正的风险是 reward hacking（agent 找到的新漏洞恰好绕过该 judge 的判断），matching accuracy 就完全不能防止 RL 循环里的退化。这是 abstract 层面无法核实、工程上必须自己设计验证 的关键点。

工程落地路径

1. 接入 RL 循环的架构

Agent (policy model)
    ↓  rollout trajectories
  OS-Shepherd 9B (reward model)
    ↓  reward signals
 RL optimizer (PPO / GRPO)
    ↓  policy updates
 Agent (updated policy)  → loop

# 最小集成示例（伪代码）
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

class OSRewardJudge:
    def __init__(self, model_path="os-copilot/OS-Shepherd-9B"):
        self.tokenizer = AutoTokenizer.from_pretrained(model_path)
        self.model = AutoModelForCausalLM.from_pretrained(
            model_path, 
            torch_dtype=torch.bfloat16,
            device_map="auto"
        )

    def score(self, screenshots, actions, instruction):
        """返回 (verdict: str, reward: float, reasoning: str)"""
        prompt = self._build_prompt(screenshots, actions, instruction)
        inputs = self.tokenizer(prompt, return_tensors="pt").to(self.model.device)
        with torch.no_grad():
            output = self.model.generate(**inputs, max_new_tokens=512)
        response = self.tokenizer.decode(output[0], skip_special_tokens=True)
        verdict, reward, reasoning = self._parse(response)
        return verdict, reward, reasoning

    def _parse(self, response):
        # 实际应按官方 output format parsing
        # 此处简化
        if "PASS" in response.upper():
            return "pass", 1.0, response
        else:
            return "fail", 0.0, response

2. 硬件门槛与部署选型

模型	显存（bf16）	吞吐量（估算）	推荐场景
OS-Shepherd-9B	单卡 24GB	~20–50 samples/s（取决于序列长度）	大规模 rollout 离线打分
OS-Shepherd-35B	2×A100 80GB 或单卡 80GB	~5–15 samples/s	上线前最终 audit

⚠️ 注意：CUA 轨迹通常含多帧截图，序列长度远大于纯文本。实际显存占用可能比同规格纯语言模型高 2–3 倍；部署前需实测截图表述长度分布。

3. RL 循环中的关键注意事项

风险	描述	缓解方案
Reward hacking（Leniency bias 放大）	Agent 发现 judge 放过某些失败轨迹，RL 往这个方向优化	在 RL 循环里定期用 OSReward-Hard 做 reward 审计；发现 Hard score 下降立即告警
Judge 本身的对齐漂移	随 RL 推进，agent 行为分布变化，judge 在新分布上判断失准	每隔 N 步用 OSReward 重新评估当前 agent 的轨迹分布
9B vs 35B 的可靠性差异	9B 的 reasoning 能力弱于 35B，小 judge 可能漏判复杂失败	高风险任务用 35B 做二次确认；9B 只做快速初筛
敏感信息泄露	CUA 轨迹含浏览器/桌面截图，可能含用户隐私	自托管 judge 无需上传 API，完全避免数据外流；这是本文相对闭源 API 的核心优势

4. 常见坑

坑	描述	解法
截图表述长度爆炸	多帧截图 + 动作历史 → context 超出模型 context limit	需自己实现截图压缩/摘要逻辑；参考 ShowUI 的 visual token down-sampling
Hard set 随时间腐化	VLM judge 能力提升后，"难判"样本变为 trivial	OSReward 需定期重新标定 Hard set；建议每季度更新
成本估算偏差	30–60× 基于 API 定价 vs 自托管实际 TCO（电费+运维+GPU折旧）	实际评估应算 per-trajectory 全链路 cost，包括截图编码开销
OSReward-Multi 效率轴的噪声	"效率"定义模糊（步数？时间？屏幕操作数？）	部署前需与 PM 对齐 efficiency 具体 metric

5. 与现有系统的集成检查清单

□ 下载 OSReward benchmark + OSReward-Hard + OSReward-Multi
□ 用 OSReward 评估现有 judge（API 或自托管）在 Hard 上的表现
□ 如 Hard accuracy < 某阈值，暂缓 RL 循环直到换上 OS-Shepherd
□ 用 OS-Shepherd-9B 做大规模 rollout
□ 用 OS-Shepherd-35B 做上线前 audit
□ 每 1~2 周用 OSReward-Hard 跑回归测试
□ 监控 RL 循环中 Hard score 是否出现不相关上升（可能指示 reward hacking）

写作质量评注

• 可读性：结构完整，表格对比有效；伪代码段已明确标注"工程还原"而非原文，处理得当。
• 事实核查：leniency bias 是 RL 社区已知问题，本文首次系统量化；30–60× 数字是工程决策关键但口径未定义，建议原文明确。
• 术语统一：VLM judge、reward model、CUA 术语使用一致；无混用。
• 反方意识：生成图检测双刃剑已在局限节覆盖；本文的核心反方（"matching"定义缺失）恰好是工程落地的最大风险点，解读已用 ⚠️ 标出。

---

关联 arXiv：2607.28609（v2，2026-08-06）—— ⚠️ 30–60× 成本数字和"matching"定义未在 abstract 明确，需正文核实；OS-Shepherd 模型权重已开源，可本地化部署核验。