为什么值得读
桌面/移动/网页 Agent 的数据筛选、评测和 RL 奖励都卡在同一件事上——怎么可靠判断任务真的完成了。VLM 裁判只看给它的观察，生成程序只能读可访问状态，两种局部视角都会漏掉决定性证据，而假完成正是奖励被 hack 的入口。
为什么两种主流验证器都不够
VLM 裁判的输入是被投喂的若干观察，画面之外的应用状态它看不到，于是结论常常只能靠猜；生成程序能读状态，但只能读「可访问」的那部分，遇到不可编程检查的界面就失灵。
更麻烦的是工程成本：不同平台、不同观测模态各写一套验证器，扩展性差，且每套都要单独调阈值。
把验证定义成「在共享流程里动态取证」
流程第一步不是判断，而是审阅可用上下文、把任务拆成一份 rubric——把「完成」拆成若干可单独判定的要求。
第二步对每条未解决的要求选证据通道：能用代码检查的就跑代码（读应用状态），必须要看界面的就走 GUI 检查。
第三步按显式证据规则合并各路结论，而不是让模型自由心证；同一套程序同时服务在线（真机/浏览器）与离线（轨迹回放）场景。
结果与归因
实验显示与参考标签的一致性优于所比较的基线；离线难例上的增益最大，在线场景下对「假称完成」的拒绝更强。
消融分析把增益归到两点：证据互补（不同通道看到的东西不重叠）与测试时探查（多花几步去看）。这个归因比单纯的分数更有信息量——它说明瓶颈在「看不全」，不在「判不准」。
对做 Agent 产品的团队意味着什么
如果你在用 CUA 跑数据闭环或 RL，验证器的核心指标不是平均准确率，而是「假完成的拒绝率」。奖励信号被伪造完成骗过一次，后面所有训练都在学错的东西。
可复用的架构提示是「rubric 前置 + 证据通道可插拔」：新增平台时只需加通道，不必重写判定逻辑。
以「与参考标签的一致性」为主要指标，而参考标签本身可能带偏；agentic 探查会带来额外调用次数与时延，摘要未给成本-精度曲线；覆盖面广但每个平台的探查深度有限；未报告在长任务、多应用协同场景下的表现。
本文基于论文原文摘要与方法章节整理，观点由编辑撰写；如与原文有出入，以 arXiv 原文为准。 内容为信息整理与技术评论，不构成投资或决策建议。 发现错误请通过站内纠错页提交（记录可查），修订记录只增不删。