这是系列的最后一篇，做三件事：把前六篇里散落的坑集中起来；给出一条团队从零开始搭建评测的路线；讨论评测之后的下一步，也就是让评测结果驱动 Skill 自动迭代。
常见误区
起步阶段
| 误区 | 后果 | 改成 | 见 |
|---|---|---|---|
| 等用例攒够了再开始 | 越晚建，越只能从运行中的系统反推成功标准 | 用 20 到 50 条真实失败起步 | 第 05 篇 |
| 先搭一个大而全的平台 | 平台搭好了，用例和评分器还是空的 | 先用脚本跑通，再选一个合适的框架，精力放在用例和评分器上 | 本篇 |
| 只定义“任务完成” | 超时、超成本、越权的执行被算作成功 | 按六个维度定义成功，安全合规一票否决 | 第 01 篇 |
执行阶段
| 误区 | 后果 | 改成 | 见 |
|---|---|---|---|
| 每条用例只跑一次 | 把随机波动当成能力 | 每条执行 n 次，看 pass^k | 第 02 篇 |
| 只看 Agent 的回复 | 虚报完成被判为成功 | 检查终态的两面，单独统计虚报率 | 第 02 篇 |
| 把环境的失败算到 Agent 头上 | 基础设施的波动被当成能力退化 | 沙箱和模型服务的失败作废重跑 | 第 02 篇 |
| 只固定模型 | Harness、其他 Skill、资源配额、运行时段的影响混进结论 | 用运行清单固定全部变量，对照组和实验组交替运行 | 第 01、03、06 篇 |
评分阶段
| 误区 | 后果 | 改成 | 见 |
|---|---|---|---|
| 规定死工具的调用顺序 | 合理的新路径被判为失败 | 只核对关键检查点和禁止动作 | 第 02 篇 |
| 用 1 到 5 分打分 | 标注不一致，需要更大的样本 | 二元判定，拆成多个检查 | 第 04 篇 |
| LLM Judge 不校准 | 研究中，常用评估模型漏掉了一半以上的质量下降 | 人工标注，用 TPR 和 TNR 按维度校准 | 第 04 篇 |
| 不读轨迹 | 评分器的错误、评测的漏洞都看不见 | 定期抽样阅读，按规则分流可疑样本 | 第 04、06 篇 |
对比阶段
| 误区 | 后果 | 改成 | 见 |
|---|---|---|---|
| 只看平均分 | 退化的用例被提升的用例掩盖 | 逐条列出提升、持平和退化 | 第 03、06 篇 |
| 不配对，也不看置信区间 | 把噪声当成提升 | 用配对差值算置信区间，事先算出最小可检测效应 | 第 06 篇 |
| 不看成本 | 选中一个贵得多、却没好多少的方案 | 效果和成本放在一起报告 | 第 02、06 篇 |
| 只用通过率评 Skill | 发现不了没触发、没遵循，以及行为上的变化 | 准入、触发、遵循、增益、代价分开测 | 第 03 篇 |
维护阶段
| 误区 | 后果 | 改成 | 见 |
|---|---|---|---|
| 只测一个方向 | Agent 被优化成什么都问、什么都搜、什么都触发 | 每个“应该做”都配一个“不应该做” | 第 05 篇 |
| 全部失败就认为 Agent 不行 | 修错了地方 | 先检查用例和评分器，用参考解和空跑做冒烟测试 | 第 04、05 篇 |
| 写 Skill 的人看着用例改 | 分数涨了，换一批问题就不行 | 留出集不对 Skill 作者开放 | 第 05 篇 |
| 能力集饱和了还在看 | 能力的提升看不出来 | 毕业进入回归集，补充更难的用例 | 第 05 篇 |
| 数据集和评分器默认用最新版本 | 前后两次的分数不可比 | 显式指定版本，评分器更新后重新评分 | 第 04、05、06 篇 |
关于第二条“先搭大而全的平台”，Anthropic 在 Demystifying evals for AI agents 的附录里说得很直接：很多团队会组合使用多个工具、自己搭评测框架，或者干脆从简单的评测脚本开始。框架能加快进度、统一标准，但它的价值取决于在上面跑的用例。比较好的做法是尽快选一个适合自己工作流的框架，然后把精力投入到用例和评分器本身的迭代上。
从零开始的推进路线
评测可以早建，也可以晚建。Anthropic 举了两个例子。Descript 做视频编辑 Agent，围绕三个维度建评测：不要搞坏东西，做用户要求的事，并且做好。他们从人工评分逐步过渡到 LLM 评分器，评分标准由产品团队定义，并定期用人工校准；现在固定运行两套评测，一套做质量基准，一套做回归测试。Bolt 则是在 Agent 已经被广泛使用之后才开始建评测的，用 3 个月搭出了一套系统：运行 Agent，用静态分析给输出打分，用浏览器 Agent 测试生成的应用，用 LLM Judge 评估指令遵循这类行为。
Anthropic 的观点是：两种时机都可以，但越早建越省力。早期的产品需求很自然就能变成用例；同一份需求，两位工程师对边界情况的理解可能不同，评测集能消除这种分歧。
下面是一条分阶段的路线。每个阶段都写明了进入下一阶段的标准，没达到就不急着往下走。
| 阶段 | 做什么 | 进入下一阶段的标准 |
|---|---|---|
| 1. 定义成功 | 选一个最重要的 Agent 或 Skill；按六个维度写下成功标准；耗时和成本先只记录 | 两位同事对“什么算成功”的判断一致 |
| 2. 跑通最小评测 | 20 到 50 条真实失败用例；用脚本检查终态；每次执行一个隔离环境；每条执行多次；读轨迹 | 参考解能通过，什么都不做时不能通过；同一配置能复现相近的结果 |
| 3. 建立基线 | 记录 Token、耗时和成本；区分环境的失败；用基线分布定预算；做错误分析，得到失败类型 | 有一份基线报告和一份失败类型清单 |
| 4. 扩充用例和评分器 | 按失败类型补用例和评分器；引入 LLM Judge，并用人工标注校准；加入澄清、不可能、注入、触发反例等专项用例 | Judge 的 TPR 和 TNR 达到团队约定的标准 |
| 5. 做对照实验 | 运行清单；成对对照；配对置信区间；报告逐条变化和成本 | 能回答“这次改动有没有让 Agent 变好” |
| 6. 进入发布流程 | 按变更触发；门禁；复核分流；能力集和回归集分开；线上采样评估，失败回流 | 每一次发布决策都有评测结果参与 |
| 7. 进阶 | 多 Harness 对比、模型升级时的 2×2 复测、常态化的变异测试、评测驱动的 Skill 自动迭代 | — |
分工上，Anthropic 的经验是：由专门的评测团队负责基础设施，由领域专家和产品团队贡献大部分用例，并自己运行评测。阶段 1 到阶段 3 可以先由一两个人推动；从阶段 4 开始，人工标注和用例贡献需要领域专家持续参与。
进阶：让评测驱动 Skill 自动迭代
评测流水线建好以后，下一步自然是：既然评测能告诉我们哪里失败了，能不能让模型根据失败自己修改 Skill？
这正在成为一个研究方向。2026 年 6 月的一篇综述把它称为一次范式转变：从人工创建 Skill，转向由评测驱动的 Skill 进化。综述把进化方法分成四类：基于执行反馈、从轨迹中提炼、压缩，以及强化学习。Anthropic 在介绍 Agent Skills 时也表示，希望将来能让 Agent 自己创建、编辑和评测 Skill。
已经有可以直接用的做法：
- 描述优化：第 03 篇提到的 skill-creator 描述优化循环，按触发评测的结果自动改写描述，用留出集挑选版本。
- 提示词进化：GEPA 采样系统的执行轨迹，包括推理、工具调用和工具输出，用自然语言反思问题所在，提出修改并测试，再把多次尝试中互补的经验组合起来。在六个任务上，它比强化学习方法 GRPO 平均高 6%，最多高 20%，所需的执行次数最多少 35 倍。
但也有需要警惕的证据。第 03 篇提到，在 SkillsBench 中，让模型先用 skill-creator 自己编写 Skill、再用这些 Skill 解题，结果在三种配置上都比不装 Skill 还低 8.1 到 11.5 个百分点；而人工整理的 Skill 在同样的配置上提升了 18.2 到 24.8 个百分点。模型写出来的 Skill 不会自动变好。自动迭代的每一轮产出，都必须像人写的版本一样，经过成对对照和门禁。
一个有防护的自动迭代循环：
评测 → 收集失败轨迹 → 模型反思并提出修改
→ 在开发集上复测
→ 在留出集上挑选版本
→ 门禁：回归集、安全、成本
→ 人工审查修改内容
→ 发布
每一道防护都对应一种风险：
| 风险 | 防护 |
|---|---|
| 对开发集过拟合 | 留出集只用来挑选版本，不参与修改；skill-creator 就是按测试集而不是训练集的分数挑选描述 |
| 改出一个能骗过评分器的 Skill | 门禁、变异测试，加上人工审查修改内容，检查有没有针对具体用例的硬编码 |
| Skill 越改越长 | 记录每一轮的篇幅和成本；SkillsBench 显示，写成大而全的文档只提升 0.7 个百分点 |
| 改坏了已有的能力 | 每一轮都跑回归集 |
| 无法回滚 | 每一轮保存运行清单和 Skill 版本 |
比较稳妥的起点，是描述优化这类范围小、结果容易量化的环节，再逐步扩展到 Skill 的正文。
系列回顾
| 篇 | 一句话 |
|---|---|
| 01 评测在回答什么问题 | 评测是一次控制变量实验，要回答完成度、过程、耗时、成本、稳定性和安全合规六个问题 |
| 02 Agent 评测 | 看终态不看声明，只核对关键检查点，每条用例跑多次，区分 Agent 的失败和环境的失败 |
| 03 Skill 评测 | 固定 Agent 只改 Skill，把准入、触发、遵循、增益、代价分开测 |
| 04 评分器 | 评分器要先证明自己判得对：冒烟测试、人工校准、变异测试 |
| 05 数据集 | 用例来自真实失败，覆盖正反两个方向，有版本，也有生命周期 |
| 06 评测链路 | 用运行清单固定变量，用配对置信区间判断差异，用门禁参与发布决策 |
| 07 误区与路线 | 按阶段推进，每一步都有进入下一阶段的标准 |
结语
第 01 篇开头说，评测要解决的问题，是把“感觉变好了”变成可以复现、可以比较的数据。整个系列的方法，都是为了让这句话成立：控制变量，是为了让差异可以归因；检查终态，是为了让“完成”有事实依据；校准评分器、配对比较，是为了让分数值得相信；管理数据集，是为了让这套标准不会过期。
Anthropic 在文章的结尾描述了两种团队：没有评测的团队陷在被动的循环里，修好一个问题又冒出另一个，分不清真实的退化和噪声；早早投入评测的团队，开发反而越来越快，因为每一个失败都变成了用例，用例又防止了退化，指标取代了猜测。
模型会换，Harness 会升级，Skill 会重写。真正能长期留下来的，是一套能告诉你每一次改动到底有没有用的评测。