Quantifying Infrastructure Noise in Agentic Coding Evals（量化智能体编码评测中的基础设施噪声）
- 原文标题
- Quantifying Infrastructure Noise in Agentic Coding Evals（量化智能体编码评测中的基础设施噪声）
- 原文链接
- https://www.anthropic.com/engineering/infrastructure-noise
- 作者
- Gian Segato 等（Anthropic）
- 发布日期
- 2026-02-05
🎯 一句话
评测分数的波动里，有相当一部分根本不来自模型——超时、限流、网络抖动、依赖服务变更都会拉低分数。⭐ 分不清这两者，你会为不存在的问题做优化。
基础设施配置对智能体编码基准分数的影响巨大且可测量，甚至超过排行榜上头部模型之间的分差——仅资源配置差异就能在 Terminal-Bench 2.0 上造成 6 个百分点的差距。
问题背景
静态基准不在乎运行环境；但智能体编码评测把模型放进完整环境里「写程序、跑测试、装依赖、多轮迭代」——运行时是解题的积极参与者而非被动容器，资源分配成了影响评测实际测什么的关键变量。
发现过程
Anthropic 在 GKE 上跑 Terminal-Bench 2.0 时发现分数与官方排行榜不符，基础设施错误率达 6%。根因：他们的 Kubernetes 把资源规格当硬顶执行——内存瞬时波动就杀容器；而官方排行榜用的沙箱提供商允许临时超配不终止。
实验：资源配置的系统性影响
固定模型、harness、任务集，测试从严格执行（1x）到完全不设限的六种资源配置：
基础设施错误率： - 1x 严格执行：5.8% - 3x 余量：2.1%（相比 1x 显著，p < 0.001） - 不设限:0.5%
成功率呈两个阶段： 1. 可靠性阶段（1x → 3x）： 成功率波动在统计噪声内（p=0.40）——1x 下失败的任务本来也会失败 2. 能力阶段（3x → 不设限）： 基础设施错误只再降 1.6 个百分点，成功率却跳升约 4 个百分点——充裕资源让 Agent 能尝试只有大配额才可行的方案（拉大依赖、派生昂贵子进程、跑内存密集测试套件）
累计效应：1x 到不设限共 6 个百分点（p < 0.01）。
度量学上的要害
资源约束在无形中改变了基准测的是什么能力。例：bn-fit-modify 任务——有些模型默认装全套 Python 数据科学栈（pandas、networkx、scikit-learn），宽限额下成功、紧限额下还没写解题代码就内存爆掉；也存在只用标准库从头实现数学的路线。「不同模型有不同的默认策略，资源配置决定了哪种策略碰巧能成功。」
跨基准验证
在 SWE-bench 上用交叉实验验证（227 题 × 10 采样，RAM 最高 5x）：效应一致但更小——5x vs 1x 只差 1.54 个百分点（SWE-bench 任务资源密集度更低）。确认资源配置在不同基准上都不是中性变量。
其他基础设施噪声源
- 时间效应： 通过率随一天中的时段波动（API 延迟随流量和事故变化）
- 集群健康状况、硬件规格、并发水平、网络出口带宽（影响依赖安装速度）
这些共同模糊了「模型能力」与「基础设施行为」的边界。对公共基准，「在多个时间、多天运行取平均」有助于消噪。
建议
- 双参数取代单一限额： 指定保证分配（下限）+ 硬杀阈值（上限），既避免「零余量」下瞬时内存尖峰误杀容器，又通过上限保持有意义的资源压力
- 实证校准间距： 下限与上限处的分数应落在统计噪声内。Terminal-Bench 2.0 的例子：3x 上限把基础设施错误率降低三分之二（5.8%→2.1%）而分数提升在噪声内；具体倍数因基准而异，应当公开报告
- 三方职责： 基准维护者发布推荐资源规格和执行方式；评测执行者把资源配置当一等实验变量记录（与提示词格式、采样温度同等严谨）；基准消费者对未说明配置的、3 个百分点以内的排行榜差距保持怀疑
结论
基准分数越来越多地驱动部署决策，但度量的严谨性没有同步提升。「几个点的领先可能是真实的能力差距——也可能只是一台更大的虚拟机，或者跑在了运气更好的时段。」
✅ 检查点
- 基础设施噪声会造成什么误判？
- 怎么把噪声和真实退化区分开？
- 为什么这在 Agent 评测里比传统模型评测更严重？
👀 答案
- ⭐ 把环境问题误判成模型能力问题：看到分数掉了就去改提示词、换模型、加约束，而真正的原因可能只是某个工具那天超时率高。反过来也一样——环境变好时会误以为是自己的优化生效了。
- ①把失败按类型分开统计（超时/限流/工具报错/模型答错），而不是只看总分；②同一套用例重复跑多次看方差；③记录每次评测的环境元数据（依赖版本、耗时分布、错误码）；④设一个「基础设施健康度」基线，先确认它正常再解读分数。
- 因为 Agent 一次任务要调用几十次工具、涉及多个外部系统，任何一环抖动都会让整条链失败；而传统模型评测通常只是一次前向推理，没有外部依赖。⭐ 链路越长，噪声累积得越厉害——单步 99% 成功率，50 步下来只剩 60%。
🛑 可以停在这里
⚡ 走神救援
⭐评测分数的波动有相当一部分不来自模型——超时、限流、网络抖动、依赖变更；分不清这两者，你会为不存在的问题做优化（看到分数掉就改提示词换模型，而真正原因可能只是某工具那天超时率高）。四个区分手段：把失败按类型分开统计（超时/限流/工具报错/模型答错）而非只看总分、同一套用例重复跑看方差、记录环境元数据、设「基础设施健康度」基线先确认它正常再解读分数。⭐⭐Agent 评测里更严重的原因：一次任务要调几十次工具、涉及多个外部系统，任何一环抖动都会让整条链失败；链路越长噪声累积越厉害——单步 99%，50 步下来只剩 60%。