调研时间：2025 年夏天

Multi-agent

大模型的上下文窗口和推理能力是有限的。当一个agent 接入了太多的工具，或者指令变得异常复杂时，它在每一步决策时的可能组合就会变得非常多。这会导致智能体更容易产生困惑、行为变得不可预测、更容易出现幻觉。

比如任务需要很多不同的专业知识领域，或者需要管理的工具数量过多时，就应转向多智能体。

多智能体系统的核心优势在于，通过将一个庞大而复杂的任务分解给多个更小、更专注的智能体，每个智能体都只需要关心自己负责的领域。这使得单个智能体更容易被开发、验证、测试和优化。同时，这些高度模块化的智能体也更易于被组合，以支持更动态、更灵活的工作流。

open AI 的两种框架：

主管模式 (Manager Pattern)：

这是一种层级化的、中心化的编排模式。系统中存在一个“主管”（Manager）或“编排者”（Orchestrator）智能体，它负责理解任务的总体目标，并将其分解为多个子任务。然后，它像一个项目经理一样，将这些子任务“委派”给多个专门的“下属”（Worker）智能体去执行。这些下属智能体对于主管来说，就是其可以调用的“工具”。主管会调用下属智能体，等待它们返回结果，最后将所有结果综合起来，形成最终的解决方案。

去中心化模式 (Decentralized Pattern)：

这是一种点对点的、分布式的编排模式。系统中没有一个中心化的主管。取而代之的是，一群对等（Peer）的智能体，它们各自拥有独特的专长，并且“知道”彼此的存在和能力。在这种模式下，工作流的控制权可以在智能体之间进行“传递”或“交接”。当一个智能体判断当前任务的后续步骤超出了自己的能力范围，但正好是另一个智能体的专长时，它就会将整个工作流的控制权以及所有必要的上下文信息，移交给那个更合适的智能体，然后自己则终止运行。一个经典的例子是：一个“客户接待”智能体负责初步 triage。当它判断出用户的请求是一个复杂的技术支持问题时，它就会将整个对话无缝地移交给一个“技术支持”智能体来继续处理。

这两种编排模式实际上是现实世界中人类组织结构的镜像。

• 主管模式类似于一个经典的项目团队：项目经理（主管智能体）不亲自编写代码或进行设计，而是协调和集成不同专家（下属智能体）的工作成果。这种模式非常适合那些可以被并行处理，或需要综合多种不同信息才能完成的任务。

• 去中心化模式则更像一条工厂的流水线，或者企业内部的部门间工作交接流程：销售部门（接待智能体）完成客户资格审查后，将整个案子完整地移交给实施部门（专家智能体）。这种模式最适合那些线性的、由不同阶段的专家序贯处理的流程。

LangChain 的两个框架

Supervisor（类似于主管模式）

LangGraph Multi-Agent Supervisor以下简称 Supervisor 框架，是由 LangChain 开源团队在2025年初推出的多智能体系统方案，其特色是层次化的智能体架构 (GitHub - langchain-ai/langgraph-supervisor-py)。在该框架中，一个中央监督者智能体（Supervisor Agent）负责调度和管理多个专业子智能体，形成树状的控制结构。Supervisor 决定何时将任务委派给哪个子智能体，并统筹整个对话或任务流程。

核心思想是将复杂任务的解决过程按照职责拆分给不同“专家”智能体，但所有沟通都通过监督者进行集中管理 (GitHub - langchain-ai/langgraph-supervisor-py)。这种模式类似现实中的团队：主管负责分配任务、汇总结果，各团队成员各司其职，最终由主管给出结论。

核心概念和设计哲学

Supervisor 框架背后的理念是集中式的协调和模块化的专业分工。其核心要素包括：

• Supervisor（监督者智能体）：处于架构顶层，负责决策和调度。Supervisor 接收用户的输入，在理解任务后决定调用哪一个下属智能体来处理 (GitHub - langchain-ai/langgraph-supervisor-py)。监督者掌控着对话的走向，起到“大脑”作用。

