多智能体架构全景：从单体到专家团队

作者：程序员马丁

在线博客：https://nageoffer.com

note

Ragent AI —— 从 0 到 1 纯手工打造企业级 Agentic RAG，拒绝 Demo 玩具！AI 时代，助你拿个offer。

从第 4 篇讲 ReAct 到现在，咱们一直在做同一件事——给一个 Agent 加装备。工具调用、Function Calling、终止控制、短期记忆、持久化、长期记忆、上下文工程、Plan-and-Execute、Skill、Reflection、把 RAG 当工具……到上一篇为止，TinyAgent 已经是个装备精良的全能选手了。

但一个问题一直悬在那儿没正面回答：这些能力全压在同一个大脑上，它到底扛不扛得住？更实际的是——当你要做一个真正上生产的比特严选智能体，该用一个 Agent 硬扛，还是拆成一支专家团队协作？

这一篇咱们先不写代码。多智能体是本系列最后一块大拼图，也是最容易被拆得越多越高级这种错觉带偏的地方。所以进代码之前，得先把这张架构地图铺开，从第一性原理讲清楚四件事：单体 Agent 到底卡在哪、一个 Agent 的本质是什么、多智能体有哪几种玩法、以及怎么科学地选——而不是拍脑袋跟风。下一篇再动手手写主从式（也就是本系列要重点落地的那种）的代码。

单体 Agent：咱们是怎么一路走到这儿的

要讲清楚为什么需要多智能体，得先搞明白单体 Agent 强在哪、又卡在哪。批判要建立在公允之上，不然拆分就成了为拆而拆。

1. 单体 Agent 的本质：一个大脑扛所有

咱们前面手写的 TinyAgent，本质就是一个典型的单体 Agent（Single Agent）：一个 LLM，配一份 System Prompt，挂一堆工具，用原生的 ReAct 模式自主推理、调工具、记上下文、给答案。

它的逻辑非常直观：大模型没法直接内化比特严选的领域知识，那咱们就把这些知识、规矩、话术，一股脑写进 System Prompt 注入给它，指望它基于这些信息给出符合预期的回答。

这种做法最大的好处是开发链路最短、ROI 最高。你只要把领域知识整理好、指令写清楚，剩下的交给模型原生的 ReAct 循环。生成一段商品文案、回答一个退货政策、查一个订单——这类简单、单一的场景，单体 Agent 往往能跑出最流畅的体验，是验证想法、最快见效的原型方案。简单场景下，它就是性价比之王。

2. 先看一个它撑不住的场景

单体 Agent 的问题，得放到真实业务里才看得清。比特严选的客服每天要处理各种需求，咱们把三类最典型的放在一起看：

• “比特 AirX 耳机和 BandPro 耳机哪个好？我通勤用”——这是导购，要懂产品、会对比、能揣摩用户偏好，还得敢给明确推荐。
• “订单 88231 到了没？那台坏的扫地机我要退”——这是售后，要严守退款政策、核对订单状态、按流程一步步办。
• “我买了比特 Phone S1，想配一套运动装备”——这是 IoT 搭配，要懂生态、会跨品类组合、算得清组合价。

单看每一个，现在的 TinyAgent 都能处理。问题在于——当这三种角色被塞进同一个大脑，配一份大而全的 System Prompt、挂上全部 7 个工具时，它们会互相拖累。为什么？这就要拆开讲了。

这里仅用 3 个场景举例，实际生产环境中，动辄几十上百个业务场景。

3. 单体的天花板：三种结构性退化

单体 Agent 的软肋，可以归到三处。

第一，Context Window 会爆炸，注意力被稀释。 现在主流大模型动不动就宣称支持百万甚至千万 Token 上下文，但真到生产环境里，你把海量背景知识或长对话直接扔给模型，效果往往不尽如人意。这背后有个容易被忽略的真相：长上下文不等于长记忆。当输入数据量涨到一定阈值，模型极易出现 Lost in the Middle（中间信息丢失）现象——注意力被稀释，没法精准定位到它真正需要的那段知识。

