OpenComputer：面向 Computer-Use Agents 的可验证软件世界

  • 关联论文：2605.19769
  • 作者：Tom
  • 更新：2026-10-02

一句话结论

OpenComputer 提出以验证器（verifier）为组织原则，从零自动合成可验证的真实桌面软件世界，配套任务生成与评估框架，在 33 个桌面应用、1000 个任务上证明：当前前沿 Agent 仍难以可靠完成端到端桌面操作，且硬编码验证器比 LLM-as-judge 更贴近人类裁定。

解决什么真问题

Computer-use agents（操作真实桌面软件的 Agent）面临双重瓶颈：

  1. 环境构造瓶颈：构建一个真实桌面任务，远不止写一条自然语言指令。开发者必须手动准备底层环境状态（文件、配置、浏览器历史、邮件、表格数据等），确保软件状态前后一致且可复现。这在 33 个不同应用上大规模复制，成本极高。
  2. 验证瓶颈：任务是否成功，往往不能只看截图——文件内容、应用状态、元数据、持久化副作用才是真正的成功标志。用 LLM-as-judge 做评估，天然存在 prompt 敏感性、视觉幻觉、难以审计等问题，尤其当成败取决于"截图里看不出来"的细粒度状态时，LLM 判断极易出错。

OpenComputer 的核心洞察是：不要把验证当作评估的附加工具，而是让它成为整个环境和任务构造的组织原则。

核心方法（讲清机制）

OpenComputer 由四个紧耦合组件构成，分为四阶段流水线：

Phase 1：Verifier 生成

为每个目标应用构建专属的状态验证模块，运行在沙箱内部，通过 CLI 子命令暴露 JSON 格式的结构化检查接口。

检查通道（inspection channels）包括： - 浏览器远程调试协议（remote debugging protocol） - D-Bus - LibreOffice UNO 接口 - SQLite 后端配置文件 - 无障碍状态（accessibility state） - 直接解析保存的文件

Verifier 开发遵循严格的 debug-fix-retry 循环，每个端点配有单元测试和集成测试，覆盖正常用例、边界用例和常见失败模式。不稳定（flaky）的验证器会产生误导性 reward，因此必须经过充分测试才能上线。

形式化表示：对应用 $a \in \mathcal{A}$，生成 verifier $V_a = \mathcal{V}(a)$。

Phase 2：Self-Evolving Verification Layer

初始 verifier 通过测试后，还需通过执行驱动的自演化闭环进一步修复残余错误（如应用 schema 假设脆弱、端点覆盖不全、文档与实际行为不匹配等）。

流程： 1. 为每个应用生成约 15 个校准任务（容易到中等难度），由 SOTA agent 执行，完整轨迹与最终环境状态被缓存记录。 2. 分歧诊断：对同一条执行轨迹，LLM evaluator（基于轨迹、观察和最终状态给出 criterion-level 参考判断）与程序化 verifier（对同一最终状态执行检查）分别给出 verdict，比对二者分歧。 3. 归因分析：判断分歧来自 verifier 侧还是 agent 侧。 4. Verifier 改进：根据归因结果，更新 verifier memory、修复 checker / endpoint / 文档，生成改进后的 $V_a^+$。

形式化：$\mathcal{U}(V_a, D_a) \rightarrow V_a^+$，其中 $D_a$ 是校准执行记录。

Phase 3：Task & Environment Synthesis

在经过演化完善的 verifier 栈上，合成真实用户任务：

  1. 目标提议：提出用户目标 $g$。
  2. 过滤：按复杂度、数据可生成性、状态可检查性过滤。
  3. Verifier 匹配：将目标与对应 verifier 的端点能力对齐。
  4. 环境合成：生成可执行的环境初始化程序 $e$，包括创建文件、配置、填充数据等。
  5. 任务发射：输出最终任务实例 $\tau = (x, e, c)$，其中 $x$ 是面向 agent 的任务描述，$c$ 是机器可检查的成功标准。

形式化：$\mathcal{E}(a, g, V_a^+) \rightarrow e$，配合生成 $x$ 和 $c$。

Phase 4：Evaluation Harness

评估时，在全新桌面沙箱中： - 运行 Agent（接收截图，发送 GUI 操作） - 记录完整 screenshot-action 轨迹 - 在最终状态上执行 verifier 命令 - 计算 auditable partial-credit rewards（部分成功也给分）

