你加了4个Agent，结果比不加更慢——多Agent的代价没人告诉你

项目刚开始，你画了一张架构图：Intent Agent → Guard Agent → Orchestrator Agent → Conversation Agent → Supervisor Agent，五个 Agent，分工明确，看起来非常"工程化"。

然后上线了。用户在实时聊天框里等了好几秒，还没收到回复。escalation 率开始上升，老板皱眉头。

你加了四个 Agent，结果比加之前更慢、更容易出错。

这不是假设，这是 ChatGenie 的真实案例。他们最终把五个 Agent 合并成两个，响应延迟降低了 50%，准确率维持在 98%。

多 Agent 不是越多越好，拆分不是免费的，而这件事背后藏着一些反直觉的数据。

今天这篇，我们就来把"单 Agent vs 多 Agent"这个问题说清楚：什么时候一个 Agent 就够了，什么时候必须拆，拆了之后要付出什么代价。

先说结论：70% 的项目用单 Agent 就够了

CoderCops 对生产项目的回顾发现，约 70% 自称"多 Agent"的项目最终可以简化为"单 Agent + 优质工具"。

Iterathon 对 47 个生产部署的统计更进一步：68% 的部署本可通过精心设计的单 Agent 系统达到同等或更好效果，成本只有多 Agent 的 30-40%，但能覆盖 90-95% 的效果。

Princeton NLP 的独立研究印证了同一结论：在 64% 的基准任务中，单 Agent 匹配或优于多 Agent，而多 Agent 仅增加约 2.1 个百分点的准确率，成本却约为两倍。

所以，多 Agent 是一把锤子，但不是每颗钉子都需要它。

那单 Agent 到底能走多远？能走很远，但不是无限远——它会撞上三堵墙。

单 Agent 的三堵墙

第一堵墙：上下文耗尽

每次工具调用的输入和输出，都会追加到上下文窗口里。一个 50 步的任务，光历史上下文就可能占用 100K+ tokens，留给推理的空间所剩无几。Agent 开始"忘记"早期的关键信息，重复已经做过的步骤，或者忽略你最核心的需求。

第二堵墙：工具过载

这里有一组让人印象深刻的数据来自 Vercel 工程团队：他们把一个 text-to-SQL Agent 的工具从 17 个砍到 2 个后——执行时间快了 3.5 倍，成功率从 80% 提升到 100%。

工具越多，模型在每一步的选择空间越大，出错概率也越高。Claude Code 的 MCP Tool Search 机制更显示，工具描述超过上下文的 10% 时自动懒加载，可将工具占用从 39.8K tokens 降到 5K。

有时候，在拆分 Agent 之前，先试试砍工具。

第三堵墙：串行瓶颈

单 Agent 本质上是串行的——一步做完才能做下一步。5 个互相独立的子任务，串行执行需要 50 分钟，但它们本可以并行完成只需 10 分钟。

这不是优化问题，是架构限制。

后端开发类比： 单 Agent vs 多 Agent，约等于单体应用 vs 微服务。单体在中小规模下开发快、部署简单、无网络开销——70% 的项目用单体就够了。但当团队扩大、模块需要独立伸缩时，拆分是必然的。关键是判断你现在处在哪个阶段，而不是盲目跟风。

何时该拆：四个条件触发拆分

拆分不是拍脑袋的决定。以下四个条件构成决策树，任意一个触发，就该认真考虑拆分：

条件一：工具数量超过 10 个且功能重叠

对应工具过载墙。Vercel 的案例已经说得很清楚了——17 个工具 → 2 个工具，成功率 80% → 100%。当 Agent 在功能相近的工具间做选择时，决策质量会显著下降。

条件二：明确的不同专业领域

"写代码"和"审查代码"是两个完全不同的心智模型，强行让一个 Agent 同时具备两种能力，意味着系统提示臃肿、工具集互相干扰。Stripe 的 Minions 架构验证了这一点：专精的 Agent 在精选的小工具集中表现最佳。

条件三：高并行需求

Fan-Out/Fan-In DAG 调度可以将 Agent 的 wall-clock 时间削减 36-50%——把可以并行的子任务同时派发，收集结果后综合，是当前生产环境主要的延迟优化手段。

但这里有一个必须强调的反直觉数据：Google 内部研究显示，多 Agent 系统在串行任务上比单 Agent 退化 39-70%——协调开销和上下文传递的损耗超过了并行收益。所以"高并行需求"不是主观判断，是需要客观验证的前提。

条件四：单次会话无法完成

当任务的总 Token 消耗超过单个上下文窗口的有效容量时，不是拆不拆的问题，而是必须拆，否则就引入跨会话的检查点机制。

反面信号：什么时候不该拆

同样重要的，是什么时候千万别拆。

Google DeepMind 对 180 种多 Agent 配置的系统测试显示，当 Agent 被随意组合而没有正式拓扑结构时，错误通过每次交接复合放大，最坏配置下的错误放大倍数达到 17.2 倍——不是 17%，是 17 倍。

企业多 Agent 部署的分析更令人警醒：41-87% 的项目在生产环境失败，其中近 79% 的失败源于规范和协调问题，而非模型能力不足。

这些数据不是反对多 Agent，而是反对未经深思熟虑的拆分。

拆了之后：三种隔离模式

决定拆之后，下一个问题是：拆出来的 Agent 之间如何隔离和通信？

Claude Code 提供了三种从轻到重的并行模型：

