多 Agent 系統故障復原：失敗模式、可靠性陷阱與生產級復原策略

1. 複合可靠性陷阱

這是多 Agent 系統最容易被忽略的問題。每個子任務獨立看起來都很可靠（95%+），但串聯起來就劇烈衰減。

Google DeepMind 2025 年 12 月的研究進一步顯示：無結構的多 Agent 網路相較於單 Agent，錯誤放大高達 17.2 倍。MAST 研究分析 1,642 次追蹤紀錄，多 Agent 系統的失敗率介於 41%–86.7%，其中最大失敗類別是協調崩潰（36.9%）。

關鍵洞察：架構決定可靠性，不是模型能力。換更強的 LLM 只會平移整條曲線，不會消除複合效應。

2. 五種真實失敗模式

子 Agent 失敗和 API 呼叫失敗是兩回事。API 回 HTTP 狀態碼，子 Agent 可能回半成品、假成功、或偷偷污染下游。根據 AI Codex 的生產經驗，實際會遇到這五種：

3. 三層復原架構

3.1 失敗分類 + 自動重試

newline 的研究指出 2–3 次重試可達 >95% 成功率。但關鍵是分清楚什麼該重試、什麼不該。

3.2 Checkpoint + Idempotency

每次子任務完成後保存狀態到持久層（LangGraph 內建 SqliteSaver 是主流做法），失敗後從上一個檢查點恢復，不重跑已完成步驟。

AI Codex 提出的關鍵設計：用輸入 hash 產出確定性 task ID，確保同一個輸入的重試不會產生副作用。

task_id = sha256(json.dumps(task_input)).hexdigest()[:16]
# 相同輸入 → 相同 ID → 安全重試

3.3 Circuit Breaker + Fallback Chain

Zylos Research 的優雅降級研究提出分層防禦：

Circuit breaker 狀態機：CLOSED → (failures > threshold) → OPEN → (cooldown) → HALF-OPEN → (success) → CLOSED。只應對基礎設施級故障（502/503/timeout）觸發，不因業務邏輯錯誤（400/401）跳閘。

4. GitHub 的三層合約模式

GitHub 工程團隊的核心洞察：「把 Agent 當程式碼對待，不是聊天介面。」他們提出三層強制合約：

5. 生產級架構選擇

Towards Data Science 總結了三種經實戰驗證的多 Agent 架構：

Klarna 的 Plan-and-Execute 實際案例：一個前沿模型做規劃，多個小型模型執行各步驟，成本降低 90% 同時維持品質。協調收益在 4 個 Agent 後趨於平緩，超過後開銷吃掉效益。

6. 務實落地：最小可行復原層

綜合以上研究，不需拆成 6 個獨立模組。一個薄 wrapper 三層就夠：

委派任務
│
├─ ① 失敗分類（transient vs deterministic）
│    └─ 只重試 timeout/空回應/529，不放 4xx/邏輯錯誤
│
├─ ② Checkpoint（輸入 hash → 任務 ID → SqliteSaver）
│    └─ 失敗從上一個檢查點恢復，不重跑已完成步驟
│
└─ ③ Circuit Breaker（3 次失敗 → 熔斷 5min → 半開探測）
     └─ 防止重試風暴，配合 fallback chain 降級

關鍵原則：重試前先分類、保存狀態再執行、熔斷比無限重試好。