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

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

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

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

這不是 AI 的問題，是協作的問題。

這篇文章會介紹 5 個我們在生產環境中反覆驗證的協作 pattern，讓你的 AI 團隊能真正一起工作。

---

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

在深入每個 pattern 之前，先建立全局觀。一個典型的多 Agent 系統長這樣：

graph TD
    O["🎯 指揮者 Orchestrator"] --> A["🔧 執行者 A"]
    O --> B["🔧 執行者 B"]
    O --> C["🔍 審查者"]
    A --> F["📁 共享檔案系統"]
    B --> F
    C --> F
    O --> F

    style O fill:#CBA000,stroke:#2A2118,color:#2A2118
    style F fill:#FAF6EE,stroke:#CBA000,color:#2A2118
    style A fill:#E8ECF1,stroke:#2A2118,color:#2A2118
    style B fill:#E8ECF1,stroke:#2A2118,color:#2A2118
    style C fill:#E8ECF1,stroke:#2A2118,color:#2A2118

關鍵架構特性：

特性	說明
階層式管理	一個指揮者統籌一切
無狀態的執行者	收到任務、執行、回報、結束
檔案即通訊	所有狀態都存在檔案裡
禁止橫向對話	執行者之間不直接溝通

為什麼是這個形狀？因為目前大多數 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  ← 當機復原用

存取規則

graph LR
    O["指揮者"] -->|讀寫| S["status.md"]
    O -->|讀寫| T["tasks/"]
    O -->|讀| A["artifacts/"]
    E["執行者"] -->|讀| T
    E -->|寫| A
    E -.->|❌ 禁止| S

    style O fill:#CBA000,stroke:#2A2118,color:#2A2118
    style S fill:#FAF6EE,stroke:#CBA000,color:#2A2118
    style E fill:#E8ECF1,stroke:#2A2118,color:#2A2118

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

為什麼是檔案？

替代方案	問題
記憶體共享	Agent 一當機就全沒了
訊息佇列	單機環境殺雞用牛刀
資料庫	多數 AI 工具操作文字檔更順手
Agent 對 Agent API	目前幾乎沒有平台支援

檔案的好處：可檢視（直接打開看）、耐久（不怕 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 次工具呼叫
- **停止條件**：如果資料檔不存在或格式錯誤，停下並回報

信封裡該有什麼？

graph TD
    E["📨 任務信封"] --> G["🎯 目標：做什麼"]
    E --> AC["✅ 驗收標準：怎樣算做好"]
    E --> I["📥 輸入：讀哪些檔案"]
    E --> O["📤 輸出：寫到哪裡"]
    E --> B["💰 預算：最多幾次呼叫"]
    E --> S["🛑 停止條件：什麼時候該放棄"]

    style E fill:#CBA000,stroke:#2A2118,color:#2A2118
    style G fill:#FAF6EE,stroke:#CBA000,color:#2A2118
    style AC fill:#FAF6EE,stroke:#CBA000,color:#2A2118
    style I fill:#FAF6EE,stroke:#CBA000,color:#2A2118
    style O fill:#FAF6EE,stroke:#CBA000,color:#2A2118
    style B fill:#FAF6EE,stroke:#CBA000,color:#2A2118
    style S fill:#FAF6EE,stroke:#CBA000,color:#2A2118

每個欄位都有它的意義：

欄位	沒有它會怎樣
目標	Agent 自己猜你要什麼
驗收標準	產出品質不可控
輸入	Agent 可能讀錯檔案，或把整個目錄都讀一遍
輸出位置	結果不知道寫到哪裡去了
預算	Agent 無限探索，帳單爆炸
停止條件	遇到問題卡住不動，也不回報

輕量版 vs 完整版

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

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

---

Pattern 3：熔斷機制（Circuit Breaker）

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

問題

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

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

解法：三態熔斷器

stateDiagram-v2
    [*] --> CLOSED
    CLOSED --> OPEN : 60 秒內連續失敗 3 次
    OPEN --> HALF_OPEN : 等待 5 分鐘
    HALF_OPEN --> CLOSED : 探測成功 ✅
    HALF_OPEN --> OPEN : 探測失敗 ❌（冷卻加倍）

    note right of CLOSED : 正常運作，放行所有呼叫
    note right of OPEN : 全部擋下，不呼叫 API
    note right of HALF_OPEN : 只放一個探測呼叫

狀態	行為	轉換條件
CLOSED（正常）	所有呼叫正常進行	60 秒內連續失敗 3 次 → OPEN
OPEN（斷路）	所有呼叫立即失敗，不實際執行	等 5 分鐘 → HALF-OPEN
HALF-OPEN（試探）	只放行一個呼叫	成功 → CLOSED；失敗 → OPEN（冷卻加倍）

