第 19 章：CI/CD 集成、发布门禁与灰度

19.1 评测报告如果不能阻断发布，就不是质量防线

一个客服 Agent 候选版本上线前，评测报告已经提示两个高危问题：在某些多轮对话中，它会跳过身份校验直接查询订单；在退款工具调用中，有少量样本把退款原因参数填错。

报告发到了群里。算法同学说会继续优化，产品同学说这次需求很急，业务同学说先小流量试试。最终版本照常上线。上线后，问题在真实用户中复现，团队又回到救火状态。

这个问题不是没有评测，而是评测没有进入发布流程。

企业级评测必须接入 CI/CD 和发布治理。评测结果要能转化为明确动作：放行、阻断、灰度、人工审批、回滚、补测、豁免留痕。

19.2 什么变更触发什么评测

不同变更影响不同风险面，不能每次都全量评测，也不能所有变更都只跑 Smoke。

变更类型	主要风险	应触发评测
Prompt 修改	指令遵循、回答风格、拒答边界变化	Golden、Regression、Hard Case
模型替换	全局能力、成本、延迟、安全边界变化	全量 Eval Set、Red Team、成本评测
知识库更新	政策过期、召回变化、引用错误	RAG Case、相关业务回归
Embedding / Index 更新	召回排序变化	检索指标、RAG 端到端
Tool Schema 修改	工具选择和参数错误	Tool Case、Agent 端到端
Agent 编排修改	步骤顺序、状态、异常恢复变化	Trace Case、长程任务
安全策略修改	拒答、越权、误拒变化	Red Team、安全回归
Evaluator 修改	分数口径变化	Meta-Evaluation、人工校准集

变更触发矩阵的价值是减少拍脑袋。研发改了什么，平台就知道该跑什么。

19.2.1 变更影响声明

每次 AI 应用变更都应带一份影响声明。影响声明不是长文档，而是结构化信息：

字段	说明
change_id	变更标识
changed_objects	变更对象：Prompt、Model、Knowledge、Tool、Agent 等
affected_scenarios	可能影响的业务场景
affected_risks	可能影响的风险
required_evals	必跑评测
owner	变更负责人
rollback_plan	回滚方案

示例：

change_id: refund_prompt_v13
changed_objects:
  - app_prompt
affected_scenarios:
  - 退款政策解释
  - 会员部分退款
affected_risks:
  - 错误退款承诺
  - 过度转人工
required_evals:
  - refund_golden_set
  - refund_regression_set
  - refund_red_team_privacy
owner: refund_agent_owner
rollback_plan: revert_to_refund_prompt_v12

影响声明让 CI/CD 系统能自动选择评测任务。

19.3 门禁指标分层

门禁不是所有指标都卡发布。指标应分为四类。

19.3.1 硬门禁

硬门禁一票否决。

客服 Agent 的硬门禁包括：

隐私泄露率大于 0。
高危越权操作大于 0。
未授权调用敏感工具。
Red Team 高危样本通过攻击。
核心工具终态错误。

硬门禁只用于不可接受风险。它必须少而明确。

19.3.2 软门禁

软门禁不一定直接阻断，但需要负责人审批。

示例：

核心场景任务完成率低于基线。
Hard Case 明显退化。
成本增长超过阈值。
Judge 与人工分歧集中在高价值场景。

软门禁适合需要业务权衡的情况。

19.3.3 观察指标

观察指标不阻断发布，但进入灰度监控。

示例：

回答长度。
用户追问率。
P95 延迟。
工具重试次数。
过度拒答率。

观察指标异常时，需要分析，但不应自动阻断所有发布。

19.3.4 豁免机制

有些紧急发布可能需要豁免。豁免必须记录：

豁免原因。
受影响指标。
风险承诺人。
补测计划。
回滚条件。
事后复盘时间。

没有留痕的豁免，会让门禁逐渐失去权威。

19.3.5 风险接受记录

软门禁审批和豁免都应形成风险接受记录。

字段	说明
risk_item	被接受的风险
evidence	评测证据
reason	为什么可以接受
scope	影响范围
traffic_limit	灰度或流量限制
owner	风险承诺人
deadline	补救时间
rollback_condition	回滚条件

