量化 agentic coding eval 中的基础设施噪声

导读

本文聚焦 agentic coding eval 的基础设施噪声：测试 flaky、依赖失败、沙箱差异和超时会污染模型能力测量，需要被记录、复现和量化。

说明：本文按 Agent Learning 的中文阅读页格式，对原文结构与关键技术细节做逐节中文转述与解读；为避免整篇镜像转载，正文保留原文章节脉络、关键数字和术语，但不做逐字复刻。

核心观点

• agentic coding eval 不只测模型，还测 sandbox、依赖、测试、网络和任务 harness。
• 同一个 patch 可能因 flaky test 或环境差异得到不同结果。
• 基础设施噪声会掩盖小模型差异，也会让 leaderboard 产生虚假波动。
• 应区分模型错误、工具错误、环境错误、测试错误和判分错误。
• 重复运行、种子控制、环境快照和 failure taxonomy 是量化噪声的基础。
• 评测报告应披露 timeout、retry、依赖安装失败率和 flaky test 处理策略。
• 对 coding agent 来说，能否诊断基础设施问题本身也是能力的一部分。
• 可靠 eval 需要可复现容器、稳定数据集和端到端 trace。

正文

原文主线

本文聚焦 agentic coding eval 的基础设施噪声：测试 flaky、依赖失败、沙箱差异和超时会污染模型能力测量，需要被记录、复现和量化。

噪声来自哪里

agentic coding eval 看起来是在测模型修 bug 或实现功能，但实际链路很长：仓库 checkout、依赖安装、测试运行、shell 工具、沙箱限制、网络状态、时间限制、判分脚本都会影响最终结果。任何一个环节不稳定，分数就会混入基础设施噪声。

这种噪声和传统 benchmark 不同。选择题或文本生成评测通常输入输出较短，而 coding eval 会执行代码。执行就意味着环境，环境就意味着不确定性。

为什么必须量化

如果两个模型分数只差 1-2 个百分点，而基础设施噪声本身就有类似幅度，那么我们很难说哪一个真正更强。更糟的是，优化 harness 或测试策略可能带来分数提升，却被误认为模型能力提升。

量化噪声的目的不是追求完美无噪声，而是让评估者知道不确定性范围。一个可信报告应该能说清：有多少任务失败于依赖安装，有多少失败于 timeout，有多少在重复运行中不稳定。

如何测量

第一步是分类。失败至少应分为模型行为错误、工具调用错误、环境错误、测试错误、判分错误。第二步是重复运行同一配置，观察结果方差。第三步是固定环境快照，让任务尽量在相同依赖和系统状态下执行。

trace 也很重要。完整日志能显示 agent 是否真的写了错误代码，还是因为下载依赖失败、测试 flaky、权限不足或命令超时而被判失败。没有 trace，噪声只能被猜测。

对 agent 设计的反作用

有趣的是，基础设施问题不一定只是评测污染。在真实开发中，agent 也会遇到 flaky test 和环境错误。优秀 coding agent 应能识别这些情况：重跑测试、缩小失败范围、检查依赖、向用户说明不确定性，而不是盲目修改代码。

因此，eval harness 既要控制噪声，也可以专门设计基础设施鲁棒性任务，评估 agent 是否会处理不可靠环境。

深度解读

这篇主题指出了 agentic coding 评测最容易被忽略的事实：我们测的不是一个纯模型，而是模型加工具加环境组成的系统。只报告 pass rate 会把复杂失败压成单个数字，隐藏了系统层面的不确定性。对工程团队而言，真正有用的 eval 应该像生产可观测性一样：分层、可追踪、可复现、可解释。否则你以为自己在提升模型，实际可能只是调顺了测试环境。

落地启示

• 给 eval 失败建立 taxonomy，至少区分模型、工具、环境、测试和判分错误。
• 对代表性任务做重复运行，观察方差而不是只看单次结果。
• 固定容器、依赖和系统快照，降低不可解释波动。
• 保存完整 trace，让每次失败能被复盘。
• 把历史 flaky case 纳入回归集，防止环境问题被反复误判为模型问题。