本文永久链接 – https://tonybai.com/2026/11/05/agent-swarm-vs-single-agent-architecture

大家好，我是Tony Bai。

【导读】

多 Agent 是 AI 工程领域最热门的架构方向之一。把任务交给多个专业 Agent 并行执行，看起来既能提升效率，又能突破单个模型的能力边界。

但现实正在变得复杂：有些团队花费数月搭建复杂的多 Agent 系统，最后发现，一个配置得当的单 Agent 就能完成同样的工作。

与此同时，另一批研究者却认为，真正强大的 Agent 系统需要更多能够长期存活、共享知识、彼此协作的 Agent。

这两种观点真的矛盾吗？

结合 Hallerite 的《On the Nature of the Swarm》和 Anthropic 的《Building agents: When to fold subagents into your main agent loop》，我们可以看到：单 Agent 与多 Agent 的争论，表面上是架构选择，底层其实是上下文容量、信息损失和协调成本之间的权衡。

【文章要点】

  1. 多 Agent 的价值不只是并行。独立上下文可以让系统同时保留多份工作记忆，避免所有信息都挤进一个窗口。
  2. 上下文压缩不是免费的。摘要、文件外置和 Subagent 交接，都可能丢失重要信息；持久化 Agent 则有机会保留已经建立的上下文。
  3. 复杂架构不等于高性能。如果任务不需要独立上下文、并行执行或专业化隔离，多 Agent 的协调成本可能超过收益。
  4. 固定的树状结构有扩展瓶颈。大规模 Agent 系统可能需要共享状态、横向通信和动态形成的专业分工。
  5. 高效架构应该允许合并与拆分。通过端到端评测，决定哪些能力应留在主循环中，哪些值得独立成为 Agent。

多 Agent 大概是眼下 AI 工程领域最热门的架构方向之一。

一个 Agent 负责规划，另一个负责研究，还有专门的 Agent 编写代码、执行测试、检查结果。把复杂任务拆给一群专业 Agent 并行处理，看起来就像给 AI 团队配备了一整套组织架构。

但问题来了：Agent 越多，系统真的就越强吗？

Anthropic 最近提出了一个值得关注的反直觉观点：在不少企业应用中，团队花费大量精力搭建的多 Agent 系统，最终可能不如一个配置合理的 Single Agent。与此同时，研究者 Hallerite 在《On the Nature of the Swarm》中提出了另一种方向：如果希望 AI 系统持续扩展能力，就应该让多个拥有独立上下文、能够长期存活并彼此交流的 Agent 协同工作。

一个主张减少 Agent，一个探索更多 Agent。看似矛盾，实际上指向了同一个问题：

如何用有限的上下文、推理计算和协调成本，完成更复杂的任务？

理解这个问题，可能比争论单 Agent 与多 Agent 谁更先进，更有助于我们设计真正高效的 Agent 系统。

Agent 越多，为什么不一定越强？

先看一种很常见的企业 Agent 架构。

用户提出需求后，系统先通过意图分类器判断任务类型，再交给规划 Agent。规划 Agent 调用若干专业 Agent，最后由汇总 Agent 整合结果。

这种架构并非没有价值。它可以隔离不同任务的上下文，赋予不同 Agent 不同的工具和权限，也能让相互独立的工作并行执行。

问题在于，很多系统在真正需要这些能力之前，就已经把任务拆得过细。

Anthropic 在 2026 年 10 月发布的文章《Building agents: When to fold subagents into your main agent loop》中指出，一些企业 Agent 系统存在明显的过度设计：每个业务团队都有自己的 Agent，中央团队再搭建一个编排层，将所有 Agent 连接起来。

结果是，系统越来越复杂，性能却未必提高。

每增加一个 Agent，系统就可能增加一套提示词、一个独立上下文、一条调用链，以及一处需要维护和评测的接口。Agent 之间还要反复传递信息，而每次传递都可能丢失细节。

