--- title: "Multi-Agent 架構實戰：為什麼我選 Supervisor 模式來協調 AI Agent" description: "深入比較 Multi-Agent 的兩種主流架構（Network vs Supervisor），並以 LangGraph 實作 Podcast 自動生成管線為例，分享 Supervisor 模式的設計思維、回饋迴路與容錯策略。" canonical_url: "https://blog.markkulab.net/post/multi-agent-supervisor-architecture" author: "Mark Ku" author_url: "https://blog.markkulab.net/author/mark-ku" site: "Mark Ku's Blog" date_published: "2026-03-23 10:00:00 +0800" category: "AI" tags: ["Multi-Agent", "LangGraph", "Supervisor", "AI Agent", "LangChain"] language: "zh-TW" license: "CC BY 4.0" license_url: "https://creativecommons.org/licenses/by/4.0/" attribution: "轉載或引用請註明作者並附上原文連結" --- # Multi-Agent 架構實戰：為什麼我選 Supervisor 模式來協調 AI Agent > **TL;DR** — 歡迎收聽 Mark 的 Tech Insights，我是主持人璦廷。當單一的人工智慧無法滿足複雜任務時，多個人工智慧代理協作的 Multi-Agent 架構就成了關鍵。 今天讓我們來看看，為什麼在眾多架構中，我們特別推薦 Supervisor 主管模式。相較於讓代理自由對話、容易失控的點對點網路，Supervisor 模式由中央主管負責流程編排，各個 Worker 代理只需專注於專業執行。 這個重點值得注意，在實作 Podcast 自動生成管線時，代理間不直接溝通，而是透過共享的 State 物件傳遞資訊。搭配 LangGraph 的 Reducer 機制，能確保代理平行運作時的錯誤紀錄不被覆蓋。這不僅讓系統完全解耦，更能輕鬆建立品質把關的回饋迴路與容錯策略。 總結來說，Supervisor 模式讓複雜的人工智慧工作流變得清晰可控。思考一下，您手邊有哪些任務，也適合拆解並交給專屬的數位員工來代勞呢？ ## 前言 2025 年 AI Agent 已經不稀奇了，真正開始捲的是 **Multi-Agent** — 讓多個 Agent 自己協調工作、分工合作。 單一 Agent 能力再強，碰到複雜任務還是會遇到瓶頸：context window 塞不下、一個 prompt 要兼顧搜尋 + 撰寫 + 校稿 + 生圖 + 語音合成，品質很難穩定。把任務拆給多個專精的 Agent，每個只做一件事，反而更可控。 但問題來了：**多個 Agent 之間怎麼協調？** 這篇整理兩種主流架構模式的差異，並用我實際做的 Podcast 自動生成管線當例子，分享為什麼我最後選了 Supervisor 模式。 ## 兩種主流架構模式 在規劃 Multi-Agent 系統時，通常會碰到兩種設計模式： ### 1\. Network / Peer-to-Peer（點對點協作） Agent 之間直接互相溝通，沒有中心控制者。每個 Agent 可以自行決定要找誰對話、傳遞什麼資訊。 ``` ┌─────────┐ ┌─────────┐ │ Agent A │◄───►│ Agent B │ └────┬────┘ └────┬────┘ │ │ ▼ ▼ ┌─────────┐ ┌─────────┐ │ Agent C │◄───►│ Agent D │ └─────────┘ └─────────┘ （每個 Agent 都可以跟任意 Agent 溝通） ``` **適合場景**：開放性討論、腦力激盪、多觀點辯論 **風險**：流程難預測、容易陷入無限迴圈、Debug 困難 ### 2\. Supervisor（主管模式） 有一個中央 Supervisor Agent 負責評估目前狀態，決定下一步要派誰上場。Worker Agent 執行完後回報結果，由 Supervisor 決定後續動作。 ``` ┌────────────┐ │ Supervisor │ │ (協調者) │ └─────┬──────┘ ┌──────────┼──────────┐ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │Worker A │ │Worker B │ │Worker C │ │(搜尋) │ │(撰寫) │ │(校稿) │ └─────────┘ └─────────┘ └─────────┘ （Worker 只跟 Supervisor 溝通，彼此不直接對話） ``` **適合場景**：有明確流程的任務管線、需要品質把關、要可追蹤進度 **優勢**：流程可控、分工明確、容錯好設計 ### 比較表