这个问题咱们在第 15 篇分析 ReAct 天花板时就撞见过同一个根子：多领域的工具结果混在同一条消息链里，售后的退款单号、导购的商品规格、搭配的组合价交错堆积，模型综合回复时得从里面把相关的捡出来，上下文越长、领域跨得越多，捡错、捡漏的概率就越高。

第二，工具膨胀导致选择准确率下降。 第 14 篇讲上下文工程、第 18 篇讲跨品类编排时都提过：工具描述是要占 Token 的，工具数量涨到十几二十个，功能相近的就容易被混淆。单体 Agent 把所有工具一股脑塞进候选列表，用户只想对比两个耳机，模型却要在 7 个工具里挑——候选越多，选错、多选的概率越高，每一圈还都得把全部工具描述重新读一遍。

第三，人设冲突。 这点最隐蔽也最要命。比特严选的售后场景需要的是严谨、守规矩的人设——退款有没有超期、政策允不允许，一步都不能含糊；导购场景需要的是热情、有主见的人设——敢在两个商品里给明确推荐，甚至适度引导加购。你把这两种要求写进同一份 System Prompt，要么写得面面俱到、长到稀释重点，要么互相打架——严格遵守政策和主动引导加购放一块，模型到底该拘谨还是该放开？

这里要说清楚：单体 Agent 不是一定会在这些地方翻车，而是它没有任何机制去隔离这些干扰。规模小的时候一切正常，规模一大就容易退化——是可靠性下降，不是必然失败。这个区别很重要，后面选型时还要用到。

4. 你其实已经给单体打过两个补丁：RAG 和 Skill

有意思的是，面对上下文这个天花板，咱们在前面的篇章里其实已经动手打过两个补丁了——只是当时没把它们放到架构演进这个视角下看。

补丁一：RAG。 你在 RAG 系列里手写过一整套检索增强。它的逻辑是先搜后答：在把知识注入模型之前，先用检索召回一轮，只把和问题最相关的片段提取出来当上下文。这就巧妙绕开了 Context Window 的长度限制，让 Agent 按需取知识，而不是全量吞。但 RAG 有个致命依赖——垃圾进，垃圾出。Agent 的表现高度依赖前置检索的准确率，检索没召回对的片段，后面模型再强也白搭。而检索这一环通常靠关键词匹配或小参数量的 Embedding 模型，它们的语义理解深度和大模型直接读全文比，是有能力断层的，漏召、误召就成了瓶颈。

补丁二：Skill。 你在第 16、17 篇亲手实现过。它把领域知识、操作规范封装成一个个说明书文件，主 Agent 不预加载全部知识，而是运行时按需读取对应的 Skill——这就是渐进式披露（Progressive Disclosure）。第 17 篇还特意讲过一个关键细节：Skill 不是去动态替换 System Prompt（那样会让模型认知错乱——身份变了但历史还是旧身份下生成的），而是 System Prompt 恒定、把 Skill 内容当作新的参考资料动态注入。所以 Skill 本质是回归单体 Agent 本体、但给它装上动态扩展能力，既轻量、上下文又一致。缺点是 Skill 并没有隔离上下文——每次激活一个 Skill，注入的指令文本和产生的工具调用结果，都堆在主 Agent 的同一条消息链里，不会因为切换到下一个 Skill 就自动清掉。用户在一轮对话里切得越频繁，这条上下文就越长，最终还是会撞上 Context Window 的老问题。

两者的共同点很明显：RAG 和 Skill，本质都是在不拆多个大脑的前提下，给单体 Agent 扩展能力边界。 它们都很有效——这也正是为什么不能急着否定单体。

5. 单体 Agent 的边界：什么时候它就够用

综合下来，单体 Agent 虽然不适合所有场景，但在下面这些条件下，它依然是落地最快、性价比最高的选择：

