原文参考：Gian Segato, “Quantifying infrastructure noise in agentic coding evals”。本文是原创解读，不是翻译。

Agent Benchmark 最容易误导人的，不是模型分数，而是基础设施噪音

过去几年大家看模型 benchmark 已经看出了一套肌肉记忆：谁更高、谁领先几分、哪条曲线更陡、哪个榜单最有公信力。

这种阅读习惯带到 agent benchmark 上，很容易产生一种危险的误会：只要评分机制够正式、任务集够像回事、图表做得够清楚，分数差异就能自然代表系统能力差异。

Anthropic 那篇《Quantifying infrastructure noise in agentic coding evals》最重要的贡献，不在于告诉你某个具体 benchmark 上升了多少，而在于它逼着我们重新面对一个很多人都不愿意认真承认的事实：agentic coding eval 从来都不是纯模型测试，它本质上是模型、运行时、资源约束、工具链与执行环境共同参与的系统测试。

换句话说，当你看一个 agent benchmark 时，你看到的从来不只是”这个模型有多强”，你还看到了：sandbox 多宽松、资源配置多慷慨、kill 语义多残酷、并发压力多高、网络多稳定、集群多健康、安装依赖时有没有额外好运气。

如果这些条件没有被充分说明，那排行榜上的分差就很难被稳当地解释。

而我认为，这恰恰是今天 agent benchmark 最容易误导人的地方。

一、agent eval 为什么天然比静态 model eval 更吃基础设施条件

要理解这篇文章的重要性，先得承认一件事：agent eval 和传统模型评测不是同一类东西。

传统静态评测大多更接近输入-输出比对：给问题、出答案、和标注答案或 judge 结果比较。

在这个范式里，运行环境当然也重要，但重要性相对有限，因为环境本身并不深度介入解题过程。

而 agentic coding eval 不一样。它要求 agent 真正进入环境里行动：安装依赖、读写文件、启动命令、执行测试、观察错误、做修复、再次验证。

这意味着基础设施不再只是”承载平台”，而是任务的一部分。资源 headroom、磁盘速度、网络抖动、依赖缓存、进程限制，这些全都可能改变任务走向。

你甚至可以说：在 agent benchmark 里，基础设施不是幕后布景，而是半个裁判。

二、为什么小分差尤其值得警惕：你很可能在比较两种环境，不只是比较两个 agent

文章最刺痛人的地方，是它提醒我们：一些看起来很有说服力的小分差，可能根本不足以支持外界常见的强叙事。

比如大家最喜欢的说法：A 比 B 强 2 分所以能力领先、新版本比旧版本涨 1.8 分说明策略优化有效、某模型在某榜上稳定领先说明其 agent 能力最强。

这些说法并不一定错，但它们的前提是：环境变量已经足够被控制。

而在 agent benchmark 场景里，这个前提经常根本不成立。

资源一紧，infra failure 就多；资源一宽，agent 又会采用更依赖安装、更多尝试、更”重型”的解法。于是同一模型在不同环境里，看起来像是两种能力水平。

这背后的问题不是”环境会影响结果”这么简单，而是：

一旦基础设施变量不透明，分差就不再纯粹属于模型或策略本身。

三、资源 headroom 改变的，不只是稳定性，还会改变解题风格

很多人会把 infra noise 理解成”环境差一点就更容易挂”，这当然成立，但还不够完整。

我觉得文章里真正更深的洞察是：资源配置不只是影响系统会不会崩，它还会影响系统敢不敢、能不能、倾向于选择某类解法。

资源紧时，系统被迫更克制

当内存、时间、网络预算都很紧时，agent 更容易选择：更少安装依赖、更少大规模试探、更倾向直接用标准库或轻量方案、更少做重型中间步骤。

这在某些任务上可能是好事，在另一些任务上却会明显拉低成功率。

资源宽时，系统会更愿意”多做一点”

环境一旦宽松，agent 可能开始：装更多库、试更多路径、做更高成本的检查、走更复杂的组合方案。

这有时让任务更容易成功，但也意味着 benchmark 不再只是在测 reasoning，而是在测这个 runtime 允许 agent 拥有多少操作余裕。

所以资源 headroom 不是一个单纯的稳定性旋钮，它还是策略空间旋钮。这个区别很关键。

四、最容易被低估的不是资源多少，而是资源怎么被执行和杀死

文章里我特别认同的一点，是它没有停在”RAM 有多少""CPU 有多少”这种表面问题，而是进一步指出：执行语义同样重要。

这点特别像分布式系统世界里的经验教训：配置值本身并不说明真实行为，行为取决于这些值是如何被实施的。

同样标称 4GB RAM，不同平台可能表现完全不同。因为背后还有很多细节：是 reservation 还是 hard cap、有没有 burst 空间、OOM 发生时是直接 kill 还是有缓冲、并发任务之间是否争抢、sandbox 是否会对短时峰值特别敏感。

从用户视角看，这些都像”平台细节”；但从 benchmark 视角看，它们直接决定 agent 是否有机会完成任务。

这也是为什么我越来越觉得，一个稍微严肃一点的 agent eval 报告，必须解释的不只是”资源额度”，还包括”资源语义”。否则报告是在提供配置幻觉，不是在提供实验条件。