面向

Network (P2P)

Supervisor

控制方式

去中心化，Agent 自行協商

中央控制，Supervisor 分派

流程可預測性

❌ 低，路徑不固定

✅ 高，有明確的狀態機

Debug 難度

😰 高，訊息流向複雜

😌 低，每步都有 log

適合任務

開放性討論、創意發想

流程明確的生產管線

擴展性

新增 Agent 需考慮通訊拓撲

新增 Worker 只需註冊到 Supervisor

容錯設計

各 Agent 自行處理

Supervisor 統一管理降級策略

## 為什麼我選 Supervisor 模式 核心原因：**Supervisor 只需要知道「誰能做什麼」，而 Worker 只需要知道「怎麼把這件事做好」。** 這個分工非常乾淨： - **Supervisor** 負責「流程編排」— 誰先做、誰後做、失敗了怎麼辦 - **Worker** 負責「專業執行」— 搜新聞就搜新聞、寫稿就寫稿、校稿就校稿 這跟軟體工程的 **單一職責原則（SRP）** 一樣 — 每個 Agent 只做一件事，做好就回報。 而且在實務上，大多數 AI 自動化任務都有明確的前後依賴關係（搜尋完才能寫、寫完才能校），Supervisor 模式天然適合這種管線型工作流。 ## 跨 Agent 怎麼協調？共享狀態是唯一溝通管道 在 Supervisor 模式裡，**Agent 之間不直接通訊**。所有協調都透過一個共享的 State 物件： ``` ┌─────────────────────────────────────────────┐ │ 共享狀態（Shared State） │ │ │ │ rawSources ← Research 寫入 │ │ podcastMarkdown ← Writer 寫入 │ │ editorFeedback ← Editor 寫入 │ │ coverImagePath ← CoverArt 寫入 │ │ audioPath ← TTS 寫入 │ │ errors ← 所有 Agent 可寫入（append 模式） │ │ │ │ Supervisor 讀取 State → 決定下一步 │ └─────────────────────────────────────────────┘ ``` 每個 Agent 的溝通方式： - **讀**：從 State 拿到自己需要的輸入（例如 Writer 讀 `rawSources`） - **寫**：把自己的產出寫回 State（例如 Writer 寫 `podcastMarkdown`） - **不需要知道**：前一步是誰做的、下一步是誰接手 這樣的好處是 **Agent 完全解耦** — 你可以隨時替換任何一個 Agent 的實作（例如把 Gemini Writer 換成 Claude Writer），只要輸入輸出的 State 欄位不變，其他 Agent 完全不受影響。 ## LangGraph State 管理機制：Annotation 與 Reducer LangGraph 用 `Annotation` 來定義共享狀態，這是整個 Multi-Agent 協調的基礎。 ### 核心概念：每個欄位可以有自己的 reducer 一般的 State 管理是「後寫覆蓋前寫」，但在 Multi-Agent 場景下這樣會出問題。例如 Agent A 記了一個 error，Agent B 又記了一個 error，如果沒有 reducer，B 的 error 會把 A 的覆蓋掉。 LangGraph 的解法是讓每個欄位定義自己的 **reducer（合併策略）**： ```typescript export const PodcastAnnotation = Annotation.Root({ // 普通欄位：後寫覆蓋（預設行為） date: Annotation, podcastMarkdown: Annotation, // append reducer：新值追加到陣列，不覆蓋舊值 errors: Annotation({ reducer: (existing, update) => [...existing, ...update], default: () => [], }), // merge reducer：合併物件的 key-value retryCount: Annotation>({ reducer: (existing, update) => ({ ...existing, ...update }), default: () => ({}), }), }) ``` ### Reducer 運作方式

Reducer 類型

行為

適用場景

無（預設）

後寫覆蓋前寫

單一 Agent 產出的欄位（podcastMarkdown）

append

新值追加到陣列

多個 Agent 都可能寫入的欄位（errors）

merge

合併物件 key

計數器、狀態追蹤（retryCount）

custom

自訂邏輯

任何特殊需求

