Agent Workflow Fallback Setup 实现原理：从单点故障到自愈工作流

为什么你需要关心 Agent Workflow Fallback？

构建一个生产级的 agent 工作流，最大的幻觉是“模型会按预期返回”。实际运行中，LLM 调用可能超时、工具链可能断掉、上下文可能溢出。没有 fallback，一次失败就会让整个 agent 卡死，用户面对的是无响应的界面或者断章取义的回复。

Agents 的失败模式比传统服务更多样：模型返回格式错误导致解析异常、外部 API 限流返回 429、多步推理中某一环输出不符合预期。Fallback 不是可选项，而是 agent 工程化的底线。

Fallback 的核心机制：不只是重试

很多人把 fallback 等同于重试机制，但 agent workflow 的 fallback 需要处理更多维度。

1. 超时与限流回退

LLM 调用和工具调用都有超时窗口。当一次 LLM 调用超过 10 秒（根据模型和场景调整）未返回，fallback 可以切换到缓存结果、降级回答（“我暂时无法处理，请稍后再试”），或者在支持多模型的架构中切换到更小更快的模型。

笔记本电脑屏幕上显示的 fallback 清单截图，包含超时设置、工具失败回退路径、并行 fallback 配置等步骤。

# 简化示例：超时 fallback 到缓存
import asyncio

async def call_llm_with_fallback(prompt, cache, fallback_model=None):
    try:
        result = await asyncio.wait_for(llm_api(prompt), timeout=10)
        cache.update(prompt, result)
        return result
    except asyncio.TimeoutError:
        cached = cache.get(prompt)
        if cached:
            return cached
        if fallback_model:
            return await fallback_model(prompt)
        return "当前请求超时，请稍后重试"

这个阶段最容易犯的错误是不设置合理的超时值。设置太短会导致正常慢响应被截断，设置太长会让用户等待过久。建议根据模型 P99 延迟动态调整，并配合客户端感知的进度反馈。

2. 工具调用失败的回退路径

Agent 工作流通常涉及多个工具调用，比如搜索、数据库查询、代码执行。任何一个工具失败，如果只是抛出异常，工作流就会中断。好的 fallback 应该是给 agent 一个“绕行”选项。

真实场景：一个客服 agent 需要查询订单物流信息，但下游物流 API 暂时不可用。这时 fallback 策略可以是：

尝试从本地缓存获取历史数据
切换到备选物流查询服务
告知用户“物流信息暂时无法查询，请稍后重试”，并记录工单

实现时，可以在工具定义中声明 fallback 行为：

tools = [
    {
        "name": "track_order",
        "description": "查询订单物流状态",
        "fallback": [
            {"type": "cache", "ttl": 300},
            {"type": "alternative_api", "endpoint": "https://backup-logistics.example.com"},
            {"type": "user_message", "content": "物流查询暂时不可用，已记录您的请求"}
        ]
    }
]

3. 推理路径的 fallback：当 agent 陷入死循环

Agent 可能在某一步反复做出相同决策，比如不停搜索同一个关键词。这通常是因为 prompt 设计不当，或者外部条件未满足。此时 fallback 需要介入，通过打断循环、提供新信息或重置状态。

实操做法：在 workflow 中加入一个“循环检测”模块，统计最近 N 步的决策是否是重复的。如果发现循环，fallback 强制注入一条提示：“你已重复执行相同操作 3 次，请换一种方式。比如直接回答用户‘我无法找到更精确的信息’，或者请求用户提供更多细节。”

最容易踩的坑：顺序 fallback vs 并行 fallback

很多人在设计 fallback 时，习惯写成顺序判断：如果 A 失败就试 B，B 失败就试 C。这在某些场景下是对的，但如果 B 和 C 的调用开销很大或者有时间窗口，顺序阻塞会让延迟线性叠加。更优的策略是并行 fallback：同时发起 A 和 B（两个候选模型或工具），谁先返回非错误结果就使用谁。

选择顺序还是并行，取决于失败模式的时延特征。如果主要失败是格式错误，但正常响应很快，顺序重试就够了。如果主要失败是超时或限流，并行 fallback 能显著降低用户感知延迟。

一个具体失败案例：某团队为 agent 配置了三级 fallback：先调大模型，超时后调小模型，再超时后调固定回复。由于没有并行执行，每次 fallback 都需要 10 秒超时等待，用户最多等 30 秒才得到一句“我无法处理”。改为并行后，3 秒内就拿到了小模型的结果。

办公桌上笔记本与手写笔记的对比图，笔记内容为顺序 fallback 与并行 fallback 的决策要点。

Fallback 的适用边界与限制

Fallback 不是万能的。如果输入 prompt 本身有安全风险或超出模型知识边界，fallback 可能会放大错误。例如，恶意 prompt 绕过了主模型的安全护栏，fallback 模型可能更不安全。此时更好的做法是拒绝服务，而非 fallback。

另一个限制：Fallback 会增加系统的复杂度，尤其是在维护多个 fallback 链时。建议为每个 agent 工作流设定 fallback 的最大深度，避免无限递归。

可执行做法：搭建你的 fallback 清单

梳理 agent 工作流的每一个调用点（LLM 调用、工具调用、API 调用）。
为每个点确定失败模式（超时、格式错误、业务异常、上下文溢出）。
针对每个模式设计 fallback 动作（重试、缓存、降级模型、替代工具、用户消息）。
确定 fallback 的执行顺序（顺序或并行），并设置最大尝试次数。
在开发环境模拟故障，验证 fallback 是否按预期触发。
监控 fallback 触发率，如果某个 fallback 频繁触发，说明主路径稳定性需要改进，而不是依赖 fallback 兜底。

失败时的备用方案

当所有 fallback 都失败时，agent 必须优雅降级。最低要求是：返回一条友好的错误消息，告知用户发生了什么，并提供替代操作入口（如人工客服或重新尝试）。不要返回空或不完整的回答。

备选方案列表：

返回静态回复，并提示用户后续可重试。
记录失败详情到日志，便于事后分析。
异步通知运维人员介入。

从 agent 新手到 agent 工程师

Fallback 是 agent 工程中的一个基础能力。掌握了 fallback，意味着你开始从“写一个 demo agent”转向“构建生产级 agent”。但仅靠 fallback 并不能解决所有稳定性问题，你还需要理解权限管理、内存管理、上下文控制、评估与迭代。