子代理与多代理系统如何分配任务与成本令牌。
子代理与多代理系统：协调者-工作者设计、四种拓扑结构、每种结构的代币成本，以及单代理表现更佳的情形。
来源: Subagents vs. Multi-Agent Systems: The Complete Guide to How AI Agents Actually Work Together
为何单个智能体会有性能上限
凡是看过《Claude Code》、《LangGraph》或Claude的研究功能演示的人，都见过这样的场景：助手不再自行回答问题，而是去寻求帮助。这时会出现一个文件检索助手，它四处查找后带回结果；而研究功能则能在人打开两个标签页的时间里悄悄查阅数十个资料来源。这并非模型突然变聪明了，而是有小型团队在背后处理工作。
下文将简要介绍这种团队协作是如何形成的，涵盖子智能体、多智能体系统、其底层架构以及相关成本。
单个智能体，即通过工具在循环中运行的一个模型，确实具备相应能力。它能读取文件、浏览网页、编写代码，并进行多步骤推理。不过，设计中已预设了三个限制：
- 一个上下文窗口。智能体所读取、思考和执行的所有内容都集中在同一个空间内。在漫长的探索任务中，工具的输出最终会使得初始问题被忽视。
- 单一执行流程。所有操作都是按顺序进行的。如果进行50次搜索，每次耗时2秒，那么在开始任何输出之前就需要超过90秒的时间。
- 单一视角。单个提示词决定了所有的决策，因此智能体很难同时考虑两种相互矛盾的方案，也难以发现自身的盲点。
子智能体与多智能体系统是解决这一问题的两种方法，通常会结合使用。后续内容将介绍这两种方法的定义、构建方式以及何时能带来实际效益。
什么是子智能体
子代理是在单个会话中启动的、功能范围有限的辅助工具。它在独立的上下文窗口中处理单一的特定任务，处理完成后再反馈结果。
Claude Code就是一个很好的例子。如果主编码会话需要理解代码库中某些陌生的部分，它可以将探索任务交给子代理，从而避免干扰主对话流程。子代理会：
- 以一个全新、干净的上下文窗口开始工作
- 通常只配备数量较少且功能受限的工具
- 自行执行阅读、搜索和推理的闭环流程
- 向父会话发送总结，并将对话记录保存在自己那里
这里的重点在于隔离性，而非额外的智能功能。主对话流程不会看到助手打开的五十个文件，只会看到其中重要的三句话，因此即使在长时间的会话中，主线程也能保持清晰，不会被冗余信息充斥。
像 Claude Code 这样的工具在实现该模式时具有以下几大特点：
- 子代理存在于同一个会话中。它们是一种任务分配方式，而非独立的运行进程。
- 它们通常无法自行启动其他子代理，这使得层级结构保持扁平，便于理解。
- 子代理的定义只需编写一次即可重复使用。为审核用子代理设定固定的系统提示和简短的工具列表，它在每次被调用时都会表现出完全一致的行为。
什么是多智能体系统
多智能体系统的结构有所不同。多个独立的智能体各自拥有自己的上下文、工具，有时还有自己的模型，共同追求一个目标，这一过程通常比单次任务委托要漫长或复杂得多。
Anthropic的Research功能是最著名的公开案例。面对一个宽泛的问题时，不会直接给出答案。相反，一个主智能体会制定解决方案并生成多个子智能体，这些子智能体会同时从不同角度展开研究。它们的结果会被整合，检查引用是否准确，最终以一个统一答案的形式返回。
总体而言，主导智能体、并行专家智能体以及最终综合步骤构成了当今大多数生产型多智能体系统所采用的模式，也正是本文后续部分要探讨的设计。
两种概念的差异
网络上这些术语经常被混用，从而造成混淆。此处展示了它们之间的实际区别。
最简单的记忆方法是：子智能体是在智能体内部使用的一种技术，而多智能体系统则是围绕多个智能体设计的架构。实际上，许多多智能体系统都是基于子智能体模式构建的。那些使用子智能体的主导智能体同时具备这两种属性。
协调器与工作节点架构
几乎所有的生产级多智能体系统，包括 Anthropic 的 Research 功能、LangGraph 的监督者模式以及 Claude Code 的子智能体模型，都属于同一设计模式的变体：协调者与执行者。
每个组件都有特定的职责：
- 主导智能体（协调者）。它负责读取查询，制定策略，并判断该任务需要投入多少精力。这一判断的重要性往往超出人们的想象。这些系统的早期版本有时会为一个仅需一个子智能体就能处理的问题启动五十个子智能体。
- 内存或临时存储区。计划内容会被记录在对话之外。长时间的智能体运行可能会超出模型的上下文窗口限制，如果这种情况在运行过程中发生，计划就必须保留下来，不能随模型内容被截断而消失。
该图使用了两种箭头。实线箭头表示任务向下传递，虚线箭头则表示汇总后的结果向上传递。这种不对称设计是刻意为之：子代理返回的是提炼后的结果而非完整的处理历史，这样可以避免主导代理的上下文信息过载。
从问题到答案的工作流程
抛开各个组件不谈，以下是从用户输入的问题到最终答案产生的事件顺序。
其中有几步值得注意：
- 第2步（先思考再规划）的重要性超出想象。系统会在这一阶段确定处理该查询所需的投入力度：简单的事实核查可能只需要一个代理和几次工具调用，而范围较广的问题则可能需要十个或更多职责明确的子代理。
多种智能体配置方式
协调者与执行者是常见的架构，但并非唯一选择。根据任务的实际拆分方式，四种通用拓扑结构中会有一种比其他更适用。
当难以决定选择哪种架构时，开发团队通常会遵循一条经验法则：对于要投入生产的系统，优先采用带有监督节点的层级结构；而对于那些流程无法提前确定的探索性或研究性工作，则保持网络或网格布局。 网格设计在图表上看起来很美观，但也是最难调试的。
其有效原因：代币经济模型
明确说明多智能体系统为何能在某些任务上优于单智能体系统是很有帮助的，因为答案并非“智能体越多，能力就越强”。
在Anthropic的内部评估中，以Claude Opus 4作为主导智能体、Claude Sonnet 4作为子智能体的组合，在一项内部研究基准测试中的表现比单独使用Claude Opus 4的智能体高出90.2%。分析其原因后发现，处理能力是主要因素。在一项复杂搜索基准测试中，令牌使用量就占据了性能差异的约80%，而工具调用次数和模型选择则解释了剩余的大部分差异。
简而言之，在需要处理大量信息的广度优先任务中，优势主要来自处理能力。将任务分配到多个独立的上下文窗口中，能让系统拥有远超过单个窗口的推理空间，而且每个子智能体都会将其读取的内容压缩成简短的报告。
这种处理能力并非免费。实际数据表明，基于智能体的工作流所消耗的令牌量大约是普通对话交互的四倍，而多智能体工作流则高达十五倍左右。这一倍数决定了该架构是否值得使用，这也引出了下一个要点。
何时多智能体系统并非合适选择
大多数关于智能体架构的论述都会跳过这一部分，而恰恰是它能够节省时间和令牌预算。
任务必须拆分为完全独立的子任务。如果各子任务之间存在高度依赖性，将它们分配给不同智能体处理只会增加协调成本，且无法实现真正的并行处理。那些可以清晰拆分的研究问题适合用多智能体系统，而试图用一个整体函数来完成的任务则通常不适合。
编程是最明显的反例。 Anthropic 自身的说明也很直白：大多数编程任务的可并行子任务数量少于研究工作，而且目前的智能体还无法可靠地实现实时协作与任务传递。其他基准测试也得出了相同结论。一项学术评估发现，多智能体编程系统的token消耗量是同类单智能体的4倍到200多倍；另一项行业分析则显示，在严格依赖顺序处理的任务中，多智能体系统的表现比单智能体差39%到70%。
错误会蔓延。 单个智能体中的错误原本只是单一错误，但在协调系统中，它可能通过任务传递不断扩散。有分析指出，在集中式协调下错误会放大约4倍，而当智能体独立运作且缺乏协调时，情况会更糟。
收益必须足以覆盖成本。由于倍率接近15倍，多智能体设计适用于高价值、高复杂度的工作，如深度研究、多领域分析以及大规模代码重构。对于那些通过合理引导且配备良好工具的单智能体就能一次完成的任务，使用多智能体设计则是过度设计。
有一个简单的测试方法：如果无法明确界定每个智能体应负责哪些工作而其他智能体不应负责，那么解决方案很可能是强化单个智能体，而非增加更多智能体。
构建多智能体系统的经验教训
Anthropic对其研究系统的回顾堪称最坦诚的公开分析，揭示了当演示版本转变为实际生产环境的多智能体系统时会出现哪些问题。其中最具参考价值的经验教训总结如下：
- 提示语是关键所在。由于提示语会引导每个智能体，因此协调者分配任务时的细微用词差异，会极大影响子智能体是重复工作还是出现空白。
- 过于宽松的授权会导致重复劳动。像“研究半导体短缺问题”这样的简短指令看似清晰，实则不然。在早期的系统中，由于没有明确标注某项任务的结束点，多个子智能体会探索相同的方向。一个好的指令应明确目标、期望的输出格式以及每个智能体职责的范围。
该模式的简化概述
以下是对协调器与工作节点的简化、与具体框架无关的概要描述。为便于看清逻辑结构，此处省略了重试、流式处理和持久化存储等功能，该内容可作为伪代码，用于移植到 LangGraph、Claude Agent SDK 或单纯的 API 循环中。
def run_research(query: str) -> str:
# 1. Lead agent plans
plan = lead_agent.think_and_plan(query)
memory.save("plan", plan) # survives context truncation
findings = []
subtasks = plan.subtasks # explicit objective + boundaries per subtask
# 2. Spawn subagents in parallel, not sequentially
results = run_in_parallel([
subagent.execute(task=subtask, tools=subtask.allowed_tools)
for subtask in subtasks
])
findings.extend(results)
# 3. Lead agent decides: enough evidence, or loop again?
while not lead_agent.has_sufficient_evidence(findings):
new_subtasks = lead_agent.refine_plan(findings)
more_results = run_in_parallel([
subagent.execute(task=t, tools=t.allowed_tools)
for t in new_subtasks
])
findings.extend(more_results)
# 4. Synthesize, then verify citations in a separate pass
draft = lead_agent.synthesize(findings)
cited_answer = citation_agent.attach_citations(draft, findings)
return cited_answer
有两个细节最值得关注，而它们往往不会出现在示例中。首先是run_in_parallel：逐个调用子智能体会大大降低加速效果。其次是用于重新规划的显式while循环，因为当第一次处理后问题多于答案时，固定轮次的子智能体无法做出调整。
发布前的检查
在发布子智能体或多智能体工作流之前，请检查以下几点：
- 每个子智能体都有明确的目标、输出格式和任务边界，而不仅仅是简短的一行指令。
- 在子智能体真正独立的情况下，让它们并行运行。
- 计划应保存到存储中，而不仅仅存在于对话中，以防上下文被截断。
相关阅读
- 当两个智能体战胜一个：一种可双向使用的LangGraph代码审查辅助工具 — 在LangGraph中分别将代码审查功能构建为单个智能体，以及作为分析器与风险审查器的组合，进而了解在哪些情况下使用多智能体系统更值得。
- 实用指南：成为排名前1%的Hermes智能体用户：完整操作手册（无） — 详细介绍了《实用指南：成为排名前1%的Hermes智能体用户：完整操作手册（无）》中的内容，包括合同模板、检查清单以及供采用该模式的团队直接使用的代码片段。