一、Agent 发布为什么比改一句提示词危险

单轮对话的灰度发布，逻辑很简单：新旧两个版本跑同一批测试样本，比分数。但 Agent 不是一次调用就结束，而是一条包含多次工具调用、多轮推理的轨迹。system prompt 的措辞、工具描述、参数结构、新增或下线一个工具——任何一环变了，整条轨迹的走向都可能完全不同。

所以在这类系统里，金丝雀发布不只是「切一部分流量试试」，还要解决一个更难的问题：出了问题，到底是哪一环导致的。常见的连锁后果有四类：

共同点只有一个：工具调用本身有副作用，不像纯文本生成那样可以无损重试。所以 Agent 的发布策略必须比普通提示词更保守。

二、上线前：先在沙箱里跑一遍完整轨迹

任何涉及工具变更的发布，第一步都不是直接上生产灰度，而是在只读或沙箱环境里跑一批历史真实任务。评的不是最终回复文本，而是整条轨迹。四个必看的字段：

• 工具调用序列是否匹配：候选版本调用的工具顺序，和历史基线差多少；
• 调用总次数：是否明显变多；
• 最终是否成功：任务状态是否真的到达成功；
• 意外触发的破坏性调用：候选版本是否调用了旧版本从未碰过的删除、支付、发送消息类工具。

最后一项最需要盯紧。只要候选版本触发了旧版本从未触发过的破坏性调用，哪怕任务最终成功了，也应该直接标为高风险变更，必须人工逐条复核具体轨迹，再决定要不要放量。

三、灰度其实是两个维度，不是一个

普通服务的灰度只有一个旋钮：流量百分比。Agent 可以拆成两个独立维度，组合使用。

举个具体例子：新增了一个「自动退款」工具。即使 Agent 的其他部分已经放量到 50%，这个工具本身也可以单独设成「先只读试运行」——Agent 照常走完推理、生成调用参数，但真正执行前插一道人工确认。观察一段时间，看参数生成的准确率稳定了，再放开自动执行。

这种分层放量的价值在于：最危险的那一小部分能力可以单独控节奏，不必等整个 Agent 都验证充分才敢上线任何一个新工具。

四、放量期间盯这四个指标

错误率、延迟这些常规指标当然要看，但 Agent 有几个特有的早期信号，往往比它们更早报警：

• 平均工具调用轮数：新版本若显著上升，通常意味着它在某类任务上开始循环试错；
• 失败后的恢复率：工具报错后，它是正确重试、切换策略，还是直接放弃或胡乱重试；
• 同任务工具序列的方差：同一类任务多跑几次，调用序列是否稳定。方差骤增说明决策开始不确定，即使平均分没掉，也值得警惕；
• 越权或异常工具调用计数：调用了不在白名单内的工具组合，功能上「跑通了」也要人工审查，因为它可能只是走了一条侥幸成功的危险路径。

五、回滚：改回提示词不算完

Agent 的回滚比单轮对话复杂，因为一次任务的状态可能已经被工具调用改变了——订单已创建、消息已发送。把版本切回去能阻止新错误继续发生，但已经产生的副作用不会自动撤销。所以发布前就要把三件事定清楚：

• 哪些调用是可撤销的：比如取消订单、删除草稿，要为它们设计好补偿逻辑；
• 哪些是不可撤销的：比如已发送的通知、已扣的款，这类工具在灰度阶段就该有更严格的确认机制，而不是指望出问题后再回滚；
• 回滚后正在进行的会话怎么办：是多轮会话直接切回旧版本跑完，还是重新开始，必须提前定义，避免同一个会话中途「换脑子」导致上下文不一致。

结语

把上面几条压缩成一句话：先在沙箱看轨迹，再分层放流量，放量时盯方差，上线前想好怎么退。四件事做到了，Agent 的发布风险就从「不可控」变成「可承受」。