LLM 打破 15 年 MARL 技術范式，多智能體協作進展到哪一步了？

我們對于 2022 年印象如此深刻，或許正是因為那一年的11月，ChatGPT 問世，讓全世界看到了大語言模型（LLM）的潛力。

然而，很少有人知道，那年 8 月，當公眾的注意力還被即將到來的 ChatGPT 所牽引時，AWS 內部已經誕生了首個基于 LLM 的智能體系統 Dialog2API。它繞過了傳統的多智能體強化學習（MARL）框架，嘗試讓智能體通過自然語言進行理解與協作。

主導這一前瞻性探索的，正是Raphael Shu，彼時他正在 Amazon Bedrock Agents 擔任 Tech Lead。

Raphael Shu

這并非偶然，從東京大學博士期間鉆研非自回歸生成模型，到在 Yann LeCun 實驗室探索下一代AI范式，Raphael Shu 的研究軌跡始終緊扣著技術演進的前沿。在加入 AWS AI Lab 后，他于2022年帶領團隊“all in” LLM AI Agent。

然而，在親手打造了北美首個云端托管的多智能體協作平臺——Bedrock Multi-Agent Collaboration 后，Raphael Shu 卻做出了一個出人意料的決定：離開 AWS，投身開源創業。

因為他清晰地看到，單智能體受限于其上下文能力，難以在復雜任務中自如切換規劃、執行與評估等多種思維模式，而多智能體的分工協作與群體自治，才是解決復雜、動態問題的關鍵。

尤其是在開放世界中，群體智能才是未來。

11 月初，Raphael Shu 在 2025 全球開源技術峰會上，以《開放世界中的多智能體協作》為題，梳理了多智能體系統從理論奠基到開放生態的技術演進路徑。以下內容根據其演講整理。

PART 01

LLM 如何顛覆 MARL 技術范式？

需要明確的是，多智能體系統并不是一個全新的概念。

早在上世紀 90 年代，就曾掀起過一輪多智能體研究熱潮。比如 Wooldridge 在 1995 年出版的經典教科書《Intelligent Agents》，早已為智能體和多智能體協作奠定了理論基礎。

進入 21 世紀初，基于簡單架構（而非自然語言）的多智能體系統開始出現。2002 年，專注于該領域的 AAAMS 學會創立。不過，在 2000 早期，尤其是在強化學習被引入多智能體系統相關研究之前，更多地是以簡單的工程架構的方式來探討多智能體協作。

這一局面直到 2017 年左右才迎來突破。隨著多智能體強化學習（MARL）的出現，多智能體系統首次實現了大規模的工業級應用。

一個典型的例子是城市交通信號燈協同調度。在一個擁有十萬個信號燈的城市中，如何實現全局最優的交通效率？通過 MARL，每個信號燈可以作為一個智能體，彼此之間進行信息交流與協同決策。例如，當某個路口檢測到車輛排隊過長時，這一信息能夠迅速被周邊信號燈感知，從而共同執行一次群體性的配時規劃。

隨后，神經網絡技術的普及也被迅速融入這一框架，進一步增強了系統的感知與決策能力。

實際上，在長達十年多年時間里，多智能體協作與強化學習幾乎成為了密不可分的關聯詞。

然而，2023 年 LLM 的興起，從根本上顛覆了延續近十五年的MARL技術范式。

比如開發自動駕駛多智能體系統，我們得事先約定“1011 代表前方車輛減速”“1000 代表收到指令”這樣的Code Book，還要通過大量強化學習讓 Agent 記住這些規則。但現實世界中總有未預設的場景——比如前方車輛視野被擋，突然發現闖紅燈車輛，這時沒有對應的 Code，Agent 就會卡殼。

而 LLM 的引入，使自然語言成為智能體之間理解與交互的通用媒介，徹底打破了這一模式。前車只需用自然語言說“前方有車，請稍等”，后車就能準確理解并放棄超車。這種自然語言的交互方式不僅適用于常見場景，更能靈活應對各種復雜狀況：

• 當車輛通過視線受阻的路口時，前車可以發出“有車闖紅燈，危險”的精準警告，后車便能立即制動；

• 當多輛車組成智能體系統時，它們還能進行復雜協商——例如救護車可以優先通行：“車上有急診病人，請讓行”；

