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 穩定可靠。