小白程序员必看：多智能体组件如何高效协作，提升大模型应用性能

本文介绍了多智能体组件在大模型应用中的重要性，分析了不同协作模式的适用场景，并通过实际案例比较了各模式的调用次数和token消耗。重点探讨了Subagents、Handoffs、Skills和Router四种模式的优缺点，帮助读者根据实际需求选择合适的多智能体架构，提升大模型应用的效率和效果。

多智能体能协调专业组件，但不是每个复杂任务都需要，一个提示写清楚、工具按需筛选的单 Agent，经常就够。

本篇先不急着写实现，重点先看三个问题：为什么需要多 Agent、常见模式分别解决什么问题，以及调用次数和 token 为什么会拉开差距。

具体不同模式的代码实现放到下一 篇。

一、概述

多 Agent并不是多调用几次模型那么简单，而是多个专业组件按某种协议协作。以下场景经常使用到：

1. 1 上下文管理

假如上下文无限、延迟为零，我们就可以把日历手册、邮件规范、CRM 字段说明、退款政策全塞进一个 system prompt，让一个超级 Agent 搞定。但是现实不能这样，因为：

1. 窗口有上限，塞满了后面的指令会被挤掉或注意力变差。

2. 无关知识会干扰决策，退款政策和「写营销文案」放一起，模型更容易串戏。

3. 每次调用都带上全量知识，token 费和延迟一起涨。

所以我们需要一种模式，让只有在相关时，把相关知识露出来。Subagents 用干净子窗口隔离；Skills 用按需加载；Router 用分到不同领域代理。

1. 2 分布式开发

日历组维护日历 Agent，邮件组维护邮件 Agent，协调层只约定「怎么调用、输入输出长什么样」。这和微服务想解决的问题类似：变更局部化。如果没有清晰边界，所有人去改同一个 300 行 system prompt，合并冲突和回归会很难。

1. 3 并行化

对比 Python / JS / Rust 做 Web 这类任务，三个领域彼此独立。如果串行问三遍，用户多等两轮模型；但是要是并行执行三个agent，时间接近最慢的那一个。能不能并行，是后面选型表里很重要的一列。

1. 4 什么时候值得上多 Agent

官方给了几点建议：

当然也有不该使用多agent的情况。

记住一句：先问是模型能力不够，还是上下文不对，当然上下文的情况更常见。先做工具筛选和提示分层，不行再考虑加agent。

二、五种模式

2. 1 模式概览

2. 2 选型维度

选型时核心看四个维度：代码怎么组织、任务能不能并行、要不要连续多步、能不能中途问用户。

1. 分布式开发：代码能不能分开维护

不同团队能不能独立改自己的组件、靠约定组合？

1. 并行化：能不能同时跑多个

有些任务可以同时做（比如同时查三个订单），这时候能不能并行提高效率。

1. 多跳（Multi-hop）：任务要连续走几步

有些任务要串成链条：例如先调研 → 再写作 → 再按反馈修改。特点是上一步的输出是下一步的输入。

1. 直接对用户交互：能不能中途回头问用户

子任务执行到一半，发现缺信息，能不能停下来问用户要补充材料？

选型速查表：

注意一个模式在某维度上弱，不代表不能用，只是代表你需要额外工作来补。

比如说 Router 在多跳上弱，但如果你把“跳”的逻辑做在子agent内部（子agent本身也是完整的 Agent，内部可以做多步），那路由层只负责分一次类也够用。选型时看的是“原生支持度”，不是“能不能硬做”。

2. 3 按优化目标选

模式可以组合：主agent用 Subagents，某个工具内部再跑一个小 Router；子agent里用 Skills 加载规范。先让一条主路径跑通，再嵌第二层。

2. 4 监督者 vs 路由器区别

监督者（Subagents 里的主agent）：本身是完整 Agent，带着对话记忆，多轮里动态决定「现在该调哪个子agent、调几次、怎么合并」。

路由器（Router）：常常是一步分类（也可以是一小段图），把请求派出去；它不一定维持「我正在和用户闲聊」的长期人格。多轮闲聊若硬套无状态 Router，每轮都重新分类，口吻和上下文容易散。

三、表现比较

选型不能只看好不好维护，还要看延迟和花销。两个指标：

1. 模型调用次数：每多一次 LLM 调用，就多一截串行等待（除非你并行），也多一笔按次费用。

2. 处理的 token 总量：所有调用的上下文加起来。窗口占用、计费、注意力质量都跟它有关。

下面是官方文档三个场景的花销和调用次数估算，用来参考，注意数值业务上的绝对值。

3. 1 单次请求：「买杯咖啡」

假如有个用户请求:“buy coffe”。

专门的咖啡代理/技能会调buy_coffee。

Subagents 为什么多 1 次？因为结果要回流主代理，主代理再组织成对用户的话。这 1 次是「集中控制」的税：主代理始终握着编排权，代价是多一步。

Handoffs / Skills / Router 在这种一件事做完可以直接回复，路径上更直接，所以是 3。

3. 2 重复请求：同一对话里再说一次「再买一杯」

Subagents 为什么还是 4？ 子代理默认无状态：每次工具调用都是冷启动，主代理虽然记得聊天，子代理不记得「上轮已经是咖啡场景」。隔离换来的是每次成本稳定，不会因为历史变长而串戏，但重复劳动也稳定存在。

Handoffs 为什么第 2 轮变 2？ 咖啡代理/咖啡步骤从第 1 轮起就还在（current_step或active_agent由 checkpointer 保住）。不必再交接，直接buy_coffee+ 回复。

