AI Agent 发布以后，团队最容易说的一句话是“已经上线”。但上线只是状态变化，不代表业务结果已经稳定。提示词、工具、知识库、权限和阈值都可能在发布后暴露问题，如果当天没有复盘，很快就会丢失证据。
发布复盘适合让 Agent 先整理第一版。它不是替负责人下结论，而是把变更内容、影响范围、异常记录、用户反馈和后续动作收在一起。这个流程可以接上 决策日志、生产停用流程、事故演练。
先还原本次到底改了什么
发布复盘第一段不要写感受，要写事实：改了哪个 Agent，改了哪些提示词、工具、知识库、权限、阈值或输出模板，发布时间是什么，谁批准，是否灰度。
这一步看似简单，却能避免后续扯皮。很多异常不是代码错误，而是某个规则被改了、某个工具权限被打开了、某份知识库被替换了。
影响范围要按对象拆开
Agent 发布影响的对象可能包括用户、客户、内部团队、外部系统和数据表。复盘时要拆开看：有没有触发外部通知，有没有写入业务系统，有没有改变报价、工单、知识库或权限记录。
如果只是内部草稿生成，复盘可以轻一点；如果涉及客户通知、系统写入或权限变更，就要把运行证据和回滚判断写得更细。
异常记录不要只写严重问题
发布当天的小异常也值得记录。比如耗时变长、人工修改率升高、引用来源变少、重复重试、某类输入更容易失败。这些未必构成事故，却能提示下一次风险。
异常记录可以来自 运行看板、审计日志 和人工反馈。Agent 负责汇总，人负责判断是否需要回滚或补配置。
后续动作要当天分配
发布复盘最怕写成“继续观察”。继续观察可以有，但必须说明观察什么、谁观察、什么时候再看、达到什么阈值要暂停。
更好的后续动作包括：补回归样本、修知识库冲突、收紧工具权限、加人工确认点、调整成本阈值、写一条用户说明。每条动作都要有负责人和完成时间。
总结
用 AI Agent 做发布复盘，重点不是让复盘更漂亮，而是让变更影响、异常记录和后续动作当天收口。Agent 发布越频繁，越需要把上线成功和业务稳定分开看。