• 场景复杂度低：业务逻辑简单，不需要复杂的多步推理或长链条规划。
• 知识体量可控：核心指令加背景知识，在约等于两万（非恒定指标）Token 以内能说清楚，直接 System Prompt 注入即可。
• 检索质量有保障：如果非要用 RAG，前提是知识库结构清晰、检索召回准确率够高。

需求小而美、领域边界清晰、检索链路成熟的场景，单体 Agent 完全够用，别过度设计。

维度	单体 Agent 的优势	单体 Agent 的劣势
架构	最原生、开发链路最短	单点能力有上限
性能	无通信开销、延迟低	工具一多，选择准确率下降
上下文	完整、无跨 Agent 信息损耗	极度依赖窗口质量，易爆炸、易 Lost in the Middle
人设	简单场景一套人设够用	多角色写进一份 Prompt 会打架
适用	Demo、单域简单任务、知识依赖少	海量知识、复杂推理、多领域协作

当你面对海量非结构化数据、复杂推理需求、或者多个人设差异巨大的领域时，就该跳出单点思维，看看多智能体这张地图了。但在铺开地图之前，得先回答一个更本质的问题。

先搞清楚：什么是一个 Agent

要谈多智能体，得先从第一性原理搞清楚一个智能体到底由什么构成。把咱们前面二十篇搭起来的 ReActAgent 抽象一下，任何一个 Agent 都可以拆成四个要素。

1. Agent 的四要素

• 人设（Persona）：一段 System Prompt，定义这个 Agent 是谁、擅长什么、遵守什么规矩。这是它的人格。
• 能力（Capability）：它能调用的工具集合。不是所有工具，而是它这个角色需要的那些。
• 上下文（Context）：它自己的对话记忆和工具结果。关键在于——每个 Agent 有自己独立的上下文。
• 循环（Loop）：驱动它一步步推理、行动、观察的引擎，也就是咱们前面手写的 ReAct 循环。

这个抽象不是我拍脑袋定的，而是从主流框架里提炼出来的共识。LangChain4j 的 agentic 模块里万物皆 Agent——一个带 @Agent 注解的接口就是一个 Agent，连工作流本身都是 Agent；AgentScope 里每个 Agent 都持有自己的 memory，靠消息互通；Spring AI 的子 Agent 拿一个全新隔离的上下文，只把最终结果回传给父级。剥开框架的外壳，内核都是这四要素。

2. 单体和多智能体，差别就在四要素怎么摆

看懂四要素，单体和多智能体的区别就一目了然了：

• 单体 Agent：四要素各一份，全塞在一起。一份大而全的人设、7 个工具全暴露、一条混合上下文、一个循环。它就是那个全科医生，什么都沾一点，但样样被别的角色拖累。
• 多智能体：每个专家一套完整的四要素，按领域切开。商品咨询专家有导购人设 + 对比检索工具 + 自己干净的上下文；售后专家有严谨人设 + 订单退款工具 + 自己干净的上下文；互不串味。这就是一家专科医院，每个科室的医生知识更聚焦、诊断更专业。

所以多智能体的第一性原理其实特别朴素：把单体那份揉在一起的四要素，按领域拆成几套干净的四要素。 拆分的收益（隔离干扰）和代价（要协调这几套四要素），后面会一条条讲。

多智能体：不是把 Agent 堆起来，是换一种架构范式

这里有个常见误解要先澄清：多智能体（Multi-Agent）不是 Agent 数量的堆叠，而是架构范式的切换。 上三个 Agent 不等于比一个 Agent 强三倍，弄不好还更差（后面有实验数据）。

1. 核心逻辑：路由分发 + 领域隔离

用医院的比方最好懂。多智能体像一家有分诊台的专科医院：门口的导医（主 Agent）只负责判断问题该挂哪个科，然后分诊给对应的专科医生（子 Agent）。心内科专家不用懂骨科，他的知识更聚焦、诊断更专业。

落到 Agent 上就是两个关键词：

