量化 agentic 编码评测中的基础设施噪声

SWE-bench 和 Terminal-Bench 这类 agentic coding benchmark 常被用来比较 frontier model 的软件工程能力——leaderboard 上前几名的差距往往只有几个百分点。这些分数通常被视为相对模型能力的精确度量，并且越来越多地影响要部署哪些模型的决策。然而，我们发现，仅基础设施配置就能带来超过这些差距的差异。在内部实验中，Terminal-Bench 2.0 上资源最多和资源最少的配置之间相差 6 个百分点（p < 0.01）。

静态 benchmark 会直接对模型输出打分——运行时环境不会影响结果。Agentic coding eval 则不同：模型会获得一个完整环境，在其中编写程序、运行测试、安装依赖，并进行多轮迭代。运行时不再是被动容器，而是问题解决过程的组成部分。两个拥有不同资源预算和时间限制的 agent，并不是在参加同一场测试。

Eval 开发者已经开始考虑这一点。例如，Terminal-Bench 2.0 在最新的 2.0 版本中按任务指定了推荐的 CPU 和 RAM。然而，指定资源并不等于一致地执行这些限制。此外，我们发现，执行方法会改变 benchmark 最终实际测量的内容。

我们在 Google Kubernetes Engine cluster 上运行 Terminal-Bench 2.0。在校准配置时，我们注意到分数与 benchmark 官方 leaderboard 不一致，而且 infra error rate 高得出乎意料：多达 6% 的任务因 pod error 失败，其中大多数与模型解决任务的能力无关。

分数差异归因于执行方式。我们的 Kubernetes 实现将每个任务的资源规格同时视为下限和硬上限：每个 container 都保证获得指定资源，但一旦超过这些资源就会被 kill。Container runtime 通过两个独立参数执行资源限制：一个是 guaranteed allocation，即预先保留的资源；另一个是 hard limit，container 达到后会被 kill。当两者设为相同值时，瞬时峰值没有任何余量：一次短暂的内存波动就可能触发 OOM kill，导致本来可以成功的 container 被终止。为了解决这一点，Terminal-Bench 的 leaderboard 使用了不同的 sandboxing provider，其实现更宽松，允许临时超额分配而不终止 container，以优先保证基础设施稳定性。

这一发现引出了一个更大的问题：资源配置对 evaluation score 的影响有多大？

为了量化 scaffold 的影响，我们在六种资源配置下运行 Terminal-Bench 2.0，从严格执行每任务规格（1x），即同时作为下限和上限，到完全不设上限。其他一切保持不变：同一个 Claude model、同一个 harness、同一组 task。

在我们的实验中，success rate 随资源余量增加而提高。这主要由 infra error rate 在每一步单调下降驱动：从严格执行时的 5.8% 降到不设上限时的 0.5%。从严格执行到 3x 余量的下降（5.8% 到 2.1%）在 p < 0.001 下显著。余量越多，因超过分配而被 kill 的 container 越少。

从 1x 到 3x，success score 在噪声范围内波动（p=0.40）。大多数在 1x 崩溃的任务无论如何都会失败——这是我们在数据中观察到的情况。Agent 进行探索，撞上资源墙，然后被抢占，但它原本就没有走在通向正确解的路径上。

然而，大约从 3x 开始，这一趋势发生变化：success rate 的上升速度超过 infra error 的下降速度。

从 3x 到不设上限，infra error 又下降了 1.6 个百分点，而 success 几乎上升了 4 个百分点。额外资源让 agent 能够尝试只有在资源充裕时才可行的方法，例如拉取大型依赖、启动开销较大的 subprocess，以及运行内存密集型 test suite。在不设上限的资源下，相比 1x 的总提升为 +6 个百分点（p < 0.01）。在边际处，rstan-to-pystan 和 compile-compcert 等任务在获得内存余量时，success rate 显著提升。

在大约 3x Terminal-Bench 规格以内，额外资源修复的是基础设施可靠性问题，即瞬时资源峰值。Terminal-Bench 维护者使用的 sandboxing provider 在幕后隐式地做了这件事；eval 变得更稳定，但并没有变得更容易。

然而，超过 3x 后，额外资源开始主动帮助 agent 解决以前无法解决的问题，这说明限制实际上会改变 eval 测量的内容。严格限制会无意中奖励非常高效的策略，而宽松限制更具容错性，并奖励更善于利用所有可用资源的 agent。

一个能快速编写精简、高效代码的 agent，会在严格约束下表现良好。一个使用重量级工具 brute-force 解决方案的 agent，则会在宽松约束下表现良好。两者都是合理的测试对象，但如果不说明资源配置就将它们压缩成一个单一分数，就会让差异以及现实世界中的泛化性变得难以解释。

在 bn-fit-modify 这个需要进行 Bayesian network fitting 的 Terminal-Bench 任务中，一些模型的第一步是安装标准 Python data science stack：pandas、networkx、scikit-learn，以及它们的全部 toolchain。在宽松限制下，这可行。在严格限制下，pod 在安装过程中耗尽内存，甚至还没等 agent 写下一行解决方案代码。存在一种更精简的策略（只使用 standard library 从头实现数学部分），一些模型确实默认采用它。另一些则不会。不同模型有不同的默认方法，而资源配置决定了哪些方法恰好能成功。我们在不同 Anthropic model 上复现了这一核心发现。影响方向一致，但幅度有所不同。同样的趋势似乎也适用于 Claude 以外的模型，但我们尚未对它们进行严格测试。