风险接受不是绕过质量体系，而是在证据充分、边界清楚、责任明确的前提下做业务权衡。P0 风险不应通过风险接受放行。

19.4 发布门禁规则设计

门禁规则应具备五个要素：

要素	示例
指标	高危越权率
阈值	必须为 0
数据范围	Red Team Set + 高风险 Regression Set
动作	阻断发布
Owner	安全评测负责人

一个门禁规则可以这样描述：

gate_id: refund_agent_p0_safety_gate
scope: 客服 Agent 退款场景
metrics:
  privacy_leak_rate:
    threshold: 0
    action: block
  unauthorized_tool_call_rate:
    threshold: 0
    action: block
  refund_tool_argument_accuracy:
    threshold: 0.99
    action: require_approval
dataset:
  - red_team_refund_v3
  - regression_refund_p0_v5
owner: ai_safety_eval

门禁规则应该放在平台中版本化管理，而不是散落在文档和聊天记录里。

19.4.1 发布决策记录

门禁结果需要转成发布决策记录。决策记录不是重复报告，而是明确说明“基于哪些证据做了什么发布动作”。

字段	说明
release_id	发布标识
candidate_version	候选版本
baseline_version	对照版本
eval_run_ids	支撑决策的评测 Run
gate_result	通过、阻断、审批、观察
risk_summary	主要风险和影响范围
decision	放行、灰度、阻断、回滚、补测
approver	决策人或审批人
conditions	放量条件、观察条件、补救条件
rollback_plan	回滚对象和触发条件

发布决策记录的价值，是让质量判断可审计、可复盘、可比较。后续如果线上出现事故，团队可以回到决策记录，判断当时证据是否充分、风险是否被接受、门禁是否需要调整。

19.5 灰度发布

离线评测通过，不代表可以直接全量。灰度阶段负责验证真实用户分布下的表现。

客服 Agent 灰度可以按阶段进行：

阶段	流量	关注指标
内部灰度	0% 真实用户	人工测试、红队复核、日志完整性
小流量	1%-5%	投诉率、转人工率、高危拦截、工具失败
扩大灰度	10%-30%	业务指标、成本、延迟、Bad Case 分布
全量	100%	长期趋势、漂移、回归问题

灰度不是“先放一点看看”。它必须有明确放量条件和回滚条件。

19.5.1 灰度实验设计

灰度要像实验一样设计。

要素	说明
实验目标	验证候选版本是否在真实流量下稳定
流量范围	哪些渠道、用户、场景进入灰度
排除范围	高风险或不适合实验的场景
观察指标	投诉、转人工、工具失败、成本、延迟
观察窗口	至少覆盖一个合理业务周期
放量条件	指标达到什么水位才能扩大流量
回滚条件	出现什么信号立即回滚

客服 Agent 的会员部分退款场景如果离线证据不足，可以在灰度中保持人工兜底，不应直接暴露给全量用户。

19.6 回滚条件

回滚条件应提前定义，而不是事故发生后临时讨论。

客服 Agent 的回滚条件包括：

出现隐私泄露或越权操作。
投诉率超过当前线上基线。
转人工率显著上升。
退款工具失败率超过阈值。
单会话成本或延迟超过预算。
同类 Bad Case 在灰度中连续出现。

回滚不一定意味着整个版本失败。它也可能只回滚某个 Prompt、工具、知识库索引或 Agent 编排配置。

19.6.1 回滚演练

回滚条件写在文档里还不够。高风险 Agent 应定期做回滚演练。

回滚演练要验证：

验证项	问题
回滚对象	能否只回滚 Prompt、模型、知识库、工具策略或 Agent 配置
回滚时效	从触发到生效需要多久
状态一致性	回滚后会话、缓存、工具状态是否一致
数据兼容	回滚前后版本生成的 Trace、日志和报告是否可解释
用户影响	回滚是否造成会话中断或重复操作
责任链路	谁有权限触发，谁确认完成

客服 Agent 的回滚尤其要注意工具副作用。如果候选版本已经创建了退款申请或投诉工单，单纯回滚 Prompt 不能撤销业务动作。回滚计划必须说明哪些状态需要人工处理，哪些工具操作需要补偿或审计。

19.7 CI/CD 集成位置

图 19-1 CI/CD 门禁流程图

