很多团队一提到发布治理，就会站到两个极端中的一个。要么只信离线评估，觉得回归集跑通了就可以上线；要么只信线上 Canary，认为真实流量才是唯一可信的检验标准。问题在于，这两种做法都只覆盖了发布风险的一半。离线评估擅长回答“已知问题是否又回来了”，却未必能提前看见真实流量中的分布漂移、集成异常和用户行为变化；在线 Canary 能看见生产环境的真实反馈，却不该替代那些本来可以在上线前被拦住的已知回归。
更稳的发布体系，不是二选一，而是把离线 eval 和在线 Canary 做成前后衔接的双层闸门。Weights & Biases Weave、Braintrust 和 Arize Phoenix 虽然入口不同，但都在强调 trace、样本、评估和线上诊断必须连成闭环。对 TaskPilots 这样的生产编排系统来说，离线评估负责拦住已知退化，在线 Canary 负责验证真实流量中的未知风险；两者一起工作，团队才能在速度和稳定性之间取得可控平衡。
为什么这个问题重要
真实运行代价
如果只做离线评估，团队很容易在“测试集通过了”之后产生虚假的安全感。模型、提示词、路由规则和工具组合在固定样本上表现稳定，不代表它们在真实流量、真实时序和真实依赖波动里也同样稳定。相反，如果只做在线 Canary，你就会把本来可以在上线前拦住的问题留给真实用户和运营同事去发现，回滚成本和客户影响都会变高。
- 只靠离线评估时，分布漂移、缓存差异和集成边界问题容易在线上才暴露。
- 只靠在线 Canary 时，已知回归会反复漏到生产环境，浪费流量和人工排查时间。
- 没有双层闸门时，团队很难区分这是评估集覆盖不足，还是线上环境真的变了。
如果不处理会怎样
最常见的后果不是某一次上线彻底失败，而是团队逐渐失去发布节奏。起初只是小流量观察时间越来越长，之后变成离线和线上结论经常互相打架，再往后就会出现“评估全绿但业务变差”或者“Canary 总能发现问题，但每次都已经太晚”的情况。发布治理一旦落到这种状态，速度和信心都会一起下降。
继续这样演进，通常会出现四类问题：第一，回归判断靠经验而不是证据；第二，线上异常无法快速定位是模型问题还是环境问题；第三，评估集越来越大，但关键失败簇仍然覆盖不到；第四，Canary 结果和业务指标没有建立稳定门槛，团队只能临场判断是否暂停或放量。
适用场景
谁最需要这套方法
这套方法最适合那些已经进入生产阶段、版本更新频率较高、并且系统行为会受到真实流量和外部依赖显著影响的团队。尤其适合三类场景：第一，多步骤或多 Agent 工作流，每次改动都可能影响不同 step 和 handoff；第二，强依赖检索、工具调用、外部 API 或人工审批的链路；第三，业务后果明确、不能把真实用户当测试样本的流程。
- 客服、运营和审批类工作流需要同时防已知回归和真实流量中的新退化。
- 高价值链路需要把版本表现与升级率、转化率或人工接管率一起判断。
- 平台团队需要在放量前后都保留清晰的追踪与回滚依据。
什么时候先不要这么做
如果当前系统仍然是低频原型、用户规模很小、变更也不频繁，那么暂时不需要把离线和在线两套门槛都做得很重。此时先把最小评估集、关键日志和基础回滚机制建好，通常比马上搭完整 Canary 流程更有收益。另一个不适用边界，是任务目标和成功标准还没稳定的探索期，此时离线样本与线上观察本身都可能频繁改写，过早固化闸门会造成维护负担。
推荐系统结构
核心角色与状态
更稳的结构，是把发布验证拆成连续两层。第一层是离线评估层，围绕历史失败簇、关键能力样本和高风险边界样本构建回归集，用来回答“这次改动是否重新引入已知问题”。第二层是在线 Canary 层，在受控流量、受控用户或受控场景下观察真实运行链路、关键业务指标和异常分布，用来回答“这次改动在真实环境里是否出现新问题”。两层之间需要共用同一套 trace、失败分类和版本标识，避免结论各说各话。
- 离线层负责拦截已知退化，必须绑定失败簇、样本集和最低通过门槛。
- 在线层负责观察未知风险，必须绑定灰度比例、观察窗口和回滚条件。
- 两层都要把结果挂回同一版本和同一运行链路，才能形成真正闭环。
与 TaskPilots 的映射
放到 TaskPilots 里，可以把链路追踪看成离线和在线共用的数据骨架，把运营审查看成高价值样本和失败分类的来源，把持续评估看成发布前闸门与放量后观察窗。也就是说，离线评估不该只看抽象的回答质量，在线 Canary 也不该只看接口错误率；两者都应该对齐到同一套 run、step、handoff 结构和失败 taxonomy。这样，团队既能在发布前回答“已知问题有没有回来”，也能在发布后回答“真实链路里有没有新的异常形态”。
站内像 别只追工具日志，要追决策链 和 生产环境的 Agent 仪表盘该怎么看 讨论的决策 trace 与生产仪表盘，也正是连接这两层发布验证的基础。没有统一的 trace 结构，离线和在线结果很难真正对齐。
风险与失效点
常见失控方式
第一种失控，是把离线评估做成“样本越多越好”的堆砌，却没有围绕高频失败簇设计，结果测试集很大，真正关键的回归仍然漏掉。第二种失控，是把在线 Canary 当成自动放量的装饰，只看调用成功率，不看失败分类和业务后果。第三种失控，是离线与在线使用不同的标签体系，导致评估通过却无法解释 Canary 告警，或者 Canary 报警却回不到离线样本修复。第四种失控，则是观察窗口太短，刚通过就放量，把慢性退化漏掉。
- 离线样本和线上真实问题彼此脱节，团队修的是测试，不是生产。
- Canary 只看技术指标，不看人工升级率和业务转化，容易放过真实坏版本。
- 版本标识和 trace 归档不清晰，导致离线和在线结论无法复盘对照。
需要人工兜底的地方
涉及高影响发布、核心业务流量、客户承诺、审批规则和高风险自动执行时，必须保留人工兜底。人工判断的价值，不是替代离线评估或 Canary，而是在两者给出冲突信号时快速判断哪边更可信、问题影响是否足够大、是否需要直接回滚。比较稳的做法，是让人工能同时看到回归样本结果、代表性线上 trace、失败分类趋势和业务指标变化，再做放量或暂停决策。
验证指标
上线前怎么验证
上线前至少要验证三件事。第一，离线回归集是否真的覆盖了最近高频失败簇，而不是只覆盖一些“看起来合理”的样本。第二，版本通过离线门槛后，是否已经为在线 Canary 明确了观察指标、流量范围和回滚阈值。第三，离线结果与线上 trace 是否能通过同一版本和同一失败标签相互映射。Weave、Braintrust 和 Phoenix 的组合思路，最适合支撑这种从样本到线上观察的连续验证。
- 检查高频失败簇是否进入离线评估，而不是只依赖泛化样本。
- 检查每次灰度是否都有清楚的停止条件，而不是“先看看再说”。
- 检查离线通过的版本是否仍然保留线上对照和样本抽查入口。
上线后怎么持续判断
上线后建议长期跟踪至少四类指标：故障定位时间、评估通过率、线上回滚率和业务转化指标。除此之外，还应补两项更贴近双层闸门本身的指标：离线拦截率，以及 Canary 发现率。前者衡量已知退化有多少能在发布前被拦住，后者衡量线上新型问题有多少是通过小流量阶段被及时发现。如果前者长期偏低，说明评估集需要重构；如果后者长期为零却线上事故仍多，说明 Canary 设计只是形式存在。
下一步 / FAQ
下一步建议
最实用的第一步，不是马上把两套体系都做复杂，而是先挑一条高价值链路，补齐一个最小双闸门。离线侧先整理最近二十到三十个真实失败案例，提炼最小回归集；在线侧再定义一个受控 Canary 窗口，明确观察指标、抽样 trace 和回滚门槛。先把这一条链路跑顺，再逐步复制到更多工作流，会比一开始就全面铺开更稳。
FAQ
离线评估通过了，为什么还要做 Canary？ 因为离线评估更擅长拦住已知问题，真实流量中的分布变化、环境噪声和集成边界仍然需要在线验证。
已经有 Canary，为什么还要做离线回归？ 因为很多已知退化完全可以在上线前被拦住，不必把真实用户和运营同事当成第一道测试。
会不会拖慢发布速度？ 初期会增加一些流程设计成本，但通常能显著减少回滚、补救和人工复盘的总成本。
最常见的组织阻力是什么？ 往往不是技术，而是团队没有统一失败标签和回滚口径，导致离线和在线各自得出结论却无法合并行动。