問題定義：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？又有多少步驟在錯誤時盲目重試？優化這些細節，系統穩定性會顯著提升。
暫無評論，快來發表你的看法吧