Multi-Agent

随着大模型能力的发展，单 Agent 在处理复杂任务时逐渐暴露出上下文压力、能力边界和任务复杂度等问题。Multi-Agent（多智能体）通过多个具有不同职责的 Agent 协同工作，将复杂任务拆解为多个子任务，提升系统的专业性、可扩展性和执行效率。

本文将从 Multi-Agent 的核心思想出发，深入分析单 Agent 的局限、多智能体协作模式（顺序流水线、并行执行、评审辩论）、中心化与去中心化架构，以及实际工程中的选型原则。同时结合生产实践，探讨为什么企业更倾向于 Supervisor-Orchestrator 模式，而不是完全去中心化协作。

最后通过手写一个简易 Multi-Agent Demo，模拟 Supervisor Agent 调度 Research Agent 和 Writer Agent 的完整流程，帮助理解 LangGraph、CrewAI、AutoGen 等框架背后的底层实现原理。

多智能体系统就是多个Agent协作完成任务，每个Agent各有分工

1.单Agent的限制

单个Agent主要有两个限制：

1. context窗口大小：复杂任务信息量一多就会撑爆
2. 单点能力：全部都让一个Agent做，每件事都是泛才

Multi-Agent 通过专业分工和并行执行，能处理更复杂、更长流程的任务

2.协作模式

1. 顺序流水线：Agent Az做完再交给Agent B
2. 并行扇出：一个调度者把多个独立子任务同时分发给不同的 Worker Agent，它们各自并行执行，最后由调度者收集汇总
3. 辩论/评审：多个 Agent 对同一个问题各自给出方案，然后由一个裁判 Agent 或者它们互相评审来筛选最优解，这种模式在需要高质量决策的场景特别有用，比如代码评审、方案选型

多个Agent并行执行提升效率，而且每个Agent的context是完全隔离的，不会相互影响

3.Multi-Agent框架

微软技术栈的生产场景建议优先考虑 MAF，其他场景 CrewAI（上层更易用）或 LangGraph（底层更灵活）都是持续维护的主流选择

4.组织方法

1. 中心化：由一个统一的调度者来分配任务、收集结果
2. 去中心化：Agent自行协商直接通信

中心化

Orchestrator不做任何具体工作，只负责：读懂用户的目标、把目标拆成一个个子任务、判断每个子任务应该交给哪个worker做、收集产出最终拼成答案

Orchestrator的三种分类：

• 静态路由：任务拆分和分配规则都是预先定义好的
• 动态规划：Orchestrator 本身是一个 LLM，它会根据用户输入动态生成任务计划，决定需要几个步骤、每步交给谁，计划本身也可以在执行过程中调整
• 自适应编排：Orchestrator 不仅动态规划，还会根据 Worker 的执行结果实时调整后续计划，比如 Researcher 搜回来的信息不够，Orchestrator 会追加一轮搜索任务

去中心化

去中心化系统里这几类问题会频繁出现：任务分配没有协调、执行顺序没有保证、失败没有感知、没有人来确认任务整体完成了

去中心化方案更多停留在学术研究里探索

5.什么时候用Multi-Agent

任务是否存在多个独立专业角色，并且这些角色需要不同上下文、不同目标或者不同工具

1. 是否存在明显的角色分工

2. 是否需要隔离上下文

   单Agent：所有信息混在一起，容易出现上下文膨胀、信息干扰

3. 是否需要不同prompt和能力

   eg：一个客服Agent，首先prompt需要擅长产品推荐、售后prompt需要擅长投诉处理

4. 是否存在并行收益

   不同任务互不依赖，并行处理提升效率

6.为啥不要盲目选Multi-Agent

Multi-Agent会增加：

1. 通信成本
2. 调度复杂度
3. Debug困难
4. token成本增加：多个Agent意味着多个llm调用

不同团队、不同框架开发的 Agent 之间怎么互相通信和协作？

A2A 定义了一套标准化的通信协议，让不同来源的 Agent 在协议层面可以互相发现和调用，思路上很像微服务

维度	Single-Agent	Multi-Agent（中心化）	Multi-Agent（去中心化）
架构复杂度	低	中	高
Context 压力	全部压在一个 Agent	各 Agent 独立管理，Orchestrator 只维护高层状态	各 Agent 独立管理，但需要额外共享协调状态
专业能力	泛才，什么都做	专才分工，各有专责	专才分工，各有专责
并行能力	不支持	支持子任务并行	支持并行
可控性	高	高，Orchestrator 统管	低，难以统一调度
调试难度	容易	中，按调度链路追踪	难，行为不可预测
工程实用性	高	高	低，主要用于学术研究
适用场景	任务清晰、复杂度适中	需要分工或并行的复杂任务	学术探索场景

7.具体实现

实现一个

用户问题
   |
   v
Supervisor Agent（负责分发任务）
   |
   +----------+
   |          |
   v          v
Research Agent   Writer Agent
(搜索数据)        (写报告)

research agent

def research_agent(task):

    print("🔍 Research Agent执行")


    result = f"""
关于{task}：

市场规模:
2025年约5000亿元

增长率:
30%

主要玩家:
A公司
B公司
C公司

"""


    return result

writer agent

def writer_agent(data):

    print("✍️ Writer Agent执行")


    report = f"""

市场分析报告：

{data}

综合来看：
该领域具有发展潜力。

"""


    return report

supervisor agent

from llm import chat


def supervisor_agent(task):


    prompt=f"""

你是任务调度Agent。


用户任务:

{task}


现在有两个Agent:

1. researcher
负责收集市场数据


2. writer
负责生成报告


判断下一步调用哪个Agent。

只返回:

researcher

或者

writer

"""


    result = chat(prompt)


    return result.strip()

main

from agents.supervisor import supervisor_agent
from agents.researcher import research_agent
from agents.writer import writer_agent



task="分析新能源汽车市场机会"


state={

    "task":task,

    "research":None,

    "report":None

}



while True:


    next_agent = supervisor_agent(
        state["task"]
    )


    print(
        "Supervisor:",
        next_agent
    )



    if next_agent=="researcher":


        result = research_agent(
            state["task"]
        )


        state["research"]=result



        # 修改任务
        state["task"]="根据研究结果生成报告"



    elif next_agent=="writer":


        report = writer_agent(
            state["research"]
        )


        state["report"]=report


        break



print(state["report"])