多代理協作（Multi-Agent Collaboration）— 從單打獨鬥的 AI 到各司其職的 AI 專家團隊

有沒有遇過這種情況——把一個超級複雜的工作丟給單一 AI，結果它給出來的答案漏洞百出，要嘛忽略細節、要嘛方向根本不對。比如說一份需要同時分析市場趨勢、財務數據、競爭對手的商業企劃書，單一 LLM 往往無法兼顧所有面向。

這不是運算力不夠的問題。主要問題在於單一模型缺乏多樣化的專業技能，也很難同時有效率地操作所有領域的工具——它沒辦法同時拿著鎚子、扳手又拿著電鑽。

目前業界對此的解法已經不再是追求更龐大的單一模型，而是轉向組建一支由專門 AI 代理組成的虛擬團隊。這就是多代理協作（Multi-Agent Collaboration）要處理的問題。

為什麼單一 AI 會遇到天花板

當任務的複雜度超過某個臨界點時，單一 LLM 的處理能力會遇到嚴重的瓶頸。這個瓶頸不是模型不夠聰明，而是結構性的：

• 缺乏多樣化專業：同一個模型很難同時是市場分析專家、財務顧問和文案寫手
• 工具切換成本高：單一模型在切換不同領域工具時，效能會顯著下降
• 上下文窗口限制：所有資訊都得塞進同一個 context，資訊過多時模型開始迷失

就像我們不可能讓一個工頭同時包辦水電、木工和泥作——他一個人做一定會顧此失彼，最後水管漏水。正常做法是拆解目標，把水電交給有水電工具的師傅，木工交給木工師傅。AI 的世界裡完全是一樣的邏輯。

讓 AI 團隊說同一種語言：共享本體

在讓多個 AI 協作之前，先要解決一個根本問題：不同的 AI 代理之間如何確保對資料的理解是一致的？

這就需要共享本體（Shared Ontology）。我們可以把它理解為一本共同的字典或藍圖——負責找客戶資料的 AI 和負責寫推銷信的 AI 必須對「客戶姓名」「痛點」「聯絡方式」這些欄位有完全相同的定義。

在程式碼層面上，這通常意味著使用標準化的資料格式（如 JSON），並預先定義好每個欄位的意義。如果沒有共享本體，第一個 AI 可能丟過去一段亂七八糟的非結構化文字，第二個 AI 根本不知道客戶名字在哪裡、痛點是什麼——雞同鴨講。有了共享本體，它們就有一套共同的通訊協定，確保資料在傳遞過程中不會產生歧義。

六種協作模式

市面上對多代理協作有幾種具體的模式，從簡單到複雜：

1. 順序切換（Sequential Handoff）

最直觀的模式，就像工廠裡的輸送帶。一個代理完成任務後，把結果直接丟給下一個代理當作輸入。

            Step 1               Step 2               Step 3
  [研究員 AI] ───→ [分析師 AI] ───→ [報告撰寫 AI]
        │                  │                  │
        │ 搜尋市場資料      │ 分析數據          │ 產出報告
        ↓                  ↓                  ↓
      JSON ───────→ JSON ───────→ 自然語言

適合有嚴格先後順序、不能跳過步驟的流程。缺點是慢——如果我們有十個章節要寫，得等第一章寫完才能開始第二章。

2. 並行處理（Parallel Processing）

當任務可以被獨立拆解時，並行處理能大幅壓縮時間。系統同時把多個子任務派發給不同代理：

                     ┌─ Agent A：爬財務報表
                     ├─ Agent B：分析競爭對手動態
  [分析上市公司] ──────┼─ Agent C：社群媒體情緒分析
                     ├─ Agent D：法規檢查
                     └─ Agent E：專利查詢
                        │
                        │ 五條路同時跑
                        ↓
                     [合併報告]

五個代理同步工作，效率驚人，但有一個問題：如果結果互相衝突怎麼辦？比如社群情緒說「這家公司形象超好」，財務報表卻顯示「下個月就要破產了」。

3. 辯論與共識（Debate & Consensus）

