量化代理编程评估中的基础设施噪声

Anthropic 发现，仅基础设施配置本身就能在代理编程基准测试中产生超过通常用于区分顶尖模型性能差异的范围的性能差异。在使用 Terminal-Bench 2.0 的内部实验中，资源最丰富和最匮乏设置之间的成功率差距达到 6 个百分点（p < 0.01）。

基础设施作为代理评估中的主动组成部分

与直接评分模型输出的静态基准不同，代理编程评估（如 SWE-bench 和 Terminal-Bench）为模型提供完整的运行时环境，使其能够编写程序、安装依赖项并运行测试。这使得运行时成为解决问题过程的组成部分，而非被动容器。

Anthropic 观察到，当资源规格（CPU 和 RAM）被同时视为下限和硬性上限时，缺乏应对瞬时峰值的余量会导致极高的基础设施错误率。在他们的 Google Kubernetes Engine (GKE) 配置中，高达 6% 的任务因与模型能力无关的 Pod 错误而失败。这是因为瞬时内存波动可能触发容器中的内存不足（OOM）终止，而这些容器的保证分配和硬性限制是相同的。

资源余量对成功率的影响

为了量化支架的影响，Anthropic 在六种资源配置下测试了 Terminal-Bench 2.0，从严格限制（1x）到完全无限制。研究结果表明，资源与得分之间存在两阶段关系：

1. 可靠性阶段（1x 到 3x 余量）

将资源增加到推荐规格的约 3 倍，主要提升了基础设施的可靠性。基础设施错误率从严格限制下的 5.8% 单调下降至 3x 余量下的 2.1%（p < 0.001）。在此阶段，成功率在噪声范围内波动（p = 0.40），表明额外资源主要修复了虚假崩溃，而非使任务更容易解决。

2. 能力阶段（3x 到无限制）

超过 3x 标记后，成功率的提升速度超过了基础设施错误的下降速度。在 3x 到无限制资源之间，基础设施错误下降了 1.6 个百分点，但成功率跃升了近 4 个百分点。这表明充足的资源使代理能够采用仅在高分配下才可能实现的策略，例如：

• 拉取大型依赖项。
• 启动昂贵的子进程。
• 运行内存密集型测试套件。

例如，在 bn-fit-modify 任务中，某些模型尝试安装完整的数据科学栈（pandas、networkx、scikit-learn）。这种策略在宽松限制下成功，但在严格限制下失败；而更轻量的策略（从头实现数学功能）无论限制如何都能成功。

跨基准验证

Anthropic 在不同模型和基准上复现了这些发现：

• 模型一致性： 该效应的方向在不同 Anthropic 模型中保持一致，尽管幅度有所不同。
• SWE-bench： 在 227 个问题上进行的交叉实验（每个问题 10 个样本）显示，得分随 RAM 增加单调上升，最高达基线的 5 倍。然而，该效应较小（在 5x 时比 1x 高 1.54 个百分点），可能是因为 SWE-bench 任务通常比 Terminal-Bench 更少依赖资源。

其他变异来源

除了 RAM 和 CPU，其他系统级因素也可能在代理评估中成为混杂因素：

• 时间限制： 某些配置下，代理的性能会随允许时间的变化而波动。
• 环境噪声： 通过率可能随一天中的时间波动，可能与流量模式相关的 API 延迟变化有关。
• 硬件和网络： 集群健康状况、硬件规格、并发级别和出口带宽都可能影响最终得分。

评估严谨性的建议

为最小化基础设施噪声并防止系统特性与模型能力混淆，Anthropic 建议采取以下措施：

• 指定双参数： 评估应为每个任务指定一个保证分配（下限）和一个独立的硬性终止阈值（上限）。这可防止虚假的 OOM 终止，同时保持硬性上限以防止得分虚高。
• 校准带宽： 下限与上限之间的差距应校准，以确保得分保持在噪声范围内。在 Terminal-Bench 2.0 中，发现 3x 上限是一个有效的折中方案，能显著降低基础设施错误，而不会大幅抬高得分。
• 报告配置： 应明确报告资源倍数和执行方法。
• 增加采样： 在不同日期多次运行评估，有助于平均掉瞬时噪声。

基准解读的启示

由于排行榜上的微小领先可能反映的是更大的虚拟机而非更优越的模型，Anthropic 建议，除非评估配置已记录并匹配，否则排行榜差异低于 3 个百分点应持怀疑态度。Terminal-Bench 中等资源配置下的观察范围仅略低于 2 个百分点，这叠加了现有的二项式置信区间。