一、引言

在 Agent 系统的构建过程中，随着系统演进，其复杂度往往持续攀升，进而显著增加管理与扩展的难度。典型挑战包括：

工具调用数量激增‌，致使选择机制的错误率显著上升；

上下文信息高度膨胀‌，单个代理已难以有效处理；

系统需协同多个专业角色‌（如规划师、研究员、数学专家等）以完成任务。

针对上述瓶颈，一种可行路径是将单一智能体解构为若干轻量级、独立的子代理，并通过协同机制构建多智能体架构。

这些子代理的复杂度可灵活配置——既可简化为基础的提示词与 LLM 调用，亦可延伸至 ReAct 代理级别（甚至超越其复杂度！）。

最近两年，大家都可以看到AI的发展有多快，我国超10亿参数的大模型，在短短一年之内，已经超过了100个，现在还在不断的发掘中，时代在瞬息万变，我们又为何不给自己多一个选择，多一个出路，多一个可能呢？

与其在传统行业里停滞不前，不如尝试一下新兴行业，而AI大模型恰恰是这两年的大风口，整体AI领域2025年预计缺口1000万人，其中算法、工程应用类人才需求最为紧迫！

学习AI大模型是一项系统工程，需要时间和持续的努力。但随着技术的发展和在线资源的丰富，零基础的小白也有很好的机会逐步学习和掌握。【点击蓝字获取】

【2025最新】AI大模型全套学习籽料（可白嫖）：LLM面试题+AI大模型学习路线+大模型PDF书籍+640套AI大模型报告等等，从入门到进阶再到精通，超全面存下吧！

随着智能体框架的持续演进，越来越多企业着手构建专属的多智能体系统，力图打造一种可通解各类智能体任务的终极方案。早在两年前，研究团队便推出了一款名为 ChatDev 的多智能体协作架构。

该系统宛如一家全虚拟的软件企业，由多个功能各异的智能体协同运转——它们分别担纲首席执行官、首席产品官、美术设计师、程序员、审校员、测试员等职位，其组织形态与现实中的软件工程公司如出一辙。

这些智能体通过协同运作与持续沟通，最终合力打造出一款电子游戏。这一成果促使诸多人坚信，任何软件工程任务皆可借助此类多智能体架构实现——每个AI均承担专属职能。

然而，现实世界的实践验证显示，并非所有问题都适配这种架构。在部分场景下，更为简洁的系统设计反而能带来更高效率与更低成本的解决方案。

1.1 单智能体架构与多智能体架构

单智能体方案在初期往往显得切实可行（例如，单一智能体即可统筹浏览器浏览与文件管理等全部操作）。然而，当任务复杂度持续攀升、可用工具数量不断膨胀时，这种单一架构便逐渐力不从心。

二、Multi-agent架构

单智能体架构与多智能体架构各具优势与局限。在任务清晰、边界明确且资源充裕的场景下，单智能体架构最为适配；而在面对复杂多变的用例、亟需专业分工与协同配合，或对系统可扩展性与动态适应性提出更高要求时，多智能体架构则展现出更强的适用性。

2.1 Multi-agent系统中的模式

在多智能体系统中，连接各个智能体有多种方法：

2.1.1 并行

多个智能体同时处理任务的不同部分。

例如： 我们希望使用 3 个代理同时对给定文本进行总结 、 翻译和情感分析 。

2.1.2 顺序

任务按顺序处理，一个代理的输出成为下一个代理的输入。

例如： 多步骤审批。

2.1.3 循环

智能体以迭代循环的方式运行，根据其他智能体的反馈不断改进其输出。

例如： 评估用例，如代码编写和代码测试。

2.1.4 路由器

中央路由器根据任务或输入确定要调用哪个代理。

示例： 客户支持工单路由

2.1.5 聚合器（或合成器）

收集各个智能体的贡献输出，并综合这些输出，形成最终结果。

例如： 社交媒体情感分析聚合器

2.1.6 网络（或水平）

智能体之间以多对多的方式直接通信，形成去中心化网络。

这种架构专为缺乏明确代理层级或固定调用序列的场景而设计。

优点‌：依托分布式协作与群体驱动的决策机制，即便部分智能体发生失效，整体系统仍可维持稳定运行。

