从 Agent Swarm 到 Single Agent：AI Agent 的高效架构，正在走向两条路
内容提要
文章比较单Agent与多Agent架构：多Agent可并行处理、隔离上下文，但协调成本高、信息易丢失，Token消耗可达单Agent的3～10倍。Anthropic建议仅在上下文污染、任务可并行或需专业化时拆分，否则应合并回主循环；Hallerite则提出持久化Agent与共享状态协作网络。核心原则是从单Agent起步，按可测量收益拆分，并通过端到端评测持续验证。
延伸解读
多 Agent 的隐性成本：Token 与延迟
文章引用 Anthropic 的观察：多 Agent 系统的 Token 消耗可达单 Agent 的 3～10 倍，另一客户评估显示单 Agent 循环运行速度约为多 Agent 方案的两倍。这些数字来自特定场景，并非普遍规律，但提醒读者：每增加一个 Agent，就多一套提示词、独立上下文和调用链，协调与信息传递都会产生开销。评估架构时，应把 Token 消耗和端到端耗时纳入对比，而非只看功能是否拆分得更细。
上下文压缩与外部记忆的局限
文章指出，上下文压缩（Compaction）要求 Agent 在总结时预判未来哪些细节重要，但总结者并不知道后续故障会依赖哪条日志。外部记忆虽能保存信息，却只解决“信息是否存在”，不解决“Agent 是否知道何时使用它”，且先前建立的理解和排除的假设不会随文件保存。临时 Subagent 同样会在任务结束后丢弃上下文，下次需重新调查。这些机制各有代价，不能默认拆分或压缩就能提升效果。
拆分前先问：获得了什么单 Agent 无法经济获得的能力
Anthropic 认为多 Agent 的收益集中在三种场景：主 Agent 上下文污染已影响表现、任务确实可并行、专业化能改善工具选择或执行。反之，若 Subagent 总是连续调用、频繁访问相同数据、依赖彼此中间结论，就不应拆成独立上下文。文章给出的原则是从单 Agent 起步，只在有可测量收益处引入多 Agent，并通过端到端评测比较任务完成质量、成本与延迟，一次只调整一部分架构。
树状结构的瓶颈与共享状态的探索
文章指出，树状多 Agent 架构在 Agent 数量增加时，重要信息仍会汇聚到根节点，根 Agent 的上下文可能再次成为瓶颈；专业知识也被困在分支里，跨分支共享需经上级转发或重复培养专家。Hallerite 因此提出让 Agent 直接通信、形成协作网络，并以共享 Git 仓库、任务跟踪系统等共享状态作为事实来源。但文章明确这仍是待探索方向，完全去中心化可能带来通信开销、重复劳动和冲突决策等问题。
Q&A
多Agent系统相比单Agent，Token消耗和运行速度大概差多少？
根据Anthropic的观察，多Agent系统的Token消耗可能达到单Agent的3～10倍；另一个客户的评估发现，单Agent循环的运行速度约为多Agent方案的两倍。这些是特定场景中的观察，并非普遍规律。
什么情况下应该把Subagent合并回主Agent循环？
当几个Subagent总是连续调用、频繁访问相同数据、依赖彼此的中间结论时，它们可能不应该被拆成独立上下文，应合并回主循环。Anthropic建议仅在上下文污染、任务可并行或需专业化时拆分，否则优先让同一个Agent保持对任务全过程的理解。
持久化Agent和临时Subagent有什么区别？
临时Subagent在任务结束后上下文通常被丢弃，下次需要相关信息时可能需重新调查；持久化Agent长期存活，保留已阅读的代码、建立的理解和积累的工具，其他任务可直接向它提问，使多Agent的价值从并行执行扩展到上下文并行化。
上下文压缩（Compaction）有什么风险？
总结发生时，Agent并不知道未来哪些细节会变得重要，可能在摘要中丢弃后来关键的信息。例如编码Agent排查间歇性测试失败时，将一条看似无关的日志视为噪声未写入摘要，两天后却发现故障原因正藏其中。
树状多Agent架构在大规模下有什么瓶颈？
所有重要信息最终可能汇聚到根节点，根Agent的上下文可能再次成为瓶颈；专业知识被困在各自分支里，其他分支需要时须经上级转发或重新培养专家，重复投入上下文和推理成本。
如何通过评测决定Agent架构该合并还是拆分？
应建立覆盖正常路径、边界情况和业务规则的基准测试；比较任务完成质量，检查哪些任务成功或失败发生变化；记录Token消耗、端到端耗时、失败率和工具调用次数；一次只调整一部分架构；反复运行评测以应对随机性。