• Specialized Agents（专业智能体）：一组具备特定技能或工具的子智能体，例如擅长数学计算的智能体、掌握知识检索的智能体、精于写作总结的智能体等。它们由Supervisor创建或注册，并不会直接与用户对话，而是在被Supervisor调用时才参与工作 (GitHub - langchain-ai/langgraph-supervisor-py)。

• Handoff Mechanism（交接机制）：Supervisor与子智能体之间通过一种工具式的调用进行通信。这实际上也是一种“Handoff”，但与OpenAI Agents SDK中由LLM自主发起交接不同，这里的交接由 Supervisor 的逻辑主导 (GitHub - langchain-ai/langgraph-supervisor-py)。Supervisor 可以将用户的问题封装为调用子智能体的工具请求，子智能体执行完毕后将结果反馈给Supervisor，再由Supervisor决定下一步 (GitHub - langchain-ai/langgraph-supervisor-py) (GitHub - langchain-ai/langgraph-supervisor-py)。

• Message History Management（消息历史管理）：Supervisor框架允许灵活控制对话历史如何在智能体之间传递 (GitHub - langchain-ai/langgraph-supervisor-py) (GitHub - langchain-ai/langgraph-supervisor-py)。开发者可以设定是在全局共享完整历史，还是仅提供最新用户消息给子智能体，以避免干扰。这样的设计保证了上下级间的上下文隔离与共享可以按需调整。

Supervisor 框架强调结构清晰和可控性。通过引入一个居中的Supervisor代理，人类可以更容易地追踪多智能体系统的决策过程，因为所有重要决策都出现在Supervisor这一级 (LangGraph Multi-Agent Supervisor: A Comprehensive Guide | by Ankush k Singal | AI Artistry | Medium)。同时，这种集中式结构有助于维护上下文的一致和决策的连贯：Supervisor可以综合来自不同子智能体的信息，再统一地回复用户，从而避免多头输出的混乱。

其设计哲学可以概括为：“中心协调，分工明确”。也就是说，将多智能体系统组织为一个有层次的团队，让每个Agent模块职责单一（单一智能体只关注自己擅长的事），由Supervisor把关整体流程。这种模式在需要上下文敏感的决策和高效任务委派的场景下特别有效 (LangGraph Multi-Agent Supervisor: A Comprehensive Guide | by Ankush k Singal | AI Artistry | Medium) (LangGraph Multi-Agent Supervisor: A Comprehensive Guide | by Ankush k Singal | AI Artistry | Medium)。例如，在一个复杂的问答系统中，Supervisor可以根据问题类型，交由检索Agent查资料，再交由推理Agent分析，最后由自己整合回答，从而既利用了不同Agent的专长又保持了回答风格和语调的一致性。

协作机制与执行流程

在 Supervisor 框架中，所有的协作交互都由中央Supervisor发起。具体来说，当收到用户输入时：

1. 任务分析：Supervisor（由一个LLM驱动）首先根据自己的提示（Prompt）理解用户意图，决定该请求需要哪些步骤或专业能力。开发者通常会为Supervisor设计一个提示，指导它如何在不同情境下选择合适的子智能体。例如：“如果问题涉及计算就调用数学Agent，如果涉及百科知识就调用检索Agent”等 (GitHub - langchain-ai/langgraph-supervisor-py) (GitHub - langchain-ai/langgraph-supervisor-py)。

2. 委派执行：Supervisor 根据策略，从其管理的子智能体列表中选出一个或多个来处理当前任务。协作的基本单位是在LangGraph框架中实现为工具调用：Supervisor把子智能体视作特殊的工具。例如，它可以调用research_agent工具并传入当前的问题，实际效果是激活对应的检索智能体，让其针对问题运行 (GitHub - langchain-ai/langgraph-supervisor-py)。这种调用通过LangGraph底层将控制转移给子智能体并获取其结果。

