Multi-Agent 多智能体：到底怎么协作？

一个 Agent 再强，也受限于单次上下文、单一视角和单线程执行。Multi-Agent 把"一个人扛所有活"变成"一队人分工合作"——每个 Agent 有专属角色、工具和记忆，通过消息互相沟通，把复杂任务拆解、并行、再汇聚。本文讲清 Multi-Agent 是什么、多个 Agent 如何协同、以及当下最常用的一批框架。

Orchestrator Role-based Agent2Agent AutoGen LangGraph CrewAI

1. Multi-Agent 一句话讲清

Multi-Agent System（多智能体系统） = 多个具备自主感知、推理、行动能力的 Agent，围绕一个共同目标相互通信、分工、协同，去解决单靠一个 Agent 搞不定的复杂问题。

🧍

单 Agent

一个"全能工人"，自己规划、自己调工具、自己出结果。简单可控，但容易上下文爆掉、视角单一、串行慢。

👥

Multi-Agent

像公司里的团队协作：产品经理、开发、测试、文档工程师各司其职，信息传递清晰，整体效率和专注度都更高。

核心思想：团队作战代替单打独斗。与其让一个 Agent 包揽所有事，不如把任务按职能拆开，每个 Agent 只负责一件专业的事。

2. 为什么需要 Multi-Agent？

🧠 原因一：单 Agent 的工作台有硬上限

LLM 处理任务时，会把"当前能看到的一切"都摆在同一张工作台上：你的指令、它自己的推理过程、工具返回的搜索结果、历史对话记录……这张工作台就是 context window。

常见模型限制从几万到一百万 token 不等，塞满之后，早期内容就会开始"掉落"——就像桌子放满了东西，新的要进来，旧的只能推到地上。

左：单 Agent 把搜索、推理、历史全堆在同一张工作台，很快被 token 上限撑爆；右：Multi-Agent 每个角色有独立干净的 context。

🚫

上下文硬上限

复杂任务信息量一旦超过窗口就开始遗忘，这是结构性限制，不是简单优化能绕过的。

🎯

专业度问题

一个 Agent 身兼数职，每件事都不够专注；分身后每个 Agent context 干净，只装自己那块。

⚡

并行提速

多个 Worker 同时跑，整体效率有实质提升；Orchestrator 识别无依赖子任务即可并发派发。

3. 单 Agent vs 多 Agent 对比

单 Agent 把所有信息压到一个上下文里；Multi-Agent 像流水线/部门协作，各自聚焦、信息传递清晰。

维度	单 Agent	Multi-Agent
Context 压力	所有信息塞进一个窗口，易溢出	每个 Agent context 独立，只关心本职
专业度	身兼数职，样样通样样松	角色分离，专注度更高
执行方式	串行，单线程	可串行/可并行，可回退再审
可调试性	出错链路长，定位困难	角色职责清晰，便于逐环节排查
复杂度	简单、可控、好落地	调度/通信/状态管理更复杂
适合场景	单次问答、简单工具调用	竞品分析、代码生成、研究汇报、复杂决策

4. 多 Agent 的三种协作模式

Multi-Agent 之间最常见的协作方式有三种：顺序流水线、并行扇出、辩论/评审。实际系统里经常混合使用。

顺序流水线适合步骤依赖型任务；并行扇出适合无依赖子任务；辩论/评审适合高质量决策与方案选型。

顺序流水线

A → B → C，每个 Agent 处理上一步输出。像后端接口开发：接口设计 → 编码 → 测试。

并行扇出

Orchestrator 识别独立子任务，同时分发给多个 Worker。如竞品分析中同时抓取 10 家公司资料。

辩论/评审

多个 Agent 给出不同方案，Judge 评估或互相审稿。适合代码评审、架构选型、安全审计。

5. 组织方式：中心化 vs 去中心化

Multi-Agent 系统的组织方式主要有两种：中心化（Centralized）和去中心化（Decentralized）。工程上主流选中心化。

工程上多用中心化：调度逻辑清晰、责任归属明确、出问题容易定位。去中心化更像 Agent 自发协商，适合探索性任务。

维度	中心化	去中心化
调度	Orchestrator 统一派发、收集	Agent 间自行协商、直接通信
可控性	高，流程一目了然	低，行为更开放
调试	容易，责任归属明确	困难，链路可能互相缠绕
适用	生产系统、确定性流程	探索性任务、创意发散
工程选择	主流	研究/原型场景较多

6. 协同的核心机制

