量化智能体编码评测中的基础设施噪声
像 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 模型、相同的框架、相同的任务集。
在我们的实验中，成功率随着资源余量的增加而提高。这主要是由基础设施错误率在每一步都单调下降所驱动的，从严格强制执行时的 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 这样的任务在获得内存余量时，成功率会显著提高。
这如何影响测量
在大约 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 变化至基线的 5 倍。同样的效果依然存在，尽管幅度较小：分数再次随 RAM 单调递增，但 5x 时仅比 1x 高 1.54 个百分点。SWE-bench 任务的资源消耗较少，因此预期效果会较小，但这表明资源分配在那里也并非中性的。
其他变异来源
资源分配并非唯一的隐藏变量。在某些配置下，时间限制也开始发挥作用。
原则上，评估设置中的每个元素都可能影响最终得分，从集群健康状况到硬件规格，从并发级别甚至到出站带宽。智能体评估从本质上讲是端到端的系统测试，而该系统的任何组成部分都可能成为混淆因素。例如，我们根据经验观察到，通过率会随一天中的时间而波动，这可能是因为 API 延迟会随流量模式和故障事件而变化。我们尚未正式量化这一影响，但它说明了一个更宏观的观点："模型能力"与"基础设施行为"之间的边界，比单一基准分数所显示的要模糊得多。模型提供商可以通过配备专用硬件来屏蔽评估基础设施的这一影响，但外部评估者很难做到同样的事。
公共基准通常旨在衡量纯粹的模型能力，但在实践中，它们有可能将模型能力与基础设施特性混为一谈。有时这可能是可取的，因为它能够对整个技术栈进行端到端测试，但更多时候并非如此。对于旨在公开共享的编码评估，在多个时间和多个日期运行有助于平均掉噪声。
我们的建议
理想情况是在完全相同的硬件条件下运行每个评估——包括运行评估的脚手架和推理堆栈——因为这将确保全面的完美可复现性。然而，这并不总是切实可行的。
鉴于容器运行时实际执行资源限制的方式——通过保证配额和单独的硬性终止阈值——我们建议评估为每个任务指定这两个参数，而不是单一的固定值。单一的精确规格会将保证配额等同于终止阈值，不留任何余地：我们在 1x 规格下记录到的瞬时内存峰值足以破坏评估的稳定性。将这两个参数分开，可以让容器有足够的喘息空间以避免误杀（OOM 终止），同时仍然强制执行一个硬性上限，防止分数虚高。
两者之间的区间应经过校准，使得处于下限和上限的分数落在彼此的噪声范围内。例如，在 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 个百分点。
几个百分点的领先可能意味着真实的能力差距——也可能只是一台更大的虚拟机。