“比人做得更好”的分数，也适用于我们的业务吗？
评估计算机操作型 AI 智能体时，一页幻灯片就可能催促你做决定：OSWorld-Verified 85%，人类基线约为 72%。这样的数字很容易让人觉得，可以把门户录入或工单处理交给它。
但是，如果分数旁边没有基准测试版本、任务长度、智能体配置和允许步数，它还不能被解读为贵公司业务的成功率。实际上，公开的 85% 与 OSWorld 2.0 的 20.6%，从模型到任务和评分方法都不是同一种结果。二者之间的差异并不证明 AI 能力突然下滑，而是一个信号：应先确认在什么条件下、将什么视为完成。
85% 并不是“经过验证的官方分数”
a16z 在 2026 年 8 月 10 日的文章中介绍了截至 2026 年 6 月，第三方 OSWorld-Verified 排行榜上 Claude Fable 5 的 85% 分数，并称其超过了约 72% 的人类基线。 不过，所核对的排行榜显示 Fable 5 为 85.0%、Claude Opus 4.8 为 83.4%，同时还写明，已提交的 24 项结果全部为self-reported，独立 verified 的结果为 0 项。
这里的“Verified”是基准测试名称的一部分，并不保证表格中的每次运行都经过了独立验证。公开页面也无法确认 Fable 5 的原始运行报告、逐任务结果、测试框架、步数预算和重试条件。因此，将 85% 视为a16z 当时引用的第三方排行榜快照更为准确。
人类 72% 这一数字也需要区分来源。2024 年最初的 OSWorld 论文报告称，在 369 项任务中，人类成功率为 72.36%，当时最佳模型成功率为 12.24%。 公开资料无法确认，这项人类评估是否在之后 OSWorld-Verified 完全相同的任务集合和协议下重新计算。
20.6% 问的是：更长的工作是否“完全完成”
OSWorld 2.0 并不是仅改了名字的同一项测试。它由 108 项长程任务组成，反映了研究、内容制作、软件开发、商业和金融等实际工作。熟练人员完成任务的时间中位数约为 1.6 小时，其中 69.6% 超过 1 小时。每项任务平均有 27.25 个评分检查点。
在该测试中，Claude Opus 4.8 在 500 步、maximum thinking 和 batched tool calls 条件下，取得了20.6% 的二元完成率和54.8% 的部分得分。 这体现了其中的差别：即使完成了一半以上的进度，如果未能按要求完成最终交付物，也不会计入完全完成。
在较长的工作中，执行负担也不同。官方资料称，Claude Opus 4.7 在 maximum thinking 下运行时，平均工具调用约 318 次，而 OSWorld 1.0 约为 30 次。 这不是所有模型的平均值，而是特定配置的结果，但它清楚说明了为何短暂的应用操作与串联多个步骤的工作难以用同一个数字比较。
| 公开数值 | 已确认的条件 | 不能据此直接说明的内容 |
|---|---|---|
| 85% | 第三方 OSWorld-Verified 排行榜上 Claude Fable 5 的自报分数 | 经过独立验证且可复现的结果；贵公司长程业务的完成率 |
| 20.6% | Claude Opus 4.8 在 OSWorld 2.0 中、500 步条件下的二元完成率 | Fable 5 在相同条件下下降了 64.4 个百分点这一结论 |
| 54.8% | 同一次 OSWorld 2.0 运行的部分得分 | 54.8% 的业务可立即在实务中使用 |
分数不是模型名称，而是一组“评估条件”
要比较基准测试结果，至少需要同时具备基准测试系列、发布版本、任务集合、模型、智能体测试框架、步数预算、重试、人工干预和评分指标。其中任何一项不同，数字回答的都可能是不同的问题。
发布版本也不能遗漏。OSWorld 2.0 的官方仓库目前推荐 osworld-v2-2026.08.08，并说明应匹配代码、任务、资产和网站版本。该版本修订了 14 项任务，并改善了 31 项任务的评估稳健性与公平性。 公开资料无法确认论文中的 20.6% 是否能在这个修订版本中原样复现，因此不应把不同发布版本的分数放在同一张表中排名。
无法用一行写清的分数，还不是采购依据。
不要只写“OSWorld 85%”，而应写成“OSWorld-Verified，发布版本未确认，Claude Fable 5，第三方排行榜自报，测试框架、步数和重试未公开”。空白之处就是要向供应商提出的问题。
今天就把供应商分数与实际业务逐行对照
不需要先建立一套新的评估系统。打开供应商提供的原始链接，以及一项自动化候选业务的实际记录，按以下顺序比较即可。
- 为分数制作一张身份卡。
用一行写下基准测试名称和发布版本、任务集合、模型、测试框架、二元分数与部分得分的区分、步数预算、重试及是否有人工干预。对未公开的项目不要猜测，保留为“未确认”。 - 单独标记验证状态。
区分官方评估、独立复现和供应商自报。不要仅因为基准测试名称中含有“Verified”，就将单项结果标注为已验证。 - 记录实际业务的长度和分支。
例如，对于保险门户理赔，记录所用应用数量、与外部资料的核对、中间保存、发生例外时的提问以及提交后的确认。还要确定，完成是指出现受理页面，还是在没有后续补正的情况下处理完成。 - 区分完全完成和部分进展。
在试点表格中，为“最终完成”“部分完成”“重试次数”“人工干预”和“执行后发现的失败”设置单独列。即使部分得分很高，如果后续工作仍需要人工重做，也不要计为自动化完成。 - 将条件差异大的分数降为参考值。
如果没有发布版本或测试框架，且执行轨迹也未公开，就只能将其作为筛选候选方案的信息，而不是性能保证。实际采购判断应基于采用相同业务记录和成功标准进行的试点。
供应商主张：OSWorld-Verified 85%
来源与验证状态：第三方排行榜 / self-reported
基准测试发布版本、测试框架、步数、重试：未确认
我们的业务：保险门户理赔提交
完成标准：不是出现受理页面，而是无需后续补正即处理完成
升级处理：保单号不一致或请求额外确认时，转交给负责人
完成这份记录后的成功标准，并不是相信或反驳某个特定分数。只要能够用可复现的条件说明供应商分数，标明这些条件与自家业务的差异，并分别统计试点的完全完成率与人工干预，就足够了。
a16z 通过供应商访谈介绍的应用案例，也集中在范围和完成条件相对明确的工作，例如更新系统记录、在门户之间移动数据和处理工单。原文同样将验证、权限、错误处理和升级处理列为重要的运营层。 不过，所介绍的供应商案例并未公开总尝试次数、失败率和独立验证资料，因此不应将其扩大为普遍的 ROI 依据。
如果想进一步深入了解
OSWorld 2.0: Benchmarking computer-use agents on long-horizon real-world tasks 这是可了解长程任务构成，以及二元完成率与部分得分差异的官方项目。 osworld-v2.xlang.ai
OSWorld-V2 README 适合了解当前推荐的发布版本，以及为何需要同时固定代码、任务和资产版本。 github.com
OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments 可追溯 2024 年原始 OSWorld 的任务数量和人类、模型基线数字的来源。 arxiv.org
