优雅降级与备用方案

换掉模型，就是换掉智能体。

对一次无状态补全来说，备用模型大体可以互换：文笔差些，形状一样。而对智能体来说，模型是那个决定"调哪个工具、何时停下、要不要拒答"的部件——所以替换它就是替换控制逻辑，而下游的每一条假设都原地不动。

• 最先坏掉的是工具调用行为，而且坏得很安静。各家模型在 schema 方言、对必填字段的严格程度、是否发出并行调用、以及"能容纳多少个工具而选择准确率不崩"这几件事上都不同。一个在主力上很可靠的十二工具智能体，换到备用上可能开始猜参数，而症状不是异常——是一个看起来很合理的错误动作。
• 上下文上限不同，备用模型可能根本装不下这个任务。一次在 20 万 token 处做压缩的运行，切到有效窗口更小的模型上并不是"降级"，而是"截断"。掉出窗口的东西对你所有的日志都不可见——"标称上下文"与"可用上下文"的区别见长上下文：有效 vs 标称。
• 拒答与安全画像在各家之间并不对齐。一个拒绝了主力会处理的类别的备用模型，会把一次故障变成一条工单队列；一个接受了主力会拒绝的类别的备用模型，会把一次故障变成一起事故。这两件事在延迟仪表盘上都看不见。
• 结构化输出通常是最先暴露的地方。约束解码的支持程度因厂商、因模型档位而异，而一个不支持它的备用模型会返回 96% 情况下正确的 JSON——这对演示没问题，对一条要解析它的流水线就是故障。
• 步数会变，成本随之而变。更弱的模型要多绕几轮才到得了同一个地方，而每一轮都在重新发送一段不断变长的对话记录。一个更便宜的备用模型，按"每完成一个任务"算下来经常更贵——这就是智能体成本控制里那道算术，对准了你最糟的那一小时。

先决定要卸掉什么，再决定要换成什么。

模型切换是本能反应，却很少是回报最高的控制手段。智能体的墙钟时间与失败大多来自工具层，而在一个降级的小时里你需要移除的负载，大多是任务本来就不严格需要的工作。

• 事先按任务类型写一份有优先级的"卸载清单"。哪些富化步骤、哪些可选检索、哪些校验轮次、哪些重排、哪些自我批判。容量吃紧时按固定顺序从末尾开始丢。在设计评审上定下来的清单，价值是事故中临时拍脑袋的十倍。
• 推理力度是一个旋钮，排在"模型是一个开关"之前。削减思考预算、把自洽性采样从五份降到一份、或关掉反思轮次，都能在保持同一个模型、同一套工具方言、同一份拒答画像的前提下腾出很大一块容量。先伸手去拿它——权衡关系见自适应思考与力度预算。
• 按租户、按任务类别卸载，而不是一刀切。一刀切的降级会把剩余容量花在本可以等的批处理作业和免费层流量上，而那个有人正盯着的交互式请求挨的是同一刀。事先定好的优先级分级，是"降级的一小时"与"丢掉的一小时"之间的区别。
• 非交互的活，排队，别降级。一个夜间批处理需要的不是更弱的模型，而是从 02:00 挪到 04:00 跑。延后是可选降级手段里最便宜的一种，而且完全不牺牲质量。
• 缓存在这里承重的方向恰好是错的。降级期间流量会集中，语义缓存的命中率反而上升，这是好事——但它端出来的条目是主力模型生成的，于是你的降级输出是两个模型的混合体，且没有任何标记说明哪句出自谁。给缓存条目打上"生成它的配置"的戳。

读操作失败时放行，一切有副作用的失败时闭合。

失败的方向是一个逐部件的决策，而无论朝哪个方向搞反，都是降级演变成事故的路径。分界线在于：这个部件的缺席改变的是智能体做什么，还是只改变它知道什么。

• 检索后端挂掉时，应该显式而可见地降级为"在没有来源的情况下作答"。智能体必须说出来，轨迹必须记下来，下游任何做主张核查的环节都必须知道。索引不可用时静默地凭参数化记忆作答，是这一页上严重程度最高的失败——因为输出看起来一模一样，而它已经不再接地。
• 护栏或策略服务挂掉时必须失败闭合。如果注入分类器、PII 过滤器或授权检查连不上，那这个动作就不执行。一个失败时放行的安全控制，恰恰在最不需要它的时候最强。这与在环路内的急停开关是同一条论证。
• 处于降级中的写操作工具，绝不能乐观重试。降级会放大重试，重试会放大副作用。在你搭这一切之前，每条写路径都需要一个由意图派生的幂等键，见幂等、重试与副作用安全；没有它，降级模式就是你把同一封邮件发四遍的那个小时。
• 质量下降时，把自主度阈值一起调低。自动放行规则是照着主力的准确率校准的。如果降级配置在你的评测上分数明显更低，那它可以无人监督执行的动作范围就必须相应收窄——一个权限不变的降级智能体是所有组合里最糟的一种，而它恰恰是默认的那一种。
• 绝不要静默地跨过合规边界做切换。位于另一个区域或另一家厂商的备用方案，可能把数据搬到你的合同不允许的地方。区域与厂商是备用方案身份的一部分，这项检查该落在配置里，而不是落在某个人的记忆里——见数据驻留与主权。

