Agent 如何判断何时重试、何时降级？

核心回答

判断是否重试，要看失败是否会暂时消失、再次执行是否安全、剩余预算是否足够。网络瞬断、短暂过载等可能重试成功，可以在截止时间内退避；参数、鉴权、权限或上下文错误，要先修复对应条件，重复同一个请求通常没有意义。

如果原路径持续不可用、继续等待超出业务预算，而备用方案仍满足质量、权限和结果要求，就降级；没有合格备用方案则停止、保留进度或转人工。对写操作结果不确定的超时，先查回执或走幂等恢复，不能当作普通失败直接再执行。

展开解析

1. 决策输入不只是“第几次失败”

执行器应拿到规范化错误类型、是否收到完整结果、下游执行状态、依赖健康度、剩余时间与费用。模型可以根据业务信息调整计划，但重试资格、预算和权限应由程序约束。

当前情况	更合适的动作	原因
只读查询遇到瞬时连接故障	预算内退避重试	同一输入可能恢复成功
参数格式或字段不合法	校验后修正参数再调用	原样重试不能消除请求错误
无有效凭证或无资源权限	结束当前路径并提示处理	不能靠换模型绕过鉴权
短期限流且等待时间可接受	按服务端提示等待或排队	立刻重发可能继续限流
额度耗尽或持续过载	恢复配额、合格备用路径或结束	不属于短等待就能恢复的故障
业务写入超时、结果未知	查询动作状态或对账	再次执行可能产生重复副作用
检索正常但证据仍不足	缩小问题、补必要输入或说明无法判断	API 成功不等于业务依据足够

429 也需要结合错误体与响应头判断。它可能代表短期限流，也可能是长期额度限制；并非所有 429 都有适合当前任务的重试窗口。

2. 在整个任务预算内安排下一次尝试

设任务剩余时间为 R，下一次等待为 W，预计调用及结果校验需要 T，只有 W + T 仍能容纳于 R 且成本、安全条件满足时，重试才有意义。T 是估计值，要根据调用延迟留余量，不能保证一定成功。

退避加入随机抖动，避免请求同一时刻再次涌入；如果供应商给出 Retry-After，结合其契约处理。还应检查 SDK 是否已有自动重试，防止应用层再次套循环。重试通常只针对失败步骤，而不是重新执行整个任务。

3. 降级按业务损失选择，不能只看模型价格

对于旅行规划，实时景点查询失败后，可以基于已确认资料生成附有限制说明的行程草稿；对于订票，库存与支付结果不能靠语言模型猜测，应该保留订单状态、等待确认或转人工。

替换模型要满足上下文、工具和输出格式要求；切换检索源也要保持资料权限。结果已经部分产生时，先保留可复用产物并标记未完成部分，避免为了“整体成功”重做已完成动作。

4. 防止失败恢复变成无效循环

记录错误指纹、输入摘要、尝试次数和每轮新增信息。如果错误相同、输入没有改变、依赖也未恢复，就不应让模型反复宣称“再试一次”。停止条件由任务截止时间、费用、安全策略和业务恢复价值共同决定，具体次数是配置，不是通用经验值。

追问

同一个调用已经失败三次，是不是必须降级？

次数本身不足以判断。先看三次是否同因、是否真的发送到下游、是否已耗尽预算，以及重试前有没有改变错误条件。权限错误应更早停止；可安全重放的异步任务则可能进入延迟队列，具体取决于业务时限。

补充证据以后还是无法支持结论怎么办？

检查是否缺关键输入、资料是否根本不存在或问题超出系统范围。可以给出已确定部分和缺口，必要时请用户补充或转专家，不能用多轮生成替代事实证据。

对应教程

参考资料