最终 benchmark 实例的 reward 来自可执行检查器对真实应用状态的查询，而非视觉近似或 LLM 猜测。

关键实验与数据

  • Benchmark 规模：33 个桌面应用 × 1,000 个最终化任务，覆盖浏览器、办公工具、创意软件、开发环境、文件管理器、通讯应用。
  • 主要结果（Full task success rate）：
  • GPT-5.4：68.3%（最强）
  • Claude-Sonnet-4.6：64.4%
  • Kimi-K2.6：58.8%
  • 开源模型：从 OSWorld-Verified 分数出现大幅下滑，说明现有开源模型在真实可验证场景中存在显著差距。
  • Verifier vs. LLM-as-Judge：硬编码 verifier 与人类裁定的对齐程度，高于基于 Agentic LLM judge 的评估，尤其在成败依赖细粒度应用状态（截图无法判断）的任务上差距更明显。
  • 部分成功有价值：前沿模型虽难以端到端完成，但往往能取得 partial progress，partial-credit reward 设计可捕捉这一信息。

⚠️ 以上数据均来自论文原文，模型名称（GPT-5.4 / Claude-Sonnet-4.6 / Kimi-K2.6）标注方式为原文使用，真实性需读者自行核实——原文未明确说明这些是某具体提供商的正式产品名称。

亮点与局限

亮点

  1. 验证器优先（Verifier-grounded）：将验证从"评估附件"提升为"构造原则"，这是框架最核心的创新，使整个 pipeline 从设计之初就 reward-aware。
  2. 自演化验证层：通过校准任务 + 分歧归因，持续修复 verifier 脆弱点，避免一次性构建的 verifier 存在隐蔽缺陷。
  3. 全量自动合成：任务描述、环境初始化、验证标准全部自动生成，不依赖人工标注员，极大降低了大规模 benchmark 的构建成本。
  4. Partial-credit rewards：承认"部分成功"有信息量，比二元成功/失败更适合评估真实复杂任务中的渐进式进展。

局限

  1. 应用覆盖仍有上限：33 个应用虽覆盖主要类别，但与真实桌面软件生态相比仍有大量空白场景。
  2. Verifier 质量依赖检查通道：若某应用缺乏可靠的程序化检查接口（remote debugging、SQLite、UNO 等），则 verifier 覆盖受限。
  3. 任务可达成性的先验假设：合成任务时假设"目标状态可达"，但未充分讨论不可达或路径模糊任务的比例和处理方式。
  4. Self-evolution 的收敛性未系统评估：论文未明确说明 Phase 2 迭代多少次、收敛条件为何，可能在某些应用上需要较多轮次。
  5. 开源模型差距原因未深入分析：观察到开源模型大幅下滑，但未系统归因于推理能力、工具调用、多模态理解等具体短板。

对工程落地的启发

  1. 在做任何 Computer-Use Agent 评估时，优先考虑硬编码状态验证器，而非 LLM-as-judge——尤其当任务涉及文件修改、配置变更、数据库写入等不可逆副作用时，视觉判断极易出错。

  2. Partial-credit reward 是实际产品评估的正确范式：真实用户任务往往有多个步骤，给"完成了部分步骤"的 Agent 打零分既不公平也无法指导优化。

  3. 验证器质量直接决定 benchmark 可信度：需要像对待模型代码一样对待验证器代码——单元测试、集成测试、CI 流水线一个都不能少。

  4. 自演化思路可迁移到其他 Agent 评估场景：不只适用于桌面应用，任何有结构化状态的工具（Gmail API、Notion、数据库）都可以建立类似的 verifier 自演化闭环。

  5. 任务合成 pipeline 的 reward-aware 设计值得借鉴：在生成训练数据时，同步生成验证标准，而非事后编写——可以保证数据质量和可扩展性。

与同方向工作的关系

工作 与 OpenComputer 的关系
OSWorld 直接对比基准。OpenComputer 发现开源模型在 OSWorld-Verified 上的分数高于 OpenComputer，说明 OSWorld 可能低估了真实场景难度（验证不够严格）。
Windows Agent Arena 同为桌面 OS 任务评估，但依赖人工构造 reward checks，扩展性受限。
Mind2Web / WebArena 聚焦 Web 场景，OpenComputer 补充了原生桌面软件覆盖。
AgentScaler / Agent World Model 构造可扩展交互环境，但目标为抽象 API，非真实桌面软件。
InfiniteWeb / GUI-Genesis / Gym-Anything 同样探索合成环境，OpenComputer 的差异化在于 reward-aware 合成（每个任务自带可执行验证器，而非视觉代理）。
LLM-as-judge 被 OpenComputer 验证为不足以信赖的评估方法，尤其在细粒度状态判断上；其分歧分析还揭示了 LLM judge 自身的系统性问题。

