多 Agent 協作指南：讓 AI 團隊不再各做各的

整理自實際運行多 Agent 系統數個月的經驗。每個 pattern 都是因為「少了它就出事」才被加進來的。

有了一個 AI Agent，它很好用。於是加了第二個、第三個，事情開始失控：

• Agent A 和 Agent B 同時改了同一個檔案
• 一個 API 掛了，三個 Agent 同時瘋狂重試，帳單爆炸
• Sub-agent 做完事，靜靜消失，沒人知道它到底成功還是失敗

問題核心多半在協作這一層，不在 AI 本身。

下面這 5 個 pattern 都是在生產環境中反覆驗證過的，能讓 AI 團隊真正一起工作。

---

先看全局：多 Agent 系統長什麼樣？

一個典型的多 Agent 系統長這樣：

        🎯 指揮者 Orchestrator
                │
        ┌───────┼───────┬─────────┐
        ▼       ▼       ▼         ▼
   🔧 執行者 A  🔧 執行者 B  🔍 審查者   📁 共享檔案系統
        │       │           │
        └───────┴───────────┴──→ 📁 共享檔案系統

關鍵架構特性：

為什麼是這個形狀？目前大多數 AI 工具給的 sub-agent 是無狀態的。它們沒有持久記憶，也沒有跟其他 agent 對話的能力。檔案系統是唯一可靠的協作機制。

---

Pattern 1：檔案白板（File Blackboard）

所有 Agent 透過檔案溝通，不透過訊息。檔案系統就是訊息匯流排。

問題

三個 Agent 需要協作，但它們：

• 沒有記憶：每次被喚起都是全新的
• 彼此隔離：沒有內建的通訊管道
• 隨時可能消失：session 說斷就斷

解法：把檔案系統當白板

workspace/
  status.md          ← 專案狀態（只有指揮者能改）
  tasks/
    task-001.md      ← 任務信封（給執行者的指示）
    task-002.md
  artifacts/
    task-001-out.md  ← 執行者的產出
    task-002-out.md
  checkpoints/
    checkpoint.json  ← 當機復原用

存取規則

核心規則就一條：只有指揮者能寫全域狀態。 執行者只能寫自己被指定的輸出位置。

為什麼是檔案？

檔案的好處：可檢視（直接打開看）、耐久（不怕 session 斷掉）、可版控（放 git 就有完整歷史）。

---

Pattern 2：任務信封（Task Envelope）

不要只跟 sub-agent 說「做 X」。給它結構化的任務包。

問題

spawn 一個 sub-agent 然後說「幫忙分析這個資料」，它可能會：

• 分析錯誤的欄位
• 跑了 50 次工具呼叫（實際上只需要 5 次）
• 做完後只回一句「分析完了」，沒有要求的格式

解法：每個任務都包成信封

## 任務：analyze-q1-data
- **目標**：摘要 Q1 營收趨勢
- **驗收標準**：產出包含趨勢方向、前 3 大驅動因素、信心等級
- **輸入**：data/q1-revenue.csv（按產品線的季度營收）
- **輸出位置**：artifacts/analyze-q1-data.md
- **預算**：最多 5 次工具呼叫
- **停止條件**：如果資料檔不存在或格式錯誤，停下並回報

信封裡該有什麼？

輕量版 vs 完整版

不是每個任務都需要完整信封。簡單規則：

• 3 步以內就能做完 → 口頭交代就好
• 有外部 API 或多檔案 → 用輕量信封（目標 + 輸入 + 輸出）
• 高風險或高成本 → 完整信封（含預算和停止條件）

---

Pattern 3：熔斷機制（Circuit Breaker）

追蹤每個 API 的連續失敗次數。三次就斷電，等一等，再試一次。

問題

Agent 打 API 碰到 429（速率限制）。它重試，再重試。同時第二個 Agent 也在重試，現在兩個都在瘋狂打同一個 API，讓速率限制更嚴重。第三個 Agent 切換到備用供應商，結果備用也被打爆了。

這就是重試風暴（Retry Storm），多 Agent 系統中最快燒光預算的方式。

解法：三態熔斷器

什麼錯誤該觸發熔斷？

不是所有錯誤都一樣：

實際踩過的坑

沉默的 Proxy 當機： API proxy 掛了，每個請求都回一樣的 generic error。Agent 不停重試，因為錯誤看起來像暫時性的。

