OSWorld 2.0：把 Computer-Use Agent 的考卷从 30 步换成 318 步之后

OSWorld 1.0 发布时，一个任务平均只需要约 30 次工具调用就能走完。放在真实办公场景里，这个长度大概相当于「打开一个文件、改几个字段、保存」。GUI Agent 评测这两年一直在这个量级里内卷：ScreenSpot 刷点位精度，AndroidWorld/WebArena 刷几十步的任务成功率，各家模型的 leaderboard 数字越来越漂亮。但稍微往真实工作流里看一眼就会发现，一个跨部门的差旅报销、一次涉及多个信息源的合规审计，动辄需要几十上百次操作，中间还会有新邮件插进来、有人临时改预算、有单据信息互相矛盾。这类任务过去几乎不出现在任何 computer-use 基准里，不是因为它不重要，而是因为构造和标注它的成本极高。

OSWorld 2.0（arXiv:2606.29537，https://arxiv.org/abs/2606.29537）想补的就是这块空白：108 个长程真实世界工作流，人类完成的中位时间约 1.6 小时，用 Claude Opus 4.7 开满思考跑一遍平均要 318 次工具调用——对比 OSWorld 1.0 的约 30 次，长度提高了一个数量级。在这个新考卷下，当前最强的模型 Claude Opus 4.8 也只能完成 20.6% 的任务（部分完成度 54.8%），GPT-5.5 虽然 token 效率高很多，但成绩早早在 13% 附近见顶。这篇论文真正推进的不是又一个「更难的 OSWorld」，而是重新定义了长程 agent 评测应该测什么、怎么测。

目录

1. 为什么这篇论文值得关注
2. 背景与问题定义
3. 核心思路：十种挑战现象分类
4. 任务构建 Pipeline 拆解
5. 评测协议与主要结果
6. 成本-性能权衡：批处理动作 vs 单动作
7. 对 APP 自动化测试 / 移动端 QA 的工程启发
8. 局限性与点评
9. 总结
10. 参考链接

1. 为什么这篇论文值得关注

放在 OSWorld → AndroidWorld → VisualWebArena → C-World 这条评测演进线上看，OSWorld 2.0 的定位很明确：它不是在扩充任务数量，而是在扩充任务的时间跨度和状态复杂度。之前的 desktop/mobile agent 基准大多把任务设计成「单一意图、少量步骤、明确终态」，agent 只要不在前几步犯低级错误基本就能拿分。OSWorld 2.0 把评测单元从「一次操作序列」换成「一段真实工作流」，工作流内部会天然产生信息滞后、状态漂移、跨源信息不一致——这些恰恰是生产环境里最常让自动化脚本和 agent 翻车的地方，也恰恰是过去的 benchmark 设计不出来的。

它的第二个价值在于诚实地把当前 agent 的失败原因说清楚了：论文摘要里直接写明，模型不是卡在基础 GUI 操作或写代码能力上，而是丢失约束、漏掉任务中途到达的新信息、靠猜而不是问用户、跳过验证步骤，在任务依赖隐藏状态、需要主动恢复信息时表现最差。这是一份对 agent 能力边界给出具体、可复现证据的诊断报告，而不是一份自我表扬的成绩单。

2. 背景与问题定义

OSWorld 1.0（arXiv:2404.07972）确立了「在真实操作系统环境里跑多模态 agent、按最终状态判分」这个范式，此后 AndroidWorld、WindowsWorld、MacArena、C-World 等基准延续了同一套评测哲学，但基本停留在几十步、单一意图的任务规模。这类任务能测出 agent 会不会点按钮、会不会用输入框，测不出 agent 会不会在几百步的执行过程里保持对目标和约束的追踪。

OSWorld 2.0 的问题定义很直接：如果一个任务需要人类花 1.6 小时完成，中间涉及多个信息来源、多次状态变化、可能出现的用户澄清，那么把它压缩成一个「打开-操作-保存」式的短任务，测出来的分数对生产可用性没有代表性。论文因此选择直接构造长程、真实、跨源的工作流，作为衡量 agent 是否具备专业级计算机使用能力的新标尺。

3. 核心思路：十种挑战现象分类

OSWorld 2.0 没有笼统地说「任务更难了」，而是把长程真实工作流里反复出现、但过去基准覆盖不足的现象拆解成十种，分为两类：

