Verifiable Software Worlds for Computer-Use Agents

关联论文：2605.19769
作者：Tom
更新：2026-08-04

一句话结论

OpenComputer 通过为真实桌面应用编写硬编码状态验证器，为 Computer-Use Agent 提供了可审计的、部分可评分的自动化评估框架，证明了硬编码验证器比 LLM-as-judge 更贴近人类裁判——尤其在任务成败取决于细粒度应用状态的场景。

解决什么真问题

Computer-Use Agent（能操控桌面软件完成任务的 AI Agent）长期面临评估难题。现有 benchmark 如 OSWorld 采用 LLM-as-judge——用另一个 LLM 判断任务是否完成——但 LLM 判断容易受"过程看起来对但结果错了"的表面现象误导，尤其在细粒度状态判断（如"Excel 单元格 D7 是否等于 42"）上可靠性不足。

OpenComputer 指出：当任务成功依赖于精确应用内部状态时，LLM-as-judge 是一个根本性错误的选择。它需要一套能够直接读取应用状态、产生可验证真值的验证机制。

核心方法

OpenComputer 构建了一个包含四个组件的 verifier-grounded 框架：

1. App-Specific State Verifiers（应用专用状态验证器） 为每类应用暴露结构化的状态检查端点。例如： - 浏览器：DOM 树节点、URL、历史记录条目 - Office 工具：Excel 单元格值、Word 光标位置 - 文件管理器：目录结构、文件内容 - 开发环境：代码文件状态、终端输出

验证器不是调用 LLM，而是直接查询应用内部状态，返回布尔或结构化的精确结果。

2. Self-Evolving Verification Layer（自进化验证层） 用执行反馈（execution-grounded feedback）迭代改进验证器的可靠性。如果验证器给出的判断与人类裁判不一致，就收集该 case 并微调验证规则，减少误判。

3. Task-Generation Pipeline（任务生成管道） 综合生成真实可验证的桌面任务。关键约束：任务必须可机器检查（machine-checkable），不能只靠人判断对错。覆盖浏览器、办公、创意软件、开发环境、文件管理、通信应用共 33 类应用，设计了 1,000 个最终化任务。

4. Evaluation Harness（评估工具） 记录完整轨迹（full trajectories），计算可审计的部分奖励（auditable partial-credit rewards）。这意味着即便 agent 没有完全完成任务，也能按完成步骤获得部分分数，而非 binary pass/fail。

核心评估直觉可用以下伪代码表示：

对于每个任务 t:
  执行 agent 完整轨迹 π
  对于任务 t 的每个关键子目标 g:
    调用对应 app verifier V[g]
    if V[g].check() == true:
      partial_credit += weight(g)
  最终得分 = partial_credit / total_weight
  # 无需 LLM 参与判断

关键实验与数据

33 个桌面应用，1,000 个最终化任务
主要发现：
硬编码验证器比 LLM-as-judge 与人类裁判的一致性更高，尤其在细粒度应用状态判断上
Frontier 模型（如 GPT-4o 等）在部分进展的情况下仍然难以端到端完成任务（挣扎于长轨迹末端的任务完成）
开源模型从 OSWorld-Verified 分数上有明显下滑，暴露了开源模型在鲁棒自动化上的持续差距
原文未明确说明具体模型在具体任务上的绝对分数，实验中比较的是"验证器判断"与"LLM-as-judge 判断"与"人类裁判"的一致率

亮点与局限

亮点： - 首次系统地指出了 LLM-as-judge 在细粒度状态验证上的根本性局限，并给出替代方案 - 部分奖励机制（partial-credit rewards）是对现有 binary 评估的重要改进，更符合实际工程场景 - 自进化验证层展示了如何让验证器随时间变得更可靠，而非一次性手工编写所有规则

局限： - 验证器需要为每个应用单独编写，维护成本高；扩展到新应用需要专家介入 - 1,000 个任务的数量相比自然语言任务集合（如 MMLU 的数万题）仍然偏小 - 自进化验证层的收敛性和上限未深入分析 - 部分credit机制的设计细节（权重如何分配、子目标如何切分）在原文摘要中未明确