缺点‌：智能体间通信的协调难度显著提升，高频交互易引发效率损耗，并可能造成任务冗余与重复执行。

2.1.7 交接

在多智能体架构中，智能体可被建模为图中的节点。每个节点完成自身的任务后，自主判断是终止执行，还是将控制权转发至其他智能体——包括自身（如形成循环流程）。

其中，‌交接‌是多智能体系统中典型的交互范式，指一个智能体将执行主导权转移给另一个智能体。通过交接，可明确配置：

目标‌：待转向的目标智能体（如目标节点的标识）；

有效载荷‌：需传递至目标智能体的上下文数据（如状态变更信息）。

为了在 LangGraph 中实现切换，agent节点可以返回 Command 对象，该对象允许您将控制流和状态更新结合起来：

def agent(state) -> Command[Literal["agent", "another_agent"]]:
    # the condition for routing/halting can be anything, e.g. LLM tool call / structured output, etc.
    goto = get_next_agent(...)  # 'agent' / 'another_agent'
    return Command(
        # Specify which agent to call next
        goto=goto,
        # Update the graph state
        update={"my_state_key": "my_state_value"}
    )

在更复杂的架构中，若每个 agent 节点自身构成一个子图，则子图内部的节点可能需跨代理边界进行导航。

以 alice 与 bob 为例（二者均为父图中的子图节点），当 alice 需访问 bob 时，可通过在 Command 对象中指定 graph=Command.PARENT 来实现该跨图跳转。

如果您需要支持使用 Command(graph=Command.PARENT) 进行通信的子图的可视化，则需要将它们包装在带有 Command 注解的节点函数中，例如，而不是这样：

交接作为一种工具

最常见的agent类型之一是 ReAct 风格的工具调用agent。对于这类agent，常见的模式是将交接操作封装在工具调用中，例如：

这是工具更新图状态中的一种特殊情形，不仅涉及状态的变更，还嵌入了控制流逻辑。

若你的工具会返回 Command 对象，可选用预构建的 create_react_agent / ToolNode 组件，亦可自行构建工具执行节点——该节点负责聚合工具返回的 Command 实例，并输出一个包含这些对象的列表，例如：

def call_tools(state):
    ...
    commands = [tools_by_name[tool_call["name"]].invoke(tool_call) for tool_call in tool_calls]
    return commands

现在让我们仔细看看不同的多智能体架构。

2.1.8 主管

在这个架构中，‌agents‌ 被建模为节点，同时引入一个‌LLM‌监管节点，负责判定下一阶段应激活的‌agents‌节点。

通过‌Command‌机制，依据该监管节点的指令，将执行流精准路由至目标‌agents‌节点。此设计天然支持‌agents‌的并行执行，亦可高效适配‌MapReduce‌模式。

from typing import Literal
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, MessagesState, START, END
model = ChatOpenAI()
def supervisor(state: MessagesState) -> Command[Literal["agent_1", "agent_2", END]]:
    # you can pass relevant parts of the state to the LLM (e.g., state["messages"])
    # to determine which agent to call next. a common pattern is to call the model
    # with a structured output (e.g. force it to return an output with a "next_agent" field)
    response = model.invoke(...)
    # route to one of the agents or exit based on the supervisor's decision
    # if the supervisor returns "__end__", the graph will finish execution
    return Command(goto=response["next_agent"])
def agent_1(state: MessagesState) -> Command[Literal["supervisor"]]:
    # you can pass relevant parts of the state to the LLM (e.g., state["messages"])
    # and add any additional logic (different models, custom prompts, structured output, etc.)
    response = model.invoke(...)
    return Command(
        goto="supervisor",
        update={"messages": [response]},
    )
def agent_2(state: MessagesState) -> Command[Literal["supervisor"]]:
    response = model.invoke(...)
    return Command(
        goto="supervisor",
        update={"messages": [response]},
    )
builder = StateGraph(MessagesState)
builder.add_node(supervisor)
builder.add_node(agent_1)
builder.add_node(agent_2)
builder.add_edge(START, "supervisor")
supervisor = builder.compile()

2.1.9 主管（工具调用）

在这种监管架构下，我们把各个智能体视为工具，并在监管节点中部署具备工具调用能力的 LLM。

