多智能体系统 (Multi-Agent System)

多智能体系统

Multi-Agent System

范叶亮 / 2026-06-20

分类: AI / 字数: 5299 / 标签: 人工智能, AI, 单智能体, Single Agent, ReAct, 多智能体, Multi Agent, 分布式智能体, Distributed Agent

在单智能体中，ReAct 框架 1 作为当前智能体的一个核心设计模式，其通过 Reasoning（推理）和 Acting（行动）两个模块实现了大语言模型推理能力与外部环境交互能力的深度协同。ReAct 框架的整体执行过程如下图所示：

在之前的博客中有介绍 ReAct 框架的主要特点，在上图中可以将流程划分为三个阶段：

该步骤会创建一个上下文，其中除了包含用户的输入以外还会包含系统提示词、可用的工具列表等其他信息。

循环迭代是 ReAct 框架的核心步骤，该步骤实现了在真实世界中人类解决问题的行为模式。

当模型判断已获得最终答案后，会停止循环迭代并将结果输出给用户。除此之外也会存在异常输出的情况，例如：循环迭代达到最大限制次数，工具调用超时或返回错误等等。

我们以 Hotpot QA 数据集中的一个问题为例，对比其他方法展示 ReAct 框架是如何解决问题的。

当单智能体配置的工具过多导致难以正确决策，或任务需要庞大的专业领域知识，抑或需要施加特定的顺序约束时，单智能体往往力不从心，此时多智能体架构成为更优的选择 2。归纳来看，引入多智能体主要是为了获得以下三方面能力：

多智能体并非银弹。Anthropic 的研究 3 表明，以 Claude Opus 4 作为主智能体、Claude Sonnet 4 作为子智能体的多智能体系统，在其内部研究类评测中比单体 Claude Opus 4 高出 90.2%，关键在于多个子智能体各自拥有独立的上下文窗口，从而实现了单智能体难以企及的并行推理。但同时也应注意，单智能体更易于构建、推理和调试，应当优先从单智能体加良好的提示词与工具设计开始，只有在确实触及瓶颈时再引入多智能体。

根据 LangGraph v0.x 版本文档（已过时）4，其将多智能体模型划分为：网络模式（Network）、监督模式（Supervisor）、工具化监督模式（Supervisor as Tools）、层级模式（Hierarchical）和自定义模式（Custom Workflow）。

不同类型的多智能体模型的特点和差异如下：

整体而言，没有最好的模式只有最适合的模式。在搭建多智能体系统时，需要根据实际的业务场景选择最合适的多智能体模式。

根据 LangChain v1.x 版本文档 5，其将多智能体模型划分为：子智能体模式（Subagents）、传递模式（Handoffs）、技能模式（Skills）、路由模式（Router）和自定义模式（Custom Workflow）。

类似上文中的监督模式。主智能体以工具方式调用子智能体对其进行协调，主智能体决定调用哪个子智能体、提供什么输入以及如何组合结果。子智能体是无状态的，所有记忆由主智能体维护。该模式的主要特点如下：

当存在多个独立的场景（例如：日程、电子邮件、数据库等）时，子智能体无须同用户直接交互或者你希望通过统一流程进行控制，适合使用该模式。

该模式下专业能力被打包成可调用的“技能”（Skill），用于增强智能体的行为能力。技能由专业化的提示词构成，智能体可以按需调用。该模式的主要特点如下：

当你希望单个智能体具有多种专业化，无须在技能之间施加强制约束，或者不同团队需要独立开发能力时，适合使用该模式。

注意

技能模式在技术上仍然只使用单个智能体，LangChain 官方将其称为“准多智能体架构”。它通过让单个智能体动态切换专业化人格，获得了与多智能体类似的分布式开发与细粒度上下文控制能力，但采用的是更轻量的、提示词驱动的方式，而非真正管理多个智能体实例。

该模式下，路由会对输入进行分类，并将其重定向至专门的智能体。该模式的主要特点如下：

当你拥有多个垂直领域（每个领域需要独立的智能体），需要并行查询多个数据源，同时希望将结果汇总成一个统一的响应时，适合使用该模式。

路由模式 v.s. 子智能体模式