• 路由分发：主 Agent（Orchestrator，编排者）扮演大脑，只做意图识别和任务路由，判断问题该交给谁，不用背负所有领域的知识重担。
• 领域隔离：每个子 Agent（Sub-Agent）有独立的身份，只内化某一类垂直场景的专业知识。它的 Prompt 更精简，工具更聚焦。

放到比特严选：用户说“订单 88231 到了没，帮我退掉”——主 Agent 识别是售后意图，派给售后 Agent；用户说“AirX 和 BandPro 哪个好”——派给商品咨询 Agent；用户说“给我的 Phone S1 配套运动装备”——派给 IoT 搭配 Agent。每个专家只在自己的领域里干活，工具、人设、上下文全是干净隔离的。

2. 别和 Skill 搞混：同上下文 vs 隔离上下文

讲到这里，学过第 16、17 篇的读者可能会犯嘀咕：这不就是 Skill 吗？ 技能不也是按场景封装一套工具和指令？这个问题得掰扯清楚，否则后面全乱套。

区别就在一个词：上下文。

• Skill 是同上下文内的模块化。 activate_skill 做的事情是把技能的指令加载进当前这个 Agent 的主上下文，再动态解锁几个专属工具。整个过程自始至终只有一个 Agent、一条 上下文。技能只是给这一个大脑临时换了套作业指导书，大脑还是同一个。
• 子 Agent 是隔离上下文的另一个大脑。 多智能体里的每个专家，是独立的一个 Agent——独立的人设、工具集、上下文。商品咨询 Agent 推理时，它的上下文里根本看不到售后 Agent 处理过什么。这是两个大脑，不是一个大脑的两套指导书。

对比维度	Skill（同上下文模块化）	子 Agent（隔离的另一个大脑）
上下文	共用主 Agent 的一条上下文	每个子 Agent 有独立上下文
人设	共用主 Agent 的人设，指令临时叠加	每个子 Agent 有自己独立人设
工具	动态解锁到主 Agent 的可见列表	每个子 Agent 只带自己的工具子集
隔离性	弱（指令、工具、结果都在一条上下文里累积）	强（领域之间互不干扰）
开销	低（不额外起 Agent，一次循环搞定）	高（每个子 Agent 是独立的推理循环）
适合场景	高频、稳定、单领域的流程沉淀	多领域、人设差异大、需要隔离干扰

判断标准也简单：想把一套稳定流程沉淀下来、避免重复规划，用 Skill 就够了；只有当不同任务的人设要求差异很大、或领域跨度大到会互相串味，才值得拆成子 Agent。 两者也不冲突——一个售后 Agent 内部，照样可以用退款 Skill 沉淀它的高频流程。Skill 解决流程复用，子 Agent 解决领域隔离，是两个维度的事。

3. Google 论文里的四种范式

多智能体具体怎么组织，业界有很多种玩法。Google Research、DeepMind 和 MIT 联合发表的《Towards a Science of Scaling Agent Systems》（arXiv:2512.08296）把主流架构归纳成四种（加上单体，一共五种）：

• 独立（Independent）：任务由外部逻辑预先拆好，多个子 Agent 各领一块并行处理，彼此不沟通，也没有人统筹调度或校验，结果直接拼接汇总。举个例子：你在代码里写死一条规则——消息含 订单 就丢给订单 Agent，含 对比 就丢给对比 Agent。谁来干、怎么拆是硬编码定死的，不是某个大脑在运行时动态判断的；干完的结果也是机械拼接，没有任何智能审核。重点：无中央、无沟通、无校验。
• 去中心化（Decentralized）：点对点网状结构，子 Agent 之间直接沟通、共享信息、达成共识，没有中央大脑。
• 中心化（Centralized）：也就是主从式。和独立最大的区别是多了一个中央 Orchestrator 扮演大脑——由它判断怎么拆任务、该派给谁、结果对不对。子 Agent 干完把结果交回 Orchestrator，经它综合审核后再输出给用户。中心辐射结构，重点：有中央、有调度、有校验。
• 混合（Hybrid）：层级监督 + 点对点协调的组合，团队的团队，平衡中央控制和灵活执行。

