AI Workflow Lab
Learn to build production-ready multi-agent AI systems with MCP, A2A protocols, LangGraph, and proven architecture patterns. Includes Python code examples.
AI 生成摘要
這篇文章是給實務工作者的指南，教你如何在2026年建構可投入生產的多代理AI系統，涵蓋架構模式、MCP、A2A協定，以及生產協調，並包含Python程式碼範例。
單一、龐大的 AI 代理的時代正在結束——而且說實話，早就該結束了。 預計到 2026 年，AI 代理系統的市場將達到 85 億美元，預測到 2030 年將達到 350 億美元。這些不是來自某些邊緣分析師報告的推測性數字：現在有 57% 的公司在生產中部署 AI 代理，Gartner 估計，到今年年底，40% 的企業應用程式將具有特定任務的代理，而 2025 年僅為 5%。
原因在於架構，而不是炒作驅動。
單一代理，無論底層模型多麼強大，在面對複雜、多領域的任務時都會達到瓶頸。 它必須掌握整個上下文，決定下一步行動，執行它，評估結果，然後重複——所有這些都在一個推理迴圈中完成。 多代理系統應用了幾十年來一直主導有效軟體工程的相同原則：分而治之。 通過將複雜的工作流程分解為專門的子任務，每個子任務由專門構建的代理處理，您可以獲得模組化、故障隔離以及獨立擴展各個元件的能力。
本文是實務指南。 我們將介紹多代理系統的核心架構模式，深入研究模型上下文協定 (MCP) 和代理到代理協定 (A2A)，比較領先的框架，逐步介紹生產最佳實務，並使用監督者模式構建一個可運作的研究助理。 如果您今天正在構建代理系統——或者計劃構建——這就是您需要的參考資料。
在選擇框架或協定之前，您需要了解可用的基本協調模式。 每個模式都在簡潔性、靈活性和容錯性之間進行不同的權衡。 因此，讓我們分解它們。
最簡單的多代理模式是循序管道：代理 A 完成其工作，將結果傳遞給代理 B，後者將其結果傳遞給代理 C，依此類推。 當您的任務具有嚴格的線性依賴關係時，這是正確的選擇——每個步驟確實需要前一個步驟的完整輸出才能開始。
一個經典的例子是內容生成管道：研究代理收集源材料，起草代理編寫初始文本，編輯代理完善它，事實核查代理驗證聲明。 每個階段完全依賴於前一個階段的輸出。
優點是簡單性和可調試性。 缺點是什麼？ 延遲（總時間是所有階段的總和）和脆弱性（任何階段的故障都會停止整個管道）。 當依賴鏈是真實且不可避免時，請使用此模式。
監督者模式引入了一個中央編排代理，該代理分解任務、委派給專業代理、評估它們的輸出並綜合最終結果。 這是大多數生產多代理系統的工作模式——並且有充分的理由。
一個關鍵的設計規則：必須指定恰好一個代理作為編排者，以防止協調衝突。 如果兩個代理都認為它們正在協調，您會得到重複的工作、矛盾的指令和極難調試的競爭條件。 我在真實專案中看到過這種情況，解開它從來都不是一件有趣的事。
監督者檢查每個專家的輸出，決定是否需要另一個專家採取行動，並且只有在它判斷任務完成時才會終止。 使此模式真正發光的是迭代改進——如果分析師發現數據中的差距，監督者可以將工作發送回研究人員。
路由器模式對傳入的請求進行分類，並將它們分發給適當的專家，然後綜合結果。 與監督者不同，路由器不參與多輪編排。 它做出單一的路由決策（或少量並行的路由決策），然後進行聚合。
此模式在多垂直知識庫中表現出色。 想像一個處理帳單、技術和帳戶查詢的支援系統。 路由器代理對傳入的問題進行分類，將其分派給相關的領域代理，並返回回應。 如果問題跨越多個領域，路由器會並行分發給多個專家並合併他們的答案。
路由器模式比完整的監督者更簡單、更快，但它缺乏跨代理進行迭代、多步驟推理的能力。 當您的問題主要關於分類和分派，而不是複雜的多步驟協作時，請選擇它。
在移交模式中，活動代理根據對話上下文動態變化。 不是由中央編排者決定誰採取行動，而是每個代理都可以在確定對話已超出其專業知識範圍時將控制權轉移給另一個代理。
此模式非常適合客戶支援流程和多階段對話體驗。 這樣想：用戶開始與一般的分類代理交談，當談到錢時，該代理會移交給帳單專家，當用戶威脅要取消時，該專家會移交給保留專家。 感覺很自然，因為它反映了真實支援團隊的工作方式。
這裡的關鍵優勢是它產生了自然的對話流程。 用戶不會遇到令人不快的上下文切換，因為每個代理都會收到完整的對話歷史記錄。 主要風險是什麼？ 設計不佳的移交條件可能會產生迴圈或死胡同——因此請徹底測試您的移交邏輯。
群體模式是移交模式的完全分散式變體。 沒有指定的編排者。 代理根據他們的專業化動態地相互移交，形成湧現的協調模式。 OpenAI 的 Swarm 框架推廣了這種方法。
當問題空間被很好地劃分並且每個代理都有明確的、不重疊的專業化時，群體效果最佳。 當任務需要全局協調或問題分解不明確時，它們會遇到困難。 在實踐中，大多數生產系統使用混合模式：域內的群體式移交，由跨域的更高級別的編排者監督。
如果多代理架構是骨架，那麼模型上下文協定就是神經系統。 MCP 由 Anthropic 在 2024 年 11 月宣佈，現在由 Linux 基金會的 Agentic AI 基金會管理，已成為代理到工具通信的事實標準。 堅持的類比（而且是一個很好的類比）是「AI 的 USB-C」：一個單一的、標準化的介面，允許任何代理連接到任何工具。
MCP 定義了三個核心基本元素，每個元素都為不同的互動模式而設計：
這種三向劃分是經過深思熟慮的。 它清晰地映射到任何代理系統中的三個控制平面：模型決定做什麼（工具）、應用程式提供什麼作為上下文（資源）以及用戶選擇什麼作為互動模式（提示）。
Python SDK 使將您的服務公開為 MCP 相容的工具和資源變得非常簡單：
這裡有一些值得注意的事情。 生存期模式使用異步上下文管理器來確保在啟動時正確初始化數據庫連接和快取客戶端，並在關閉時進行清理——這絕對是您在生產環境中需要的。 進度報告 API 允許客戶端顯示長時間運行的操作的有意義的狀態更新。 資源定義為模型提供結構化上下文（如數據庫模式），而無需工具調用。
MCP 規範在開放治理下繼續快速發展。 2026 年的主要增強功能包括多模式支援，允許工具和資源以原生方式處理圖像、視頻和音頻。 工具現在可以返回帶註釋的圖像或接受音頻剪輯作為輸入，協定處理序列化和流式傳輸。 轉向 Linux 基金會也加速了採用，主要雲提供商現在提供託管 MCP 伺服器託管。
雖然 MCP 標準化了代理如何與工具交談，但代理到代理協定 (A2A) 標準化了代理如何相互交談。 A2A 由 Google 發起，擁有 50 多個合作夥伴（包括 Atlassian、Salesforce 和 SAP），現在也由 Linux 基金會管理。 這兩個協定是互補的：MCP 處理垂直整合（代理到工具），A2A 處理水平整合（代理到代理）。
A2A 建立在三個基本思想之上：
規範的 0.3 版本增加了 gRPC 支援，為延遲敏感、高吞吐量的代理間通信啟用了高性能二進制通信——想想實時交易系統或自動駕駛汽車協調。
考慮這樣一種情況：您的組織在不同的團隊中獨立開發了代理：法律合規代理、財務分析代理和客戶洞察代理。 如果沒有 A2A，整合這些代理需要自定義點對點整合（相信我，這會很快變得混亂）。 借助 A2A，每個代理都會發布一個代理卡，任何其他代理或編排者都可以通過標準化協定發現和調用它。
MCP 和 A2A 的結合創建了一個強大的互操作性層。 編排者代理使用 A2A 將子任務委派給專業代理。 該專業代理使用 MCP 與其工具互動。 結果通過 A2A 流回編排者，後者綜合最終輸出。 單獨使用任何一個協定都不夠； 它們共同構成了多代理系統的完整通信基礎設施。
多代理框架的格局已經相當成熟。 這是對四個領先選項的實際比較，基於基準測試和實際使用模式。
LangGraph 建立在 LangChain 之上，將代理工作流程建模為具有顯式狀態管理的有向圖。 基準測試結果表明它是最快的框架——在等效任務上比 CrewAI 快約 2.2 倍。 它也是最節省 token 的，在標準基準測試任務上使用大約 2,589 個 token，而 CrewAI 使用 5,339 個。
LangGraph 的優勢在於細粒度控制。 您顯式定義節點（代理或函數）、邊（轉換）和條件路由邏輯。 這使得複雜的工作流程透明且可調試。 缺點是什麼？ 與更高級別的抽象相比，學習曲線更陡峭，樣板代碼更多。
在以下情況下選擇 LangGraph：您需要最大的性能和控制，您的工作流程具有複雜的分支邏輯，或者您需要優化 token 使用量和成本。
CrewAI 採用基於角色的團隊隱喻。 您將代理定義為具有特定角色、目標和背景故事的團隊成員。 任務分配給代理，框架處理協調。 CrewAI 每個任務使用最多的上下文（大約 5,339 個 token），這意味著代理具有更豐富的上下文，但成本更高。 複雜任務的延遲約為 9 秒。
CrewAI 的真正優勢在於開發者體驗。 定義代理團隊和一組任務是直觀的，並且需要最少的樣板代碼。 如果您曾經組織過團隊會議，那麼心理模型會很好地轉移。
在以下情況下選擇 CrewAI：您想要快速原型設計，您的團隊在代理架構方面經驗較少，或者代理之間全面的上下文傳遞比原始速度更重要。
AutoGen 將多代理互動建模為對話。 代理以類似聊天的格式相互交談，具有可配置的對話模式（雙代理聊天、群組聊天、嵌套聊天）。 每個任務的 token 使用量平衡在大約 3,316 個 token。
AutoGen 的優勢在於定義對話協作模式的靈活性，特別是對於受益於辯論、批評和迭代改進的任務。 它在代碼生成任務中表現特別出色，其中一個代理編寫代碼，另一個代理審查代碼。
在以下情況下選擇 AutoGen：您的任務受益於代理到代理的審議，您需要協作代碼生成，或者您想要比基於圖的工作流程感覺更自然的對話模式。
OpenAI Agents SDK 是最新的參與者，提供原生 MCP 支援和內置的移交基本元素。 它旨在盡可能簡潔和有主見：代理、移交和防護欄是核心抽象。 SDK 與 OpenAI 的模型生態系統緊密整合，但可以與其他提供商合作。
在以下情況下選擇 OpenAI Agents SDK：您主要基於 OpenAI 模型構建，您需要內置的移交和防護欄支援，或者您想要用於常見代理模式的最簡單的 API。
沒有一個框架是普遍最好的。 決策矩陣如下所示：
在實踐中，許多生產系統使用組合。 LangGraph 監督者編排 CrewAI 子團隊是一個完全有效——並且越來越常見——的架構。
構建在演示中運作的多代理系統很簡單。 構建在生產中運作的系統？ 這完全是另一門學科。 以下是將玩具系統與可靠系統區分開來的模式和實務。
這可能是多代理生產系統最重要的見解：大多數代理故障是編排和上下文傳輸問題，而不是模型故障。 底層模型通常會產生良好的輸出。 當代理 A 的輸出沒有正確格式化為代理 B 的輸入時，當上下文在移交過程中丟失時，或者當編排者做出錯誤的路由決策時，系統會崩潰。
解決方案是結構化的移交模式。 不要代理之間傳遞自由格式文本。 使用顯式的、類型化的結構：
此結構強制每個代理明確說明它發現了什麼、它的信心有多大、什麼證據支持它的結論以及還剩下什麼問題。 下游代理接收結構化的上下文，而不是含糊不清的文本塊。 這是一項小投資，可以在調試時間上獲得巨大的回報。
代理記憶不能是事後才想到的。 在生產中，您需要具有不同持久性和訪問模式的分層記憶儲存：
語義快取層值得特別關注。 與精確匹配快取不同，語義快取使用嵌入相似性來查找足夠接近以重用的先前回應。 如果用戶詢問「第三季度收入數字是多少？」，並且有人先前詢問「向我顯示第三季度收入」，則語義快取可以提供先前的結果，而無需調用任何代理。 非常聰明，對吧？
無狀態代理設計更容易水平擴展，但需要在每次調用時重建上下文。 有狀態設計保持連續性，但為負載平衡、故障轉移和水平擴展帶來了挑戰。
大多數生產系統使用無狀態-具有-外部-狀態模式：代理本身是無狀態的，但它們從外部狀態儲存（Redis、DynamoDB 或專用狀態管理服務）讀取和寫入。 這使您既具有無狀態的可擴展性，又具有有狀態的連續性。 這是兩全其美，假設您可以容忍外部狀態查找的額外延遲。
您無法調試您無法觀察到的內容。 每個生產多代理系統都需要：
OpenTelemetry 已成為代理系統的標準檢測層，有幾個代理特定的擴展可用於追蹤多步驟工作流程。
多代理系統顯著擴大了攻擊面。 代理可以訪問的每個工具都是潛在的向量。 必要的安全措施包括：
傳統的單元測試是必要的，但還不夠。 多代理系統需要三個額外的測試層：
讓我們用一個完整的、可運作的範例將所有內容聯繫起來：一個使用監督者模式、LangGraph 進行編排和 MCP 進行工具整合的多代理研究助理。 該系統有三個由監督者協調的專業代理。
該系統包含四個代理：
首先，我們定義我們的代理將使用的工具，公開為 MCP 伺服器：
現在我們構建 LangGraph 監督者，它協調我們的三個專家：
此研究助理說明了我們在本文中討論的幾個關鍵原則：
在生產部署中，您將添加可觀察性（每個節點周圍的 OpenTelemetry span）、持久狀態（將中間結果檢查點到數據庫）、身份驗證（用於工具訪問的 OAuth token）和全面的錯誤處理（重試、回退和優雅降級）。 但此處顯示的核心架構是其他所有內容都建立在其上的基礎。
幾個趨勢正在融合，以塑造多代理 AI 的下一個階段。
最重要的轉變是從人在迴圈（人批准每個行動）到人在迴圈（人設置策略、監控結果，並且僅在需要時進行干預）。 這是由實際需要驅動的：隨著代理系統並行處理更多任務，每次行動的人工批准都會成為瓶頸。 相反，組織正在定義防護欄、預算和升級標準，使代理系統可以在定義的範圍內自主運行。
人類操作員的角色正在從使用代理的人轉變為管理代理團隊的人。 這需要新的技能：定義明確的目標、設置適當的自主級別、設計升級路徑以及解釋代理決策追蹤。 這是管理，而不是提示——而且說實話，這種轉變讓很多人措手不及。
MCP 和 A2A 生態系統正在 Linux 基金會的治理下迅速融合。 新興的架構很清晰：MCP 用於代理到工具的通信，A2A 用於代理到代理的通信，以及跨越兩者的共享發現和身份驗證層。 現在採用這些標準的組織將擁有可互操作的代理系統。 那些建立在專有協定上的組織將面臨以後的昂貴遷移。
多代理系統正在跨越 2026 年的企業就緒門檻。 標準化協定、成熟框架、已建立的可觀察性和安全性的最佳實務以及組織在代理操作方面的經驗不斷增長，這意味著問題不再是是否構建多代理系統，而是如何構建它們。
將引領的組織是那些投資於三件事的組織：強大的架構基礎（本文中描述的模式）、協定採用（MCP 和 A2A，而不是自定義整合）以及卓越的運營（可觀察性、測試和安全性作為首要考慮，而不是事後才想到）。 多代理的未來不是即將到來——它就在這裡。 問題是您是否在堅實的基礎上構建它。