Agentic Coding 评估：先控制基础设施噪声，再判断模型退步

同一道任务昨天通过，今天超时，能直接宣布模型退步了吗？跑分变化不自动等于模型能力变化。 Anthropic 在 2026 年 2 月的基础设施噪声研究中分析了运行资源对 Agentic Coding 评估的影响。以下是自行设计的故障推演，重点是解释结果变化，不是复现论文。

把运行环境当作实验变量

把运行环境当实验的一部分记录：模型版本、工具、仓库状态、依赖是否可用、时间预算、并发和网络策略。缺少这些信息，分数就无法迁移。同一个模型换一个 harness，成功机会可能完全不同。

分开记录不同失败原因

按真正的停止原因记录失败：补丁错误、测试失败、超时、抢占、缺依赖或 harness 错误。不要把所有非通过都归为“模型质量”。无论复盘 take-home 还是现场回答，这个区分都很有用。

说明结论的可复现边界

用小样本重跑并报告波动，明确哪些变量没有控制。可信的回答可以说结论只是方向性证据，而不是假装做出了完美因果实验。

跑分跌了，先别增加重试次数

假设夜间评估在迁移 runner 后下降，模型名称和题集看起来都没变。最直接的反应是多重试几次，直到分数恢复。但新运行获得了更多机会，已经不是和原来相同的实验，反而可能掩盖真实问题。

先选一个失败任务，对比仓库提交、容器镜像、CPU 和内存限制、测试超时、并发以及依赖缓存。同时核实实际模型参数；公开名称相同，不代表所有配置都没变。缺失的信息要记为未知，不能默认一致。

补丁错误和执行受阻要分开定位

补丁错误要指出违反了哪个断言；超时要记录当时执行什么操作、是否还在推进；缺依赖要确认本来是否允许联网。这几类假设对应不同修复方式，不能统一归因于“模型不聪明”。

如果任务本来要求离线，Agent 却依赖在线下载，那是任务失败。如果环境误关了本该可用的包镜像，则是另一个测量问题。环境失败仍要保留在端到端结果中，分类不是把不好看的样本从分母里删除。

如何设计能改变结论的对照？

固定 Agent 配置和环境重置方法，让同一任务分别在旧资源配置与新资源配置下运行。可以交替执行顺序，避免服务负载的时间变化恰好与某一组重合。适当重复以观察波动，并报告样本量，不要把几次运行包装成确定结论。

如果只在旧内存限制下通过，结论是资源变化影响了这个负载。它不证明模型在其他任务上都正确，也不证明增加资源一定划算。生产决策前还需扩展到有代表性的样本。

保留两类视角：用户是否完成任务，以及失败发生在哪一层。用户看到的仍然是失败，拆分原因则帮助团队决定应该修模型生成、依赖准备还是资源分配。

面试结尾可以落到决策：“发布比较先恢复可比的 runner，所有失败仍进入报告，资源敏感案例另做对照。”这比笼统要求更多算力更有价值。好的运行记录应让下一个实验更小，让结论更明确。

2026 年的 benchmark 讨论，必须把有效性算进去

Anthropic 的 infrastructure noise 分析说明，资源限制既会影响稳定性，也会改变 Agent 能解决什么问题。OpenAI 对 SWE-bench 的复核则提醒，任务或标签发生问题时，benchmark 可能已经不能测量原本想测的能力。因此分数是带配置的测量结果，不是模型脱离环境后的固定属性。

至少记录这些变量：