第 2.15.1 节：用评测集和黄金问题定义发布基线
评测集与黄金问题只有拆成可执行步骤，才容易复核、排错和交接。完成本节后，你应该能够按顺序说明评测集与黄金问题的触发、处理、复核、记录和兜底步骤。
本章要解决什么问题
前面章节已经把企业客服知识库与工单 Agent（智能体） 工作台的主要能力讲完整了：它能用 RAG（检索增强生成） 回答资料问题，能通过 Tool Calling（工具调用） 查询订单、创建工单，能用 Guardrail（护栏） 控制风险，也能用 Trace ID（追踪编号） 做可观测性。
做到这里，很多新手会以为“系统能跑，就可以上线”。真实项目里，这一步最危险。
客服 Agent 不是静态页面。它上线后的行为会被这些变化影响：
- 知识库新增了售后政策，原来的答案可能变了。
- 一份过期资料被下线，某些问题应该从“能回答”变成“拒答或转人工”。
- Prompt（提示词）改了一句话，工具调用顺序可能变化。
- 审批流从“客服主管审批”改成“主管加财务双人审批”，高风险动作的状态会变化。
- 前端工作台发布了新版本，客服看到的引用、审批卡片、工单状态可能不一致。
- 模型从一个版本切到另一个版本，回答风格、拒答边界、成本和延迟都会变化。
- 工具接口增加了新字段，Agent 可能误把草稿工单当成已提交工单。
如果没有自动化质量检查和发布流程，这些变化会悄悄进入生产环境。用户看到的是错误答案，客服看到的是混乱状态，主管看到的是投诉，工程师看到的是“昨天还好好的”。
本章要解决的问题是：如何把客服 Agent 的每次变更，变成可评测、可审批、可灰度、可回滚、可复盘的发布工程。
这里的自动化质量检查不是让你背几个测试工具名称，也不是教你写代码命令。本章重点讲制作方法、质量门禁和验收：
- 如何设计 evaluation set（评测集）。
- 如何挑 golden questions（黄金问题）。
- 如何做 regression test（回归测试）。
- 如何沉淀 red team cases（红队样例）。
- 如何管理 prompt/version（提示词/版本）和 knowledge snapshot（知识快照）。
- 如何设计 release gate（发布门禁）。
- 如何做 canary（灰度）和 rollback（回滚）。
- 哪些发布必须 human approval（人工批准）。
- 内容发布和系统发布有什么区别。
- 发布后如何做 post-release review（发布后复盘）。
面试时，自动化质量与发布流程是从“我能做 Demo（演示）”走向“我知道怎么上线”的关键能力。一个成熟回答不是“我会测试一下”，而是：我会把资料、提示词、模型、工具、前端和审批流都纳入发布记录，用评测集、黄金问题、红队样例、回归结果和人工批准形成发布门禁，再用灰度、回滚和发布后复盘控制风险。
学习目标
读完本章后，你应该能够：
- 用人话解释 evaluation set（评测集）、golden questions（黄金问题）、regression test（回归测试）和 red team cases（红队样例）的区别。
- 为客服知识库更新、资料下线、模型切换、Prompt 变更、工具审批流变更和前端工作台发布设计发布流程。
- 设计 knowledge snapshot（知识快照），让每次评测都知道当时用的是哪一版资料。
- 设计 prompt_version（提示词版本）和模型版本记录，避免“改了哪里没人知道”。
- 设计 release gate（发布门禁），把质量结果、风险等级、人工批准和回滚方案结合起来。
- 判断哪些变更可以自动发布，哪些必须人工批准，哪些必须灰度。
- 设计 canary（灰度）范围、观察指标和扩大规则。
- 写出发布记录字段契约，覆盖 release_id（发布编号）、change_type（变更类型）、regression_result（回归结果）、rollback_plan（回滚方案）、trace_id（追踪编号）等关键字段。
- 设计发布后复盘，发现知识缺口、错误答案、审批卡点和工具风险。
- 面试时把“自动化测试”讲成“生产级 Agent 发布治理能力”。
贯穿业务场景
本章继续使用“企业客服知识库与工单 Agent 工作台”。
假设客户是一家有电商售后和企业客户支持团队的公司。客服工作台已经具备这些能力：
- 客服或用户输入问题。
- 系统检索企业知识库，给出带引用的回答。
- Agent 可以查询订单、物流、发票和历史工单。
- 对退款、发券、短信通知、资料发布等高风险动作发起人工审批。
- 前端工作台展示会话、引用、工具卡片、审批卡片、工单状态和质检结果。
- 主管可以查看日志、质量看板和发布记录。
现在出现 6 类真实变更。
| 变更 | 示例 | 为什么需要发布流程 |
|---|---|---|
| 知识库更新 | 售后政策从“7 天无理由”补充到“定制商品不适用” | 更新后答案应该更准确，但不能破坏旧问题。 |
| 资料下线 | 旧版保修政策失效 | 系统不能继续引用旧政策，也不能凭记忆回答。 |
| Prompt 变更 | 把“简洁回答”改成“先询问订单号” | 可能影响工具调用和转人工判断。 |
| 工具审批流变化 | 退款从单人审批改成双人审批 | 前端状态、工具执行和日志都要同步。 |
| 前端工作台发布 | 新增“引用对比”和“发布风险提示” | 页面变化不能让客服误判工单是否已提交。 |
| 模型切换 | 从旧模型切到新模型以降低成本 | 可能改变回答风格、拒答率、延迟和 Token（文本计量单位）成本。 |
这些变更不是同一个风险级别。改一个按钮文案和下线一批售后资料，不应该走同样流程；切模型和改退款审批，也不能只靠开发自测。
本章的核心思想是：每次变更都先归类，再评测，再过门禁，再灰度或发布，再复盘。
新手为什么会卡住
很多学习者做完客服 Agent 后，会在上线前卡住。原因通常不是不会写功能，而是不知道如何判断“现在能不能发布”。
| 卡点 | 表现 | 根因 | 正确处理 |
|---|---|---|---|
| 把测试当成随手试问 | 问几个熟悉问题，觉得差不多就上线 | 没有固定评测集 | 建立 evaluation set（评测集），每次变更都复测。 |
| 只看新功能有没有成功 | 新政策能答了，但旧政策问题答错了 | 没有 regression test（回归测试） | 每次发布都检查旧能力有没有退化。 |
| 不知道怎么测模型安全 | 用户诱导泄露内部补偿规则时系统答了 | 没有 red team cases（红队样例） | 把越权、提示注入、敏感信息、恶意工具请求纳入测试。 |
| 知识库版本说不清 | 评测通过时用的是旧资料还是新资料没人知道 | 没有 knowledge snapshot（知识快照） | 每次评测绑定资料快照。 |
| Prompt 随手改 | 改完后回答风格、拒答边界和工具调用都变了 | 没有 prompt_version（提示词版本） | 提示词也要像产品配置一样版本化。 |
| 所有发布都一把推 | 高风险变更直接影响全部客服 | 没有 canary（灰度） | 先给小范围用户、租户或客服组试用。 |
| 回滚只停留在口头 | 发布出问题时不知道退回哪一版 | 没有 rollback_plan（回滚方案） | 发布前写清退回资料、提示词、模型、前端和审批规则的路径。 |
| 人工审批变成形式 | 审批人只看到“发布一下” | 审批材料没有质量结果和风险解释 | human approval（人工批准）要看到变更内容、评测结果、风险、灰度和回滚。 |
新手容易把“自动化质量检查”理解成技术命令。真实项目里，它更像发布治理：让团队在每次改变系统行为前，都知道改变了什么、影响谁、风险多大、如何验证、谁批准、出事怎么退。