Anthropic 提到，在他们观察到的一些实现中，多 Agent 系统的 Token 消耗可能达到单 Agent 的 3～10 倍；另一个客户的评估则发现，单 Agent 循环的运行速度约为多 Agent 方案的两倍。这些是特定场景中的观察，并非所有系统都适用的普遍规律。

因此，真正应该问的不是“能不能拆出更多 Agent”，而是：

拆分之后，究竟获得了什么单 Agent 无法经济地获得的能力？

如果答案只是代码组织更清晰，或者架构图看起来更专业，那么多 Agent 很可能并不值得。

真正的瓶颈：上下文，而不只是计算能力

要理解多 Agent 为什么有时有效、有时反而拖累系统，我们需要先理解上下文的作用。

Agent 执行复杂任务时，会不断读取文件、调用工具、运行测试、分析错误。这些操作积累的信息构成了它解决问题所需的上下文。

但上下文窗口并非无限。即使模型支持很长的上下文，也不意味着把所有信息都塞进去就是最好的选择。随着上下文增长，信息筛选、注意力分配和上下文管理都会成为实际问题。

Hallerite 的文章从这个角度重新解释了 Agent 的几种常见设计。

1. 上下文压缩：每次总结，都是一次下注

当 Agent 的上下文接近上限时，可以让它总结当前进展，再把摘要交给一个新的上下文继续工作。

这种机制通常称为 Compaction。

它让 Agent 可以连续工作很长时间，但存在一个根本问题：总结发生时，Agent 并不知道未来哪些细节会变得重要。

例如，一个编码 Agent 在排查间歇性测试失败时，发现了一条看似无关的日志。当天，它可能把这条日志视为噪声，没有写入摘要。

两天后，真正的故障原因却恰恰藏在这条日志中。

这并不一定意味着总结能力不够强，而是总结本身需要在有限的信息预算内，提前决定哪些信息值得保留。

2. 外部记忆：信息保留下来了，理解却不一定保留下来

另一个办法是把详细信息写入文件、数据库或其他外部存储。

这样，摘要只需要记录信息的位置，而不必承载所有细节。

但外部存储解决的是“信息是否存在”，不是“Agent 是否知道何时使用它”。

新的 Agent 仍然需要判断某份资料是否相关、找到它，再把内容读回上下文。更重要的是，之前的 Agent 已经建立起来的理解、排除过的假设和形成的判断，不会自动随着文件一起保存。

3. Subagent：让另一个上下文替你完成工作

现在，我们换一种方式。

主 Agent 不必亲自阅读整个代码库，可以启动一个 Subagent，让它专门调查重试逻辑在哪里，或者某个测试为什么不稳定。

Subagent 可以消耗大量上下文来完成调查，而主 Agent 只需要接收与问题有关的结论。

这里存在一个关键区别：主 Agent 可以在问题已经明确之后，才决定需要哪些信息。

这比提前猜测哪些细节值得写入摘要更灵活。

但临时 Subagent 也有缺陷：任务结束后，它的上下文通常就被丢弃了。下一次需要相关信息时，系统可能不得不重新读取代码、重新运行测试，再次完成相同的调查。

4. 持久化 Agent：让上下文成为可以反复调用的资源

Hallerite 进一步提出，可以让 Subagent 长期存活，而不是任务完成就销毁。

一个长期负责前端代码的 Agent，可以保留已经阅读过的代码、建立的理解以及积累的工具。当另一个任务需要前端知识时，系统可以直接向它提问，而不必从头开始。

这样，多 Agent 的价值就不再局限于并行执行。

它还可以让多个独立上下文长期共存，使系统能够保留比单个上下文窗口更广泛的工作状态。

需要注意的是，持久化 Agent 并不意味着信息永远准确。它仍然需要处理上下文压缩、知识过时、资源占用和状态同步等问题。

但它揭示了一个重要方向：多 Agent 不只是把计算并行化，也可以把上下文并行化。

为什么 Anthropic 又建议减少 Agent？

如果多个 Agent 可以扩展上下文容量，为什么 Anthropic 又建议把部分 Subagent 合并回主 Agent？