3. 获取结果与整合：当子智能体完成任务后，会将结果（例如检索到的信息或计算的答案）返回给Supervisor (LangGraph Multi-Agent Supervisor: A Comprehensive Guide | by Ankush k Singal | AI Artistry | Medium)。Supervisor将这个结果纳入自己的对话上下文中。它可以选择继续调用其他智能体处理后续子任务，或者在足够信息齐备时生成对用户的最终回答。

4. 输出响应：**最终由Supervisor产出面向用户的答复。用户看到的只有Supervisor的回答，而不会直接与底层子智能体对话。**整个过程中，对于用户来说就像在跟一个拥有多种能力的助手交流，只是这个助手内部通过Supervisor+多Agent架构完成了复杂任务。

(GitHub - langchain-ai/langgraph-supervisor-py) 上图左侧展示了 Supervisor 框架中添加两个专业智能体（数学Agent和搜索Agent）形成层次结构，右侧则示意了 Supervisor 将用户请求 “交接” 给某个子Agent处理的过程。Supervisor 接收到输入（In）后，通过handoff机制将任务传递给合适的子Agent执行，由该Agent利用LLM产生行动（调用工具）并得到反馈，最后Supervisor获取Agent产出的结果并返回给用户（Out）。这样的一级主管-多工人模式确保了任务流程的井然有序和可控。

值得一提的是，LangGraph Supervisor 框架还支持多级监督：即Supervisor本身也可以管辖一些次级Supervisor，从而形成更深的层次结构 (GitHub - langchain-ai/langgraph-supervisor-py)。这对于非常复杂的场景（比如一个大型项目分成多个小组，每个小组再细分任务）很有用。但一般情况下，**两层（1个Supervisor + N个专家Agent）**已经能覆盖大部分应用需求。

Swarm（去中心化）

LangGraph Multi-Agent Swarm以下简称 Swarm 框架，同样由LangChain团队推出，但与Supervisor的集中式架构不同，Swarm代表了一种去中心化的多智能体协作范式 (GitHub - langchain-ai/langgraph-swarm-py)。在Swarm模式下，没有固定的“老板”智能体；取而代之的是，一组对等的智能体按照需要动态交接控制权，共同推进任务。可以把它类比为一个没有明确领导者的小组，成员会根据任务需求自行决定由谁来处理当前阶段。

核心概念和设计理念

Swarm（字面意思是“蜂群”）在AI多智能体领域通常指群体智能协作的概念。LangGraph的Swarm框架实现了一种自主协商的 Agent 群，其核心思想包括：