多个 Agent 能协作起来，离不开下面四块基础设施。框架不同，实现方式不同，但本质一致。

🎭

1. 角色定义（Role / Persona）

每个 Agent 有明确身份、目标、可用工具和限制。例如"需求分析师只输出功能列表，不写代码"。

💬

2. 通信协议（Message Passing）

Agent 之间通过消息交换状态、结果和请求。中心化系统中通常走 Orchestrator；去中心化系统直接 P2P。

🗺️

3. 任务调度（Orchestration）

决定谁先做、谁后做、谁能并行。包括子任务拆分、依赖管理、结果聚合、错误回退。

🧠

4. 共享状态 / 记忆

所有 Agent 能访问统一上下文（黑板/共享记忆），避免各说各话。 LangGraph 的 State 就是典型实现。

协同本质：把"一个大上下文"拆成多个"小上下文 + 通信协议 + 共享状态"。分工会带来信息损失，所以通信协议设计是关键。

7. 完整流程示例：生成一份竞品分析报告

一个典型 Multi-Agent 工作流：用户请求 → Orchestrator 拆分 → 多个角色并行/串行执行 → 汇总整合 → 输出结果。

收益：每个 Agent context 只装自己这块，不会把"代码细节"和"搜索资料"混在一起；同时搜索可以并行，整体速度更快。

8. 主流 Multi-Agent 框架盘点

2025 年生态里，CrewAI、LangGraph、MAF / AutoGen / AG2 是最常被提到的选择。选框架时要留意微软在 2025 年把 Semantic Kernel（企业级）和 AutoGen（多 Agent 编排）合并成 Microsoft Agent Framework（MAF）这条变化。

三大主流选型：CrewAI 偏上层易用；LangGraph 偏底层灵活；MAF 是微软系生产级统一 SDK。

框架	定位	核心抽象	适合谁	备注
CrewAI	上层框架	Agent、Task、Crew、Process	快速搭原型、业务人员也能上手	抽象高，开箱即用
LangGraph	编排层	StateGraph、Node、Edge、Conditional Edge	需要精细控制循环/条件/状态的项目	LangChain 生态，灵活但学习曲线陡
MAF	企业级 SDK	Microsoft Agent Framework	微软技术栈、生产场景	2025 年由 SK + AutoGen 合并而来
AutoGen	研究/原型	ConversableAgent、GroupChat	多 Agent 对话实验	原仓库继续以研究身份迭代
AG2	社区 fork	向后兼容 AutoGen	想延续 AutoGen API 的社区项目	社区维护，保持向后兼容

9. 框架怎么选？

快速验证 / MVP

用 CrewAI。几行代码定义角色和任务，最快看到多 Agent 跑起来。

复杂流程 / 需要状态机

用 LangGraph。能精细控制循环、条件分支、共享状态，适合需要回退/重试的链路。

微软云 / 企业生产

优先考虑 MAF。统一 SDK、企业级支持、与 Azure / Semantic Kernel 整合更深。

注意生态变化：微软 2025 年将 Semantic Kernel 和 AutoGen 合并为 MAF。如果你是微软技术栈或面向生产，建议直接看 MAF；AutoGen 原仓库继续偏向研究与原型；AG2 是社区 fork，保持向后兼容。

10. 关键挑战

🌀

循环与死锁

Agent 之间来回踢皮球，任务可能陷入无限循环。需要设置最大轮次、终止条件、超时机制。

📡

通信开销

消息传递会丢失上下文细节。需要设计好消息格式、共享状态、以及"黑板"机制。

🧩

状态一致性

多个 Agent 同时读写共享状态时，需要版本控制、冲突解决和幂等设计。

🔍

可观测性

多 Agent 链路长，必须记录完整 trace：谁调了谁、输入输出、耗时、错误。

11. 面试回答要点

面试官问"什么是 Multi-Agent，多个 Agent 怎么协作"时，别只回答"多个 AI 一起工作效率更高"。重点说清下面三点：

Context window 硬上限：单个 Agent 处理复杂任务时信息量超出窗口就开始遗忘，这是结构性限制，必须拆分。
专业度问题：分工后每个 Agent context 干净，只装自己那块信息，专业能力更强、输出质量更高。
并行执行：多个 Worker 同时跑，整体效率有实质提升；Orchestrator 识别无依赖子任务即可并发派发。

补充：协作模式（顺序/并行/评审）、中心化组织方式、常用框架（CrewAI/LangGraph/MAF）及选型思路，基本就答到位了。