性能,成本,可控性：从Sub-Agents到Multi-Agent的工程详细指南

先纠正一下，很多人误以为 Sub-Agents 和 Multi-Agent 是两个对立不同的架构，其实不是，Sub-Agents 是 Multi-Agent 体系下的一种架构模式，而不是一个与 Multi-Agent 对立的总体范式。

花了两个月搭建的多智能体系统，上线后发现响应时间比预期的慢了3倍，而且每单次请求的成本直接把预算烧掉了三分之一。

这个场景，可能大家都不陌生。

当你开始搭建真正的AI应用时，几乎都会遇到两个致命问题：能力越来越多，单个prompt放不下；不同团队在不同模块里改代码，协作变得混乱。

这时候，你面临的选择就很关键：是走Multi-Agent（多智能体）路线，还是用Sub-Agent（子代理）架构。

LangChain在《choosing the right multi-agent architecture》这篇文章中给过一个核心判断：大多数任务仍然适合单智能体，但当"上下文管理"和"分布式开发"成为瓶颈时，多智能体才成为必要选择。

但问题是，Multi-Agent和Sub-Agent到底有什么区别？什么时候该选哪个？

扒了很多资料，这篇文章我们就来系统聊聊这个问题。

文章篇幅稍长，但绝对干货满满。

1.一个真实的试错经历

去年的时候，有一个朋友，他们团队是搞金融的，他们有这样的场景：用户问一个复杂的问题，比如"帮我分析一下Q3的营收情况，对比去年同期，并给出改进建议"。

这个问题涉及三个独立领域：数据查询、财务分析、策略建议。

一开始他们用的是单智能体方案。把所有逻辑塞进一个prompt里，挂载一堆工具。

问题很快就暴露了。

首先是上下文管理失控。当需要同时处理数据查询、财务指标计算、行业知识检索时，prompt里塞满了各领域的专业术语和规则。上下文窗口被占满，推理质量直线下降。

LangChain的benchmark研究显示，当distractor domains（干扰域）从0增加到8个时，单agent架构的性能从0.67暴跌至0.34，下降50%。

这简直是灾难性的。

也就是说，你塞进去的知识越多，模型反而越容易晕。

其次是团队协作困难。负责数据查询的团队、负责财务分析的团队、负责策略建议的团队，大家都在改同一个大prompt。版本冲突、权限混乱、不知道谁改了什么东西，最后变成了一团乱麻。

他们意识到，必须升级架构了。

但他们面临一个更关键的问题：怎么升级？

是搞一个真正的Multi-Agent系统，让三个独立智能体协作？还是用一个主智能体加几个Sub-Agent？

2.Multi-Agent和Sub-Agent的本质区别

很多人会混淆这两个概念，我先简单的跟大家说清楚。

Sub-Agents 和 Multi-Agent 不是两个对立不同的架构，Sub-Agents 是 Multi-Agent 体系下的一种架构模式，而不是一个与 Multi-Agent 对立的总体范式。

Multi-Agent（多智能体系统） ，本质上是一群相对独立的智能体在协作。它们可能有各自的目标、各自的状态、各自的上下文，通过通信协议来协调。

就像一个真正的工程团队，产品经理、架构师、工程师、测试，大家有明确的分工，各自负责自己的部分，通过会议、文档、工具来协同。

而Sub-Agent（子代理） ，本质上是集中式架构下的分工。一个主智能体掌控全局，把任务委派给几个专用的子代理。这些子代理更像工具，无状态，只处理被分配的子任务。

就像一个项目经理手下有几个专精的执行者。项目经理知道全局目标和上下文，根据需要把任务分发给不同的人，拿到结果后再整合。

这个区别很重要。

Google Cloud的一篇文章给出了一个非常清晰的对比：Agent as Tool（工具式子代理）vs Sub-Agent（委派式子代理）。

Agent as Tool就像一个专家顾问，主智能体调用它时，给出明确的输入，拿到明确的输出，就像调用一个API。这个专家顾问有自己的逻辑，但主智能体不需要知道细节。

而Sub-Agent更像一个项目经理的分身，它在主智能体的全局上下文中工作，处理复杂的多步骤流程，可以访问主智能体的对话历史和状态。

关键区别在于：控制权和上下文。

