量化 Agentic 编程评测中的基础设施噪声
引言
SWE-bench 和 Terminal-Bench 等 Agentic 编程基准测试被广泛用于评估前沿 AI 模型的软件工程能力。然而，仅基础设施配置一项就能造成性能差异，且这种差异超过了排行榜前列排名之间的差距。在内部实验中，Terminal-Bench 2.0 上资源配置最充足与最紧张之间的差距达到 6 个百分点（p < 0.01）。
核心问题
静态基准测试独立于运行时环境对模型输出进行评分，但 Agentic 编程评测的运作方式不同。这些系统为模型提供完整的环境，模型在其中编写代码、执行测试、安装依赖，并跨越多个回合迭代。基础设施成为问题解决的内在组成部分，而非被动的容器。两个在不同资源预算和时间约束下运行的 Agent，实际上面对的是不同的测试。
虽然 Terminal-Bench 2.0 为每个任务指定了推荐的 CPU 和 RAM，但规范不等于一致执行。研究人员发现，执行方法从根本上改变了基准测试所测量的内容。
调查与发现
初步观察
在 Google Kubernetes Engine 上运行 Terminal-Bench 2.0 时，发现得分与官方排行榜不一致。基础设施错误影响了多达 6% 的任务，其中大多数与模型能力无关。
差异源于执行方式。Kubernetes 实现将每个任务的资源规范视为硬限制——容器获得保证分配，但一旦超过阈值就立即终止。容器运行时通过两个参数执行资源限制：保证分配（预先预留）和硬杀阈值。将两者设置为相同值，就完全没有应对瞬时波动的余地。内存峰值可能触发内存不足终止，尽管任务最终可能成功。Terminal-Bench 的排行榜使用更宽松的沙箱机制，允许临时超分配而不终止。
量化影响
在保持模型、测试框架和任务集不变的情况下，测试六种资源配置——从严格执行（1x）到完全无上限——结果显示：
基础设施错误率：
- 严格执行：5.8%
- 3x 余量：2.1%（p < 0.001 显著性）
- 无上限：0.5%
成功率趋势：
在 1x 和 3x 配置之间，成功分数在噪声范围内波动（p=0.40）。大多数在 1x 崩溃的任务无论如何都会失败——Agent 在追求可行方案之前就遇到了资源墙。
从 3x 左右开始，模式发生转变。在 3x 和无上限设置之间：
- 基础设施错误下降 1.6 个百分点
- 成功率跃升近 4 个百分点
- 从 1x 到无上限的总提升：+6 个百分点（p < 0.01）
额外资源使需要大量分配的方法成为可能：导入大型依赖、派生资源密集型子进程、运行内存消耗大的测试套件。rstan-to-pystan 和 compile-compcert 等任务在内存余量充足时显示出显著改善。
这对测量的启示
在约 3x 规格之前，额外资源主要解决基础设施稳定性问题——处理瞬时峰值。Terminal-Bench 维护者通过其沙箱提供商隐式实现了这一点。评测变得稳定，但并未变得更容易。
超过 3x 后，额外资源主动启用了以前不可用的问题解决能力。资源限制决定哪些解决策略能够成功。紧张的限制奖励高效编码和快速执行。宽松的限制有利于利用全面工具和重量级方法的 Agent。
实际案例
bn-fit-modify 任务需要贝叶斯网络拟合。某些模型的初始方法是安装标准 Python 数据科学包：pandas、networkx、scikit-learn 及相关工具链。在宽松限制下，这会成功。在紧张限制下，安装过程中就会发生内存耗尽，根本来不及尝试解决方案。替代策略是存在的——仅使用标准库从头实现数学计算——但某些模型默认采用重型工具方法。不同模型拥有不同的默认策略；资源配置决定了哪些方法最终可行。
跨基准验证
测试扩展到 SWE-bench，通过交叉实验在 227 个问题上将可用 RAM 变化至基准的 5 倍，每个问题 10 个样本。相同的效果持续存在，但幅度较小：分数随 RAM 单调增加，但 5x 仅比 1x 高 1.54 个百分点。由于 SWE-bench 任务需要的资源较少，效果较小在意料之中，但资源分配中性显然并不普遍成立。
研究人员在不同 Anthropic 模型上复现了核心发现，方向性效果一致，幅度各异。在 Claude 之外更广泛的适用性尚未经过严格测试。
其他混淆变量
资源分配不是唯一的隐藏变量。在某些配置下，时间限制可能扮演类似角色。
评测设置的每个元素都可能影响最终分数：集群健康状况、硬件规格、并发水平，甚至出站带宽。Agentic 评测按设计构成端到端系统测试；任何系统组件都作为潜在的混淆因素。传闻中，通过率随一天中的时间波动，可能反映了 API 延迟随流量模式和事件的变化。虽然未正式量化，但这说明了一个更广泛的原则：模型能力与基础设施行为之间的界限变得相当模糊。模型提供商可以通过硬件专用屏蔽评测基础设施；外部评估者无法轻易复制这一点。
公共基准测试理论上测量纯模型能力，但实际上有将它们与基础设施怪癖混淆的风险。端到端堆栈测试有时是可取的，但更多时候并非如此。公开共享的编程评测受益于在多个时间和日期执行以平均噪声。
建议
理想场景是在相同的硬件条件下运行评测，包括脚手架和推理堆栈，确保可复现性。实际约束可能阻止这种情况。
鉴于容器运行时通过保证分配和单独的硬杀阈值执行资源限制，评测应该为每个任务指定这两个参数，而不是固定单个值。单个精确规范将保证分配设置为等于杀阈值，消除了余地。1x 下记录的瞬时内存峰值会破坏评测稳定性。分离参数为容器提供呼吸空间，避免虚假的内存不足终止，同时维持硬上限防止分数膨胀。
保证分配与硬限制之间的区间应该校准，使得下限和上限的分数落在噪声范围内。对于 Terminal-Bench 2.0，每个任务规范的 3x 上限将基础设施错误率大致削减三分之二（5.8% 到 2.1%，p < 0.001），同时保持适度的、噪声级别的分数提升（p = 0.40）。这代表了合理的权衡：基础设施混淆因素被大幅中和，而未移除有意义的资源压力。精确倍数因基准测试和任务分布而异，需要报告，尽管经验校准原则通用。
为什么这很重要
这些发现具有超越评测基础设施的实际意义。越来越多的基准测试分数为决策提供信息，但这种依赖并未带来相应的执行或报告严谨性。目前，2 个百分点的排行榜领先优势可能反映真实的能力差异，也可能只是某次评测在更强大的硬件上运行，甚至是在更有利的时间运行，或这些因素的组合。没有发布或标准化的设置配置，外部验证需要付出大量努力才能在相同条件下复现结果。
对于研究组织，Agentic 评测的资源配置值得作为一等实验变量对待，以与提示格式或采样温度规范相匹配的严谨性进行记录和控制。基准测试维护者发布推荐的资源规范可以做出重大贡献；指定执行方法可以弥合已识别的差距。对于基准测试结果消费者，小幅度 Agentic 评测分数差异比报告的数字精度所暗示的具有更大的不确定性——特别是考虑到某些混淆因素难以控制。
在资源方法标准化之前，证据表明，在没有记录和匹配的评测配置的情况下，3 个百分点以下的排行榜差异值得怀疑。在 Terminal-Bench 中，中等资源配置范围内的观察差异略低于 2 个百分点。简单的二项式置信区间已经跨越 1-2 个百分点；记录的基础设施混淆因素叠加其上，而非其中。分配范围极端产生的差异达到 6 个百分点。
几个百分点的优势可能表明真正的能力区别——或者只是反映了优越的硬件分配。
致谢
由 Gian Segato 撰写。感谢 Nicholas Carlini、Jeremy Hadfield、Mike Merrill 和 Alex Shaw 的贡献。这项工作代表了多个团队评估编程 Agent 能力的集体努力。有兴趣的贡献者可以在 anthropic.com/careers 申请。