Agent 评测正在失真：基础设施噪声可能比模型能力更影响榜单
- 核心发现：6 个百分点的差距
- 为什么会这样
- 两层影响机制
- 一个具体例子
- 资源限制会奖励不同类型的 Agent
- SWE-bench 也不是完全免疫
- 对榜单的影响
- 对开发者和企业的启发
- 其他隐藏变量
- 结语
- 引用来源
本文首发地址 https://h89.cn/archives/571.html
本文基于 Anthropic 工程博客 Quantifying infrastructure noise in agentic coding evals 整理，原文发布于 2026 年 4 月。
如果你经常关注 Coding Agent 榜单，大概率会看到这样的结论：某个模型在 SWE-bench 上领先 2 个百分点，另一个模型在 Terminal-Bench 上又反超 3 个百分点。
但 Anthropic 最近的一篇工程博客提醒了一个更麻烦的问题：这些差距，可能不全是模型能力造成的。
在 Agentic Coding Eval 里，基础设施配置本身就可能让分数上下波动几个百分点。有时，这个波动甚至比榜单上两个顶级模型之间的差距还大。
核心发现：6 个百分点的差距
Anthropic 在 Terminal-Bench 2.0 上做了一组实验：
同一个 Claude 模型、同一套 harness、同一批任务，只改变资源配置——从严格限制到完全不限资源。
结果很直接：资源越宽松，成功率越高。从最严格配置到不限资源，成功率相差 6 个百分点（p < 0.01）。
6 个百分点是什么概念？很多顶级模型在榜单上的差距，可能也就几个百分点。
这意味着，一个 2 分的领先，可能确实代表模型更强，也可能只是跑在了更大的 VM 上。
为什么会这样
传统模型评测通常比较简单：给模型一个输入，看它输出什么，然后根据答案打分。运行环境不是解题过程的一部分。
Agent 评测不一样。模型要进入一个真实或半真实的开发环境里：读文件、改代码、运行测试、安装依赖、调用命令行、反复试错。
这台机器的 CPU、内存、网络、时间限制、容器策略，都会影响它能不能完成任务。
Anthropic 最初在 Google Kubernetes Engine 上运行评测时，把每个任务的资源规格同时当作"保证值"和"硬上限"。这意味着：容器会被保证拿到这些资源，但只要瞬间超过这个上限，就可能被直接杀掉。
Agent 运行测试、安装依赖、编译项目时，内存可能会出现短暂尖峰。这个尖峰不一定说明模型失败了，但容器可能已经被 OOM kill 了。
两层影响机制
基础设施影响分数的方式分两层：
第一层：减少基础设施错误（1x → 3x）
从严格限制到给大约 3 倍 headroom，基础设施错误率从 5.8% 降到 2.1%，这个下降具有统计显著性（p < 0.001）。
但在这个阶段，成功率本身的波动并不显著（p=0.40）。这说明大部分在 1x 配置下崩溃的任务，即使给了更多资源也不会成功——Agent 本来就没走对路。
这个阶段更像是在修复评测系统本身，让 Agent 不要因为无关原因失败。
第二层：资源开始改变题目难度（3x → uncapped）
当资源继续变得更宽松后，Agent 不只是少遇到系统错误，而是开始能使用原本跑不动的策略。
从 3x 到 uncapped，基础设施错误只下降了 1.6 个百分点，但成功率跳升了近 4 个百分点。
这时候，评测已经不只是"更稳定"了，而是变得"更容易"了。
| 资源配置 | 主要影响 | 成功率变化 |
|---|---|---|
| 1x → 3x | 减少基础设施错误 | 波动不显著 (p=0.40) |
| 3x → uncapped | 支持更多策略 | +4 个百分点 |
| 总体 (1x → uncapped) | 两层叠加 | +6 个百分点 (p < 0.01) |
一个具体例子
在 Terminal-Bench 的 bn-fit-modify 任务（贝叶斯网络拟合）中，有些模型的第一反应是安装完整的 Python 数据科学栈：pandas、networkx、scikit-learn 及其依赖。
在宽松资源下，这个策略可以跑通。
但在严格资源限制下，容器在安装依赖时就会因为内存不足被杀掉，Agent 连一行解题代码都没写。
另一种策略是只用标准库从头实现数学逻辑。这种方案更轻量，在严格限制下反而能成功。
有些模型默认选第一种，有些默认选第二种。资源配置决定了哪种策略能成功，但这两种策略代表的能力其实不一样。
资源限制会奖励不同类型的 Agent
| 资源环境 | 表现好的 Agent 特征 |
|---|---|
| 严格限制 | 写轻量代码、少装依赖、快速定位问题、用标准库绕过重型工具 |
| 宽松限制 | 敢于安装大型依赖、跑完整测试、brute force 更多尝试、充分利用资源 |
这两类能力都是真实能力。问题不在于谁对谁错，而在于 benchmark 不能把它们混成一个单一分数，然后假装这个分数只代表"模型更强"。
SWE-bench 也不是完全免疫
Anthropic 在 SWE-bench 上测试了 227 个问题，每个问题跑 10 个样本，内存从 1 倍逐步提升到 5 倍。
结果显示，分数依然会随内存单调上升，从 1 倍到 5 倍提升了 1.54 个百分点。
SWE-bench 的任务通常不像 Terminal-Bench 那样资源密集，所以影响更小。但即使如此，资源配置仍然不是中性的。
对榜单的影响
Anthropic 的建议很明确：
在资源配置没有标准化之前，Agentic Eval 中低于 3 个百分点的 leaderboard 差异，都应该保持怀疑，除非评测配置被清楚记录并且可复现。
这句话很重要。因为今天很多模型发布、产品宣传、社区讨论，都喜欢抓住几个百分点的领先来讲故事。
但如果评测配置没有公开，或者不同模型不是在同一套基础设施约束下运行，那么这些小差距可能并不可靠。
对开发者和企业的启发
如果你在看榜单选型
| 建议 | 说明 |
|---|---|
| 看大差距，不迷信小差距 | 1-2 个百分点的差异可能只是评测噪声 |
| 看评测环境是否公开 | CPU、内存、时间限制、容器策略、并发、网络 |
| 在真实任务上复测 | 企业内部环境可能和公开 benchmark 完全不同 |
| 拆分评测维度 | 不只看 pass rate，还要看成本、耗时、失败原因、资源消耗 |
| 关注 Agent 策略风格 | 高效克制 vs 资源消耗大但探索能力强，哪种更适合你？ |
如果你在做 Agent 评测
Anthropic 的这篇文章给出了几个明确建议：
- 公开资源配置：不只是推荐值，还要说明实际执行策略
- 报告基础设施错误率：把 infra error 和 model failure 分开统计
- 多次运行并报告方差：单次运行的分数可能不稳定
- 考虑分层报告：不同资源配置下的表现可以分别报告
- 明确评测目标：是测效率还是测能力上限？不同目标应该用不同配置
对国内团队的特别提醒
国内很多团队在评估 Coding Agent 时，会直接参考海外榜单。但需要注意：
- 国内网络环境、依赖源、API 延迟与海外不同
- 很多企业内部有更严格的资源限制和安全策略
- 私有化部署的硬件配置可能与公开评测环境差异很大
所以即使某个模型在公开榜单上领先，也不代表它在你的生产环境里一定更好。
其他隐藏变量
资源配置只是最明显的一类。Anthropic 还提到，Agent 评测里还有很多其他隐藏变量：
- 时间限制
- 集群健康状态
- 硬件规格
- 并发程度
- 网络出口带宽
这些变量都会影响 Agent 的表现。因为 Agent 的能力不是一次输出，而是一整套闭环：观察环境、制定计划、执行命令、等待结果、根据反馈修改策略。
这个闭环里的任何环节变慢、失败、受限，最后都会反映到分数上。
结语
Anthropic 这篇文章提醒我们：Agent 评测的数字，不应该被看得过于精确。
当模型开始操作工具、运行代码、安装依赖、调用外部环境时，评测就不再是一个单纯的问答测试，而是一场系统工程实验。
在这样的实验里，基础设施不是背景板，而是变量本身。
所以，下次看到某个 Coding Agent 在榜单上领先 2 个百分点，不妨先别急着下结论。
先问三个问题：
- 它们是在同样的资源限制下跑的吗？
- 基础设施错误率是多少？
- 这个差距大到足以超过评测噪声吗？
如果这些问题没有答案，那么那个领先可能代表模型能力，也可能只是代表它拿到了一台更大的机器。
引用来源
本文链接：Agent 评测正在失真：基础设施噪声可能比模型能力更影响榜单 - https://h89.cn/archives/571.html
版权声明：原创文章 遵循 CC 4.0 BY-SA 版权协议，转载请附上原文链接和本声明。