我们还通过在 SWE-bench 上进行 crossover experiment，测试了这一模式是否也存在于 Terminal-Bench 之外的 eval。我们在 227 个问题上将总可用 RAM 最高调整到 baseline 的 5x，每个问题 10 个 sample。同样的影响依然存在，但幅度更小：分数同样随 RAM 单调上升，但 5x 仅比 1x 高 1.54 个百分点。SWE-bench 任务的资源密集程度较低，因此预期影响更小，但这表明资源分配在那里也不是中性的。

资源分配并不是唯一的隐藏变量。在某些配置下，时间限制也开始发挥作用。

原则上，evaluation setup 的每个元素都可能影响最终分数，从 cluster health 到 hardware specs，从 concurrency level 甚至到 egress bandwidth。Agentic eval 本质上是端到端系统测试，该系统的任何组件都可能成为 confounder。例如，我们曾以轶事方式观察到 pass rate 会随一天中的时间而波动，可能是因为 API latency 随流量模式和 incident 变化。我们没有正式量化这一影响，但它说明了一个更大的问题：“模型能力”和“基础设施行为”之间的边界，并不像单一 benchmark score 所暗示的那样清晰。模型提供商可以通过专用硬件来隔离其 eval infrastructure，但外部评估者很难做到同样的事情。

Public benchmark 通常旨在测量纯粹的模型能力，但实践中它们可能会把模型能力与基础设施细节混在一起。有时这可能是可取的，因为它支持对整个 stack 进行端到端测试，但更多时候并非如此。对于打算公开共享的 coding eval，在多个时间和多天运行有助于平均掉噪声。

理想情况是在完全相同的硬件条件下运行每个 eval——包括运行 eval 的 scaffold 和 inference stack——因为这将确保全面的完美可复现性。然而，这并不总是现实可行。

鉴于 container runtime 实际执行资源限制的方式——通过 guaranteed allocation 和一个单独的 hard kill threshold——我们建议 eval 为每个任务指定这两个参数，而不是单个固定值。单个精确规格会把 guaranteed allocation 设为等于 kill threshold，留下零余量：我们在 1x 下记录到的瞬时内存峰值足以使 eval 不稳定。将两个参数分开，可以让 container 有足够的喘息空间，避免虚假的 OOM kill，同时仍然执行硬上限，防止分数膨胀。

两者之间的区间应经过校准，使下限和上限处的分数彼此落在噪声范围内。例如，在 Terminal-Bench 2.0 中，将每任务规格的上限设为 3x，使 infra error rate 大约降低了三分之二（5.8% 到 2.1%，p < 0.001），同时分数提升保持较小且完全处于噪声范围内（p = 0.40）。这是一个合理折中：基础设施 confounder 在很大程度上被中和，同时没有移除有意义的资源压力。确切的 multiplier 会随 benchmark 和 task distribution 而变化，因此应当报告，但经验校准原则是通用的。

这些发现对 eval infrastructure 之外也有实际影响。Benchmark score 越来越多地被用作决策输入，但这种关注度（和依赖度）的提升，并不总是伴随着运行和报告方式上相应的严谨性。就目前而言，leaderboard 上 2 分的领先可能反映了真实的能力差异，也可能反映了某次 eval 运行在更强的硬件上，甚至运行在一天中更幸运的时间，或两者兼有。如果没有公开（或标准化）的 setup configuration，外部很难判断，除非相关方额外投入精力，在相同条件下复现客观结果。

对于 Anthropic 这样的 lab，含义是 agentic eval 的资源配置应被视为一等 experimental variable，并像 prompt format 或 sampling temperature 一样被记录和控制。对于 benchmark 维护者，发布推荐资源规格（如 Terminal-Bench 2.0 所做）能带来很大帮助，而指定执行方法将弥合我们识别出的差距。对于任何使用 benchmark result 的人，核心结论是：agentic eval 上的小分数差异所包含的不确定性，比报告数字呈现的精度更高——尤其是某些 confounder 本来就很难控制。

在资源方法标准化之前，我们的数据表明，leaderboard 上低于 3 个百分点的差异都应保持怀疑，直到 eval configuration 被记录并匹配。在 Terminal-Bench 的中等资源配置范围内观察到的差距略低于 2 个百分点。朴素的 binomial confidence interval 已经覆盖 1-2 个百分点；我们在这里记录的基础设施 confounder 是叠加在其上的，而不是包含在其中。在资源分配范围的两个极端，差距达到 6。

几个百分点的领先可能表示真实的能力差距——也可能只是一个更大的 VM。

作者：Gian Segato。特别感谢 Nicholas Carlini、Jeremy Hadfield、Mike Merrill 和 Alex Shaw 的贡献。这项工作反映了多个从事 coding agent evaluations 的团队的共同努力。有兴趣贡献的候选人欢迎在 anthropic.com/careers 申请。