该架构可构建为一个 ReAct 风格的代理，由两个核心节点组成：一个 LLM 节点（即监管节点）与一个负责工具调用的执行节点（本例中为代理）。

from typing import Annotated
from langchain_openai import ChatOpenAI
from langgraph.prebuilt import InjectedState, create_react_agent
model = ChatOpenAI()
# this is the agent function that will be called as tool
# notice that you can pass the state to the tool via InjectedState annotation
def agent_1(state: Annotated[dict, InjectedState]):
    # you can pass relevant parts of the state to the LLM (e.g., state["messages"])
    # and add any additional logic (different models, custom prompts, structured output, etc.)
    response = model.invoke(...)
    # return the LLM response as a string (expected tool response format)
    # this will be automatically turned to ToolMessage
    # by the prebuilt create_react_agent (supervisor)
    return response.content
def agent_2(state: Annotated[dict, InjectedState]):
    response = model.invoke(...)
    return response.content
tools = [agent_1, agent_2]
# the simplest way to build a supervisor w/ tool-calling is to use prebuilt ReAct agent graph
# that consists of a tool-calling LLM node (i.e. supervisor) and a tool-executing node
supervisor = create_react_agent(model, tools)

2.1.10 层级式（或垂直式）

Agents以树状结构组织，其中高级代理（主管代理）管理低级代理。

随着系统中智能体数量的增长，主管智能体在协调全部智能体时可能面临能力瓶颈。

它在决策下一个被调用的智能体时，易出现判断偏差，同时上下文信息的膨胀使其难以有效追踪整体状态。换言之，这正是多智能体架构中固有的管理困境。

针对这一挑战，可引入层级化系统架构：将智能体划分为多个由专属主管负责的、功能专一的代理团队，并由一个顶层主管统一协调各团队的运作。

from typing import Literal
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, MessagesState, START, END
from langgraph.types import Command
model = ChatOpenAI()
# define team 1 (same as the single supervisor example above)
def team_1_supervisor(state: MessagesState) -> Command[Literal["team_1_agent_1", "team_1_agent_2", END]]:
    response = model.invoke(...)
    return Command(goto=response["next_agent"])
def team_1_agent_1(state: MessagesState) -> Command[Literal["team_1_supervisor"]]:
    response = model.invoke(...)
    return Command(goto="team_1_supervisor", update={"messages": [response]})
def team_1_agent_2(state: MessagesState) -> Command[Literal["team_1_supervisor"]]:
    response = model.invoke(...)
    return Command(goto="team_1_supervisor", update={"messages": [response]})
team_1_builder = StateGraph(Team1State)
team_1_builder.add_node(team_1_supervisor)
team_1_builder.add_node(team_1_agent_1)
team_1_builder.add_node(team_1_agent_2)
team_1_builder.add_edge(START, "team_1_supervisor")
team_1_graph = team_1_builder.compile()
# define team 2 (same as the single supervisor example above)
class Team2State(MessagesState):
    next: Literal["team_2_agent_1", "team_2_agent_2", "__end__"]
def team_2_supervisor(state: Team2State):
    ...
def team_2_agent_1(state: Team2State):
    ...
def team_2_agent_2(state: Team2State):
    ...
team_2_builder = StateGraph(Team2State)
...
team_2_graph = team_2_builder.compile()
# define top-level supervisor
builder = StateGraph(MessagesState)
def top_level_supervisor(state: MessagesState) -> Command[Literal["team_1_graph", "team_2_graph", END]]:
    # you can pass relevant parts of the state to the LLM (e.g., state["messages"])
    # to determine which team to call next. a common pattern is to call the model
    # with a structured output (e.g. force it to return an output with a "next_team" field)
    response = model.invoke(...)
    # route to one of the teams or exit based on the supervisor's decision
    # if the supervisor returns "__end__", the graph will finish execution
    return Command(goto=response["next_team"])
builder = StateGraph(MessagesState)
builder.add_node(top_level_supervisor)
builder.add_node("team_1_graph", team_1_graph)
builder.add_node("team_2_graph", team_2_graph)
builder.add_edge(START, "top_level_supervisor")
builder.add_edge("team_1_graph", "top_level_supervisor")
builder.add_edge("team_2_graph", "top_level_supervisor")
graph = builder.compile()

优点：‌

各层级 agent 的角色定位与职责边界明确。

