问题定义：fallback 和 retry 分别解决什么问题？
在 agent workflow 中，错误处理是确保系统健壮性的关键。fallback 和 retry 都是应对失败的手段，但它们的适用场景截然不同。简单来说：当某个步骤失败时，retry 是“再试一次”，fallback 是“换条路走”。
- retry：适用于临时性、可恢复的错误。例如 API 调用超时、网络抖动、资源暂时不可用。重试通常有次数限制（如 3 次）和退避策略（如指数退避），避免雪崩。
- fallback：适用于永久性或不可恢复的错误，或者你提前知道某种失败是预期的。例如模型返回格式错误、兜底方案（如降级到更简单的模型）、或者用户输入超出边界。Fallback 通常会触发一个备选逻辑，比如使用缓存结果、提示用户重新输入、或者切换到人工处理。
操作步骤：如何在 workflow 中实现 fallback 和 retry？
实现 retry 的标准流程
- 识别可重试的错误类型：例如 HTTP 5xx、超时、速率限制。不要对 4xx 或认证失败重试。
- 设置最大重试次数：通常 2-3 次，过多会延迟整体流程。
- 配置退避策略：固定间隔（如 1 秒）、指数退避（如 1s, 2s, 4s）、或带 jitter 的退避（避免 thundering herd）。
- 记录重试日志：方便定位问题。
- 集成超时控制：总重试时间不能无限长。
具体场景示例：你的 agent 需要调用 OpenAI API 生成摘要。网络偶尔中断，返回 503。此时重试 3 次，每次间隔 2 秒。如果第 3 次仍失败，则进入 fallback。
实现 fallback 的标准流程
- 识别需要 fallback 的步骤：通常是关键路径上的非关键操作，或者有明确降级方案的任务。
- 设计备选逻辑：例如用更便宜或更快的模型替代、返回缓存数据、询问用户、或记入死信队列后续人工处理。
- 在 workflow 中配置 fallback 节点：当主路径抛出不可恢复错误时，自动跳转到备选节点。
- 测试 fallback 路径：确保备选逻辑能正常工作，不会引入新问题。
具体场景示例：你的 agent 在解析用户意图时，主要用 GPT-4，但若 GPT-4 返回了无效 JSON 格式（这是永久性错误），则 fallback 到一个基于规则的正则匹配，或者提示用户重新表述。
真实场景：一个客服 agent 中的决策
假设你正在构建一个客服 agent，负责回答产品问题。工作流如下：
- 接收用户问题。
- 用向量搜索找到相关文档片段。
- 用 LLM 基于片段生成回答。
- 返回回答给用户。
这里可能的失败场景：
- 步骤 2 中向量数据库查询超时：这是可恢复错误，应 retry 1-2 次。若仍失败，可以 fallback 到使用关键词搜索（后备方案）。
- 步骤 3 中 LLM 响应包含格式错误或拒绝回答（如“我无法回答”）：这是永久错误，不应该 retry（重试大概率仍得到同样结果），而应直接 fallback 到预设的兜底回答，比如“抱歉，我暂时无法回答，请稍后再试”。
选择不当的后果：如果对永久错误（如格式错误）执行重试，不仅浪费时间和成本，还可能给用户返回同样无用的结果，导致体验下降。反之，如果对临时错误（如网络超时）直接 fallback 到缓慢的备用逻辑，可能造成不必要的降级。
最容易踩的坑：三个常见误区
误区 1：对所有错误统一采用 retry
很多人习惯对任何失败都重试，认为重试无害。但有些错误重试只会加重系统负担。例如，用户输入超出 token 限制，重试会重复消耗 tokens 还是失败。正确的做法是区分错误类型：永久错误直接 fallback。
误区 2：fallback 路径没有充分测试
Fallback 代码往往写完之后很少执行，因此容易隐藏 bug。等到真正触发时，可能 fallback 本身也失败，导致整个 workflow 崩溃。务必在开发阶段手动触发 fallback 场景，并监控其执行效果。
误区 3：忽略失败原因分析
无论是 retry 还是 fallback，都必须记录失败原因和上下文。没有日志，你就无法改进系统。例如，如果某个步骤频繁触发 fallback，那可能意味着主流程设计有问题，需要调整。
失败时的备用方案：如果 fallback 也失败了怎么办？
这是很多人忽略的最后一环。如果主路径和 fallback 都失败，workflow 必须有一个最终默认行为。常见方案：
- 返回通用的错误消息给用户，并提示人工介入。
- 将失败任务写入死信队列，由管理员定期处理。
- 发送告警给开发团队。
- 对于非关键流程，可以跳过该步骤继续执行。
总之，设计容错时，要构建一个完整的错误处理链：retry -> fallback -> 最终失败。
如何选择：一个简单的决策树
如果你还在犹豫，可以用这个快速决策：
- 错误是否可能因为瞬时条件而消失？如果是，用 retry。
- 错误是否表明当前方法不可行，但存在备用方法？如果是，用 fallback。
- 如果两者都不可行，那就接受失败，并优雅地降级。
在实际项目中，建议在 workflow 图中显式标明每个步骤的容错策略，并和团队 review。
现在，你可以检查一下自己的 agent workflow：有多少步骤缺少明确的 fallback？又有多少步骤在错误时盲目重试？优化这些细节，系统稳定性会显著提升。
暂无评论，快来发表你的见解吧