智能体上线怎么灰度：Preview 部署、离线评测、回测与一键回滚

智能体不能照搬普通服务的发布流程——代码评审加流量灰度那套不够用，因为真正决定行为的是模型的实时推理，而不是代码。可用的最小闭环是：每个 PR 起一个 Preview 部署 → 跑离线评测与回测 → 小流量放线上 → 用在线评测盯指标 → 一键回滚。少了中间任何一环，你都是在盲发。

为什么”代码评审 + 灰度”对智能体不够

• 决定行为的是推理，不是代码：同样一份代码，换个提示词、换个模型，行为就完全不同。不实际跑起来，没人知道它会做什么。
• 输入是自由文本：用户能往框里输入任何东西，交互空间无法穷举，本地测试覆盖不到真实分布。
• 代价已经显现：麦肯锡 2025 年 11 月的调研显示 62% 的受访者在试验智能体，但任一业务职能中真正规模化的不超过 10%；Gartner 预测到 2027 年底超过 40% 的智能体项目会因为成本失控、价值不清或风险控制不足被砍掉。

第一步：每个 PR 一个 Preview 部署

Preview Builds 这类能力解决的是一个很具体的痛点：本地测试没法让产品、 QA 、领域专家在同一个地方看同一个版本在干什么。

• 隔离环境：每个 PR 从源分支起一个临时部署，挂在父部署下面，不会动到父部署本身。
• 跟随推送自动更新：分支有新 commit 就生成新的 revision，评审人不用重新搭环境。
• 触发策略可选：每次 PR 都建，或只在打了指定标签后建。前者适合大多数改动都需要行为评审的团队。
• 生命周期可控：Idle TTL 决定闲置多久自动回收，并发上限控制成本，也可以手动删。

第二步：离线评测和回测，两件事都要做

这两者经常被人混为一谈，其实解决的问题不同。

回测的具体做法：从生产的 tracing 项目里抽一批 run，把输入转成数据集、把当时的输出记为基线实验，然后让新版本在同一份数据集上跑一遍，两个实验直接对比。相比”拿上线前的数据集评测”，回测更能说明这次改动相对于当前线上是进步还是退步。

离线评测通常要覆盖四类：终态响应评测（最终结果对不对）、单步评测（单个节点逻辑对不对）、轨迹评测（调了哪些工具、顺序对不对）、多轮评测（跨轮次的上下文保持）。多智能体系统里，只看最终输出会掩盖子智能体选错、工具乱调的问题。

第三步：把质量闸门写进 CI

一个完整的智能体 CI/CD 流水线，触发源不止”推代码”：

• 代码变更：改图结构、换模型、调智能体逻辑
• 提示词仓库更新：提示词有新的 commit 就触发 webhook
• 在线评测告警：线上指标劣化自动触发流水线
• trace webhook：基于 trace 分析和性能指标自动触发
• 手动触发：紧急发布

测试层次也要铺开：单元测试、集成测试、端到端测试之外，加上上面那四类离线评测，再加一个”开发服务器可用性”检查（起服务、轮询健康接口直到可用）。 PR 通过就生成 Preview 部署，合并进主干时删掉 preview 、创建生产部署。

第四步：灰度与回滚

1. 先放小流量，5%–10% 起步，别一次全切。
2. 盯三类在线指标：任务完成率、工具失败率、 helpfulness 打分。在线评测的作用是发现”昨晚是不是变差了”，不是给改动下定论。
3. 回滚要能一键：提示词、模型、工具这三样必须能独立回退。把提示词硬编码在代码里，回滚就只能整体发版，恢复时间会被拉长好几倍。

顺带一句关于 LLM-as-a-judge：它能在人工审不过来的规模上打分，但只和你给的评判标准一样可靠。正确用法是先人工标注一批真实 trace，跑评判器，看它在哪里跟人工不一致，反复调评判提示词直到对齐——跳过这一步，你会得到一堆看起来很严谨、实际什么也没说明的分数。相关做法在提示词版本管理与回归测试里也有展开。

一个反直觉的建议

别急着上多智能体。经验是：先用单智能体配好提示词，需要能力就加工具，加工具比拆智能体更便宜也更好调试。只有当上下文溢出、能力膨胀、团队边界这些限制真的成为瓶颈时，才升级到子智能体、路由或 handoff 。我们之前在上下文工程里讲的限制，多数情况靠检索和工具设计就能解决。

1. 该 PR 是否有 Preview 部署，产品/QA 是否实测过
2. 四类离线评测是否全绿（终态 / 单步 / 轨迹 / 多轮）
3. 是否跑过回测，相对当前线上是进步还是退步
4. 提示词、模型、工具是否都能独立回滚
5. 在线评测告警是否已配置，阈值是否合理
6. 敏感动作是否有人工确认（human-in-the-loop）

相关阅读

• 智能体可观测性与链路追踪
• 人机协同：什么动作必须让人确认
• 工具调用的重试与降级