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 並不能解決所有穩定性問題，你還需要理解權限管理、記憶體管理、上下文控制、評估與迭代。