理解 Agent 评估中的基础设施噪声：区分代码错误、环境故障与资源约束，分析 CPU、内存和时间预算怎样影响执行，再用对照实验与完整报告解释分数差异。
上一篇讨论了测试题能不能提供有效区分。题目有区分度之后，还需要确认另一件事：测出来的差异，究竟来自 Agent，还是来自运行条件？
假设两个 Coding Agent 的通过率分别是 61% 和 63%。只看分数，后者似乎更强；但如果前者经常遇到容器退出，后者拥有更多内存和更宽松的超时，两个数字就不能直接解释为模型能力的差距。
Anthropic 的《Quantifying infrastructure noise in agentic coding evals》用资源配置实验讨论了这个问题。沿着它提出的测量问题，本文分三个层次整理：
- 失败归因： 区分 Agent 的判断错误、环境故障，以及策略与资源预算之间的关系。
- 运行条件： 理解资源分配、限制方式、时间与并发怎样改变执行过程。
- 实验比较： 怎样控制变量、处理重复运行和异常，报告可以解释的结果。
下面用一个自拟的代码修复任务贯穿说明：修复项目中的 CSV 解析问题，并运行测试确认修改。场景与配置例子用于解释机制，不是实际跑出的 Benchmark 成绩。
一、评估分数与失败怎样归因h2
Coding Agent 不只交出一段答案。它会读取项目、安装依赖、修改文件、启动测试，再依据输出继续行动。环境参与了这条执行链，也就参与了最终结果。
1. 测量对象：模型能力与端到端表现h3
同一个模型，配上不同工具、指令和运行环境，可能得到不同成绩。因此首先要明确，比较的对象是什么。
如果要比较两个模型在相同条件下的解题能力，Harness、任务、工具和资源预算就应该尽量一致。否则，换模型的同时也换了工作条件，很难知道差异由谁带来。
如果要比较两套完整 Agent 系统的实际表现，不同的 Harness 或资源安排可以是方案的一部分。例如，一套系统用更好的缓存降低安装开销，这本身有工程价值。但结论应当是“这套系统在这组条件下表现更好”，而不是直接归为“模型更聪明”。
回到 CSV 修复任务：成功意味着最终代码通过约定的检查。模型是否找对原因、执行环境是否跑得动测试、评分程序是否拿到完整结果，都会影响这一次成功能否发生。成绩可以评价整个执行链；要解释某个组件，就需要进一步控制其他组件。
2. 失败分类：能力错误、环境故障与资源约束h3
看到一个失败记录，先找导致任务中断的证据，再决定归类。
| 任务中的现象 | 初步判断 | 需要继续确认什么 |
|---|---|---|
| Agent 把带引号的分隔符也当成列边界 | 代码或判断错误 | 测试输入、修改内容和实际输出 |
| 工作容器没有启动，Agent 尚未获得项目 | 环境故障 | 调度、镜像和启动日志 |
| Agent 启动大量并行测试后内存不足 | 策略与预算共同作用 | 资源限制、进程峰值和任务约定 |
| 测试超时，只有一条退出记录 | 暂时无法归因 | 程序是否死循环、CPU 是否受限、等待发生在哪里 |
第三类尤其重要。资源相关错误并不天然独立于 Agent：无节制地创建子进程可能是策略问题；正常步骤因宿主机故障被打断，则是另一回事。只有一个 OOM 或 timeout 标签，证据还不够。
归因也不必强行二选一。可以先记录“内存限制下终止”，再标注已确认的原因与未知部分。这样既保留了任务未完成的事实，也没有把不确定的原因写成模型缺陷。
二、资源与运行条件怎样影响结果h2
运行条件有两种作用：一是让相同工作能否稳定完成，二是决定哪些工作方式实际可行。前者关系到测量噪声，后者关系到测试本身的难度和范围。
3. Requests 与 Limits：资源分配和限制方式h3
“给容器 2 个 CPU、4 GiB 内存”还不够明确。这些数字是调度时申请的资源，还是运行时不允许超过的上限？
以 Kubernetes 为例，requests 主要参与调度和资源分配；节点有可用资源时，容器的实际使用量可以超过 request。limits 则限制运行时使用：CPU 通常通过节流限制执行速度，内存限制在压力下可能触发 OOM 终止。不能把 CPU 超限也统一理解为立即杀死进程。 具体语义见 Kubernetes 资源管理文档。
例如，下面是解释两者区别的配置片段，不是通用的评估推荐值：
resources: requests: cpu: "2" memory: "4Gi" limits: cpu: "4" memory: "8Gi"申请量与上限之间留出了空间，但这不意味着容器始终独占 4 个 CPU，也不保证每次都能获得相同的额外资源。宿主机负载与资源竞争仍然需要关注。
所以，复现一场评估，既要记录配置数字，也要记录这些数字怎样被执行。相同的名义配置，不一定对应相同的运行条件。
4. Resource Headroom：运行稳定性与策略空间h3
Headroom 是基础分配之外允许使用的资源余量。它为什么会影响通过率，可以沿着两个方向看。
第一种影响是减少意外中断。 修复方案和测试步骤没有变化，只是依赖安装或测试启动的短暂峰值不再导致终止。这时更多执行记录能够完整结束，但不代表这些记录最后都会通过。
第二种影响是改变可用策略。 原本跑不动的大型依赖、全量分析或并行测试，现在可以运行了。Agent 获得的不只是稳定性，还获得了不同的解题空间。
Anthropic 在 Terminal-Bench 2.0 上固定模型、Harness 和任务，比较了六种资源配置：最严格到不设上限的成功率相差约 6 个百分点。基础设施错误率从 1x 的 5.8%，降到 3x 的 2.1%，再降到无上限时的 0.5%。但 1x 到 3x 的成功率差异未达到统计显著；3x 到无上限的成功率却又提高了约 4 个百分点。错误率下降和成功率上升，不是一一对应的关系。 这些数字及其范围来自原文实验，3x 不是适用于所有任务的标准配置。
在 CSV 场景里，小规模测试可能用标准库就足够；Agent 也可能安装较重的数据处理依赖，再加载完整数据集验证。不同预算下，后一条路线未必都可行。如果测试本来就要求低内存运行，那么资源效率是被测能力的一部分，不能把失败一律当作噪声消除。
5. 时间、并发与网络：执行预算的其他条件h3
相同的内存上限，还不能保证相同的完成机会。
假设任务有固定的总时限。Agent 先等待依赖下载，再等待模型响应，最后才启动测试。等待时间变长，留给实际调试的时间就变少了；即使没有出现显式网络错误，结果也可能受影响。
时间预算因此要说明计时边界：从容器启动，还是从 Agent 接到任务开始？是否包含初始化、排队、工具等待和重试？只写“十分钟”，读者无法判断两次运行是否真的等价。
并发也有类似问题。同一台机器上同时运行更多任务，可能带来 CPU、磁盘和网络竞争。一次独占运行与一次高并发运行，就算容器配置相同，也可能面对不同的实际吞吐。
这些因素不是要求评估拥有完美环境，而是提醒我们：环境条件需要成为实验记录的一部分，而不是分数出来之后才寻找的解释。
三、怎样比较实验并报告可信结果h2
把环境影响列出来之后，下一步不是一味增加资源，而是让比较对象、控制条件和结论对应起来。
6. 对照实验：固定条件与校准资源h3
比较模型版本时，尽量保持任务、项目快照、工具、Harness、评分规则和运行预算一致。研究资源影响时，则固定模型与其他设置，只调整明确的资源变量。
仍以 CSV 修复为例，可以先检查项目在指定配置下能否正常安装、启动和运行既有测试，再观察 Agent 执行时的峰值、错误类型与轨迹。这能帮助区分“基础环境就无法工作”和“Agent 选择了一条过重路线”。基线跑通并不保证所有路线都跑得通，但能排除一部分明显的配置问题。
需要校准余量时，小步调整并同时观察两类结果：意外终止是否减少，以及策略与成功率是否发生变化。若测试已经允许完全不同的重型路线，就不能只把变化描述成“修复了环境噪声”。
资源更宽松不一定不公平，资源更严格也不一定更科学。关键是预算是否符合测量目标，两个方案是否在约定条件下接受比较。
7. 重复运行：随机波动与系统偏差h3
同一个任务多跑几次，可以观察 Agent 的随机性与偶发运行异常；把运行分布到不同批次，也能减少某一次服务波动主导结果的风险。
但重复运行不能自动解决系统性差异。如果 A 始终在较小内存下运行，B 始终拥有更多资源，重复一百次只会更稳定地测出这两套条件的差别，不会把它变成纯模型比较。
比较时应保留每个任务、每次 Trial 的结果，尽量让两个方案经历相近的运行批次和负载条件，再看总体差异与任务级变化。只对失败的一方无限重跑，直到它通过，测到的就不再是原来约定的单次表现。
统计区间可以反映所用方法覆盖的抽样不确定性，不会自动包含未控制的环境偏差。因此，“多跑几次”与“控制运行条件”是互补关系，不能互相代替。
8. 异常处理：失败分类、重跑与分母h3
环境异常怎么处理，应当在看到成绩之前确定，而不是为了某个结果临时调整。
例如，容器尚未启动就遇到已确认的宿主机故障，可以按预先约定重跑；Agent 已经修改项目后再重跑，则还需要恢复初始快照，避免继承前一次留下的文件或缓存优势。原始失败、重跑原因和重跑结果都应保留。
如果报告排除了某些运行，至少同时交代：总共尝试多少次、排除了多少次、排除依据是什么，以及哪些失败仍然计入成绩。不同分母的通过率不能悄悄当成同一个指标比较。
同样，环境错误减少 3 个百分点，不意味着成功率应该补回 3 个百分点。被打断的任务继续运行之后，仍然可能解错。不能用错误率给最终分数直接做加法修正。
9. 结果报告：把成绩与实验条件一起交付h3
一份便于复核的结果，可以把下面几组信息与成绩放在一起：
- 被测方案： 模型版本、指令、工具与 Harness 版本。
- 任务与判分： 任务集版本、初始项目状态、Grader 与成功标准。
- 运行预算： CPU、内存、申请量和上限、超时计时规则、并发与网络条件。
- 执行记录： Trial 数量、运行批次、错误分类、排除和重跑策略。
- 比较结果： 通过率、任务级变化，以及统计方法对应的不确定性。
这不是为了给每个分数附上一份运维手册，而是保留影响判断的条件。读者应当知道，自己看到的是同一预算下的模型比较，还是不同资源成本下的系统比较。
于是，面对开头的 61% 与 63%，可以先核对条件，再看差异是否稳定、集中在哪些任务、有没有对应的执行证据。不能仅凭两个百分点就确认优势，也不能反过来规定“小于某个数的差异都无效”。分差的意义来自实验条件与证据，不来自一个脱离任务的固定门槛。
几个关键问题，串起失败归因与实验比较h2
任务因为 OOM 失败，就能排除为基础设施问题吗？
不能。需要看内存限制、使用峰值、执行步骤，以及任务是否本来就要求资源效率。正常运行被异常打断，与 Agent 选择了超出预算的策略，是不同情况；证据不足时应保留不确定归因。
环境错误率下降，为什么通过率不一定等幅上升？
减少中断只让任务有机会完整结束，不保证解题正确。一部分被恢复的运行最后仍会失败。因此错误率与成功率应分别报告，不能直接相加或互相抵扣。
为什么给两个模型写上相同的 CPU、内存数字，还不够？
数字可能分别指申请量和上限，执行方式也可能不同。CPU 节流、内存终止、宿主机竞争与并发负载都会影响实际运行。需要比较配置含义和执行条件，而不只是名义规格。
增加资源是在去除噪声，还是改变考试？
两种情况都有可能。如果相同路线只是少了意外中断，主要改善的是稳定性；如果大型依赖、重型测试或并行探索因此可行，策略空间也变了。判断时要结合轨迹和资源使用，而不只看分数。
把评估多跑几遍，能解决环境不公平吗？
不能。重复运行有助于观察随机波动，但不会消除始终存在的预算差异。比较模型时需要控制环境；比较完整系统时则应把环境配置与成本一起报告。
面对一个小幅领先，应该怎样下结论？
先确认测量对象和运行条件是否匹配，再检查样本、重复结果、错误分类与任务级变化。证据支持到哪里，结论就写到哪里：在特定配置下表现更好，不自动等于在所有环境下都更强。