课程0基础Agent开发课 / 前沿方向 / Multi-Agent多智能体协作
— 12 min read

Multi-Agent多智能体协作

> **时效说明**:本文内容以 2026 年 3 月为基准。

Multi-Agent 多智能体协作:复杂任务的分工之道

时效说明:本文内容以 2026 年 3 月为基准。

1.1 为什么需要多 Agent:单 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 各司其职。

分配调研任务

分配写作任务

分配格式化任务

返回调研结果

返回报告草稿

返回PPT提纲

用户请求

Supervisor Agent
任务分配 + 结果汇总

Research Agent
信息收集整理

Writer Agent
报告撰写

Formatter Agent
PPT提纲生成

最终输出

Supervisor 像一个项目经理,它不亲自干活,负责:理解用户意图并分解任务,决定下一步让哪个 Worker 来做,收集 Worker 的输出并判断是否需要返工,整合所有结果输出最终答案。

适合:任务可以明确分解为独立子任务,子任务之间有明确的前后依赖,需要严格的质量把控。

优点:逻辑清晰,容易调试,Supervisor 的决策链可以被完整记录。

1.2.2 Hierarchical 模式:多层结构

更复杂的任务需要多层 Agent,上层做高层规划,下层做具体执行。

用户请求

Manager Agent
高层规划

Sub-Manager 1
调研协调

Sub-Manager 2
内容创作

Web Search Agent

Data Extraction Agent

Draft Writer Agent

Editor Agent

交付用户

层级模式适合超大型任务,比如完整的软件项目开发、大型研究报告生成。上层管规划,中层管协调,下层管执行,每层只需要关注自己这一层的事情。

缺点:调试难度高,任何一层出问题都可能导致整体失败。

1.3 用 LangGraph 实现 Supervisor 多 Agent

LangGraph 非常适合实现 Multi-Agent。每个 Agent 是图中的一个节点,通过共享 State 传递信息,Supervisor 通过 Command 对象控制路由。

State 是所有 Agent 的共享内存——每个 Agent 只负责更新 State 中属于自己职责范围的字段,Supervisor 通过读取 State 中哪些字段已填充来决定下一步。这个设计避免了 Agent 之间需要直接通信的复杂性。

python
# 安装依赖: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"])

这段代码的设计要点

  1. 每个 Worker Agent 职责单一:调研只做调研,写作只做写作,格式化只做格式化。这样每个 Prompt 可以针对单一任务优化,效果更好。

  2. Supervisor 不做实际工作:它只做路由决策,通过读取 State 字段判断进度。这让 Supervisor 的逻辑简单清晰,容易调试。

  3. 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。不要为了"架构先进"而引入不必要的复杂性。

本页目录