教訓： 連續多次以上收到一模一樣的錯誤，不管錯誤碼是什麼，直接觸發熔斷。一模一樣的連續錯誤等於系統性故障。

---

Pattern 4：人機升級（HITL Escalation）

知道什麼時候該問人，是 AI 系統最重要的能力之一。

三層升級制度

關鍵指標：升級率

理想的升級率是 10-15%：

• 太低（< 5%）→ AI 在做高風險的事情卻沒有通知，危險。
• 太高（> 30%）→ 人變成瓶頸，自動化失去意義。
• 10-15% → 大部分事情自動化，重要的事情有人把關。

升級時的資訊格式

當 Agent 升級到人類時，不要只說「不確定」，給決策所需的完整資訊：

## 需要決策

**情境**：正在部署新版本到生產環境
**問題**：測試全過，但有一個 warning 跟記憶體使用有關
**選項**：
  A. 照常部署（warning 歷史上沒有造成問題）
  B. 先修 warning 再部署（預估延遲 2 小時）
  C. 部署到 staging 先觀察一天

**建議**：選 A，因為 [原因]
**等待回覆中……**

---

Pattern 5：模型選擇（Model Selection）

貴的模型用來思考，便宜的模型用來執行，反過來就是浪費錢。

二分法則

多 Agent 成本控制最核心的一條規則：

• 需要判斷力（策略 / 分析 / 審查）→ 貴的模型
• 不需要判斷力（寫 code / 格式化 / 抓資料）→ 便宜的模型

常見配置

省錢的 80/20 法則

四個改動就能省下大部分多 Agent 成本：

1. 模型分級（貴的思考，便宜的執行）→ 影響最大
2. 傳路徑不傳內容（讓 agent 自己讀檔）→ 省 token
3. 壓縮已完成的階段（只留一句話摘要）→ 省 token
4. 任務信封裡設預算上限 → 避免異常值

---

總結：5 個 Pattern 的關係

這些 pattern 不是各自獨立的，它們組成一個完整的運作體系：

---

開始動手

最小可行的順序：

1. 建一個共享目錄（workspace/status.md + tasks/ + artifacts/）
2. 第一個任務用信封包（不需要完整版，目標 + 輸入 + 輸出就夠）
3. 加熔斷機制（用 JSON 檔追蹤 API 失敗次數）
4. 決定哪些操作需要人批准（先從「會影響外部系統」的開始）

這四步做完，就有一個可運作的多 Agent 協作系統了。

想要完整的 pattern 文件、程式碼範本和更多實戰案例，整理成了開源 repo：

👉 Orchestration Playbook on GitHub

MIT 授權，歡迎取用。

延伸閱讀

• 多 Agent 開發流程
• 用 AI 團隊開發演算法
• Claude Code + Codex 協作 playbook
• OpenClaw 多 Agent 架構
• AI Agent 自我修復

小企鵝的經驗

OpenClaw 跑的 Opus / Sonnet / ChatGPT 三 agent 系統，這 5 個 pattern 是踩坑後一條一條長出來的。最初幾版兩個 agent 同時改同一個檔，狀態就花了；API 失敗時三個 agent 一起重試，帳單馬上跳。後來把共享狀態收斂到檔案系統、任務都包成信封、API 加熔斷、重要操作走人工 gate，整個系統才穩下來。模型分級（指揮用貴的，執行用便宜的）是後期才放上去，省下來的 token 比想像中多。

常見問題

Q: 什麼是 AI Agent 的 Orchestration？

Orchestration 是指一個主要的 Agent（指揮者）負責分配任務、收集結果、處理失敗，而其他 Agent 專心執行各自被分配的工作。就像樂團指揮一樣，確保每個樂手在對的時間演奏對的樂曲。

Q: 為什麼 AI Agent 不能直接互相對話？

目前大多數 AI 工具（Claude Code、Codex 等）的 Sub-agent 是無狀態的。它們被生出來、執行任務、回報結果後就消失了。沒有持久的記憶，也沒有內建的通訊機制。所以需要透過檔案系統來間接溝通。

Q: Circuit Breaker 在 AI 系統中的作用是什麼？

Circuit Breaker（熔斷機制）會追蹤 API 呼叫的連續失敗次數。當連續失敗達到閾值時，自動停止呼叫一段時間，避免所有 Agent 同時重試造成的『重試風暴』，這是多 Agent 系統中最燒錢的故障模式。

---

整理：Penna｜小企鵝 Penchan