Agent 上线后的多数事故，不是模型突然变笨，而是一次“小改动”同时改变了规则、知识、工具或权限。生产变更应先回答改的是什么、影响谁、怎样验证、怎样逐步放量、出问题怎样停。
第一步：先给变更分类
| 变更类型 | 例子 | 主要批准人 |
|---|---|---|
| 业务规则 | 报价门槛、升级条件、验收谓词 | 业务 Owner |
| 知识内容 | 制度、产品参数、SOP 新版 | 内容 Owner/批准人 |
| 连接器 | 新增写入字段、第三方接口升级 | IT/系统 Owner |
| 模型与路由 | 更换模型、调整降级顺序 | Agent 运营/平台管理员 |
| 权限与动作 | 扩大可见范围、开放自动发送 | 有权管理员与业务负责人 |
不要用“优化 Agent”概括所有变更。不同类型需要不同证据和批准人。
第二步：写出影响清单
变更单至少列出受影响的 Agent、技能、岗位、组织、业务对象、定时任务和运行中长任务；说明读取范围、写入范围、人审门槛、成本与时延是否变化。若无法列出影响范围，说明平台缺少依赖关系，不能安全放量。
第三步：用固定用例回归
除正常问题外，还要跑缺字段、来源冲突、重复触发、权限不足、连接超时和人工驳回。涉及写操作时，在隔离环境验证幂等、字段白名单和写后回读；涉及模型升级时，不能只比较文字好不好看，还要比较工具选择、结构化输出和拒绝边界。
技能发布的状态流程见企业 AI 技能怎么发布；上线前的红队方法见企业 AI Agent 怎么评估。
第四步：灰度并观察完整任务
先限定一个组织、岗位或少量真实任务，观察业务终态、人工接管、异常类型和单位成功任务成本。不要只看前几次调用成功，也不要在同一次灰度里继续叠加别的改动。
运行中的长任务默认固定启动时的版本。若是紧急安全问题，可以停止后续危险动作，但要把受影响任务转入明确的异常队列。
第五步：回退后仍要处理已发生动作
回退不是把代码或配置切回旧版就结束。已经发送的消息、创建的单据、修改的字段不会自动消失。应查询变更窗口内的任务，回读业务终态，逐项决定保留、修正或人工处置。
每次变更最终沉淀版本、差异、批准、测试、灰度结果和回退记录。这样 Agent 才能像正式业务系统一样长期运营，而不是永远依赖某个人记得“上次改了什么”。需要建立这套运营底座，可从企业 AI 管理后台继续评估。
建立生产变更窗口
对高频运行或涉及外部动作的 Agent，约定常规变更窗口和冻结时段。月底结账、重大交付和促销高峰期间，不应同时升级模型、改价格规则和换连接器。紧急安全修复可以例外，但要明确停止哪些动作、怎样通知业务和何时复盘。
发布前记录当前生产版本、正在运行的任务、异常基线与关键指标。没有基线，发布后看到失败增加也无法判断是新版本导致，还是业务量和上游系统本身发生变化。
配置也要纳入版本控制
很多事故并非代码造成，而是后台开关、模型路由、权限范围或环境变量被直接修改。影响行为的配置应有草稿、差异、批准、生效时间和回退值；密钥本身不进入普通版本记录，但引用关系和轮换事件要可审计。
同一会话中随任务状态动态增删工具，也可能改变模型上下文和行为。工具集合应以稳定运行配置为主，真正的业务限制由后端权限、凭据和动作批准执行，不能把前端隐藏按钮当安全边界。
变更后核对“没有做什么”
除了验证新能力成功，还要验证旧红线仍然成立：无权用户仍看不到数据，高风险动作仍需确认，重复触发不会重复写入，未知错误不会伪装成成功。负向用例往往比一条漂亮成功路径更能发现回归。
观察窗口结束后由业务 Owner 和运营人员共同确认是否扩大范围。若真实数据表明人工接管长期升高，就回到当前范围修正，不以“已经发布”为理由继续放量。
