01 为什么需要多 Agent：先把「我要多 Agent」翻译成人话

一句话讲透：多 Agent 不是”更高级的架构”，而是”分工”——当一件事一个人扛不住（上下文太长、工具太多、要同时干几件事）时，才拆成几个人干。拆之前先证明一个人真的扛不住。

官方先泼的一盆冷水#

原文开头就提醒：

Multi-agent systems coordinate specialized components to tackle complex workflows. However, not every complex task requires this approach—a single agent with the right (sometimes dynamic) tools and prompt can often achieve similar results.

（多 Agent 系统协调”专业化组件”来对付复杂工作流。但并不是每个复杂任务都需要它——一个 Agent 配上合适的（有时是动态的）工具和提示词，往往能达到差不多的效果。）

说人话：

多 Agent = 多几次模型调用 = 更贵、更慢、更容易出故障（多一个环节就多一个出错点）。
所以它换来的必须是单 Agent 真做不到的东西：上下文隔离、并行、团队分工。
如果你只是因为”一个 Agent 的提示词写得太乱了”，那先重构提示词和工具，别急着拆 Agent。

🧭 补充解读（非原文）：这和工程里的常识一致——微服务不是”比单体高级”，而是”当团队规模、部署边界、性能隔离真的需要时”才拆。拆早了，你得到的是分布式系统的全部麻烦，却没有它的收益。

你说”我要多 Agent”，其实是想要这三件事之一#

原文说，开发者说需要 multi-agent 时，通常想要的是下面三种能力之一（或几个）：

诉求	原文叫法	说人话	典型症状	常见对应模式
上下文管理	Context management	给 Agent 专业知识，但别把上下文窗口撑爆	提示词越写越长，塞了一堆用不上的资料，模型开始”看漏”	Skills、Subagents
分布式开发	Distributed development	不同团队各管一块能力，边界清晰，再组装成大系统	一个巨大的提示词/工具集，谁都不敢改	Subagents、Skills
并行化	Parallelization	给子任务开专门 worker，并发跑完更快	串行问三个领域，用户等到怀疑人生	Subagents、Router

原文对第一点有一句很关键的话：

If context were infinite and latency zero, you could dump all knowledge into a single prompt—but since it’s not, you need patterns to selectively surface relevant information.

（如果上下文无限大、延迟为零，你完全可以把所有知识一股脑塞进一个提示词——但现实不是这样，所以你需要一些模式来有选择地把相关信息端上来。）

什么时候真的该上多 Agent#

原文给了三类”确实值得”的场景：

场景	症状	为什么单 Agent 会崩
工具太多，选不准	一个 Agent 挂了 30+ 个工具，经常调错	工具描述全挤在一个上下文里，模型分不清该用哪个
需要”专业 + 大量上下文”	每个领域都有长提示词 + 专用工具	全量加载 → 上下文爆掉、成本飙升、注意力被稀释
有顺序约束	必须”先登记保修，才能分类问题，再决定维修/换货”	单 Agent 很难可靠地”锁住”流程，容易跳步

💡 提示：官方文档特别强调，多 Agent 设计的中心是上下文工程（context engineering）——决定每个 Agent 到底看到哪些信息。你的系统好不好，基本取决于”每个 Agent 手里那份材料是不是刚刚好”。

一张图看懂：为什么”分工”能省上下文#

1
【单 Agent 硬扛】所有知识 + 所有工具都塞进同一个提示词
2
┌─────────────────────────────────────────┐
3
│ 系统提示：产品文档 + 工单库 + 论坛问答…全量 │ ← 上下文越塞越长
4
│ 工具清单：40 个                          │ ← 工具越多，越容易选错
5
└─────────────────────────────────────────┘
6
              │
7
              ▼
8
     一次模型调用要扛下所有事：慢、贵、还容易幻觉
9

10
【多 Agent 分工】每个 Agent 只带自己那份上下文
11
┌───────────┐   ┌───────────┐   ┌───────────┐
12
│ 产品文档   │   │ 工单库     │   │ 论坛问答   │  ← 上下文互相隔离
13
│ ~2K token │   │ ~2K token │   │ ~2K token │
14
└───────────┘   └───────────┘   └───────────┘
15
        └───────────────┬───────────────┘
16
                        ▼
17
            主管 / 路由：只负责"派活 + 汇总"

那”少即是多”的边界在哪：先试试这些更简单的做法#

🧭 补充解读（非原文）：原文只说了”单个 Agent + 合适的工具和提示词常常就够”。结合实际工程，下面这些更便宜的手段应该先用完，再考虑多 Agent：

你真正的问题	先试这些（成本低得多）
提示词太长太乱	精简提示词、把稳定知识放系统提示、把易变信息放检索
工具太多选不准	给工具改好名字/描述；按场景动态挂载工具；工具分组
需要固定几步流程	普通代码 `if/match` + 函数编排（确定性逻辑根本不需要 LLM 决策）
需要专业知识	检索（RAG）或”技能”按需加载（见 `06`）
只是嫌慢	并行工具调用、流式输出，而不是拆 Agent

只有当”必须让模型动态决定派谁、并且上下文必须隔离”时，多 Agent 才是正确答案。

官方已经内置了一套：Deep Agents#

原文的提示框里写了：

想要开箱即用的多 Agent 支持，用 Deep Agents：它是构建在 LangChain 之上的更高层封装，自带 subagents（子智能体）、skills（技能）、planning（规划）、虚拟文件系统、上下文管理。

说人话：

本系列文档（01–12）教你的是怎么自己搭这些模式，理解原理、能按需改造。
Deep Agents 是”已经搭好的一套”，适合你不想自己写编排的时候。
两者不冲突：理解了本文档的模式，你用 Deep Agents 时才知道它内部在干什么、什么时候该绕开它。

小结#

多 Agent 的本质是分工：把”上下文 / 团队边界 / 并行”三件事里的至少一件，从”一个人扛”变成”几个人各扛一块”。
默认答案是单 Agent：只有当工具多到选不准、单域上下文长到爆、或流程有硬顺序约束时，才升级。
它是有代价的：调用次数变多（见 03 的实测对比），链路变长，出错面和调试难度都上升。
设计重心是上下文工程：不是”我分了几个 Agent”，而是”每个 Agent 看到的信息是否刚好”。
Deep Agents 提供内置实现：想少写编排代码，可以直接用它。

一句话选型#

该上多 Agent：工具有几十个且选不准；单域知识上下文太长；需要并行处理多个领域；需要”先 A 后 B”的强顺序约束。
别上多 Agent：只是提示词乱、只是想更快、只是流程固定几步——这些用精简提示词、动态工具、检索或普通代码编排就能解决。

下一篇：02 五种模式总览与选型 — 认全 Subagents / Handoffs / Skills / Router / Custom workflow 五张脸，再学会挑。