子智能体模式中的主智能体是一个完整的智能体，用来维护对话的上下文，并动态地决定在多轮中调用哪些子智能体。路由模式中的路由只是一个分类步骤，它将任务分派给各个智能体，其并不维护持续的对话状态。不过路由也可以被包装成一个工具，嵌入到一个有状态的会话智能体中，从而在保留分类与并行分发能力的同时，弥补其不维护对话历史的不足。

类似上文中的网络模式。该模式下，行为会根据状态动态变化。其核心机制是工具更新一个可跨多轮的状态变量，系统通过该状态变量来调整行为（例如：应用不同的提示词和工具，或将用户路由到不同的智能体）。该模式的主要特点如下：

当你希望依据强制约束进行执行，智能体需要跨不同状态同用户直接沟通，或者构建多阶段对话流程时，适合使用该模式。该模式在客户支持场景中尤其适用，因为在该场景下需要根据特定顺序收集信息，例如在发起退款之前收集订单 ID。

注意

传递模式只能顺序执行，无法并行处理。在需要同时咨询多个领域的场景下，它无法利用并行工具调用，往往需要更多的模型调用次数，效率较低。

类似上文中的自定义模式。该模式下，你可以自定义执行流程，包括顺序执行、条件分支、循环和并行执行等。该模式的主要特点如下：

当上述模式无法满足需求，需要将确定性逻辑与智能体行为相结合，或者场景需要复杂的路由或多阶段处理时，适合使用该模式。

从分布式开发、并行化、多跳调用（Multi-hop，即串行调用多个子智能体）以及用户直接交互四个维度来看，不同模式各有侧重：

不同模式在模型调用次数和 token 消耗上存在明显差异。以下以三个典型场景为例：

从中可以总结出几点规律：

最后需要强调的是，上述模式并非互斥，而是可以相互组合的。例如子智能体模式内部可以调用路由模式或自定义模式，子智能体本身也可以借助技能模式按需加载上下文。更多智能体架构的对比讨论和选择请参考 LangChain 官方博客。

OpenClaw 采用的是子智能体模式 6 7，在 OpenClaw 中“一个智能体”拥有自己的：

凭证配置是按智能体划分的，每个智能体都会从自己的位置读取。子智能体是由一个现有的智能体派生出来的，其在独立的会话（agent:<agentId>:subagent:<uuid>）中运行。

Hermes Agent 采用的是路由模式 8 9，在 Hermes Agent 中“一个智能体”定义为一个档案（Profile）。每个 Profile 拥有自己的目录，其中包含各自的 config.yaml、.env、SOUL.md、记忆、会话、技能、Cron 任务和状态数据库。

QwenPaw 通过一个内置的 多智能体协作（Multi-Agent Collaboration） 技能实现智能体之间的通信和协作 10，个人理解类似路由模式。每个智能体拥有自己的工作区，包括 AGENTS.md、SOUL.md、工具、技能、对话历史、定时任务等。

除了与不同工作区的其他智能体协作外，QwenPaw 还支持在当前项目内派发临时子任务。

通过 spawn_subagent 派发的子智能体不可恢复，子智能体使用相同的配置（例如：人格、工具等），只是在独立的会话中运行。

以上讨论的都是在相同服务下的单智能体和多智能体实现，当我们需要让不同来源和实现的智能体之间进行协同时则需要构建一个分布式智能体系统。在分布式智能体中，每个智能体具备局部感知、自主规划与执行能力，并能跨节点交互，突破了单一系统在算力、扩展性和功能上的限制。分布式智能体具有如下特点：

在分布式智能体之间进行通信和协作需要统一的标准，A2A 协议 11 是由 Google 贡献，当前已加入 Linux 基金会的一个开放标准，它实现了智能体之间的无缝通信和协作。它为使用不同框架和由不同供应商构建的智能体提供了一种通用语言，从而促进了互操作性并打破了信息孤岛。不同于 MCP 协议解决的是智能体与工具、资源之间的协同问题，A2A 协议解决的是智能体与智能体之间的协同问题，两者之间的区别如下图所示：

虽然分布式智能体可以在横向扩展（更多实例，解决吞吐和并发问题）和纵向扩展（更多类型，解决合作和协同问题）上具有优势，但当前其仍面临诸多挑战 12，例如：