五、基础设施噪音会怎样污染 benchmark 的解释力

基础设施噪音最糟糕的地方，不是它让结果有波动，而是它会污染解释本身。

一旦噪音没有被显性建模，整个 benchmark 的叙事就会越来越脆弱。你不知道分数变化到底来自模型更强了、策略更好了、环境更松了、集群状态更健康了、高峰时段避开了、并发少了，还是网络更稳了。

而团队、媒体、产品方、甚至研究者，往往又最喜欢从这些分数里提炼宏大结论。

这就出现一种非常典型的行业问题：数据本来只支持”某系统在某条件下表现更好一点”，叙事最后却变成”某模型在 agent 场景绝对领先”。

这种跳跃在静态 benchmark 里就已经存在，在 agent benchmark 里只会更危险。

六、为什么 agent benchmark 需要 disclosure discipline，而不是只要 leaderboard aesthetics

我觉得接下来一两年 agent benchmark 会越来越卷，但真正有价值的，不会只是更漂亮的 leaderboard，而是更严格的 disclosure discipline。

也就是说，不只是给分数，还要给条件。

一个真正可引用、可比较、可复现的 agent benchmark，至少应该披露四类关键信息。

资源层：硬件上限、资源 enforcement 方式、并发配置。

环境层：sandbox 策略、网络条件、外部依赖约束、任务超时策略。

行为层：是否允许额外安装依赖、是否启用缓存。

统计层：评测运行时间窗口、重复运行次数与方差观察。

这些信息看起来枯燥，却决定了 benchmark 是否真的有资格被用来做判断。

否则很多所谓”排行榜”，本质上只是一个可视化得比较漂亮的实验快照。

七、一个成熟的 eval harness，必须能区分失败来源，而不是只统计失败总数

文章里我最认同的另一个隐含方法论，是它推动我们重新看待失败。

在 agent eval 里，失败从来不该只是一个总数。成熟的系统应该关心的是：失败来自哪里。

至少要拆成几类：reasoning failure、planning failure、tool-use failure、environment failure、dependency-install failure、timeout / latency failure、resource-kill failure。

如果不拆，团队就会不断在错误的层上优化。

比如：明明是环境过紧，却在疯狂改 prompt；明明是 tool discoverability 差，却在怀疑模型不够聪明；明明是 benchmark 本身判分方式不稳，却在解释 agent 波动。

一个好的 eval harness，真正的价值不只是”告诉你失败了”，而是”告诉你失败该归到哪一层”。

八、重复实验、时间窗口和置信意识，会成为 agent benchmark 的基本修养

传统静态 benchmark 常常给人一种”跑一次就够了”的幻觉，尤其在输入固定、输出判断相对稳定的场景里，这种习惯还能勉强成立。

但 agent benchmark 不一样。它天然更吃环境和时机，所以我认为未来成熟团队必须建立更强的重复实验意识：同样配置重复跑多次、在不同时间窗口重复跑、观察 variance band 而不只是 best run、把极端值和正常值区分开、对外报告时避免用单次最优结果做故事。

这其实是在把统计常识重新带回工程现场。听起来很基础，但现在大量 benchmark 叙事根本做不到这一点。

九、一个更完整的内部使用流程：把榜单当输入，而不是当结论

如果让我给真正做 agent 的团队一个流程建议，我会把公开 benchmark 的使用顺序写成这样：

第一步：把外部榜单当输入——它帮你缩小候选范围，决定哪些模型、哪些 runtime、哪些 workflow 值得进下一轮验证。

第二步：把自己的真实任务切出来——不要直接复用公开榜单的任务结构，而要选择：自己最常见的任务类型、自己最在意的失败代价、自己最真实的资源约束、自己真正会遇到的环境噪音。

第三步：做本地对照实验——在本地约束下对候选方案做再验证，尤其要关注：成功率、成本、波动、失败原因分布、是否更容易恢复。

第四步：再做决策映射——最后才把实验结果转换成组织动作：是否继续试点、是否值得迁移、是否值得在某条工作流上扩大使用、是否只在特定任务上适用。

这个流程看起来保守，但它会帮团队避开一类非常昂贵的错误：把榜单当结论，而不是当线索。

结语：成熟的 agent benchmark 使用方式，不是拿它代替判断，而是拿它逼自己做更好的判断

如果我要给这篇文章最后留一句最适合收尾的话，那会是：

agent benchmark 最有价值的时候，不是它替你做出了判断，而是它迫使你建立一套比”看榜单下结论”更成熟的判断方法。

我觉得这才是基础设施噪音讨论真正应该导向的地方。它不是让人从此不看 benchmark，而是让人终于知道：什么时候该看、怎么看、看到什么程度就该停下来自己验证。

---

谁应该读这篇

这篇适合下面几类读者：

• 正在搭建或引用 agent benchmark 的工程/研究团队
• 想把 agent eval 做成可复现系统实验的人
• 经常看 leaderboard 并据此做判断的技术负责人
• 在做 sandbox、runtime、benchmark infra 的平台团队
• 对”为什么相同 agent 在不同环境表现差这么多”有强烈疑问的人