后记

还记得第 1 章开头那个上线一周就翻车的客服 Agent 吗？

500 条自动化用例全部通过，接口正常、标准问答准确、退款物流订单三个主流程能走通——测试报告很漂亮。然而上线后口语化表达识别失败、多轮上下文丢失、知识库冲突条款未处理、工具失败后瞎编承诺、高风险金额问题未转人工，问题集中爆发。

如果这本书的方法在那个团队落地，六个月后事情会变成什么样？

让我们再走一遍同样的场景，但这一次评测体系已经成为基础设施。

同一个 Agent，六个月后

业务目标从一开始就被拆成了可度量指标：自助解决率、退款政策正确率、工具参数准确率、越权率、转人工率、P95 延迟、单会话成本。这些指标不是挂在墙上的数字，而是各自绑定了数据集、Evaluator、阈值和门禁规则。

客服 Agent 的退款场景有了分层评测。RAG 组件单独测召回率和引用准确率，Tool Call 组件单独测工具选择和参数生成，编排执行层通过 Trace 检查步骤顺序和异常恢复，应用业务层通过端到端 Case 检查任务完成率和风险边界。不再用一个“回答对不对”覆盖所有问题。

Eval Set 不再是 500 条 happy path。它分成了 Golden Set（核心稳定能力）、Regression Set（已修复问题防复发）、Hard Case Set（长尾和边界场景）、Red Team Set（安全攻击样本）。会员部分退款叠加优惠券的场景不再是漏网之鱼，它在 Hard Case 里有专门的样本；他人订单查询在 Red Team 里有 20 条多轮诱导变体。

Evaluator 不再是一个 Judge 打天下。隐私泄露和禁止承诺用规则拦截，退款金额和工具参数用脚本计算，政策忠实度和表达清晰度用 Rubric 约束的 LLM-as-Judge 评分，高风险退款和 Judge 低置信样本自动进入人工复核。Judge Prompt 经过试标校准，不再因为回答更长就给高分。

每次评测 Run 都记录完整版本血缘：模型版本、Prompt 版本、知识库索引版本、工具 Schema 版本、Evaluator 版本、数据集版本。当两个版本分数不同时，团队能立即回答“是什么变了”，而不是开两小时会猜测原因。

发布不再凭感觉。P0 风险（隐私泄露、越权操作、错误退款承诺）一票否决，核心场景通过率低于基线 2% 需要审批，成本延迟超阈值进入评审。候选版本在物流场景提升但退款场景退化时，门禁不会被平均分掩盖——系统会给出“物流可灰度、退款需补测”的细粒度决策，而不是简单的“放行/阻断”。

线上监控不再是事后看投诉率。转人工率、追问率、工具失败率、无证据回答率、单会话成本实时看板，异常自动告警。线上出现新的 Bad Case 时，经过脱敏、去重、归因后会进入候选 Regression Set，而不是被人工修完就遗忘。

那个曾经把“积分不会扣回”答错的会员部分退款场景，现在有了明确的处理流程：

它在 Hard Case Set 里有 30 条变体样本
正确政策未召回时归因到 RAG 层，提示优化 Chunk 和召回策略
政策已召回但模型仍编造时归因到 Prompt 或模型忠实性，补充约束 Few-shot
未调用退款规则工具时归因到编排层，检查工具前置策略
无论哪一层修复，修复后都必须在 Regression Set 上通过，并在后续版本中持续回归

最关键的变化不是分数提高了多少，而是质量讨论的语言变了。团队不再争论“模型行不行”，而是讨论“这个 Bad Case 的 RAG 召回率是多少”“Trace 里工具参数错在第几步”“门禁规则是否需要调整”“这个样本该进 Golden 还是 Regression”。质量从主观感受变成了可观测、可归因、可改进的工程对象。

评测不是终点，是持续进化的起点

我在写这本书的过程中，经常被问到一个问题：评测做到什么程度算“够了”？

答案是：永远不够，但你必须从某个地方开始。

没有团队能在第一天就建成完美的 EvalOps 平台、覆盖所有长尾场景、Judge 与人评一致性达到 95%、线上回流完全自动化。但你可以从最小闭环开始：选一个核心业务场景（比如退款），建 50-100 条 Golden Set，实现规则+脚本+Judge 的基础 Evaluator，记录版本血缘，设置最简单的硬门禁，把线上 Bad Case 手工回流到回归集。

这个最小闭环跑通后，再逐步扩展场景、增加数据分层、完善平台能力、接入 CI/CD、建立红队机制。评测体系不是一次性项目，而是和 AI 应用一起持续生长的基础设施。

这本书给你的不是一套固定答案，而是一套思考框架和可操作的工具。每个企业的业务场景不同、风险偏好不同、团队结构不同，具体指标、阈值、流程必然不同。但底层逻辑是共通的：

评测从业务目标和风险出发，而不是从 Benchmark 出发
被评对象需要分层，不能用一个总分掩盖层级问题
数据是资产，不是题库，需要版本、血缘和生命周期管理
Evaluator 是度量仪器，需要选型、校准和 Meta-Eval
没有版本血缘的评测不可复现，不可复现的评测不可信
不进门禁的评测只是报告，不接线上的评测会逐渐失效
Bad Case 的终点不是报告，是修复、验证和回归沉淀
安全是一等维度，不是上线前临时补测

给正在建设 AI 质量体系的你

如果你正在一家企业从零搭建 AI 评测体系，我会给你三个建议：

先闭环，再完美。 不要等到平台建好、数据集够大、Judge 校准完才开始。先用脚本和表格跑通一个场景的“评测→门禁→回流”最小闭环，哪怕只有 50 条样本，也比规划了三个月但没有一次真正阻断发布的“完整体系”有价值。

先风险，再覆盖。 不要平均分配评测资源。找出你的 P0 场景——那些一旦出错会造成财务损失、合规风险或用户信任崩塌的场景——先把它们评测到可信程度，再扩展到长尾体验问题。一个越权查询都拦不住的系统，答案满意度再高也没有意义。

先归因，再优化。 看到 Bad Case 时忍住直接改 Prompt 或微调模型的冲动。先花时间定位根因：是知识缺失、检索失败、上下文截断、工具错误、编排遗漏，还是模型幻觉？归因对了，一个修复可能解决一类问题；归因错了，十个修复可能只是在打补丁。

AI 系统的质量不会自动发生。它需要被设计、被度量、被维护、被持续改进。评测体系就是让这件事从“凭运气”变成“靠工程”的基础设施。

希望这本书成为你建设这套基础设施时的有用参考。

愿你所有上线的 Agent 都不再翻车。

——作者 2026 年 7 月