• 在高速匯車場景中，車輛可通過自然語言在毫秒級內完成協商，決定“一車加速、一車減速”的具體操作；

• 隨著參與車輛增多，系統還能實現更復雜的群體決策和協調機制。

總的來說，LLM 的出現，為多智能體系統帶來了三大顛覆性改變：

無需預設協議：Agent 間通過自然語言直接交互，比如“前方有車闖紅燈，請注意避讓”，無需記憶復雜編碼；

場景無限制覆蓋：自然語言能精準描述任何長尾場景，無論是“路口有行人突然橫穿”還是“高速上后方有救護車”，Agent都能精準理解；

零訓練快速上線：無需大量強化學習訓練，新場景下 LLM 直接“聽懂”并響應，系統落地速度從“按月算”壓縮至“按天算”。

PART 02

Magentic One：企業應用多智能體系統的標配

微軟的 Magentic One，是異步多智能體系統的代表，歷經多版迭代，已成為北美企業級多智能體系統的“標配”。

Magentic One 采用中心化架構，其核心是一個主協調智能體（Orchestrator），負責統籌任務，并調度四個功能專一的子智能體（Sub Agent），分別負責文件管理、網頁瀏覽、編碼、命令執行。

具體而言，Magentic One 是如何運作的呢？

比如，當用戶向系統提交一個“分析標普500的趨勢”的任務時，整個流程將由一個 Orchestrator 主導，并進入一個核心循環：

1. 任務監控：Orchestrator 持續監控和評估當前任務的完成狀態。

2. 任務分解與分配：只要任務未被判定為完成，Orchestrator 就會將任務或子任務分配給一個合適的 Sub Agent（子智能體） 去執行。

3. 結果匯總：當所有子任務完成，Orchestrator 會收集結果，并向用戶反饋一個最終的 Summary（總結）。

可以看到，Magentic One 是一個很經典的中心化架構。在該架構中，Orchestrator 同時充當了任務的發起者與最終決策者，能夠將一個復雜任務進行分解，并分配給專門化的子智能體進行并行處理，從而實現高效的問題解決。

不過，值得注意的是，并非所有多智能體系統都采用這種中心化決策模式。例如，在某些場景下（如投票機制），即使由 Orchestrator 發起任務，最終決策也可能通過去中心化的投票方式產生。

基于對微軟、AWS 等標普 500 企業案例的深度拆解，異步多智能體系統通常包含四層架構：

1. 調度層：無 LLM 依賴，僅負責系統基礎運轉——比如給 Orchestrator 生成的指令排期、處理“文件寫入”等新事件，相當于多智能體的“行政管家”；

2. Orchestrator 層：核心決策層，僅聚焦兩大核心：一是“規劃”（生成 To-Do List 或基于知識圖譜的 DAG 圖），二是“追蹤”（監控任務進度，判斷下一步動作）；

3. 記憶層：存儲任務狀態（已完成/未完成）、新消息、Agent間共享緩存，如同多智能體的“共享大腦”，保障異步協作的狀態同步；

4. Agent Pool 層：執行層，由各類專項 Agent 組成（如數據處理 Agent、報告生成 Agent），接收Orchestrator 指令后直接落地執行。

PART 03

單智能體的能力局限

看到這里，相信很多人都會疑惑，對于撰寫分析報告這樣的任務，單智能體的能力已經足夠強了，基本能夠解決。為什么還要多智能體協作呢？

一方面，單智能體存在三大局限。

• 上下文限制：一個智能體的處理能力有限，很難同時兼顧復雜任務的不同方面。比如，一個任務可能需要它先做規劃，再去執行（如分析網頁、點擊按鈕），最后還要進行評估。這需要智能體在不同思維模式間頻繁切換，很容易達到其能力上限，導致整體表現不佳。

• 效率低下：當把所有任務都塞給一個智能體時，它可能會在某個局部問題上鉆牛角尖，花費過多時間，從而忽略了整體目標。舉個例子：這就像用 AI 編程工具（如 Cursor）時，你給它一個復雜需求，它有時會卡在一個微不足道的小 bug 上反復調試，而忘了最主要的任務。

• 違背“群體智能”規律：從長遠看，無論是自然界還是人類社會，群體協作的效率和質量通常都高于單個個體。多智能體可以將復雜問題分解，由不同專家分工協作、并行處理，效率自然更高。