• Dynamic Handoff（动态交接）：任何智能体在对话过程中都可以通过一个交接工具（Handoff Tool）将控制权转移给另一个智能体 (GitHub - langchain-ai/langgraph-swarm-py) (GitHub - langchain-ai/langgraph-swarm-py)。这种交接不是预先固定的层次关系，而是由对话上下文和智能体自身的策略决定的 (#aiagents #langchain #langgraph | Syed Muhammad Ali Kazmi)。例如，当当前智能体意识到用户的请求超出自己的知识或权限时，可以调用“交接”函数让另一智能体来回答 (GitHub - langchain-ai/langgraph-swarm-py)。

• Shared State（共享状态）：Swarm 中的所有智能体共享同一个对话状态，包括消息历史和一个标记当前活动智能体的字段 (#aiagents #langchain #langgraph | Syed Muhammad Ali Kazmi) (#aiagents #langchain #langgraph | Syed Muhammad Ali Kazmi)。这意味着无论控制权如何转移，整个系统保有统一的上下文记忆，避免信息丢失。共享状态确保当新的Agent接手时，它能看到之前对话内容（或定制后的内容），从而上下文连续 (#aiagents #langchain #langgraph | Syed Muhammad Ali Kazmi)。

• Active Agent Tracking（活动Agent跟踪）：框架维护一个当前处于激活状态的Agent标识，每次交接会更新该标识 (#aiagents #langchain #langgraph | Syed Muhammad Ali Kazmi) (#aiagents #langchain #langgraph | Syed Muhammad Ali Kazmi)。当用户有新的输入时，系统会默认将消息发送给上次回答的智能体处理，除非出现新的交接。这有点像对话中的“话题持有者”，保证多轮对话时不会每次都从头分配Agent，而是由上次互动的Agent继续 (GitHub - langchain-ai/langgraph-swarm-py) (GitHub - langchain-ai/langgraph-swarm-py)。

• Peer Autonomy（对等自主）：Swarm假定所有Agent地位平等，没有一个主导Agent。它们都可以自主决定下一步要做什么，包括是否交给他人。Swarm强调灵活协作而非预先规划的流程 (#aiagents #langchain #langgraph | Syed Muhammad Ali Kazmi) (#aiagents #langchain #langgraph | Syed Muhammad Ali Kazmi)。这种理念类似现实团队中根据情境动态决策谁来领衔：例如在讨论中某个成员发现另一个成员更有发言权，就让贤把话题交给对方。

Swarm 设计的哲学可概括为：“涌现式协作，灵活分工”。没有固定剧本，各智能体基于自身能力和当前对话内容做出本地决策，整体协作模式是在交互过程中涌现出来的 (#aiagents #langchain #langgraph | Syed Muhammad Ali Kazmi) (#aiagents #langchain #langgraph | Syed Muhammad Ali Kazmi)。这要求每个Agent都有适当的提示，让它知道自己擅长什么、什么时候该把问题转交他人。例如，一个Swarm团队可能有A擅长数学、B擅长语言，两者的提示都会写明“如果你觉得请求涉及数学运算而你无法解决，可以调用交接给A（或B）”。这样，每个Agent能自我评估并在需要时触发交接。

协作机制与运行流程

Swarm 框架的运行有点类似于一场“接力赛”或者“对话圆桌会议”。初始时会指定哪个Agent优先处理用户请求，然后根据内容可能在多个Agent间辗转，直到任务完成。具体步骤：

1. 初始Agent：开发者需要选择一个默认的Agent来先响应用户（通常在create_swarm时指定default_active_agent） (GitHub - langchain-ai/langgraph-swarm-py)。例如默认让Alice先回答。

2. 处理或交接：当用户输入到来时，当前活动的Agent（例如Alice）基于其提示和能力尝试处理。如果它可以回答，则直接给出答复（这时Swarm流程对用户来说就跟单Agent无异）；如果它判断需要其他Agent帮助，则会调用交接工具将控制权交给目标Agent（如Bob） (GitHub - langchain-ai/langgraph-swarm-py)。交接通过Swarm的create_handoff_tool实现，Agent在LLM思考时把它当作一个可调用的函数。当LLM选择调用该“函数”时，Swarm框架就会把对话状态切换到目标Agent，并在其上下文中注入必要信息。

3. 下一个Agent响应：被交接到的Agent（Bob）现在成为活动Agent，它收到最新的对话状态（通常包含用户请求及前一步Agent的交接指令），然后继续回复用户或进一步交接。如果再次交接，就重复步骤2；若提供了最终答复，则该回合结束。

4. 多轮对话：Swarm框架会记住当前活动Agent为Bob。如果用户接着又问了一个新问题（新的对话轮次），那么Bob会作为默认Agent来先处理 (#aiagents #langchain #langgraph | Syed Muhammad Ali Kazmi)。除非这个新问题应该由Alice处理，此时Bob可以再交接回Alice。如此，Swarm在多轮对话中支持上下文连贯：用户不需要每次指明希望哪个Agent回答，系统会沿用最近的角色，除非内容触发了交接。

(GitHub - langchain-ai/langgraph-swarm-py) 上图形象地展示了 Swarm 模式下多智能体在对话中的动态协作示例。左侧是用户与系统的对话时间线，右侧描绘了两个Agent（飞行预订Agent和酒店预订Agent）如何根据对话内容交替成为主动方。在开始时，“订机票”的请求由航班Agent处理；当用户提出“订酒店”时，航班Agent通过交接工具将控制权转交给酒店Agent（如图中粉色对话框最后一条 Handoff tool 所示），随后酒店Agent开始响应后续的酒店预订请求。这种机制确保了对话流程顺畅衔接：用户感觉像在和一个综合助手交流，而实际上不同专长的Agent在背后动态接棒 (#aiagents #langchain #langgraph | Syed Muhammad Ali Kazmi) (#aiagents #langchain #langgraph | Syed Muhammad Ali Kazmi)。

与Supervisor不同的是，Swarm里每个Agent都可能既是“请求处理者”又是“请求转交者”。没有一个全局的大脑来指挥，一切决策都由Agent各自做出。因此Swarm对Agent提示设计要求较高，需要明确规定各Agent什么时候该把问题交出去，交给谁。在LangGraph Swarm实现中，这通常通过create_handoff_tool(agent_name=...)配置交接目标，以及Agent自身的prompt来实现 (GitHub - langchain-ai/langgraph-swarm-py) (GitHub - langchain-ai/langgraph-swarm-py)。例如，在代码示例中，Alice的工具列表包含create_handoff_tool(agent_name=\&\#34;Bob\&\#34;)，Bob的工具列表包含相应的交接回Alice的工具 (GitHub - langchain-ai/langgraph-swarm-py) (GitHub - langchain-ai/langgraph-swarm-py)。这相当于告诉Alice：“你可以把任务交给Bob”；告诉Bob：“你可以交还给Alice”。

导演编排发言顺序

框架对比

框架	优点	缺点	适合场景
中心化	集中决策，行为可解释 模块化设计，扩展方便 生态集成	单点瓶颈 不够灵活 实现成本	客服问答系统（根据问题类型转交不同专家） 多步骤研究（检索-分析-报告流程） 复杂内容生成（不同Agent负责结构、措辞、校对）等需要明确任务边界和流程控制的应用
去中心化	灵活协作：没有固定流程，智能体能根据对话实时做决定 平行专家团队 扩展对话连续性，适用于连续对话场景 实现相对简单：相比Supervisor需要设计复杂的调度Prompt，Swarm每个Agent关注自身能力边界即可。	决策不确定性：更难预测和控制，容易死循环 不适合严格流程 上下文窗口占用 实现心智模型复杂	对话式助理（要求能应对各种话题并自动调用合适能力） 多模态交互（不同Agent处理文字、图像、语音等不同模态，然后协作） 复杂任务的探索式解决

产品例子

metaGPT x MGX

https://mgx.dev/

不是一个简单的 AI 助手，而是一个完整的 AI 开发团队，包含产品经理、架构师、工程师和数据分析师等多个角色。

• Mike（团队领导）：统筹全局，管理团队协作

• Emma（产品经理）：负责需求分析和产品规划

• Bob（架构师）：设计系统架构和技术方案

• Alex（工程师）：负责具体代码实现

• David（数据分析师）：处理数据分析相关工作

ChatDev

https://zhuanlan.zhihu.com/p/654459772

ChatDev 借鉴软件工程瀑布模型的思想，将其分为软件设计（Designing）、系统开发（Coding）、集成测试（Testing）、文档编制（Documenting）四个主要环节。之后，通过对软件开发瀑布模型的进一步分解，形成由原子任务构成的交流链（Chat Chain）。整条链可视为由原子任务组成的“软件生产线”，链中每个子任务通过专业角色（例如产品设计官、Python 程序员、测试工程师等）的智能体进行对话式信息交互和决策；驱动其进行自动化需求分析、头脑风暴、系统开发、集成测试、GUI 创作、文档编制等全流程软件工程。

BMAD-METHOD-去中心化

https://github.com/bmadcode/BMAD-METHOD

atypica.ai-中心化

https://atypica.ai/