内容来源：Anthropic Engineering 官方技术博客。

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

基础设施配置可能让智能体式编码基准波动几个百分点，有时甚至超过顶尖模型之间的排行榜差距。

来源：https://www.anthropic.com/engineering/infrastructure-noise
发布日期：2026-02-05

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-kill 一个本来会成功的容器。为了解决这一点，Terminal-Bench 的排行榜使用了不同的沙箱提供商，其实现更宽松，允许临时超额分配而不终止容器，以优先保证基础设施稳定性。

这一发现提出了一个更大的问题：资源配置会在多大程度上影响评测分数？

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

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

这如何影响测量

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

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

一个能非常快速写出精简、高效代码的智能体，在严格约束下会表现良好。一个用重型工具暴力搜索解决方案的智能体，在宽松约束下会表现良好。二者都是合理的测试对象，但如果不指定资源配置就把它们压缩成单一分数，会让差异及其真实世界泛化性难以解释。

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

我们还通过在 SWE-bench 上运行交叉实验，测试这种模式是否适用于 Terminal-Bench 之外的评测。我们在 227 个问题上以每题 10 个样本，将总可用 RAM 提高到基线的 5x。相同效应仍然存在，但幅度更小：分数同样随 RAM 单调上升，但 5x 相比 1x 只高 1.54 个百分点。SWE-bench 任务资源密集程度较低，因此较小效应符合预期，但它说明资源分配在那里也并非中性。

其他方差来源

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

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

公共基准通常旨在衡量纯粹的模型能力，但实践中有可能将模型能力与基础设施特性混在一起。有时这可能是可取的，因为它能端到端测试整个栈，但更多时候并非如此。对于打算公开共享的编码评测，在多个时间点、跨多天运行，有助于平均掉噪声。

我们的建议

理想情况是让每次评测都在完全相同的硬件条件下运行，包括运行评测的 scaffold 和推理栈，因为这可以确保整体完全可复现。然而，这并不总是现实。

鉴于容器运行时实际通过保证分配和单独的硬性终止阈值来执行资源限制，我们建议评测为每个任务同时指定这两个参数，而不是一个固定值。单一精确规格会把保证分配设为等于终止阈值，留下零余量：我们在 1x 记录的瞬时内存峰值足以使评测不稳定。分离这两个参数可以给容器足够呼吸空间，避免虚假的 OOM kill，同时仍执行硬上限，防止分数膨胀。

二者之间的区间应经过校准，使下限和上限的分数落在彼此噪声范围内。例如，在 Terminal-Bench 2.0 中，相比每任务规格设置 3x 上限，将基础设施错误率降低了大约三分之二（5.8% 到 2.1%，p < 0.001），同时分数提升保持温和，并且完全位于噪声范围内（p = 0.40）。这是一个合理取舍：基本中和基础设施混杂因素，同时不移除有意义的资源压力。精确倍数会因基准和任务分布而异，因此应当报告出来，但这种经验校准原则是通用的。

我们为什么在意

这些发现的实际影响超出了评测基础设施本身。基准分数越来越多地被用作决策输入，但这种日益增加的关注（和依赖）并不总是伴随着相应的运行或报告严谨性。按照今天的情况，排行榜上 2 分的领先可能反映真实能力差异，也可能反映一次评测运行在更强硬件上，甚至只是处于一天中更幸运的时段，或者二者兼有。如果没有公开（或标准化）的设置配置，外部很难判断，除非相关方额外努力，在相同条件下复现客观结果。

对于 Anthropic 这样的实验室，含义是智能体式评测的资源配置应被视为一等实验变量，并以与提示格式或采样温度相同的严谨度进行记录和控制。对于基准维护者来说，发布推荐资源规格（就像 Terminal-Bench 2.0 那样）已经大有帮助，而指定限制执行方法则会弥合我们识别出的差距。对于任何使用基准结果的人，核心结论是：智能体式评测上的小分数差异，比报告数字的精度所暗示的更不确定，尤其是有些混杂因素实在太难控制。

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

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

致谢

本文由 Gian Segato 撰写。特别感谢 Nicholas Carlini、Jeremy Hadfield、Mike Merrill 和 Alex Shaw 的贡献。这项工作反映了多个团队在编码智能体评测方面的集体努力。欢迎有兴趣做出贡献的候选人访问 anthropic.com/careers 申请。