二是多智能體的高級形態——群體自治表現出極高的協同優勢。除了分工協作，多智能體系統還能模擬人類社會的“競爭”機制。良性的競爭和博弈往往能更高效地解決問題。

舉個例子，在金融領域，分析“星巴克”的估值，最直接的方法是找到一位專注星巴克十年的金融分析師。但如果用戶需求是“分析標普 500 中任意一家公司的估值”，為每家公司都配一個專家，指定一套 Workflow 就不現實了。

這時，更好的方法是建立一個“虛擬交易所”，讓上千個代表不同分析視角的智能體在里面自由交易。通過它們之間的買賣行為，就能動態、高效地評估出任何一家公司的價值。

這就是“群體自治”的威力。

因此，關于多智能體協作的未來發展，核心在于兩個方面：一是如何設計更高效的組織拓撲架構，二是如何構建完整的生態系統。

目前整個產業生態正在圍繞以下幾個層次展開布局：

一是框架層，用于搭建多智能體系統的基礎工具。例如 LangGraph、AutoGen，以及OpenAI 最近低調發布的Agents SDK。

二是基礎設施層：提供托管服務的平臺。主要玩家包括 AWS 的 Bedrock Agents、字節的 Coze、Google 的 Vertex AI Agent Builder 等。微軟則主要依托 AutoGen、Semantic Kernel 等工具構建其生態。

以上兩層能幫助企業構建內部使用的、相對封閉的多智能體系統。但如果我們著眼于未來更開放的多智能體協作，目前還缺少兩個關鍵層次：

第三層的協議層，例如大家熟知的 MCP、A2A，以及近期出現的 ACNBP、ACP 等。這些協議旨在實現智能體與工具、服務之間的標準化通信。

第四層的網絡層，也可稱為協作層。開源的 OpenAgents 項目就屬于這一層，它建立在協議層之上，專注于解決大規模（如數百至數千個）智能體之間的跨協議協作問題。

PART 04

從“Workflow”到“Ecosystem”

當多智能體走出企業封閉場景，進入開放世界，新的問題隨之而來。

從此前提到的幾個應用實踐中可以看到，封閉系統具有幾個顯著特征：

• 任務邊界清晰，例如Magentic One系統專司報告撰寫或代碼生成，自動駕駛系統則聚焦于車輛間的協同決策；

• 智能體數量固定，如Magentic One始終維持四個智能體的架構；

• 其獎勵函數和外部環境也保持相對穩定。

在這種確定性框架下，特別是在企業級應用中，我們關注的重點是 Workflow Engineering ——如何設計最優的任務流水線，確定各個智能體的執行順序與協作方式，從而最大化獎勵函數。

然而，現實世界中的任務往往具有高度不確定性。以分析標普500成分股為例，任務邊界本身就在動態變化：是否需要關注咖啡豆期貨市場？是否需要引入新的專業分析智能體？

在開放協作環境中，智能體的來源和穩定性也難以保障——今天接入的第三方智能體，明天可能就無法使用。

更復雜的是，不同廠商的智能體可能具有相互沖突的目標函數。當多個第三方智能體都能提供市場分析服務時，如何選擇合適的協作對象？

系統中甚至存在博弈關系：某些智能體可能在特定領域與本方利益存在沖突，這就要求我們必須謹慎控制信息共享的范圍。

在這樣充滿不確定性的開放環境中，傳統的工作流工程方法面臨根本性挑戰：智能體成員不固定，使得預設工作流變得不可能；外部環境持續變化，今天的市場條件明天就可能失效。

事實上，現實世界中越來越多的任務——無論是企業級應用還是其他領域——都呈現出這樣的特征，迫使我們不得不直面這些挑戰。

• 首先，任務邊界變得模糊不清。以近期備受關注的"AI科學家"為例，不同的研究思路會導致完全不同的研究路徑：實驗設計、評估方法甚至論文發表方式都可能形成不同的體系。在這種情況下，試圖通過預先定義的固定工作流來適應各種研究想法，幾乎是不可能完成的任務。