為了解決衝突，系統引入具有不同觀點的代理互相辯論：

  ┌─ 樂觀投資者 ─┐
  │ system prompt │ ← 正面看待所有數據
  └──────┬───────┘
         │ 互相檢視
         │ 反覆辯論
  ┌──────▼───────┐
  │ 紅隊駭客     │ ← 專門找問題
  │ system prompt │
  └──────┬───────┘
         │
         ↓
    [共識結論]

透過設定不同的 system prompt——一個設定為極度樂觀的投資者，另一個設定為非常挑剔的紅隊駭客——讓他們互相檢視對方的論點，透過反覆對話逼近最客觀的結論。

代價是通訊開銷與運算成本很高。所以辯論模式不會用在「今天天氣怎麼樣」這種日常查詢上，而是保留給高風險決策，如醫療診斷、法律合規審查、大型併購風險評估。

4. 分層結構（Hierarchical Structure）

當參與的代理越來越多（例如 50 個代理處理跨國專案），就需要管理機制。分層結構引入管理代理（Supervisor）和工作代理：

Supervisor（規劃與分配）
  ├─ Agent A：市場研究
  ├─ Agent B：財務分析
  ├─ Agent C：風險評估
  └─ Agent D：法規遵循

管理代理不負責具體執行，而是分析高階指令、動態分配任務、綜合回報結果。基層代理不需要理解整個巨型專案的複雜度，只需專注在自己擅長的工作上。

5. 專家團隊（Expert Team）

多個專家代理平行分析同一個問題，各自從不同專業角度提出觀點，最後由合併代理統整。這在 CareerWise 的平行化架構中已經實作過——三個代理同步分析薪資市場、技能成長與求職準備。

6. 評論家與審查者（Critic & Reviewer）

這個模式專門解決 AI 幻覺問題。核心是把「生成」和「驗證」兩個功能拆開：

   [生成代理] ──→ 產出草稿 ──→ [審查代理]
        ↑                          │
        │                   帶著檢查清單：
        │                   • 事實正確性
        │                   • 資料來源
        │                   • 語氣一致性
        │                   • 安全性
        │                          │
        └──── 打回票 + 修改建議 ←──┘

生成代理負責大膽創作，審查代理帶著嚴格的評分標準進行無情審查。如果發現問題，審查代理不會幫忙改，而是附上具體建議打回重做。透過這種來回迭代，確保最終輸出的品質。

通訊架構的演進

有了協作模式，還需要決定代理之間怎麼溝通。通訊架構從簡單到複雜可以分為六個階段：

  單一代理             網路模式              主管模式

  [Agent]           A ── B           [Supervisor]
                    │ ╱ ╲ │             │   │
                    C ── D              A   B
                                         / \ / \
  不與其他代理       點對點全互連         C  D E F
  互動              容錯高              中心樞紐
  能力受限          通訊爆炸            單點故障


  主管作為工具          層次結構             客製化

  [Supervisor]←┐  [Supervisor A]        ┌──┐
   ↑   ↑   ↑   │       │       │        │自│
   A   B   C   │       │       │        │訂│
   │   │   │   │  [Sup B]  [Sup C]      │架│
   把主管當資源    │  │     │  │        │構│
   主動呼叫       E  F     G  H         └──┘
                多層管理              混合搭配
                分散決策              量身打造

單一代理（Single Agent）：最基本的層級，一個代理自主運作，不與其他代理互動。系統單純但能力受限，只適用於可獨立解決的子問題。

網路模式（Network）：去中心化的點對點互動，所有代理互相連線。優點是容錯率高，問題在於通訊開銷會變成災難——一個代理發現錯誤發訊息給所有人，另一個根據舊資料又發出修改指令，最後陷入無限糾正迴圈。

主管模式（Supervisor）：引入一個中心樞紐，由專門的代理負責收集資訊、分配任務、解決衝突。但當底下有幾十個代理時，主管會被海量資訊淹沒，變成單點故障。

主管作為工具（Supervisor as Tool）：主管轉變成資源與服務的提供者，不再死盯著每一個流程。下屬代理在需要額外運算能力或跨部門資料時，主動去呼叫主管，把它當作一個工具來使用。

