Anthropic 量化智能体编码评测中的基础设施噪声

SWE-bench 和 Terminal-Bench 等智能体编程基准常被用来比较前沿模型的软件工程能力——排行榜上的头名往往只相差几个百分点。这些分数常被视为模型相对能力的精确度量，并越来越多地影响关于部署哪些模型的决策。然而，我们发现，仅基础设施配置一项就能产生超过这些差距的差异。在内部实验中，Terminal-Bench 2.0 上资源最充足与最匮乏的配置之间的差距为 6 个百分点（p < 0.01）。

静态基准直接对模型的输出打分——运行时环境不参与结果。智能体编程评测则不同：模型会获得一个完整环境，在其中编写程序、运行测试、安装依赖，并进行多轮迭代。运行时不再是被动的容器，而是问题求解过程中不可或缺的组成部分。资源预算和时间限制不同的两个智能体，参加的并不是同一场测试。

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

我们是如何走到这一步的

我们在 Google Kubernetes Engine 集群上运行 Terminal-Bench 2.0。在校准环境时，我们注意到分数与基准官方排行榜不符，且基础设施错误率高得惊人：多达 6% 的任务因 pod 错误而失败，其中大多数与模型解决任务的能力无关。

分数差异归结于强制执行方式。我们的 Kubernetes 实现将按任务的资源规格同时视为下限和硬上限：每个容器获得所指定资源的保证，但一旦超出就会被杀死。容器运行时通过两个独立参数来强制执行资源限制：保证分配——预先预留的资源——以及容器被杀死时的硬限制。当二者设为相同值时，瞬时峰值没有任何余量：一次短暂的内存波动就可能 OOM 杀死一个原本会成功的容器。为此，Terminal-Bench 排行榜使用了另一家沙箱提供商，其实现更为宽松，允许临时超额分配而不终止容器，以优先保证基础设施稳定性。

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

为了量化脚手架的影响，我们在六种资源配置下运行 Terminal-Bench 2.0，从严格强制执行按任务规格（1x）——使其同时作为下限和上限——到完全不设上限。其他一切保持不变：相同的 Claude 模型、相同的 harness、相同的任务集。

在我们的实验中，成功率随资源余量增加而上升。这主要是由基础设施错误率在每一步单调下降所驱动的，从严格强制执行时的 5.8% 降至不设上限时的 0.5%。从严格强制执行到 3x 余量之间的下降（5.8% 到 2.1%）在 p < 0.001 水平上显著。余量越多，因超出分配而被杀死的容器就越少。

从 1x 到 3x，成功分数在噪声范围内波动（p=0.40）。大多数在 1x 下崩溃的任务无论如何都会失败——这是我们在数据中观察到的现象。智能体进行探索，撞上资源墙，被抢占，但它从未走在通往正确解决方案的路径上。

然而，从 3x 左右开始，这一趋势发生了变化：成功率的攀升速度快于基础设施错误的下降速度。

在 3x 到不设上限之间，基础设施错误又下降了 1.6 个百分点，而成功率跃升了近 4 个百分点。额外的资源使智能体能够尝试那些只有在充裕分配下才奏效的方法，例如拉取大型依赖、启动昂贵的子进程，以及运行内存密集型的测试套件。在不设上限的资源下，相对于 1x 的总提升为 +6 个百分点（p < 0.01）。在边际上，像 rstan-to-pystan 和 compile-compcert 这样的任务在获得内存余量时，成功率显著提高。

这如何影响测量

在 Terminal-Bench 规格大约 3x 以内，额外资源解决的是基础设施可靠性问题，即瞬态资源峰值。Terminal-Bench 维护者所使用的沙箱提供商在幕后隐式地做到了这一点；评估变得更稳定，但并没有变得更简单。

然而，超过 3x 标记后，额外资源开始主动帮助智能体解决它此前无法解决的问题，这表明限制实际上可以改变评估所测量的内容。严格的限制无意中奖励了非常高效的策略，而宽松的限制则更为宽容，奖励那些能更好地利用所有可用资源的智能体。

一个能快速编写精简、高效代码的智能体在严格约束下会表现出色。一个用重量级工具暴力求解的智能体在宽松约束下会表现出色。两者都是值得测试的合理内容，但如果不指定资源配置就将它们合并为单一分数，会使差异——以及现实世界的可泛化性——难以解读。

