线上 Agent 挂了不是因为模型推理出错而是因为 API 调用超时了。这个场景做 Agent 生产部署的人大概率都遇到过凌晨两点OpenAI 或 Anthropic 的 API 突然返回 5xx或者某个模型因为负载过高响应时间从 800ms 飙到 8s。你的 Agent 没有回退能力直接报错给用户——或者更糟卡在某个工具调用循环里一直重试把上下文窗口和账单一起撑爆。这类问题比模型输出质量差更难处理。输出质量差可以用验证层兜底但模型不可用是整个执行链路的中断。如果系统没有降级机制用户看到的就不是答案不太准确而是服务不可用。模型回退链最基础的降级手段最简单的降级策略就是给 Agent 配置多个模型按优先级排列。主模型挂了自动切换到次选模型再不行就切到更便宜的模型或兜底策略。回退链的触发条件需要分清楚。API 返回 429限流和 5xx服务端错误的处理方式不同限流通常是暂时的可以等几秒重试服务端错误往往意味着该模型或端点当前不可用应该直接切到下一个模型。而超时则需要区分是偶发还是持续——偶发超时可以重试一次持续超时就应该走回退。实现上回退链可以做成一个简单的路由器const modelChain [ { model: claude-4-sonnet, provider: anthropic, fallbackOn: [5xx, timeout] }, { model: gpt-4o, provider: openai, fallbackOn: [5xx, timeout, rate_limit] }, { model: claude-3-5-haiku, provider: anthropic, fallbackOn: [*] }, ]每一层除了指定模型和 provider还要明确什么条件下触发回退。*表示兜底层接受任何失败场景保证系统始终有一个可用的模型。这里有个容易被忽略的细节回退不只是换模型还要考虑工具兼容性。不同模型对工具定义格式的支持不同。比如 Claude 的 tool use 格式和 OpenAI 的 function calling 格式不完全一致回退时如果工具定义没有做适配层模型可能无法正确解析工具参数。因此回退链里每个模型都需要有对应的工具定义适配器或者在设计工具时就选择跨模型兼容的格式。跨 provider 回退比同 provider 的 cost 差异更大——不只是 API 调用费还有延迟、缓存命中率、输出质量的变化。一个常见的做法是同 provider 回退可以作为快速降级手段因为缓存可能还在跨 provider 回退作为最后手段同时记录切换原因用于后续复盘。降级等级不只是换模型还要换行为模型回退只能解决模型不可用的问题。但 Agent 的问题不止于此——有时候模型本身可用但质量下降或者上游数据源不稳定或者工具调用链太长导致延迟不可接受。降级等级Degradation Tiers的思路是根据当前的系统状态动态调整 Agent 的行为模式而不是简单地在正常和挂掉之间二选一。一个典型的四级降级模型Tier 0正常全功能运行。所有工具可用使用最强模型响应质量最高。Tier 1轻度降级模型降级到次选模型但工具集不变。适用于 API 延迟升高但尚未超时或某个模型负载过高的情况。用户不会感知到功能变化但响应可能变慢或质量略有下降。Tier 2中度降级收缩工具集限制 Agent 能调用的工具范围和调用深度。例如关闭 Web 搜索、限制文件写入、禁止调用外部 API。这阶段 Agent 仍然可以完成任务但只能使用内部数据和确定性逻辑。适用于上游数据源不稳定或外部服务大面积故障的场景。Tier 3重度降级Agent 转为半自动模式——所有关键操作需要人工确认或者直接降级为简单的规则引擎或 FAQ 应答。适用于模型完全不可用或系统处于严重故障状态。Tier 4紧急降级系统返回预设的降级提示告知用户当前服务不可用引导用户通过其他渠道获取帮助。这是一个兜底状态保证用户不会看到一个空白的错误页面或无限 loading 的界面。降级等级的切换需要自动检测和手动干预两条路径。自动检测通过监控指标触发延迟 P99 超过阈值、错误率上升、工具调用成功率下降等。手动干预则允许运维人员直接指定降级等级比如在已知 API 维护窗口期提前降级。熔断器防止 Agent 在被拖垮的服务上反复重试模型回退链和降级等级解决了怎么降的问题但还有一个关键问题在降级之前系统怎么知道该降级了很多 Agent 的降级逻辑是等一次失败才触发。但问题在于如果模型处于不稳定状态——不是完全不可用而是间歇性超时或返回错误——Agent 可能每次重试都失败一次再切换到下一个模型造成大量浪费。熔断器模式Circuit Breaker可以用来解决这个问题。它的核心思路是当失败率达到阈值时直接熔断——不再向该模型发送请求进入快速失败状态等待一段时间再尝试恢复。熔断器有三个状态Closed关闭正常状态请求正常发送。失败计数递增。Open打开失败率超过阈值熔断器打开。所有请求直接走 fallback不再尝试调用该模型。Half-Open半开经过冷却时间后允许少量请求通过测试模型是否恢复。如果请求成功熔断器关闭如果失败重新打开。对于 AI Agent 来说熔断器的阈值设置需要和传统微服务有所不同。Agent 的每次调用不是独立的 RPC——它可能包含多轮工具调用链每轮都有多个模型调用。一个合理的做法是按执行会话而不是单次 API 调用来统计失败率。如果一个 Agent 会话中超过 30% 的模型调用失败就应该触发熔断而不是等待连续 N 次失败。冷却时间也需要根据模型类型调整。同 provider 的不同模型可能共享底层基础设施如果 claude-4-sonnet 熔断了claude-3-5-haiku 可能也受影响。这种情况下跨 provider 的熔断应该独立计数冷却时间也要更长。落地时容易被忽略的边界降级和回退看起来是加法——给系统加一层保护。但实际落地时有几个容易被忽略的边界。状态一致性Agent 的执行状态可能在降级过程中丢失。比如 Agent 正在执行一个多步骤任务在第三步时熔断触发了回退到更便宜的模型。新模型没有之前步骤的上下文或者即使有上下文模型能力差异也可能导致无法接续执行。解决方法是降级前先做一次状态持久化记录当前执行进度回退后从最近的 checkpoint 恢复。降级风暴如果多个 Agent 实例共享同一个模型后端当模型出问题时所有实例可能同时触发降级造成降级对降级的复合效应——降级后的模型也承受不住突然涌入的流量进而触发更深度降级。避免方法是给降级路径也做流量控制不要让所有实例同时回退到同一个后备模型。降级感知的测试降级路径本身需要测试而且不能只在正常状态下测试。很多团队只测试了主模型路径降级配置上线后从来没真正触发过。等到线上故障时才发现后备模型的工具定义不兼容或者降级后的 Prompt 没有适配模型能力差异。一个实用的做法是在 CI 中定期触发降级路径的集成测试确保每条回退链都能正常工作。降级成本降级不一定省钱。回退到更便宜的模型确实降低了单次调用成本但如果降级导致 Agent 需要更多轮次才能完成任务或者频繁触发回退链增加了基础设施开销总体成本可能反而上升。需要监控降级后的端到端成本而不是只看单次调用的单价。选择适合你的降级策略不是所有 Agent 都需要四级降级。决定降级策略的深度取决于你的 Agent 在业务中的角色。面向用户的 Agent 至少需要 Tier 0 到 Tier 2 的覆盖——保证用户在任何情况下都能得到回应哪怕质量差一点。内部工具类的 Agent 可以更激进直接降级到 Tier 3 或 Tier 4因为对用户来说等一个内部工具恢复比看到一个半吊子的结果更可预期。熔断器的阈值也要根据业务容忍度来设。如果 Agent 每次调用平均成本很高你可能希望熔断器更敏感——早点熔断避免浪费昂贵调用。如果 Agent 对响应质量要求极高你可能希望熔断器给模型更多机会不让偶发波动影响体验。降级和回退不是万一出问题怎么办的预案而是生产系统必须内置的能力。模型服务不可能永远可用API 总会有波动数据源总会有异常。在生产环境运行 Agent 的团队越早把降级逻辑纳入系统设计线上故障时就越从容。