### 為什麼這很重要？ 沒有 reducer 的 Multi-Agent 系統，最常見的 bug 就是**狀態被意外覆蓋**。想像這個場景： 1. CoverArt Agent 和 TTS Agent **平行執行** 2. CoverArt 遇到錯誤，寫入 `errors: [{ agent: 'coverArt', message: '...' }]` 3. TTS 也遇到錯誤，寫入 `errors: [{ agent: 'tts', message: '...' }]` 4. 沒有 append reducer → TTS 的 error 覆蓋 CoverArt 的 error → **你永遠不知道封面生成失敗了** 有了 append reducer，兩個 error 都會被保留。這是 Multi-Agent 系統 State 管理的基本功。 ## 設計概念：用 LangGraph StateGraph 實作 Supervisor 我用 [LangGraph](https://langchain-ai.github.io/langgraphjs/) 的 `StateGraph` 來實作 Supervisor。核心思路是： 1. **共享狀態（State）**：所有 Agent 讀寫同一個 State 物件（上面講的 Annotation） 2. **節點（Node）**：每個 Agent 是一個節點 3. **邊（Edge）**：定義節點之間的執行順序 4. **條件路由（Conditional Edge）**：Supervisor 根據 State 決定下一步走哪條路 ``` START → Research → Writer → Editor ─┬─→ Publisher → [CoverArt + TTS] → END ▲ │ │ (score < 60, retry ≤ 2) └───────────────┘ 回饋迴路：帶著問題清單重寫 ``` ## 實作案例：Podcast 自動生成管線 我用這個架構做了一個「科技新聞 Podcast 自動生成器」，6 個 Agent 各司其職：

Agent

職責

使用技術

🔍 ResearchAgent

搜尋最新 AI 新聞（8-12 則）

Claude CLI + web_search

✍️ WriterAgent

將新聞素材寫成 Podcast 文章

Gemini 3.1 Pro

📝 EditorAgent

品質評分 + 清理 AI 痕跡

Gemini 3.1 Pro + regex

📦 PublisherAgent

組裝 frontmatter、寫入 MDX

Filesystem

🎨 CoverArtAgent

生成封面圖

Gemini Image + sharp

🎙️ TTSAgent

生成多角色對話語音

Gemini + VoAI TTS