一个关键区分：前两种（独立、去中心化）只有子 Agent，没有中央大脑；后两种（中心化、混合）都有一个 Orchestrator 作为主 Agent。

4. 重点：中心化主从式——本系列的主角

前面四种范式一笔带过，读者可能还没建立直觉。这里重点拎两种最常被拿来比较的——中心化和去中心化——多举几个例子把手感找到。

中心化主从式，核心是有一个人拍板。 所有请求汇到一个中央节点，由它统一决策、分发、校验。生活中到处是这种结构：

• 外卖平台的调度中心：用户下单，调度中心算出最优骑手派单，骑手送完回报调度中心。骑手之间不需要互相沟通，调度中心是唯一的协调者。好处是高效可控；坏处是调度中心一挂，全城瘫痪。
• 公司里的项目经理：需求进来，PM 拆成前端、后端、测试三个子任务分别派人，各自干完交回给 PM，PM 整合后交付。每个人只管自己的活，PM 负责拼全局。
• 落到 Agent：主 Agent（Orchestrator）就是那个调度中心。用户请求进来，它判断意图、拆任务、派给对应的子 Agent，子 Agent 干完把结果交回来，主 Agent 校验、综合后回复用户。

去中心化，核心是没有谁说了算，大家商量着来。 没有中央节点，参与者之间直接沟通，靠讨论和共识收敛到一个结论：

• 一群同事围坐头脑风暴：没有主持人，谁有想法谁说，其他人补充或反驳，讨论到大家都认可为止。好处是视角多元、容易迸出意外的好点子；坏处是讨论可能发散收不回来，三个人吵半天没结论。
• 开源社区的 RFC 讨论：一个提案丢出来，十几个 maintainer 各自评论、互相引用、反复修改，最终靠 rough consensus 定稿。效率不高，但质量往往很扎实，因为经过了充分的对抗性检验。
• 落到 Agent：几个子 Agent 拿到同一个问题，各自给出答案，然后互相看对方的回答、指出漏洞、补充观点，经过几轮辩论收敛出最终结论。没有谁是老板，靠群体智慧胜出。

一句话概括：中心化像公司——有老板统筹，效率高但老板是瓶颈；去中心化像社区——没老板，靠共识，探索能力强但收敛慢、成本高。

搞清楚手感后，再说为什么本系列选中心化主从式。四个理由：

• 错误可控：主 Agent 天然是个校验瓶颈——子 Agent 的输出要经过它审核、综合，才给到用户。这一步卡口能拦住不少错误（后面有数据，这是它最大的护城河）。
• 职责单一、Prompt 精简：主 Agent 只管路由，子 Agent 只管一个领域，每个节点的提示词都干净可控。
• 可独立调优：售后 Agent 效果不好，只针对性优化它一个，不影响商品和 IoT Agent，维护灵活性大大提升。
• 支持并行：无依赖的子任务可以并发跑，提升吞吐。

它的短板也很清楚：主 Agent 会成为性能和故障的瓶颈，任务拆分的质量直接决定整体上限，上下文在主子之间传递还有损耗（这几点第 23 篇会专门破）。

范式	结构	有无中央大脑	优点	缺点	适用场景
独立	并行不通信	无	简单、并行快	无校验，错误放大最狠	子任务完全独立、结果可直接拼
去中心化	点对点网状	无	涌现能力强、无单点瓶颈	通信成本高、收敛慢、难复现	开放探索、辩论、创造性任务
中心化主从	中心辐射	有 Orchestrator	错误可控、职责单一、易调优	主 Agent 是瓶颈、拆分质量决定上限	多领域复杂任务（生产主流）
混合	层级 + 网状	有	可撑超大规模	架构复杂、运维成本高、延迟叠加	超大规模企业级平台

