多智能体架构：盲目拆分只会适得其反

“把一个智能体拆成多个，是不是就能变聪明？”

答案是”看情况”。Anthropic的研究数据显示，多智能体系统在特定条件下性能可以超出单智能体90% - 但关键词是”特定条件”。实际跑下来，性能差距取决于你要解决的任务类型，差异可以非常悬殊。

下面用三个典型场景，拆解四种架构模式各自的真实表现。

四种模式速览

• 子代理（Subagents）：主代理把专业任务分发给子代理，子代理作为工具被调用。擅长并行执行，但所有结果都必须回传给主代理做汇总
• 技能（Skills）：单个代理按需动态加载专家级提示词。轻量灵活，但上下文会随对话不断累积
• 交接（Handoffs）：每个阶段切换成不同的活跃代理。天然适合顺序工作流，但无法并行处理任务
• 路由（Router）：对查询进行分类后并行分发，最后聚合结果。无状态 - 不保留对话上下文

场景一：一次性请求

“帮我买杯咖啡” - 一句话、一个意图、一个结果。专业代理调用 buy_coffee 工具搞定。

调用次数：子代理 4 次，技能/交接/路由 3 次。

核心洞察：一次性任务不需要状态。技能、交接、路由三种模式效率最高。子代理多一次往返，带来额外延迟。

实战建议：FAQ机器人、简单指令、单次查询 - 用单个代理就够了，别折腾多智能体。

场景二：重复请求

“再来一杯咖啡” - 同样的请求发第二遍，上下文需要延续。

调用次数（第2轮）：子代理 4→8 次累计。技能/交接 2→5 次累计（减少40%）。路由 3→6 次累计（减少25%）。

核心洞察：有状态的技能和交接模式碾压其他方案。子代理天生无状态，每次都要走完整流程 - 但换来的好处是上下文隔离更干净。

实战建议：聊天机器人、对话式助手、基于会话的服务 - 必须选有状态模式，否则用户体验会很割裂。

场景三：多领域查询

“对比一下Python、JavaScript和Rust” - 每种语言约2K token的文档量。

性能表现：子代理 5 次调用，约9K token。技能 3 次调用，约15K token。交接 7+ 次调用，约14K+ token。路由 5 次调用，约9K token。

核心洞察：支持并行的模式完胜。子代理和路由比技能模式节省67%的token。上下文隔离直接影响token成本。

实战建议：调研系统、多源分析、跨领域比较 - 用子代理或路由，token省下来的钱实打实。

模式选型速查表

场景	推荐模式
一次性任务	单个代理
高频重复请求	技能 或 交接
多领域并行处理	子代理 或 路由
顺序工作流	交接

一条实用原则

别一上来就搞多智能体。先从单个代理开始，把提示词写好，工具配齐。等真的遇到瓶颈了，再根据任务类型选对应的架构模式。选对架构带来的90%性能提升是真实的 - 但选错架构带来的反效果同样真实。