層次結構（Hierarchical）：建立多層次的監督者——高階主管管理中階主管、中階主管管理基層代理。超級複雜的問題可以一層一層向下分解，系統在定義好的邊界內進行分散式決策。

客製化（Custom）：混合前面多種模型的元素，針對特定問題量身打造通訊結構。適用於標準模型無法滿足的特殊需求。

框架實作：CrewAI 與 Google ADK

這些架構不是停留在白紙上的理論。工程師現在正用具體的框架實踐這些模式。

CrewAI：順序切換的簡潔實作

CrewAI 完美展示了如何用幾行程式碼協調出一個編輯室：

import { Agent, Task, Crew, Process } from 'crewai-ts'

const researcher = new Agent({
  role: 'Senior Research Analyst',
  goal: 'Find and summarize the latest trends in AI.',
  backstory: '一位熟悉辨識關鍵趨勢的資深分析師',
  tools: [searchTool],
  llm: 'gemini-2.0-flash',
  allowDelegation: false,
  verbose: true,
})

const writer = new Agent({
  role: 'Technical Content Writer',
  goal: 'Write a clear and engaging blog post based on research findings.',
  backstory: '一位能將複雜技術主題轉譯為易懂內容的作家',
  llm: 'gemini-2.0-flash',
  allowDelegation: false,
  verbose: true,
})

const researchTask = new Task({
  description: 'Research the top 3 emerging trends in AI.',
  expectedOutput: '一份涵蓋 3 個 AI 趨勢的詳細摘要',
  agent: researcher,
})

const writingTask = new Task({
  description: '根據研究結果寫一篇 500 字的部落格文章',
  expectedOutput: '一篇 500 字的部落格文章',
  agent: writer,
})

const crew = new Crew({
  agents: [researcher, writer],
  tasks: [researchTask, writingTask],
  process: Process.sequential,
})

研究員先搜尋趨勢，把結果傳給作家，作家再根據研究結果寫文章。清楚明瞭。

Google ADK：分層與迴圈機制

Google ADK 提供了更細緻的狀態控制。實作分層結構時，定義一個 Root Agent 作為父代理，它本身不執行具體動作，而是透過路由邏輯把任務交給子代理：

const root = {
  name: 'root',
  instruction: '分析使用者需求並分配給對應的專業代理',
  children: [researchAgent, writingAgent, reviewAgent],
}

其中最精彩的是迴圈機制（LoopAgent）。很多工作不可能一次就做對——比如更新某個狀態直到完成為止。LoopAgent 內部包含一組子代理，依序反覆執行，並透過一個專門的條件檢查代理來決定何時停止：

import { LoopAgent, LlmAgent, BaseAgent } from '@google/adk'
import { Event, EventActions } from '@google/adk/events'

// 條件檢查代理：檢查 session 狀態是否為 completed
class ConditionChecker extends BaseAgent {
  async runAsyncImpl(context: InvocationContext) {
    const status = context.session.state.get('status', 'pending')
    if (status === 'completed') {
      yield new Event({
        author: this.name,
        actions: new EventActions({ escalate: true }),  // 終止迴圈
      })
    } else {
      yield new Event({
        author: this.name,
        content: '條件未滿足，繼續迴圈',
      })
    }
  }
}

// 處理步驟：執行任務，完成時將狀態設為 completed
const processStep = new LlmAgent({
  name: 'ProcessingStep',
  model: 'gemini-2.0-flash-exp',
  instruction: '執行你的任務。如果你是最後一步，將 session state 中的 status 設為 completed。',
})

// LoopAgent：反覆執行子代理，最多 10 次
const poller = new LoopAgent({
  name: 'StatusPoller',
  maxIterations: 10,
  subAgents: [processStep, new ConditionChecker()],
})

LoopAgent 依序執行 processStep 和 ConditionChecker。如果 ConditionChecker 發現 status 為 "completed"，就透過 escalate: true 終止迴圈；否則繼續下一次迭代，直到達到 maxIterations 上限。

ADK 的並行處理

ADK 的並行處理實作也很有意思。ParallelAgent 可以同時啟動多個子代理：

