量化 Agent 编码评测中的基础设施噪声¶
原文发布于 2025 年 2 月 5 日，作者 Gian Segato
核心观点¶
基础设施配置能让 Agent 编码评测分数波动数个百分点——有时超过排行榜前几名模型之间的差距。
概述¶
Agent 编码评测中，资源配置差异带来的分数波动可高达 6 个百分点，足以颠覆排行榜排名。 SWE-bench、Terminal-Bench 等 Agent 编码基准已成为衡量前沿模型软件工程能力的标尺。排行榜头部模型之间往往只相差几个百分点，而这些分数越来越多地影响着部署决策。然而，Anthropic 发现仅仅是基础设施配置的差异，就能产生超过这些差距的分数变化。
核心发现： 在 Terminal-Bench 2.0 上，资源最宽松与最严格的配置之间，分数差距达到 6 个百分点（p < 0.01）。
为什么 Agent 评测不同于静态基准¶
Agent 评测中，运行时环境不再是被动容器，而是问题求解过程的组成部分。 静态基准直接给模型输出打分，运行时环境无关紧要。而 Agent 编码评测为模型提供完整环境——模型在其中编写程序、运行测试、安装依赖、多轮迭代。运行时环境的资源限制直接影响模型能尝试的策略空间。
问题是怎么发现的¶
Kubernetes 严格执行资源上限导致高达 6% 的任务因基础设施错误而失败。 Anthropic 在 Google Kubernetes Engine 集群上运行 Terminal-Bench 2.0 时，校准阶段发现两个问题：
- 分数与基准的官方排行榜不一致
- 基础设施错误率惊人——高达 6% 的任务因 Pod 错误失败，与模型能力无关
根本原因在于资源执行方式的差异。容器运行时通过两个独立参数管理资源：
| 参数 | 作用 |
|---|---|
| 保证分配（Guaranteed Allocation） | 预先为容器预留的资源 |
| 硬限制（Hard Limit） | 超过此值容器会被杀死 |
Anthropic 的 Kubernetes 实现将每个任务的资源规格同时设为下限和硬上限——两者相等意味着零余量，瞬时峰值就会触发 OOM Kill。而 Terminal-Bench 官方排行榜使用的沙箱提供商实现更宽容，允许临时超额分配而不终止容器。
实验设计¶
在六种资源配置下运行 Terminal-Bench 2.0，从严格执行（1x）到完全不限制，其他变量保持不变。 使用相同的 Claude 模型、相同的评测框架、相同的任务集。
实验结果¶
| 配置 | 基础设施错误率 | 分数变化 |
|---|---|---|
| 1x（严格限制） | 5.8% | 基线 |
| 3x 余量 | 2.1% | 在噪声范围内（p=0.40） |
| 无上限 | 0.5% | 比 1x 高 6 pp（p < 0.01） |
关键观察¶
资源余量的增加带来两阶段效应：先修复可靠性问题，再解锁新的求解策略。
- 成功率随资源余量增加而提升
- 基础设施错误率在每一步都单调下降
- 从 1x 到 3x：错误率从 5.8% 降至 2.1%（p < 0.001），但分数提升在噪声范围内（p=0.40）
- 从 3x 到无上限：错误率仅下降 1.6 pp，但成功率跃升近 4 个百分点
额外资源让 Agent 能够尝试需要大量资源的策略——拉取大型依赖、启动高开销子进程、运行内存密集型测试套件。例如 rstan-to-pystan 和 compile-compcert 等任务在内存充裕时成功率显著提升。
对测量的影响¶
资源限制不仅影响评测可靠性，还会改变评测本质上衡量的能力维度。
| 资源范围 | 效应 | 含义 |
|---|---|---|
| 低于 ~3x 规格 | 修复基础设施可靠性（消除瞬时峰值导致的假失败） | 评测更稳定，但没有变简单 |
| 高于 ~3x 规格 | 主动帮助 Agent 解决之前解不了的问题 | 限制实际改变了评测衡量的内容 |
两种资源策略奖励不同的模型行为：
| 资源策略 | 奖励的行为 |
|---|---|
| 严格限制 | 高效节俭的策略 |
| 宽松限制 | 充分利用所有可用资源的策略 |
示例：bn-fit-modify 任务¶
这个 Terminal-Bench 任务需要进行贝叶斯网络拟合。一些模型的第一反应是安装完整的 Python 数据科学栈（pandas、networkx、scikit-learn）。在宽松限制下可以成功；在严格限制下，安装过程中 Pod 就会被 OOM Kill，解题代码尚未开始执行。但存在一种更精简的策略——仅用标准库从头实现数学运算——有些模型会默认采用这种方式。
不同模型有不同的默认策略，而资源配置决定了哪种策略恰好能成功。
跨模型与跨基准验证¶
核心发现在不同模型和不同基准上均可复现。
- 在不同的 Anthropic 模型上测试：方向一致，幅度有差异
- SWE-bench 交叉验证实验：对 227 个问题（每个 10 次采样）将 RAM 最高提升至 5 倍基线
- SWE-bench 分数随 RAM 单调递增：5x 比 1x 高 1.54 个百分点
- SWE-bench 效应较小，符合预期——其任务资源需求普遍低于 Terminal-Bench
其他方差来源¶
除资源分配外，时间限制、集群健康度、甚至一天中的时段都会引入噪声。 基础设施噪声的来源远不止内存和 CPU：
| 方差来源 | 说明 |
|---|---|
| 时间限制 | 在某些配置下影响评测结果 |
| 集群健康度 | 硬件规格、并发度、出口带宽 |
| 时间段效应 | 通过率随时间波动，可能因 API 延迟随流量模式变化 |
"模型能力"与"基础设施行为"之间的边界，远比一个基准分数所暗示的更加模糊。
模型提供商可以通过专用硬件屏蔽自己评测的基础设施噪声，但外部评估者很难做到这一点。
建议¶
评测应同时指定保证分配和硬杀阈值两个参数，在可靠性与公平性之间取得平衡。
理想情况： 每次评测在完全相同的硬件条件下运行（脚手架和推理栈），实现完美可复现。
实际建议： 评测应为每个任务指定两个参数（保证分配 + 硬杀阈值），而不是单一固定值。两者之间的区间应经过校准，使分数在下限和上限处落入噪声范围内。
对于 Terminal-Bench 2.0，3x 上限相对于每个任务的规格：
- 基础设施错误率降低约三分之二（5.8% → 2.1%，p < 0.001）
- 分数提升温和且在噪声范围内（p = 0.40）
具体倍数因基准而异，应明确报告。对于面向公众发布的编码评测，在不同时间和不同天数运行多次有助于平均化噪声。
为什么这很重要¶
在资源方法论标准化之前，排行榜上低于 3 个百分点的差距值得怀疑。
| 统计数据 | 数值 |
|---|---|
| 中等资源配置间的观察分差 | 接近 2 个百分点 |
| 朴素二项置信区间 | 1-2 个百分点 |
| 极端分配范围的分差 | 6 个百分点 |
基础设施干扰因素叠加在统计噪声之上，而非包含在其中。
几个百分点的领先可能代表真实的能力差距——也可能只是一台更大的虚拟机。
致谢：特别感谢 Nicholas Carlini、Jeremy Hadfield、Mike Merrill 和 Alex Shaw。