Computer-use agent 正在从演示走向产品。模型能看屏幕、点按钮、输入表单、读网页、操作桌面应用，也能在手机环境里跨 app 完成任务。但一个更基础的问题没有解决：它到底有没有完成任务？
普通问答任务可以比对答案，代码任务可以跑测试，数学题可以看最终数值。电脑操作任务复杂得多。一个轨迹里有截图、鼠标键盘动作、工具调用、模型推理、环境状态变化和最终页面。人类看一遍都可能漏掉细节，更别说把每条轨迹都交给人工审核。于是很多团队把 VLM 当 judge：把轨迹喂给视觉语言模型，让它判定成功或失败。
OSReward: Instituting Standardized Evaluation for Cross-Platform Computer-Use Reward Models 正是在质疑这条默认路线。论文 2026 年 7 月 30 日发布，8 月 7 日进入 Hugging Face Daily Papers 第 2 位。它提出的核心判断很直接：当前 VLM judge 还不够可靠，尤其容易把失败的 computer-use 轨迹误判为成功。
CUA 轨迹为什么难评
CUA trajectory 不是一段文本，而是一组交错记录：用户指令、屏幕状态、agent 动作、工具返回、模型解释和中间观察。一个任务是否完成，经常依赖非常细的状态。
例如，“把文件重命名后移动到指定文件夹”看似简单，但 judge 需要确认文件名是否完全匹配、目标文件夹是否正确、是否误移动了同名文件、操作是否真实生效。浏览器任务也类似：填表成功不等于提交成功，提交成功不等于服务端接受，页面显示“完成”也可能只是前端状态。
这就是通用 VLM judge 的难点。它可以看懂截图和文本，却未必能稳定追踪跨平台动作序列。它也可能受最终页面的表面提示影响，对中间错误不敏感。OSReward 把这种问题称为对 CUA reward 的系统化评估缺口。
OSReward 做了什么
论文构建了一个 realistic benchmark，用于评估 VLM judge 对 CUA 轨迹的判断能力。根据 Hugging Face 页面摘要，这些轨迹来自不同 agent backbones，在 web、Windows、Ubuntu、mobile 等平台上执行经过人工验证的指令，然后经过多阶段人工标注得到 ground-truth verdict。
这件事的重要性在于“跨平台”。很多 agent benchmark 只看 web 或单一沙箱，容易把评测问题简化成网页点击是否到达目标页面。但真实 CUA 系统会横跨浏览器、桌面软件、文件系统、移动界面和本地工具。跨平台轨迹让 judge 必须理解更多 UI 语义和状态转移。
论文还派生出 OSReward-Hard 和 OSReward-Multi。前者集中真正困难的 case，用来观察 judge 在边界场景中的失败；后者关注更细粒度的效率与 alignment 打分。这说明作者不是只想给模型排榜，而是想建立 reward model 的诊断工具。
关键发现：judge 偏宽松
最有工程价值的结论，是 VLM judge 存在 systematic leniency bias。换句话说，它们倾向于把失败运行判成成功。
这比“模型偶尔看错截图”严重得多。如果 judge 偏严格，开发者会多做一些人工复核，成本上升但安全性还在。如果 judge 偏宽松，失败轨迹会进入训练数据、评测结果会虚高、上线门禁会漏过问题。对 RL 来说，这相当于奖励模型在鼓励错误行为。
论文还指出，少数可靠 judge 成本太高，便宜开源模型明显落后。这是 CUA 规模化训练的现实瓶颈：你可以收集大量轨迹，却付不起每条轨迹都用 frontier VLM 细判的成本。
OS-Shepherd 的价值
为了解决成本和可靠性之间的矛盾，论文发布了 OS-Shepherd-100K，这是一个带 reasoning annotation 的 CUA judge 样本语料，并训练了 OS-Shepherd 9B 和 35B reward models。Hugging Face 页面称这些开放模型能以更低成本提供稳定可靠的 reward signal，并接近商业 judge。
这对开发者有两个启发。
第一，reward model 应该领域化。电脑操作轨迹的判定不是通用视觉问答，而是一种带状态追踪、动作语义和任务验收的专门能力。让通用 VLM 直接判，等于把领域评估外包给一个没有足够校准的模型。
第二，reward model 需要 reasoned judgment。只输出 success 或 fail 不够，最好能说明哪一步满足或违背了任务要求。这样的解释不只是给人看，也能帮助构造 hard negative、清洗数据和定位 agent 失败阶段。
工程系统该怎么接入
如果你正在做 CUA 产品，不必马上训练自己的 OS-Shepherd，但应该把评测管线改成分层结构。
第一层是规则检查。凡是可机器验证的结果，不要交给模型。例如文件是否存在、URL 是否匹配、表单字段是否保存、API 是否返回成功、数据库是否出现记录。这些规则廉价、稳定、可解释。
第二层是轨迹 judge。把规则无法覆盖的 UI 语义、视觉状态和步骤合理性交给专用 reward model 或强 VLM。但 judge 的输出不要直接作为真相，而应保留置信度、理由和引用帧。
第三层是人工抽检。抽检不应随机平均，而要集中在 judge 置信度低、任务高风险、轨迹很长、动作包含外部副作用、或规则与 judge 结论冲突的样本。
可以把记录格式设计成这样：
type CuaEvaluation = {
taskId: string;
platform: "web" | "windows" | "ubuntu" | "mobile";
ruleVerdict: "pass" | "fail" | "unknown";
judgeVerdict: "success" | "failure" | "uncertain";
judgeConfidence: number;
evidenceFrames: string[];
failureStage?: "perception" | "planning" | "action" | "verification";
needsHumanReview: boolean;
};这个结构的重点是保留冲突。例如规则显示文件没移动，但 judge 觉得成功，就必须进入人工复核。反过来，如果规则通过但 judge 发现 UI 中有错误提示，也不能直接放行。
对 RL 的影响
CUA 的强化学习尤其依赖 reward。任务成功与否如果判错，训练就会快速学坏。偏宽松 judge 会让 agent 学会“看起来完成”，而不是真正完成。比如它可能学会停在一个相似页面、伪造最终状态、忽略错误提示，或者利用 judge 对截图的浅层理解。
OSReward 的意义在于给 RL 管线补上 reward audit。训练前先问：我的 judge 对失败样本的误判率是多少？对 hard case 是否稳定？在不同平台上是否偏差一致？成本是否能支撑在线筛选？没有这些问题，所谓 CUA RL 很可能只是把评测噪声放大。
对产品上线的影响
产品上线时，judge 不应只用于离线 benchmark，也应该进入发布门禁。每次 agent planner、视觉解析、执行器或提示词变更，都要跑固定 CUA regression set。这个集合至少包含三类样本：
一类是 golden paths，确认核心能力没有倒退。一类是 known failures，确认系统不会把历史失败误判成成功。第三类是 adversarial tasks，例如相似按钮、错误弹窗、延迟加载、权限弹窗、重复文件名和跨页面状态丢失。
OSReward-Hard 的思想可以直接迁移：不要只用平均任务评估 agent，而要保留一组真正容易误判的 hard set。
局限
OSReward 也不是终点。首先，轨迹标注本身昂贵，多阶段人工标注仍然可能有边界争议。其次，跨平台覆盖再广，也不可能覆盖所有企业软件、内部工具和语言环境。第三，reward model 可能学习 benchmark 的判定风格，而不是完全泛化到你的产品。
所以最稳妥的做法是把它当作评测框架和训练资源，而不是一键替代本地验收。真正上线前，还要把自己的高频工作流、失败样本和风险操作加入评测集。
结论
OSReward 把 CUA 领域一个容易被忽略的问题摆到了台前：当 agent 能操作电脑以后，最稀缺的不只是更强的执行模型，而是可信、可扩展、成本可控的奖励模型。
没有可靠 reward，benchmark 会虚高，数据清洗会掺水，RL 会奖励错行为，产品上线也会错把“看起来完成”当成“真的完成”。OSReward、OSReward-Hard、OSReward-Multi 和 OS-Shepherd 的组合，为 CUA 评测提供了更专业的基础设施。对开发者来说，下一步不是把所有轨迹都丢给一个通用 VLM，而是建立规则、专用 judge、人工抽检和 hard regression set 共同工作的评测系统。
参考来源：Hugging Face Daily Papers: OSReward、arXiv:2607.28609、OSReward 项目页。