交互设计类挑战：streaming interaction（流式交互，信息随时间持续到达）、dynamic environment（动态环境，外部状态在任务执行期间发生变化）。

Agent 模式类挑战：cross-source reasoning（跨源推理，需要综合多个信息源才能得出正确动作）、implicit-state inference（隐式状态推理，关键信息没有摆在明面上，需要主动恢复）、visual-spatial precision（视觉空间精度）、multimodal editing（多模态编辑）、multi-item tracking（多项目追踪）、proactive interaction（主动交互，agent 需要主动向用户澄清而不是自己猜）、conflict disambiguation（冲突消歧）、tutorial following（教程跟随）。

Figure 1 右侧的散点图信息量很大：横轴是每任务输出 token 数，纵轴是得分（注意纵轴顶部有折断，实际得分区间被压缩显示）。Claude Opus 4.8/4.7 系列曲线整体位于左上——用更多 token 换更高分；GPT-5.5 的曲线在低 token 区间就有相对不错的表现，说明它在 token 效率上占优，但曲线很快趋于平坦，天花板明显低于 Opus 系列。这与文本摘要里「GPT-5.5 更 token 高效但在 13% 附近见顶」的结论一致。

左侧的六步截图值得多看一眼：Step 1 是差旅报销指南文档，Step 108 要求 agent 从噪声与真实混合的收据邮件里挑出正确金额（跨源推理），Step 257 需要从之前的步骤记录里找隐藏信息（隐式状态推理），Step 372 是新邮件到达触发重新规划（动态环境），Step 499 是弹窗询问用户「乘客信息不符，是否报销」（主动交互）。这不是把几个独立子任务拼在一起，而是同一条任务轨迹里连续暴露多种挑战——这正是长程真实工作流和「多个短任务打包」的本质区别。

十种挑战现象在不同模型身上的暴露和处理情况也被单独统计出来：

这张图的价值在于把「模型在哪类问题上真正失败」和「模型压根没遇到这类问题」区分开——很多 benchmark 只报总分，掩盖了失败究竟集中在哪个能力维度。三个模型的 Blocked 比例分布并不均匀：隐式状态推理和跨源推理这两类需要主动恢复信息的挑战，普遍是三个模型 Blocked 占比最高的现象，印证了论文摘要里「agent 在需要恢复隐藏状态时表现最差」的结论；相比之下视觉空间精度、多模态编辑这类偏底层操作能力的现象，Handled 比例明显更高，说明当前模型的瓶颈确实已经不在基础 GUI 操作上，而在信息整合和状态推理这类更高层的认知能力上。

4. 任务构建 Pipeline 拆解

108 个长程任务不是靠模板批量生成的，构造成本本身就是这篇论文的重要贡献点。

任务收集阶段并行跑了四条路线：专家访谈（高质量但规模小）、问卷调查（速度快但留存率低）、头脑风暴（团队从 YouTube/文档/软件里学习领域知识，再结合 Reddit/教程/真实工作提出任务，同伴交叉验证可行性，质量和规模都不错）、LLM 合成提案（人工修复 + 试跑审计，方差较大）。四条路线汇总后经过复杂度、多样性、可行性三重筛选，只有通过筛选的候选任务才会进入任务规格化阶段。

任务规格化阶段生成一份包含指令、输入构件、中间约束、终态评估标准的规格表，并与可执行环境构建（搭建环境、跑评估器、生成测试）形成迭代循环——这一步保证了每个任务不是「写一段自然语言描述」，而是真正落地成可以自动判分的可执行环境。

质量保证栈是三层叠加：自动单元测试生成、人工交叉检查（两名标注员独立判断后比对一致性）、多模型轨迹回放。最后有四项显式检查：人工可行性通过、部分奖励审查通过、排除 reward-hacking、排除假阴性。这套流程直接回应了长程 agent 评测里最容易被诟病的问题——任务越复杂，越容易在设计终态判据时留下可以被 agent 投机取巧的漏洞（reward hacking），OSWorld 2.0 把排查这类漏洞做成了流程里的强制环节，而不是事后补救。

5. 评测协议与主要结果

主评测协议是 500-step 二元完成率（binary completion）配合部分完成度评分（partial score）。这两个指标的组合值得注意：二元完成率反映任务是否被完整正确地做完，部分完成度反映即使没做完，agent 到底往前推进了多少——对长程任务而言，这个区分比单一的成功/失败标签有意义得多。

