量化 agentic eval 里的「基础设施噪声」：榜单上几分的领先，可能只是一台更大的虚拟机
SWE-bench、Terminal-Bench 这类 agentic 编码基准，常被用来比较前沿模型的软件工程能力——而榜首之间往往只差几个百分点。这些分数被当成「相对能力的精确测量」，越来越多地左右着「该部署哪个模型」的决定。但我们发现：仅仅是基础设施配置，就能造成超过这点差距的分数差异。 在内部实验里，Terminal-Bench 2.0 上「资源最足」与「资源最紧」两种配置相差 6 个百分点（p < 0.01）。
为什么 agentic eval 不一样
静态基准直接给模型的输出打分——运行时环境不进入结果。agentic 编码 eval 不同：模型拿到一个完整环境，在里面写程序、跑测试、装依赖、多轮迭代。运行时不再是个被动的容器，而是解题过程的有机组成部分。 两个资源预算和时限不同的 agent，根本不是在考同一张卷子。
eval 开发者已经开始考虑这点。比如 Terminal-Bench 2.0 在最新版里按任务给出了推荐的 CPU 和 RAM。但是——「指定资源」不等于「一致地强制执行」。更要紧的是，我们发现执行方法本身，会改变这个 benchmark 最终到底在测什么。
我们是怎么撞上这事的
我们在 Google Kubernetes Engine（GKE）集群上跑 Terminal-Bench 2.0。校准时发现我们的分数和官方榜对不上，而且 infra 错误率高得惊人：多达 6% 的任务因 pod 错误而失败，其中大多数与模型解不解得了题毫无关系。
分数对不上，根子在执行方式。我们的 K8s 实现把「每任务资源规格」既当下限又当硬上限：每个容器保证拿到指定资源，但一超过就立刻被杀。容器运行时其实用两个独立参数来管资源：
| 参数 | 含义 |
|---|---|
| 保证分配（guaranteed allocation） | 预先预留的资源 |
| 硬限制（hard limit） | 一旦触及就杀掉容器 |
⭐ 当这两个值设成一样时，瞬时尖峰就零余量：一次瞬时的内存波动，会把一个本来能成功的容器 OOM-kill 掉。Terminal-Bench 官方榜用的是另一个 sandbox 提供商，实现更宽松——允许临时超分配而不杀容器，以偏向基础设施的稳定性。
这引出一个更大的问题：资源配置到底对评估分数影响多大？
实验：六种资源配置
为量化脚手架的影响，我们在 Terminal-Bench 2.0 上跑了六种资源配置——从严格执行每任务规格（1x，既当下限又当上限），到完全不设上限。其余全部不变：同一个 Claude 模型、同一个 harness、同一套任务集。
结果：成功率随资源余量增加而上升。 主要驱动力是 infra 错误率单调下降——从严格执行的 5.8% 降到不设上限的 0.5%。严格执行→3x 余量这一段（5.8% → 2.1%）在 p < 0.001 上显著。
但细看有个拐点：
| 区间 | 发生了什么 |
|---|---|
| 1x → 3x | 成功分数在噪声范围内波动（p=0.40）。1x 时崩掉的任务，大多本来也会失败——agent 探索、撞上资源墙、被抢占，但它本就不在通往正确解的路上 |
| 3x → 不设上限 | 趋势变了：成功率涨得比 infra 错误降得更快。infra 错误再降 1.6 个百分点，成功却跳了近 4 个百分点。额外资源让 agent 能尝试「只有在慷慨分配下才行得通」的办法——拉进大依赖、生成昂贵子进程、跑内存密集的测试套件 |
不设上限时，相对 1x 的总提升达 +6 个百分点（p < 0.01）。
这如何影响「测量」本身
- 到约 3x 为止：额外资源修的是基础设施可靠性（瞬时资源尖峰）。Terminal-Bench 维护者用的那个 sandbox 提供商，其实是在幕后隐式地做这件事——eval 变稳了，但没变简单。
- 3x 以上：额外资源开始实际帮 agent 解出之前解不了的问题。这说明——资源限制会改变 eval 测的东西。紧限制无意中奖励高效策略，慷慨限制更宽容、奖励能榨干所有可用资源的 agent。
⭐ 一个写精简、高效、快代码的 agent，在紧约束下表现好;一个用重型工具暴力解题的 agent，在慷慨约束下表现好。两者都是值得测的合理对象，但把它们压成一个不标注资源配置的单一分数，就让差异——以及对真实世界的泛化性——变得难以解读。
具体例子（bn-fit-modify，一道贝叶斯网络拟合任务）：有些模型第一步就去装标准 Python 数据科学栈——pandas、networkx、scikit-learn 及整条工具链。慷慨限制下，行;紧限制下，pod 在安装阶段就内存耗尽，agent 还没写一行解题代码就挂了。其实存在一个更精简的策略（只用标准库从头实现数学），有些模型默认就这么做，有些不会。不同模型默认方法不同，而资源配置决定了哪种方法恰好成功。
我们在不同 Anthropic 模型上复现了核心发现：效应方向一致，幅度不同。我们还跨到 Terminal-Bench 之外做了交叉验证——在 SWE-bench 上，227 道题各 10 个样本、RAM 最多调到 5x：同样的效应成立，但幅度更小，5x 仅比 1x 高 1.54 个百分点（SWE-bench 任务资源密集度更低，效应小符合预期）。但它表明，资源分配在那里也不是中性的。
其他方差来源
资源分配不是唯一的隐藏变量。某些配置下，时间限制也开始起作用。
原则上，评估设置的每个元素都可能影响最终分数：集群健康、硬件规格、并发级别，乃至出口带宽。agentic eval 在构造上就是端到端的系统测试，系统里任何一个组件都可能成为混杂因子。 我们就轶事性地观察到 pass 率会随时段波动，大概是因为 API 延迟随流量和故障而变。这说明一个更大的道理：「模型能力」和「基础设施行为」之间的边界，比一个 benchmark 分数所暗示的要模糊得多。 模型提供方可以靠专用硬件屏蔽这种影响，外部评估者却很难做到。
公开基准本意是测纯粹的模型能力，实践中却有把它和基础设施怪癖混为一谈的风险。对要公开分享的编码 eval，在多个时段、多天反复跑有助于把噪声平均掉。
我们的建议
理想情况是：在完全相同的硬件条件（既包括跑 eval 的脚手架、也包括推理栈）下跑每个 eval，以保证完美可复现。但这未必总是可行。
鉴于容器运行时用「保证分配 + 独立的硬杀阈值」两个参数来管资源，我们建议 eval 按任务同时指定这两个参数，而不是一个钉死的值：
- 单个精确规格 = 把保证分配和杀阈值设成相等 = 零余量，我们记录到的 1x 瞬时内存尖峰就足以搞乱 eval;
- 把两个参数分开，既给容器足够的喘息空间避免假性 OOM、又保留一个防止分数虚高的硬上限。
两者之间的带宽应校准到「下限和上限的分数落在彼此的噪声范围内」。例如 Terminal-Bench 2.0 里，3x 上限把 infra 错误率砍掉约三分之二（5.8% → 2.1%，p < 0.001），同时分数提升很小、稳稳落在噪声内（p=0.40）——这是个合理权衡：基础设施这个混杂因子被大体中和，又没把有意义的资源压力去掉。具体倍数因 benchmark 和任务分布而异，应当报告出来，但「经验校准」这个原则是通用的。
为什么我们在意
这些发现有超出 eval 基础设施的现实后果。benchmark 分数越来越多地被当作决策输入，但这份关注（和依赖）并没有伴随相应严谨的「怎么跑、怎么报」。就现状而言，榜单上领先 2 分可能反映真实能力差异，也可能只是因为一个 eval 跑在更强的硬件上、甚至更幸运的时段——或者两者皆有。没有公开（或标准化）的配置，外人很难分辨。
⭐ 在资源方法标准化之前，我们的数据表明：榜单上低于 3 个百分点的差距，在 eval 配置被记录并对齐之前，都值得怀疑。 朴素的二项置信区间本就横跨 1~2 个百分点;我们记录的基础设施混杂因子是叠加在它之上，而非包含其中。在资源分配范围的极端处，这个跨度能达到 6。
榜单上几分的领先，可能标示着真实的能力差距——也可能只是一台更大的虚拟机。