降级模式要么是一个有出口的具名状态，要么就变成永久状态。

一个造得不错的降级方案，最常见的结局并不是失败。而是：系统在某次事故中进入了降级模式，事故解决了，没人注意到，三周后产品已经悄悄跑在便宜模型和缩水工具集上了。

• 把它做成一个显式状态，而不是重试逻辑的涌现属性。在运行上、在每个 span 上、在每一行日志上、在仪表盘上写 mode=degraded。如果知道自己在降级的唯一办法是从错误率里反推，那你就不会知道。
• 对进入、对持续时长、对受影响流量占比分别告警。只对"进入"告警就是噪声。"过去 40 分钟有 12% 的运行处于降级"是一起事故；"有一次运行降级了"只是个星期二。
• 恢复需要显式健康检查和迟滞。要在主力连续健康达到一个既定窗口后再切回，而不是探测第一次成功就切——否则一个抖动的厂商会让你的系统在两个行为不同的智能体之间来回振荡，那对用户比一直降级更糟。
• 每一项降级都要有主人和到期日。一个关掉校验轮次的开关需要一个日期。没有到期日的开关，正是"临时权衡"变成"架构"的路径；纪律见面向智能体的特性开关。
• 在产品里用一行字告诉用户。"当前处于降级模式——来源不可用"不花什么成本，却保住了整个界面赖以存在的那份信任校准。用户会原谅一个事先被提醒过的降级答案，不会原谅一个没被提醒的自信错误答案。

去演练它，因为没被测试过的备用方案等于不存在。

降级路径在构造上就几乎没有生产运行时长。你系统的其他每一部分都被流量持续测试着；这一部分只被故障测试——而那是发现"备用方案的 API key 三月份就过期了"的最糟时机。

• 持续把一小股真实流量路由到备用方案上。百分之一二，长期开着。它能让凭据保持有效、让这条代码路径持续被编译和执行，而真正的收获是：它在真实流量上、而不是在一份过期评测集上，产出一份与主力的持续质量对比。
• 做有排期的降级演练。按计划在生产环境里强制主力失败十五分钟，团队在旁边看着。第一次演练总能翻出东西：一个没设的超时、一个继承了引用不存在工具的提示词的备用配置、一场重试风暴、一条从来不会触发的告警。
• 要测的是切换过程，不只是两个状态。大多数降级缺陷住在开关里——一次在轨迹中途切换、丢掉了工具调用历史的运行，或者一段与新模型不再匹配、于是悄悄按全价计费的缓存前缀。"运行途中切换"和"从一开始就降级启动"是两个不同的测试用例。
• 把"退出降级"也纳入演练。恢复是没人排练的那一半，而迟滞相关的缺陷只在主力回来时才现身。
• 让备用方案的评测结果保持新鲜。用与主力相同的节奏对降级配置重跑评测集。一个九个月前针对某个此后已退役的模型版本做过资格认证的备用方案，等于一个根本没人评测过的配置——这也是模型退役与迁移里的那种失败模式。

说明降级是否奏效的五个数字。

只看可用性，会在一个"每个答案都没有接地"的小时里报告成功。下面这些说的话更有用。

• 处于降级模式的时长，以及受影响运行的占比。暴露度指标。按周看趋势；缓慢上升说明主力的容量规划在漂移，而不是说明备用方案运转良好。
• 同一套评测集上，主力与降级的质量差值。把"降级"变成一个决策的那个数字。如果你说不出它，你就不知道一次故障的代价是多少——也就没法为降级模式设定自主度阈值。
• 降级模式下的任务完成率。不是回答率。一个对每个请求都返回点什么、却只完成一半任务的降级智能体，是一个报告 100% 可用性、交付 50% 产品的系统。
• 静默降级事件数。你事后才发现"当时已经降级而告警没响"的次数。目标是零，而第一次度量通常不是。
• 每完成一个任务的成本，降级 vs 主力。经常更高，永远出人意料，也是终结"故障期间便宜的备用方案在省钱"这个假设的最快办法。

相关：速率限制与厂商容量看这一切上游的准入控制，SLO 与错误预算看降级在花掉什么，模型路由与级联看同样的切换被刻意做出来时是什么样，以及为失败而设计看用户看到的是什么。