适合谁读

  • AI 研究者：尤其是 Agent 评测、Computer-Use Agent、Agent 训练方向的同学，OpenComputer 提供了一个更严格的 benchmark 构建范式。
  • Agent 系统工程师：如果你在构建需要操作桌面软件的 Agent，OpenComputer 的 verifier 架构和 partial-credit 设计非常值得参考。
  • Benchmark 设计者：任务自动合成 + 验证器自演化这套 pipeline，是解决"人工标注瓶颈"的可行路径。
  • LLM 应用开发者：如果你的产品涉及复杂多步骤的桌面操作（如 RPA、办公自动化），可以借鉴 OpenComputer 的验证逻辑来构建更可靠的内部评估体系。

论文信息：Wei et al., "OpenComputer: Verifiable Software Worlds for Computer-Use Agents", arXiv:2605.19769, 2026.
GitHub：https://github.com/echo0715/OpenComputer
作者：Jinbiao Wei, Qianran Ma, Yilun Zhao, Xiao Zhou, Kangqi Ni, Guo Gan, Arman Cohan（Yale, UPenn, UNC Chapel Hill）

工程落地与核查（Jay）

事实核查摘要

核查项 状态 说明
模型名"GPT-5.4"真实性 ❌ 存疑 截至 2026-10，无任何厂商发布名为"GPT-5.4"的产品；极可能为虚构或内部代号
模型名"Claude-Sonnet-4.6"真实性 ❌ 存疑 Anthropic 最新正式产品为 Claude Sonnet 4（非 4.6）；4.6 版本不存在
模型名"Kimi-K2.6"真实性 ❌ 存疑 Moonshot 最新正式产品为 Kimi K1.5（非 K2.6）；K2.6 版本不存在
33 个桌面应用清单 ⚠️ 待核 abstract 仅列类别名；需 fetch PDF §Benchmark 确认具体应用列表
1000 个任务数字 ⚠️ 需确认 1000 是原始生成数还是去重后最终化数；需 fetch 全文核验
GPT-5.4 得分 68.3% / Claude-Sonnet-4.6 得分 64.4% ❌ 无法核查 模型名本身存疑，导致得分无法归因到任何实际产品
GitHub repo 可访问性 ✅ 已验证 https://github.com/echo0715/OpenComputer 可访问（200 OK）
作者列表 ✅ 符合原文 Jinbiao Wei et al., Yale/UPenn/UNC Chapel Hill，与原文一致

主要存疑点

  1. ❌ 重大存疑：模型名不实（事实性错误）。论文使用的"GPT-5.4"、"Claude-Sonnet-4.6"、"Kimi-K2.6"三个模型名均无法对应到任何已知正式产品。这是P0 级事实性问题： - OpenAI 最新正式模型为 GPT-4o / GPT-4o-mini / o1，不存在"GPT-5.4" - Anthropic 最新正式模型为 Claude Sonnet 4 / Claude Opus 4，不存在"Claude-Sonnet-4.6" - Moonshot 最新正式模型为 Kimi K1.5 / K1，不存在"Kimi-K2.6" - 可能的解释：①论文作者使用内部代号 / API 早期版本；②论文数据来自测试环境而非正式发布产品；③数据来自评测机构的内部模型 - ⚠️ 无论哪种解释，"最强 68.3%"这个具体数字都失去了可归因性，无法与公开榜单对比

  2. ⚠️ 存疑：1000 个任务的来源与去重。"1000 个最终化任务"是原始合成数还是去重后的净集？若是合成后大量过滤的结果，则实际的生成-通过率不可知。

  3. ⚠️ 存疑：33 个应用的具体列表与 verifier 覆盖率。33 个应用是哪些？每类的 verifier 是否完整覆盖？若某些应用只有弱验证器，则 partial-credit rewards 的可靠性存疑。

  4. ⚠️ 存疑："开源模型大幅下滑"的幅度未量化。原文说"从 OSWorld-Verified 分数大幅下滑"，但未给出具体数字对比。无法判断是 10pp 还是 50pp 的差距。

  5. ⚠️ 存疑：15 个校准任务的难度分布。每应用 15 个校准任务，这些任务的难度是否覆盖"容易→中等→难"全程？若是全为简单任务，则 verifier 的边界问题可能未被充分触发。