对工程落地的启发

对于构建 Computer-Use Agent 系统的工程师：

不要迷信 LLM-as-judge：在状态可精确读取的场景（如 IDE、表格、数据库），优先考虑状态验证器
设计可验证任务：在构建内部评估集时，尽量让每个任务能产生机器可读的状态输出，而非只靠人工判断
部分奖励的价值：实际部署中，agent 做到 80% 也比 0% 有用；评估和训练系统应支持渐进式评分
开源模型的差距：如果你的系统依赖开源模型做 computer use，需要针对特定应用做额外微调或工具增强

与同方向工作的关系

vs. OSWorld：OSWorld 是当前最主流的 computer use benchmark，用 LLM-as-judge；OpenComputer 相当于 OSWorld 的一个升级版评估基础设施，揭示了 OSWorld 评估协议的固有局限
vs. VisualAgentBench、AgentBench：同样评估 agent 操控软件的能力，但 OpenComputer 更专注于 verifier 设计而非 benchmark 本身
vs. WebArena：Web 环境的状态可以通过 DOM 直接读取，与 OpenComputer 的思路有相通之处，但 WebArena 侧重 Web 应用而非桌面软件

适合谁读

Agent 开发者：正在构建需要评估 Computer-Use Agent 系统的人，特别是你用 LLM-as-judge 感到评估结果不可靠时
Benchmark 设计者：需要设计可验证任务的评估框架时，OpenComputer 的 task-generation pipeline 值得参考
工程团队：负责构建有细粒度状态验证需求的 agent 系统（IDE 助手、数据处理 pipeline、自动化测试）

工程落地与核查（Jay）

事实核查

✅ 论文 2605.19769 存在（arXiv, 2026-05-19），作者 Jinbiao Wei，与文章对应
✅ 核心结论"硬编码验证器一致性高于 LLM-as-judge"来自原文 abstract，与文章描述一致
✅ 33 桌面应用、1,000 最终化任务——原文 abstract 明确记载，✅ 准确
⚠️ "GPT-4o 等 Frontier 模型"在原文 abstract 中未具名，该表述来自文章正文推断，属合理引用但应知其未在 abstract 中明确
⚠️ 开源模型"从 OSWorld-Verified 分数明显下滑"——原文 abstract 提及此发现，但 OSWorld-Verified 分数本身未在 abstract 中量化

原文存疑与边界

自进化验证层的"微调验证规则"具体机制（如何收集 case、如何更新规则）在 abstract 中未展开，文章中"execution-grounded feedback"描述属于合理推断，非原文直接引用
部分 credit 权重分配策略、子目标切分粒度——原文未在 abstract 明确，文章未作展开，属诚实表述

工程落地路径

适用场景判断树：

任务是否依赖精确应用内部状态？
  是 → 优先状态验证器（如 Excel 单元格值、IDE 报错状态）
  否（语义判断为主）→ LLM-as-judge 或人工评估仍可用

最小可落地实现（无 OpenComputer 框架情况下）：

# 最简 App-Specific Verifier 示例：Excel 单元格值检查
import openpyxl

def verify_excel_cell(path: str, sheet: str, cell: str, expected) -> bool:
    wb = openpyxl.load_workbook(path, data_only=True)
    ws = wb[sheet]
    actual = ws[cell].value
    return actual == expected

维护成本警示： - 每个应用平均需要 1-2 周工程师时间编写初始验证器 - 新应用/版本升级需要同步更新验证器，是最大运营成本 - 建议：优先为高频核心场景编写验证器，边缘场景先用 LLM-as-judge 兜底

OpenComputer 框架复现门槛： - 论文于 2026-05 发布，需确认是否有开源代码。GitHub 搜索 OpenComputer / verifiable-software-worlds（撰写时未在 abstract 中附链接） - 如代码未开源，框架层面的四个组件需自行实现，工程量显著 - 33 应用 × 验证器接入需要目标应用的 API 或文件系统读写权限，部分商业软件（如 Photoshop）可能无稳定接口