import { Agent, ParallelAgent } from '@google/adk'

const weatherFetcher = new Agent({
  name: 'weather_fetcher',
  model: 'gemini-2.0-flash-exp',
  instruction: '取得指定位置的天氣資料，只回傳天氣報告。',
  outputKey: 'weather_data',  // 結果存入 session.state.weather_data
})

const newsFetcher = new Agent({
  name: 'news_fetcher',
  model: 'gemini-2.0-flash-exp',
  instruction: '取得指定主題的最新新聞，只回傳該則新聞。',
  outputKey: 'news_data',     // 結果存入 session.state.news_data
})

const dataGatherer = new ParallelAgent({
  name: 'data_gatherer',
  subAgents: [weatherFetcher, newsFetcher],
})

每個子代理的結果透過 outputKey 存入 session state，ParallelAgent 在底層以平行執行緒同步啟動所有子代理，互不干擾，極大節省等待時間。

代理作為工具：終極靈活性

ADK 中還有一個更前衛的概念——代理作為工具（Agent as Tool）。在傳統觀念中，AI 的工具不外乎計算機、搜尋引擎或網頁瀏覽器。但這個模式下，代理本身變成了另一個代理的工具，中間透過 AgentTool 包裝層銜接：

import { LlmAgent } from '@google/adk'
import { AgentTool } from '@google/adk/tools'

// 1. 定義一個工具函式（核心能力）
function generateImage(prompt: string): { status: string; imageBytes: Buffer; mimeType: string } {
  console.log(`Generating image for: ${prompt}`)
  return {
    status: 'success',
    imageBytes: Buffer.from('mock_image_data'),
    mimeType: 'image/png',
  }
}

// 2. 定義影像生成代理，掛載工具
const imageGeneratorAgent = new LlmAgent({
  name: 'ImageGen',
  model: 'gemini-2.0-flash',
  instruction: '根據使用者的 prompt，使用 generate_image 工具產生圖片。',
  tools: [generateImage],
})

// 3. 用 AgentTool 包裝，讓其他代理可以呼叫它
const imageTool = new AgentTool({
  agent: imageGeneratorAgent,
  description: '用一段描述性文字產生圖片。',
})

// 4. 藝術家代理把 imageTool 當作一般工具來使用
const artistAgent = new LlmAgent({
  name: 'Artist',
  model: 'gemini-2.0-flash',
  instruction: '先發想一個有創意的圖片 prompt，然後用 ImageGen 工具產生圖片。',
  tools: [imageTool],
})

運作流程：

  [Artist Agent]             [ImageGen Agent]         [generate_image]
  大腦 A                     大腦 B                  工具函式
       │                          │                      │
       │ 發想 prompt               │                      │
       │ ── AgentTool.call ───→   │                      │
       │                          │ ── tool call ───→   │
       │                          │                      │ 生圖
       │                          │ ←── 圖片 bytes ──   │
       │ ←────── 結果 ────────── │                      │

藝術家代理負責發想 prompt，但它本身沒有生成圖片的能力。它把 ImageGen 代理當作一個工具來呼叫——就像一個大腦操控另一個大腦來完成創作。AgentTool 是中間的橋樑，讓代理可以被包裝成標準的工具介面。

這種架構徹底打破了傳統模組的死板邊界。當 AI 可以互相把對方當作動態工具來呼叫時，我們面對的就不再只是自動化腳本，而是一個可以無限擴展、甚至自我組織的智慧網路。

CareerWise 對照

CareerWise 是一個以 LLM 為核心的職涯諮詢網站，提供履歷健檢、職涯建議與預約諮詢，也是這個系列文章的主要實作專案。

多代理協作中的角色

Summer（開發者）
  設計了 CareerWise 的架構、寫了 system prompt
  定義了 Summer 的人設與知識庫內容
   │
   ▼
