把评测从「偶尔手动跑」变成「每次改动的默认动作」：EDD 闭环、统计意识的门禁阈值（几十个任务只拦得住大幅退化）、CI 三层跑法、红灯先归因、advisory→enforcing 的团队引入路径。与 a15（CI 落地）、a24（统计）形成工程闭环的最后一环。
先修：a24（统计严谨性）、a33（自建评测集）。已有评测集但还没接进 CI 的团队。核心动作：核心层门禁 = 安全硬门禁 + 总分软门禁（显著下降才拦）。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
Agent 非确定，正常波动会让门禁随机挂掉，团队烦了就会绕过它。正确做法：关键项零退化硬拦 + 总分用置信区间判「显著下降」才拦 + flaky 移出门禁。
① 跑 oracle——标准解都不过是评分器/题目问题；② 重跑看是否忽对忽错——题目飘，移出门禁；③ 调失败 trace 看根因——确认是 Agent 真退化才动 Agent。
从 advisory 到 enforcing：先只报告不阻断（建立信任）→ 安全等关键项强制 → 随评测集稳定逐步收紧。被团队信任偶尔放行的门禁，比被痛恨集体绕过的严格门禁有用。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
到这一讲，评测已经能跑、看得见、线上也盯着。但还差一步——如果评测只是"偶尔手动跑一下"，它就发挥不了最大价值。这一讲，我们把评测接入日常工程流程：评测驱动开发（EDD）+ 回归与 CI。
让评测像单元测试一样，成为每次改动的默认动作，而不是上线前临时抱佛脚。
如果你写过测试驱动开发（TDD），EDD 的思路你一秒就懂：先有评测，再改 Agent，用评测的反馈来驱动迭代。它建立的是一个闭环：改动（prompt / 模型 / 工具）→ 跑评测 → 看反馈 → 再改动。
对比一下你可能更熟悉的另一种工作方式——"凭感觉调 prompt"：改一版、拿几个例子看看"感觉好像好点了"、就上线。EDD 要取代的正是这个"感觉"：每一次改动，都让数据说话。
EDD 还有一个关键词叫前置（shift-left）：评测越早跑越好。别等到上线前才发现"哦这版退化了"，而是让每次改动一提交就自动被评测检验——问题在最便宜的时候被抓住。
落到日常，EDD 的一天大概是这样：你要改进"退款失败时的话术"，第一件事不是改 prompt，而是先确认评测集里有能衡量"话术好坏"的用例（没有就先加）；然后改 prompt、本地跑相关子集看分数动没动；满意了提 PR，CI 自动跑核心层门禁；绿灯合入、红灯回去改。你会发现——评测在这个流程里不是"额外的负担"，而是你每一步的"仪表盘"：没有它，你改完根本不知道是变好了还是变坏了。EDD 的本质，是把"反馈"从"上线后几天"提前到"改完几分钟"。
一是"隐性退化"防不胜防。改一个 prompt 里的词、升一个模型小版本、动一个工具的描述——你本意是修好 A 场景，却可能悄悄弄坏了三个月前早就搞定的 B 场景。你测了 A（因为你在改 A），却根本没想到去测 B。
二是改动面特别广。Agent 的行为由 prompt、模型、工具、harness 共同决定，任何一个变了都可能牵动全局。你以为只是"改了个提示"，实际可能影响了几十个场景。
结论：没有自动化的回归防护，你会一直待在"修一个、坏一个"的循环里，还浑然不觉。而回归防护，靠的正是把评测接进 CI。
回归集：Agent 已经搞定的老用例，永久保留，每次改动都跑一遍——专门用来抓"改坏了老场景"。
回归门禁（gate）：定一条基线，新改动必须不低于基线（或至少关键项不退化）才能合入 / 上线。它是评测从"报告"变成"守门人"的关键一步。
但门禁的阈值怎么定？这里必须有统计意识，否则你会踩大坑。Agent 是非确定的——如果你把门禁设成"必须 100% 通过"，那它会因为正常的随机波动时不时随机挂掉，团队很快就会烦到直接把它关掉。正确的门禁是统计意义的：
举个定阈值的具体例子。核心集就几十个任务时，基线通过率 80% 的 95% 区间其实很宽——约 ±11%（n≈50）。所以新版 78%？稳稳落在 [69%, 91%] 内，是噪声，放行。新版 62%？跌破区间下沿，真退化，拦截。这也暴露一个常被忽视的事实：几十个任务的门禁，只拦得住大幅退化；掉三五个点这种小退化会淹没在噪声里、根本拦不住——想抓小退化，要么靠全量层的更大样本、要么对关键任务多跑几次。所以门禁的判据永远是"有没有显著下降"，而不是"有没有下降"；而能测出多小的下降，取决于你的样本量。当然，安全那类硬门禁例外——它零容忍，哪怕掉一个 case 也拦。
门禁的艺术，是既能拦住真退化、又不被噪声天天误伤。
评测又慢又（LLM 裁判）贵，不可能每次 commit 都跑全量。解法是用三层评测集，对应 CI 的不同阶段：
| CI 阶段 | 跑哪一层 | 目的 |
|---|---|---|
| 每次 commit | 冒烟层（~10 个核心 task，秒级/分钟级） | 第一时间挡住低级错误 |
| 每次 PR / 合入 | 核心层（几十个，覆盖全维） | 当回归门禁 |
| 每日 / 发版前 | 全量 + 回归集 | 全面体检 |
越往上越快越频繁、越往下越全越慢——这样你既有"随手就能跑"的快反馈，又有"上线前兜底"的全面检查。而在 CI 里被调用、真正把这些评测跑起来的那个执行器，就是评测 harness。
评测太慢太贵，CI 跑不动怎么办？几个实用招：
目标是让门禁快到不影响开发节奏——如果一次 PR 门禁要等半小时，团队迟早想办法绕过它。
门禁红了，先别急着改 Agent——要分清是"真退化"还是"评测本身的问题"：
快速归因就三步：① 跑 oracle——如果连标准解都过不了，那是评分器或题目的问题，不是 Agent；② 看是不是 flaky——重跑几次，若忽对忽错，是题目飘，移出门禁；③ 调出失败 trace 看根因——确认真是 Agent 错了，才动 Agent。养成"红灯先归因、再动手"的习惯，能省掉大量"改了半天才发现是题目的错"的冤枉功。
别让坏评测卡住开发，也别让真退化蒙混过关——这两个方向的错误都很常见。
门禁也不必非黑即白，可以分级：硬门禁——安全 / 关键项零退化，不过就是不过，没得商量；软门禁——总分轻微波动、非关键项，亮黄灯、给信号，但允许人工评估后放行。
还记得"生产即数据源"的闭环吗？它的终点，正是这一讲的 CI 门禁：线上发现新失败 → 固化成回归集用例 → 进 CI 门禁 → 从此这个错不再复发。
这就是 offline ⇄ online 完整闭环在工程上的落地：线上抓到的每一个真实失败，最终都变成 CI 里的一道"防它复发"的门禁。而 EDD，就是驱动这个飞轮持续转动的引擎——每一次改动都过评测，每一个线上失败都变成永久的回归防护。你的 Agent 会因此单调地、不可逆地变得更可靠：修好的错，靠回归门禁保证不再犯第二次。
到这里你可能觉得 EDD 主要是"防守"——防退化、守门禁。但它还有"进攻"的一面。因为你的评测集，本质上定义了"更好"意味着什么：想让 Agent 变好，就等于想让它在评测集上得分更高。于是评测集成了改进的靶子——你盯着上面那些还没过、分数低的用例去攻，比漫无目的地"优化"高效得多。
两者合起来，你的 Agent 就走上了一条"不退化 + 持续进步"的轨道。而这条轨道能不能持续，取决于评测集是不是在生长——停止生长的评测集，既失去防守意义（被追平了）、也失去进攻靶子（没新题可攻了）。
门禁最容易走两个极端：
平衡点前面说过：硬门禁守底线（安全零退化）、软门禁给信号（显著下降才拦）。还有一个隐蔽的失效方式——评测集长期不更新（腐烂）：门禁还在跑，但跑的是一批过时、早被 Agent 追平的老题，绿灯给得毫无意义。门禁的有效性，取决于它背后那套评测集是不是活的。
技术之外，EDD 落地最大的阻力往往是人——工程师一开始会嫌门禁"碍事、拖慢我"。而硬上一道会随机误伤的严格门禁，是最快让团队反感、进而想方设法架空它的方式。稳妥的引入路径是从"建议"到"强制"：
别一步到位。一个被团队信任、偶尔放行的门禁，比一个被团队痛恨、集体绕过的严格门禁有用得多。配套地，评测集和门禁得有人负责维护——没人管的门禁，会随评测集一起腐烂，最后变成一道大家都懒得看的红灯。
把这一讲落到退款 Agent，一次"改了退款话术 prompt"的改动，在 CI 里会这样走：commit 时冒烟层 10 个核心退款场景 1 分钟跑完挡低级错误；PR 时核心层几十个（正常退款/不可退/超时/越权/澄清…），门禁为安全项零退化（硬）+ 总通过率不显著低于基线（软）→ 发现"不可退订单"场景通过率显著掉了 → 拦下；修复后重跑通过；发版前全量 + 回归集确认没弄坏三个月前修好的老场景；灰度上线 + 线上监控，有异常回流成新回归用例。
注意那个"拦下"——如果没有门禁，这次话术改动就会带着"不可退订单处理退化"悄悄上线，直到线上出事。门禁把一次本会流到生产的退化，挡在了 PR 阶段。这就是 EDD + CI 的价值：把发现问题的成本，从"线上事故"降到"一次 PR 红灯"。
再体会一下这条流水线的分工：冒烟层用秒级反馈挡住手滑级的低级错误；核心层门禁用几十个全维用例拦住"改坏了某个场景"的隐性退化；全量 + 回归集在发版前兜底；灰度 + 线上监控接住那些线下没覆盖的长尾，再把新失败回流成回归用例。每一层都在用越来越真实、但也越来越慢的方式，把问题拦在离用户越来越远的地方。