多智能体不是银弹：复杂度只是被转移了

好处讲完了，代价也得讲透。多智能体解决了单体的知识隔离问题，但它把复杂度转移到了别处——引入了三个新瓶颈。

1. 路由准确率的压力

当子 Agent 只有三五个时，主 Agent 分诊还算轻松。但如果场景膨胀到几十上百个子 Agent，主 Agent 就要在极短的上下文里精准判断意图、分发到正确的科室。一旦误路由（Misrouting），后面子 Agent 再努力也是白搭——导医把心梗病人分到了皮肤科，皮肤科医生再专业也没用。而且这种风险随节点数量增加是累积叠加的。

2. 上下文割裂（最隐蔽的痛点）

这是主从式最隐蔽也最容易翻车的地方。子 Agent 往往只盯着自己任务的局部最优，缺乏对全局上下文和用户完整意图的感知，于是会出现两种现象：

• 重复执行：用户问“订单 88231 的扫地机为啥连不上网”，售后 Agent 查了订单、诊断了一轮；用户追问“那给我换台新的推荐啥”，商品 Agent 接手，因为不知道前面已经查过这台设备，可能又把订单查一遍——白白浪费算力和响应时间。
• 结论冲突：不同子 Agent 基于各自的局部信息，可能得出互相矛盾的结论，回答逻辑不自洽，用户一脸问号。

换个科室就得重新问一遍病史，还可能两个医生说法打架——这就是上下文割裂。

3. 通信带宽的两难

为了解决割裂，一个自然的想法是让子 Agent 之间共享上下文历史。但工程上这又撞上通信带宽的两难：

• 信息有损压缩：主 Agent 传给子 Agent 的，往往是经过摘要（Summary）或改写（Rewrite）的上下文，而不是原始对话流。这种有损传输很可能丢掉关键细节——比如用户明明说预算 1000 以内，摘要时给漏了，子 Agent 就推荐了台 2000 的。
• Token 爆炸与耗时：如果为了不丢信息，强行扩大通信带宽、把原始上下文全传过去，又会迅速引发新的 Context Window 爆炸，还显著拉长生成时间和整体链路耗时——绕了一圈又回到单体的老问题上。

说到底：多智能体没有消灭复杂度，只是把它从单体内部的纠结转移成了多体之间的协同。想构建高质量的主从式系统，你得投入精力去打磨每个节点、设计通信协议、调摘要策略、处理边界 Case。Agent 越多，协同治理的难度非线性上升。

别再拍脑袋：怎么科学地选架构

前几年做 Agent，架构选型基本靠直觉和经验——架构演化太快，LLM 系统本身不确定性又强。好在这两年开始有实证研究给出可参考的方法论了。

1. Google DeepMind 的五条实证结论

前面提到的那篇论文，做了一个大规模受控实验：跨 6 个 agentic benchmark、5 种架构（单体 + 四种多智能体）、3 个模型家族（GPT、Gemini、Claude），标准化工具、提示词和算力，共 260 组配置，就为了把架构这个变量单独拎出来看。结论里有好几条相当反直觉，值得咱们拿来校准选型：

结论一：模型越强效果越好，但 Agent 越多不一定越好。 Agent 能力和模型能力基本正相关，但多智能体不是万能解——有时候上了显著提升，有时候意外降低。别无脑堆 Agent 数量。

结论二：尽量降低沟通成本和通信带宽。 在固定 Token 预算下，频繁的 Agent 间沟通会显著降低整体效果——因为沟通本身消耗宝贵的 Context Window，挤占了用于推理和知识注入的空间。这恰好印证了前面 Skill 那一段的道理：能由单个 Agent 内部消化的逻辑，尽量别拆成多轮跨 Agent 对话。

结论三：单 Agent 的 45% 阈值法则。 当单个 Agent 的任务成功率已经超过 45%，单纯增加 Agent 数量带来的收益就边际递减、甚至转负（论文里这个系数 β=-0.408，统计显著）。意思是：如果你的单体基线已经够好，硬上复杂的多智能体协同，反而拉低整体表现。

