
从ReAct到Multi-Agent:LangGraph如何实现智能体间的无缝协作? 原创
在LangChain生态日益成熟的今天,我们构建的AI应用正从简单的“问答机器人”向复杂的“智能体协作系统”演进。而LangGraph,作为LangChain生态中用于构建有状态、多步骤AI应用的利器,其核心价值之一就在于对多智能体(Multi-Agent) 系统的优雅支持。
为什么要“多智能体”?
- 智能体(Agent)是什么本质是一个能感知环境、基于策略行动以实现目标的“自主体”。在 LangChain/LangGraph 中,哪怕最简单的对话循环也可视为一个智能体。
a.具备感知(输入)、决策(策略/推理)、行动(工具/调用)、学习(记忆/更新)能力。
b.形式上可以是软件角色、机器人、业务微服务、甚至一个“LLM + 工具”组合。
- 为什么会走向多智能体(Multi-agent)单体智能体在复杂问题上会遭遇三类瓶颈:
a.工具过载:工具太多导致“调用哪个”的决策困难。
b.上下文负担:长对话导致推理退化。
c.领域专精冲突:规划、检索、计算、执行等专业能力难以在单一提示词里兼顾。解决方法是“模块化 + 专精化”:将系统拆分为多个职责单一的小智能体,组合成中/大型系统。
- 多智能体的核心收益
a.模块化:开发、测试、维护成本更低。
b.专精化:专家智能体的鲁棒性更强。
c.可控性:通信/交接路径与策略可显式定义,而不是完全交给 LLM 即兴发挥。
五种典型架构
- 网络(Fully-connected Network)任意智能体都可与其他智能体通信。灵活但易“泛滥”,适合探索性、弱流程约束场景。
- 监督者(Supervisor)引入一个“调度/路由”智能体,由它决定调用哪个专家。结构清晰,利于审计与限流。
- 监督者(工具调用变体)把专家抽象为“工具”,监督者是 ReAct 智能体,通过工具调用来路由。利于快速落地。
- 层级(Hierarchical)多个团队各自有监督者,顶层再由总监督者统筹。适合大规模系统或多产品线场景。
- 自定义工作流(Deterministic/Dynamic Mix)部分边是固定顺序,部分由 LLM 通过
Command
动态路由。工程中较常见的折中方案。
如果你不确定选哪种架构,先用“监督者(工具调用)”起步,随后按复杂性迭代。
Handoffs & Command
- 交接概念智能体执行完当前职责后,决定“结束/继续/转交给他人”。交接的关键是显式描述:
a.目标智能体:goto
b.携带负载(状态更新):update
c.图域(在哪个图生效):graph
,常见为当前图或 Command.PARENT
(从子图跳回父图)
- 最小 Command 模式
a.智能体节点函数返回 Command
,用于控制下一步路由;否则返回状态更新结束当前轮次。
b.在工具调用场景中,务必插入配对的“工具结果消息”,以满足多数 LLM 提供商的协议约束(每个 ai_msg
的工具调用,必须跟一个 tool
消息)。
- 常见交接手法
a.直接在智能体节点里决策,返回 Command
。
b.把交接包装成一个“工具”,由 LLM 以工具调用的方式触发交接(显著提升统一性)。
c.子图内要交接到父图的其他智能体时,设置 graph=Command.PARENT
。
智能体通信与状态设计
- 统一 state(共享消息)图中的每一步都接收并产出
state
,通常包含messages
。共享完整“草稿”(推理过程)能提升整体推理能力,但要提防上下文爆炸。 - 异构 state(私有草稿 + 共享摘要)各智能体维护自己格式的内部状态,借助输入/输出转换与父图 state 对接。
a.优点:清晰边界、可做“信息最小化共享”。
b.技巧:交接时只共享“上一条 AI 回复 + 工具回执”,而非全部草稿。
- 工具调用与负载监督者作为 ReAct 节点时,工具的参数就是负载。LangGraph 支持将父图 state 注入到工具(例如
InjectedState
),实现“带记忆的交接”。
三种Handoff模式对比与最小代码片段
1. 直接 Command 交接(节点内路由)
- 适用:两个或少数几个智能体的网络架构,逻辑简单、路由清晰。
- 关键点:当
ai_msg.tool_calls
非空,插入工具结果消息,再goto
下一个智能体。
from typing_extensions import Literal
from langgraph.types import Command
from langgraph.graph import MessagesState
from langchain_core.tools import tool
@tool
def transfer_to_multiplication_expert():
"""向乘法智能体寻求帮助(只用于表明交接意图)"""
return
def addition_expert(state: MessagesState) -> Command[Literal["multiplication_expert", "__end__"]]:
system_prompt = "你是加法专家。若需乘法,请先完成加法,再交接。"
messages = [{"role": "system", "content": system_prompt}] + state["messages"]
ai_msg = model.bind_tools([transfer_to_multiplication_expert]).invoke(messages)
if ai_msg.tool_calls:
tool_call_id = ai_msg.tool_calls[-1]["id"]
tool_msg = {"role": "tool", "content": "成功交接", "tool_call_id": tool_call_id}
return Command(goto="multiplication_expert", update={"messages": [ai_msg, tool_msg]})
return {"messages": [ai_msg]}
- 常见坑
a.遗漏工具结果消息:导致提供商报错或上下文不同步。
b.无限交接:加步数上限或终止条件。
- 建议引入步数预算:
MAX_STEPS = 8
def guard_and_return(cmd_or_update, state):
steps = state.get("steps", 0) + 1
if steps > MAX_STEPS:
return {"messages": [{"role": "assistant", "content": "超出步数预算,结束。"}]}
if isinstance(cmd_or_update, Command):
cmd_or_update.update = {**cmd_or_update.update, "steps": steps}
return cmd_or_update
return {"messages": cmd_or_update["messages"], "steps": steps}
2. 交接工具(handoff tool)
- 适用:每个智能体是一个“子图”,通过工具将控制权交还父图并路由到目标智能体。
- 关键点:在工具中返回
Command(goto=..., graph=Command.PARENT, update=...)
。
from typing import Annotated
from langchain_core.tools.base import InjectedToolCallId
from langgraph.prebuilt import InjectedState
from langchain_core.tools import tool
from langgraph.types import Command
def make_handoff_tool(*, agent_name: str):
tool_name = f"transfer_to_{agent_name}"
@tool(tool_name)
def handoff_to_agent(
state: Annotated[dict, InjectedState],
tool_call_id: Annotated[str, InjectedToolCallId],
):
tool_message = {
"role": "tool",
"content": f"成功交接到 {agent_name}",
"name": tool_name,
"tool_call_id": tool_call_id,
}
return Command(
goto=agent_name,
graph=Command.PARENT,
update={"messages": state["messages"] + [tool_message]},
)
return handoff_to_agent
- 优点:
a.路由逻辑统一沉淀在“工具层”,智能体代码更干净。
b.便于在团队内部约定交接规范与审计。
3. 预构建 ReAct 智能体(create_react_agent)
- 适用:不需要自定义 ToolNode/循环的场景,快速搭建。
- 要点:把交接工具加入工具列表即可。
from langgraph.prebuilt import create_react_agent
from langchain_core.tools import tool
@tool
def add(a: int, b: int) -> int:
return a + b
@tool
def multiply(a: int, b: int) -> int:
return a * b
addition_expert = create_react_agent(
model,
[add, make_handoff_tool(agent_name="multiplication_expert")],
prompt="你是加法专家。必要时交接给乘法专家。",
)
multiplication_expert = create_react_agent(
model,
[multiply, make_handoff_tool(agent_name="addition_expert")],
prompt="你是乘法专家。必要时交接给加法专家。",
)
函数 API
当你希望“每个智能体能与所有其他智能体通信”,但又想暂时避开图的节点/边定义时,可以用 LangGraph 函数 API:
- 用
@entrypoint()
定义主流程循环; - 用
@task
封装对各智能体的调用; - 通过识别最近一条
AIMessage.tool_calls
决定交接目标; - 在工具上用
@tool(return_direct=True)
,使得代理一旦调用交接工具就立刻“跳出”自身循环,将控制权交回主流程。
工程上建议在主循环里加入:
- 步数上限、异常重试、交接工具白名单校验(防止 LLM“幻想”出未定义的工具名)。
工程化落地的关键要点
- 提示词
a.“先做自己职责,再交接”应写入 system prompt。
b.明确输出格式、是否中文、是否需要结构化信息(JSON/Markdown)。
- 终止条件与预算控制
a.设定步数预算、调用预算、时间预算;超限即 __end__
。
b.在状态中追踪 steps/cost
,并在每轮更新。
- 状态设计与内存治理
a.区分“共享消息”和“私有草稿”;用转换器只暴露必要上下文。
b.引入“摘要工具/裁剪策略”(例如只保留近 N 轮 + 摘要)。
- 工具安全
a.工具入参强类型化(Pydantic 校验);
b.重要操作前加“确认工具”(双人复核型);
c.对“交接工具名”设白名单,拒绝未知路由。
- 可观测性与调试
a.使用 graph.stream(..., subgraphs=True)
订阅事件;
b.统一 pretty_print_messages
,将 ai/tool
消息流对齐打印;
c.日志里打出 tool_call_id
对应关系,便于问题复盘。
- 性能与并行
a.能“分而治之”的子任务用并行 map,再汇总 reduce;
b.对“冷工具”(慢 IO)启用异步;
c.压测不同架构的延迟/费用分布,形成“选型矩阵”。
- 稳定性与测试
a.构造“金样本对话流”,回归测试交接路径与最终答案;
b.在异常热点处增加 try/except
+ “安全降级”(例如改用本地规则/缓存)。
常见错误与快速排查
- 少了工具结果消息:每个
ai_msg
的 tool call 后必须追加 1 条tool
消息。 - 子图交接没指定
Command.PARENT
:导致交接“困在子图”。 -
update
写错键名或结构:{"messages": [...]}
不可缺。 -
tool_call_id
不匹配:工具回执里的 ID 必须对应刚触发的 call。 - 未设 START 边或错误路由名:
builder.add_edge(START, "node")
别漏。 - 无限循环:缺少步数控制,或提示词没强制“先做自己,再交接”。
总结
多智能体不是“把大模型套上更多提示词”,而是“把复杂问题拆解成可治理的自治单元”,并通过可观测、可控的交接协议把它们编排起来。Command 是编排的内核;state 是沟通的载体;工具是行动的接口;层次/网络/监督者/自定义工作流是架构的选项。 真正跑代码的时候,建议先用最简单的模式跑通端到端,再引入交接工具统一路由,最后按规模演进到层级或混合架构。
本文转载自AI 博物院 作者:longyunfeigu
