计算机使用基准测试：一次跑对需要400小时的十个坑

大多数人只跑一次基准测试就发榜。这份来自实践者的复盘告诉你，为什么那些数字可能根本不值得信任。

一次计算机使用（Computer Use）基准测试跑对一次，大约需要 400 机器小时。这不是夸张——OSWorld 2.1 的 108 个任务，在每次改动评测框架后跑三遍取平均，就是 324 次尝试，而单次干净运行中位数任务耗时 46 分钟，最长的达到 8.9 小时。

原文作者阅读了约 200 个 GitHub issue 和 pull request，来源覆盖 OSWorld、SWE-bench 和 Terminal-Bench 的维护团队，发现同样十个问题反复出现。他结合自己构建 agent 运行时的经验，给出了每个问题的处理方案。

为什么基准测试分数如此不可靠

计算机使用是最难的评测场景。代码基准只需要一个带 shell 的容器，而计算机使用基准需要为每次尝试准备一整个桌面环境——自己的应用、自己的网站——agent 每个任务要执行数百步操作。

在 Yutori 追踪的 OSWorld-Verified 结果中，111 条标注了运行次数的记录里，有 94 条只跑了一次。少数团队会重复：Anthropic 为 Claude Fable 5.1 在 OSWorld 2.0 上跑了五次取平均，Yutori 为自己的 Navigator n2 跑了三次。

问题在于，同一套 benchmark，跑了三次取最好和取平均，结果可以差出 2.6 个百分点。Simular 公布的运行数据显示，按每个任务第一次干净运行算是 0.7674，按最好一次算是 0.7938。这个差距足以改变一个模型在排行榜上的位置。

什么是“计算机使用”基准？ 与代码基准（SWE-bench 只需一个带 shell 的 Docker 容器）不同，计算机使用基准要求 agent 像人一样操作图形桌面：打开应用、点击按钮、在浏览器里填表、跨窗口拖拽文件。代表性工作包括 OSWorld（108 个跨应用任务）、Terminal-Bench（终端操作）和 Yutori 的 Navigator 套件。每个任务通常需要 agent 执行数十到数百步“观察屏幕—决定动作—执行动作”的循环，涉及截图、坐标点击、键盘输入等。这带来了评测上的质变：环境不再是单一可复现的进程，而是一个有状态、有 GUI、有网络依赖的虚拟桌面，任何一步的延迟或崩溃都可能让整条轨迹偏离，因此对隔离、重试和评分的正确性要求远高于纯代码任务。

十个让分数失真的问题

作者把问题整理成一张表，涵盖从资源调度到成本核算的全链路：

问题	对数字的影响	检查什么
1. 容量	最慢的任务拖住整轮	每小时有效结果数
2. 准备	环境搭建时间藏在任务时间里	每个就绪步骤
3. 速率限制	被限流的任务提前结束	每次尝试的调用次数对配额
4. 隔离	尝试之间互相污染结果	同时跑两次尝试
5. 运行时故障	崩溃看起来像 agent 失败	超时和真实健康检查
6. 重试	动作执行两次；最好一次读成平均值	重试发生在什么时候
7. 评分	基础设施错误变成 0 分	是否运行、是否评分、证据是否保留
8. 可复现性	同一个模型，不同的数字	运行清单（manifest）
9. 可观测性	卡住看起来像慢	每次尝试一个 ID
10. 成本	便宜的运行证明不了什么	每个有效结果的成本

容量与准备：被低估的时间黑洞

并行桌面能缩短等待，但改变不了总工作量。400 机器小时就是 400 机器小时，40 个桌面理论上 10 小时跑完，实际永远不会——因为整轮运行要等最慢的任务结束。Simular 报告在 30 个并行环境下，一轮 OSWorld 需要 4 到 5 小时，有时 6 小时，全耗在等最后几个任务上。

40 个默认规格的桌面意味着 160 GB 客户机内存和 160 个虚拟 CPU，还没算宿主机上其他东西。

