LangGraph 中的容錯機制：重試、超時和錯誤處理器

在實際生產環境中，AI 代理會遇到原型中從未出現的錯誤：網路故障、工具呼叫錯誤、LLM 速率限制。一個執行數小時的任務如果中途遇到不可恢復的錯誤，是直接放棄還是從頭開始？這顯然不是可持續的生產方式。編寫正常路徑通常很簡單，但使代理在生產中存活下來的錯誤處理樣板程式碼（重試、超時、降級）往往比業務邏輯本身還要長。

LangGraph 將容錯視為一等公民。它是一個底層編排框架，將代理建模為一組離散步驟（節點），組織成圖。由於 LangGraph 控制執行，它也是處理任何步驟失敗的正確位置。本文介紹 LangGraph 幫助處理樣板程式碼的三個原語：RetryPolicy（帶退避和抖動的自動重試），TimeoutPolicy（基於牆鍾時間或進度超時），以及 error_handler（重試耗盡後執行的節點，帶有失敗上下文）。它們如何組合以及為何在工作流引擎內部實現至關重要，尤其是當你開始考慮清理/補償邏輯時。

在 LangGraph 中，你透過新增節點和邊到 StateGraph 來定義代理。所有三個原語直接透過 add_node 附加到節點，因此容錯配置位於它保護的邏輯旁邊。RetryPolicy 支援指數退避、可選抖動和可配置的異常謂詞（預設只重試 ConnectionError 和 5xx 響應）。TimeoutPolicy 提供 run_timeout（硬牆鍾時間上限）和 idle_timeout（無進展時的空閒超時），並可透過 heartbeat 重新整理。當超時觸發時，節點嘗試被取消並引發 NodeTimeoutError。

錯誤處理器在重試耗盡後才執行。這使其非常有用：例如，在支付提供商持續宕機後標記訂單失敗、通知客戶、回滾部分副作用或釋出事件。在 LangGraph 中，錯誤處理器接收 NodeError 物件（包含失敗節點名稱和異常），並且狀態遷移是原子的：原始節點失敗後，其 ERROR 寫入被提交到檢查點，處理器任務在同一超步中被排程。這確保了主機崩潰後恢復時，會重新排程處理器而非原始失敗節點。

這三個原語組合的真正力量體現在涉及副作用的流程中，如航班預訂。每個步驟（預訂座位、處理付款、出票）都與外部系統互動，任何步驟都可能失敗。簡單的整體重試方法會導致狀態不一致，例如座位已預留但付款失敗。SAGA 模式是分散式系統中處理此類失敗的標準方式。在 LangGraph 中，你可以為每個步驟設定相同的重試策略和錯誤處理器，後者將流程路由到補償節點，該節點檢查已完成步驟列表並反向撤銷它們。

LangGraph 的 retry_policy、timeout 和 error_handler 使得構建能夠優雅處理各種錯誤的代理變得簡單。你只需為用例定義合適的策略，執行時負責其餘工作。