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

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

Anthropic Engineering

2026 年 2 月 5 日。

像 SWE-bench 和 Terminal-Bench 这样的智能体编码基准，常被用来比较前沿模型的软件工程能力——排行榜上的前列位置，往往只相差几个百分点。这些分数经常被当成对相对模型能力的精确测量，并且越来越多地影响该部署哪个模型的决定。然而，我们发现，仅仅是基础设施配置，就能产生超过这些差距的差异。在内部实验里，Terminal-Bench 2.0 上资源最充足与最不足的设置之间，差距为 6 个百分点（p < 0.01）。

静态基准直接给模型的输出打分——运行环境不进入结果。智能体编码评测不同：模型得到一个完整环境，在里面写程序、跑测试、安装依赖，并跨多个回合迭代。运行时不再是一个被动容器，而是解题过程的组成部分。两个资源预算和时间限制不同的智能体，并不是在做同一场测试。

评测的开发者已经开始把这一点算进去。例如 Terminal-Bench 2.0 在其最新的 2.0 发布里，按任务指定了建议的 CPU 和内存。然而，指定资源并不等于一致地强制执行。此外，我们发现，强制执行的方法会改变基准最终实际在测量什么。

我们是如何走到这里的

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

分数上的出入，归结为强制执行的方式。我们的 Kubernetes 实现把每任务的资源规格既当作下限，也当作硬上限：每个容器被保证得到所指定的资源，但一旦超出就被杀掉。容器运行时通过两个分开的参数来强制资源：一个是保证分配——预先保留的资源；一个是硬限制，到达该限制时容器会被杀掉。当这两者被设成同一个值时，瞬时尖峰没有任何余量：一次短暂的内存波动，就能把一个本来会成功的容器 OOM 杀掉。为了处理这一点，Terminal-Bench 的排行榜使用另一家沙箱提供方，其实现更宽松，允许临时超额分配而不终止容器，以便偏向基础设施的稳定。

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

为了量化脚手架的效应，我们在六种资源配置上运行 Terminal-Bench 2.0，从对每任务规格的严格强制执行（1 倍，让它们同时充当下限和上限），一直到完全不设上限。其他一切保持不变：同一个 Claude 模型，同一套 harness，同一组任务。

在我们的实验里，成功率随资源余量增加。这主要是由基础设施错误率在每一步单调下降所推动的，从严格强制执行时的 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 这样的任务，在获得内存余量后成功率显著提高。

这如何影响测量

直到大约 3 倍的 Terminal-Bench 规格，额外资源修复的是基础设施可靠性问题，也就是瞬时的资源尖峰。Terminal-Bench 维护者所使用的沙箱提供方，是在幕后隐含地做这件事；评测变得更稳定，而没有变得更容易。

然而过了 3 倍这个刻度，额外资源开始主动帮助智能体解决它以前解决不了的问题。这表明，限制实际上会改变评测在测量什么。紧的限制会无意中奖励非常高效的策略，而慷慨的限制更宽容，奖励那些更能用尽全部可用资源的智能体。

一个写得精简、高效、而且很快的智能体，会在紧约束下表现好。一个用沉重工具蛮力求解的智能体，会在慷慨约束下表现好。两者都是正当的测试对象，但若不指明资源配置就把它们塌缩成一个分数，差异——以及真实世界的可推广性——就很难解释。

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

我们也测试了这一模式在 Terminal-Bench 之外的评测上是否成立，方法是在 SWE-bench 上做一次交叉实验。我们把总可用内存变到基线的最多 5 倍，覆盖 227 道题，每题 10 个样本。同样的效应成立，不过幅度更小：分数再次随内存单调上升，但在 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（http://anthropic.com/careers）申请。