### 完整架構圖 ``` ┌─────────────────────────────────────────────────────────────────────┐ │ LangGraph StateGraph │ │ (Supervisor 協調者) │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ Research │───▶│ Writer │───▶│ Editor │───▶│ Publisher │ │ │ │ Agent │ │ Agent │◀───│ Agent │ │ Agent │ │ │ │ │ │ │回饋 │ │ │ │ │ │ │ Claude │ │ Gemini │迴路 │ Gemini │ │ Filesystem │ │ │ │ CLI + │ │ 3.1 Pro │(≤2) │ 3.1 Pro │ │ MDX 寫入 │ │ │ │web_search│ │ │ │ │ │ │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────┬───────┘ │ │ │ │ │ ┌──────────┴────┐ │ │ │ 平行執行 │ │ │ ┌────▼────┐ ┌──────▼──┐ │ │ │CoverArt │ │ TTS │ │ │ │ Agent │ │ Agent │ │ │ │ Gemini │ │ Gemini │ │ │ │ Image + │ │ + VoAI │ │ │ │ sharp │ │ │ │ │ └────┬────┘ └────┬────┘ │ │ ▼ ▼ │ │ END END │ └─────────────────────────────────────────────────────────────────────┘ ``` ## 程式碼重點解析 ### 1\. 共享狀態定義（LangGraph Annotation） 所有 Agent 讀寫同一個 State，用 `Annotation` 定義資料結構與 reducer： ```typescript import { Annotation } from '@langchain/langgraph' export const PodcastAnnotation = Annotation.Root({ // ─── 輸入 ─── date: Annotation, config: Annotation, // ─── 各階段產出 ─── rawSources: Annotation, // Research 寫入 podcastMarkdown: Annotation, // Writer 寫入 editorFeedback: Annotation, // Editor 寫入 cleanedContent: Annotation, // Editor 寫入 coverImagePath: Annotation, // CoverArt 寫入 audioPath: Annotation, // TTS 寫入 // ─── 控制欄位 ─── errors: Annotation({ reducer: (existing, update) => [...existing, ...update], default: () => [], }), retryCount: Annotation>({ reducer: (existing, update) => ({ ...existing, ...update }), default: () => ({}), }), }) ``` 💡 **重點**：`errors` 用 append reducer，不會被後面的 Agent 覆蓋掉前面的錯誤紀錄。 ### 2\. StateGraph 組裝：節點 + 邊 + 條件路由 ```typescript import { StateGraph, END } from '@langchain/langgraph' export function buildGraph() { const graph = new StateGraph(PodcastAnnotation) // 註冊節點（每個 Agent 都是一個 function） .addNode('research', researchAgent) .addNode('writer', writerAgent) .addNode('editor', editorAgent) .addNode('publisher', publisherAgent) .addNode('coverArt', coverArtAgent) .addNode('tts', ttsAgent) // 順序執行 .addEdge('__start__', 'research') .addEdge('research', 'writer') .addEdge('writer', 'editor') // 條件路由：Editor 決定要重寫還是放行 .addConditionalEdges('editor', routeAfterEditor, { publisher: 'publisher', writerRetry: 'writerRetry', }) // Publisher 後：平行執行 CoverArt + TTS .addConditionalEdges('publisher', routeAfterPublisher, { coverArt: 'coverArt', tts: 'tts', end: 'end', }) .addEdge('coverArt', END) .addEdge('tts', END) return graph.compile() } ``` 💡 **重點**：`addConditionalEdges` 就是 Supervisor 的核心 — 根據目前 State 決定下一步走哪條路。 ### 3\. Worker Agent 的實作（以 WriterAgent 為例） 每個 Worker 只做一件事：接收 State → 執行任務 → 回寫結果： ```typescript export async function writerAgent( state: PodcastState ): Promise> { const model = await createVertexModel({ model: state.config.writerModel, temperature: 0.8, }) // 如果是 retry，帶入 Editor 的回饋 let feedbackContext = '' if (state.editorFeedback && !state.editorFeedback.passed) { feedbackContext = state.editorFeedback.issues .map(i => `- ${i}`) .join('\n') } const prompt = buildWriterPrompt(state.date, newsContext) + feedbackContext const response = await model.invoke([{ role: 'user', content: prompt }]) return { podcastMarkdown: response.content.trim(), currentStep: 'writing_done', } } ``` Worker 不需要知道自己是第幾次被叫、前後是誰，它只管「把稿子寫好」。 ## 回饋迴路：品質守門員模式 這是 Supervisor 模式最強大的地方 — **可以設計回饋迴路（Feedback Loop）**。 ``` Writer ──寫稿──▶ Editor ──評分──┬──▶ ✅ 通過 → Publisher │ ❌ 不合格（score < 60） │ 帶回饋重寫（最多 2 次） │ └──▶ Writer ``` ```typescript function routeAfterEditor(state: PodcastState): string { // 通過 → 下一步 if (state.editorFeedback?.passed) return 'publisher' // 沒通過但還有重試次數 → 帶回饋重寫 const retries = state.retryCount?.['writer'] ?? 0 if (retries < MAX_WRITER_RETRIES) return 'writerRetry' // 超過重試次數 → 帶警告繼續 return 'publisher' } ``` ### 類比：Coding Agent 場景 同樣的模式可以套在程式碼審查上： ``` Coding Agent ──提交代碼──▶ Supervisor Agent ──檢查──┬──▶ ✅ 通過 → Merge │ ❌ 資安漏洞 / 不符規定 │ 帶回饋改程式碼（最多 N 次） │ └──▶ Coding Agent ``` Supervisor 只需要評估「這段 code 有沒有問題」，Coding Agent 只需要「根據回饋修正」。兩邊職責清楚，不會互相干擾。 ## 容錯與降級策略 在 Multi-Agent 系統裡，不是每個 Agent 都同樣重要。好的 Supervisor 要設計**分級容錯**：

失敗情境

處理方式

嚴重度

Research 搜尋失敗

Writer 用 LLM 自身知識生成

⚠️ 降級

Editor 多次不合格

帶警告繼續發布

⚠️ 降級

CoverArt 生成失敗

