Multi-Agent多智能体协作
> **时效说明**:本文内容以 2026 年 3 月为基准。
Multi-Agent 多智能体协作:复杂任务的分工之道
时效说明:本文内容以 2026 年 3 月为基准。
1.1 为什么需要多 Agent:单 Agent 的能力天花板
三种多 Agent 协作模式——Supervisor(左)/ Peer-to-Peer(中)/ Hierarchical(右)
在学 Multi-Agent 之前,先搞清楚为什么需要它。不清楚这个,你就不知道什么时候该用,什么时候是过度设计。
单 Agent 的能力上限来自两个层面:
计算资源层面。LLM 的上下文窗口限制了单 Agent 能处理的信息量。即使是百万 token 的超长上下文,在处理真正复杂的长流程任务时也有边界。而且研究表明,上下文越长,模型对中间内容的关注度越低——这个现象叫 Lost in the Middle,简单说就是"前面和后面的信息模型记得住,中间的容易忘"。
专注度层面。当一个 Agent 需要同时承担调研、分析、写作、代码生成等多种能力时,每项能力的 Prompt 设计会相互干扰。专用的 Agent(专注做一件事)往往比通用的 Agent(什么都做)在特定任务上表现更好。这和人类组织中"专业分工"的道理一样。
但多 Agent 不是银弹。引入多 Agent 的代价是实实在在的:每多一个 Agent,调试复杂度指数级上升;Agent 间的每次通信都是一次 LLM 调用,成本倍增;协调机制本身的设计需要额外工作。只有当单 Agent 的边界被清晰地遇到,才值得引入多 Agent 架构。
1.2 多 Agent 的核心设计问题:协调机制
多 Agent 系统的核心不是"有多少个 Agent",而是协调机制:谁决定哪个 Agent 做什么,信息如何在 Agent 之间传递,出错了如何处理。
不同的协调机制对应不同的适用场景和工程复杂度。
1.2.1 Supervisor 模式:有中央控制器
一个 Supervisor Agent 负责任务分配和协调,多个 Worker Agent 各司其职。
Supervisor 像一个项目经理,它不亲自干活,负责:理解用户意图并分解任务,决定下一步让哪个 Worker 来做,收集 Worker 的输出并判断是否需要返工,整合所有结果输出最终答案。
适合:任务可以明确分解为独立子任务,子任务之间有明确的前后依赖,需要严格的质量把控。
优点:逻辑清晰,容易调试,Supervisor 的决策链可以被完整记录。
1.2.2 Hierarchical 模式:多层结构
更复杂的任务需要多层 Agent,上层做高层规划,下层做具体执行。
层级模式适合超大型任务,比如完整的软件项目开发、大型研究报告生成。上层管规划,中层管协调,下层管执行,每层只需要关注自己这一层的事情。
缺点:调试难度高,任何一层出问题都可能导致整体失败。
1.3 用 LangGraph 实现 Supervisor 多 Agent
LangGraph 非常适合实现 Multi-Agent。每个 Agent 是图中的一个节点,通过共享 State 传递信息,Supervisor 通过 Command 对象控制路由。
State 是所有 Agent 的共享内存——每个 Agent 只负责更新 State 中属于自己职责范围的字段,Supervisor 通过读取 State 中哪些字段已填充来决定下一步。这个设计避免了 Agent 之间需要直接通信的复杂性。
# 安装依赖:pip install langgraph langchain-openai
from typing import TypedDict, Annotated, Literal
from langgraph.graph import StateGraph, START, END
from langgraph.types import Command
from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
# 定义共享状态
class MultiAgentState(TypedDict):
task: str # 原始任务
research_result: str # 调研 Agent 的输出
report_draft: str # 写作 Agent 的输出
final_output: str # 格式化 Agent 的输出(最终产物)
# Worker Agent 1:调研 Agent
def research_agent(state: MultiAgentState) -> Command:
"""专注于信息调研,不做写作"""
prompt = f"""你是一个专业的市场调研分析师。
任务:{state['task']}
请进行调研分析,提供:
1. 核心功能特性对比
2. 定价策略对比
3. 市场定位分析
4. 主要优缺点总结
输出结构化的调研结果,清晰标注各个维度。"""
result = llm.invoke([HumanMessage(content=prompt)])
# 更新自己负责的字段,然后把控制权交还给 Supervisor
return Command(
update={"research_result": result.content},
goto="supervisor"
)
# Worker Agent 2:写作 Agent
def writer_agent(state: MultiAgentState) -> Command:
"""专注于报告写作,不做调研"""
prompt = f"""你是一个专业的商业分析报告撰写者。
调研结果:
{state['research_result']}
原始任务:{state['task']}
请基于调研结果撰写一份专业的分析报告,包括:
- 执行摘要(核心结论,不超过 200 字)
- 竞品对比分析(用表格)
- 市场机会分析
- 行动建议
报告要逻辑清晰,结论明确。"""
result = llm.invoke([HumanMessage(content=prompt)])
return Command(
update={"report_draft": result.content},
goto="supervisor"
)
# Worker Agent 3:格式化 Agent
def formatter_agent(state: MultiAgentState) -> Command:
"""专注于将报告转化为 PPT 提纲,不做内容创作"""
prompt = f"""你是一个专业的演示文稿设计师。
分析报告:
{state['report_draft']}
请将报告整理为 PPT 提纲:
- 每页幻灯片的标题
- 每页的 3-5 个要点(简洁,适合演讲)
- 建议配图类型
PPT 在 10 页以内,重点突出,适合高管汇报。"""
result = llm.invoke([HumanMessage(content=prompt)])
return Command(
update={"final_output": result.content},
goto="supervisor"
)
# Supervisor Agent:任务协调和路由
def supervisor(state: MultiAgentState) -> Command:
"""根据当前状态决定下一步,不亲自执行任务
这是 Supervisor 模式的核心:通过检查 State 字段是否已填充
来判断当前进度,决定下一步路由到哪个 Agent
"""
if not state.get("research_result"):
# 还没有调研结果,先调研
print("[Supervisor] 启动调研 Agent...")
return Command(goto="research_agent")
elif not state.get("report_draft"):
# 有调研结果了,写报告
print("[Supervisor] 调研完成,启动写作 Agent...")
return Command(goto="writer_agent")
elif not state.get("final_output"):
# 有报告了,生成 PPT 提纲
print("[Supervisor] 报告完成,启动格式化 Agent...")
return Command(goto="formatter_agent")
else:
# 所有步骤完成
print("[Supervisor] 所有任务完成!")
return Command(goto=END)
# 构建 Multi-Agent 图
builder = StateGraph(MultiAgentState)
builder.add_node("supervisor", supervisor)
builder.add_node("research_agent", research_agent)
builder.add_node("writer_agent", writer_agent)
builder.add_node("formatter_agent", formatter_agent)
# 所有流程都从 Supervisor 开始,Supervisor 决定路由
builder.add_edge(START, "supervisor")
# 编译
graph = builder.compile()
def run_analysis(task: str) -> dict:
"""执行分析任务"""
initial_state = MultiAgentState(
task=task,
research_result="",
report_draft="",
final_output=""
)
result = graph.invoke(initial_state)
return {
"research": result["research_result"][:500] + "...", # 截断展示
"report": result["report_draft"][:500] + "...",
"ppt_outline": result["final_output"]
}
# 使用示例
# result = run_analysis(
# "分析 Notion、Obsidian、Roam Research 三款知识管理工具,分析功能、定价、市场定位"
# )
# print(result["ppt_outline"])
这段代码的设计要点:
每个 Worker Agent 职责单一:调研只做调研,写作只做写作,格式化只做格式化。这样每个 Prompt 可以针对单一任务优化,效果更好。
Supervisor 不做实际工作:它只做路由决策,通过读取 State 字段判断进度。这让 Supervisor 的逻辑简单清晰,容易调试。
State 是唯一的信息通道:Agent 之间没有直接通信,全靠 State 传递。这避免了 Agent 间的耦合,也让整个执行过程可追踪。
1.4 三大主流框架对比
截至 2026 年 3 月,多 Agent 框架主要有三个:
LangGraph:基于图结构,把 Agent 之间的关系用节点和边表示,可以精确控制流程。支持循环(Agent 可以重复执行)、并行(多个 Agent 同时执行)、人工干预节点。适合复杂的定制化业务流程。学习曲线稍陡,概念比较多。
AutoGen(微软):对话式多 Agent,Agent 之间通过消息对话协作,更接近人类团队讨论的方式。特别适合代码生成场景,内置了 UserProxyAgent 和 AssistantAgent,可以模拟程序员和代码审查员的对话。如果任务是让多个 AI 通过辩论或协商得出结论,AutoGen 很合适。
CrewAI:角色扮演式框架,给每个 Agent 定义"角色"、"目标"和"工具",Agent 会根据角色设定自主行动。适合内容创作、营销方案等场景,配置简单,上手快,但灵活性不如 LangGraph。(详见本章第 08 篇)
| 框架 | 协调方式 | 上手难度 | 适合场景 |
|---|---|---|---|
| LangGraph | 图结构,精确控制 | 中高 | 复杂条件分支,需要精细控制流程 |
| AutoGen | 对话式协商 | 中 | 代码生成,需要多轮讨论的任务 |
| CrewAI | 角色分工,流水线 | 低 | 内容创作,任务分工明确的流水线 |
1.5 使用 Multi-Agent 的注意事项
Agent 数量不是越多越好。每多一个 Agent,就多一层出错的可能,调试成本成倍增加。两个 Agent 能搞定的任务不要硬拆成七八个,否则系统会非常脆弱。
Agent 间通信有成本。每次 Agent 调用 LLM 都消耗 token,Supervisor 的每次路由决策也是一次 LLM 调用。一个三步流程,实际 LLM 调用次数可能是六七次。如果任务对成本敏感,先算清楚。
调试难度高。单 Agent 出问题很容易定位,Multi-Agent 出问题可能是任何一个节点的问题,也可能是 Agent 之间的交互逻辑问题。LangGraph 提供了 LangSmith 追踪工具,强烈建议开发阶段开启。
State 设计要慎重。State 的字段设计很关键——字段太少,Agent 拿不到需要的上下文;字段太多,State 变得臃肿,前面的信息可能干扰后面 Agent 的判断。
1.6 正确的使用路径
先把单 Agent 用熟,知道单 Agent 的边界在哪里,感受到上下文限制或分工需求时,再引入多 Agent。
如果你现在只是在学习 Agent 开发,先不要上 Multi-Agent。先把第 12-13 章的单 Agent 和 LangGraph 搞透,再来看这里。
如果你在做真实项目,确认这个任务单 Agent 确实处理不好(比如上下文太长导致遗忘,或者一个 Agent 承担太多角色导致质量下降),再考虑引入多 Agent。不要为了"架构先进"而引入不必要的复杂性。