Multi-Agent模式下，控制权是分布式的，每个Agent都有一定的自主权，上下文是隔离的。而Sub-Agent模式下，控制权是集中式的，主智能体说了算，上下文是共享的。

3.性能与成本的真实对比

回到上面那个金融团队的案例中。

他们一开始尝试的是Multi-Agent方案。三个独立Agent：数据Agent、分析Agent、建议Agent。每个Agent有自己的prompt、自己的工具集、自己的上下文。

从理论上看，这个方案很完美。职责清晰，易于扩展，团队可以独立开发各自负责的Agent。

但上线后问题很快就暴露了。

首先是延迟问题。用户一个请求进来，需要经过多个Agent的来回协作。Agent之间要通信，要协商，要同步状态。每次协作都增加一次模型调用，响应时间直线上升。

更严重的是成本问题。每次Agent之间的交互，都需要消耗token。而且由于上下文隔离，很多信息需要重复传递。

LangChain做过一个对比测试，结果很有意思。

场景一：一次性请求（比如"帮我买杯咖啡"）

• Skills模式（单Agent动态加载技能）：3次模型调用
• Handoffs模式（Agent间切换）：3次模型调用
• Sub-Agents模式：4次模型调用
• Router模式：5次模型调用

Sub-Agents之所以多一次调用，是因为所有结果必须回传给主Agent进行整合与决策。这个数据还挺意外的。本来以为Multi-Agent会更快，结果反而慢了。

场景二：重复请求（两次"买咖啡"）

• Skills模式：5次模型调用（节省40%）
• Handoffs模式：5次模型调用
• Sub-Agents模式：8次模型调用
• Router模式：10次模型调用

Skills和Handoffs因为有状态复用，在重复请求时效率大幅提升。而Sub-Agents和Router因为无状态设计，每次都得走完整流程。

场景三：多领域查询（同时问三个专业问题）

这是Multi-Agent的优势场景。

• Skills模式：约15K token消耗
• Sub-Agents模式：约9K token消耗
• Router模式：约9K token消耗

Skills模式之所以token消耗高，是因为所有专业领域的知识都会累积到同一个对话上下文中，出现上下文膨胀。而Sub-Agents和Router通过上下文隔离，每个子Agent只加载和自己领域相关的内容，节省了大量token。

Anthropic的研究也得出了类似结论。他们用Claude Opus 4作为主Agent、Claude Sonnet 4作为Sub-Agents的多Agent系统，在内部评估中比单纯的Claude Opus 4高出90.2%。

但这个提升是有代价的：更高的成本和更长的延迟。

4.维度一：性能与延迟

性能和延迟，是Multi-Agent架构最需要权衡的地方。

4.1 并行能力

Multi-Agent的一个核心优势是并行执行。当任务可以拆分为多个独立子任务时，多个Agent可以同时工作，大大缩短总时间。

比如用户问：帮我查一下Python、JavaScript、Rust三种语言的最新特性。

如果是Sub-Agent模式，主Agent可以并行调用三个语言专家Agent，它们同时工作，最后汇总结果。理论上可以节省2/3的时间。

但前提是这些子任务是真正独立的。如果存在依赖关系，比如需要先用Agent A的结果去调用Agent B，那就无法并行了。

Handoffs和Router模式在并行能力上相对较弱。Handoffs是顺序执行的，Agent A做完才能轮到Agent B。Router虽然可以并行调用多个Agent，但Router本身的分类和分发是串行的。

4.2 调用次数

这是影响延迟的关键因素。

每次模型调用都需要时间，而且可能是可观的延迟（特别是用大模型的时候）。

简单任务上，Skills和Handoffs只需要3次调用，Sub-Agents需要4次，Router需要5次。差距看起来不大，但在大规模应用中，这个差异会被放大。

但复杂任务上，情况就不一样了。

比如一个需要多次交互才能完成的任务，Sub-Agents模式的优势就出来了。因为Sub-Agents可以在主Agent的上下文中持续工作，不需要每次都重建上下文。

而Skills模式虽然调用次数少，但上下文会不断累积，可能导致后续调用变慢或质量下降。

4.3 响应时间

响应时间 = 调用次数 × 单次调用延迟 × 并行因子

这是一个简化的公式，但抓住了核心。

Sub-Agents模式调用次数多，但可以并行，总响应时间可能不会太差。Router模式调用次数也多，而且Router的步骤本身可能比较复杂（分类+分发），响应时间可能更长。