文章照常發布（無封面）

💡 可接受

TTS 合成失敗

文章照常發布（無音檔）

💡 可接受

Publisher 寫入失敗

中止管線

🔴 硬性失敗

💡 **設計原則**：核心流程（Research → Write → Edit → Publish）失敗要降級處理，附加功能（Cover、TTS）失敗不應影響主線。 ## 注意事項 / PS ### 實務踩坑 - **共享狀態要用 reducer**：如果多個 Agent 同時寫入 `errors`，不用 append reducer 會互相覆蓋。LangGraph 的 `Annotation` reducer 是救命的 - **平行執行要注意獨立性**：CoverArt 和 TTS 可以平行，是因為它們沒有資料依賴。如果有依賴就必須串行 - **回饋迴路要設上限**：沒有 `MAX_RETRIES` 的回饋迴路 = 無限迴圈。我設 2 次，超過就帶警告繼續 - **不同 Agent 可以用不同模型**：Research 用 Claude（搜尋能力強）、Writer/Editor 用 Gemini（便宜 + 長 context）、TTS 用專門的語音 API，混搭反而效果更好 ### 效能參考

模式

耗時

說明

純文字（skip-tts + skip-cover）

~2 分鐘

Research → Writer → Editor → Publisher

含封面

~3 分鐘

加上 CoverArt 生成

完整管線

~4 分鐘

CoverArt + TTS 平行執行