交互路径简洁，通信效率高。

天然适配具备标准化决策链路的规模化系统。

缺点：‌

核心层节点失效易引发系统级崩溃。

基层 agent 的自主决策能力受到显著约束。

2.1.11 自定义多代理工作流程

每个智能体仅与部分其他智能体进行通信，其中部分通信路径是预设固定的，另一部分则由智能体自主决策后续调用对象。

在此架构中，各智能体被建模为图中的节点，并预先设定其在定制工作流中的执行序列。在 LangGraph 中，工作流的定义方式主要有两类：

显式控制流（普通边）‌：LangGraph 利用标准图边明确刻画应用程序的控制流向（即智能体间的调用次序），该模式代表了上述架构中确定性最强的形式——系统在运行前即可精确预知下一被调用的智能体。

动态控制流（命令）‌：LangGraph 支持通过 Command 实现 LLM 对应用部分流程的动态调控，其中一种典型情形为监督工具调用架构。

在此模式下，负责驱动工具调用的 LLM 监督智能体，将实时决定后续调用哪些工具（即智能体）。

三、Agent之间通信

构建多智能体系统时，核心在于明确智能体间的通信机制，这主要涵盖以下三个关键点：

智能体是依赖图状态通信，还是通过工具调用来交互？

当两个智能体的状态模式不一致时，系统将如何应对？

共享邮件列表能否作为有效的跨智能体沟通渠道？

3.1 图状态与工具调用

智能体之间传递的“有效载荷”指什么？在多数架构中，智能体以图状态为通信媒介。对具备工具调用能力的监管者而言，该有效载荷即为工具调用参数。

图状态

为了实现基于图状态的通信机制，需将各智能体建模为图中的节点，这些节点既可封装为独立函数，也可嵌入为完整的子图结构。

在图的每一轮执行过程中，智能体节点会接收当前图状态，运行其内部逻辑代码，并将处理后的新状态传递至下游节点。

例如，在社交媒体聚合器的实现中，图状态被定义为：

通常情况下，智能体节点共享同一个状态模式 。但是，您可能希望设计具有不同状态模式的智能体节点。

3.2 不同的状态模式

在 LangGraph 中，若智能体需具备区别于其他智能体的状态模式，可采用以下两种策略：

为子智能体设定专属状态模式‌：当子图与父图之间不存在共享的状态键（通道）时，需显式配置输入/输出转换逻辑，以确保父图能正确与子图进行交互；

为智能体节点函数指定私有输入状态模式‌：该模式独立于全局图状态，仅承载执行该节点所必需的最小信息集，从而实现状态隔离与职责解耦。

两种方式均保留原始术语与技术语义，仅通过语序重组与表达精炼实现风格上的自然变体。

3.3 共享消息列表

智能体间最普遍的通信机制是借助共享状态通道，通常体现为一个消息队列。此机制预设状态中必然存在至少一个被多个智能体共同访问的键（通道）。

在采用消息列表实现通信时，还需权衡一个关键问题：智能体应披露其全部推理路径，抑或仅传递最终结论？

四、结论

多智能体 LLM 系统构建了一种高效范式，通过并行、顺序、路由器与聚合器工作流等多种架构模式协同应对复杂任务，这一点在本博客中已有深入探讨。

通过对共享状态、消息列表与工具调用等通信机制的深入剖析，智能体间的协同运作已实现高效且无间断的协调。

最近两年，大家都可以看到AI的发展有多快，我国超10亿参数的大模型，在短短一年之内，已经超过了100个，现在还在不断的发掘中，时代在瞬息万变，我们又为何不给自己多一个选择，多一个出路，多一个可能呢？

与其在传统行业里停滞不前，不如尝试一下新兴行业，而AI大模型恰恰是这两年的大风口，整体AI领域2025年预计缺口1000万人，其中算法、工程应用类人才需求最为紧迫！

学习AI大模型是一项系统工程，需要时间和持续的努力。但随着技术的发展和在线资源的丰富，零基础的小白也有很好的机会逐步学习和掌握。【点击蓝字获取】

【2025最新】AI大模型全套学习籽料（可白嫖）：LLM面试题+AI大模型学习路线+大模型PDF书籍+640套AI大模型报告等等，从入门到进阶再到精通，超全面存下吧！