Agent Prompt 与工具的金丝雀发布怎么做

单轮 Prompt 的灰度发布，核心是”新旧两个版本对比一批测试样本的得分”，这套方法在 Prompt 变更如何做回归测试与灰度发布里讲过。但 Agent 系统的发布要复杂一层：Agent 不是一次调用就结束，而是一条包含多次工具调用、多轮推理的轨迹（trajectory），任何一环——system prompt 措辞、工具描述、工具参数 Schema、新增/下线某个工具——发生变化，都可能让整条轨迹的走向完全不同。金丝雀发布在这里不只是”切一部分流量试试”，还要解决”出问题了到底是哪一环导致的”这个更难的定位问题。

一、Agent 发布为什么比单轮 Prompt 更危险

单轮 Prompt 出错，最坏结果是这一次回复质量差。Agent 出错，尤其是工具调用相关的变更出错，后果可能是连锁的：

错误的工具选择：Agent 本该调用”查询订单”却调用了”取消订单”，这类错误一旦执行就无法通过重试挽回
参数拼装错误：工具描述或 Schema 的微小调整，可能让模型对某个参数的理解发生偏移（比如把”退款金额”理解成”订单总额”）
轨迹发散：新 prompt 让 Agent 在某类任务上陷入循环调用（反复尝试同一个失败的工具），消耗大量 token 却没有推进任务
权限越界：新增的工具如果权限设计不当，可能让 Agent 在未被充分测试的场景下执行了破坏性操作

这些问题的共同点是：执行工具调用的动作本身可能有副作用，不像纯文本生成那样可以无损重试。所以 Agent 发布策略要比普通 Prompt 更保守。

二、发布前：先在只读/沙箱环境跑一遍完整轨迹

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

def evaluate_trajectory(task, agent_run_fn, baseline_trajectory):
    candidate = agent_run_fn(task)
    return {
        "tool_call_sequence_match": compare_tool_sequence(
            candidate.tool_calls, baseline_trajectory.tool_calls
        ),
        "tool_call_count": len(candidate.tool_calls),
        "final_success": candidate.final_state == "success",
        "unexpected_destructive_calls": [
            c for c in candidate.tool_calls if c.tool in DESTRUCTIVE_TOOLS
            and c.tool not in baseline_trajectory.tool_names
        ],
    }

其中 unexpected_destructive_calls 是最需要重点关注的一项——如果候选版本触发了旧版本从未触发过的破坏性工具调用（删除、支付、发送消息类），哪怕最终任务成功了，也应该被标记为高风险变更，需要人工复核每一条具体轨迹再决定是否放量。

三、灰度维度：不只是流量比例，还有工具权限分级

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

维度	说明
流量比例	多少比例的任务由新版本 Agent 处理，同 Prompt 灰度逻辑
工具权限分级	新版本 Agent 即使拿到流量，某些高风险工具是否仍强制走旧版本或人工审批

例如新增了一个”自动退款”工具，即使 Agent 的其他部分已经放量到 50%，“自动退款”这个工具本身也可以单独设置为”先只读试运行”——Agent 正常走完推理流程、生成调用参数，但实际执行前插入一道人工确认，观察一段时间参数生成的准确率之后，再放开自动执行权限。这种”分层放量”能把最危险的那一小部分能力单独控制节奏，不必等整个 Agent 都验证充分才能上线任何新工具。

四、监控指标：Agent 特有的几个信号

除了常规的错误率、延迟,Agent 系统需要额外监控这些信号,才能在放量过程中及时发现问题:

平均工具调用轮数：新版本如果平均轮数显著上升，可能意味着 Agent 在某类任务上出现了循环试错
工具调用失败后的恢复率：工具报错后，Agent 有没有正确地重试或切换策略，还是直接放弃/胡乱重试
同任务工具序列的方差：同一类任务在多次运行里，调用的工具序列是否稳定。方差骤增说明 Agent 的决策变得不确定，即使平均表现没有明显下降,也是需要警惕的早期信号
越权/异常工具调用计数：候选版本调用了不在预期工具白名单内的组合，即使功能上”跑通了”也要人工审查是不是恰好走了一条侥幸成功的危险路径

五、出问题时如何回滚——不能只回滚 Prompt

Agent 的回滚比单轮 Prompt 复杂,因为一次任务的状态可能已经被工具调用改变(订单已创建、消息已发送)。回滚 Prompt 版本能阻止新错误继续发生,但已经产生的副作用不会自动撤销。发布前就应该明确:

哪些工具调用是可撤销的（如取消订单、删除草稿），为这些操作设计好补偿逻辑
哪些是不可撤销的（如已发送的通知、已扣款），这类工具在灰度阶段应该有更严格的确认机制，而不是寄希望于”出问题了再回滚”
回滚后的会话如何处理：正在进行中、还没走完的多轮 Agent 会话,版本切换后是继续用旧版本跑完,还是重新开始,需要提前定义策略,避免同一个会话中途换脑子导致上下文不一致