Skills 为什么也是 2？ 技能正文已经在对话历史里（上一轮load_skill的 ToolMessage 还在）。不必再加载，直接调业务工具。

Router 为什么还是 3？ 无状态路由每轮都要先分类。可以优化：把 Router 包成有状态对话代理的一个工具，具体做法放在第 17 篇第四节。

粗算：有状态模式在重复请求上能省大约 40%–50% 的调用。这不是魔法，是少做了一次切换/加载。

3. 3 多领域：对比三种语言做 Web

用户问：「比较 Python、JavaScript 和 Rust 在 Web 开发中的应用。」

设定：

1. 每个语言各自有一份约 2000 token 的领域文档（框架生态、典型写法、坑）。

2. 任务天然可拆成三个彼此独立的子问题，最后再合成一段对比。

3. 我们关心两件事：要调几次模型，以及所有调用加起来吃了多少 token。

这个场景最能拉开四种模式的差距，以为单次「买咖啡」大家差不多，多领域才会同时考到并行和上下文隔离。

下面按模式分析谁在什么窗口里看见什么、调用怎么数。数字是官方文档参考。

（1）Subagents：并行 + 厚文档不进主窗

典型链路（约 5 次调用）：

1. 主代理读用户问题，决定要请三个语言专家（1 次）。

2. 同一轮里并行打出三个子代理工具（或连续很快打出）；每个子代理在自己的干净窗口里，带着自己那 2K 文档做一次（或少数几次）推理（计 3 次量级）。

3. 三份短摘要回到主代理，主代理写成对比回答（1 次）。

关键差别在「隔离」：

1. Python 子代理的窗口里只有 Python 文档 + 短查询，看不见 Rust 那 2K，也不会被主对话里的闲聊污染。

2. 主代理窗口里最终多的是三份摘要，不是 6K 原文说明书。

3. 所以总 token 能压到约 9K 量级：三份 2K 分别在三条短链路里各算一次，而不是叠在同一个越来越长的上下文里反复搬运。

主代理多出来的那一步（汇总）是税，但换来集中控制和可并行。多领域对比是 Subagents 的主场之一。

（2）Handoffs：一个工位串行逛完三个域

Handoffs 的模型是，每一步只有一个活跃agent，它能直接与用户交互。路径如下：

1. 进入 Python 子agent（或从通用接待交接过去），带着 Python 文档聊/总结。

2. 再交接进 JavaScript 子agent——此时对话历史里已经有上一域的讨论。

3. 再交接进 Rust 子Agent，历史会话更长。

4. 最后在某个工位（或再切回综合）写成对比。

于是出现两个结构性缺点：

1. 很难并行。 工位是互斥的，不能像三个 tool_calls 那样同时转。墙钟时间和调用次数都容易变成 7+。

2. 上下文会滚雪球。 每换一域，旧域的对话还在；再叠上各域文档/提示，总量往 14K+ 走。官方表里 Handoffs 在多领域最差，不是调参问题，是模式不匹配。

适合必须串行解锁的流程；不适合同时请教三个专家再对比这种需要并行的流程。

（3）Skills：调用可以很少，但三份说明书挤同一窗

Skills 仍是一个代理。路径可能很短（约 3 次调用量级）：

1. 加载 python / js / rust 三个技能（有时模型会合并成较少次 load，这里按「技能正文进历史」理解）。

2. 在同一对话里阅读三份文档并写对比。

3. 回复用户。

调用次数很少，但 token 消耗很高：

1. 三个技能各约 2K，一旦 load 进同一条 messages，后面这次（以及若用户追问的下一轮）推理，往往要反复带着合计约 6K 技能正文走。

2. 没有「子窗口」把文档隔开，隔离发生在「是否 load」，不发生在「load 之后分房间算」。

3. 所以官方估算总 token 约 15K，比 Subagents/Router 的 ~9K 更高。调用少 ≠ 更便宜；多领域厚文档时，Skills 容易变成「次数好看、总量难看」。

Skills 更适合：同一时刻主要只用一个领域的厚提示，或技能很短。三个厚领域要并列对比时，它不太适合。

（4）Router：显式分类，然后并行扇出

Router 和 Subagents 在多领域上数字接近（约 5 次、~9K），骨架不同：

1. 先有一步分类（1 次）：判断要咨询哪些域，这里是 python / js / rust 三个都要。

2. **用Send（或等价扇出）并行
   因此官方在「大上下文 + 多领域」上勾 Subagents 与 Router，不是口味问题，是并行与隔离两条机制叠在一起的结果。

3. 4 对照小结

具体数字不用记，只要记住每个模式他在不同场景的优缺点就行。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包：

• ✅ 从零到一的 AI 学习路径图
• ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
• ✅ 百度/阿里专家闭门录播课
• ✅ 大模型当下最新行业报告
• ✅ 真实大厂面试真题
• ✅ 2026 最新岗位需求图谱

所有资料 ⚡️ ，朋友们如果有需要《AI大模型入门+进阶学习资源包》，下方扫码获取~

① 全套AI大模型应用开发视频教程

（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）

② 大模型系统化学习路线

作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

③ 大模型学习书籍&文档

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

④ AI大模型最新行业报告

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

⑤ 大模型项目实战&配套源码

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

⑥ 大模型大厂面试真题

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

以上资料如何领取？

为什么大家都在学大模型？

最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！

不出1年，“有AI项目经验”将成为投递简历的门槛。

风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！

这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

以上全套大模型资料如何领取？