### 什麼時候不該用 Supervisor - 如果任務本身就是開放性的（例如多 Agent 辯論、創意發想），Supervisor 反而會限制 Agent 的自主性 - 如果只有 2 個 Agent 且流程是線性的，直接串接就好，不需要搬出 Supervisor 架構 ## 結論 Multi-Agent 的核心不是「Agent 越多越好」，而是**分工明確 + 流程可控**。 Supervisor 模式的三個設計原則： 1. **Supervisor 管流程，Worker 管執行** — 單一職責、各司其職 2. **回饋迴路保品質** — Editor/Reviewer 當守門員，不合格就打回去 3. **分級容錯** — 核心流程降級、附加功能 graceful fail 如果你也在規劃 Multi-Agent 系統，建議先想清楚「這個任務有沒有明確的前後順序」。有的話，Supervisor 模式是最穩的起點。 ![AI Agent 執行新聞搜尋、內容撰寫與品質審核流程](https://blog.markkulab.net/content/markku/posts/multi-agent-supervisor-architecture/images/2.jpg)![AI文章生成系統的Pipeline流程圖介面](https://blog.markkulab.net/content/markku/posts/multi-agent-supervisor-architecture/images/667429162_26583505644577677_1599853590001067562_n.jpg) --- ## 關於本文與作者 本文出自 [Mark Ku's Blog](https://blog.markkulab.net/post/multi-agent-supervisor-architecture) 授權條款： [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) — 轉載或引用請註明作者並附上原文連結 ### 關於作者 **[Mark Ku](https://blog.markkulab.net/author/mark-ku)** — Software Solution Provider - 10+ 年資深軟體工程師，現為 AI 應用 Builder - 專注大型平台架構設計，從北美電商到AI SaaS訂閱收費系統 - 結合 AI Agent 與自動化，打造高效可演進的產品技術基礎 ### 作者開發的免費工具 以下工具皆可免費使用： - [免費 PDF 簽名工具](https://blog.markkulab.net/tools/pdf-sign): 線上 PDF 簽名工具，瀏覽器內完成手繪、打字、上傳簽名，可拖曳放置、縮放、下載。所有處理都在你的裝置完成，檔案不會上傳。 - [VS Code Refactory](https://blog.markkulab.net/tools/refactory): Refactory 是一款 VS Code 重構擴充套件：34 個重構動作、37 條 code smell 檢查、Code Health 儀表板、18 種語言、534 支測試。懂你的專案慣例：介面放哪、DI 註冊寫在哪、'use client' 該不該加；還會用 git 修改頻率 × 複雜度排出「該先修哪個檔案」，並一鍵把壞味道交給你自己電腦上的 Claude Code 修。免費使用，原始碼不離開你的機器。 - [DB-Kit 資料庫管理工具](https://blog.markkulab.net/tools/db-kit): DB-Kit 是一個用 Tauri + Rust + React 打造的輕量跨平台資料庫管理工具，用單一一致的介面同時管理 MySQL、MariaDB、PostgreSQL、SQL Server、Oracle、SQLite、MongoDB、Redis、Kafka、Elasticsearch 與 RabbitMQ 十一種資料來源：連線密碼以 OS keychain 加密、SSH Tunnel、完整 CRUD、視覺化查詢建構器、多結果集同時顯示、跨連線資料傳輸與比對同步、Excel / CSV 匯入匯出、執行計畫視覺化、ER 圖、排程備份、SQL 壓力測試（p50～p99 延遲百分位）、15 條規則的 SQL 審查、Kafka 訊息瀏覽與監控告警；繁中 / 英文雙語介面，內建 AI 助手（自然語言生成 SQL、AI 審查與調校建議）與命令列工具 dbk。免費開源（MIT），提供 Windows / macOS / Linux 安裝檔。 - [VS Code Super Mermaid](https://blog.markkulab.net/tools/super-mermaid): Super Mermaid 是一款 VS Code 擴充套件：開箱即用的漂亮 Mermaid 圖表，自動上色、即時預覽、滑鼠平移縮放、PNG / SVG 高解析匯出，內建 21 種範本與多種主題。免費開源（MIT）。 - [React Super Mermaid](https://blog.markkulab.net/tools/react-super-mermaid): react-super-mermaid 是一個開源 React 元件庫：一行 即可渲染漂亮的 Mermaid 圖表，內建 colorful / sketch 主題、平移縮放、圖內搜尋、SVG / PNG 高解析匯出。輕量、SSR 安全、完整 TypeScript 型別。免費開源（MIT）。 - [Jira / Confluence Super Mermaid](https://blog.markkulab.net/tools/jira-super-mermaid): Atlassian Forge app：在 Jira issue 與 Confluence 內文直接寫 Mermaid 語法，畫流程圖、時序圖、狀態機與甘特圖。11 種圖表、SVG / PNG 匯出、明暗主題、完整中日韓文字支援。取得 Runs on Atlassian 資格：圖表存在你自己的站台，app 不呼叫任何第三方服務。免費，即將上架 Atlassian Marketplace。 - [Mermaid 線上預覽](https://blog.markkulab.net/tools/mermaid-preview): 在瀏覽器裡寫 Mermaid、即時看圖，整張圖表壓進網址就能分享。免註冊、不上傳伺服器，相容 mermaid.live 的分享連結。 - [React Intl Phone Number](https://blog.markkulab.net/tools/react-intl-phone-number): react-intl-phone-number 是一個開源 React 元件：framework-agnostic、不依賴 antd，提供 E.164 進出、可搜尋國旗 / 國碼下拉、可配置驗證等級（strict / mobile-strict / loose）、可主題化 CSS 與 i18n，電話邏輯由 google-libphonenumber 驅動。輕量、完整 TypeScript 型別。免費開源（MIT）。 - [Uptime Kuma Cluster](https://blog.markkulab.net/tools/uptime-kuma-cluster): 把單機版 Uptime Kuma 改造成高可用叢集：OpenResty + Lua 智慧負載平衡、MariaDB 共享狀態、健康檢查與自動 Failover，附叢集管理 REST API，一行 Docker Compose 啟動。免費開源（MIT）。 - [特教專案](https://blog.markkulab.net/education): 為特殊教育學生製作的學習教材 ### 每日 Podcast - [科技新鮮事](https://blog.markkulab.net/category/tech-news): 每日精選 AI 與科技趨勢，透過語音摘要快速掌握最新技術動態，涵蓋 AI 應用、軟體架構、DevOps 與工程實戰。 — RSS: https://blog.markkulab.net/feed.xml - [AI股市蝦聊](https://blog.markkulab.net/category/ai-stock-chat): 每個交易日用 AI 分析台股盤勢，以雙人對話聊當天的盤中觀察與隔日預測。 — RSS: https://blog.markkulab.net/ai-stock-chat/feed.xml ### 電子報 [訂閱電子報](https://blog.markkulab.net/subscribe) — 第一時間收到新文章通知，無垃圾信、隨時可取消訂閱。