一张白板讲透多智能体系统：架构、成本与三大教训

多智能体系统正在成为AI应用的热门架构，但很多团队在没搞清楚适用边界的情况下就仓促上马，结果token账单暴涨、效果却不升反降。一个来自YouTube的科普视频用一张白板的篇幅，把多智能体系统的动机、接线方式、成本和工程教训讲得相当清楚。本文基于该视频内容，结合Anthropic和OpenAI的公开资料做交叉梳理。

为什么需要多个智能体？

Anthropic将多智能体系统定义为：多个LLM智能体在循环中使用工具，协同完成工作。这个定义里有两个关键词——"循环"和"协同"。单个智能体在循环中调用工具的能力，是上一期内容讨论的基础；而多智能体的核心增量，在于把工作拆分给多个独立运行的智能体。

视频给出了三个使用多智能体的理由。

第一，研究类任务是开放式的。你很难预先预测需要哪些步骤，因此无法硬编码一条固定路径。传统工作流适合流程确定的场景，而开放式研究更适合让智能体自主规划。

第二，上下文压缩。子智能体并行工作，每个都在自己的上下文窗口中运行，再把最重要的信息压缩后返回给主智能体。这让主智能体不必被海量原始信息淹没。

第三，关注点分离。每个子智能体拥有自己的工具、提示词和探索路径。据视频作者的说明，Anthropic的内部评估显示，这类系统在广度优先查询上表现突出——也就是同时探索多个独立方向的任务。

一个值得注意的数据是：在某次测试中，主智能体使用Opus 4、子智能体使用Sonnet 4的组合，在Anthropic内部研究评估上比单独使用Opus 4高出90.2%。这说明"强主脑+快子脑"的异构搭配可能优于单一强模型。

它为什么有效？答案主要是token

多智能体系统性能提升的机制，很大程度上可以归结为"花足够多的token"。

在Anthropic的BrowseComp分析中——这是一项寻找难以找到的信息的测试——仅token使用量一项就解释了80%的性能差异。这个结论的含义很直接：多智能体带来的提升，有一部分并非来自更聪明的架构，而是来自更大的计算投入。

理解了这一点，就能理解后面的成本问题。

BrowseComp 是 OpenAI 于 2025 年发布的基准测试，专门评估模型在开放网络上“寻找难以找到、难以定位的信息”的能力。题目设计成答案简短但需要多步检索与交叉验证，例如「某位特定学者的某篇冷门论文的第三作者是谁」这类问题。由于任务本身高度依赖搜索广度与信息整合深度，它常被用来衡量智能体系统的检索与综合能力。Anthropic 在分析中引用该基准，正是因为它能暴露「架构 vs. 计算投入」的贡献比例——结果发现仅 token 使用量就能解释 80% 的性能差异，这说明在开放式检索任务上，多智能体带来的增益很大程度是「用更多算力换更全的探索」，而非架构本身带来的智能跃迁。

系统是怎么接线的

视频用一个完整流程描述了多智能体研究系统的典型接线方式：

用户的查询首先到达主智能体，主智能体规划研究方法，并把计划保存到记忆中。这里有一个工程细节：上下文窗口超过200,000 token后会被截断，因此计划需要落到外部记忆里。

接着主智能体创建若干子智能体，数量不限，每个子智能体分配一个具体的研究任务。子智能体搜索网页、评估结果、返回发现。主智能体对返回结果做综合，判断是否需要更多研究。如果需要，它可以创建更多子智能体，或者调整策略。

当信息足够时，一个引用智能体负责找到每条论断的出处，确保所有主张都能追溯到来源，最后结果返回给用户。

成本账：4倍与15倍

多智能体的代价在token消耗上体现得非常明显。据视频引用的数据，智能体使用的token大约是普通对话的4倍，而多智能体系统大约是15倍。

这意味着任务本身必须足够有价值，才值得为性能提升支付这笔费用。视频明确指出了不适用的情况：当智能体之间必须共享同一上下文，或者高度相互依赖时，多智能体是糟糕的选择。大多数编程任务的并行度就低于研究任务。

适合多智能体的场景有几个共同特征：任务价值高、高度可并行、信息量超过单个上下文窗口、需要多种复杂工具。

上下文窗口指模型单次推理能处理的 token 总量上限，它同时是模型的「工作记忆」和硬性成本边界。原文提到超过 200,000 token 后会被截断，意味着主智能体无法把所有子智能体的原始返回都保留在上下文中——这正是「上下文压缩」动机的由来：子智能体各自在自己的窗口内消化海量原始信息，只把提炼后的结论回传，从而让主智能体的窗口专注于规划与综合。理解这一点也能解释为何多智能体的 token 成本约为普通对话的 15 倍：每个子智能体都拥有独立的上下文窗口，等于并行开启了多份「工作记忆」，每份都要为系统提示词、工具定义和历史对话付费。

三条工程教训

早期智能体犯过一些典型错误，比如为简单查询生成50个子智能体。视频总结了三条教训。

教训一：教会主智能体如何委派。 每个子智能体都需要明确的目标、输出格式、工具和来源，以及清晰的任务边界。委派描述含糊，子智能体就会跑偏。

教训二：按查询复杂度缩放投入。 通过提示词中的规则来控制规模。简单的事实查找只需要一个智能体、三到十次工具调用；复杂研究则可能用到十个以上的子智能体。

教训三：并行化。 主智能体一次启动三到五个子智能体，每个子智能体并行使用三个以上的工具。据视频数据，这让复杂查询的研究时间最多缩短了90%。

两种交接模式：agents as tools 与 handoffs

多智能体如何交接工作？在OpenAI的Python Agents SDK中，有两种最常见的编排模式。

Agents as tools（智能体即工具）。 一个管理者智能体保持对对话的控制，把专家智能体作为工具来调用。适合由一个智能体对最终答案负责的场景。

Handoffs（交接）。 一个分诊智能体把对话路由给某个专家，由该专家接管本轮后续的处理。适合专家应当直接回应用户的场景。两种模式也可以组合使用。

Claude Code同样有子智能体机制，它们在单个会话内工作，每个都运行在自己的上下文窗口中，拥有自定义系统提示词、特定工具访问权限和独立权限。

另外需要澄清一个常见误解：A2A（AI智能体之间的开放通信标准）既不是子智能体协议，也不是工具调用协议。视频建议，子智能体和工具调用应使用框架原生原语或MCP。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底开源的标准化协议，用于让 LLM 应用以统一方式连接外部工具与数据源。它把「工具提供方」和「模型调用方」解耦：工具只需实现一次 MCP 服务端，任何支持 MCP 的客户端（如 Claude Code、各类 IDE 插件）都能直接调用，无需为每个框架重复适配。原文建议子智能体和工具调用优先使用框架原生原语或 MCP，正是因为 MCP 解决的是「模型如何访问工具」这一层问题，而 A2A 解决的是「智能体之间如何发现与通信」这一层问题，两者层次不同、不可互相替代。混淆二者会导致用错抽象层，增加不必要的复杂度。

一句话总结与落地建议

主智能体把开放式工作拆分给拥有各自上下文窗口的子智能体，当任务值得额外token时，这笔投入就有回报。用于有价值、可并行的工作；当智能体必须共享上下文或相互依赖时，跳过它。

最重要的建议是：从简单方案开始。先找到尽可能简单的解法，只在确有必要时才增加复杂度。多智能体不是默认选项，而是一把在特定场景下才值得拔出的工具。