因为上下文并不是越多越好，独立上下文也不是没有代价。

Anthropic 认为，多 Agent 的收益主要集中在三种场景。

第一，主 Agent 的上下文污染已经影响任务表现。

当一个任务需要阅读大量无关资料、探索多条调查路径时，把探索过程隔离到 Subagent，可以避免主 Agent 的上下文被大量中间细节占据。

第二，任务确实可以并行执行。

例如，独立研究不同技术方案、检查互不依赖的代码模块，或者从多个方向验证一个假设。

如果任务之间有清晰边界，彼此只需要交换少量结果，那么并行执行的收益可能超过协调成本。

第三，专业化能够改善工具选择或任务执行。

如果一个任务需要特殊权限、不同的工具集合，或者主 Agent 很难在互相冲突的指令中做出正确选择，独立 Agent 就可能带来实际收益。

反过来，如果几个 Subagent 总是连续调用、频繁访问相同数据、依赖彼此的中间结论，那么它们可能不应该被拆成独立上下文。

从多个 Agent，回到一个执行循环

Anthropic 提出的替代方向，是采用单一 Agent 循环，并通过 Skills、Tools 和渐进式上下文加载来组织能力。

这里的关键不是把所有东西塞进一个巨大的系统提示词，而是按需加载能力。

  • Skills：保存完成某类工作所需的流程、领域知识和判断规则。
  • Tools：负责读取实时数据、调用外部系统、执行操作，以及实施权限和安全约束。
  • 渐进式披露：先让模型看到简短的能力说明，需要时再加载详细内容。
  • 单一执行循环：由同一个模型根据执行结果持续调整计划，而不是每跨过一个 Agent 边界就重新交接上下文。

这种方式有一个重要优势：模型能够直接看到前面步骤的原始结果，并据此修正自己的判断，不必完全依赖其他 Agent 提炼过的摘要。

Anthropic 还强调，随着模型能力提升，一些原本由固定编排逻辑完成的工作，现在可以交给模型自行处理。过于僵硬的架构反而可能限制新模型的发挥。

当然，单 Agent 并不意味着取消并行工具调用、外部记忆或结果验证。它强调的是：除非确实需要独立上下文，否则优先让同一个 Agent 保持对任务全过程的理解。

从树状编排到 Agent Swarm：下一步是什么？

前面讨论的多 Agent 系统，大多采用树状结构。

一个主 Agent 负责调度 Subagent，Subagent 还可以继续创建自己的 Subagent，最终结果逐层返回。

这种架构简单、容易理解，也适合有明确任务边界的工作流。

但当 Agent 数量不断增加时，树状结构会遇到一个新的瓶颈：所有重要信息最终都可能汇聚到根节点。

如果根 Agent 必须了解每个分支的工作进展、判断它们之间的关系，再协调后续任务，那么它自身的上下文就可能再次成为瓶颈。

更麻烦的是，专业知识被困在各自的分支里。

假设一个 Agent 已经深入理解前端架构，另一个分支也需要这份知识。树状结构可能要求请求先返回共同的上级，再由上级转发给前端专家。或者，每个分支都重新培养自己的前端专家，重复投入上下文和推理成本。

Hallerite 因此提出了另一种可能：让 Agent 之间能够直接通信，形成一个由多个 Agent 组成的协作网络。

在这样的系统里，专业化可以随着工作自然形成：某个 Agent 因为持续处理前端问题，积累了相关上下文和工具，其他 Agent 就可以在需要时直接向它请求帮助。

不过，这仍然是一种值得探索的架构方向，而不是已经得到普遍验证的最终答案。

完全去中心化的网络同样可能产生通信开销、重复劳动、冲突决策和责任不清等问题。

Hallerite 自己也没有断言纯粹的 Mesh 就是最佳结构。他提出的一个更务实的设想是，让 Agent 使用共享 Git 仓库、任务跟踪系统和通信渠道，并以共享状态作为事实来源。系统可以从人类设计的组织结构开始，再逐步探索更合适的协作方式。

