當我們用 OpenClaw 串接各種 API、MCP 工具或是通知服務時，真正讓人頭痛的往往不是系統偶爾出錯，而是當外部依賴中斷時，自動化流程卻像沒事一樣繼續跑。
如果沒有事先定義好重試機制、替代路徑與停跑條件，AI 代理（Agent）很可能會重複建立資料、漏發重要通知，甚至把不完整的結果當作成功交付。這對於企業級的應用來說是巨大的風險。以下分享五個實用的規則，建議你可以直接放入每個外部依賴的執行設計中，打造更穩定的工作流。
本篇目錄
先分清楚「可重試」與「不可重試」的錯誤
把錯誤狀況明確分成「暫時性」與「業務性」是第一步。像是 DNS 暫時找不到、連線逾時（Timeout）、HTTP 429 請求過多或 5xx 伺服器錯誤，這些通常可以透過重試解決。但如果是驗證失敗、權限不足、參數格式錯誤或是資源根本不存在，重試一百次也沒用，應該直接退件。
每次發生錯誤時，記得在 Log 中保留依賴服務的名稱、操作動作、發生時間與相關的 request ID（記得遮罩 Token 與敏感個資）。把錯誤分類做好，比單純增加重試次數重要多了，否則盲目重試只會變成放大異常流量的元兇。
為每個 API 操作設定合理的「重試上限」
千萬不要設定無限重試。 你應該為單次任務設定明確的重試次數、總等待時間與退避間隔（例如最多重試三次，採用指數退避並加入隨機抖動時間）；同時也要幫整個 Job 設立一個 Deadline。
遇到 429 錯誤時要乖乖聽從 Retry-After 的指示，要是遇到連續的 5xx 錯誤，就該暫停對該服務的呼叫。在發動重試前，也必須確認這個操作有沒有「冪等鍵（Idempotency Key）」。如果是寫入資料、扣款或發送通知這類有副作用的操作，絕對不能因為一個 timeout 就直接再送一次。這在處理 Webhook 串接必做的資料檢查時，也是防範重複觸發事件的核心防線。
設計明確的「降級路徑」（Fallback）
降級不是把錯誤偷偷吞掉，而是讓系統改走「事先批准的最小可用功能」。舉例來說，當我們在處理 OpenClaw 串接外部 MCP 工具的管理 遇到查詢服務不可用時，系統可以只產出待人工確認的草稿；當通知服務中斷時，把事件寫入本地的待送佇列，並清楚標示為「未送達」；如果外部資料抓不完整，就停止產出需要該資料依賴的欄位。
每一條替代路徑都要有清楚的輸入、輸出與禁止事項，並且一定要保留原始的任務 ID。這樣一來，就能避免降級產出的半成品，被下游誤認為是已經正式完工的結果。
把資料保留與恢復順序寫進流程裡
當外部服務終於恢復連線後，最怕的就是讓所有失敗的工作「同時」擠著補跑，這通常會引發二次災難。
請先保留任務原始的輸入值、版本號、執行狀態與已經完成的步驟，然後再按照優先等級分批慢慢恢復；對於那些不可重放的操作，先轉交人工核對。你的訊息佇列（Queue）必須具備去重鍵、過期時間設定與最大堆積量限制，一旦超過容量水位，就該停止接收新任務。恢復測試時，至少要驗證一次成功、一次重複提交與一次部分完成的狀況，確認不會重複寫入資料。
定義清楚的「人工接管與恢復驗收」標準
只要出現了未授權、資料不一致、重試次數超限、降級輸出依舊不完整，或是佇列持續異常增加的狀況，別猶豫，直接將任務標記為「需人工接管」，同時暫停有副作用的後續步驟。
人工接管系統必須提供明確的任務 ID、是哪個依賴服務失敗、最後一次嘗試的時間、以及系統建議的決策方向。特別是在架構複雜的 多代理 (Multi-Agent) 流程設計 中，安插人工決策的節點是確保 AI 工作流不失控的關鍵。在恢復排程前，維運人員應先用固定的測試請求驗證權限與格式，驗收過關後才能解除系統的停跑封印。
常見問題 FAQ
不行。重試前要先確認該操作是否可能已經在對方系統執行完畢，以及有沒有使用冪等鍵防護。如果是帶有副作用且狀態不明的操作，應該直接轉為人工處理。
只有在「事先定義好」且「不包含缺失關鍵資料」的情況下才可以；否則，一律必須加上「草稿」或「待人工確認」的明確標示。
當重試次數超過上限、發生嚴重的權限或資料一致性錯誤、佇列超過負載容量，或是極有可能重複執行導致副作用（如重複扣款、寄發重要信件）時，請立刻暫停。
請先發送固定的測試請求來檢查權限與回應格式，接著抽查一筆真實的工作任務，確認執行狀態、去重機制與通知結果都沒問題後，再把排程全面恢復。