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

诸如 SWE-bench 和 Terminal-Bench 这样的智能体编程基准测试，常被用来比较前沿模型的软件工程能力——排行榜上领先位置之间的差距往往只有几个百分点。这些分数经常被当作衡量模型相对能力的精确指标，并越来越多地影响着模型部署决策。然而，我们发现仅基础设施配置的差异，就可能超出这些差距的幅度。在内部实验中，资源最充足与最匮乏的配置在 Terminal-Bench 2.0 上的差距为 6 个百分点（p < 0.01）。

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

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

我们是如何走到这一步的

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

分数的差异归根结底在于执行方式。我们的 Kubernetes 实现把按任务的资源配置既当作下限又当作硬性上限：每个容器都被保证获得指定的资源，但一旦超出就立即被杀掉。容器运行时通过两个独立的参数来执行资源限制：保证分配——预先保留的资源——以及硬性上限，达到该上限时容器会被杀掉。当两者被设置为相同的值时，瞬时峰值就没有任何余地：一次短暂的内存波动就可能导致一个本可以成功的容器被 OOM 杀掉。为此，Terminal-Bench 的排行榜使用了一个不同的沙箱提供商，其实现更为宽松，允许临时超配而不终止容器，以优先保障基础设施的稳定性。

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

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

在我们的实验中，成功率随着资源余量的增加而提高。这主要由基础设施错误率在每一步中单调下降所驱动：从严格执行时的 5.8% 降到不设上限时的 0.5%。从严格执行到 3 倍余量之间的下降（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 这样的任务在获得内存余量后成功率显著提高。

这对测量有何影响

在大约 3 倍 Terminal-Bench 规格以内，额外的资源只是修复了基础设施的可靠性问题，即瞬时的资源尖峰。Terminal-Bench 维护者所使用的沙箱提供商实际上在幕后就在做这件事；评测变得更稳定，但并没有变得更简单。

然而，超过 3x 标记后，额外的资源开始实实在在地帮助智能体解决以前无法解决的问题，这说明限制实际上会改变评测所测量的内容。严格的限制会无意中奖励非常高效的策略，而充裕的限制则更宽容，奖励能够更好利用所有可用资源的智能体。

一个能非常快速地写出精炼高效代码的智能体在严格约束下会表现出色。一个用重量级工具暴力求解的智能体在充裕的资源下会表现出色。两者都是值得测试的合理能力，但把它们合并成一个分数而不指明资源配置，会让人难以解读这些差异——以及真实世界中的可推广性。

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

我们还通过在 SWE-bench 上进行交叉实验，测试了这种模式在 Terminal-Bench 之外的评测中是否成立。我们在 227 个问题上将总可用内存上限提高到基线的 5 倍，每个问题采样 10 次。同样的效应依然存在，只是幅度更小：分数再次随内存单调上升，但在 5x 时仅比 1x 高 1.54 个百分点。SWE-bench 任务对资源的需求较低，因此效应较小是预期之中的，但这表明资源分配在那里同样不是中性因素。

其他差异来源

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

原则上，评估设置的每一个元素都可能影响最终得分，从集群健康状况到硬件规格，从并发级别到甚至出口带宽。Agent 式评估从构造上讲就是端到端的系统测试，该系统的任何组件都可能成为混淆因素。例如，我们曾偶然观察到通过率会随一天中的时间而波动，原因很可能是 API 延迟随流量模式和事故而变化。我们尚未正式量化这一影响，但它说明了一个更大的问题：“模型能力”与“基础设施行为”之间的边界，比单一基准得分所显示的要模糊得多。模型提供方可以通过专用硬件将评估基础设施与此隔离，但外部评估者却难以做到。

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

我们的建议

理想情况是在完全相同的硬件条件下运行每次评估——包括运行评估的脚手架和推理栈——这样能确保整体的完美可复现性。然而，这并不总是可行的。

鉴于容器运行时实际上是以“保证配额加单独的硬性终止阈值”的方式来执行资源限制的，我们建议评估为每个任务同时指定这两个参数，而不是单一固定值。单一的精确规格会把保证配额设为等于终止阈值，留下零余量：我们在 1x 下记录到的瞬时内存峰值就足以让评估不稳定。将这两个参数分开，既能让容器有足够的喘息空间以避免虚假的 OOM kill，同时仍能强制执行防止得分膨胀的硬性上限。

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

我们为什么关心

这些发现的影响超出了评估基础设施的范围，具有实际意义。基准得分越来越多地被用作决策输入，但这种关注（和依赖）的增加并不总是伴随着运行或报告方式上相应的严谨性。就目前的情况而言，排行榜上 2 分的领先可能反映的是真实的能力差异，也可能反映的是一次评估运行在更强悍的硬件上，甚至是碰上了运气更好的时段，或两者兼有。在没有公开（或标准化）配置的情况下，外部很难分辨，除非相关方愿意付出额外努力，在相同条件下复现客观结果。

对于像 Anthropic 这样的实验室来说，这意味着智能体评测（agentic evals）的资源配置应当被视为一等实验变量，并以与提示词格式或采样温度同等的严谨程度进行记录和控制。对于基准测试的维护者来说，发布推荐的资源配置规格（正如 Terminal-Bench 2.0 所做的那样）大有裨益，而进一步明确执行方法则能弥补我们所发现的差距。对于任何使用基准测试结果的人来说，核心结论是：智能体评测中微小的分数差异所蕴含的不确定性，比报告中数字的精度所暗示的更大——尤其是一些混淆因素根本难以控制。

在资源配置方法标准化之前，我们的数据表明，在评测配置得到记录和比对之前，排行榜上低于 3 个百分点的差异值得怀疑。在中等范围的资源配置下，Terminal-Bench 上观察到的分数差异略低于 2 个百分点。朴素的二项式置信区间本身已覆盖 1-2 个百分点；而我们在此记录的基础设施混淆因素是叠加在其之上，而非包含在其中。在资源配置区间的两端，差异可达 6 个百分点。

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

致谢

本文由 Gian Segato 撰写。特别感谢 Nicholas Carlini、Jeremy Hadfield、Mike Merrill 和 Alex Shaw 的贡献。这项工作体现了多个致力于编程智能体评测的团队的集体努力。有兴趣贡献力量的候选人欢迎在 anthropic.com/careers 申请职位。