AI agent 进入生产后，最难排的回归往往不是“模型今天变差了”这么单纯。真实情况更常见的是：模型换了一版、系统提示改了、工具 schema 多了两个字段、policy 把某类动作从允许改成 review、fallback 顺序也顺手调了。表面上看每个改动都不大，但它们叠在同一次 run 里，系统的判断环境就已经不是昨天那套了。
如果这时你还只把版本理解成“模型版本”或“prompt 版本”，排查基本注定会陷入猜谜。因为你根本回答不了：这次结果变差，到底是模型推理路径变了，还是 tool schema 让参数默认值变了，还是 policy 把某个步骤截断了，还是 fallback 改得更激进了。
这也是为什么 AI agent 更需要 version set，而不是零散版本号。你真正需要固定的不是某个单独部件，而是一次 run 当时所处的整套判断环境。
建议配合 AI agent 灰度发布与功能开关、AI agent Prompt Contract 设计、AI agent 工具 Schema 演进兼容 和 AI agent 模型路由与回退链设计 一起看。
一个 version set 至少应该包含哪些东西
| 组成部分 | 为什么必须进同一组 |
|---|---|
| 模型与 fallback 路由 | 决定推理能力、成本和容错路径 |
| System Prompt / Contract | 决定 agent 如何理解任务与状态 |
| Tool Schema / Capability Manifest | 决定 agent 能用什么参数、看到什么能力 |
| Policy / Review Rule | 决定哪些动作被允许、阻断或升级人工 |
| Post-processing / Merge Rule | 决定输出如何被验证、合并和外发 |
这张表里少任何一项，回滚都会变得不完整。因为系统真正执行的从来不是“某个模型”，而是一组互相解释彼此的规则。
Pinning 的目的不是保守，而是让结果可解释
不少团队一听到 pinning 就担心速度慢、试验受限。其实 pinning 真正保护的是可解释性。因为没有 pinning，你永远很难复原一次结果到底是在什么条件下产生的。尤其是长任务、异步回调和多步执行链路里，某个 step 如果在执行中间被切换到新版本，最终产物的行为就会变得非常诡异：一半像老系统，一半像新系统。
更合理的做法不是“一切永远钉死”，而是：
- 同一 run 使用固定 version set
- 新版本只在新 run、canary run 或 shadow run 中启用
- version set 变化写进 session / run metadata，便于后续 replay 和审计
这样既保留了迭代速度，也不至于让线上结果失去可归因性。
回滚要回滚整组环境，而不是只回一个模型
很多回滚失败都发生在这里。团队发现问题后，第一反应是把模型切回上一版。结果切完之后表现仍不稳定，因为 prompt、policy、tool schema 还停留在新版本。最终得到的是一个谁都没真正测试过的混搭环境。
更稳的 rollback 设计应该像这样：
- 用 version set ID 代表一整组发布单元
- rollout / canary / rollback 都以 version set 为单位
- 如果某个组件必须单独热修，也要生成新的 version set，而不是偷偷改一个局部
这听起来像多了一层管理成本，但它换来的是更清晰的排障路径。因为你终于能回答：“这次回滚后，系统到底回到了哪一套真实存在过的环境。”
Replay 和差分分析，离不开 version set 记录
当线上结果变差时，最有价值的问题不是“模型有没有抽风”，而是“和上一次稳定结果相比，判断环境差了哪几层”。只有 version set 被完整记录，你才能做真正有意义的 diff：
- 模型没变，但 prompt contract 变了
- prompt 没变，但 tool schema 的必填字段多了
- tool schema 没变，但 policy 把自动外发改成了 review required
这些差分比单看日志有用得多。因为 AI agent 的回归，很多时候并不是错误，而是环境整体漂移后的行为偏移。
一个很真实的事故：canary 做了，混版还是把回归藏住了
某团队给内容生成 agent 做了一轮 canary。模型升级 10%，prompt 也微调了一版，工具参数多加了一个 riskBand。按理说他们已经做了小流量验证，可上线后一周，仍出现大量“同任务不同结果”的问题。根因在于：
- canary 只按模型版本打标
- prompt 从配置中心热更新，没有绑定到 run
- 一部分 worker 读取了新 tool schema，一部分没有
- 回归时只切回模型版本，prompt 和 schema 仍留在新版本
最后系统不是在 old 和 new 之间切换，而是在多个半新半旧的组合里漂浮。
修复后，他们改成任何会改变 agent 判断环境的东西都必须进入 version set，run 只引用 version set ID。这个改动的意义不是更“正规”，而是终于让 canary 和 rollback 变成了真正可执行的动作，而不是口头概念。
真正该先做的，是把“环境”当成发布对象
如果你现在只能先补一层，优先别去追求更复杂的灰度平台，而是先把模型、prompt、tool schema、policy 和 post-processing 用同一个 version set ID 收口。只要这几层还分散在不同系统里各自升级，你的回滚就永远不完整，排障也永远需要靠经验猜测。
AI agent 的一次发布，真正发布出去的不是某个部件，而是一整套判断环境。只有把这套环境显式命名、固定和回滚，系统才会开始变得可维护。
延伸阅读：
