到这一阶段，团队通常已经有了：
- 多 Agent 协作链路；
- 能力注册中心；
- 基础观测与告警。
但上线质量仍不稳定，核心原因是：评测还停留在“参考信息”，没有进入“发布决策”。
这一章要做的就是把评测从“建议项”升级为“硬门禁”：
- 指标不达标，禁止发布；
- 高风险能力只允许灰度；
- 发布后持续验收，不达标自动回滚。
学习目标
完成本章后，你将能够：
- 建立 AI 能力发布门禁模型（质量、合规、成本、稳定性四条线）。
- 把离线评测、在线验收、灰度放量串成统一发布流水线。
- 设计“阈值 + 趋势 + 风险权重”综合判定机制。
- 让每次发布都有可复核证据链，而不是靠主观判断。
一、为什么“测了”仍会出事
常见现象：
- 发布前做了离线评测，分数看起来不错；
- 一上线就出现策略违规或执行失败；
- 复盘发现评测报告没有进入发布系统，只是附件。
根因在于：
- 评测样本不覆盖真实高风险场景。
- 指标只看平均值，不看长尾与漂移。
- 没有阻断机制，发布决策和评测结果脱钩。
所以要从“评测报告”升级为“评测门禁”。
二、门禁模型：四条线同时达标
一个可用的门禁模型至少包含四类阈值：
- 质量线：业务准确率、首轮通过率、可执行性。
- 合规线：策略违规率、越权调用率、敏感输出率。
- 稳定线：任务成功率、p95 延迟、重试放大率。
- 成本线：单有效任务成本、预算占用斜率。
2.1 门禁策略示例
release_gate:
capability_id: cap.code.review.v3
quality:
business_accuracy: ">= 0.93"
action_executability: ">= 0.97"
compliance:
policy_violation_rate: "<= 0.005"
unauthorized_tool_call_rate: "<= 0.001"
reliability:
success_rate: ">= 0.985"
p95_latency_ms: "<= 2500"
cost:
cost_per_accepted_task_usd: "<= 0.20"四条线任意一条不通过，都应阻断进入生产。
三、把离线评测接入 CI：每次变更先过“静态门”
触发条件包含：
- Prompt 改动；
- 工具契约变更；
- 知识库版本更新；
- 模型/路由策略调整。
3.1 CI 阶段检查清单
- 契约兼容性检查（Schema Diff）。
- 回归评测集（黄金样本 + 历史事故样本）。
- 对抗样本评测（歧义输入、越权诱导）。
- 成本模拟与配额冲击分析。
CI 的目标是快速发现“确定性坏改动”。
四、在线验收门：灰度不是形式，而是第二道门禁
离线通过后不能直接全量，必须进入灰度验收。
4.1 灰度阶段指标
- 线上业务准确率（抽检 + 自动对齐）
- 策略违规率（实时守护统计）
- 工具调用失败率（含超时、参数错误）
- 用户侧负反馈率（撤回、二次返工）
4.2 灰度放量规则
canary_policy:
steps:
- traffic: 5
duration: 2h
pass_if: ["success_rate >= 0.985", "policy_violation_rate <= 0.005"]
- traffic: 20
duration: 4h
pass_if: ["business_accuracy >= 0.93", "rollback_trigger == 0"]
- traffic: 50
duration: 8h
pass_if: ["cost_per_accepted_task <= 0.20"]未满足条件不得进入下一档。
五、综合判定：阈值不够，还要看趋势与风险权重
固定阈值适合“是否合格”，但不适合“是否安全放量”。
你应增加两类判断：
- 趋势判断：指标是否持续恶化（例如 3 个窗口连续下滑）。
- 风险权重：高风险能力（财务/权限）使用更严阈值。
5.1 风险加权示例
- 低风险能力：通过线 = 基准阈值。
- 中风险能力：通过线 = 基准阈值 + 10% 安全余量。
- 高风险能力：通过线 = 基准阈值 + 20% 安全余量 + 人工审批。
六、把门禁结果产出为“发布证据包”
每次发布都应自动生成证据包，包含：
- 本次变更范围（Prompt/模型/工具/知识库版本）。
- 离线评测结果（样本集版本、指标、失败案例）。
- 灰度阶段指标曲线与告警记录。
- 最终发布决策（通过/拒绝/回滚）与责任人。
证据包的价值：
- 事故复盘可追溯；
- 审计合规可交付；
- 团队经验可沉淀。
七、Foundation 接口实现建议
public sealed class GateDecision
{
public bool Passed { get; init; }
public string ReasonCode { get; init; } = string.Empty;
public IReadOnlyList<string> FailedChecks { get; init; } = Array.Empty<string>();
}
public interface IReleaseGateEvaluator
{
GateDecision Evaluate(string capabilityId, string candidateVersion);
}
public interface IEvidencePackService
{
string Generate(string capabilityId, string version, GateDecision decision);
}在流水线层面只认 GateDecision.Passed，不允许“人工口头豁免”绕过系统。
八、组织协同：谁有权放行
建议采用双钥匙机制：
- 技术负责人：确认质量与稳定性。
- 业务/合规负责人：确认策略风险可接受。
高风险能力必须双签；低风险能力可单签自动化放行。
九、失败后的标准动作
门禁失败后不要只给“失败通知”，要有标准化处置：
- 自动回滚到上一个稳定版本。
- 生成失败归因工单（含失败样本与指标快照）。
- 标注阻断类型（质量/合规/稳定/成本）。
- 要求下一次发布附带修复验证证据。
没有标准动作，门禁就会沦为“红灯提示器”。
常见坑
1) 门禁指标太多
超过 8-10 个核心指标后，团队会开始“选择性解释”。
2) 只在主干分支做评测
应在 PR 阶段就执行基础门禁，提前拦截问题。
3) 灰度只看成功率
必须联看策略违规率和用户负反馈率，否则会漏掉高风险问题。
4) 失败可人工强行上线
一旦存在常态化“例外上线”，门禁体系会迅速失效。
下一章进入《从协作到自治：Auto-Run 工作流的安全边界设计》，重点解决“让 AI 自动执行”时的权限、审批、回滚与审计闭环。