行业真实：Agent 能"上线"，可"换新"才是最考验功夫的
从第 11 篇我们把 Agent 抬上 HTTP 服务，到第 14 篇给它上了"护栏 + 兜底"，它从"能跑"变成了"靠得住"。但你在生产放上一天就会发现，最让运维冒冷汗的不是第一天，而是之后每一个"要改它"的时刻：
- 产品说"新 prompt 分词更好，换成跑一周对比"——你直接在代码里改 prompt？你敢吗？
- 测试提"换个更聪明的模型试试，只放 10% 的流量"——按比例能实现？切错可就没法回滚了。
- 前天新模型把白酒行情问崩了，老板让你秒回上一版——你要回滚到上一版，不是拨个开关，你要翻代码回滚？
这些场景的共同点：你想"变"，但要"变"得安全、可回滚、可灰度。这就是 Agent 工程里非常重要的一个能力——可配置、可版本化、可回滚、可灰度。
别急着写一堆框架。用一个标准库 + 一份 JSON 配置，就能把"切换模型/切换提示词/回滚/灰度"做成手不是抖的几个动作。这就是这一篇。
把"会变的"和"不变的"分开：Agent 的可配置架构
先看一个工程常识：任何成熟系统，都会把"会变的"和"不变的"解耦。
| 会变（该进配置） | 基本不变（留代码） |
|---|
