Agent 的 Shadow Mode：让新版 Agent 和旧版同时运行，对比效果差异

我最早以为 Shadow Mode（影子模式）是 A/B 测试的穷人版。反正都是新旧两个版本一起跑，然后比分数、定胜负，能有多大区别？直到我自己真搭了一套，才发现这个理解错得离谱——A/B 测试的核心是让真实用户投票，Shadow Mode 的核心是让真实用户完全不知情：新版本在旁边偷偷跑，它的输出不返回给任何人，只进日志和评测系统。

这个“偷偷跑”的思路是从微服务时代传下来的。Martin Fowler 在金丝雀部署的文章里就提到过 dark launch：把新版本部署上去，但用户看不见，让它在后台跑，拿它的行为和旧版对比。到了 Agent 这里，事情突然变复杂了——因为 Agent 的“输出”不是一个 HTTP 响应，而是一条完整的行动轨迹：怎么拆解任务、调了哪些工具、每个工具返回什么、中途怎么修正、最后给出什么回答。两个版本的差异，可能藏在这条轨迹的任何一处。

先把 Shadow Mode 跟另外两个容易混淆的方案放在一起看：

方案	新版本是否影响线上	对比发生在哪	适合什么场景
Shadow Mode	否，完全不碰真实用户	离线，跑完整轨迹后评测	版本上线的第一道闸门
金丝雀部署	是，承接少量真实流量	在线，需要实时监控	有把握之后的灰度放量
A/B 测试	是，流量被拆分	在线，依赖用户行为数据	产品层面的效果比拼

看这张表你会发现，Shadow Mode 是三者里唯一一个“出了错也没有真实用户受伤”的方案。这一点对 Agent 尤其重要——因为 Agent 在真实环境里犯错，代价是实打实的：多订一张机票、误删一个文件、给客户群发一条错误的账单。

但 Shadow Mode 真正难的地方，不是流量镜像，而是怎么算赢。

我一开始以为，对比两个 Agent 就跟给模型打分一样简单：同一个测试集跑一遍，看准确率。后来发现自己错得离谱。Agent 面对的任务没有标准答案——用户诉求是模糊的，达成目标的路径是无穷多的。你没法用“准确率”衡量，因为你根本不知道正确答案是什么。

我踩过一个具体的坑。有一版新 Agent 在 80% 的任务上跟旧版表现一样，但有一个明显差异：它调工具的平均次数多了 60%。只看最终答案的话，两者分数几乎相同。可一旦上线呢？多出的每一次工具调用，都是额外的延迟、额外的 token 成本、额外一次出错的机会。更隐蔽的是，它可能多调用了一个“删除”类工具——在影子模式下这个调用被 mock 掉了，没有真的删掉任何东西，但轨迹日志里清清楚楚写着：它打算删，而且模拟执行成功。

具体到工程上，影子 Agent 通常跑在一个隔离环境里：模型调用是真的，工具服务全部换成 mock——查询类工具返回预设数据，写入类工具只记录参数不落库。这样既能看到它真实的思考和调用倾向，又不会产生任何副作用。

一套合格的 Shadow 评估，至少要包含这几步：

镜像真实流量（或从真实流量中采样），保证新版本看到的输入分布跟线上一致；
让影子 Agent 以 dry-run 模式完整跑一遍——推理可以真做，工具调用必须 mock 或放进沙箱；
把新旧两条轨迹完整记录下来：每一轮思考、工具名、参数、返回值、最终答复；
用自动化规则加上裁判模型（LLM-as-judge）对轨迹打分——注意是要按评分标准逐项打分，不是问模型哪个好；
积累足够样本后做统计检验——语言模型自带随机性，跑 3 次就想下结论，不靠谱。

评估维度也远不止“答案对不对”：

维度	看什么	为什么重要
任务成功率	用户目标是否最终达成	底线指标，但它掩盖了大量细节
轨迹质量	步骤是否冗余、工具选择是否合理、有没有走弯路	轨迹差的 Agent，迟早会在真实世界出事
工具调用的合法性	参数是否合法、权限是否越界、有没有碰危险工具	影子模式不执行动作，这类问题只能从轨迹里发现
成本与延迟	token 数、工具调用数、总耗时	效果再好，成本翻三倍的版本也未必值得上线

但 Shadow Mode 有一个根本性盲区，你必须知道。

影子 Agent 没有真正执行动作，这意味着所有“真实世界副作用”类的问题，它都测不出来。比如新版 Agent 把“发送账单”的收件人地址填错了——在影子模式下，这个错误只存在于调用参数里，邮件没发出去，没有任何系统能感知到它的后果。你只能靠人工抽检轨迹来发现这类隐患，而人工没法覆盖全部流量。

更隐蔽的问题是：Shadow Mode 假设输入分布不会变。但真实世界里，如果新版 Agent 的提问方式跟旧版不同，用户接下来的行为就会不同。你在影子模式下喂给新版本的，是旧版用旧话术引导出来的对话历史——这相当于让一个性格不同的新人，去接听别人用旧话术拉来的电话。他能做对比，但你永远看不到他自己会引出什么样的新对话。

还有一个让我头疼很久的问题：随机性。同一个 Agent，温度设成 0，同一个输入，跑两遍结果也可能不一样。推理服务端的动态批处理、浮点累加顺序，都会引入微小差异。我的经验是每个用例至少跑 3 到 5 轮，等结果有统计显著性再下结论——否则你看到的“新版更差”，可能只是掷骰子掷出来的。

温度设成 0，结果不就确定了吗？

不完全是。温度 0 只是让采样变成贪心解码，但服务端的动态批处理和内核层的浮点计算顺序，依然会造成微小波动。对长轨迹的 Agent 任务来说，一个词的波动就可能让整条轨迹分岔。OpenAI 的 API 提供了 seed 参数，但官方文档明确说它不保证完全可复现。

Shadow Mode 和金丝雀部署到底有什么区别？

金丝雀是让新版本承接 5% 的真实流量，出了事最多影响 5% 的用户；Shadow Mode 则完全不碰真实流量，新版本的输出只进日志和评测系统。一个是带伤试错，一个是零风险旁观。

影子评估要跑多久才能下结论？

取决于流量和任务类型。我的大致经验是：每个典型任务类型至少积累 50 到 100 个样本，再结合自动化评测和人工抽检。低于这个量级，结论的置信度很低。

把话说回我自己：我最早以为 Shadow Mode 是一个部署工具，后来才意识到它是一个评价体系的容器——真正的功夫全在评估设计上。它值得当 Agent 上线的第一道闸门，但不该是唯一一道。上线前用 Shadow 挡掉明显更差的版本；上线后用少量真实流量做金丝雀，盯住真实世界的副作用指标。两道闸门配合，才是我现在比较信任的方案。如果你想从这篇文章带走一件事，那就是：先把注意力放在轨迹评估上，那才是 Shadow Mode 真正值钱的地方。