Multi-Agent 多智能体

单 Agent 能完成的任务有上限：任务太复杂，一个循环里既要做 A 又要做 B，上下文互相干扰、每一步都在掉质量。Multi-Agent 的思路是从单兵到团队——由多个分工协作的 Agent 共同完成任务，通过拆分任务与隔离上下文，解决单 Agent 系统难以处理的复杂问题。但团队不是银弹：Token 消耗量大、协作效率低、系统复杂度过高，用得不好比单 Agent 更糟。这一章讲清楚多 Agent 解决什么、有哪些组织模式、什么时候该用什么时候坚决别用。工程实现见 Agent 核心 12 · 多 Agent 与选型策略 与 LangGraph 10 · 多 Agent 架构。

1. 演进脉络：为什么需要团队

1.1 单 Agent 的天花板（2023-2024）

单 Agent 系统在 2023 年的实践中暴露四个问题：

1. 上下文污染：任务 A 的中间结果、工具输出塞进同一个上下文，干扰任务 B 的推理
2. 注意力稀释：一个循环要兼顾太多职责，每个职责都做不精（「多任务合并省下调用费，赔上质量」）
3. 角色冲突：同一个模型既要当「研究员」又要当「审稿人」还要当「写手」，立场互相打架
4. 工具决策失准：注册两三个工具时模型还能选对，注册几十上百个工具后基本调不准——工具选择本身成了瓶颈

1.2 框架催熟（2024）：多 Agent 成为热点

2024 年，多 Agent 框架密集出现：

• AutoGen（微软）：会话式多 Agent，Agent 之间互相「对话」协作
• CrewAI：角色化 Agent 团队，模拟「研究小组」「市场团队」
• LangGraph：从图论视角编排多 Agent——团队是「图」，Agent 是「节点」，控制流是「边」（本课程的深度实践）

1.3 研究验证（2024.12）：Anthropic 的规模化实践

2024 年 12 月，Anthropic 发表《Building effective agents / Multi-Agent Research System》，披露其内部多 Agent 研究系统：一个主管 Agent 调度多个子 Agent，各自有独立上下文窗口和工具集。公开数据显示其质量相比单 Agent 显著提升，同时给出明确的使用边界——这篇文章几乎定义了 2025 年后多 Agent 讨论的框架。

文章还承认一个反直觉的事实：Anthropic 团队自己曾投入数月构建复杂的多 Agent 架构，最终却退回单 Agent 设计——优化提示词与工具描述后，效果反而更好。多 Agent 不是「更高级」，而是「特定条件下的选择」：它的价值来自上下文隔离，不是来自「数量多」。

2. 核心概念：三种典型组织模式

多 Agent 的「团队组织」可以归纳为三种模式：

2.1 路由模式（Router）

一个入口 Agent 判断「任务属于哪个领域」，分发给对应专家 Agent，专家独立完成后返回。

用户请求 → 路由Agent（分类）→ 代码Agent / 写作Agent / 数学Agent → 结果

适用：任务类型可明确分类、各领域互相独立。

2.2 编排-执行模式（Orchestrator-Workers）

主管 Agent 负责任务分解、进度跟踪、结果整合；子 Agent 各自独立执行子任务（通常并行）。

                    ┌─ Worker A（检索资料）
主管Agent ──分解──► ├─ Worker B（分析数据）
（计划/整合）       ├─ Worker C（撰写初稿）
                    └─ 汇总 → 主管整合输出

适用：任务可拆分为并行子任务，是最常用的模式（Anthropic 研究系统即此模式）。

2.3 协作/评审模式（Collaborative）

多个 Agent 平级协作，互相评审、质疑、迭代（类似「双人写代码 + 互相 review」）。

研究员Agent ──产出──► 审稿Agent ──意见──► 研究员Agent 修订 → 循环至满意

适用：需要质量把关、观点碰撞的任务（写作、设计、代码评审）。

3. 关键认知：多 Agent 的账要算清楚

多 Agent 的本质是用 Token 换质量——团队每个人都要独立的上下文窗口，总消耗是单 Agent 的数倍。所以决策必须算账：

该用多 Agent：

• 子任务之间上下文需求严重冲突（隔离带来的收益 > 成本）
• 任务可清晰拆分为并行子任务（并行还能省墙钟时间）
• 需要多视角/多专业立场（评审、辩论类任务）

不该用多 Agent：

• 单 Agent + 好提示词能搞定的事——别为了「架构好看」引入复杂度
• 子任务间强耦合、需要频繁交换中间状态——协作开销爆炸
• Token 预算敏感、对延迟敏感的场景

经验法则（Anthropic 的结论）：先证明单 Agent 不够，再上多 Agent。 多 Agent 系统的故障排查成本是单 Agent 的指数级——每个子 Agent 都可能出错，错误还在汇总时互相污染。

4. 现状与趋势（2026）

• 多 Agent 走向「少而精」：2025 年「10 个 Agent 大合唱」的噱头退潮，工程共识转向「2-5 个职责清晰的 Agent + 明确的图结构」
• 与 LangGraph 深度绑定：图编排（状态、超步、子图、检查点）成为多 Agent 的生产级基础设施
• 成本治理成为议题：多 Agent 的 Token 消耗、模型选型（子 Agent 用小模型）成为工程必修课

5. 警惕「伪多 Agent」

2025-2026 年最常见的架构失误，是把单 Agent 能做的事硬拆成多 Agent：

伪多 Agent 的典型形态：给同一个模型换了三套提示词，就宣称是「三 Agent 协作系统」。问题在于——拆出来的「角色」共享同一个模型、同一个知识、同一份上下文需求，拆了不仅没带来隔离收益，反而引入角色切换开销和编排复杂度。

另一个高频 bad case：按职能拆分——一个 Agent 写代码、一个 Agent 测试、一个 Agent review。听起来合理，但三个角色依赖的是同一份代码上下文，大量 token 消耗在「解释上下文、对齐彼此工作」上，效果往往不如一个 Agent 顺序干完。正确的拆分边界是「上下文」而不是「职能」：谁掌握某块信息，谁就把这块负责到底；只有当子任务需要的背景信息、上下文知识完全不同时，才值得拆。

判断真伪的标准（三个问题）：

1. 拆开后上下文是否真的隔离了？——如果所有子任务都要看同一份长文档，拆开只会每份都重读一遍
2. 角色之间是否有真实的信息壁垒？——研究员和审稿人若看到的东西完全一样，「独立视角」就是假的
3. 协作是否有真实开销？——如果「协作」只是把 A 的输出拼给 B，那只是顺序调用，不是多 Agent

经验法则升级版：先证明单 Agent 不够（上下文冲突、职责冲突、并行需求），再拆；拆的时候先拆「上下文」，再拆「角色」。 多 Agent 的价值来源是上下文隔离，不是「数量多」。

延伸阅读

• 《Building Multi-Agent Systems: When and How to Use Them》（Anthropic，2024.12）——多 Agent 的「为什么/何时/怎么」权威解读
• 深度版：Agent 核心 12 · 多 Agent 与选型策略、LangGraph 10 · 多 Agent 架构