降级和重试有什么区别？换路和再试

AI 智能体调服务失败时，手里有两张牌：重试是原路再试一次，降级是换一条能走的路，什么时候打哪张牌，考验的是容错设计。

可以把它想成赶飞机：航班延误你选择继续等，这是重试；改签高铁，这是降级。这个类比的失效之处在于，航班延误有明确原因可查，服务故障的原因往往一时看不清，判断依据要靠错误类型和恢复信号。带走一个判断：重试赌运气，降级换方案，顺序不能乱。

先说结论：再试赌运气，降级换方案

短暂抖动、偶发超时，适合重试：等一小会儿再发，成功率不低；持续故障、明确限流，适合降级：换备用模型、换简化流程或返回兜底话术。判断的分水岭是故障属于一时的波动，还是一段时间的瘫痪。判断还可以交给数据：记录一段时间内错误类型和恢复时长的分布，你的业务该多重试、多早降级，数字会给答案。

差异一：对故障的判断不同

重试假设故障会自行消失，动作只是等待加重复；降级假设短时间好不了，动作是切换路径。重试要看错误类型：限流错误重试等于火上浇油，额度规则见限流和排队有什么区别？一张表分清；降级要看备选路径的质量，备选实例的分布见多实例和多租户有什么区别？边界一次说清。

差异二：用户体验的走向不同

重试成功，用户拿到的是原计划的结果，体验无损，代价是等待变长；降级启用，用户拿到的是简化版结果，速度保住了但内容打了折扣。两者都会拉长响应，要不要把等待交给后台，见异步和同步调用有什么区别？适用场景分开讲。讯飞星火、智谱清言的开放服务在错误码文档里会区分可重试与不可重试，接入前值得通读，错误码就是打牌前的读牌环节。

打牌的时机也有信号可循。连续多次请求在同样位置失败，多半不是抖动，重试价值骤降；错误响应里带了「稍后重试」或预计恢复时间，重试就有了明确锚点；备选路径与主路径差距大，降级要慎用，宁可多等一会儿。信号都读不到时，设一个总时限兜底：时限内重试，到点降级，绝不让请求悬在半空无限等，兜底时限是最后防线。

两者怎么配合成一套策略

常见组合是先重试后降级：短暂抖动先重试一两次，仍失败就降级兜底，并把降级决策记进日志供复盘。重试要带上递增间隔，别贴脸连发；降级路径要提前演练，别等出事才发现备胎没气。资料问答的降级还涉及是否退回模型自身知识，边界讨论见RAG 和长上下文差在哪？外挂资料和内置容量。

容错策略还要分层设计。对体验敏感的前台请求，降级阈值放宽、兜底话术备好，宁可给个简化结果也别让用户看报错；对数据一致性敏感的后台任务，反过来宁可不降级——失败入队延后处理，也不能用一个近似结果污染下游数据。同一个系统里两种策略并存并不矛盾，关键是一开始就想清楚每类请求错得起什么，这张清单值得写进设计文档。

容错策略速查：

• 偶发超时：带间隔地重试一两次
• 持续故障：果断降级，保基本可用
• 限流错误：不重试，先看额度

两张牌按序打，服务才稳得住。

关于降级和重试的三个常问问题

• 重试几次算合理？：一般一到两次，配合递增间隔，再多只是消耗额度。
• 降级会告诉用户吗？：正规做法会提示当前为简化服务，不冒充完整结果。
• 降级路径平时要维护吗？：要，定期演练才能保证启用时真的可用。

容错设计的一句话心得：先想好什么情况下放弃，再谈坚持。