Fork 最"重"——子 Agent 继承父 Agent 的完整对话历史、系统提示和工具池，字节级一致，用于 Prompt Cache 共享。代价是 Token 成本高，但如果子任务需要理解父 Agent 之前 30 步推理的完整脉络，这是唯一选择。

Teammate 是最强大的模式。它拥有全部工具加 SendMessage 能力，支持双向对等消息传递，多个 Teammate 通过共享任务表、文件锁和邮箱协议协调——是"持续协作"而非"派生后遗忘"。

Worktree 是大规模并行代码修改的唯一解。不同会话编辑不同文件，永不冲突，"在一个终端构建功能的同时，在第二个终端修复 Bug"成为可能。

编排方式：Handoff vs Agents-as-Tools

拆分之后，多个 Agent 之间用什么方式编排？OpenAI Agents SDK 定义了两种基本模式：

Handoff：控制权完全转移

分诊 Agent 将对话控制权完全转移给专业 Agent，自己退出，由专业 Agent 直接响应用户。

就像医院的分诊台：分诊护士把你交给对应科室的医生，分诊护士不再参与后续诊疗。

但 Handoff 有一个在生产中被反复验证的痛点：CallMissed 的基准测试显示，52% 的失败源于交接过程中缺失或不一致的上下文——前一个 Agent 的关键推理没有被完整传递给后一个 Agent。

Agents-as-Tools：管理 Agent 保持控制权

管理 Agent 始终在场，把专业 Agent 当作工具调用，综合结果后统一响应用户。就像项目经理协调多个专家——始终掌控全局，最终由 PM 汇报。

两者可以组合使用：分诊 Agent Handoff 给专家，专家再把其他 Agent 作为工具调用处理窄子任务。

最容易被忽视的硬约束：Token 经济学

这一节是整篇文章最值得认真对待的部分。

多 Agent 不是免费的，它的 Token 成本可能让架构决策完全反转。

子 Agent 模式的上下文膨胀问题

在子 Agent 模式（Agents-as-Tools）中，编排器的上下文随着每个子 Agent 的返回结果而增长。如果你编排了 10 个子 Agent，每个产出 2,000 tokens，编排器的上下文里会累积 20,000+ tokens 的返回结果。到第 10 个子 Agent 返回时，编排器在一个膨胀的上下文里做综合决策，质量必然下降。

团队模式的经济优势

团队模式（完全并行）中，每个 Agent 只加载自己任务相关的上下文（约 2,000-4,000 tokens），完整历史存在共享存储里，没有单一 Agent 累积全部上下文。

量化对比：10+ 并行 Agent 场景下，团队模式比子 Agent 模式便宜 3-5 倍。TECHTAEK 的实测显示，同一任务两种模式的 Token 成本差异最高达 86%（约 7 倍）。

Anthropic 的真实数据：15 倍代价换 90% 提升

Anthropic 在 Claude Research 多 Agent 系统上的内部评估给出了最直接的参照：

多 Agent（Opus 4 主导 + Sonnet 4 工作）比单 Opus 4 提升 90.2%，但 Token 成本是单 Agent 的 15 倍——且 80% 的性能差异由 Token 使用量单独解释。

Anthropic 的核心原则是：ruthlessly parallelize（无情地并行），但只在你能证明 15 倍 Token 成本带来了 15 倍以上价值时。

一个触目惊心的生产案例

Iterathon 对一个 290 万查询/月的 SaaS 客服系统的分析：

准确率只差 2.1%，但月成本多花 $24,300，每次查询多等 4.8 秒。

在 10 万查询/月时，多 Agent 是合理选择。在 290 万查询/月时，协调开销线性增长，收益趋于平稳——多 Agent 的拐点已经过了。

后端类比： Token 经济学 ≈ 微服务中的网络带宽优化。子 Agent 模式像同步 RPC 调用——每个调用的响应都回到调用方，调用方的内存随调用次数线性增长。团队模式像消息队列——各服务独立工作，结果写到共享存储，不需要回到调用方。大规模场景下，消息队列永远比同步 RPC 更可扩展。

最后一条警告："Agent Zoo Problem"

Sébastien Dubois 把过度拆分的症状称为 "Agent Zoo Problem"：

一旦超过 5-6 个 Agent，管理 Agent 名单本身就成了工作。你不再使用 AI 来完成工作，而是开始管理 AI 来完成工作。

增加新能力时，"write a skill, not an agent"——写一个技能，而不是新建一个 Agent。

这是对所有拆分决策的终极检验：你是在解决问题，还是在创造新的管理问题？

拆分三原则

用三条原则收尾：

原则一：按领域拆，不按步骤拆。 "写代码 Agent"和"审查代码 Agent"是合理的拆分，"第一步 Agent"和"第二步 Agent"不是——后者只是把一个流程强行切断。

原则二：隔离级别匹配协作深度。 需要继承上下文的子任务用 Fork（进程级），需要双向通信的长期协作用 Teammate（线程级），需要独立并行开发用 Worktree（容器级）。

原则三：编排模式匹配规模。 2-4 个 Agent 的小规模任务用 Agents-as-Tools；5-10 个 Agent 的中规模任务用 Handoff；10+ 个 Agent 的大规模并行任务必须用团队模式——子 Agent 模式的编排器上下文会膨胀到无法处理。

单 Agent 能走很远，但不是无限远。多 Agent 能做到更多，但代价你得先算清楚。

在你打开 IDE、开始画那张多 Agent 架构图之前，先问自己一个问题：

你的工具，砍过了吗？

— 完 —