2026 多代理 AI 協調：模式決策指南
兩個代理比一個簡單，五個代理就是麻煩的開始
2026 年，幾乎每個把 AI 推到生產的團隊，最後都會撞上同一面牆。單一代理把工作流簡單的七成處理得漂亮。然後有人加了一個研究子代理，再加一個寫作子代理，再加一個批評子代理。簡報上看起來很厲害。到了生產環境，代理開始互相搶工具呼叫。主管代理搞不清楚哪個子代理負責哪個任務。token 成本以二次方成長、延遲以線性成長，而團隊的除錯介面從一條追蹤變成一個沒人想讀的追蹤圖。
這就是多代理協調問題，也是 2026 年最被低估的工程難題。框架已經成熟了。LangGraph、CrewAI、Microsoft Agent Framework、AutoGen、Swarm——全都交付出可投入生產的基礎元件。困難的從來不是框架。問題在於這個領域至今仍把協調模式當成事後考量，但在實務裡，模式就是架構。
這篇文章是寫給要為真實工作流（不是展示）挑選協調模式的開發者。我們會涵蓋 2026 年真正上線的模式、對應的框架、沒人會提醒你的取捨，以及一份決策指南，幫你為「你手上的」工作流選對模式——而不是你希望有的工作流。如果你來這裡是想看框架跑分，這篇是錯的文章。多數情境下框架可以互換，模式不行。
2026 年「多代理」真正的意思
現在市面上流通著三種多代理架構定義，把它們混為一談是糟糕架構決策的根源。第一個定義——也是大多數廠商展示會用的——是代理式工作流：一張由 LLM 呼叫組成的圖，以分支方式組成確定性管線。這就是 LangChain 早期的「agent executor」做的事，也是多數團隊在「多代理」標籤下實際打造的東西。它們其實不是真的多代理，而是多步驟。
第二個是協作代理：多個由 LLM 驅動的行動者，各自擁有獨立的上下文視窗、工具與決策權，透過訊息傳遞互相溝通。這就是 Anthropic Research 系統採用的模型，也是 Microsoft Agent Framework 所說的「handoff（移交）」或「group collaboration（群組協作）」模式。這類系統會展現湧現行為，能各自採取不同策略。
第三個是代理群：大量小型代理鬆散地協調，常共用記憶體或任務佇列，優先最佳化吞吐量而非單一任務的正確性。OpenAI Swarm 函式庫與部分 CrewAI Flows 執行階段偏向這裡。代理群在研究、摘要、高吞吐量抽取上很出色；對單一錯誤就代價高昂的交易型工作流來說，通常是錯的。
該用哪個模式，取決於你實際需要的是哪一種。多數團隊需要的是帶確定性骨架的協作代理。純粹的代理群比行銷說的少見。把多步驟管線加上單一代理的上下文，通常就夠應付那些「人們以為」需要多代理的問題。
真正上線的五種模式
五種協調模式佔了 2026 年生產多代理系統壓倒性的多數。每一種都有獨特的失敗模式、獨特的成本輪廓、以及適合它的某類工作流。沒有任何一種是全面最優的。
1. 管線（循序）
最古老的模式。代理 A 把輸出交給代理 B，代理 B 把輸出交給代理 C。管線可以分支或迴圈，但執行大體上線性。最好的心智模型是有型別的函式管線，每個函式恰好是一個 LLM。常見於文件處理（抽取 → 分類 → 摘要 → 翻譯）、研究（搜尋 → 綜合 → 查證），以及程式碼審查（解析 → 分析 → 建議）。
取捨：管線容易推理、容易除錯、容易在步驟之間設一道品質門檻把關。它們也以一種特定方式「fail open」——一個自信但錯誤的中間輸出，會默默傳遞到每個下游階段，而每個階段都把上一階段的輸出當成事實。Anthropic 工程團隊的多代理研究文章明指了這件事。如果沒有明確的驗證或挑戰步驟，管線會默默放大幻覺。
2. 主管（階層式）
一個主導代理負責整個任務。它拆解工作、分派子代理、監督進度、整合最終答案。這是 2026 年生產環境的主流模式——Anthropic 的 Research 功能、LangGraph 的 supervisor 模式、CrewAI 的階層式 process，以及 Microsoft Agent Framework 的群組聊天全都收斂到這裡。
取捨：主管模式之所以強大，正是因為它會做決策，但同樣的決策能力也是它的失敗模式。一個差的主管計畫，會把差的工作傳遞給每個子代理。主管的上下文視窗會隨著累積的中間結果膨脹；如果沒有明確的上下文工程（壓縮、摘要、或選擇性保留），主管會在任務完成前就把注意力預算用完。Anthropic 回報，BrowseComp 表現 80% 的變異來自 token 用量，主管上下文視窗管理就是那個槓桿。請把主管的上下文當成一等公民來看，而不是工具呼叫的免費副作用。
3. 對等（協作式）
沒有單一主導。代理共用一個訊息頻道，自行決定誰回應。Microsoft Agent Framework 的群組聊天模式與 CrewAI 的 consensual collaboration process 屬於這一類。最適合創意發想、腦力激盪、辯論，以及任何「對的答案從歧見中浮現」的工作流。
取捨：對等模式是「最容易產生湧現但不可預期行為」的模式。兩個代理可以對同一個問題無限期迴圈，或一個代理主導而其他沉默。如果沒有明確的終止條件、主持人角色、以及回合預算，對等模式會失控。它也是最難評估的模式，因為軌跡不是唯一的。如果你的工作流有可量測的正確答案，對等模式通常是錯的。
4. 移交（轉移）
同一時間只有一個代理擁有對話。當它的任務完成，或它判斷另一個代理更適合時，它把整個上下文交出去。這是客服分流（接待代理 → 帳務代理 → 技術代理）、銷售路由、以及多數偽裝成「單一小幫手」的 B2B 代理產品背後的模型。
取捨：移交模式最容易設定範圍、把關、與稽核。每個代理的上下文視窗保持精簡；每個代理的工具可以權限控管到它實際需要的資源。失敗模式是「無聲的移交循環」——代理 A 移交給 B，B 又交回給 A，使用者就在那邊等。如果沒有跳躍次數上限與強制升級到真人，會話可能無限乒乓。
5. 代理群（平行工作者）
許多小型代理從共用佇列取任務，常共用記憶體或共用草稿本。最適合語料庫上的高吞吐量平行工作。大規模文件分析（每份文件一個代理）、批次抽取、平行搜尋、紅隊演練都屬於這裡。
取捨：代理群以犧牲單一任務可靠性來換取吞吐量。當你有數百個相似且獨立的任務、以及一個能在整體上抓出錯誤的下游驗證步驟時，它是正確答案。它對單一高風險工作流是錯的答案。別讓行銷說服你相信相反的事。
框架地圖：誰主攻哪個模式
2026 年的框架層已經收斂。五個框架交付出嚴肅的生產基礎元件；另外半打提供更輕量的抽象或特定用途。以下是實務地圖。
| 框架 | 最強模式 | 部署介面 | 擅長場景 | 較弱處 |
|---|---|---|---|---|
| LangGraph | 主管、管線、圖形思考 | LangSmith Deployment（前身 LangGraph Platform）；自架 | 長時間有狀態代理、可續執行、checkpoint、人在迴圈中 | 概念負擔陡；你得自己打造協調邏輯 |
| CrewAI | 角色式 crew、循序/階層/共識 | CrewAI AMP 雲端；Docker 自架 | 快速原型、角色與目標的心智模型、給非工程師的視覺化建構器 | 狀態管理是隱式的；跨 crew 除錯比 LangGraph 困難 |
| Microsoft Agent Framework | 圖形工作流、移交、群組聊天、循序、並行 | Python、.NET、Go；Microsoft Foundry 雲端；自架 | .NET 與 Azure 重度團隊、企業治理、checkpoint | 四個框架中年紀最輕；第三方範例池較小 |
| AutoGen（微軟研究院） | 對話式、對等 | Python；自架 | 研究、對話式實驗、辯論式協調 | 生產硬化由團隊負責；偏向原型導向 |
| OpenAI Swarm | 移交、輕量 | Python 函式庫；實驗性 | 教學、移交優先設計、原型後再移植 | 未針對生產硬化；OpenAI 未承諾長期支援 |
先選模式，再選最會實現它的框架。順序反過來——先選框架再把工作流硬凹進去——是團隊搞出過度工程化架構的原因。
決策指南：模式對應工作流
2026 年最常見的錯誤，是把「多代理」當成目標。它不是。它是一個有成本的工具。用以下指南，挑最便宜且合用的模式。
| 如果你的工作流是… | 選這個模式 | 理由 |
|---|---|---|
| 確定性步驟，每一步可步進、每一步有可驗證輸出 | 管線（循序） | 最便宜除錯、最容易把關；單一代理的上下文通常就夠 |
| 開放式研究或分析，路徑未知 | 平行子代理的主管 | 把未知路徑拆解，又能驗證最終綜合 |
| 面對客戶的分流、路由、銷售 | 移交 | 每代理權限、上下文精簡、稽核軌跡清楚 |
| 腦力激盪、創意發想、設計探索 | 有主持人的對等 | 湧現的歧見是特色，不是 bug |
| 語料庫的高吞吐量平行處理 | 有下游驗證的代理群 | 吞吐量是價值所在；用整體驗證抓錯，不是逐任務 |
| 單一代理已正確處理 80% 以上的工作流 | 停下來。改進單一代理。 | 多代理的邊際效益少有值得營運成本 |
沒人談論的成本現實
Anthropic 工程團隊在 2025 年發佈了少數關於多代理成本的硬數字。多代理系統對同一任務使用的 token 量約為單一代理聊天的 4 倍，對最難的研究類查詢則約為 15 倍。這不是打錯字。多代理系統中的 token 花費不是隨任務複雜度線性成長——而是超線性，因為每個子代理各自攜帶上下文，加上主管累積的上下文，再加上訊息傳遞的開銷。
這不代表「不要做多代理」。它代表「擴展之前先量」。如果單一代理的基準在每次查詢花 0.8 美分，而多代理版本每次查詢多花 10 美分，那就是成本增加 12.5 倍換來未知的品質差異。我們看過團隊出貨多代理架構，唯一量化效益是評估集上 3% 的品質提升，相對成本增加 600%。那是壞交易。如果你的評估套件沒顯示有意義的品質贏面，就別付多代理的溢價。
兩個緩解手段很重要。第一，子代理用比主管更小的模型。Anthropic 自己的生產架構把 Claude Opus 4 主管配上 Claude Sonnet 4 子代理。主管是昂貴的推理；子代理是結構化抽取。token 對品質的曲線在主管那層比子代理那層陡得多。第二，子代理的輸出在送進主管之前先壓縮或摘要。一個 10,000 token 的原始搜尋結果，到達主管時應該是 400 token 的結構化摘要，不是逐字稿。多數團隊跳過這一步，因為它需要工程；但它也正是主管 30–50% token 預算被浪費的地方。
好架構長什麼樣：Anthropic Research 模式
值得描述 Anthropic Claude Research 功能背後的架構，因為它是 2026 年生產多代理模式最乾淨的參考實作。三個元件很重要：
- 規劃研究的主導代理。它不搜尋。它決定要搜什麼、依什麼順序、以及原始查詢要拆解成哪些子問題。它接收查詢、回傳研究計畫。
- 執行搜尋的平行子代理。每個子代理有自己的上下文視窗、自己的工具、自己的搜尋軌跡。它們並行執行。它們回傳結構化摘要，不是原始結果。
- 綜合步驟。主導代理消化摘要、找出缺口、可能再分派更多子代理，然後產出答案。
三個細節讓這套架構成為可能。第一，主導代理永遠看不到原始搜尋輸出——只有結構化摘要。這是整個架構裡最重要的決定。第二，子代理的提示是量身打造而非通用。搜尋公司董事的子代理，跟搜尋學術文獻的子代理，指令完全不同。第三，評估是軌跡感知。Anthropic 評分整條軌跡，不只是最終答案，因為一個正確的最終答案配上一條浪費的軌跡，仍然是營運問題。
多數團隊應該複製這個模式。它不是唯一對的模式，但是 2026 年文件最齊全的生產模式，也是這個領域最接近「參考架構」的東西。
常見錯誤
把多代理當成答案。它只是某類問題的答案。對單一代理已正確處理的問題，多代理是開銷。我們看過團隊加子代理，只是因為架構圖看起來更厲害，不是評估套件要求。
讓主管攜帶原始中間上下文。一個收到 10,000 token 原始搜尋輸出的主管，在後續每一步都付 10,000 token 的注意力稅。壓縮、摘要、或評分篩選之後再讓主管看到資料。多數「我的多代理系統上下文不夠用」的問題，其實是「我的主管囤著它沒用到的上下文」。
跳過終止條件。如果沒有明確的停止規則——回合預算、跳躍次數、主持人決定、或品質門檻——任何多代理模式都可以無限迴圈。對等是最嚴重的犯規者。主管迴圈比較容易抓，因為它們都在同一條追蹤裡；對等迴圈可以藏在代理之間。
把工具開放給所有代理。一個有所有工具權限的子代理，就是一個可以呼叫任何工具的子代理。每代理權限控管是 2026 年最便宜的可靠性贏值之一。移交模式天生就把這件事做好；主管模式需要紀律。一個做研究的子代理不應該擁有你的資料庫寫入權限。
把框架當成架構。框架是實作。架構是模式。兩個用 LangGraph 的團隊可以交付出截然不同的架構。一個用 CrewAI、另一個用 Microsoft Agent Framework 的團隊可以交付出同一套架構。先根據問題選架構，再選實現它的框架。
忽略評估。多代理系統的錯誤會跨代理累積。三個代理各 5% 的錯誤率，大約等於 14% 的複合錯誤率。如果你沒在跑軌跡感知評估套件，你根本不知道自己在出貨什麼。框架自帶可觀測性（LangGraph + LangSmith、CrewAI AMP、Microsoft Agent Framework + Foundry）光是這一點就值得它們的營運複雜度。
多代理是錯選擇的時候
當以下任何一項成立時，多代理就是錯的選擇：任務有單一代理已找到的確定性正確答案；延遲是約束條件，你負擔不起訊息傳遞延遲；團隊無法做軌跡級可觀測性；成本上限低於多代理溢價；或者工作流的評估套件分不出單一代理與多代理的表現。
多數內部工具——摘要、分類、抽取、單步問答——單一代理搭配好的視訊工程就是正確答案。整個產業在 2024–2025 出貨了一整代多代理框架，而多數的生產部署其實是用那些框架打造本質上就是「帶結構化工具呼叫的單一代理」。那不是批評。那是多數問題的正確答案。
多代理的對的時機是：工作流開放、路徑未知、而替代方案是一個會對每個新查詢形狀都壞掉的脆弱確定性管線。研究、複雜客服、多源綜合、以及任何符合 Anthropic 研究評估報告「比單一代理提升 90.2%」的工作流，才是真正的贏面。在其他地方，框架只是給了你用不到的多餘表面。
實務的打造順序
如果你從零開始，2026 年能交付出可靠多代理系統的打造順序長這樣：
- 打造單一代理基準版。推給內部使用者。量測。
- 找出單一代理無法處理的失敗模式。忍住一次修全部的衝動。
- 加最小可行的多代理拆解——通常是一個主管加一個專家。
- 在擴展更多代理之前，先把軌跡級可觀測性裝好。
- 只有當評估套件正當化時，才加下一個代理。
出問題的團隊跳過步驟 1、略過步驟 4、然後在步驟 5 一直加代理直到系統無法維護。能交付可靠系統的團隊做相反的事：最小拆解、先量測、再增量擴展。
常見問題
我真的需要框架嗎？還是用純 Python 就能協調代理？
對兩個代理、沒有生產流量的原型，純 Python 可以。框架開始顯得值得，是當你需要耐久性（當機後 checkpoint 與恢復）、可觀測性（軌跡追蹤）、每代理權限控管、或人在迴圈中。如果你正在推到生產，問題不在框架；耐久性、retry 策略、可觀測性才是。挑一個把這些都免費送你的框架。
幾個代理算「太多」？
超過大約七個，協調成本開始主導。2026 年生產系統的經驗法則是每個工作流三到五個代理，一個主管配兩到四位專家。超過這個數字通常代表你沒把工作流拆乾淨。我們看過 15 個代理的研究系統，四個就能做同樣的事，且可觀測性更好、成本更低。
所有代理要用同一個 LLM 嗎？
不要。主管用最強的推理模型，子代理用更便宜、更快的模型來做結構化抽取、搜尋或摘要。token 對品質的曲線在主管層比子代理層陡很多。Anthropic 自己的架構把 Opus 4 主管配 Sonnet 4 子代理。成本與品質的贏面很大。
Microsoft Agent Framework vs LangGraph 怎麼選？
它們是 2026 年生產動能最強的兩個框架。Microsoft Agent Framework 較適合 .NET 重度企業團隊、Azure 部署、以及需要治理與中介層內建的團隊。LangGraph 較適合 Python 優先的團隊、需要深度自訂協調圖、與已經用 LangSmith 的團隊。它們並不互斥——LangGraph 今天有更豐富的第三方整合生態系；MAF 有更強的企業級耐久性基礎元件。
怎麼評估多代理系統？
用軌跡感知評估，不只是最終答案評估。評分整條追蹤——工具呼叫數、每任務 token 花費、錯誤後恢復率、拒答校準。多代理的錯誤會累積；只看最終答案的準確率會藏住導致累積的每代理錯誤率。LangSmith、CrewAI AMP 與 Microsoft Foundry 都把軌跡感知追蹤作為一級功能。請用上。
結語
協調模式比框架重要。2026 年有五個生產級框架成熟；而把可靠多代理系統與脆弱多代理系統分開的，幾乎從來不是框架選擇。是模式。挑合用於工作流的模式。用能解決問題的最小拆解。擴展之前先量。多代理的 4 倍 token 溢價是真的，只有當評估套件顯示品質提升值得時，才該付。