兩個恢復方案，一場不該有的混淆
在 AI 程式設計團隊中，工作流程（workflow）復原是一個經常被低估的環節。你的 Agent 可能在長時間上下文運行後狀態錯亂，也可能在呼叫外部 API 時出現臨時故障。許多團隊會同時接觸「Agent Workflow Recovery Template」和「Responses API recovery order」這兩種恢復機制，卻很難說清楚什麼時候該用哪一個，或乾脆混在一起用。結果往往是恢復腳本越寫越複雜，但 Agent 的穩定性並沒有真正提升。
這篇文章直接比較兩者的適用對象、配置方式、典型失敗點，並給出一個可執行的遷移檢查清單。
兩者到底在恢復什麼
先明確兩個概念恢復的對像不同。
- Agent Workflow Recovery Template：是一個可重複使用的復原模板，通常用於 Agent 工作流程本身的故障復原。例如：當 Agent 在處理多步驟任務時，某一步因上下文過長導致 token 溢出，此時模板會回滾到上一個檢查點，重新分配上下文資源。它恢復的是 Agent 的工作流程狀態。
- Responses API recovery order：是呼叫 Responses API 時的一種重試或恢復順序策略。當你透過 Responses API 取得 LLM 回覆後，如果回傳結果異常（如內容截斷、格式錯誤），recovery order 定義了重試的優先順序和方式。它恢復的是 API 呼叫的輸出可靠性。
簡單來說：一個管工作流程內部狀態，一個管 API 呼叫結果。如果混用，可能在一個恢復場景中呼叫了另一個的配置參數，最終恢復失敗。
對比維度：誰該用哪個
| 維度 | Agent Workflow Recovery Template | Responses API recovery order |
|---|---|---|
| 適用物件 | 建構複雜 Agent 工作流程的團隊，工作流程包含多個工具呼叫、狀態持久化、情境管理 | 以 Responses API 作為主要 LLM 介面的編碼團隊，需要處理 API 層面的例外 |
| 恢復粒度 | 工作流程等級（可回滾到步驟、檢查點） | 請求等級（重試單一請求、切換模型或回退到快取回應） |
| 配置成本 | 較高：需定義檢查點、狀態序列化、回滾邏輯 | 較低：通常只需配置重試次數、逾時、回退回應策略 |
| 失敗場景 | 上下文溢位、Agent 決策迴路、工具呼叫異常（如程式碼執行掛起） | API 逾時、模型輸出格式錯誤、內容安全過濾拒絕 |
| 典型限制 | 範本本身不處理 API 層異常；如果 API 呼叫一直失敗，工作流程復原可能重複進入失敗循環 | 無法修復工作流程內部狀態損壞；如果 Agent 狀態本身已經錯亂，重試 API 意義不大 |
| 常用備份方案 | 手動重設工作流程、切換到備用 Agent、記錄日誌後人工重播 | 降級到本機模型、返回預設回覆、從緩存取上次成功回應 |
容易失敗的地方：一個真實場景
假設你是一個使用 Cloud IDE 開發 AI 程式設計工具的團隊。你們為 Agent 設定了 Workflow Recovery Template，用來在 Agent 產生程式碼時，如果上下文接近極限，自動回滾到最近的檢查點並壓縮歷史。同時，你們也配置了 Responses API recovery order，當 API 傳回不完整的程式碼片段時，自動重試一次。
問題來了：有一次 Agent 在產生大型重構程式碼時，Responses API 因為 token 限制回傳了截斷結果。 Recovery order 偵測到截斷，於是重試請求－但此時 Agent 的工作流程已經因為上下文接近極限觸發了 Recovery Template。模板將工作流程回滾到了上一個檢查點，同時，recovery order 的重試請求到達了 API，並且成功返回了完整程式碼。
但是，因為工作流程已經回滾，這個傳回的程式碼片段屬於先前的工作流程狀態，現在被錯誤地寫入了已經回滾後的會話上下文中。結果 Agent 混入了舊程式碼，問題反而更複雜。
這個案例的核心在於：兩個恢復機制獨立運行，它們沒有生命週期協調。模板恢復的是狀態，order 恢復的是 API 輸出，但當兩者同時觸發時，狀態與輸出不符。
可執行做法：改用統一的復原策略
避免上述混淆的最好方法是：不要同時啟用兩個機制的自動恢復，而是將恢復決策集中到一個地方。
具體做法如下：
- 確定主恢復機制：如果你的團隊以工作流程為核心（例如使用 Codex 或 Cloud IDE 擴充 Agent 行為），那麼優先使用 Workflow Recovery Template，並關閉 Responses API recovery order 的自動重試，改為日誌或觸發後記錄。
- 定義衝突偵測：在 Workflow Recovery Template 的回溯邏輯中，增加一項判斷：如果目前回溯是由 API 異常觸發的，則先丟棄本次 API 的傳回結果，並標記該請求不可用。
- 設定靜默期：當工作流程恢復發生後，在接下來 5 秒內禁止 Responses API 自動重試，以避免狀態與輸出不同步。
- 建立日誌稽核（audit log）：記錄每次復原的觸發原因、復原類型、最終狀態，以便排查問題時區分是工作流程問題還是 API 問題。
- 遷移檢查清單：如果你目前兩者都啟用，請按照以下步驟遷移：
- 停止 Responses API recovery order 的自動重試
- 將 API 異常處理回呼事件綁定到工作流程復原範本中
- 在 Cloud IDE 中測試一個包含 API 逾時的工作流程，觀察復原行為
- 確認工作流程復原後，API 呼叫不再重複執行
什麼時候該用備用方案
如果兩個恢復機制都關閉自動執行，仍然可能遇到需要手動介入的情況。備選方案順序如下：
- 人工重播（manual replay）：從日誌中找到上一個正常檢查點，手動觸發工作流程恢復。這是最安全的方式，適合關鍵任務。
- 切換到備用 Agent：如果主要 Agent 的工作流程狀態已不可恢復，啟動一個備用 Agent（使用不同的上下文空間）重新處理目前任務。
- 降級到輕量級模型：當反覆出現 API 輸出錯誤時，暫時將模型切換到更簡單、更穩定的版本（如從 GPT-4 降級到 GPT-3.5-turbo），以完成目前最核心的程式碼補全。
總結
Agent Workflow Recovery Template 和 Responses API recovery order 不是替代關係，而是不同層的復原工具。混用的後果是狀態與呼叫結果可能不一致，導致 Agent 產生不可預測的行為。最佳實踐是：以工作流程恢復為主，將 API 復原事件整合進工作流程模板，同時關閉 API 層的自動重試，並利用日誌和靜默期來避免衝突。
下一步，如果你希望深入掌握 AI 工程中 Agent 工作流程的高可用設計，包括更複雜的上下文管理、工具調用恢復與多模型切換策略，可以關注後續的原始付費文章與 AI 編程進階課程。
暫無評論，快來發表你的看法吧