生产环境稳定运行的 Agent，怎么通过 PR 把历史版本维护好？

先说一个场景：你们的询价 Agent 上线三个月，一直挺稳。今天业务主管说「客户总说报价慢，把回复改快一点」，于是有人直接改了一句提示词「回复要更简练」。晚上七点，客户投诉来了——Agent 把「需人工确认」的报价也直接报出去了。

这时候你第一反应是什么？「赶紧改回去」。改回去的前提是什么？你手里得有上一版。

如果提示词是在某个对话框里随手改的，上一版在哪？谁还记得原文是什么？这就是没有版本管理的 Agent，在生产事故面前的样子：不是修不修得好的问题，是连「回到出事前」都做不到。

一、Agent 进了生产环境，就是一套系统

很多人有个错觉：Agent 就是「一段提示词」，改起来很随意，不像软件那么金贵。

但一旦 Agent 接进了真实业务——自动回客户、自动查舱、自动生成报价——它就是你业务的一部分。它出错，客户看到的是你公司出错。这时候它和银行系统的地位是一样的：可以改，但必须有版本、能回退、出问题能查。

软件行业早就想明白了这件事，办法叫「版本管理」：代码放仓库，每次改动留记录，出问题回滚到上一个稳定版本。Agent 的版本管理，思路完全一样，只是管的东西从「代码」换成了「prompt、配置、规则集」。

二、把 Agent 当代码管：prompt、配置、规则集都进仓库

一个 Agent 由什么组成？提示词、工具配置、调度规则、凭据、记忆。这些东西全是文本，而文本就该放在仓库里，像代码一样管。

具体做法不复杂：

1. 每个 Agent 一个文件夹，里面放着它的提示词、配置、说明文档
2. 任何改动都走「提交 → 评审 → 合并」，不留「直接在线上改」的后门
3. 每次合并就是一个新版本，历史版本永远留着，随时能查能回滚
4. 出问题时先回滚，再排查——别让业务一直坏着等你慢慢找原因

这套东西听起来像程序员的事，但现在工具已经把门槛降到很低了：你不需要懂代码，只需要会「改文件 → 提交 → 等确认」。货代公司的业务员，学一学就会。

三、一个真实事故的两种结局

同一个事故，有没有版本管理，结局完全不同。

没有版本管理： 晚上七点客户投诉，业务主管翻聊天记录找谁改的，没人记得。只能先停掉 Agent，人工接回所有报价，团队加班到半夜重新写提示词，还不敢保证和原来一样。第二天继续提心吊胆。

有版本管理： 晚上七点客户投诉，值班的人翻开变更记录：「下午三点有人改过提示词」。对比一下发现问题，一键回滚到上一版。八点 Agent 恢复正常，九点复盘：为什么那笔改动没走评审？下次怎么避免。

区别不在技术，在于你有没有「回到出事前」的能力。这个能力，就是版本管理。

四、货代场景：哪些「配置」也该进仓库

说到版本管理，别只想到提示词。业务里的规则集、路由配置、通知模板，凡是 Agent 会读、会依据的东西，都值得进仓库：

• 询价 Agent 的运价规则集——哪条航线查哪张表
• 对单 Agent 的字段映射——哪个字段对应哪个系统
• 催款 Agent 的通知模板——什么语气、什么节奏
• 自动回邮件的边界规则——什么话能说、什么话必须转人工

这些规则今天可能还是业务主管脑子里的经验，或者某个 Excel 里没人管的表。把它们变成仓库里的文本文件，Agent 才能读、才能按版本走、才能改出问题回退。这一步做完，你的 Agent 才真正「管得住」。

五、适用边界

这套做法最值钱的时刻，是 Agent 已经开始影响客户的时候。如果 Agent 还在试用、只服务内部、出错也没人受伤，可以先轻一点，但至少要养成「改完留个备份」的习惯。

我还想说明白一件事：版本管理解决的是「能回退」，不解决「为什么改坏了」。真正减少事故，还要靠评审习惯和测试——版本管理是底线，不是全部。

继续读：怎么像有开发团队一样去提需求、去建设 Agent？；搭一个 AI 员工，不用写代码；SOP 是 Agent 的边界。