主题
影子模式与灰度验证
1. 一个常见的升级焦虑
你刚给 Agent 系统换上了新检索策略和更强的模型，演示效果让人眼前一亮。但上线两周后，问题开始冒头：产物引用变少了，审稿拦不住明显错误，生成成本涨了一倍。你想回滚，却不知道问题到底出在新模型、新 Prompt，还是新编排顺序；因为版本没记录，指标没留全，连“回到上一版”都不敢一键执行。
这就是 Agent 系统升级的典型陷阱：节点替换在工程上很容易，但质量变化往往藏在细节里。接口仍然返回 200，产物也能生成，可引用、审稿、风格和成本都在悄悄偏移。影子模式和灰度验证，就是为了让这些偏移在影响真实用户之前被看见、被解释、被回退。
一句话理解：影子模式让新版本先“陪跑”，灰度验证再让它接触少量真实任务，两者都把版本、指标和回滚开关写进流程。
2. 可替换之后还要验证
Agent 项目里，很多节点都可以替换：
- 资料召回从纯向量检索升级为混合检索。
- 执行 Prompt 从 v2 升级到 v3。
- 审稿规则增加事实核查和引用检查。
- 模型从一个供应商切到另一个供应商。
- 结构规划 Agent 从固定模板改成动态规划。
- 交付检查从人工清单改成自动规则和人工复核结合。
这些替换在工程上通常只是配置、Prompt、模型或节点编排的变化。更难判断的是：新版本是否让产物更可信、更清晰、更稳定，还是把问题转移到了另一个节点。Agent 系统的质量变化通常不会表现为单元测试失败，产物仍然能生成、接口仍然返回 200，但资料引用可能变少、审稿可能变松、风格可能漂移、成本也可能上升。上线策略需要覆盖这些渐进变化，并把结果写进任务 trace 和指标面板。
3. 影子模式：让新版本先陪跑
影子模式的做法是：旧版本继续服务真实用户，新版本在后台用同样输入陪跑，只记录结果，不影响正式输出。
适合影子验证的变更包括：
- 新检索策略。
- 新 rerank 模型。
- 新审稿 Prompt。
- 新结构规划节点。
- 新交付检查规则。
- 新多 Agent 编排顺序。
例如，新旧检索策略可以同时运行：
txt
用户任务
-> 正式路径：retriever_v1 -> 任务继续
-> 影子路径：retriever_v2 -> 只记录对比结果影子路径要复用同一份任务需求、场景配置、用户约束和资料范围。这样比较结果时，差异才更接近节点变化本身。对比时不要只看「召回条数」，还要看这些指标：
- 官方来源占比是否提升。
- 与结构部分的匹配度是否提升。
- 审稿阻塞问题是否减少。
- 生成产物是否更少出现无来源判断。
- 成本和延迟是否可接受。
影子模式的边界是不会影响用户交付。新版本即使失败，也只进入 trace、样本库和指标面板。等到新版本在离线样本和真实输入上都稳定之后，再考虑让它承担少量正式任务。
4. 灰度验证：小范围真实任务
影子模式证明新版本有价值后，才进入灰度。灰度意味着一小部分真实任务开始使用新版本。
分组方式要谨慎：
| 分组方式 | 适用场景 | 风险 |
|---|---|---|
| 按用户 | 长期任务习惯明显 | 用户间差异会影响结果 |
| 按任务 | 单个任务独立 | 同一用户体验可能不一致 |
| 按场景 | 场景风格稳定 | 放量速度较慢 |
| 按组织 | 企业客户或团队空间 | 样本量可能不足 |
Agent 项目通常优先按任务或场景灰度。单个任务互相独立，场景又能约束题材、风格和资料范围，这两种分组更容易解释质量变化。
同一个产物内部要保留一致的实验版本。例如资料节点、结构节点、执行节点和审稿节点都应写入同一个 experiment id。不要让资料节点用 v1、审稿节点用 v2、改写节点又回到 v1，否则一个产物变差时，团队很难判断问题来自检索、执行、审稿还是版本组合。
5. 灰度指标：不能只盯成功率和延迟
灰度前要先定指标。可以分成四组：
| 指标组 | 例子 |
|---|---|
| 质量 | 审稿阻塞率、人工推翻率、交付后修订率、用户采纳率 |
| 资料 | 官方来源占比、引用使用率、来源冲突率 |
| 性能 | TTFB、产物完成时间、审稿耗时 |
| 成本 | 每产物 token 成本、工具调用次数、缓存命中率 |
如果只看成功率和延迟，质量回退会被漏掉。Agent 系统的灰度需要把质量指标放进去，尤其是审稿阻塞率、人工推翻率和交付后修订率。
还要区分「指标下降」和「指标异常变好」。审稿阻塞率下降可能代表产物质量提升，也可能代表审稿 Prompt 变松。人工推翻率下降可能代表模型建议更准，也可能代表界面没有把风险充分暴露给用户。灰度期间要抽样看产物、资料、审稿意见和最终交付物，避免只从聚合指标判断质量。
6. 回滚和停止条件
灰度不能一路放量。上线前要写清楚停止条件：
- TTFB P95 超过阈值。
- 审稿阻塞率异常下降，可能代表审稿变松。
- 官方来源占比明显下降。
- 交付后修订率升高。
- 用户采纳率下降。
- 成本超过预算。
回滚也要可执行。Prompt 版本、检索策略、模型版本、审稿规则、工具调用配置和 Agent 编排都应该有版本号，并写入任务 trace。出现问题时，系统才能定位是哪一版进入了灰度，并把后续任务切回稳定版本。
对于已经生成但尚未交付的产物，要明确处理策略：保留旧版本结果、重新生成、只重新审稿，还是转人工复核。Agent 系统的回滚既影响服务流量，也影响交付队列里的存量产物。
7. 从 1% 到全量
一个保守放量路径可以是：
- 离线评估：用历史任务对比新旧结果。
- 影子模式：真实输入陪跑，不影响用户。
- 1% 灰度：低风险任务先使用新版本。
- 10% 灰度：观察质量、延迟和成本。
- 50% 灰度：确认没有场景或用户类型偏差。
- 全量：保留快速回滚开关。
每一步都要有退出条件。没有指标支撑的放量，只是把风险推迟到线上发现。对 Agent 系统来说，放量节奏还要避开高风险场景、重要发布窗口和客户交付节点。
8. 一句话总结
影子模式让新版本在后台陪跑，灰度验证让它逐步接触真实任务；两者都离不开版本记录、质量指标、停止条件和回滚开关。把这套机制嵌入 Agent 流程，替换检索、Prompt、模型、工具编排或审稿规则时，才能及时发现产物可信度、资料质量和审核效率的变化。