硬件规格本身就能改变分数。Anthropic 发现，在严格的每任务 CPU 和内存限制下，Terminal-Bench 有高达 6% 的任务因与模型无关的 pod 错误而失败；放宽限制后，分数最多移动了 6 个百分点。

准备阶段同样漫长。环境"就绪"包含四步：镜像已缓存在宿主机、虚拟机已启动、控制通道可用、任务所需文件和网站就位。OSWorld 团队看到 LibreOffice 首次启动要一分钟，因为 AWS 延迟加载快照恢复的磁盘；把镜像从 50 GB 压到 25 GB 后，首次启动降到 5 秒。Epoch 发现 SWE-bench 的任务镜像总计 684 GiB，重建后降到 67 GiB。

解法是预热池：提前启动并检查好若干桌面。作者在自己构建的系统里测到，部署时间从约 60 秒降到不足 1 秒。但预热必须同时意味着干净——桌面只有在经过验证的重置后才能回到池中。

机器小时与并行度的关系：机器小时是任务实际占用 CPU/GPU 时间的总和，代表不可压缩的总工作量。并行桌面只能把墙钟时间除以并行度（理论上 400 机器小时 ÷ 40 桌面 = 10 小时），但有两个约束会打破这个理想值：一是长尾，整轮运行必须等最慢的任务结束，OSWorld 单任务最长 8.9 小时，因此并行度再高也要等它；二是资源争抢，40 个虚拟机同时启动会争抢宿主机的磁盘 IO 和网络，导致单项任务本身变慢。所以真实的墙钟时间是 max(总工作量 / 并行度, 最长单任务时间) 再乘上效率折损系数，这也是为什么预热池、镜像瘦身（如把 50 GB 压到 25 GB）能显著缩短时间——它们直接压缩的是每个任务启动前的固定开销。

重试与评分：两个最容易埋雷的环节

在 agent 第一次动作之前重试是安全的，之后桌面已有状态，重试可能重复已经发生的事。

一个 OSWorld 的 PR 展示了这种问题如何被忽视：桌面会终止运行超过 120 秒的命令并报告错误，控制器对每个错误都重试，包括那些已经部分执行的命令。在那份日志中，23244 个动作里有 357 个执行了两次。当被重复的命令是 ctrl 键按下时，按键在整个任务剩余时间里保持按下状态，而轨迹看起来完全正常。Harbor 的桌面运行时把这个规则写在代码注释里：重放点击不是幂等的。

不同层的重试还会叠加。Harbor 的一个 issue 描述了 SDK 和 harness 的重试堆叠，一次挂起的调用可能耗时约 90 分钟。

评分环节更隐蔽。Simular 在生成 OSWorld 2.1 参考运行时就踩过坑：模型密钥的使用上限让任务在一步后停止，却被记录为成功、得分为 0。整个文件夹的平均分算出 0.40，用他们的话说，"看起来像一个测量结果"。最终是步数暴露了问题。

评分器本身也会制造假零分。OSWorld 维护者有一个未合并的修复，针对 108 个任务中的 14 个——它们的评分器会把对裁判模型的失败调用变成 0 分。

一个团队记录了 240 次 SWE-bench 运行全部为 0%，一直怪罪自己的 agent，直到发现标准答案的 gold patch 也失败了。

幂等性（idempotency）：一个操作执行一次和执行两次结果相同，就是幂等的；否则是非幂等的。读取文件、查询状态是幂等的，而“点击提交按钮”“按下 ctrl 键”“发送一笔支付”都是非幂等的——重复执行会产生额外副作用。Harbor 的运行时把这条规则写进代码注释：“重放点击不是幂等的。”这正是重试的雷区：当框架在超时或错误后自动重试一个已经部分执行的动作，agent 的轨迹可能看起来完美无误，实际桌面状态已经错乱（例如 ctrl 键被按下两次后一直保持按下）。正确做法是只对动作发出前的失败重试，或让每个动作携带唯一 ID、由执行层保证“至多一次”语义，并在日志中标记是否发生重放。