Summer 代理                   審查代理
（LLM 扮演職涯顧問）           （LLM 扮演品質審查員）
  角色：產出回答                 角色：挑錯、打回票
  人格：Summer                  人格：客觀審查者
  職責：根據使用者問題回答         職責：拿著檢查清單審查

  Summer 代理產出回答
       │
       ▼
  審查代理檢查（事實、來源、語氣）
       │
  ├─ OK → 輸出給使用者
  │
  └─ 不合格 → 附上具體建議 → 打回 Summer 代理重寫

兩個代理都是 LLM 扮演的 AI，都不是真人。Summer是開發者，不參與每次回答的產出流程，而是設計了這套協作機制讓兩個 AI 角色 (Summer 代理、審查代理) 互相合作，產出更高品質的回應。

回頭看 CareerWise 目前的架構，已經實作的有：

順序切換對應的是 career chain 的三步驟提示鏈。使用者的問題先經過背景分析（輸出結構化 JSON）、再送知識庫比對（輸出比對結果 JSON）、最後產出個人化建議報告。每一步的輸出都是下一個步驟的輸入，像輸送帶一樣依序傳遞。

平行多代理對應的是 complex tier 的平行化架構。當使用者問「該不該離職」這類跨領域問題時，系統同時啟動三個 Agent——分別分析市場薪資、技能成長與面試準備——三個 Agent 各自獨立搜尋知識庫、產出 JSON 結果，最後由 merge.ts 合併成一份綜合報告。其中 merge.ts 的角色就是這個團隊的總編輯：它不產生新觀點，只把三個分析師的觀點組織成結構化報告——對應文章中提到的「合併代理」角色。

三個代理平行分析（各自產出 JSON）：
  Agent A: 市場分析師 → { findings, insights, risk_level }
  Agent B: 成長顧問   → { findings, insights, risk_level }
  Agent C: 實戰教練   → { findings, insights, risk_level }

merge.ts 收到三個 JSON → 一次 LLM 呼叫 → 產出結構化報告：
  ## 市場分析
  ## 成長建議
  ## 實戰準備
  ## 行動建議

分層結構對應的是路由系統的 tier 分流。CareerWise 收到問題後，先由路由層判斷難度，再分流到對應的處理路徑——簡單問題走 SSE streaming 秒回（simple），中等問題走提示鏈逐步分析（medium），需要計劃審查的走審查流程（planned），跨領域複雜問題才動用平行代理（complex）。每層有自己的處理邏輯，上層不需要理解下層的實作細節。

另外還有一個品質審查機制——reflect.ts，每次 Summer 代理回答完後用第二次 LLM 呼叫來檢查回答品質：

Summer 代理產出回答
  │
  ▼
reflect.ts 檢查 4 項：
  ① 是否有事實錯誤或幻覺
  ② 建議是否具體可行，還是空泛鼓勵
  ③ 語氣是否恰當
  ④ 是否根據使用者具體情況回答
  │
  ├─ OK → 保留原回答
  │
  └─ 有問題 → 輸出修正版，取代原回答

但它目前是單次 LLM 呼叫，不是完整的審查代理。對照前面提到的「評論家與審查者」模式：

如果要升級成審查模式，可以讓 reflect.ts 不直接改答案，而是打回給原 LLM 重寫，並設定最多迭代 3 次。

另外，還沒做但可以改善的方向：

其中最直接可做的是前面提到的審查代理升級——把 reflect.ts 從一個簡單 LLM 呼叫升級成一個真正的審查代理，自帶檢查清單（事實正確性、資料來源、語氣一致性），發現問題時打回重寫，最多迭代 3 次。改動範圍小但效果明顯。

總結

多代理協作的核心思路很簡單：當一個問題太複雜，不要讓一個 AI 硬扛，而是組一支專家團隊。

從順序切換到並行處理，從辯論共識到分層管理，再到代理互為工具的終極型態——每一種模式都在解決特定的問題：速度不夠就並行，品質不夠就審查，規模太大就分層。

未來真正的競爭力不在於誰能訓練出最大的模型，而在於誰能建立一個具有專門角色分工、分散式執行、嚴謹溝通機制的多代理協作網路。我們不需要親自下去寫每一行程式碼或畫每一張圖——我們的工作是當那個懂得如何指揮 AI 團隊的專案經理。

參考資料

• 第 7 章：多智能體協作