什麼錯誤該觸發熔斷？

這很重要——不是所有錯誤都一樣：

錯誤類型	觸發熔斷？	原因
429（速率限制）	✅	繼續打只會更糟
503（服務不可用）	✅	對方掛了
網路逾時	✅	連線問題不會下一秒就好
401（認證失敗）	❌	是你的設定問題，修 token 而不是等
400（請求錯誤）	❌	是你的 bug，重試沒用

實際踩過的坑

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

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

---

Pattern 4：人機升級（HITL Escalation）

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

三層升級制度

graph TD
    T["新任務進來"] --> R{"風險評估"}
    R -->|低風險、可逆| AUTO["🟢 自主執行"]
    R -->|中風險、重要節點| NOTIFY["🟡 執行後通知"]
    R -->|高風險、不可逆| GATE["🔴 停下等人批准"]

    AUTO --> D["直接執行"]
    NOTIFY --> E["執行 → 通知人類"]
    GATE --> W["等待批准 → 才執行"]

    style AUTO fill:#4CAF50,stroke:#2A2118,color:white
    style NOTIFY fill:#FFC107,stroke:#2A2118,color:#2A2118
    style GATE fill:#F44336,stroke:#2A2118,color:white

層級	風險	Agent 行為	範例
🟢 自主	低，可回復	直接做	讀檔、寫草稿、跑測試
🟡 通知	中，重要節點	做完再通知人	commit 程式碼、更新狀態
🔴 閘門	高，不可逆	停下來等人說好	push 到 production、發送訊息、刪除資料

關鍵指標：升級率

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

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

升級時的資訊格式

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

## 需要決策

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

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

---

Pattern 5：模型選擇（Model Selection）

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

二分法則

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

graph LR
    T["任務"] --> Q{"需要判斷力？"}
    Q -->|是：策略/分析/審查| EXP["💰 貴的模型<br/>Opus / GPT-4+"]
    Q -->|否：寫 code/格式化/抓資料| CHEAP["🪙 便宜的模型<br/>Sonnet / Haiku / Flash"]

    style EXP fill:#CBA000,stroke:#2A2118,color:#2A2118
    style CHEAP fill:#E8ECF1,stroke:#2A2118,color:#2A2118

常見配置

角色	模型等級	理由
指揮者	貴	它做所有重要決策——省這裡虧全局
寫 code	便宜	產出可以跑測試驗證
審 code	貴	需要抓到別人漏掉的問題
收集資料	便宜	機械式抓取 + 格式化
分析資料	貴	解讀、找 pattern、下判斷
跑測試	便宜	結果是 pass/fail，不需要創意
格式轉換	最便宜	純粹的資料轉換

省錢的 80/20 法則

四個改動就能省下 ~80% 的多 Agent 成本：

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

---

總結：5 個 Pattern 的關係

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

graph TD
    FB["📁 檔案白板<br/>溝通基礎"] --> TE["📨 任務信封<br/>結構化派工"]
    TE --> CB["⚡ 熔斷機制<br/>故障防護"]
    CB --> HITL["🙋 人機升級<br/>風險管控"]
    HITL --> MS["💰 模型選擇<br/>成本控制"]

    FB -.->|所有通訊都經過檔案| CB
    TE -.->|信封裡設預算| MS
    CB -.->|熔斷後升級給人| HITL

    style FB fill:#CBA000,stroke:#2A2118,color:#2A2118
    style TE fill:#CBA000,stroke:#2A2118,color:#2A2118
    style CB fill:#CBA000,stroke:#2A2118,color:#2A2118
    style HITL fill:#CBA000,stroke:#2A2118,color:#2A2118
    style MS fill:#CBA000,stroke:#2A2118,color:#2A2118

Pattern	解決的問題	沒有它會怎樣
檔案白板	Agent 之間怎麼溝通	狀態衝突、資料遺失
任務信封	怎麼清楚交代任務	產出品質不可控、預算爆炸
熔斷機制	API 故障怎麼辦	重試風暴、帳單炸裂
人機升級	什麼時候該問人	高風險操作沒人把關
模型選擇	用哪個模型	全用貴的白花錢，全用便宜的品質崩

---

開始動手

如果你現在就想開始，這是最小可行的順序：

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

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

想要完整的 pattern 文件、程式碼模板和更多實戰案例，我們把所有內容整理成了開源 repo：

👉 Orchestration Playbook on GitHub

MIT 授權，歡迎取用。