當 AI 工作流程替你寄信、建立客服單或呼叫外部工具時，「重試」不是把同一句提示詞再送一次這麼簡單。AI 自動化重試真正要處理的是：第一次呼叫可能已經完成，只是回應在途中遺失。若代理把逾時當成失敗，第二次執行就可能重複寄信、重複建單。本文以一般後端重試為基礎，說明 AI 代理如何把執行邏輯做得可追蹤、可恢復；文中的情境例子皆為虛構、非實測，實作仍須依各平台文件判斷。 原創概念插圖，非流程規格：同一次操作的重試，應沿用同一個作業識別。 1. 先分清楚：逾時不等於失敗 客戶端逾時只代表「在限定時間內沒有收到可用回應」，不代表遠端服務沒有執行。AWS Builders’ Library 的逾時、重試與抖動文章提醒，逾時或網路錯誤發生時，副作用可能已經發生；有副作用的呼叫若沒有冪等設計，重試並不安全。 因此，AI 代理的狀態不應只有成功／失敗兩格，至少要能表達「已確認成功」「確認未開始」與「結果含糊」。例如建立工單的回應遺失時，代理不應立即再建一張，而應先用原本的業務操作識別查詢結果；查不到也不能直接宣稱一定沒建立，必要時轉入對帳或人工覆核。 這和「再次呼叫模型」是兩件事。模型可以重新判斷下一步，但模型重試本身不會替外部系統去重，也不能消除第一次工具呼叫的未知結果。 2. 用穩定的業務操作識別，不要用每次執行的新 ID 冪等性（idempotency）可以白話理解為：同一操作重複請求，不因重試而增加一次副作用；它不等於讓模型每次回答都一樣。防止重複執行的核心，是讓同一個業務意圖在重試中保持同一個識別。例如「替訂單 A-123 建立退貨申請」可形成穩定的 operation ID（作業識別）；同一次操作的所有模型輪次、工作佇列訊息與工具呼叫，都帶著這個上下文。 同一次操作最初可以產生隨機 ID，但每次重試都重新產生，反而會讓系統把重試誤認為新工作。不要只拿訂單編號當鍵：同一訂單的兩次合法操作仍需不同作業識別，只有同一次操作的重試才沿用。 接著把作業識別映射成服務可理解的冪等鍵（idempotency key），並定義鍵的作用範圍、保存時間與參數一致性。Stripe 的官方文件示範了這種設計：同一鍵可用於重試，服務會保存首次執行的結果；若後續參數不同，會拒絕不一致的重用。這是 Stripe API 的具體行為，不能直接當成所有供應商的共同標準，實作前必須查該服務契約。 識別內容也不要直接塞入電郵地址、姓名等敏感資料。可用高熵隨機鍵或內部不可猜測的作業 ID，再把業務資料留在受控的伺服器端紀錄。 3. 去重必須靠原子性，不是「先查表再執行」 常見但危險的做法是：先查「這個鍵是否存在」，不存在才寄信或建單，完成後再寫入紀錄。兩個並行請求可能同時查到不存在，接著一起執行，形成競態；所以單純查表後執行，不能保證自動化防重複。 較可靠的方向是讓資料庫唯一約束、原子插入／佔位、交易或由外部服務原生支援的冪等鍵，負責裁決誰能建立這個操作。這裡的「原子性」，是指關鍵判斷與狀態變更不可被其他同時執行的工作插隊拆開。副作用和狀態紀錄仍要設計一致性邊界：例如先取得唯一的作業狀態，再由具冪等契約的寄信服務發送；若外部系統沒有這種契約，就不能靠 AI 自己聲稱「已防重複」。 還要保存請求指紋與結果，避免同一鍵被拿去做不同事情。若兩次請求的收件人、內容或工單主旨不一致，應停下來報錯，而不是猜哪一個才是最新意圖。 原創概念插圖，非流程規格：結果不明時，先核對紀錄，再決定是否重試。 4. 只重試暫時錯誤，並限制次數與總等待時間 不是每個錯誤都值得再試。網路連線中斷、服務暫時不可用、限流或部分 5xx，可能適合重試；驗證失敗、權限不足、參數錯誤與資源不存在，通常應停止並修正原因，除非該服務文件另有規則。即使錯誤被列為可重試，有副作用的操作仍須確認冪等契約；不具備時應先對帳，不要盲目重送。AWS SDK 官方重試行為文件也採錯誤分類，而非無差別重試。 實務上應設定總嘗試次數或總等待時間，使用指數退避加 jitter（隨機抖動）：失敗後逐漸拉長等待，再加入隨機延遲，避免所有工作同時重送；到達上限後，進入待處理佇列或人工處理。AWS Well-Architected 的REL05-BP03同樣建議退避、抖動與最大重試值，並警告多層同時重試會放大流量。AI 代理尤其要避免「模型層、工具 SDK、佇列」各自重試，最好指定一個主要控制層。 重試策略不是保證不重複的承諾；它只是降低暫時故障的影響。每一次嘗試都應記錄作業識別、冪等鍵、錯誤類別、等待時間與最終狀態，方便查出是否真的執行過。 5. 遇到含糊結果，先對帳，再決定是否人工覆核 當回應遺失、串流中斷、工具回傳格式損壞，系統可能不知道副作用的真實狀態。這時不應讓模型自由發揮「再做一次」，而要進入對帳狀態：用同一個作業識別或服務提供的查詢條件查詢，核對時間、目標、內容指紋與外部資源 ID。 若查詢結果清楚，就把本地狀態補齊；若結果互相矛盾、查詢本身也失敗，應保留「未知」而不是偽造成功或失敗。對寄信、批次建單等可延後工作，可暫停自動化並交給人工覆核。涉及付款、公開發佈或刪除資料時，更應先核對遠端結果，保留人工介入機制。 這套做法讓 AI 工作流程把模型用在分類、摘要與提出候選處置，而把「是否可重試」「鍵是否一致」「何時升級」交給可測試的程式與服務契約。若要把回答接進工具，可搭配AI 結構化輸出與 JSON Schema檢查資料格式；但格式正確，仍不代表外部動作只執行一次。 常見問題 AI 自動化重試是不是把提示詞再送一次？ 不是。模型重試只重新取得判斷，外部工具的副作用仍須靠冪等鍵、唯一約束與狀態機處理。 逾時後查不到紀錄，可以直接再建單嗎？ 不能一概而論。先確認查詢與建立操作的契約；若仍無法判定，保留未知狀態並人工覆核，避免把查不到誤當成未發生。 冪等鍵是不是永遠有效？ 不是。保存期限、作用範圍與參數比對都由各服務定義。應在文件中確認，並避免把某一平台的規則當成通用標準。
