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

像 SWE-bench 和 Terminal-Bench 这样的智能体编码基准测试（agentic coding benchmarks）常被用来比较前沿模型的软件工程能力——排行榜上的顶尖位置往往只差几个百分点。这些分数通常被视为模型相对能力的精确度量，并越来越多地用于决定部署哪些模型。然而，我们发现仅凭基础设施配置的差异就能产生超过这些差距的变化。在内部实验中，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 的排行榜使用了不同的沙箱提供商，其实现更为宽松，允许临时超量分配而不终止容器，以利于基础设施的稳定性。

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

为了量化这种支撑结构（scaffold）的影响，我们在六种资源配置下运行了 Terminal-Bench 2.0，范围从严格强制执行每个任务的规格（1x，即同时作为下限和上限）到完全不设上限。其他所有条件保持不变：相同的 Claude 模型、相同的测试框架、相同的任务集。

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

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

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

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

大约在 Terminal-Bench 规格的 3 倍以内，额外的资源主要解决了基础设施可靠性问题，即瞬时资源峰值。Terminal-Bench 维护者使用的沙箱提供商在幕后隐式地做了这件事；评估变得更加稳定，而并没有变得更容易。

然而，在 3 倍以上，额外的资源开始积极帮助智能体解决它以前无法解决的问题，这表明限制实际上可以改变评估衡量的内容。严格的限制无意中奖励了非常高效的策略，而宽松的限制则更具包容性，奖励那些能更好利用所有可用资源的智能体。

一个能快速编写简洁、高效代码的智能体在严格限制下会表现良好。一个使用重量级工具强行求解的智能体在宽松限制下会表现良好。两者都是值得测试的，但如果不指定资源配置就将它们合并为一个分数，那么这些差异——以及在实际世界中的泛化能力——就很难解释。

在 bn-fit-modify 这个需要贝叶斯网络拟合的 Terminal-Bench 任务中，一些模型的第一步是安装标准的 Python 数据科学栈：pandas、networkx、scikit-learn 以及它们所有的工具链。在宽松限制下，这可以工作。在严格限制下，pod 在安装过程中就会耗尽内存，而智能体甚至还没来得及写一行解决方案代码。存在更精简的策略（仅使用标准库从头实现数学计算），并且一些模型确实默认采用这种策略。其他模型则不然。不同的模型有不同的默认方法，而资源配置决定了这些方法中哪些能够成功。

我们在不同的 Anthropic 模型上复现了这一核心发现。效果的方向是一致的，但幅度有所不同。同样的趋势似乎在 Claude 之外的模型上也成立，但我们没有进行严格的测试。

我们还通过在 SWE-bench 上进行交叉实验，测试了这种模式是否在 Terminal-Bench 之外的评估中也成立。我们在 227 个问题上（每个问题 10 个样本）将总可用 RAM 变化到基线水平的 5 倍。同样的效果依然存在，尽管幅度较小：分数再次随 RAM 增加而单调递增，但在 5 倍时仅比 1 倍时高 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 个百分点。

几分的领先可能标志着真实的能力差距——也可能仅仅是一个更大的虚拟机。

作者：Gian Segato。特别感谢 Nicholas Carlini、Jeremy Hadfield、Mike Merrill 和 Alex Shaw 的贡献。这项工作反映了多个团队为编码智能体开发评估的集体努力。有兴趣贡献的候选人欢迎在 anthropic.com/careers 申请。