昨天把 Checkpoint 和每一步的狀態記錄加進 Workflow 之後，流程失敗終於不用每次都從第一步重新跑，例如十個步驟跑到第八步才出錯，我可以保留前七步已經完成的結果，只重新處理第八步，再從後面繼續。

不過真的開始讓它自己重跑之後，很快又碰到下一個問題，失敗之後重新執行看起來很合理，可是有些錯誤重試一次就會好，有些錯誤跑一百次結果還是一樣。

如果全部都用同一套 Retry 規則，最後很可能只是把原本的一次錯誤變成連續三次一模一樣的錯誤。

先分清楚這次到底為什麼失敗

以前自己操作的時候其實很自然，網站 Timeout 會重新整理一次，密碼錯了就不會一直按登入，API Rate Limit 則知道可能要等一下再試。

自動化流程也需要做類似的判斷。

我現在先很粗地把錯誤分成幾類：

Timeout
Rate Limit
Temporary Service Error
Invalid Input
Authentication Error
Permission Error
Validation Error

像 Timeout、暫時性的 Service Error 通常值得 Retry，因為下一次呼叫時外部服務可能已經恢復。

但如果錯誤是：

Invalid API Key

重跑十次也不會突然變成正確的 API Key。

同樣地，如果 AI 產生的 JSON 一直沒有符合 Schema，可以先嘗試重新生成一次，但如果 Retry 幾次仍然失敗，就應該停下來留下原始輸出，而不是讓 Workflow 一直自己轉下去。

Retry 不能馬上一直打

假設 API 回傳：

429 Too Many Requests

如果流程的策略是：

失敗
立刻 Retry
失敗
立刻 Retry
失敗

那很可能只是讓 Rate Limit 更嚴重。

所以我開始加入 Backoff，最簡單可以先變成：

第 1 次失敗 → 等 2 秒
第 2 次失敗 → 等 4 秒
第 3 次失敗 → 等 8 秒

這就是很常見的 Exponential Backoff。

如果外部服務只是暫時忙碌，留一點時間之後再重新嘗試，成功率通常會比連續狂打好很多，同時也比較不會讓自己的自動化流程在對方服務出問題時，反過來製造更多 Request。

實際做的時候還可以加一點隨機時間，也就是 Jitter，避免大量 Workflow 剛好全部在同一秒重新發 Request。

有些 Error 一看到就應該停

Retry 做下去之後，我反而覺得更重要的是 Stop Condition。

像下面這些情況我現在會比較希望流程直接停止：

Authentication Failed
Permission Denied
Invalid Required Field
Schema Changed
Human Approval Required

因為這些問題通常不是時間能解決的。

例如 Google Sheet 原本有一個 Email 欄位，某天有人把欄位改成 User Email，Workflow 讀不到資料之後，如果只是一直 Retry：

找不到 Email
找不到 Email
找不到 Email

完全沒有意義。

比較合理的行為是直接把目前 Step 標成：

FAILED_NEEDS_ATTENTION

留下錯誤訊息、輸入資料和執行位置，等人修改流程之後再從 Checkpoint 繼續。

昨天做的 Checkpoint 到這裡才真的開始有價值。

AI 的錯誤又比一般 API 麻煩一點

一般 API Failure 很多時候有 Status Code 可以看，但 AI 的失敗比較曖昧，有時候 Request 是成功的、HTTP 也是 200，結果內容卻不符合需求。

例如我要：

{
  "priority": "high",
  "category": "bug"
}

模型卻回：

這看起來應該是一個高優先級的 bug。

從 API 的角度完全成功，自動化流程卻沒有辦法繼續。

所以 AI Step 的 Retry Trigger 不能只看 Exception，我還要把前面 AI Engineering 裡用過的 Validation 概念搬過來：

API Success
↓
Schema Validation
↓
Business Rule Validation
↓
Pass / Retry / Stop

如果只是一個格式小問題，可以 Retry 一次並把 Validation Error 一起傳回模型，例如告訴它缺少 priority 欄位。

但如果輸入本身資訊不足，像 Issue 裡根本沒有任何內容可以判斷 Priority，那一直叫模型重新猜其實也沒有幫助，這時候比較適合直接送到人工確認。

我現在比較想要的是有理由的 Retry

一開始做自動化時，Retry 對我來說比較像一個開關：

Retry = 3

現在則開始覺得這個設定太粗了。

比較完整的狀態可能會變成：

Timeout
Retry: Yes
Max Attempts: 3
Backoff: Exponential

Rate Limit
Retry: Yes
Max Attempts: 5
Respect Retry-After: Yes

Validation Error
Retry: Once
Include Error Feedback: Yes

Authentication Error
Retry: No
Escalate: Human

Workflow 才會知道自己為什麼重新跑，以及什麼時候應該放棄。

做到 Day 16 之後，我發現穩定的自動化並不是讓流程永遠不要失敗，外部 API 會掛掉、網路會斷、資料格式會改、模型偶爾也會產生奇怪輸出，這些事情很難全部避掉。

真正需要設計的是失敗出現之後流程要做什麼，有些錯誤等幾秒再試一次，有些只值得再給模型一次機會，有些則應該立刻停止並把問題交回來。

只要這些邏輯開始寫清楚，自動化就比較不像一條只能祈禱它順利跑到底的流程，而是就算中間出事，也知道下一步該往哪裡走。