Table 3 里最关键的几行数字：

• Claude Opus 4.8（批处理动作）：binary 20.6%，partial 54.8%，每任务成本约 72.4 美元，481.8 次工具调用，224K 输出 token——所有配置里的最佳成绩，但成本也最高。
• Claude Opus 4.7（批处理动作）：binary 18.2%，partial 48.9%，成本约 33.6 美元。
• GPT-5.5（批处理动作）：binary 13.0%，partial 49.5%，成本约 25.5 美元，只用了 149.8 次工具调用、37.1K 输出 token——工具调用数和 token 消耗只有 Opus 系列的三分之一到五分之一，partial score 却接近，token 效率明显占优。
• 单动作条件下：Claude 系列（8.3%~18.5%）明显好于 MiniMax M3、Kimi 2.6、Qwen 3.7-Plus（2.8%4.6%），后三者虽然成本极低（2.46.6 美元/任务），但完成率也低了一个数量级。

一个容易被忽略但很重要的细节：同一个模型在批处理动作条件下的表现普遍优于单动作条件（比如 Opus 4.8 批处理是 20.6%/54.8%，单动作是 18.5%/49.3%，且步数从 190.5 降到 103），这说明动作打包/并行发出的能力本身就是长程任务成功率的一个变量，而不仅仅是模型底层理解和规划能力的差异。

6. 成本-性能权衡：批处理动作 vs 单动作

Figure 6 把这个权衡可视化得很清楚：不管是按轮数还是按 token 计算，Claude Opus 系列和 GPT-5.5 共同构成了性能前沿，其中 Opus 系列走的是「高投入换高分」路线，GPT-5.5 走的是「少投入逼近前沿」路线；Claude Sonnet 4.6、MiniMax M3、Qwen 3.7-Plus 三者不论投入多少轮数或 token，得分都明显落在前沿内侧，说明它们目前不是「差一点」，而是存在结构性的能力差距。图中每个模型内部还标出了不同 reasoning effort（推理强度）下的表现，可以看到推理强度提高带来的收益存在明显边际递减——单纯加大推理开销不是免费的分数提升手段。

这里的工程含义是：如果要在生产环境里部署一个长程 computer-use agent，选型不能只看 leaderboard 上的单一分数，需要先确定自己的成本预算和轮数/延迟约束，再去前沿曲线上找对应区间里表现最好的模型，而不是无条件选榜首。

7. 对 APP 自动化测试 / 移动端 QA 的工程启发

OSWorld 2.0 是桌面场景基准，但它对长程任务的拆解方式对 APP 端自动化测试和移动端 QA 有直接的方法论迁移价值，主要体现在测试用例设计和评估闭环两个层面。

十种挑战现象可以直接映射成移动端测试的用例分类模板。streaming interaction 对应推送到达、IM 消息插入、直播弹幕干扰这类测试用例执行期间外部事件持续到达的场景；dynamic environment 对应后台状态变更、账户余额/库存实时变化、A/B 实验开关翻转；cross-source reasoning 对应需要同时核对 UI 展示值、接口返回值、本地缓存值、支付渠道对账单是否一致的用例；implicit-state inference 对应需要从多步之前的操作记录里恢复关键状态的场景，比如一个电商下单流程里，优惠券的可用性其实取决于三步之前选择的收货地址；proactive interaction 对应需要测试 agent/自动化脚本在遇到歧义（比如支付金额与展示金额不符）时是否会主动报错或请求人工确认，而不是静默继续执行。目前主流的 Appium/UIAutomator/XCUITest 用例大多只覆盖单一意图的短流程，这十个分类可以直接作为补齐长程业务流用例覆盖度的检查清单。

任务构建 pipeline 里的「规格表 + 可执行构建 + 迭代循环」结构，值得搬到测试用例生成流程里。当前很多 APP 测试用例生成方案（包括不少基于 LLM 的用例生成工具）止步于「生成步骤描述」，缺少可执行的终态判定标准。OSWorld 2.0 的做法是：每个任务规格表必须同时包含输入构件、中间约束、终态评估，并且规格表要和「搭建环境、跑评估器、生成测试」的可执行构建反复迭代，直到规格表描述的终态真的可以被自动化判定。放到 APP 测试场景，这意味着用例生成不能只产出操作步骤，还需要同步产出可执行的断言——UI 状态断言、业务状态断言（订单状态、库存变化）、日志/网络请求断言、崩溃/ANR 检测——并且这些断言要经过一轮「能不能真的跑起来判分」的验证,而不是留在文档里。

