AI Agent 的上线最怕一刀切。提示词改了一句、工具参数多了一个字段、知识库换了一批资料，看起来都是小改动，但一旦直接推到全部流量，问题会在客户回复、外部写入和人工返工里同时冒出来。
灰度发布的价值，是先让小流量和旧样本替团队踩坑。它应该和 影响面评估、回放验收、观测指标 放在同一条上线链路里，而不是发布前随口说一句“先观察”。
先决定什么值得灰度
不是所有改动都要走重流程，但涉及客户可见回复、外部写入、权限、费用、数据导出和合同条款的 Agent 变更，都不应该直接全量发布。越靠近真实业务动作，越需要灰度。
判断时不要只看改动文件大小。提示词里删掉一个限制条件，可能比新增一整段解释更危险；工具版本换了一个返回结构，也可能让下游判断全部偏掉。
旧样本要先跑一遍
灰度前要先用旧事故、人工退回、低置信度和工具失败样本跑一遍。它们暴露过真实弱点，比临时编的测试问题更能说明新版本是否稳。
如果旧样本都过不了，就不要急着给真实用户。至少要知道失败发生在提示词、知识库、工具返回还是人工确认节点，再决定是修复、缩小灰度，还是延后发布。
小流量也要有指标
灰度不是把 5% 流量切过去就结束。团队要提前写清楚观察指标：成功率、接管率、引用缺失率、工具失败率、成本变化、人工修改原因和客户可见错误数量。
这些指标可以接上 运行时运营。如果只看有没有人投诉，灰度其实已经失去意义，因为很多问题在用户投诉前就能从日志里看出来。
回滚条件要写在发布前
最容易被忽略的是回滚条件。比如高风险样本失败、工具失败率翻倍、人工接管率异常上升、关键客户任务出错、成本超过阈值，都应该触发暂停或回滚。
这一步和 变更治理 是同一件事。灰度不是为了证明一定能上线，而是为了给团队一个有证据的继续、暂停或回退决定。
总结
AI Agent 灰度发布的核心，是把旧样本回放、小流量验证、指标观察、人工确认和回滚条件放到一条线上。先在小范围暴露问题，才有机会避免全量上线后的连锁返工。
