量化 Agent 编码评估中的基础设施噪声
发布日期： 2026年2月5日
作者： Gian Segato
本文研究了基础设施配置如何单独将 Agent 编码基准测试结果偏移几个百分点——有时甚至超过排行榜上顶级模型之间的差距。
核心发现
SWE-bench 和 Terminal-Bench 等 Agent 编码评估与静态基准测试不同，因为"运行时不再是被动容器，而是问题解决过程中不可或缺的组成部分。"两个在不同资源预算和时间限制下运行的 Agent 实际上是在参加不同的测试。
在内部实验中，Terminal-Bench 2.0 在资源配置最高和最低的配置之间显示了6个百分点的差异（p < 0.01）。
调查如何开始
Anthropic 在 Google Kubernetes Engine 上运行 Terminal-Bench 2.0。在校准期间，分数与官方排行榜出现偏差，基础设施错误率出乎意料地高——高达6%的任务因与模型能力无关的 Pod 错误而失败。
根本原因是强制执行方法。他们的 Kubernetes 设置将每任务资源规格同时视为保证分配和硬上限。容器运行时通过两个参数强制执行资源：保证分配和硬终止阈值。当两者设置为相同时，瞬态尖峰没有任何余量，导致过早的 OOM 终止。
Terminal-Bench 的排行榜使用不同的沙箱提供商，其强制执行更宽松，允许临时超分配。
实验
他们在六种资源配置下运行 Terminal-Bench 2.0——从严格的1倍强制执行到完全无上限——同时保持相同的 Claude 模型、Harness 和任务集不变。
关键结果：
- 基础设施错误率单调下降：从1倍时的5.8%到无上限时的0.5%
- 从严格强制执行到3倍余量的下降在 p < 0.001 水平上显著
- 从1倍到3倍，成功分数在噪声范围内波动（p=0.40）
- 在3倍和无上限之间，成功分数跳升了约4个百分点，而基础设施错误仅下降了1.6个百分点
- 无上限相对于1倍的总提升为+6个百分点（p < 0.01）
文章解释说，在约3倍规格以内，额外资源修复了可靠性问题。超过3倍，资源积极帮助 Agent 解决以前无法解决的问题，这意味着"限制实际上可以改变评估衡量的内容。"
对测量的影响
不同的资源配置奖励不同的策略。严格的限制有利于高效、精简的方法；慷慨的限制奖励利用所有可用资源的 Agent。文章使用贝叶斯网络拟合任务（bn-fit-modify）作为示例：一些模型安装完整的 Python 数据科学栈，这在慷慨限制下成功但在严格限制下在包安装期间崩溃。
核心发现在不同的 Anthropic 模型中得到了复制，方向一致但幅度不同。在 SWE-bench 上的交叉实验（227个问题，每个10个样本）显示了相同的随 RAM 单调增加的趋势，尽管5倍与1倍之间的差距较小，为1.54个百分点——这是预期的，因为 SWE-bench 任务的资源密集度较低。
其他方差来源
资源分配不是唯一的隐藏变量。时间限制在某些配置中也起作用。作者指出"评估设置的每个元素都可能影响最终分数"，包括集群健康状况、硬件规格、并发级别，甚至出口带宽。他们观察到通过率随一天中的时间波动，可能是由于 API 延迟变化。
文章指出"'模型能力'和'基础设施行为'之间的边界比单个基准测试分数所暗示的更加模糊。"
建议
作者建议评估应指定每任务的保证分配和硬终止阈值，而不是单个固定值。两者之间的带宽应被校准，使底限和上限的分数在彼此的噪声范围内。对于 Terminal-Bench 2.0，3倍上限将基础设施错误率降低了约三分之二，同时将分数提升保持在噪声范围内——被描述为一个合理的权衡，中和了基础设施混杂因素而不移除有意义的资源压力。
关键要点
文章总结说"排行榜上低于3个百分点的差异值得怀疑，直到评估配置被记录和匹配。"在 Terminal-Bench 中等资源配置下观察到的差异略低于2个百分点，而基础设施混杂因素叠加在朴素二项式置信区间之上而非内部。排行榜上的几分领先可能反映真实能力——也可能只是反映了更强大的硬件。
致谢： 特别感谢 Nicholas Carlini、Jeremy Hadfield、Mike Merrill 和 Alex Shaw。