Agent Engineering Recovery Workflow Example vs Responses API recovery order：AI 程式設計團隊該如何選擇

適用對象

本文為 AI 程式設計團隊的工程師和技術負責人。你們正在建立或維護 Agent 系統，遇到了「恢復工作流程」（recovery workflow）的設計難題：當 Agent 呼叫失敗、上下文遺失或工具執行逾時時，應該用哪種方式讓系統自動恢復？你們可能已經聽過 Agent Engineering 社群推薦的「Recovery Workflow Example」（重試+狀態回滾的範本），也接觸過 OpenAI Responses API 自帶的「recovery order」機制。但究竟在什麼場景下選哪個？這需要根據團隊的技術堆疊、系統複雜度以及對恢復精度的需求來判斷。

對比維度

1. 復原能力範圍：自訂 vs 平台內建

Agent Engineering Recovery Workflow Example 通常是一個自訂實現的恢復模板，它允許你定義「恢復鏈」（recovery chain）：例如先重試三次，不行就回滾到上一個檢查點，再不行就降級（degrade）到只讀模式。這種彈性意味著你可以精確控制每一步的復原邏輯，甚至能寫條件分支來處理不同的錯誤類型。

Responses API recovery order 則是 OpenAI 提供的內部恢復機制，它在 API 呼叫層實作。當一次請求失敗時，API 會自動依照預設優先權嘗試備用配置（例如回退到較小的模型、降低 temperature、縮短 max_tokens）。但你不能幹預這個順序，只能透過調整 API 參數中的「recovery order」陣列來改變優先順序。

2. 適用場景：何時用自訂恢復，何時用 API 級恢復

場景一：Agent 內多工具呼叫的恢復

想像一個需要順序調用「搜尋->程式碼產生->測試」的 Agent。如果程式碼產生失敗，你可能會想回滾搜尋的副作用（例如釋放記憶體），然後再試一次。這時 Responses API recovery order 無能為力，因為它只處理單一 API 呼叫的失敗，無法感知多個工具間的狀態依賴。你需要自訂 Recovery Workflow Example，引入一個狀態機來管理每一步的補償操作。

具體做法：在 Agent 的循環中，為每個工具呼叫定義「on_failure」回呼。當程式碼產生失敗時，先執行搜尋的回滾函數（例如清除快取），再根據錯誤類型決定是否要替換成備用程式碼模型。

場景二：高負載下的 API 呼叫快速降級

如果你的團隊用 Responses API 建造聊天機器人，上了一個昂貴的 gpt-4o 模型。當 API 傳回 429（限流）或 500（伺服器錯誤）時，你希望自動切換到更小、更便宜的 gpt-3.5-turbo 模型，並且降低迴應長度以節省成本。這時用 Responses API recovery order 最直接：在請求中設定 "recovery_order": [{"model": "gpt-3.5-turbo", "max_tokens": 512}, {"model": "gpt-3.5-turbo", "max_token」: "gpt-3.5-turbo", "max_token」}。每次失敗 API 自動依序嘗試，無需你寫重試邏輯。

3. 最容易失敗的邊界

失敗點一：自訂恢復工作流程狀態膨脹

很多團隊剛開始用 Recovery Workflow Example 時，喜歡把每種錯誤都映射成一個恢復步驟。但很快狀態圖就變成一團亂麻。一位工程師在 Reddit 上分享過：他的 Agent 有 12 個狀態和 30 個轉換，導致測試覆蓋率不到 30%。最後在一次生產事故中，恢復工作流程進入了死循環，日誌裡全是「recovery->rollback->retry->recovery」。

關鍵在於：不要為所有錯誤設計恢復。給錯誤分優先級，只對「可恢復的」錯誤（如網路逾時、臨時性限流）定義恢復路徑。對於「不可恢復的」（如無效輸入格式、權限不足），應該直接拋給人類處理。

失敗點二：Responses API recovery order 無法處理業務級錯誤

Responses API 的 recovery order 只覆寫 HTTP 層錯誤。如果你的業務邏輯中，API 回傳了 200 但 JSON 欄位缺失或內容被截斷，它不會觸發復原。有一次我們用 gpt-4-1106-preview 產生了程式碼，結果回傳的程式碼區塊被截斷了一半，但 API 認為請求成功。這種情況下 recovery order 不會啟動恢復，我們需要在應用層偵測完整性並觸發重試。

一個真實場景（含失敗與解決方案）

去年幫一個做程式碼審查的 AI 產品團隊做重構。他們用 Responses API 建構了一個程式碼分析 Agent：接收 diff，呼叫 API 分析，回傳建議。高峰期 API 經常逾時，所以他們設定了 recovery order：先重試同配置兩次，然後切換成 gpt-3.5-turbo。方案看起來合理，但上線後發現：當 gpt-3.5-turbo 也超時時，API 會回傳一個錯誤，而 recovery order 執行完畢，不再重試。這個錯誤沒有被應用層捕獲，導致使用者看到空白頁面。

後來我們改為自訂 Recovery Workflow Example：在 API 執行層外層包覆一層復原邏輯－如果所有 API 復原步驟都失敗，就傳回一個有「分析逾時，請稍後重試」的降級回應，而不是讓錯誤穿透到 UI。同時記錄這次失敗的上下文到日誌（包括 diff 摘要），以便後續離線重跑。

這個案例說明：Responses API recovery order 適合作為第一道防線，但不能解決所有問題。對於需要優雅降級和日誌追蹤的複雜場景，自訂復原工作流程是必要補充。

可執行做法：團隊該怎麼選

1. 列出你的 Agent 的核心呼叫類型：是單 API 呼叫還是多工具鍊式呼叫？單一呼叫考慮 Responses API recovery order，多重呼叫考慮自訂 Recovery Workflow。
2. 為錯誤分等級：哪些錯誤是「可恢復的」（如逾時、限流）？哪些是「不可恢復的」（如無效參數、身份驗證失敗）？只對可恢復的錯誤設計恢復路徑。
3. 從簡單開始：先用 Responses API recovery order 做快速層，再為關鍵路徑新增自訂恢復。不要在第一天就設計複雜的恢復狀態機。
4. 監控復原效果：記錄每次復原成功或失敗的日誌。如果恢復成功率低於 80%，則需要調整恢復策略（例如增加重試間隔、更換備用模型）。
5. 準備備用方案：如果兩種恢復方式都無法處理錯誤，確保系統有「降級回應」機制（例如返回快取結果或提示使用者稍後重試），而不是讓錯誤暴露給終端用戶。

限制

• Agent Engineering Recovery Workflow Example 需要團隊具備狀態機設計能力，維護成本較高。
• Responses API recovery order 僅對 OpenAI API 有效，如果切換到其他模型提供者（如 Anthropic），需要自行實現。
• 兩種方式都不能保證 100% 恢復成功。對於根因是程式碼 bug 或資料錯誤的失敗，復原只會掩蓋問題，最終需要人工介入。

總結

在 AI 程式設計團隊中，選擇恢復工作流程不是“二選一”，而是分層防禦。 Responses API recovery order 適合快速處理 API 層的瞬時失敗，而自訂 Recovery Workflow Example 適合處理複雜的業務級復原和狀態管理。根據你的呼叫鍊長度和業務容忍度，決定在哪一層部署恢復邏輯。

下一步

如果你希望有系統地掌握 Agent 工程的設計模式，包括恢復工作流程、情境管理、工具校準等核心技能，推薦深入學習高品質原創付費文章和 AI 程式設計進階課程。