原文标题：Quantifying infrastructure noise in agentic coding evals
原文链接：https://www.anthropic.com/engineering/infrastructure-noise
Agentic coding benchmarks，例如 SWE-bench 和 Terminal-Bench，通常被用来比较前沿模型的软件工程能力——而排行榜前几名之间往往只差几个百分点。这些分数常常被当作对模型相对能力的精确测量，并且越来越多地被用于决定部署哪种模型。然而，我们发现，仅基础设施配置本身，就可能造成超过这些差距的分数变化。在内部实验中，资源最充足与资源最少的配置之间，在 Terminal-Bench 2.0 上的差距达到了 6 个百分点（p < 0.01）。
静态 benchmark 会直接给模型输出打分——运行时环境不会影响结果。Agentic coding evals 则不同：模型被给予一个完整环境，在其中编写程序、运行测试、安装依赖，并在多轮交互中不断迭代。运行时不再是一个被动容器，而是问题求解过程的组成部分。两个拥有不同资源预算和时间限制的 agent，实际上并不是在参加同一场测试。
Eval 开发者已经开始考虑这个问题。例如，Terminal-Bench 2.0 在其最新的 2.0 版本中，按任务给出了推荐的 CPU 和 RAM 配置。然而，指定资源并不等于能够始终如一地强制执行。更进一步，我们发现，执行方式本身也会改变 benchmark 实际测量的对象。
我们是如何发现这个问题的
我们在 Google Kubernetes Engine 集群上运行 Terminal-Bench 2.0。在校准这套配置时，我们注意到自己的分数与 benchmark 官方排行榜不一致，而且基础设施错误率高得惊人：最多有 6% 的任务因为 pod 错误而失败，而这些错误大多数都与模型是否有能力解决任务无关。
分数差异归根结底来自执行方式。我们的 Kubernetes 实现，把按任务指定的资源规格同时当作下限和硬上限：每个容器都能获得所指定的资源保证，但一旦超出，就会立刻被杀死。容器运行时会通过两个独立参数来执行资源限制：一个是保证分配值——即预先保留的资源；另一个是硬限制值——一旦超出，容器就会被终止。当这两个值被设置为相同数值时，就完全没有任何冗余空间：一次短暂的内存波动，就可能让一个本来会成功的容器因为 OOM 而被杀死。为了解决这个问题，Terminal-Bench 排行榜使用了不同的 sandbox provider，其实现方式更加宽松，允许临时超额分配，而不会立刻终止容器，从而优先保证基础设施稳定性。
这一发现引出了一个更大的问题：资源配置究竟会在多大程度上影响评测分数？
为了量化 scaffold 的影响，我们在六种资源配置下运行了 Terminal-Bench 2.0，从严格执行按任务规格（1x）——即同时把它当作下限和上限——一直到完全不设上限。其他一切保持不变：相同的 Claude 模型、相同的 harness、相同的任务集。
在我们的实验中，随着资源冗余的增加，成功率也随之提高。其主要原因是基础设施错误率在每一步都单调下降：从严格执行时的 5.8%，降到不设上限时的 0.5%。从严格执行到 3x 冗余之间的下降（5.8% 到 2.1%）在统计上显著（p < 0.001）。冗余越多，因超出分配额度而被杀死的容器就越少。
从 1x 到 3x，成功分数的波动仍然落在噪声范围之内（p = 0.40）。在 1x 下崩溃的大多数任务，即使不崩溃，最终也会失败——这是我们在数据中观察到的现象。Agent 会进行探索、撞上资源墙、被提前中止，但它原本就不在通向正确解的路径上。
然而，大约从 3x 开始，这一趋势发生了变化：成功率上升的速度，开始超过基础设施错误率下降的速度。
从 3x 到不设上限之间，基础设施错误又额外下降了 1.6 个百分点，而成功率却上升了将近 4 个百分点。额外资源使 agent 能够尝试那些只有在资源充足时才行得通的方法，比如拉取大型依赖、启动昂贵的子进程、运行高内存占用的测试套件。在不设上限的情况下，相比 1x，总提升达到了 +6 个百分点（p < 0.01）。在边缘任务中，像 rstan-to-pystan 和 compile-compcert 这样的任务，在获得内存冗余后，成功率显著提高。
这会如何影响测量结果
在大约 3x Terminal-Bench 规格之前，额外资源主要是在修复基础设施可靠性问题，也就是那些短暂的资源峰值。Terminal-Bench 维护者使用的 sandboxing provider，实际上就在后台隐式地完成这件事；评测会变得更稳定，但不会因此变得更容易。
然而，超过 3x 之后，额外资源开始主动帮助 agent 解决原本无法解决的问题。这说明，资源限制确实会改变 eval 所测量的内容。严格限制会无意中奖励那些非常高效的策略；而宽松限制则更宽容，也更奖励那些能够充分利用所有可用资源的 agent。
一个能快速写出精简高效代码的 agent，会在严格约束下表现更好。一个借助重量级工具、采用暴力式方案的 agent，则会在宽松约束下表现更好。这两者都是合理的测试目标，但如果在不说明资源配置的情况下，把它们折叠成单一分数，那么这些差异——以及它们在现实世界中的可泛化性——都会变得难以解释。
在 bn-fit-modify 这个 Terminal-Bench 任务中，需要进行 Bayesian network fitting。有些模型的第一步，是安装标准 Python 数据科学栈：pandas、networkx、scikit-learn 以及它们整套工具链。在宽松限制下，这种方式能成功；而在严格限制下，pod 会在安装过程中就耗尽内存，还没等 agent 写出任何一行解决方案代码。其实存在一种更精简的策略（只使用标准库，从零实现数学部分），而且有些模型确实会默认采用这种方式；另一些则不会。不同模型有不同的默认路径，而资源配置决定了这些路径中哪些最终能成功。我们也在不同的 Anthropic 模型上复现了这一核心发现。效应方向是一致的，只是幅度有所不同。相同趋势似乎也适用于 Claude 之外的模型，但我们尚未对其进行严格测试。
我们还通过在 SWE-bench 上进行交叉实验，测试了这一模式是否适用于 Terminal-Bench 之外的 eval。我们在 227 个问题上、每题 10 次采样，把可用总 RAM 提高到基线的最多 5 倍。结果同样成立，只是影响幅度更小：分数依旧随着 RAM 单调上升，但在 5x 相比 1x 时，只高出 1.54 个百分点。SWE-bench 任务对资源的需求没那么高，所以影响较小也在预期之内；但这同样说明，资源分配在那里面也不是中性的。
其他方差来源
资源分配并不是唯一的隐藏变量。在某些配置下，时间限制也会开始产生作用。
原则上，评测配置中的每一个元素，都可能影响最终分数：从集群健康状况到硬件规格，从并发级别到出口带宽，都是如此。Agentic evals 从构造上看，就是端到端系统测试，而系统中的任何组件，都可能成为混杂因素。例如，我们曾从经验上观察到，通过率会随一天中的时间不同而波动，这很可能是因为 API 延迟会随流量模式和故障情况变化。我们还没有对这一效应进行正式量化，但它说明了一个更大的事实：在单一 benchmark 分数里，“模型能力”与“基础设施行为”之间的边界，比看上去更模糊。模型提供方可以通过为评测基础设施分配专用硬件来避免这个问题，但外部评估者很难同样做到。
公共 benchmark 通常意在测量纯粹的模型能力，但在实践中，它们有可能把基础设施的怪异行为也混在一起。有时候这可能是可取的，因为它实现了对整个栈的端到端测试；但更多时候并不是如此。对于要公开共享的 coding evals，如果能在多个时间点、跨多天运行，将有助于把这些噪声平均掉。
我们的建议
理想情况下，应当在完全相同的硬件条件下运行每一次 eval——包括运行 eval 的 scaffold 和推理栈——这样可以确保全局范围内的完美可复现性。不过，这在现实中未必总是可行。
考虑到容器运行时在实际执行资源限制时，是通过“保证分配值”和“单独的硬终止阈值”这两个参数来完成的，我们建议 eval 为每个任务同时指定这两个参数，而不是只给出一个固定值。单一的精确规格，会让保证分配值等于终止阈值，从而没有任何缓冲空间：我们在 1x 下记录到的那些瞬时内存峰值，已经足以让评测变得不稳定。把这两个参数分开，可以给容器足够的呼吸空间，避免虚假的 OOM kill，同时仍保留一个硬上限，以防止分数膨胀。
这两者之间的区间，应当通过校准来确定，使得在下限和上限下得到的分数彼此仍落在噪声范围之内。例如，在 Terminal-Bench 2.0 中，把硬上限设置为按任务规格的 3x，可以使基础设施错误率大约下降三分之二（5.8% 到 2.1%，p < 0.001），同时分数提升幅度仍较小，并且明确处于噪声范围内（p = 0.40）。这是一个合理的折中：基础设施这一混杂因素在很大程度上被中和了，但又没有移除有意义的资源压力。具体倍数会因 benchmark 和任务分布不同而变化，因此应当被报告出来，但这种依赖实证校准的原则具有普遍性。
为什么我们关心这个问题
这些发现带来的实际影响，并不止于 eval 基础设施本身。Benchmark 分数越来越多地被当作决策输入，但这种关注度（以及依赖度）的提升，并不总是伴随着相应的运行与报告严谨性。按照当前状况，排行榜上领先 2 分，既可能反映真实的能力差异，也可能只是因为某次评测运行在更强的硬件上，或者碰巧在一天中更幸运的时间点进行，甚至两者兼有。若没有公开（或标准化）的配置说明，外部很难判断，除非相关方愿意额外投入成本，在相同条件下复现客观结果。
对于像 Anthropic 这样的实验室而言，这意味着在 agentic evals 中，资源配置应被视为一等实验变量，像 prompt 格式或采样温度那样，以同等严谨性进行记录和控制。对于 benchmark 维护者而言，像 Terminal-Bench 2.0 那样公布推荐资源规格，已经很有帮助；如果进一步说明执行方式，就能补上我们发现的缺口。而对于所有 benchmark 结果的使用者而言，核心结论是：在 agentic evals 上，几个百分点的微小差异，其不确定性要比报告数字看起来更大——尤其是在某些混杂因素本身就极难控制的情况下。
在资源执行方法尚未标准化之前，我们的数据表明：如果 eval 配置没有被记录并严格匹配，那么排行榜上低于 3 个百分点的差异，都应当被谨慎看待。我们在 Terminal-Bench 中等资源配置范围内观察到的分数波动，略低于 2 个百分点。即使是最朴素的二项分布置信区间，也已经横跨 1–2 个百分点；而我们在这里记录的基础设施混杂因素，是叠加在其之上的，而不是包含在其中。在资源分配范围的极端情况下，波动甚至可以达到 6 个百分点。
几个百分点的领先，可能意味着真实能力差距——也可能只是更大的 VM。
致谢
本文由 Gian Segato 撰写。特别感谢 Nicholas Carlini、Jeremy Hadfield、Mike Merrill 和 Alex Shaw 所作贡献。这项工作体现了多个从事 coding agents 评测团队的集体努力。有兴趣参与相关工作的候选人，欢迎申请 anthropic.com/careers。