Agent Workflow Fallback vs Retry：深入对比与选型指南

为什么需要比较 fallback 与 retry？

在构建 Agent workflow 时，错误处理是不可回避的环节。无论是 LLM 调用超时、外部 API 返回异常，还是工具执行失败，都需要决定：是重试（retry）还是切换到备用路径（fallback）。选错可能导致资源浪费、任务死锁或结果不一致。本文基于实际工程场景，拆解两者的本质区别与适用边界。

Fallback 与 retry 的定义与核心差异

Fallback（降级/备用）：当主路径失败时，执行一个预定义的替代方案。例如，LLM 调用返回空结果后，转用规则引擎生成回复；或者支付服务不可用时，切换到备用网关。

Retry（重试）：对失败的操作重复执行，预期是临时故障恢复后重新成功。例如，网络超时后指数退避重试，或 LLM 输出格式不对时重新生成。

维度	Fallback	Retry
执行逻辑	切换到备用路径	重复当前路径
适用场景	不可恢复的错误、业务不允许阻塞	可恢复的瞬时故障
资源消耗	通常较高（需备用资源）	可能累积调用次数
延迟影响	切换时间 + 备用执行	重试间隔 × 次数
成功概率	依赖备用路径可靠性	逐步衰减或平缓

真实场景：智能客服订单查询

假设一个 Agent 需要查询订单状态：先调用新订单系统，失败时 fallback 到旧系统；同时，对于网络超时这类瞬时错误，采用最多 3 次重试。

场景：新系统返回 503（服务过载），此时 retry 会加剧负载，应直接 fallback 到旧系统。但如果新系统返回 429（限流），则可以等待后 retry。若不区分错误类型，全用 retry 可能导致雪崩；全用 fallback 则可能导致旧系统不堪重负。

决策点：必须根据错误码和上下文选择机制。实践中，将 retry 用于客户端错误（如超时、格式错误），将 fallback 用于服务端错误（如不可用、认证失败）。

最容易踩的坑：无限制重试与隐式 fallback

坑1：无上限重试。某团队在 LLM 调用上设置了无限重试，结果 LLM 持续返回异常，消耗了数千元 API 费用。正确做法：设置最大重试次数（通常 2-3 次）和指数退避。

坑2：隐式 fallback 覆盖问题。例如，fallback 路径没有独立监控，导致主路径失败后静默切换到备用，而备用本身也有缺陷，用户得到错误结果而不知。必须为 fallback 路径也记录日志并报警。

坑3：忽略幂等性。Retry 操作必须幂等，否则重复执行可能产生重复订单、重复扣款。如果操作不幂等，应优先使用 fallback 或设计去重机制。

具体操作：如何选择与实现

1. 分类错误类型。将错误分为瞬时（可重试）和永久（需 fallback）。例如，网络超时、HTTP 503 算瞬时；认证失败、404 算永久。
2. 设定重试策略。使用指数退避 + 抖动，最大重试次数根据服务 SLA 调整。对于 LLM 调用，建议 2-3 次，间隔 1-5 秒。
3. 设计 fallback 路径。确保备用路径的资源和数据独立，监控到位。例如，支付时主用支付宝， fallback 到微信支付（需用户确认）。
4. 组合使用。先 retry 几次，若仍失败则 trigger fallback。例如，调用外部 API：retry 3 次 → fallback 到缓存结果。
5. 记录决策轨迹。将每次 retry/fallback 的原因、时间、结果写入日志，便于调试和优化。

失败时的备用方案

如果两者都不可用或无法确定，考虑：

• 人工介入：将任务标记为待处理，通知开发者手动修复。
• 跳过当前步骤：如果业务允许，忽略该任务继续执行后续步骤。
• 安全默认值：返回一个合理的默认值，避免整个 workflow 中断。

注意，备用方案也应该有日志和监控，不能成为黑盒。

结论

Fallback 和 retry 不是非此即彼，而是互补的。正确做法是根据错误类型和业务需求组合使用：retry 处理瞬时故障，fallback 处理持久故障。同时，必须设定边界（重试次数、超时时间）、监控 fallback 路径、保证幂等性，才能让 Agent workflow 稳定可靠。