AI Agent 进入生产以后，最怕的不是一次改动失败，而是失败以后没人说得清到底改了什么。提示词换了一段话、工具多开了一个写权限、知识库换了新版本、评测样本少跑了一组，都可能让同一个流程出现完全不同的结果。
所以 Agent 变更单不是管理形式，而是复盘材料。它和 影响面评估、变更复盘、运行证据包 放在一起，才能让团队知道一次改动从哪里来、会影响谁、出了问题怎么退回去。
先写清楚变更对象
变更单第一栏不要写“优化 Agent 效果”。这个说法太宽，后面无法验收。更好的写法是明确对象：系统提示词、工具列表、连接器权限、知识库版本、评分器规则、调度时间、人工审批条件，或者外部写入字段。
对象越具体，影响范围越容易判断。比如改提示词主要影响回答风格和工具选择，改连接器权限可能影响数据出口，改知识库版本则可能影响事实口径。
影响范围要写到流程
很多变更单只写“影响客服 Agent”，仍然不够。应该继续往下拆：影响哪些入口、哪些客户群、哪些任务类型、哪些外部系统、哪些人工审批节点。Agent 是流程的一部分，影响范围也要按流程写。
这一步可以对照 连接器清单 和 权限矩阵。如果变更会扩大读写范围，审批级别就不应该和普通文案调整一样。
评测样本要绑定变更目的
变更单里要写本次为什么改，以及用哪些样本证明改动有效。比如为了减少错误退款承诺，就应该跑退款相关失败样本；为了提升知识库引用稳定性，就应该跑引用冲突和过期文档样本。
这和 评测集 是一条线。评测不是上线前临时跑分，而是变更单的一部分：你为什么改，就用什么样本证明它没有把核心场景改坏。
回滚方式不能只写“可回滚”
“必要时回滚”是一句空话。变更单要写旧版本在哪里、回滚触发条件是什么、谁能执行回滚、回滚后哪些数据需要恢复、要通知哪些人。涉及外部写入的流程，还要写清楚能不能补偿。
前面写过 OpenClaw 回滚预案，核心逻辑一样：回滚不是上线失败后的临场反应，而是变更之前就要准备好的退路。
总结
AI Agent 变更单要回答四个问题：改了什么，为什么改，会影响哪些流程，出问题怎么退回。把提示词、工具、知识库、评测和回滚都写清楚，Agent 的生产改动才不会变成一次次凭记忆补救。