结论四：错误放大效应。 论文用受控实验量化了一个关键比值：以单体 Agent 的错误数为基线 1，纯独立架构（无中央校验）的系统级错误数是基线的 17.2 倍，而引入中心化校验后能压到 4.4 倍。打个比方：同一批测试题，单体 Agent 答错 10 道，把任务拆给几个独立子 Agent 各干各的、结果直接拼，最终错的不是 10 道而是 172 道——因为每个子 Agent 都可能出错，又没人交叉检查，错误不会互相抵消，只会叠加放大。而主从式多了一个主 Agent 做校验瓶颈，相当于拼结果前有人过一遍，错误数就从 172 道降到了 44 道。没有监管的群策群力，极易变成集体幻觉——这正是主从式相比无监管独立架构的核心护城河。

结论五：场景决定架构，没有万能钥匙。 论文在不同任务上跑下来发现：

• 串行推理类任务（一步步规划、复杂推理链）：单体最优，多智能体反而降效 39%~70%——因为跨 Agent 通信打断了推理链（chain-of-thought）。
• 可并行 / 可分解任务（比如金融推理）：中心化主从最佳，能提升约 80.9%。
• 动态搜索 / 高熵任务（比如网页浏览）：去中心化的点对点辩论更有优势（+9.2%），因为多样化探索能帮着在不确定空间里试错。

任务类型	特征	推荐架构	对应比特严选场景
串行推理	强逻辑、工具依赖少	单体 Agent	一步步排障、单链条规划
可并行 / 可分解	子任务能拆开再合并	中心化主从	对比 + 搭配 + 查订单一起来
动态搜索 / 高熵	路径不确定、要试错	去中心化	开放式选购探索（少见）

论文的价值在于：它让你从任务本身的属性（有多少串行依赖、工具密度多高）出发去选架构，而不是拍脑袋赌一个 vs 一群。这个框架能预测 87% 的最优架构选择。

2. 奥卡姆剃刀：一条由简入繁的选型路径

把上面这些结论收敛成一句可操作的原则，就是奥卡姆剃刀——如无必要，勿增实体。理想的 Agent 建设路径应该是由简入繁、按需升级：

• P0：能用单体解决的，绝不上复杂架构。 呼应 45% 阈值——单体基线够好就别折腾。
• P1：遇到知识瓶颈，优先上 Skill。 用动态渐进式加载扩展能力边界，比多智能体轻量，也比 RAG 精准，还保住了全局上下文一致性。
• P2：只有上述方案失效、且对效果上限有极致追求时，再谨慎启用主从式多智能体，并做好长期调优的准备。
• P3：针对高度不确定的探索性任务，再灵活叠加 Agent Teams 这类并行协作能力。

补一句 Agent Teams 是啥：这是 Anthropic 在实验性文章里提的更新形态——多个子身份并行探索同一个开放难题，还实时共享一个 Task List、彼此看得见进度。它不是为了解决知识注入，而是为了啃那些没有标准答案、不知从何下手的探索题，靠并行的多样性胜过串行的确定性。代价是算力成倍增加，而且并行探索必须配一个强中心化的校验机制兜底（否则就是结论四里的错误放大 17.2 倍）。比特严选的客服场景大多有明确套路，用到 P3 的机会不多，本系列会点到为止。

落到比特严选：该不该上主从式

绕了一大圈，回到咱们自己的场景——比特严选到底该不该上多智能体，上哪种？

1. 该上主从式，三个理由

• 人设差异大：售后要严谨守政策、导购要热情有主见、IoT 搭配要懂生态会算账——这三种人设塞进一份 System Prompt 会互相打架，正是领域隔离能解决的。
• 跨品类复合请求多：比特严选的核心竞争力就在跨品类。用户一句话经常横跨对比、搭配、售后好几个领域（回顾第 18 篇那个例子）。这类可分解任务，正是结论五里中心化主从最擅长的（+80.9%），而且单体处理复合任务时基线成功率并不高——容易漏子任务，正好在 45% 阈值以下，拆开更划算。
• 要错误可控：客服直接面对用户，退款、订单这些操作对出错很敏感。主从式的中央校验瓶颈（错误放大只有 4.4 倍 vs 独立的 17.2 倍）正好压得住。

