AI Agent 工程实践（32）：Agent 如何上线

系列AI Agent 工程实践上一篇第 31 篇《Agent 如何部署》下一篇第 33 篇《Agent 如何监控》一、开场一次全量切换的事故某团队新版 Agent 提示词优化了测试也过了。周五晚上直接把流量 100% 切到新版本。周一上班投诉爆了新版本在某个边缘场景答非所问而旧版本没问题。因为没有灰度所有用户第一时间踩雷没有快速回滚修复等了半天。上篇31讲怎么让它活着这篇讲怎么把活的版本交给用户才安全——上线。二、问题背景直接全量 vs 渐进发布直接全量# 配置里写死版本 agent_version: v2 # 一键切所有流量进 v2渐进发布流量按比例、按人群逐步释放每个阶段都有刹车。差别全量切 赌渐进发布 用可控代价验证。三、错误尝试三种上线翻车错误 1直接全量切无回滚版本一换出问题只能再发一版修复中间所有用户受影响。最怕的是新版本引入的 bug 比修的还多。错误 2不做版本区分新老逻辑靠if硬改代码回滚要改代码重新部署慢且易错——发布变成高风险动作。错误 3无对照不知好坏上了新版本靠感觉变好了没有量化对比劣化无人知等客诉才暴露。四、关键观察上线 受控释放 可观测回滚上线不是部署完开流量而是一个带闸门的流水线。每个阶段都是一道安全阀v1内部/小流量先让内部人或 1% 用户踩问题先暴露给自己人。灰度5%~10%扩大到真实小比例用户验证稳定性与基本质量。A/B对照新旧同跑量化对比关键指标证明新比旧好。全量确认无劣化、成本可控才 100% 切。关键每个阶段都能一键回滚到上一版回滚是配置开关而不是重新发版。这才是上线和部署的本质区别——部署让它能跑上线让风险可控。五、最终方案四阶段上线流水线v1 内部验证 ↓ (无 P0 故障) 灰度 5%~10% ↓ (成功率/延迟达标) A/B 对照实验 ↓ (核心指标不劣化甚至有提升) 全量 100% ↓ 全程可回滚 ──────────┐ (任一步异常) ───────┘ 回滚到上一稳定版版本管理三件套版本号每个发布打标、路由权重流量分配、回滚开关feature flag 或路由回指旧版。三者齐备上线才从心跳游戏变成工程动作。六、架构图Mermaid七、代码与配置示例用路由权重做灰度伪配置releases: v1: { weight: 90, endpoint: agent-v1 } v2: { weight: 10, endpoint: agent-v2 } # 灰度 10% # 异常时把 v2.weight 改回 0 即回滚无需重新部署用 feature flag 控制新逻辑def build_prompt(user_input, flags): if flags.enabled(new_prompt_v2): # 开关决定走哪版 return PROMPT_V2 return PROMPT_V1 # 关掉即回滚A/B 指标对比必须量化# 同一批请求新旧各跑一份对比 metrics_v1 run_experiment(v1, dataset) metrics_v2 run_experiment(v2, dataset) assert metrics_v2.success_rate metrics_v1.success_rate - 0.01八、设计权衡何时不必灰度场景建议理由面向公网、高频必走完整流水线翻车影响大内部工具、低频v1 小流量即可影响面小仅修复 bug灰度可缩短风险低提示词大改必做 A/B质量难凭感觉反过度工程内部小工具不必照搬大厂四阶段但回滚开关一定要有——这是底线不是奢侈品。再小的发布也要能在一分钟内退回上一个好版本。九、总结✅ 直接全量切 赌一次翻车影响所有用户。✅ 三种翻车无回滚、不做版本区分、无对照。✅ 上线 受控释放 可观测回滚四阶段 v1→灰度→A/B→全量。✅ 版本号 路由权重 回滚开关三件套让回滚成配置而非发版。✅ 底线回滚开关必须有哪怕跳过灰度。下一篇全量之后——上线了要看什么才叫稳。33参考资料带用途说明本系列31Agent 如何部署本文假设服务已部署讲部署后的流量释放。本系列30Agent 如何做测试A/B 对照依赖30的 Golden Dataset 与回归测试。本系列29成本控制A/B 实验需同时对比成本避免质量好了但烧钱翻倍。本系列33Agent 如何监控灰度和全量阶段靠33的指标判断是否达标。LaunchDarkly 文档launchdarkly.comfeature flag 与渐进发布的工程实践参考。本文是 AI Agent 工程实践系列的第 32 篇第四阶段第十二篇。系列导航上一篇第 31 篇《Agent 如何部署》下一篇第 33 篇《Agent 如何监控》