可复现性的真正含义

评测框架本身就能让数字移动。Anthropic 在修复 zoom 工具的 bug 并提高每轮 token 上限后重新运行了旧模型，结果发现此前一直在低报 OSWorld 分数。Claude Opus 4.7 从 78.0% 涨到 82.8%，模型没有任何变化。

环境也在变。OSWorld 2.0 到 2.1 之间，174 个针对任务文件的 pull request 被合并。Simular 让同一个 agent 跑在两个桌面镜像上，一个得 0.7766，另一个得 0.7414。Princeton 的 HAL 团队指出，OpenRouter 可能在同一端点的名字下提供不同量化版本的模型，同一个名字并不保证同一个模型。

所以每次运行都需要一份清单（manifest），记录每一个可能让数字移动的东西：任务和评分器版本、镜像摘要和网站构建、模型和实际提供服务的供应商路由、裁判模型、harness 提交、观察和动作设置、屏幕尺寸、步数和时间预算、每个桌面的资源、重试和重复策略（取平均还是取最好）。

清单不能让模型变得确定，但它能在数字移动时告诉你什么没变。

运行清单（manifest）的作用：机器学习实验里，只靠随机种子远远不够。一个可复现的评测结果依赖于一长串外部状态：模型权重版本与量化精度、实际路由到的推理供应商、裁判模型及其 prompt、评测框架的 git commit、桌面镜像摘要、依赖的网站构建版本、屏幕分辨率、步数与时间预算、每桌面的 CPU/内存配额、重试与重复策略。清单就是把这些全部序列化记录下来，让“同一个模型分数不同”这类问题变成可排查的差异比对，而不是玄学。它不能让结果确定，但能保证当数字移动时，你清楚是哪一个变量动了——这是从“一次运行”走向“可验证证据”的关键一步。

成本与可观测性

Simular 公布了 OSWorld 2.1 参考活动的模型开销：27662 次网关调用共 2417.63 美元，约合每次干净尝试 18 美元。桌面小时数不包含在这个数字里。

遗留资源会迅速累积。OSWorld 的 Docker 供应商曾为每个任务留下一个 32 GB 的卷，一次完整运行不到一小时就能填满磁盘，直到被修复。

在规模上，成本决定方法。HAL 在它的 rollout 上花了约 4 万美元，仍然不得不对大多数评测依赖单次运行。有些模型他们根本没跑。

可观测性则是区分"慢"和"卡住"的关键。一个 Harbor 用户在这种停滞上花了两天：试验静默等待直到 30 分钟超时。原因是两个崩溃的试验，它们 4 GB 的沙箱继续运行，填满了账户 10 GB 的内存上限，于是每个新沙箱都被拒绝并静默重试。

解法是从分配到清理，用一个尝试 ID 贯穿模型调用、桌面动作、评分和清理，记录每个阶段的耗时，保留失败尝试的证据而不是删除它。

什么样的运行方式才算合格

每个修复单独看都很普通。问题在于，每个修复都会暴露下一个问题，所以日常运行必须同时撑住全部十个。这需要八个站点——队列、准入控制、就绪桌面、尝试、看门狗、评分、证据和报告——以及贯穿始终的唯一尝试 ID。

这些站点今天都能找到：并行桌面、预热池、重试和仪表盘存在于 OSWorld 自己的 runner、Harbor、HUD、Cua 和各家沙箱供应商中。但在 benchmark 的确切包上、每天都跑、同时撑住全部环节的完整设置，依然罕见。

作者的建议很直接：一个基准测试分数，是一次操作的输出。在信任它之前——无论是你自己的还是实验室的——先问它是怎么跑的。保存那张表和清单，它们对 SWE-bench 和 Terminal-Bench 同样适用。

对于关注 AI agent 评测的人来说，这篇文章的价值不在于给出一个"正确答案"，而在于揭示了一个行业现实：公开排行榜上的很多数字，可能从未被任何人真正重跑验证过。",