上线不是开关

Agent 也是软件：一切版本化，发布走「离线→影子→金丝雀→全面」的闸门序列，SLO 下降自动回滚。开关体系给渐进发布和紧急熔断提供抓手。

「部署完成」不等于「上线」。一次全量切换，把全部用户变成实验组；把发布当过程来做的团队，故障在到达用户之前就被闸门拦住。Agent 也是软件，传统软件那套发布工程对它一条都不能少——而且因为 Prompt、模型版本、工具端点都是行为的一部分，要版本化的东西反而更多。

先给一切建立版本管理

至少三类东西要进版本：Prompt、工具 Schema 与工具服务器、安全开关和模型选择 agents-in-action-8。Prompt 通常与代码同库版本化已经够用，也可以选择独立版本——目的是不改代码也能单独优化和回滚提示词。另一条常被漏掉：固定并记录每个对话轮次实际使用的模型版本与工具端点，否则结果不可复现，故障复盘时连「当时跑的是哪个版本」都答不出。没有版本记录的系统，回滚只是把另一个未知推上线。

发布走闸门序列，SLO 下降自动回滚

逐步发布的路径是固定的：离线测试→影子流量（Shadow Traffic）→小规模金丝雀（Canary）→全面上线；服务级别目标（SLO）下降则自动回滚 agents-in-action-8。每级闸门回答的问题不同：离线测试问「比现状好吗」，影子流量问「真实输入下会做错什么而用户无感」，金丝雀问「一小群真实用户的体验掉没掉」。对 Agent 还有一条特例：牺牲智能换性能的改动——换更小模型、降低推理档位——即使指标全绿，也要加浸泡期（soak period）再扩量，用户报告「变笨」通常远慢于评测报告。从失败到工程资产 里 Anthropic 回滚的正是这类默认值改动。闸门序列不是上线前才搭的：在线与离线两条腿 给影子与灰度的度量口径，闸门只是把口径变成通行条件。

开关体系是发布的地基

特性开关——可远程控制某项功能开停、无需重新部署——同时服务三个目的：实验、渐进发布、紧急熔断 ai-agent-book-7。没有开关，「渐进发布」退化为「重新部署一个旧版本」，熔断退化为一次值班事故。两个实现细节：编译时开关在构建阶段把代码物理移出产物，内部专用特性在外部构建中根本不存在，逆向也发现不了——这同时是干净的消融机制，关掉某特性不是运行时跳过，而是它物理上不在；A/B 分流则要求改动可按人群回收，支持快速回滚或渐进扩量。

自我修改也走这条流水线

发布工程对持续进化同样适用。Agent 修改自己不是运行中的进程直接覆盖自身：从当前稳定版本创建隔离更新分支，由 Coding Agent 生成最小补丁，依次通过静态检查、单元测试、安全扫描、失败轨迹重放和旧任务回归，才生成可灰度部署的新版本 ai-agent-book-9。进化提案也遵循同一闸门：边界案例改善、旧任务不退化、通过发布门槛，三者齐备才进灰度。这条流水线把「自我修改」从科幻词变成可审计的软件发布——正因为有它，下一章才敢讨论让系统自己改自己。