Skills模式调用次数最少，但上下文膨胀可能导致单次调用变慢。

Handoffs模式调用次数少，但无法并行，如果任务步骤多，总响应时间也可能很长。

真实的选择，要看你的具体场景。

如果你的任务可以高度并行，Sub-Agents和Router更有优势。如果你的任务需要多轮交互但领域切换频繁，Skills可能更好。如果你的任务有严格的顺序依赖，Handoffs更合适。

5.维度二：成本控制

成本，是Multi-Agent架构另一个需要认真考虑的问题。

5.1 Token消耗

Token消耗直接决定了你的API调用成本。

LangChain的测试数据显示，多领域查询场景下，Skills模式消耗约15K tokens，而Sub-Agents和Router只消耗约9K tokens，节省了约40%。

这个差距来自上下文隔离。Skills模式下，所有领域的专业知识都会累积到同一个对话历史中，第三个Skill加载时，前两个Skill的内容仍然占用着上下文窗口。

而Sub-Agents模式下，每个子Agent只在自己独立的上下文中工作，只加载和自己领域相关的内容（约2000 tokens + 少量任务指令）。

如果任务涉及3个以上领域，Skills模式的token成本会迅速失控。

5.2 模型选择

这是一个很多人忽略但非常关键的优化点。

Sub-Agents模式的一个优势是，不同的子Agent可以用不同的模型。

主Agent可以用最强大的模型（比如GPT-4或Claude Opus），因为它负责全局规划和结果整合，需要最强的推理能力。

但子Agent可以用更小更快的模型（比如GPT-4.5 Mini或Claude Sonnet），因为它们只需要处理特定领域的任务，推理复杂度相对较低。

Boris Cherny（Claude Code的开发者，前段时间很火那个）就提到过这个实践。他在使用Claude Code时，所有工作都用Opus 4.5，但在一些简单的子任务上，可以换成Sonnet来节省成本。

Skills模式相对灵活一些，可以动态切换模型，但切换成本可能较高。Handoffs和Router模式因为需要保持状态一致性，切换模型的难度更大。

5.3 重复请求优化

如果你的用户经常会重复类似的问题，这一点就很关键。

Skills和Handoffs因为有状态复用，在重复请求时可以节省大量成本。LangChain的数据显示，重复请求时可以节省40%的模型调用。

但Sub-Agents和Router因为无状态设计，每次都得走完整流程，无法从重复中获益。

这个数据还挺重要的。如果你的应用场景中，用户经常会问类似的问题，Skills或Handoffs可能更划算。

但如果每次请求都是新的查询，Multi-Agent的上下文隔离优势就更明显。

6.维度三：可维护性与调试

性能和成本是外在的，可维护性和调试是内在的，但同样重要。特别是当你的系统需要长期运行和持续迭代时。

6.1 日志与追踪

Multi-Agent系统的日志管理复杂度比单Agent高很多。

单Agent模式下，你只需要追踪一条调用链。

输入 → Agent推理 → 工具调用 → 输出。

但Multi-Agent模式下，调用链变成了网状结构。Agent A调用Agent B，Agent B又调用Agent C，Agent A和Agent C直接通信……如何追踪一个错误是哪个Agent引入的？

Sub-Agents模式相对简单一些，因为调用链是树状的。主Agent调用子Agent，子Agent可能再调用更下层的Agent，但不会横向通信。

Router模式的调用链也比较清晰，Router负责分发，子Agent负责执行，最后汇总。

Skills和Handoffs模式最简单，因为从外部看仍然是单Agent，只是内部逻辑更复杂。

6.2 状态一致性

当多个Agent协同工作时，如何保证它们对同一个状态有一致的理解？

比如一个订单处理系统，库存Agent看到库存是10个，订单Agent生成了订单，但支付Agent处理超时了。库存Agent怎么知道订单没有成功？它看到的库存应该还是10个，还是被锁定的？

Sub-Agents模式通过共享上下文来解决这个问题。所有子Agent都在主Agent的上下文中工作，状态由主Agent统一管理。

Handoffs模式通过传递状态来保证一致性。Agent A完成时，把自己的状态和上下文传递给Agent B。

Multi-Agent模式需要专门的机制，比如共享内存、消息队列、或者事件总线。

