傳統的自動化不是成功就是失敗。Zapier 的 zap 將資料從 A 移動到 B——如果 API 呼叫失敗，它會重試。每次的輸出都相同。
AI 工作流程則不同。模型可能在負載下逾時。速率限制可能會節流你的請求。輸出可能有效但未達標。而且因為 AI 工作流程通常有多個步驟,第 3 步的失敗不應該讓第 1 步和第 2 步的成功結果付諸流水。
針對這些現實情況進行設計,就是你的團隊信任的工作流程與他們在第一次不好的體驗後就放棄的工作流程之間的差別。
帶退避的自動重試
JieGou 會自動以指數退避重試失敗的 recipe 步驟。當步驟因暫時性錯誤而失敗時——速率限制 (429)、伺服器錯誤 (502, 503) 或逾時——系統會等待並重試,以指數方式退避 (2秒、4秒、8秒,最多 30秒),並加入隨機抖動以避免驚群問題。
你可以為每個步驟設定最大重試次數。對於大多數 recipe,2-3 次重試就能處理暫時性錯誤,而不會顯著延遲工作流程。對於速率限制常見的高流量工作流程,你可能會設定更高的重試次數。
永久性錯誤——無效輸入、身份驗證失敗、模型拒絕——會完全跳過重試。重試一個每次都會以相同方式失敗的請求毫無意義。
錯誤分類很重要
並非所有失敗都是平等的。JieGou 將錯誤分類,以便工作流程能適當回應:
- 暫時性錯誤(可重試):速率限制、伺服器過載、網路逾時。這些會透過重試自行解決。
- 永久性錯誤(不可重試):錯誤輸入、身份驗證失敗、內容政策違規。這些需要人工介入或輸入變更。
- 部分成功:AI 回傳了輸出,但未完全符合預期的 schema。工作流程可以使用現有內容繼續,或標記問題供審查。
這種分類是自動的。你不需要撰寫錯誤處理邏輯——執行器知道哪些 HTTP 狀態碼是暫時性的,哪些是永久性的。
核准關卡作為安全網
核准步驟不僅用於業務流程簽核。它們也是可靠性檢查點。
在任何輸出品質對下游步驟很重要的步驟之後放置核准關卡。例如:
- 研究潛在客戶(recipe 步驟)
- 審查研究品質(核准關卡)
- 根據研究草擬外展內容(recipe 步驟)
如果研究步驟回傳的結果很少——也許公司規模小,公開資訊有限——核准關卡讓人類決定是否使用現有資訊繼續,或在草擬外展內容前提供額外背景。
如果沒有關卡,外展步驟會根據不完整的研究產生電子郵件,產生通用訊息,違背了自動化的目的。
用條件步驟驗證輸出
使用條件步驟在繼續之前檢查輸出品質:
- 提取發票資料(recipe 步驟)
- 條件:如果 total_amount 存在且 line_items 不為空(條件步驟)
- 則:繼續差異檢查
- 否則:標記為需人工處理
這能捕捉 AI 未能提取關鍵欄位的情況——也許發票格式不尋常或文字掃描品質不佳。工作流程不會將不完整的資料傳遞到下一步,而是將其路由給人類處理。
失敗時的 Webhook 通知
工作流程可以在完成時發送 webhook 通知——無論是成功還是有錯誤。設定輸出 webhook 以在工作流程失敗時通知你的團隊:
- 當排程工作流程遇到錯誤時發送到 Slack 頻道
- 對於需要立即關注的關鍵工作流程發送到 PagerDuty
- 更新狀態儀表板顯示工作流程健康狀態
Webhook 酬載包含執行 ID、狀態、哪個步驟失敗以及錯誤詳情。你的團隊會獲得可操作的資訊,而不只是「出問題了」。
平行執行和部分失敗
平行步驟會同時執行多個分支。如果一個分支失敗,其他分支會繼續。這是設計如此——一個獨立分支的失敗不應該阻擋不相關的工作。
平行執行完成後,你可以檢查哪些分支成功,哪些失敗。平行區塊後的條件步驟可以根據所有分支是否完成或有些失敗來路由工作流程。
為第 95 百分位數設計
大多數 AI 呼叫在第一次嘗試時就會成功。大多數輸出符合預期的 schema。大多數工作流程執行沒有問題。但當你為依賴結果的團隊每天執行工作流程時,「大多數」是不夠的。
為那 5% 的情況設計你的工作流程:
- 為每個 recipe 步驟新增重試。失敗時額外幾次 API 呼叫的成本,與工作流程執行失敗的成本相比微不足道。
- 在高風險輸出前新增核准關卡。如果工作流程產生的內容會發送給客戶或高階主管,應該由人類驗證。
- 在提取步驟後新增條件檢查。在將資料往前傳遞之前,驗證 AI 實際上提取了你需要的資料。
- 為排程和觸發的工作流程設定 webhook 通知。如果沒有人在看 UI,當出問題時你需要警報。
目標是能優雅降級的工作流程——將問題浮現給人類,而不是默默產生錯誤輸出。