2. 那这支专家团队长啥样

顺着前面四要素按领域切开的思路，比特严选的客服场景自然切成三个专家。工具全部复用前面篇章已经实现的（第 18 篇的基础工具 + 第 20 篇的 RagSearchTool），不新造：

专家 Agent	人设关键词	工具子集	负责场景
商品咨询 Agent	专业、会对比、有主见的选购顾问	compareProducts、ragSearch	规格对比、选购建议、功能咨询
售后服务 Agent	严谨、守政策、按流程办事	queryOrder、queryLogistics、applyRefund	查订单、查物流、退款换货
IoT 搭配 Agent	懂生态、会跨品类组合的搭配顾问	recommendBundle、ragSearch	IoT 套装推荐、跨品类搭配

划分上有两个讲究：一是按人设差异切，而不是按工具切——为什么售后单独一个 Agent？因为它的人设要求和另外两个差别最大，隔离出来就不用担心导购那套主动推销的调性污染退款判断。二是工具子集要最小充分——每个专家只带自己真正用得上的工具，商品咨询 Agent 不需要 applyRefund 就别给它，候选越少选对概率越高（正好对症前面说的工具膨胀）。至于每个专家具体怎么用带人设的 ReActAgent 实现、主 Agent 怎么把请求分诊给它们，就是下一篇动手写代码的事了。

3. 但也要守住剃刀

用户只问“你们退货政策是啥”或“订单 88231 到哪了”这种单域简单问题，仍然走单体或 Skill 就好，没必要惊动整个专家团队。别为了用多智能体而多智能体。

所以本系列接下来三篇的路线是这样的：

• 第 22 篇：手写主从式的骨架——Orchestrator 怎么做路由分发、SpecialistAgent 怎么复用咱们已有的 ReActAgent，从最轻量的确定性路由，到能自主决策的 LLM Supervisor。
• 第 23 篇：破解主从式的头号痛点——上下文割裂。共享黑板、消息传递、结果聚合、依赖 handoff，怎么让专家之间不重复、不冲突。
• 第 24 篇：端到端实战 + 拓扑变体（并行子任务、评审循环、Agent Teams 一瞥）+ 工程治理（状态外置、可观测、容错、成本），把整套主从式在比特严选场景里跑通。

文末总结

这一篇没写代码，专门把多智能体的架构地图和选型逻辑铺开：

• 单体 Agent 不是不能用，但有结构性天花板——上下文爆炸、工具膨胀、人设冲突，RAG 和 Skill 是两个有效的补丁，但补不了领域隔离的根本需求。
• 一个 Agent 的本质 = 四要素（人设、能力、上下文、循环），多智能体就是把揉在一起的四要素按领域拆成几套干净的。别和 Skill 搞混——Skill 是同一个大脑换指导书，子 Agent 是隔离上下文的另一个大脑。
• 中心化主从式是当下生产主流，靠路由分发 + 领域隔离 + 中央校验站稳脚跟。但它不是银弹——路由准确率压力、上下文割裂、通信带宽两难，复杂度只是从单体内部转移到了多体协同。
• 选型靠任务结构，不靠直觉——DeepMind 论文的 45% 阈值、错误放大系数、场景决定架构三条结论，配上奥卡姆剃刀的 P0→P3 升级路径，能覆盖大部分决策。落到比特严选：人设差异大、跨品类可分解、要错误可控，值得上主从式。

地图铺开了，方向也定了——比特严选值得上主从式，团队也画好了。下一篇，咱们就动手：手写一个能把用户请求分诊给对口专家的主从式骨架。