第 2.15.2 节：用回归、红队和版本管理守住发布质量
回归、红队与版本管理只有拆成可执行步骤，才容易复核、排错和交接。完成本节后，你应该能够写出回归、红队与版本管理的验收样例、通过/不通过标准、判断阈值和风险说明。
核心概念四层解释法
本节按“四层解释法”讲核心概念：人话解释、项目位置、工程动作、面试说法。
Evaluation Set（评测集）
人话解释：evaluation set（评测集）是一组固定的业务样例，用来反复检查 Agent（智能体）在不同版本下表现是否合格。它不是随便问几个问题，而是覆盖正常问答、边界问题、无资料问题、权限问题、工具问题和高风险问题的样例库。
项目位置：客服工作台中，评测集可以覆盖售后政策、发票、物流、保修、订单查询、工单创建、退款审批和转人工。每次知识库、Prompt（提示词）、模型或工具规则变化，都要跑对应评测集。
工程动作：为评测集记录 evaluation_set_id（评测集编号）、适用范围、样例类型、期望行为、引用要求、通过规则、负责人和版本。评测集要持续维护，不能一次写完就不管。
面试说法：我不会用主观感觉判断 Agent 能不能上线，而是用评测集固定检查核心场景，并把评测结果接入发布门禁。
Golden Questions（黄金问题）
人话解释：golden questions（黄金问题）是最关键、最能代表业务质量的一小组问题。它们通常来自真实高频咨询、客户投诉、客服主管重点关注问题和历史事故。
项目位置：客服知识库里，“七天无理由退货条件是什么”“定制商品能不能退”“超过保修期怎么办”“没有订单号怎么查进度”都可以成为黄金问题。黄金问题不是最多，而是最重要。
工程动作：每个黄金问题都要有期望行为，而不是只写固定答案。比如必须引用最新政策，必须提到例外条件，不能承诺无条件退款，无资料时必须转人工。
面试说法：我会把黄金问题作为发布前的硬门禁。普通评测可以允许少量非关键问题待优化，但黄金问题失败通常不能发布。
Regression Test（回归测试）
人话解释：regression test（回归测试）是检查“新改动有没有破坏旧能力”。AI（人工智能）系统最常见的问题不是完全坏掉，而是修好一个问题后，另外一批问题变差。
项目位置：售后政策新增了“定制商品不适用七天无理由”后，系统既要能回答新规则，也不能把普通商品退货规则答错。工具审批流改了，旧的查订单、建工单流程也不能被影响。
工程动作：每次变更都要记录 regression_result（回归结果），区分通过、警告、失败和需人工复核。回归不只看最终回答，也看引用、拒答、工具调用、审批状态和日志。
面试说法：我会把回归测试当成发布底线，防止 Agent 因为知识、提示词、模型或前端改动产生隐性退化。
Red Team Cases（红队样例）
人话解释：red team cases（红队样例）是故意用刁钻、恶意或高风险方式测试系统，看看它会不会越权、泄露、乱调用工具或编造答案。
项目位置：客服工作台的红队样例包括：诱导模型忽略系统规则、要求查看别人的订单、要求泄露内部补偿政策、要求跳过审批直接退款、要求引用已下线资料、要求生成误导性承诺。
工程动作：红队样例要和 Guardrail（护栏）、权限、审批和日志结合。每个样例都要写清风险类型、期望拦截方式、用户提示、内部告警和复盘字段。
面试说法：我不会只测正常问题，还会用红队样例验证越权、提示注入、敏感信息、工具滥用和资料下线后的拒答能力。
Prompt（提示词） Version（提示词版本）
人话解释：prompt_version（提示词版本）是给 Prompt 配置编号。提示词会影响回答边界、工具选择、语气和拒答规则，所以不能随手改完就上线。
项目位置：客服 Agent 可能有问答提示词、工具选择提示词、转人工提示词、质检提示词和审批摘要提示词。任何一个变化都可能影响业务行为。
工程动作：每次变更记录 prompt_version（提示词版本）、变更说明、影响范围、评测结果、批准人和回滚版本。提示词版本要和发布记录绑定。
面试说法：我会把 Prompt 当成生产配置管理，而不是聊天文案。每次改提示词都要有版本、评测、审批和回滚。
Knowledge Snapshot（知识快照）
人话解释：knowledge snapshot（知识快照）是某一时刻知识库资料、分块、索引、权限和版本的固定记录。它回答“这次评测和发布到底用了哪一版资料”。
项目位置：客服知识库每周都可能更新。售后政策、产品说明、价格规则、保修条款、内部补偿标准都需要知道当前生效版本。
工程动作：每次内容发布前生成 knowledge_snapshot_id（知识快照编号），记录资料范围、新增资料、下线资料、权限变化、索引状态和负责人。评测结果必须绑定这个快照。
面试说法：RAG（检索增强生成）系统的质量不能脱离资料版本。我会用知识快照固定评测上下文，避免“当时测的是哪版资料”说不清。
Release Gate（发布门禁）
人话解释：release gate（发布门禁）是发布前必须通过的一组条件。它像机场安检：不是每个人都看一眼就放行，而是按风险检查身份、行李和目的地。
项目位置：客服工作台的发布门禁可以包含：黄金问题通过、回归测试无严重失败、红队样例通过、知识快照可用、提示词版本已记录、回滚方案可执行、灰度范围已定义、人工批准已完成。
工程动作：发布门禁要有明确结果：pass（通过）、warn（警告）、block（阻断）。不同风险等级的变更使用不同门禁。低风险文案改动可以轻量，模型切换和审批流变化必须严格。
面试说法：我会把发布门禁设计成质量、风险和审批的组合，而不是单纯看构建是否成功。
Canary（灰度）
人话解释：canary（灰度）是先把新版本放给一小部分用户、客服组、租户或场景使用，观察质量稳定后再扩大范围。
项目位置：模型切换可以先对内部客服组灰度；新知识库可以先对售后团队灰度；新前端工作台可以先给 5 个客服坐席使用；审批流变化可以先在测试租户和低金额退款场景验证。
工程动作：定义 canary_scope（灰度范围）、观察指标、持续时间、扩大条件和停止条件。灰度期间要重点看错误答案、转人工率、工具失败率、审批卡住、投诉和成本。
面试说法：高风险 Agent 变更我不会全量发布，会先灰度小范围并用可观测性指标判断是否扩大。
Rollback（回滚）
人话解释：rollback（回滚）是在发布出问题时退回到上一版可用状态。它不是事后拍脑袋，而是发布前就写好的方案。
项目位置：客服工作台的回滚可能包括退回旧 Prompt、旧模型、旧知识快照、旧审批规则、旧前端配置或关闭某个工具入口。
工程动作：每次发布记录 rollback_plan（回滚方案），说明什么情况下回滚、回滚到哪个版本、谁执行、对正在处理的会话和审批单怎么处理、如何通知客服。
面试说法：我会在发布前准备回滚方案，尤其是资料下线、模型切换、工具审批和前端工作台变更，避免出问题时只能临时救火。
Human Approval（人工批准）
人话解释：human approval（人工批准）是让有责任的人在关键发布前确认风险、结果和回滚方案。它不是让领导点个按钮，而是让正确的人基于证据做决定。
项目位置：资料下线需要资料负责人批准；退款审批流变化需要业务主管批准；模型切换可能需要工程负责人和成本负责人批准；对外内容发布需要运营或法务确认。
工程动作：审批材料要包含变更摘要、风险等级、评测结果、红队结果、灰度范围、回滚方案和已知限制。审批通过后才能进入发布。
面试说法：我会把人工批准放在高风险发布门禁里，让业务负责人和技术负责人基于评测证据共同承担上线决策。
Content Publishing（内容发布）
人话解释：content publishing（内容发布）是把知识库资料、政策、FAQ（常见问题）、话术和公告从草稿状态发布到可被 Agent 检索和引用的状态。
项目位置：企业客服知识库不是上传文件就算发布。资料要经过解析、分块、权限、版本、生效时间、下线规则、引用展示和评测。资料发布后，客服 Agent 的答案会变化。
工程动作：内容发布要有 draft（草稿）、reviewing（审核中）、approved（已批准）、published（已发布）、deprecated（已废弃）、removed（已下线）等状态。发布后要生成知识快照并触发评测。
面试说法：我会区分系统发布和内容发布。RAG 项目里，知识内容本身就是生产变更，必须有审核、快照、评测和回滚。
Post-release Review（发布后复盘）
人话解释：post-release review（发布后复盘）是在发布后检查真实效果，确认有没有新问题、用户反馈、成本变化和业务影响。
项目位置：客服工作台发布后，要看黄金问题真实命中情况、错误答案、转人工率、工具失败率、审批卡住、投诉、客服反馈和成本。
工程动作：复盘要记录 post_release_issue_count（发布后问题数）、问题类型、影响范围、关联 trace_id（追踪编号）、处理结果和是否进入下个版本。复盘不是只在事故后做，重要发布都应该做轻量复盘。
面试说法：我会把发布后复盘作为闭环，用真实运行数据反向更新评测集、红队样例、知识库和发布门禁。
本章在客服工作台中的位置
自动化质量与发布流程是客服 Agent 工作台的“上线控制面”。它不直接回答用户问题，但它决定哪些能力可以进入真实客服流程。
| 工作台层级 | 本章负责什么 | 典型变更 |
|---|---|---|
| 知识库层 | 内容发布、知识快照、资料下线、引用验证 | 新售后政策、旧政策下线、权限调整。 |
| Prompt 层 | 提示词版本、评测、回滚 | 回答风格、拒答规则、工具选择策略变化。 |
| 模型层 | 模型切换、成本和延迟评测 | 更换模型、调整模型路由、启用备用模型。 |
| 工具与审批层 | 工具契约、审批流、权限门禁 | 退款审批、发券审批、工单创建规则变化。 |
| 前端工作台层 | 页面发布、状态展示、客服操作验收 | 引用卡片、审批卡片、工单状态、质检入口变化。 |
| 观测与日志层 | 发布 trace、质量指标、复盘依据 | 发布后错误、投诉、成本异常、工具失败。 |
| 发布治理层 | 发布门禁、灰度、回滚、人工批准 | 决定是否发布、发布给谁、失败后怎么退。 |
如果第 2.12 章可观测性让系统“看得见”，第 2.13 章安全与审批让系统“守得住”，第 2.14 章商业验收让项目“交得清”，那么本章就是让每次变更“发得稳”。
系统流程图
这张图有 5 个重点：
读图重点：先从四类变更分支汇入评测门禁；门禁阻断就回修、警告就人工复核，通过后才准备灰度；灰度异常回滚，健康才扩大，所有结果都进入发布复盘。
- 发布不是从“点发布按钮”开始，而是从识别变更类型和风险等级开始。
- 知识库、提示词、模型、工具、审批流和前端都要进入同一套发布记录。
- release gate（发布门禁）必须看评测、回归、红队、风险和回滚，不只看功能是否能用。
- canary（灰度）期间要观察真实指标，不能只等用户投诉。
- post-release review（发布后复盘）要反向更新评测集和红队样例，让发布体系越来越强。
模块拆分
| 模块 | 负责什么 | 输入 | 输出 |
|---|---|---|---|
| Release Registry（发布登记） | 记录每次变更和发布状态 | 变更说明、负责人、风险等级 | release_id（发布编号）、发布记录。 |
| Change Classifier（变更分类） | 判断变更属于知识、提示词、模型、工具、前端还是审批 | 变更内容 | change_type（变更类型）和门禁策略。 |
| Evaluation Manager（评测管理） | 管理评测集、黄金问题和红队样例 | evaluation_set_id（评测集编号）、样例库 | 评测计划和评测结果。 |
| Snapshot Manager（快照管理） | 固定知识库资料和索引版本 | 文档、权限、分块、索引 | knowledge_snapshot_id（知识快照编号）。 |
| Version Manager（版本管理） | 管理 Prompt、模型和审批规则版本 | 配置变更 | prompt_version（提示词版本）和配置版本。 |
| Gate Engine（门禁引擎） | 汇总质量、风险、审批和回滚条件 | 评测结果、风险说明、审批状态 | 发布门禁结果。 |
| Approval Center（审批中心） | 管理人工批准 | 高风险发布材料 | approval_status（审批状态）。 |
| Canary Controller（控制器） | 控制发布范围和扩大规则 | canary_scope（灰度范围）、观察指标 | 灰度状态和扩大建议。 |
| Rollback Controller（控制器） | 记录并执行回滚策略 | rollback_plan（回滚方案） | 回滚结果和影响范围。 |
| Review Board（发布复盘） | 复盘发布后的真实问题 | trace_id（追踪编号）、投诉、日志、指标 | 问题清单和下一轮改进。 |
模块拆分的目的不是增加复杂度，而是让责任清楚。评测集由质量负责人维护，知识快照由内容或知识库负责人确认，门禁由发布负责人汇总，高风险发布由业务和技术共同批准。