单 Agent 能处理很多事，但当任务足够复杂时，单个 Agent 会面临两个核心瓶颈：
- 上下文窗口有限：塞太多信息会导致性能下降。LLM 的上下文窗口再大（200K token）也不是无限的，而且长上下文会带来推理延迟和注意力分散。
- 注意力扩散：上下文过长时出现 Lost in the Middle 问题------信息放在开头和末尾容易被关注，放在中间则容易被忽略。这在多跳推理任务中尤其致命。
Anthropic 的研究表明：多个独立上下文的子 Agent 比单个大上下文的 Agent 效果更好。
一、为什么需要多 Agent
典型问题场景：一个 Agent 同时搜索公司文件和实时法律法规，上下文里同时包含内部文档和外部网页。当上下文越来越长后，LLM 的注意力开始混乱------它可能在网页搜索时误用了公司内部文件的上下文，或者在回答公司内部问题时引用了过时的网页信息。
多 Agent 通过分离记忆和分工并行来解决这些问题。每个子 Agent 只关注自己的上下文，不受其他领域信息的干扰。
除了注意力问题，还有两个驱动因素：
- 工具隔离：不同子任务需要不同的工具集。搜索 Agent 只需要 Search tool，写作 Agent 只需要 Write tool。混在一起反而让 LLM 难以选择。
- 故障隔离：一个 Agent 出问题（死循环、幻觉）不影响其他 Agent。
二、Supervisor 架构
最常见的多 Agent 模式是 Supervisor 架构：
bash
用户请求
└─ Supervisor Agent（主管/项目经理）
├─ Worker Agent 1（搜索论文）
├─ Worker Agent 2（搜索新闻）
└─ Worker Agent 3（搜索专利）
- Supervisor Agent：负责任务分配和协调，根据任务特点分配给合适的工人 Agent。Supervisor 本身不做具体执行工作，它只做"调度"。
- Worker Agents：各自负责特定子任务，有独立 Context 和 Tool 配置。Worker 之间不直接通信，所有通信通过 Supervisor 中转。
Supervisor 架构的变体还有：
- Peer-to-Peer 架构：Agent 之间直接通信，没有中央协调者。适合 Agent 数量少、协作需求简单的场景。
- Pipeline 架构：Agent 按固定顺序串联，前一个的输出是后一个的输入。适合有明确流程线的任务（如数据采集→清洗→分析→报告）。
- Debate 架构：多个 Agent 对同一问题给出答案，然后通过讨论/辩论达成共识。适合需要多角度分析的高复杂度决策。
类比：项目经理分配任务给团队成员的流程。
三、多 Agent 的优势
| 优势 | 说明 |
|---|---|
| 分离记忆 | 每个 Agent 只处理自己的子任务上下文，避免注意力扩散 |
| 分工并行 | 多个 Agent 可以同时处理不同子任务，提升效率（IO 密集型任务尤其明显） |
| 专业化 | 每个 Agent 可以专注特定领域，配置专属的 Tools 和 Skills，效果更好 |
| 故障隔离 | 子 Agent 出问题不影响主系统 |
四、实际应用场景
- 复杂研究：一个 Agent 搜论文，一个搜新闻，一个搜专利，Supervisor 汇总结果。三个搜索可以并行进行，大幅缩短响应时间。
- 代码开发：一个 Agent 写前端，一个写后端，一个写测试，一个做 Code Review。每个 Agent 只需要关注自己的代码上下文。
- 客服系统：一个 Agent 处理退款流程（需要访问财务系统），一个处理技术支持（需要访问知识库），一个识别恶意用户（需要访问风控系统）。工具隔离保护了系统安全。
- 数据分析管道：数据采集 Agent → 数据清洗 Agent → 分析 Agent → 报告生成 Agent，Pipeline 架构串联。
五、什么时候不需要多 Agent
多 Agent 不是银弹，它也有代价：
- 复杂度上升：需要设计 Agent 间通信协议、任务分配策略、结果汇总逻辑
- 成本增加：多个 LLM 调用比单个调用更贵
- 延迟增加：Agent 间通信和协调需要时间
- 调试困难：问题可能出在任何子 Agent，排查难度大
核心判断标准：如果单 Agent 的上下文能装下所有信息，就不要用多 Agent。 只有当你明确遇到上下文太长、注意力扩散的问题时，再考虑多 Agent 架构。
