今天这篇我们就来把单 Agent vs 多 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 完整推理脉络的子任务fork()系统调用Teammate独立终端持久运行需要跨 Agent 双向协作的长任务线程间消息队列Worktree独立 Git 分支 工作目录大规模并行代码修改永不冲突Docker 容器隔离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 汇报。维度HandoffAgents-as-Tools控制权完全转移给专家管理 Agent 保留用户交互专家直接响应管理 Agent 综合后响应提示聚焦高专家只看自己的任务中管理 Agent 需要理解所有结果后端类比HTTP Redirect / 服务转发Aggregator 模式 / Fan-out-Fan-in两者可以组合使用分诊 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 倍。管道规模子 Agent 编排器成本团队模式单 Agent 成本小型2-4 Agent短输出可忽略可忽略中型5-10 Agent中等输出30-50K tokens每 Agent 2-4K tokens大型10 Agent大输出可能触及上下文限制每 Agent 2-4K tokensAnthropic 的真实数据15 倍代价换 90% 提升Anthropic 在 Claude Research 多 Agent 系统上的内部评估给出了最直接的参照多 AgentOpus 4 主导 Sonnet 4 工作比单 Opus 4 提升90.2%但 Token 成本是单 Agent 的15 倍——且 80% 的性能差异由 Token 使用量单独解释。Anthropic 的核心原则是ruthlessly parallelize无情地并行但只在你能证明 15 倍 Token 成本带来了 15 倍以上价值时。一个触目惊心的生产案例Iterathon 对一个 290 万查询/月的 SaaS 客服系统的分析方案月成本准确率差异延迟差异多 Agent编排检索生成三 Agent$47,000基准基准单 AgentGPT-5 RAG$22,700-2.1%-4.8秒/查询准确率只差 2.1%但月成本多花 $24,300每次查询多等 4.8 秒。在 10 万查询/月时多 Agent 是合理选择。在 290 万查询/月时协调开销线性增长收益趋于平稳——多 Agent 的拐点已经过了。后端类比Token 经济学 ≈ 微服务中的网络带宽优化。子 Agent 模式像同步 RPC 调用——每个调用的响应都回到调用方调用方的内存随调用次数线性增长。团队模式像消息队列——各服务独立工作结果写到共享存储不需要回到调用方。大规模场景下消息队列永远比同步 RPC 更可扩展。最后一条警告Agent Zoo ProblemSé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-Tools5-10 个 Agent 的中规模任务用 Handoff10 个 Agent 的大规模并行任务必须用团队模式——子 Agent 模式的编排器上下文会膨胀到无法处理。