• 其次，生態系統的高度復雜性帶來新的難題。以高盛集團的金融分析為例，其基金管理業務可能需要接入多個第三方提供的專業分析智能體。未來，這種由多方提供的智能體系統將越來越普遍——在一個多智能體系統中，外部開發的智能體可能占據半壁江山。這些智能體可能使用不同的通信協議：有的基于自然語言，有的則采用其他專用協議。

• 此外，外部環境始終處于快速變化中。即使保持相同的智能體配置，市場環境也可能從高度競爭轉為相對緩和，或是出現某個智能體突然失效的情況。系統必須能夠在不停機的情況下實現無縫切換，及時找到替代的智能體或解決方案。

正是這些現實需求，推動著我們不得不深入探索開放世界中的協同合作機制，要從傳統的 Workflow Engineering 轉向 Ecosystem Engineering。

重點不再是如何設計固定流程，而是如何構建一個具有自適應能力的多智能體生態系統。這包括建立有效的激勵機制吸引優質智能體參與，設計沖突協調機制化解目標矛盾，最終打造一個能夠自主演化、持續優化的開放協作體系。

總體而言，開放世界中的智能體數量可能呈現爆發式增長，而成員的頻繁進出更帶來了極高的不確定性。這導致兩個核心難題：一是難以建立有效的評估體系，二是在高度不確定的環境中如何確保整體系統始終維持在可用的性能水平。這些問題都需要我們持續探索和解決。

面對這些挑戰，Raphael Shu 和團隊給出了一個答案，正是開源項目 OpenAgents——一個聚焦網絡層，或者說協作層的多智能體框架，目標是讓 100-500 個 Agent 在開放世界中高效協作。

OpenAgents 的架構同樣分為四層：

• 協議層：兼容 HTTP、WebSocket、gRPC 等多種協議，無論 Agent 來自瀏覽器還是服務器，都能快速接入；

• 拓撲層：支持多樣化網絡拓撲管理，比如“星型結構”（一個中心 Agent 統籌）、“網狀結構”（Agent 自由交互），靈活適配不同場景需求；

• 插件層：提供豐富協作場景模板，包括“聯合寫文檔”“會議反思”“維護 Wikipedia”，甚至支持 Agent 組隊玩 Minecraft，避免無意義閑聊，聚焦有效協作；

• 智能代理層：支持AI分身或人類肉身接入，任何人通過Studio客戶端就能成為生態中的一個 Agent，清晰掌握生態規則、可用工具和協作對象。

OpenAgents 不是要做一個超級 Agent，而是要構建一個Agent 社區。這些 Agent 會 24 小時在線，擁有自己的時間表——閑置時自動查資料學習，完成任務后開短會反思優化，甚至能通過社交結交 Agent朋友。

比如在金融生態中，有的 Agent 負責爬取數據，有的負責分析建模，有的負責生成報告，它們會自動協作，還能根據市場變化動態調整分工。

正如 Raphael Shu 在演講中表達的，單個智能體再強，也有上限；真正的潛力，藏在群體智能里。

而我們現在熟悉的，無論是 LangGraph 還是 AutoGen，大多還是在解決封閉場景里的協作問題。任務、環境、伙伴都是預設好的。但現實世界是混亂、開放和動態的。當你需要讓幾十上百個來自不同地方、遵循不同協議的智能體一起完成一個模糊的目標時，挑戰就完全不一樣了。

這不再是簡單的Workflow Engineering，而是更接近Ecosystem Engineering。你需要考慮服務發現、通信協議、資源競爭、甚至安全問題——這聽起來是不是特別像我們早年構建分布式系統時遇到的難題？只不過節點從服務器變成了 AI 智能體。

所以，OpenAgents 想做的，其實就是成為這個開放世界的基礎設施。 它不生產智能體，而是致力于成為智能體之間的“社交網絡”和“協作平臺”，讓它們能自主、安全、高效地一起干活。

這條路顯然剛起步，充滿了未知的技術挑戰。

如果你也對如何構建大規模、開放的多智能體系統感興趣，不妨關注開源項目 OpenAgents：

https://github.com/openagents-org/openagents

• 官網：https://openagents.org
  

• Discord：https://discord.gg/openagents

這或許是通向下一代 AI 應用架構的關鍵一步。

評論區留言“OpenAgents 演講 PPT”，即可獲取完整演講資料～

添加微信，進交流群

Agent Networks

OpenAgents：開放協作的 AI 智能體網絡