多 agent 架构的直觉吸引力很强：把复杂任务拆给若干个「专家」，各司其职，像一个团队一样协作。但在动手之前，需要先看清它真正提供了什么、以及收走了什么。
multi-agent（多智能体）真正提供的是并行探索能力。多个 agent 各自拥有独立的上下文窗口，可以同时在不同方向上搜集信息、试验方案。对于一个「需要看 50 份资料才能下结论」的任务，单 agent 必须串行地把 50 份资料挤进一个窗口（还要面对 lost in the middle），而 5 个 subagent 可以各看 10 份、各自提炼，再汇总。这是实打实的容量扩展，不是修辞。
它收走的是共享上下文。这是多 agent 最根本、也最容易被低估的代价。同一个 agent 内部，第 7 步天然知道第 3 步发生了什么——信息是连续的。而两个 agent 之间，信息只能通过它们交换的那几段文字传递。所有没被写进消息里的隐含判断、试过但放弃的路径、微妙的上下文，全部丢失。
把它类比成团队协作会更清楚：一个人做完一件事，和五个人分工做完同一件事，后者需要额外付出沟通成本，而且沟通必然有损。人类团队之所以还值得分工，是因为人有真正的并行能力和专业差异。多 agent 也一样——只有当并行带来的收益，大于上下文割裂带来的损失时，它才是对的。
把上面的分析收敛成一条可操作的判断线：
| ✓ 适合多 agent | ✗ 不适合多 agent | |
|---|---|---|
| 子任务关系 | 互相独立，可并行 | 紧密依赖，后一步取决于前一步的细节 |
| 信息流向 | 读取为主（搜集、调研、检索） | 写入为主（修改同一份产物） |
| 汇总方式 | 结果可以简单拼接或归纳 | 需要全局一致性，局部结果无法独立成立 |
| 典型任务 | 多方向资料调研、多来源信息交叉验证、大规模并行检索 | 写代码、编辑一份文档、需要通盘权衡的方案设计 |
写代码是最经典的反例。修改一个函数需要知道其他文件里的约定、刚才改过什么、整体设计意图是什么。让三个 agent 并行改三个文件，它们会各自做出局部合理但彼此冲突的决定——变量命名不一致、接口假设不匹配、重复实现同一个工具函数。合并这些冲突的成本，往往高于一开始就串行做。
大量多 agent 设计其实是在解决本可以更简单解决的问题：
① 更好的工具。很多「需要一个专门的 agent」的场景，本质是需要一个更好的工具。「让一个 SQL agent 负责查数据」通常不如「给主 agent 一个设计良好的查询工具」（4.1）——后者少一层上下文传递，少一处失败点。
② 代码编排 + 单 agent。如果流程是确定的，用代码写死编排逻辑，每一步调用单 agent 或直接调用模型。确定性的部分交给代码，不确定的部分才交给模型（4.2）。这比让一个「主 agent」去动态调度可靠得多，也便宜得多。
③ 单 agent + 上下文压缩。如果问题只是上下文装不下，先试 4.3 的压缩与外部化策略。这比引入多 agent 的复杂度低一个数量级。
Anthropic 公开分享过他们构建多 agent 研究系统的工程经验。这份材料的价值在于，它同时给出了收益和代价——这在多 agent 的讨论中很少见。
务必连条件一起记：90.2% 是特定模型搭配（Opus 4 领队、Sonnet 4 做子 agent）对单 agent Opus 4 的对比，评测是他们内部的研究类任务集，其典型形态是需要多个独立方向并行展开的广度优先查询（例如「找出标普 500 信息技术板块所有公司的董事会成员」）。这个任务形态本身就是多 agent 的最佳场景——换成紧耦合任务，结论会完全不同。
第三、四个数字才是这份报告里最有信息量的部分。如果 token 用量单独就能解释约八成的性能方差（再加上工具调用次数与模型选择，三者合计解释 95%），那么意味着：多 agent 的大部分收益并非来自「多个专家协作」这种架构魔法，而是来自「投入了多得多的计算」。这个认识会立刻改变你的评估方式——比较多 agent 与单 agent 时，必须在相当的 token 预算下比较，否则你测的只是「花更多钱效果更好」，那几乎是必然的。
关于适用边界，这份材料的判断与本章正文一致：多 agent 擅长可以拆成并行研究分支的问题，而对紧密耦合的任务（如写代码）效果较差。经济性上的结论也很直白——15 倍的 token 消耗意味着它只适用于任务价值明显高于计算成本的场景，例如法律尽调、竞品情报、生物医学文献综述这类高价值研究工作。
怎么用这份材料：不要把 90.2% 当作「多 agent 更好」的证据搬到自己的场景。要记住的是那个三元组——收益（并行探索）、代价（约 15× token）、适用条件（任务可并行拆分且价值高）。拿这三条去对照你自己的任务，通常会发现结论是「不该上」。
条件说明：上述数字来自厂商自身的公开工程报告，评测任务、基线设置与模型配置均由该团队定义，不构成跨场景可比的通用结论。把它当作一个有参考价值的工程案例，而不是一项独立验证的基准结果。
编排框架：LangGraph（以图结构定义状态与转移）、CrewAI（角色分工抽象）、AutoGen（多方对话式协作；已进入维护模式，官方建议新项目改用其后继 Agent Framework，后者 1.0 于 2026-04 发布）等各有侧重。选型前先确定你需要的是哪种拓扑——是「主从（orchestrator-worker）」「流水线」还是「自由对话」。这三种的可控性与调试难度差别极大，其中自由对话式最难在生产中控制。
最实用的形态是 orchestrator-worker：一个主 agent 负责拆解与汇总，若干 worker 并行执行独立子任务，worker 之间不互相通信。它的信息流是树状而非网状，可预测、可限流、可调试。多方自由对话虽然更「智能」，但轮数与成本难以预估，且极易陷入互相附和的循环。
成本控制是硬需求：多 agent 的成本方差极大，必须设置全局 token 预算与subagent 数量上限，并在超限时优雅降级。没有预算闸门的多 agent 系统会在遇到复杂输入时产生离谱账单。
可观测性要求更高：需要能看到每个 subagent 的完整轨迹以及它们之间传递的消息。只记录最终输出的多 agent 系统基本无法排查——你连是哪个 subagent 出的错都不知道。这类系统的调试成本本身就是它的一项重要代价。
A 技术调研 → 多 agent 合理。几十个来源可以并行查阅，每个来源的分析互相独立，结果可归纳汇总——三条判据全部满足。且这类任务是读取为主，不存在写冲突。这是多 agent 的标准适用场景。
B 重构模块 → 单 agent。典型的紧耦合任务：修改一个文件需要知道其他文件的接口约定与刚做出的设计决定。并行修改会产生命名不一致、接口假设冲突、重复实现等问题，合并冲突的成本高于串行完成的成本。如果上下文装不下 8 个文件，正确做法是改进检索与压缩（4.3），而不是拆 agent。
C 客服工单 → 都不是，用代码编排。这是本题的陷阱。「分类 → 检索 → 生成」是一个完全确定的流程，步骤固定、顺序固定、无需动态规划。正确做法是代码写死这三步，每步调用模型或直接调用检索——零 agent，零循环。给它套多 agent 架构是纯粹的过度设计，会让一个可预测的流程变得不可预测。
D 财报多角度分析 → 多 agent 可行，但先试单 agent。三个角度确实相对独立、可并行、可汇总，符合适用条件。但要先问一句：单 agent 分三次调用行不行？如果财报能放进一个上下文窗口，那么「同一份材料、三个不同的分析 prompt、并行调用」就能拿到全部并行收益，而不需要引入 agent 编排的复杂度——这本质上是三次独立的模型调用，不是多 agent。只有当每个角度都需要各自去检索大量额外材料时，真正的多 agent 才有必要。
核心影响：它把「架构对比」变成了一个必须控制变量的实验。
如果性能差异主要由投入的计算量驱动，那么「多 agent 比单 agent 好」这个结论在不控制 token 预算的情况下几乎没有信息量——你只证明了花更多钱效果更好，而这不需要多 agent 也能做到。
正确的对比方式：给单 agent 相当的 token 预算，让它用其他方式把这些预算花掉——更多轮的 ReAct 循环、更多次的自我检验、更大的检索召回量、对同一问题做多次采样再归纳。如果单 agent 在同等预算下表现相当，那么多 agent 带来的只是复杂度。
这个方法论可以推广：任何声称「新架构效果更好」的对比，都要先问「它是不是只是花了更多计算？」。这在 agent、prompt 技巧、集成方法的评估中普遍适用，也是识别真实创新与包装的有效手段。
反过来的实用推论：如果你确实愿意为某个任务花 15 倍的计算，那么多 agent 是把这些计算有效花出去的一种方式——尤其当单 agent 已经受限于上下文容量而无法继续吸收更多计算时。这才是多 agent 真正不可替代的地方：突破单一上下文的容量天花板。
这类开放题的最佳回答，是先质疑前提再给设计。
第一步：先论证为什么需要多 agent。明确说出三个必要条件——子任务可并行、彼此独立、结果可汇总；并说明已排除三个更简单的替代方案：更好的工具、代码编排 + 单 agent、单 agent + 上下文压缩。直接开始画架构图的候选人，通常没意识到多 agent 是最后的手段。
第二步：选最简单的拓扑。默认 orchestrator-worker——主 agent 拆解与汇总，worker 并行执行且互不通信。树状信息流可预测、可调试；避免多方自由对话，它的轮数和成本都难以约束。
第三步：设计 agent 之间的接口。这是最关键也最常被忽略的部分。因为每条边都是有损压缩，必须明确规定 worker 回传什么——结构化的结果 + 依据来源 + 置信度 + 未能完成的部分，而不是一段自由文本。接口设计的质量直接决定系统上限。
第四步：闸门与降级。全局 token 预算、subagent 数量上限、单个 worker 的超时；超限时优雅降级（返回已完成部分而非失败）。
第五步：可观测性与评估。记录每个 worker 的完整轨迹与传递的消息；评估时在同等 token 预算下与单 agent 对比，并按 4.5 的方法同时看结果指标与轨迹指标。
加分：主动说明什么情况下你会放弃多 agent 方案——例如发现子任务其实互相依赖，或发现单 agent 在同等预算下表现相当。