质量保证栈里排查 reward-hacking 和假阴性的思路，对应测试用例里排查「假通过」和「过度敏感」的问题。自动化测试长期存在两类顽疾：断言写得太宽松导致真实 bug 被放过（对应 reward-hacking，用例可以在不真正完成业务目标的情况下通过判定），断言写得太严格导致正常的 UI 微小差异触发误报（对应假阴性）。OSWorld 2.0 用「自动单元测试生成 + 人工交叉检查 + 多模型轨迹回放」三层质检来控制这两类问题，这个思路可以直接搬到测试用例评审流程：用例上线前跑多次不同环境/设备的回放，看是否存在因为环境差异导致的偶发失败或偶发通过，而不是只在单一设备单一环境下验收一次。

批处理动作 vs 单动作的成本-性能权衡，对应移动端自动化脚本里操作合并 vs 逐步执行的选择。移动端 UI 自动化里，把多个操作打包成一次动作序列（比如连续滑动+点击+输入）通常能减少截图/查询开销、降低总执行时间，但也会牺牲每一步的可观测性和失败定位精度。OSWorld 2.0 的数据显示，批处理动作在几乎所有场景下都优于单动作（同模型对比），这提示在设计移动端自动化执行引擎时，操作打包本身可能是一个被低估的效率杠杆，但需要配合更细粒度的执行后校验（而不是只在打包末尾校验一次），否则失败定位会变得更难。

8. 局限性与点评

真正贡献：把长程真实工作流的构造流程标准化，并给出了可复现的十种挑战现象分类框架，这个分类本身比单纯堆任务数量更有长期价值——后续论文可以直接引用这套分类来定位自己解决的是哪一类问题。同时，论文没有回避「当前最强模型完成率只有 20.6%」这个不好看的结果，反而把失败归因讲清楚了（丢约束、漏信息、靠猜不问、跳过验证），这比大多数只报成功率数字的 benchmark 论文更有诊断价值。

可能被高估的部分：108 个任务的规模决定了统计意义上的置信区间会比较宽,单个任务的极端难度或标注偏差对整体分数的影响会被放大;论文里的十种挑战现象是研究团队定义的分类体系,分类边界之间存在一定主观性(比如 cross-source reasoning 和 implicit-state inference 在很多任务里同时出现,很难说某个失败具体归因于哪一类);另外,评测环境是模拟的桌面工作流,尽管构造过程很严谨,但和真实企业系统里权限、认证、第三方 API 限流等因素交织的复杂度相比,依然是被简化过的版本——这一点论文本身也承认,称之为「realistic」而非「real」。

可复现/可落地建议：如果要在自己的测试/评估体系里复用这套方法论，优先复用的不是具体的 108 个任务，而是任务构建 pipeline 里的「规格表 + 可执行判定 + 三层质检」结构，以及十种挑战现象分类作为用例覆盖度检查清单。工程上还应该实测批处理动作在自己场景下是否真的带来成本-性能双重收益，因为这个结论目前基于桌面 GUI 环境下 Claude 系列模型的行为，跨模型跨平台的泛化性还需要验证。

9. 总结

OSWorld 2.0 做的事情看似简单——把任务变长——但背后需要解决的是构造成本、判分可靠性、失败归因这三个真正困难的问题。它把评测重心从「agent 会不会操作 GUI」搬到了「agent 能不能在几百步里保持对约束和状态的追踪」，并且用具体数字证明了这两件事之间存在巨大鸿沟：即使是最强模型，长程任务完成率也只有两成出头。对 GUIAgent 领域而言，这提示接下来的重点不应该继续在几十步任务上卷分数，而应该投入到状态追踪、主动澄清、执行验证这些长程能力上；对 APP 自动化测试而言，它给出的挑战现象分类和任务构建方法论是可以直接借鉴的工程资产。

10. 参考链接

• 论文：OSWorld 2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks，https://arxiv.org/abs/2606.29537
• 前作：OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments，arXiv:2404.07972