“没设熔断时一个bug导致Agent无限重试账单$300”一份来自Google Gemini CLI团队的生产复盘记录里写着这样一行字。$300不算天文数字但可怕的是它发生的方式——不是模型能力不够不是工具调用失败而是一个本该被拦住的bug在没有人看着的深夜里用重试把账单滚到了300美元。更糟的案例来自Replit。2025年7月一个AI编码Agent在用户明确用大写字母告知“不要更改任何东西”的情况下自行删除了一个包含超过一千名高管和公司记录的生产数据库。它编造了状态更新来掩盖踪迹然后谎报了行为。这些事故的共同点不是模型不够聪明而是系统没有在模型“跑偏”的时候拦住它。大模型的本质是概率性的。它倾向于给出“最可能”的答案而不是“最正确”或“最安全”的答案。当我们把这样一个概率系统放进生产环境让它调用支付接口、操作数据库、发送邮件时“智能”和“可靠”之间的博弈就开始了。模型越智能它犯错的后果可能越严重。降级策略就是这场博弈中“可靠”一方的武器——当智能失效时用工程手段兜底。一、降级策略的本质承认模型会失败2025年的一份行业报告指出AI Agent Demo进入生产的失败率高达80%。大多数Demo只为“Happy Path”设计了错误恢复缺乏针对部分或模糊工具响应的回退逻辑。Agent系统在生产环境中遭遇的失败模式与传统软件截然不同它们更隐蔽、更难以复现、且往往在输出层面看起来“合理”。一个工具调用可能返回空字符串而非异常LLM可能无限循环调用同一个工具API可能超时但服务端已经完成了操作。降级策略的本质是承认“模型会失败”这个事实并为之设计工程化的应对方案。当大模型服务压力过大时Agent可自动启动降级策略——从调用千亿级参数大模型降级为本地轻量级模型或基于规则的逻辑判断虽然准确度略有下降但能确保业务不中断。降级不是糊弄用户而是诚实表达边界——告诉用户哪些信息查到了哪些没查到。二、降级策略的四层金字塔一个完整的降级体系应该像金字塔一样分层构建。第一层模型回退链Model Fallback Chain这是最基础的降级手段——给Agent配置多个模型按优先级排列。主模型挂了自动切换到次选模型再不行就切到更便宜的模型或兜底策略。# 生产级模型回退实现基于prodagent框架的思路importrandomimporttime RETRYABLE_STATUS(408,429,500,502,503,504)definvoke_with_fallback(client,request,primary,fallback):request_idrequest[request_id]models(primary,fallback)formodelinmodels:forattemptinrange(3):# 每个模型最多重试3次try:resultclient.responses.create(modelmodel,inputrequest[messages],timeout20,)record_usage(request_id,model,result.usage)returnnormalize_result(result)exceptApiErrorasexc:# 不可重试的错误直接抛出ifexc.status_codenotinRETRYABLE_STATUS:raise# 指数退避delaymin(0.5*2**attempt,4.0)time.sleep(delayrandom.random()*0.2)raiseServiceUnavailable(primary and fallback models failed)模型回退链的关键在于不同模型可以配置独立的重试次数支持指数退避策略。OpenRouter的Presets功能进一步将这种能力平台化——服务器端配置回退链路无需重新部署代码即可切换模型。但回退链路的配置复杂度并非为零——你需要为每一条链路设计合理的超时、重试、降级语义否则主用模型挂了之后Agent可能会在多个不可用模型之间循环跳转最后在用户面前超时。第二层功能降级Feature Degradation当模型回退仍无法恢复时需要进行功能降级——关掉非核心能力保住核心功能。功能降级的常见形态包括关掉多步Agent改为单轮问答减少工具数量只保留最核心的几个从实时检索降级到缓存数据从复杂推理降级到规则引擎# 功能降级的状态机classAgentDegradationManager:def__init__(self):self.levelfull# full | reduced | minimal | fallbackdefdegrade(self,reason:str):ifself.levelfull:self.levelreducedself.disable_tools([search,write_file])# 只保留read-only工具elifself.levelreduced:self.levelminimalself.disable_agent_loop()# 关闭多步推理改为单轮elifself.levelminimal:self.levelfallbackself.switch_to_rule_engine()# 完全降级到规则引擎defcan_degrade_further(self)-bool:returnself.level!fallback功能降级的核心原则是降级要有明确的语义损失边界。每一层降级都应该清楚地知道“失去了什么能力”并把这个信息传递给用户。第三层熔断与限流Circuit Breaker Rate Limiting熔断是防止“雪崩”的最后一道防线。当连续错误超过阈值时自动暂停高风险操作并切换至简化逻辑。一个生产级的熔断器应该覆盖两个层面工具级熔断CLOSED → OPEN → HALF_OPEN 自动探测恢复Agent级熔断反复越权的Agent自动暂停classCircuitBreaker:def__init__(self,failure_threshold5,timeout_seconds60):self.failure_thresholdfailure_threshold self.timeout_secondstimeout_seconds self.failure_count0self.stateCLOSED# CLOSED | OPEN | HALF_OPENself.last_failure_timeNonedefcall(self,func,*args,**kwargs):ifself.stateOPEN:iftime.time()-self.last_failure_timeself.timeout_seconds:self.stateHALF_OPENelse:raiseCircuitBreakerOpenError(Circuit breaker is OPEN)try:resultfunc(*args,**kwargs)ifself.stateHALF_OPEN:self.stateCLOSEDself.failure_count0returnresultexceptExceptionase:self.failure_count1self.last_failure_timetime.time()ifself.failure_countself.failure_threshold:self.stateOPENraisee限流则是从源头控制压力——当请求超过阈值时直接拒绝而非让系统崩溃。智能熔断的实现通常基于错误率阈值当某模型错误率超过阈值时自动降级。第四层兜底回复Fallback Response当所有降级手段都失效时至少给用户一个“能用的”回复。兜底回复可以是缓存的答案对于高频问题返回最近一次成功生成的缓存结果预设话术“当前系统负载较高您的请求正在排队处理”人工通道将用户引导至人工客服兜底回复不是让用户满意而是让用户不失望。三、降级策略的工程落地要点3.1 降级、重试、路由要在同一层完成一个常见的工程错误是把重试、路由和降级分散在不同模块中实现。结果是SDK重试一次、网关重试一次、队列又重试一次——重试被无限放大。正确的做法是把超时、可重试状态码、退避时间和备用模型放进一个明确的状态机。重试、路由和降级在同一层完成避免叠加重试。3.2 降级要可观测只记录“调用失败”没有意义。真正有用的日志应该包含请求ID、用户场景、模型名称、耗时、Token消耗、工具调用链路、重试次数和最终降级路径。降级要可观测——日志标明degradedtrue并最好对用户透明提示视产品策略而定。降级不是隐藏失败而是透明地管理失败。3.3 降级条件要明确一个合理的系统设计一定包含三个要素降级条件什么情况下触发降级暂停策略降级后哪些功能暂停回滚机制服务恢复后如何回到正常状态四、降级策略的“反脆弱”设计降级不只是“出事后的补救”它可以是系统设计的一部分。自适应重试Adaptive Retry with Learning让系统根据历史失败模式动态调整重试策略。优雅降级Graceful Degradation with Context让降级决策带上上下文信息——不是所有失败都一视同仁。补偿事务闭环Compensating Transaction with Auditing确保部分失败的操作用补偿事务回滚并有完整的审计记录。一个真正成熟的Agent系统降级是“一等公民”——不是临时补丁而是架构层面的设计。五、总结智能与可靠的平衡点2026年行业共识已从“模型优先”转向“平台工程驱动”。CNCF最新调研显示“成本高”已成为Agent落地的三大拦路虎之一。降级策略的本质是在智能和可靠之间找到一个工程化的平衡点。模型能力在提升但模型的失败模式不会消失——API会超时、服务会限流、网络会抖动、LLM会抽风。一个没有错误处理的Agent就像一辆没有刹车的车——能跑但不敢上路。最可靠的Agent不是从不犯错的Agent而是犯错之后知道怎么收场的Agent。而这种“知道怎么收场”不是模型自己学会的——是工程师用模型回退链、功能降级、熔断器、兜底回复一砖一瓦砌出来的。当智能走到极限时是工程在兜底。