在 bn-fit-modify 上，这是一个要求拟合贝叶斯网络的 Terminal-Bench 任务，一些模型的第一步是安装标准的 Python 数据科学栈：pandas、networkx、scikit-learn, 及其整个工具链。在宽松的限制下，这行得通。在严格的限制下，pod 在安装期间就耗尽了内存，此时智能体还没写下一行解决方案代码。存在一种更精简的策略（仅使用标准库从头实现数学计算），一些模型确实默认采用它。其他模型则没有。不同模型有不同的默认方法，而资源配置决定了这些方法中哪些恰好能够成功。我们在不同的 Anthropic 模型上复现了核心发现。效应的方向是一致的，而幅度有所变化。同样的趋势似乎在 Claude 以外的模型上也成立，但我们尚未严格测试它们。

我们还通过在 SWE-bench 上运行交叉实验，测试了这种模式是否在 Terminal-Bench 之外的评估中成立。我们在 227 个问题上各取 10 个样本，将可用总 RAM 变化至基线的 5 倍。同样的效应成立，尽管幅度较小：分数再次随 RAM 单调增加，但在 5x 时仅比 1x 高 1.54 个百分点。SWE-bench 任务资源密集度较低，因此预期效应较小，但这表明那里的资源分配也并非中性。

其他方差来源

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

原则上，评估设置的每一个要素都可能影响最终得分，从集群健康状态到硬件规格，从并发级别到甚至出口带宽。智能体评估在构造上就是端到端的系统测试，而该系统的任何组件都可能成为混杂因素。例如，我们曾观察到通过率会随一天中的时间波动，这很可能是因为 API 延迟会随流量模式和故障事件而变化。我们尚未正式量化这一效应，但它说明了一个更大的问题：“模型能力”与“基础设施行为”之间的界限比单一基准分数所暗示的更为模糊。模型提供商可以通过专用硬件来使其评估基础设施免受此影响，但外部评估者很难轻易做到同样的事。

公开基准通常旨在衡量纯粹的模型能力，但在实践中，它们有将模型能力与基础设施的怪癖混为一谈的风险。有时这可能是可取的，因为它能对整个技术栈进行端到端测试，但更多时候并非如此。对于旨在公开分享的编码评估，在多个时间、多个日期运行有助于将噪声平均掉。

我们的建议

理想场景是在完全相同的硬件条件下运行每个评估——包括运行评估的脚手架和推理栈——因为这将确保全面的完美可复现性。然而，这并不总是切实可行。

鉴于容器运行时实际执行资源限制的方式——通过保证分配和单独的硬性终止阈值——我们建议评估为每个任务同时指定这两个参数，而不是一个单一的固定值。单一精确规格会使保证分配等于终止阈值，留下零余量：我们记录的 1 倍下的瞬时内存峰值就足以使评估失稳。将这两个参数分开，可以让容器有足够的喘息空间来避免虚假的 OOM 终止，同时仍执行硬性上限以防止分数虚高。

两者之间的区间应经过校准，使下限和上限处的分数落在彼此的噪声范围内。例如，在 Terminal-Bench 2.0 中，相对于每任务规格的 3 倍上限将基础设施错误率降低了约三分之二（5.8% 降至 2.1%，p < 0.001），同时将分数提升保持在适度且完全在噪声范围内的水平（p = 0.40）。这是一个合理的权衡：基础设施混杂因素在很大程度上被中和，同时没有消除有意义的资源压力。确切的倍数会因基准和任务分布而异，因此应予以报告，但经验校准原则是通用的。

我们为何关注

这些发现具有超越评估基础设施的实际后果。基准分数越来越多地被用作决策输入，但这种日益增加的关注（和依赖）并不总是伴随着在运行或报告方式上的相应严谨性。就目前情况而言，排行榜上 2 分的领先可能反映了真实的能力差异，也可能反映了一个评估运行在更强大的硬件上，甚至是在一天中更幸运的时间运行，或者两者兼有。如果没有公开（或标准化）的设置配置，除非相关方付出额外努力在相同条件下复现客观结果，否则很难从外部判断。

对于像 Anthropic 这样的实验室而言，这意味着智能体评测的资源配应被视为一等实验变量，像提示格式或采样温度一样严格记录和控制。对于基准维护者来说，发布推荐资源规格（如 Terminal-Bench 2.0 所做的那样）大有裨益，而明确执行方法则能弥合我们发现的差距。对于任何使用基准结果的人来说，核心要点是：智能体评测上的微小分数差异所承载的不确定性，比所报告数字的精度所暗示的更大——尤其因为某些混杂因素实在难以控制。

在资源方法论标准化之前，我们的数据表明，在评测配置被记录并匹配之前，排行榜上低于 3 个百分点的差异值得怀疑。在 Terminal-Bench 中，中等资源配范围内观察到的差距略低于 2 个百分点。朴素二项置信区间已经跨越 1-2 个百分点；我们在此记录的基建设施混杂因素叠加在其之上，而非包含其中。在分配范围的极端处，差距达到 6。

几个百分点的领先可能意味着真实的能力差距——也可能只是更大的虚拟机。