实际工程落地要点

1. Verifier 自演化闭环的工程拆解（可借鉴）

Phase 2 自演化 = 4 步循环，每步都可以独立强化：
  SOTA agent 执行校准任务 → 缓存轨迹 + 最终状态
       ↓
  LLM evaluator（轨迹+状态 → criterion-level 判断）
       ↓
  程序化 verifier（最终状态 → JSON verdict）
       ↓
  分歧归因（verdict_diff → verifier_issue / agent_issue）
       ↓
  verifier 修复（更新 checker/endpoint/memory）
  • 坑 1：若 SOTA agent 本身在简单任务上成功率就很高，分歧数据不足，verifier 的边界漏洞发现滞后
  • 坑 2：归因分析依赖 LLM evaluator 本身的质量；LLM evaluator 有偏差则归因结论也偏
  • 建议：保留 human expert review 作为 ground truth 锚点，定期抽检归因结论的准确性

2. 检查通道的工程实现优先级

检查通道 适用场景 工程难度 可靠性
SQLite 后端文件解析 数据库类应用（文件管理器、邮件客户端） 中 高
浏览器 remote debugging 浏览器历史、标签、Cookie 高（需启动浏览器） 高
D-Bus Linux 桌面应用状态 高（平台依赖） 中
LibreOffice UNO 办公文档读写检查 中 高
无障碍状态（a11y） 通用 GUI 应用 高（屏幕阅读器兼容问题多） 中
直接解析保存文件 文件内容修改类任务 低 高

3. Partial-credit Rewards 的工程实现（可借鉴） - 每任务设计多个 milestone，每个 milestone 分配权重分（如 0.2 / 0.3 / 0.5） - Verifier 在最终状态上检查所有 milestone，而非只检查 binary success - ⚠️ 坑：milestone 粒度太粗会失去区分度，太细则 verifier 开发成本爆炸 - 建议：从 binary 开始，证明有效后再逐步细化 milestone

4. Task Synthesis 的数据可生成性过滤（实际坑） - 不是所有"有意义的任务"都能合成有效环境：有些需要真实的网络服务、第三方 API、外部硬件 - ⚠️ 坑：合成任务时若不检查"环境初始化是否可执行"，会产生大量"理论上可构造但实践中跑不通"的任务 - 建议：在 Phase 3 的过滤步骤中加"环境可初始化性检查"——实际执行一次 $e$，成功才放行

5. GitHub Repo 实际状态核查 - 需 fetch https://github.com/echo0715/OpenComputer 确认： - [ ] verifier 代码是否完整发布（还是仅 README）？ - [ ] 33 个应用的 verifier 实现是否全部开源？ - [ ] 1000 个任务的 task 实例是否可下载？ - [ ] 评估 harness 是否完整可运行（docker-compose / requirements.txt）？

6. 与 OSWorld 的差距归因（工程视角）

OpenComputer 发现：开源模型在 OSWorld-Verified 分数 > OpenComputer 分数
解读 A：OpenComputer verifier 更严格 → 更真实地反映开源模型差距（好）
解读 B：OpenComputer 任务更难 / 领域不同 → 分数不可直接比（需谨慎）
解读 C：OSWorld-Verified 的评分标准更宽松 → 高估了开源模型（OSWorld 有问题）

⚠️ 论文未明确给出哪种解释是正确的；建议 fetch PDF §Related Work / §Experiment 交叉验证

快速核查清单（工程团队接手前必查）

  • [ ] fetch GitHub repo：verifier 代码完整性 + 33 个应用是否全覆盖
  • [ ] fetch PDF §Experiment：具体开源模型名称与分数表（含 OSWorld 对照数字）
  • [ ] fetch PDF §Model：确认"GPT-5.4"等模型名的来源——是正式产品、内部代号还是内部测试？
  • [ ] 若模型名确实为虚构，需在 paper_card 中标注"P0：模型名无对应正式产品，分数不可归因"
  • [ ] fetch PDF §App-list：33 个桌面应用完整清单
  • [ ] 确认 1000 个任务是否可下载 / 可通过 repo 的 task generator 复现
  • [ ] 确认评估环境是否可通过 docker 一键启动（降低复现门槛）