6.3 错误处理与恢复

当某个Agent出错时，如何恢复？

单Agent模式下，你可以重试整个请求，或者部分重试。

Multi-Agent模式下，如果Agent A出错，但Agent B和C已经成功执行了，怎么办？是回滚所有Agent的操作，还是只重试Agent A？如果Agent B和C的结果依赖于Agent A，那重试Agent A可能没有意义。

Sub-Agents模式相对简单，因为主Agent可以看到所有子Agent的执行结果，可以决定是重试某个子Agent，还是调整策略后重新分配任务。

Router模式需要Router来协调错误恢复。如果某个子Agent失败，Router需要决定是重试、换一个子Agent，还是返回错误给用户。

Skills和Handoffs模式因为调用链相对简单，错误处理也相对容易。

7.四种架构模式的适用场景

Anthropic在ADK架构中将Multi-Agent分为四种模式：Sub-Agents、Skills、Handoffs、Router。

每种模式都有最适合的场景。

7.1 Sub-Agents：集中式编排的专业协同

适用场景：

• 多个独立领域需要统一工作流控制
• 需要强上下文隔离
• 团队协作，不同团队负责不同领域

典型例子：

• 企业知识库Agent：主Agent负责意图理解和结果综合，技术文档Sub-Agent、财务数据Sub-Agent、HR政策Sub-Agent各司其职
• 个人助理：协调日历、邮件、CRM，多个独立领域需要统一控制

优势：

• 强上下文隔离，避免领域间相互污染
• 集中式控制，便于协调和整合
• 易于团队分工协作

劣势：

• 每次交互多一次模型调用（结果需要回传主Agent）
• 系统复杂度增加，调试链路更长

7.2 Skills：渐进式能力披露的轻量化扩展

适用场景：

• 单Agent需要覆盖多种专业方向
• 功能切换频繁但单次对话涉及领域较少
• 需要快速迭代和探索

典型例子：

• 编程Agent：在一次会话中需要Python调试、前端开发、API设计多种能力
• 创意写作Agent：需要在SEO优化、文案撰写、数据可视化间快速切换
• 个人生产力工具：功能多但不要求强隔离

优势：

• 轻量，开发门槛低
• 对话连贯性强，技能加载后保留在上下文中
• 适合快速迭代和产品探索

劣势：

• 上下文会不断累积，容易token膨胀
• 多领域混合时性能不如Sub-Agents
• 难以严格隔离不同领域的权限

7.3 Handoffs：状态驱动的流程化交互

适用场景：

• 分阶段顺序工作流
• 智能体需要全程交互用户
• 后续步骤依赖前序结果

典型例子：

• 客服流程：信息收集Agent → 问题诊断Agent → 解决方案Agent
• 保险理赔：资料收集Agent → 审核Agent → 赔付计算Agent → 通知Agent
• 订单处理：商品查询Agent → 库存Agent → 支付Agent → 物流Agent

优势：

• 多轮交互自然，上下文在阶段间平滑传递
• 每个Agent专注自己的阶段，职责清晰
• 适合有严格顺序约束的场景

劣势：

• 无法并行处理，效率较低
• 状态管理复杂
• 不适合需要多Agent协作的场景

7.4 Router：并行派发与结果综合

适用场景：

• 垂直领域多源查询
• 需要整合多专业结果
• 请求无状态，可以独立处理

典型例子：

• 企业知识库查询：技术文档+销售数据+法律合规并行查询
• 电商平台推荐：库存Agent、价格Agent、评价Agent并行查询
• 内容生成：不同风格的内容并行生成后综合

优势：

• 并行执行，节省时间
• 无状态设计，性能稳定
• 横向扩展能力强

劣势：

• 对话需要历史上下文时，每次都需要重新分类，带来重复开销
• Router本身的分类逻辑需要精心设计
• 不适合需要多轮协作的场景

总结一下

最后，基于我们看到的成功案例和失败教训，以及我们亲身做的项目01Agent，从 routeragent 走向 multiagent，总结一些经验，欢迎感兴趣的朋友一起来交流。

从单Agent起步，逐步演进

不要一上来就上Multi-Agent架构。

LangChain在文章开头就明确写道："Many agent tasks are best handled by a single agent with well-designed tools. You should start here."

单Agent不是过渡方案，而是正确的默认值。

原因很简单：