这意味着未来的 Agent 系统可能不是在树状结构和 Mesh 之间二选一，而是根据规模与任务特征，动态组合层级协调、共享记忆和横向协作。

如何选择合适的 Agent 架构？

综合这两篇文章，我们可以得到一个更实用的工程原则：

从单 Agent 开始，只在有可测量收益的地方引入多 Agent，并持续验证哪些拆分值得保留。

下面是一套可以用于实际项目的决策框架。

任务特征 优先考虑的架构
工作流程相对连续，前后步骤需要共享大量信息 单 Agent 循环
需要按需加载领域知识或执行规则 单 Agent＋Skills／Tools
多条研究路径彼此独立，可以同时执行 多 Agent 并行
需要独立权限、独立指令或隔离验证过程 专业 Subagent
多个任务反复需要同一份专业上下文 考虑持久化 Agent 或共享记忆
大量 Agent 需要跨分支共享专业知识 探索共享状态与横向协作

但架构决策不能只靠经验。Anthropic 特别强调了端到端任务评测的重要性。

在合并或拆分 Agent 之前，至少应该完成以下工作。

  • 建立基准测试。收集一组真实任务，覆盖正常路径、边界情况以及必须遵守的业务规则。即使最初只有 10 个高质量样例，也比凭感觉判断更可靠。
  • 比较任务完成质量。不要只看最终答案是否正确，还要检查哪些任务在架构调整后从成功变成失败，或者从失败变成成功。
  • 记录成本与延迟。比较 Token 消耗、端到端耗时、失败率以及工具调用次数，避免为了减少 Agent 数量而牺牲任务质量。
  • 一次只调整一部分架构。先把调用频繁、共享上下文多、经常连续执行的专业 Agent 合并，再观察结果。不要一次性推翻整个系统。
  • 反复运行评测。Agent 具有随机性，单次成功不足以证明架构有效。对于重要任务，应多次运行，并检查那些可能被平均分掩盖的失败案例。

例如，一个客服系统最初有订单查询 Agent、物流 Agent 和退款 Agent。如果订单查询与物流查询经常连续发生，而且共享大量数据，那么可以尝试把它们合并为一个具备相关 Skills 和 Tools 的主 Agent。

但如果退款操作需要独立权限和严格审批，就不应该为了追求架构简单而取消这道边界。

这也揭示了一个重要区别：应该合并的是不必要的上下文边界，而不是所有的权限边界、验证边界和安全边界。

架构应该服务于任务，而不是让任务迁就架构。

小结：不要崇拜 Agent 数量，要优化信息流动

把这两篇文章放在一起看，我们会发现，它们实际上讨论的是同一个问题的两个侧面。

Hallerite 关注的是如何突破单一上下文的限制：通过多个持久化 Agent，让系统拥有更多可用的工作记忆，并探索更灵活的协作网络。

Anthropic 关注的则是另一面：当模型已经能够在一个执行循环中处理复杂任务时，过度拆分会引入上下文损失、额外延迟和维护成本，应该把不必要的 Subagent 合并回来。

前者提醒我们，不要把所有知识都塞进一个上下文窗口；后者提醒我们，不要为了拆分而拆分。

两者并不矛盾。

真正值得追求的 Agent 系统，既不是一个包办一切的巨型 Agent，也不是一群不断相互转发消息的小 Agent。

它应该知道哪些信息必须放在一起，哪些工作可以独立完成，哪些上下文值得长期保留，以及什么时候集中协调比彼此协商更划算。

Agent 架构的下一阶段，竞争焦点可能不再是“谁拥有更多 Agent”，而是“谁能以更低的协调成本，让正确的信息在正确的时间到达正确的 Agent”。

当我们开始用这个标准衡量架构时，Single Agent、Subagent 和 Agent Swarm 就不再是互相排斥的技术路线，而是构建高效 AI 系统时可以灵活组合的工程工具。

参考资料：

  1. On the Nature of the Swarm - https://hallerite.com/posts/on-the-nature-of-the-swarm
  2. Building agents: When to fold subagents into your main agent loop - https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。