OpenComputer：面向计算机使用智能体的可验证软件世界 OpenComputer: Verifiable Software Worlds for Computer-Use Agents
以验证器为中心的框架，合成1000个可机器检查的桌面任务。
前置知识
Computer-Use Agent
通过截图观察桌面状态并输出鼠标键盘动作来操作真实软件应用的智能体，本质上是 GUI-grounded 强化学习或 SFT 策略。代表性系统包括 GPT-5.4、Claude-Sonnet-4.6、Kimi-K2.6。
本文评测对象就是这一类 agent，benchmark 的任务、轨迹和 verifier 都围绕截图-动作闭环设计。
LLM-as-Judge
用大语言模型作为裁判，根据文本/图像判断 agent 输出是否成功。优势是灵活，但易受 prompt 措辞、视觉近似和模型偏差影响，难以审计复现。
它是当前 OSWorld 等基准的主流评估方式，本文正是要证明 hard-coded verifier 比 LLM-as-judge 更贴近人类判定。
程序化验证器 (Hard-Coded Verifier)
直接调用 CDP、D-Bus、SQLite、UNO、ffprobe 等应用专属接口读取底层状态，并暴露 JSON CLI 端点作为 reward 函数，区别于基于像素的视觉近似。
它是 OpenComputer 的核心组件，决定任务能否机器检查，所有评估奖励 $R=N_{\text{pass}}/N_{\text{total}}$ 都由其产出。
沙箱桌面环境
在 Docker 或虚拟机中启动的隔离 Linux 桌面，agent 可在其中自由点击、打开应用、读写文件，结束时可被冻结以查询任意应用状态。
1000 个任务每个都需要 fresh sandbox，初始化脚本 $e$ 和 checker $c$ 都运行于其内，是基准可复现性的物理基础。
部分得分奖励 (Partial-Credit Reward)
把任务拆成多条独立 success criterion，最终 reward 取通过条目的比例 $R=N_{\text{pass}}/N_{\text{total}}$，而不是 0/1 二元判定，便于定位 agent 失败模式。
它是评估表的 metric 基础，让 88.4% 这种平均 reward 与 68.3% 成功率可以同时报告。
研究动机
现有 computer-use benchmark 如 OSWorld、Windows Agent Arena、WebArena、VisualWebArena 等基本依赖人工构建任务，规模普遍只有几十到几百实例，且评估多采用 LLM-as-judge 从截图判断成功。然而 LLM 判官对细粒度应用状态——表格分列错误、面板折叠项被编辑、文件元数据未更新、终端 scrollback 残留——容易给出虚高分数。开源 GUI agent 在 OSWorld 报出 50%+ 成绩，看似接近人类水平，但真正可验证的端到端完成度可能远低于此；此外每个新任务都需要人工编写 reward check，使得大规模合成难以扩展。
本文的目标是提出 OpenComputer 框架，把验证器当作基准构建的一等公民，自动合成覆盖 33 款桌面应用、1000 个任务的 benchmark，每个任务都附带可执行 checker、可执行环境初始化脚本和自然语言指令。评估从视觉近似走向可审计的程序化判定，并提供部分得分奖励以支持细粒度失败分析；最终推动 computer-use 研究拥有像 ImageNet 之于分类那样可大规模扩展、可机器验证的评测基础设施。
与已有工作不同的是，与 OSWorld 等把验证放在 benchmark 构建之后、且依赖 LLM-judge 的方案不同，OpenComputer 验证器先行：先用稳定接口（CDP、D-Bus、AT-SPI、SQLite、UNO、ffprobe 等）暴露应用真实状态，再用 agent 执行反馈自我修复验证器，最后才合成任务。这一顺序保证每个任务的 reward 都能落地为可执行命令，且当 LLM 判官与程序化 verdict 不一致时能定位到 verifier 端加以修正。
核心方法
OpenComputer 采用四阶段 pipeline 设计：Phase 1 为每款应用生成 Python 验证器模块，暴露 JSON 格式 CLI 端点 query-* 和 check-*；Phase 2 用约 15 个校准任务的 agent 执行轨迹驱动验证器自演化；Phase 3 在验证器基础上合成真实用户目标并物化环境；Phase 4 跑 agent 并执行 checker 计算部分得分奖励 $R=N_{\text{pass}}/N_{\text{total}}$。整体把验证器 $V_a$、任务 $\tau=(x,e,c)$、演化 $U(V_a,D_a)\to V_a^+$ 耦合为闭环。
与 LLM-judge 路线最本质的区别在于：OpenComputer 不依赖视觉近似判断成功，而是通过应用专属的检查端点直接查询底层状态——CDP 读 Chrome/Brave profile，UNO 读 LibreOffice 文档，SQLite 读 darktable/obsidian 数据库，AT-SPI 读 GUI 可访问性树，ffprobe 读媒体文件等。当 LLM 判官和程序化 verdict 不一致时，分析阶段把分歧归因到 agent 失败或 verifier 失败，verifier-attributed 错误被用于迭代修复 checker 代码、端点或文档，把验证器本身当作可调试软件工件对待。
方法步骤详情
第一阶段枚举应用可观察状态面并映射到最可靠 inspection channel，编写单元与集成测试，通过 debug-fix-retry 循环直到端点稳定。第二阶段跑 SOTA agent 在约 15 个校准任务上得到从 $s_0$ 到 $s_T$ 的冻结轨迹，LLM evaluator 对每条 criterion 出 reference verdict，与程序 verifier 的 structured verdict criterion-by-criterion 比对，verifier-attributed 错误进入至多 3 轮的修复循环 $V_a^+\leftarrow U(V_a,D_a)$。第三阶段由 LLM 提议候选任务，按复杂度、可生成性、可检查性过滤后必要时扩展 verifier 端点，再打包为 task.json $(x,e,c)$。第四阶段用 fresh sandbox 跑 agent 并执行 checker 得到部分得分奖励。
技术新颖性
技术新颖性体现在三方面：(1) 验证器优先的设计——把什么状态可被程序化检查作为基准设计约束而非事后补充；(2) 自演化机制——用真实 agent 执行暴露 verifier 的脆弱假设，3 轮预算内修复 89.4% 的 checker-side 错误，把人类-checker 一致性从 85.2% 抬到 94.1%；(3) 可审计的部分得分——区别于 binary reward，$R=N_{\text{pass}}/N_{\text{total}}$ 同时给出细粒度失败定位和总体可比性，且 reward 函数本身可在执行后复算。
实验结果
实验给出四组关键数据。第一组主表 (Table 2) 显示 GPT-5.4 以 68.3% 成功率、88.4% 平均 reward 领先，Claude-Sonnet-4.6 达 64.4%/76.6%，Kimi-K2.6 为 58.8%/70.7%，开源模型大幅下滑——Qwen-3.5-27B 从 OSWorld 56.2% 跌到 32.3%，GUI-OWL-1.5-8B 从 52.3% 暴跌至 5.7%，EvoCUA-8B 从 46.1% 降至 10.9%。第二组验证器对比 (Figure 3) 显示 hard-coded verifier 与人类 checklist 一致性达 97.3%、任务级 94.1%，LLM-judge 仅 92.2% 和 79.2%。第三组 ablation (Table 4) 证明 self-evolution 修复 76 个 checker-side 错误中的 68 个 (89.4%)。第四组 GUI-CLI 对比 (Table 3) 在 14 应用/343 任务子集上，CLI 平均 141 秒/任务远快于 GUI 288 秒。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| OpenComputer 1000-task 主基准 | 成功率 / 平均 Reward | GPT-5.4 68.3% / 88.4%；Claude-Sonnet-4.6 64.4% / 76.6%；Kimi-K2.6 58.8% / 70.7% | OSWorld-Verified 报告分 75.0% / 72.5% / 73.1% | 闭源 frontier agent 仍比 OSWorld 低 6-15 pp，开源模型跌幅高达 44-46 pp |
| 验证器 vs LLM-judge 与人类一致性 | Per-item Checklist Agreement / Task-level Alignment | Hard-coded verifier 97.3% / 94.1%（120 任务） | LLM-as-judge 92.2% / 79.2%（同 120 任务） | checklist 一致性 +5.1 pp，任务级对齐 +14.9 pp |
| Self-Evolving Verification 修复效率 | 修复率 / 人类-checker 一致性提升 | 76 个 checker-side 错误中修复 68 个 (89.4%)；一致性 85.2%→94.1% | 演化前同一组 checker：85.2% | +8.9 pp 人类一致性，且 47/76 在 1 轮内修复 |
| GUI vs CLI 控制效率 | 成功率 / 平均每任务秒数 | CLI Claude Code 67.2% / 141s | GUI GPT-5.4 75.2% / 288s；GUI Claude-Sonnet-4.6 73.0% / 622s | CLI 速度快 2-4.4 倍，但成功率低 6-8 pp |
局限与改进
作者明确承认三类局限：(1) 视觉/几何判断难完全程序化——Draw.io 箭头是否连接两框、Blender 视角对齐、字体排版等仍需视觉判断；(2) 1000 任务生成中有 17 个含不可完全程序化验证 criterion 的任务被剔除，仅保留做诊断；(3) 任务由 LLM 提议可能存在分布偏差，过度集中在 LLM 擅长或熟悉的 workflows。我额外观察到：self-evolution 只用约 15 校准任务覆盖单个应用，对罕见 corner case 覆盖不足；3 轮修复预算对 OSWorld 级 agent 收敛较快，对更弱 agent 可能不收敛；评测仅覆盖 8 个模型，未包括 Anthropic Computer Use 最新版本或 OpenAI o3 等。
独立分析的弱点
独立分析有四点弱点：(1) GUI-OWL-1.5-8B 从 52.3% 跌至 5.7%、EvoCUA-8B 从 46.1% 跌至 10.9% 暴露开源 agent 严重泛化失败，但论文未深入分解失败是 planning 错误还是 grounding 错误；(2) verifier 端点开发高度依赖领域知识（CDP/UNO/AT-SPI/SQLite），新应用接入门槛陡峭；(3) $R=N_{\text{pass}}/N_{\text{total}}$ 无法反映 checker 间依赖关系，扭曲可比性；(4) Gemini-3-Flash 不提供内置桌面 action space，被 prompt 改写后参与评测，可比性受损。改进方向：提供分层诊断 (per-criterion failure attribution + planning vs execution 拆分)、跨应用 verifier 模板、以及考虑依赖的加权 reward $\mathcal{R}=\sum_i w_i\cdot\mathbb{1}[c_i\text{ passed}]$。
未来方向
作者指出三条延伸路径：(1) 用真实 agent 轨迹收集 SFT/rejection sampling 数据或用 $R=N_{\text{pass}}/N_{\text{total}}$ 作为 RL 奖励训练；(2) 混合验证——可执行 checker 配 LLM 视觉判断用于 layout/几何类标准；(3) 扩展到移动、Web、终端等更广域。我补充的可能方向：把 verifier 模块开放为协议允许社区扩展应用；引入任务难度动态调整；用 OpenComputer 作为 reward model 训练 self-play agent；以及把 $\mathcal{R}$ 重定义成考虑 checker 依赖的加权 reward，让 17 个被剔除任务也有可计算得分。
复现评估
复现性整体较好：(1) 完整代码、verifier 模块、任务规范、初始化脚本和评估 harness 已在 GitHub (echo0715/OpenComputer) 开源；(2) 1000 任务的 task.json 与环境脚本可直接消费；(3) 支持 Docker 本地、AWS/Tencent Cloud/E2B 云端并行 rollout；(4) 算力需求方面，开源模型（除 Kimi-K2.6 走 API）需 2×H100 部署，闭源模型经官方 API 调用；(5) 难度集中在 verifier 端点开发——需 CDP、D-Bus、SQLite、AT-SPI、ffprobe 等多领域知识，普通研究者扩展新应用成本较高，但消费已有 1000 任务的门槛低，可直接对接论文报告的 reward。
论文图表