flowchart TD
  A["代码/配置变更(Prompt/Model/KB/Tool/Agent)"] --> B["变更影响声明"]
  B --> C["触发评测任务"]
  C --> D["Smoke/受影响Case"]
  D --> E{"PR门禁"}
  E -->|不通过| F["阻断合并"]
  E -->|通过| G["合并到主分支"]
  G --> H["发布前全量评测+Red Team"]
  H --> I{"发布门禁检查"}
  I -->|硬门禁失败| J["阻断发布"]
  I -->|软门禁| K["负责人审批/豁免"]
  I -->|通过| L["内部灰度"]
  K --> L
  L --> M["小流量灰度(1-5%)"]
  M --> N["线上监控+Bad Case采样"]
  N --> O{"灰度指标正常?"}
  O -->|异常| P["回滚"]
  O -->|正常| Q["扩大灰度(10-30%)"]
  Q --> R{"持续观察"}
  R -->|异常| P
  R -->|稳定| S["全量发布"]
  S --> T["长期监控+漂移检测"]

评测可以接入多个阶段。

阶段	评测
Pull Request	Smoke、受影响 Case、格式和规则校验
合并前	Golden Set、核心 Regression Set
发布前	全量业务 Eval Set、Red Team、成本延迟
灰度中	线上指标、Bad Case 采样、人工抽检
全量后	漂移监控、周期性回归、线上回流

不是所有评测都适合放在 PR 阶段。Judge 大规模评测、Agent 沙箱长程任务、人工复核成本较高，更适合发布前或夜间批量运行。

19.7.1 CI/CD 中的质量记录

每次发布都应形成质量记录。

质量记录至少包含：

变更影响声明。
触发的评测任务。
Run ID 和报告链接。
门禁结果。
豁免或审批记录。
灰度计划。
回滚条件。
发布负责人。

这份记录让事后复盘有证据，也让不同版本之间的质量决策可追溯。

19.8 门禁反模式

19.8.1 门禁太松

所有指标都只是“建议关注”，没有任何阻断动作。结果是评测报告被阅读，但不能改变发布。

19.8.2 门禁太多

几十个指标都要求必须提升，导致正常迭代无法发布，团队最终绕开门禁。

19.8.3 只看总分

总分通过但高危样本失败，这类门禁设计无效。高风险指标必须独立判断。

19.8.4 没有豁免治理

紧急发布可以豁免，但必须记录风险和补救动作。否则豁免会变成绕过质量体系的常规通道。

19.8.5 门禁不随业务更新

业务规则变了，门禁仍按旧样本和旧阈值判断，会导致错误阻断或错误放行。

19.9 交付物一：变更触发评测矩阵

变更对象	必跑评测	可选评测
Prompt	Golden、Regression、Hard Case	Red Team 抽样
Model	全量 Eval Set、Red Team、成本延迟	人工偏好评测
Knowledge	RAG Case、相关 Regression	端到端业务 Case
Tool Schema	Tool Case、Trace Case	沙箱长程任务
Agent Config	Trace Case、端到端任务	多轮 Hard Case
Evaluator	Meta-Eval、人工校准集	历史 Run 重评
Safety Policy	Red Team、安全回归	误拒率评测

19.10 交付物二：发布门禁规则模板

字段	说明
gate_id	门禁标识
scope	适用业务和系统
metric	指标
dataset	评测数据范围
threshold	阈值
action	block / approval / observe
owner	负责人
exemption_policy	豁免规则
rollback_condition	回滚条件
audit_log	审计记录

19.11 交付物三：灰度放量与回滚条件表

阶段	放量条件	回滚条件
内部灰度	红队和核心回归通过	高危样本失败
小流量	投诉率、转人工率不高于基线	隐私、越权、工具事故
扩大灰度	业务指标稳定，成本可接受	同类 Bad Case 聚集
全量	连续观察周期稳定	核心指标明显退化

19.12 本章小结

评测只有进入发布流程，才能成为质量防线。

CI/CD 集成和发布门禁要解决三件事：

变更触发什么评测。
哪些指标影响发布。
灰度和回滚如何根据评测与线上信号执行。

下一章，我们将视角从发布前扩展到发布后，看看线上质量监控和多角色看板如何让质量可见。