我们对于 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 全球开源技术峰会上，以《开放世界中的多智能体协作》为题，梳理了多智能体系统从理论奠基到开放生态的技术演进路径。
以下内容根据其演讲整理。
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 直接 “听懂” 并响应，系统落地速度从 “按月算” 压缩至 “按天算”。
Magentic One：企业应用多智能体系统的标配
微软的 Magentic One，是异步多智能体系统的代表，历经多版迭代，已成为北美企业级多智能体系统的 “标配”。
Magentic One 采用中心化架构，其核心是一个主协调智能体（Orchestrator），负责统筹任务，并调度四个功能专一的子智能体（Sub Agent），分别负责文件管理、网页浏览、编码、命令执行。
具体而言，Magentic One 是如何运作的呢？
比如，当用户向系统提交一个 “分析标普 500 的趋势” 的任务时，整个流程将由一个 Orchestrator 主导，并进入一个核心循环：
- 任务监控：Orchestrator 持续监控和评估当前任务的完成状态。
- 任务分解与分配：只要任务未被判定为完成，Orchestrator 就会将任务或子任务分配给一个合适的 Sub Agent（子智能体） 去执行。
- 结果汇总：当所有子任务完成，Orchestrator 会收集结果，并向用户反馈一个最终的 Summary（总结）。
可以看到，Magentic One 是一个很经典的中心化架构。在该架构中，Orchestrator 同时充当了任务的发起者与最终决策者，能够将一个复杂任务进行分解，并分配给专门化的子智能体进行并行处理，从而实现高效的问题解决。
不过，值得注意的是，并非所有多智能体系统都采用这种中心化决策模式。例如，在某些场景下（如投票机制），即使由 Orchestrator 发起任务，最终决策也可能通过去中心化的投票方式产生。
基于对微软、AWS 等标普 500 企业案例的深度拆解，异步多智能体系统通常包含四层架构：
- 调度层：无 LLM 依赖，仅负责系统基础运转 —— 比如给 Orchestrator 生成的指令排期、处理 “文件写入” 等新事件，相当于多智能体的 “行政管家”；
- Orchestrator 层：核心决策层，仅聚焦两大核心：一是 “规划”（生成 To-Do List 或基于知识图谱的 DAG 图），二是 “追踪”（监控任务进度，判断下一步动作）；
- 记忆层：存储任务状态（已完成 / 未完成）、新消息、Agent 间共享缓存，如同多智能体的 “共享大脑”，保障异步协作的状态同步；
- Agent Pool 层：执行层，由各类专项 Agent 组成（如数据处理 Agent、报告生成 Agent），接收 Orchestrator 指令后直接落地执行。
单智能体的能力局限
看到这里，相信很多人都会疑惑，对于撰写分析报告这样的任务，单智能体的能力已经足够强了，基本能够解决。为什么还要多智能体协作呢？
一方面，单智能体存在三大局限。
- 上下文限制：一个智能体的处理能力有限，很难同时兼顾复杂任务的不同方面。比如，一个任务可能需要它先做规划，再去执行（如分析网页、点击按钮），最后还要进行评估。这需要智能体在不同思维模式间频繁切换，很容易达到其能力上限，导致整体表现不佳。
- 效率低下：当把所有任务都塞给一个智能体时，它可能会在某个局部问题上钻牛角尖，花费过多时间，从而忽略了整体目标。举个例子：这就像用 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 项目就属于这一层，它建立在协议层之上，专注于解决大规模（如数百至数千个）智能体之间的跨协议协作问题。
从 “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，这或许是通向下一代 AI 应用架构的关键一步。
- GitHub：github.com/openagents-…
- 官网：openagents.org
- Discord：discord.gg/openagents
- 进群交流加小助手：19323993004