1. 1.单Agent更容易构建、推理和调试
2. 2.成本与延迟更可控
3. 3.便于快速迭代和验证

只有当你真正遇到以下问题时，才考虑升级：

1. 1.上下文管理失控：单个prompt塞不下了，或者推理质量因为上下文过长而下降
2. 2.分布式开发不可避免：多个团队需要独立维护不同模块

根据你的核心需求来选择：

1. 1.需要多领域并行执行、集中式工作流管控 → Sub-Agents
2. 2.需要轻量化多能力扩展、快速迭代 → Skills
3. 3.需要分阶段顺序工作流、智能体需全程交互用户 → Handoffs
4. 4.需要垂直领域多源查询、整合多专业结果 → Router

不要为了用Multi-Agent而用Multi-Agent。每个模式都有自己的适用场景和Trade-off。

优化模型选择

不要所有Agent都用同一个大模型。

这是一个很多人忽略的优化点。主Agent可以用最强的模型，因为需要全局规划和结果整合。但子Agent可以用更小更快的模型，因为它们只处理特定领域的任务。

Boris Cherny提到：虽然Opus比Sonnet更大更慢，但因为你需要更少的引导，工具使用能力更强，最终几乎总是比用小模型更快。

但这个"更少引导"的前提是，你的Agent设计得足够好，知道什么时候该调用哪个工具，怎么组合工具的结果。

设计清晰的通信协议

Multi-Agent系统最大的坑往往在通信上。

Agent之间说什么？什么时候说？怎么说？这些都需要明确的协议。

最常见的问题包括：

1. 1.语义不统一：同一个词在不同Agent中有不同的含义
2. 2.信息不对称：Agent A知道的信息Agent B不知道
3. 3.决策冲突：Agent A想做X，Agent B想做Y，但两者无法同时满足

1. 1.统一术语和格式定义
2. 2.设计清晰的消息协议（比如用JSON schema定义消息格式）
3. 3.引入冲突解决机制（比如投票、协商、优先级）

Multi-Agent系统的调试比单Agent难一个数量级。

你需要能够：

1. 1.追踪每个Agent的决策过程
2. 2.记录Agent之间的所有通信
3. 3.可视化整个调用链
4. 4.快速定位问题Agent

很多团队会在系统中嵌入详细的日志和追踪机制，甚至专门开发调试工具。

这也是为什么很多企业最终还是选择现成的Multi-Agent框架，而不是自己从头搭建。这些框架通常已经提供了完善的监控和调试能力。

考虑Human-in-the-Loop

Multi-Agent系统的一个风险是"失控"。Agent之间的协作可能陷入死循环，或者朝着错误的方向越走越远。

引入Human-in-the-Loop机制，让人类在关键节点介入审核和决策，可以很大程度上降低这个风险。

比如：

1. 1.主Agent在调用某个子Agent前，先向人类确认
2. 2.子Agent返回结果后，主Agent在整合前让人类审核
3. 3.设置最大迭代次数，超过后自动停止并通知人类

就像前文提到那个金融团队，他们最终选择的是Sub-Agents模式。主Agent负责意图识别、任务分解、结果整合，三个子Agent分别负责数据查询、财务分析、策略建议。

上线后的效果还不错。响应时间比之前的多Agent方案降低了60%，token消耗减少了40%，而且因为职责清晰，团队协作也顺畅了很多。

但他们也很清楚，这个选择不一定适合所有场景。

如果你的应用是单次查询为主、领域切换频繁，Skills可能更合适。如果你的应用是严格顺序的工作流，Handoffs可能更简单。如果你的应用需要大规模并行处理，Router可能更高效。

没有最好的架构，只有"最合适"的架构。

关键在于，你得先搞清楚自己的需求是什么。

参考资料：

• LangChain: Choosing the right multi-agent architecture https://blog.langchain.dev/choosing-the-right-multi-agent-architecture/

• Google Cloud: Where to use sub-agents versus agents as tools https://cloud.google.com/blog/topics/developers-practitioners/where-to-use-sub-agents-versus-agents-as-tools

• Anthropic: Multi-Agent Systems https://docs.anthropic.com/en/docs/build-with-claude/multi-agent-systems

• IBM: What is a multi-agent system?

  https://www.ibm.com/think/topics/multiagent-system

关注公众号, 用极客视角洞察未来!