第 9 章 何时需要多智能体

什么时候才真的需要多智能体，多数团队回答不上来，这一章给三件判断工具：9.1 的四级架构阶梯加三个逐级追问的问题，9.2 的最简可行架构原则加一组实测代价数字（token、延迟、调试和误差面四项，外加隔离的省钱空间核算），9.3 的任务复杂度评估（四个任务特征圈出候选，三道关卡逐一筛选，电商客服中文案例走完全程）。背景数字来自 Victor Dibia 的公开通讯（What Types of Agents are Companies Building?，2025 年 5 月）：Y Combinator 孵化器 5,304 家公司的公开描述里，做 AI 智能体的占比从 2020 年的 5.9% 涨到 2025 年的 50.8%，五年翻了八倍多。方向这么热，这一章的立场反而是：多智能体值得学习，但第一步是学会不使用它，升级要有证据，不凭感觉。

9.1 架构升级阶梯

架构选择有一件现成的判断工具：一道从简单到复杂的四级阶梯，加三个逐级追问的问题。评审会上常见的情形正是缺了它，需求刚讲到一半，就有人提议使用多智能体，规划、执行和审查三个角色分工明确，听起来很专业，也很少有人反对，但真要问一句为什么需要，往往没人答得上来；架构到底应该从最复杂的方案里选，还是从任务本身出发，多数团队手里并没有现成的判断工具。这一节沿着阶梯往上讲，从最底层的第一级开始，说明每一级要解决什么问题、要付出什么代价。

第一级是直连模型。应用直接调用一次模型的 API，不接入回路、不带工具、不保存状态，输入文本，输出文本。这一级要判断的是任务仅凭生成文本能不能完成。最常见的例子是询问埃菲尔铁塔的高度，换成中文场景同样适用，把一句商品描述翻译成英文、判断一条差评的情绪倾向、按固定格式从合同里抽取甲乙方与金额，都是输入文本、输出文本，模型参数里存储的知识足以应付。

直连模型几乎不产生费用，只有一次调用，行为也最容易复现，排查问题只需查看一对输入输出。它看起来不太像一种架构，但正因为什么都没有额外添加，便宜、快速和可预测这三个优点，是另外三级都无法提供的。

这一级同样需要工程工作，系统提示、少样本示例和结构化输出约束都属于这一类，提示词打磨到位，很多表面上看起来需要智能体的任务，在这一级就能解决。

那什么时候才算不够用？判断标准只有一条，任务需要的答案不在模型参数里。询问某只股票当前的价格，训练数据里没有当前信息，模型只能靠猜测编造答案。让系统去下一笔订单、发一封邮件，仅凭生成文本本身也无法触及外部世界。一旦任务要求在生成文本之外采取行动，第一级就不够用了。

再往上一级是单智能体。在模型外面加上第 2 章讲过的智能体回路，配上工具和记忆，能够查询、写入和修改外部状态，都属于这一级。这一级要判断的问题很具体：任务确实需要采取行动，但一种专长加一套工具够不够用。顾客问“我的订单怎么还没发货”，它调用订单接口查看状态，调用物流接口查询轨迹，再把结果组织成回答，从头到尾只有一个智能体、一份上下文。

专长够不够，检验的方法是把任务需要的工具清单和操作规范写成一份文档，看一个新同事照着做能不能完成。文档写得清楚，单智能体多半也能胜任；文档写不清楚，不同环节要查阅不同领域的手册，专长这时才真正出现分化。

第二级也有自己的代价。回路每一步都可能出现分支，行为不再是完全确定的；工具需要定义和维护；上下文要按第 7 章的方法管理。对相当一部分业务系统来说，这一级已经是终点，第 2 章到第 8 章的所有工作，都是为了把这一级做扎实。

第三级是多智能体工作流。一群智能体按固定的流程分工，谁先执行、在哪里交接、结果交给谁，都提前写进了代码，这种做法叫预定义编排（defined orchestration）。它要处理的情况是解决方案的步骤清晰、能够固化成流程，但各个步骤需要的专长并不相同。财务分析流水线是现成的例子，市场数据、风险评估和组合优化三个环节各自负责一段，按固定顺序连接起来。

换成中文场景，店铺运营的周报系统同样属于这一级，先抓取各平台的销售数据，再做同环比分析，最后套用模板写成周报，三个步骤实际上包含两种专长。

费用到第三级明显上升。编排代码需要维护，智能体之间每传递一句话，都要花掉一批 token，每个环节的输入输出契约也都需要事先约定好。另外，到了第三级，并不是说每一步都必须由智能体完成，流程里的某些步骤写成普通代码完全可行，这一级的分界点在于控制权掌握在谁手里，答案是开发者。

环节一多，可靠性也随之下降，而且下降的方式接近乘法关系。整条链路连接起来后，成功率等于每个环节成功率的连乘；只要一个环节出错，后面的环节即使运行正确也没有意义。用数字算一下就能看清楚，假设单个环节成功率为 98%，十个环节连接起来只剩约 82%。在交接处增加一道校验，拦截违规输出并进行补救，这 2% 的失败中有九成能够挽回，真正遗漏的只有 0.2%。于是单个环节的有效成功率提升到 99.8%，十个环节再连接一次，又回到约 98%。

环节之间的这份输入输出约定，写进代码就是 3.1 讲的结构化输出。这为结构化输出补充了第二个理由，除了省去解析代码，它还能把失败拦截在环节边界上，避免错误的输出进入下游状态。

再往上就是第四级，自主多智能体，也叫 AI 驱动编排（AI-driven orchestration）。这一级把编排的决策权交给模型，运行时由谁接着执行、执行什么，由模型根据任务和中间结果实时决定。它要应付的是解决方案无法写成固定流程、只能通过探索和试错逐渐显现的情形。开发一款既能看行情、又能买股票、还能报税的手机应用就是这类工作，界面设计、客户端开发、接口集成和测试调试多种专长交织在一起，写一版、运行一次、根据结果决定下一步。航空公司的订票网站只提供网页界面、不提供 API，订票时该点哪个按钮、填哪个表单，同样要看了上一屏才能知道下一屏是什么。

还有三条更细的信号，可以用来确认是否真正到了第四级。每个智能体都能独立定义、独立改进，各自拥有不同的提示词和工具，可以单独调整和更新；彼此协作的关系需要随中间结果动态调整；性能需要通过反复试错、逐步积累提升。

第四级的费用也是四级中最高的，常见的有四类，结果难以预测、跨模型版本难以复现、出错概率更高，还有额外的成本与延迟。能力最强的一级，恰恰也是最难驾驭的一级。

多智能体值得学习的底层原因，有一个学术名称，叫涌现（emergence），说的是系统层面的行为不体现在任何单个组件上，而是由组件之间的交互产生的。城市的居住格局就是这样形成的。每位居民对邻居只有一点温和的偏好，不愿意自己所在的街区成为少数族群聚居地，谁也没打算住进一个按族群分区的城市，但各个家庭各自搬几次家之后，整座城市就分成了界线分明的街区。想通过拆开单个组件来研究、再拼出整体行为，这条路在涌现面前走不通；更麻烦的是，几种不同的微观过程能够产生同一种宏观格局，仅凭观察组件很难追溯原因。涌现是双向的，整体能做到个体做不到的事，这是多智能体的吸引力所在；没有人设计过的不良行为同样会在交互中产生，这是它的风险。编排与协作协议值得专门研究，涌现是理论依据之一；第 11 章的博弈论从利益冲突的角度给出另一条依据。

级别	回答的问题	控制权在哪	主要代价
直连模型	只靠生成文本能完成任务吗	无需控制流	一次调用，几乎为零
单智能体	一种专长加一套工具够用吗	模型按回路推进	回路分支、工具与上下文的维护
多智能体工作流	固定流程里需要多种专长吗	开发者写死流程	编排代码、智能体间传话的 token
自主多智能体	解法要靠探索才能涌现吗	模型在运行时决定	不可预测、难复现、出错面大、成本与延迟

这张表可以正着看，也可以反着看。正着看是能力视角，一级比一级强；反着看是成本视角，一级比一级贵。做工程决策时，用成本视角更稳妥，先问最低那一级为什么不行，成立之后，再考虑升到上一级。

四级其实可以浓缩成三个问题，从最简单的那一级开始，逐一提问。

先问第一个问题，任务仅凭生成文本能否完成？能完成，任务就停在第一级，选择到此结束；不能完成，说明任务需要采取行动，接着问下一个问题。

第二个问题针对解决方案本身，步骤是否清楚、能否写成固定流程？能写清楚，就进入专长这一层的分岔，不同步骤需要的专长不同，就用第三级；一种专长配一套工具就够了，回到第二级。

第三个问题针对解决方案写不成流程的情形。先看每一步具体怎么做，事先是否已经知道。做法都清楚，每一步只是简单的调用加验证，但任务各不相同，整条序列事先无法穷尽，因此写不成固定流程；这样的任务用第二级边执行边处理就够了。如果连下一步做什么都要边执行边探索、协作关系要随中间结果动态调整，才需要第四级。

举个竞品舆情周报的例子，团队要监控五个品牌在微博、贴吧上的讨论，归纳出负面焦点，最后输出一页简报。套用第一个问题，它需要在生成文本之外采取行动吗？需要，平台数据要靠抓取，第一级因此排除。

再套用第二个问题，解决方案能否固定成流程？能。抓取、清洗、归纳和成稿四个步骤顺序固定，候选答案在第二级和第三级之间。接着按专长划分，抓取和清洗是工程工作，写成普通代码更合适；归纳和成稿是语言工作，两次模型调用足以完成。整条流程再没有第二种非模型不可的专长，因此答案确定在第二级，外层包一段普通代码，里面放一个带检索工具的智能体。

同样的任务，很多团队常常做成三个智能体协作，采集员、分析师和撰稿人各自负责一个角色，运行起来效果不错，但费用会翻上好几倍。

这个例子还揭示了一个常见的误判。不少人一看到步骤多，就认为应该用多智能体，但那三个问题里根本没有步骤数这一项。单智能体按计划一步步执行完二十步，往往比三个智能体各自执行七步更稳定，原因在于上下文只有一份，状态不会在交接过程中丢失。

真正需要判断的变量只有三个，是否需要采取行动，专长是否会分化，路径能否写成流程。两个方案都能运行时，用这三个变量比较一下，就有了判断的依据。

与三问配套的还有一条原则，架构选择应该是最简单、但能满足任务要求的那一种。复杂度每提升一级，都意味着更多的开发时间和更多的潜在故障点，拿不准时从简单的方案开始，等理解加深之后再逐步演进。

从简单开始还有一层含义，多数团队容易忽略，我自己也忽略过，层级不是只能向上调整，也可以向下调整。随着实现的深入，对任务的理解也在变化，当初判断写不成流程的部分，实现后才发现几个分支就能覆盖，这时就应该撤销自主协作，退回工作流甚至单智能体。架构如果停在超出实际需要的层级上，付出的是持续的 token 和维护开销，远超最初一次性的开发成本。

单智能体与多智能体之间并没有一条整齐的界线。第 8 章的子智能体本身就存在于单智能体内部，工具也可以是另一个智能体；用户看到的是一个助手，背后可能运行着好几个专项角色。第四部分之所以仍按显式协作来讲述，是为了把设计原则讲透彻。因此这道阶梯真正的分界不在于进程数量，只看两点，控制权在谁手里，上下文分成几份。

9.2 最简可行架构原则

多数项目根本用不上多智能体系统，这条建议展开成两句话：先从最简单又能运行的架构开始，除非评测证明收益明确，否则不增加复杂度；单智能体还没做对就急着拆成一群，复杂度先涨上来，效果反而更差。两句话合起来就是最简可行架构原则。

违反这条原则的团队很常见。多智能体的演示看起来确实好看，几个角色来回对话，产出的质量肉眼可见地好；但代价在演示阶段基本看不出来，十次调用看不出 token 增长了多少倍，调试的成本在一个下午的演示里也不会显现。

违反这条原则的方式多种多样，业内也给这类做法起了名字。上帝智能体（god agent）指的是把所有工作都堆到一个智能体身上，指望它从人力资源一直管到物流的做法；随着领域复杂度上升，单个全能智能体多半无法应对，反而在最该做出正确决策的地方失误。另一种反模式叫本该只是一个工具的应用，明明一个简单的工具就能完成、让上层智能体调用一下就行，却偏要升级成一个完整的智能体，多出来的只有一层不确定性。

用户想要的结果，一张确定性的表单、一个 if 语句就能百分之百正确地给出来，这种情况下还要用模型走一遍，就叫为 AI 而 AI。这三个名字的根本问题相同，都是把复杂度加得过多。

组织层面还有一层因素。架构的决定权常常掌握在看过演示的人手里，费用却记在另一个团队名下，决策和代价因此天然错位。要抵消演示带来的误判，只能依靠数字。

这组数字来自一项公开的对比评测，出处见本章参考资料。实验用同一款模型 GPT-4.1-mini 构建四个配置，与阶梯上的四级一一对应，放到四类共 10 个任务上运行；打分由 LLM 裁判负责，从准确性、完整性、有用性和清晰度四个维度评价，满分 10 分。

配置	构成
直连模型	裸调用 GPT-4.1-mini，无包装、无工具、无编排
单智能体加工具	一个智能体，挂 Think、Calculator、DateTime、GoogleSearch、TaskStatus 五个工具
多智能体轮转	规划者、求解者、审查者三人组，固定顺序轮流发言，求解者带同样的工具
多智能体 AI 编排	同样三人组，模型按任务进展动态选下一个发言者，工具同上

整个实验设计中最关键的一点，是求解者挂载的工具与单智能体那套完全相同。因此分数差异只能归因于编排层，与能力差异无关，归因很清晰。四类任务的搭配也经过设计，简单推理 3 个，是数学应用题、逻辑谜题和阅读理解，不需要工具；工具重型 3 个，都是需要实时信息的调研题；规划 2 个，是多约束的行程与时间分配任务；核查 2 个，负责查证流言、发现论证漏洞。

第一批数字对多智能体不利。简单推理套件里，四个配置中分数最高的是直连模型，拿到 9.7 分；多智能体 AI 编排反而落到 9.3 分，是四个配置里最低的。分数的具体来源，留到第 12 章讲评测方法论时再说明，这里只把它当作测量结果看待。模型本身就是简单推理任务的合格基线，任务只要靠推理就能完成，就不应该过度设计。协调消息、过程展示和多次模型调用这些多智能体的开销，在这里没有换来任何收益，反而让分数下降了一点。

更明显的是费用差异。全场取平均，直连模型每个任务消耗 355 个 token，多智能体 AI 编排要 15,343 个，两者相差 43 倍。这个量级能找到文献旁证，四项独立研究测得，多智能体场景里单次请求的 token 总量在 6,000 到 25,000 之间。实测的 15,343 正好在这个区间内，两处数据互相印证。

评测还单独计算了效率指标，看每千 token 能换回多少分。计算方法是只统计运行成功的任务，用任务得分除以该任务消耗的 token（按各套件自身的平均值分别计算，不是全场平均的 355 与 15,343），再乘以一千。简单推理这类不需要工具的任务本身耗费的 token 就远低于全场平均，所以这一套件的效率值会明显偏高，直连模型的效率值是 54 分，三个智能体配置都掉到 2 到 4 分。核查套件里，直连模型是 32 分，智能体配置不到 8 分。规划与工具重型套件里，直连模型在 10 到 32 分之间，智能体配置不到 1 分。四个套件放在一起看，效率差距最小的也有好几倍，最大的超过一个数量级。

到了需要外部信息的那批任务，结论就不一样了。工具重型套件里，多智能体 AI 编排拿到 9.2 分，直连模型只有 6.8 分，差距明显拉开。这差距从哪里来？套件里有个播客调研任务，直连模型只拿到 3.2 分，因为它没有挂载搜索工具，实时信息要么凭空编造，要么如实承认不知道；三个带搜索工具的配置，在这个任务上则都拿到了 9.0 分。

数字放在一起看更清楚，起作用的其实是搜索工具，与智能体的数量无关，把同样的工具配置给单智能体，这个任务照样能解决。加不加工具、用不用多智能体，是两件互不相关的事。加工具在这批任务里带来的收益很大，用多智能体几乎没有额外收益，单智能体加工具的总体分是 9.2，多智能体 AI 编排是 9.3，两者基本持平。

至于夹在中间的规划和核查两类任务，四个配置的分数都在 8.6 到 9.6 分这个窄区间里，说明这两类任务对架构没有明显的偏好。

上面这些分数，是校准过裁判之后得到的结果。没有校准的第一轮，总体分完全是另一种情况，直连模型拿到 7.94 分，多智能体只有 6.82 分，直连模型明显领先。回头查看裁判写的评分理由，才发现问题出在裁判自己身上；重新校准后，多智能体的分数提升到了 9.30 分。直连模型校准后的总分，这组数据没有单独公布；它翻转前的分数在实验中有记录，就是第一轮的 7.94 分，校准后它究竟在 9.30 分的哪一边，需要重新运行这组评测才能知道。这场偏差是怎么发现、怎么修正的，12.3 讲裁判偏差校准时再展开说明。

这次偏差留下两条教训。第一条，LLM 裁判自身带有偏见，评测工具本身也需要作为调试对象；如果当时停在第一轮，这一节的结论会完全相反。第二条，单次实验的数字只能看趋势，不要当作普遍适用的常数。本书的统一口径也是这样，10 个任务、一个模型、一个裁判，样本并不大，换成 DeepSeek 或通义的模型、换一批任务分布，具体分数必然会变化。

有两条方向性的结论，除了这次实验之外，还有机理层面的支持。一条是，任务缺少实时信息时，收益来自工具接入，这与使用哪家模型无关；另一条是，编排层在纯推理任务上只增加成本、不提升能力，同样与模型无关。

多智能体强化学习的研究已经在这个领域进行了几十年，有三条结论与这一节的实验方向一致。各智能体互不干扰、各自学习的独立学习（independent learning），是该领域公认的最简基线，但这种完全不协调的做法，成绩常常能追平专门为协调设计的复杂算法，协调机制必须先超越这条基线才有意义，与这一节“单智能体加工具总分持平多智能体”是同一个道理。想把 n 个智能体合并成一个中央控制器统一决策，理论上也不被看好，每个智能体有 k 种动作，中央要面对的动作组合数就是 k 的 n 次方，智能体一多，最先变得无法计算的就是那张联合动作表，这也解释了“上帝智能体”为什么无法应对复杂场景。协调的难度还取决于利益结构，奖励此消彼长的零和博弈、共同得益的合作博弈，还有介于两者之间的一般和博弈，第 11 章的囚徒困境，就是一般和博弈中最著名的反面例子。这三条结论在工程上是同一句话，协调本身是要花成本的，值不值得花，要用证据说话。

操作上至少要做到三件事，完整记录执行轨迹和裁判理由；结果可疑时先查轨迹、再下结论；评测体系本身，也要作为调试对象来对待。

这组实验同样留有未解答的问题。单智能体配置的 token 用量没有单独公布，多智能体相对单智能体的倍数只能根据机理推测；任务集只有 10 个，模型也只有一款中档型号。因此引用时要注意口径，43 倍只是这一次实验的结果，是直连模型对多智能体 AI 编排的差距；换任务、换模型，倍数一定会变化，但量级和方向应该保持一致。

实验数字加上机理分析，多智能体的真实代价可以归纳为四项：token、延迟、调试和误差面。

第一项是 token。多智能体每协作一轮，就要重新计费一次，规划者阅读任务、编写计划，求解者阅读计划、开始执行，审查者再把前两人的产出完整阅读一遍才能发言，每个角色每发一次言，都要把共享上下文重新计算一次费用，43 倍的差距就是这样逐渐积累起来的。

用示意价格粗略计算一下就能看清楚，输入按每百万 token 一元计算，具体以官方定价页为准。多智能体 AI 编排单次任务 15,343 个 token，折合约 0.015 元，看起来只是很小的数目，但乘以一天十万次调用，一天的费用约 1,534 元。直连模型单次任务 355 个 token，同样的调用量一天约 36 元，只有前者的四十三分之一左右。两种方案放到一年，分别约 56 万元与约 1.3 万元。而且这还只是按输入价格计算，协调所使用的对话内容恰恰全是输出，实际倍数只会更大。

第二项是延迟。三个角色只能轮流发言，整个流程天然是串行的；每发一次言都算一次完整的模型调用，轮次一多，等待时间只能累加，中间还要加上交接处理，面向顾客的场景很难接受这种层层叠加的延迟。并行只对能够并行的子任务有效，讨论、审查这类协作本来就必须串行执行。对实时性敏感的系统来说，往往是延迟先出现问题，token 的费用还是后面的事。

第三项是调试。单智能体的 bug 只存在于一份执行轨迹里，三个智能体的 bug 则分散在三份交织的轨迹里，几十条消息、多次工具调用交织在一起，要定位原因就得先把整场对话复原出来。观测和日志从可选项变成了必需项，规划多智能体项目时，团队最容易忽略的就是这项基础建设成本。

第四项是误差面。多个具有自主性的智能体一起工作，出错的地方也会增多。机理可以分成两层：一层是错误顺着交接传播，上游智能体编造了一个事实，通过交接消息传给下游，下游把它当作可信输入，错误就这样在链条里传下去；另一层是审查失灵，多一个审查者相当于多一道校验，但审查者自己也是一次概率性的调用，可能放过错误的结论，也可能误判正确的结论。

看一场三智能体的协作，规划者分解任务时虚构了一个不存在的接口参数，求解者按照这个参数调用，失败了，把错误归因于网络波动；审查者复查时又重复了同一套错误假设。三份上下文各自独立，始终没有一个环节停下来核对接口文档。换成单智能体犯同样的错误，错误现场至少只有一份，定位速度会快得多。

跨版本的复现问题还要再加上一层。编排的决策对模型版本很敏感，换一代模型，谁发言、何时交接都会随之变化，回归测试的负担成倍增加。

除了以上这些代价，还有一种失效方式，问题出在角色之间的相互作用上。有位实践者搭建过一套治理层级，用于自主交易实验，战略由 CEO 智能体负责，风险分析由顾问智能体负责，实现由工程师智能体负责，策略智能体则按不同打法各自设立。早期这套结构确实有效，曾经拦截过一笔情绪化的追单操作；后来这套系统失效了，原因与代码无关。顾问智能体把训练数据里学到的风险管理方式照搬使用，变得过度厌恶风险，任何策略在它眼里都太危险；CEO 智能体从训练数据中学到的模式是管理层应该听从专家顾问的意见，于是它选择了顺从而不是否决；工程师智能体则一直闲置，没有策略轮得到它实现。精心设计的层级结构，最后产出的结果还不如一个只带最基本指令的单智能体。

问题的根源在于结构本身。每个智能体都会引用模型训练数据中的角色设定来解释自己的行为，而这些解释之间的相互作用，设计者预料不到。那位实践者最后采取的是彻底简化的做法，把四个专用智能体合并成一个，指令简化为一句话，“自主交易到收盘”。从这次失败中可以总结出三条教训。第一条，从单智能体开始，只在有证据表明不够用时才增加智能体。第二条，角色定义要写具体的行为，不要写抽象的性格，9.3 第一道关卡的人设检验防的正是这类问题。还有一条，随时准备简化回去，留在多智能体上，就要一直用效果证明这份复杂度值得。

拆分之后还有一个隐蔽的问题。医疗领域的一份实践综述提到过这样一个例子，把各个组件单独优化到相当高的准确率，整个系统的端到端表现反而落后于一套整合得当的设计。组件各自的分数只是局部指标，系统好坏取决于衔接处，上游交出的内容是否正好是下游需要的内容，比每个环节自身的漂亮数字更重要。所以“不要过度拆分”不只是为了节省 token：把组件拆开很容易，拆开之后要对齐却很难；每个组件都调整到最佳状态，组合起来也未必是整个系统的最佳状态。

本书在工程上采纳的建议是，从阶梯中尽量靠下的那一级开始，是否升级，交给证据来决定。

这四项代价都在成本一侧，收益一侧要换一种算法，按人的注意力计价。论实际耗时，智能体往往比人慢，一件工作让模型花三个小时才完成，熟练的人一个小时就能办完，按速度比较，多智能体多半占不到便宜。但两边的一小时价格不一样，模型的一小时按 token 折算成本，人的一小时按注意力折算成本，后者要贵得多。时间套利（把人的注意力从盯流程里换出来）指的就是这种换算，多花几十倍的 token，换回一段人的注意力，往往是划算的交易，把比较换到注意力这一侧，结论就反转了。还有两条趋势在同时推动这个方向，推理价格持续下降，人的时间成本持续上升，夹在中间、值得换算的任务一年比一年多。这一节的数字提醒的是换算这件事：token 花费本身说明不了盈亏，要看它替代了多少人的注意力。

不少团队想使用多智能体，背后真实的推动力是上下文装不下了，工具越挂越多，历史越拉越长，单一窗口早就装满。这个动机本身是合理的，但解决办法不一定要走编排这条路。第 7 章讲的隔离策略和第 8 章的子智能体，架构上正是多智能体的最简形态，只做隔离、不做协作，成本比完整编排低一档。隔离在前，编排在后，许多看起来非多智能体不可的系统，做到隔离这一步就足够了。

隔离能省多少钱，很容易算错，值得单独算一遍。第 1 章提过，模型 API 没有状态，每一轮都要把整份上下文原样重新发送、重新计费一次。因此一段体积不小的输出，只要留在主上下文里，之后每一轮都要为它付费。子智能体运行测试时输出一大段日志，日志进入主循环，主循环再运行五轮，这段日志就要跟着重复发送五遍。把这类工作交给子智能体之后，噪声输出留在它自己的上下文里，返回给主循环的只有一份摘要；主上下文变得干净了，模型留给正事的注意力也完整了。

但真正节省的费用，比表面看到的要少。有人用一组示意数字算过，只看每轮重复发送的 token，拆分出子智能体能节省百分之六点八；一旦把前缀缓存计算进去，节省的就只剩一两个百分点。这个口径要与第 7 章区分开，第 7 章对比的是窗口膨胀，不包含缓存折扣，这里算的是折扣后的费用。缓存只识别原样重复发送的前缀，谁改动了历史，谁的缓存就会失效。第 7 章的压实操作改动了历史消息，压实这条路径享受不到缓存优惠；反过来，不拆分的时候主循环整段历史原样重发，大部分能命中缓存、按折扣计费。拆分与不拆分，两边都有折扣兜底，名义上那点重复开销，缓存已经抵消了大部分。这样算下来，拆分子智能体真正的收益在于保护主上下文和注意力质量，不在于省钱。为了省钱而拆分的，多半会落空。

那什么样的工作值得拆分？判断标准同样有两条。第一条，输入量远大于输出量，一大段材料读进去、最后只得出几句话的结论，这类任务最适合交给子智能体。第二条，工作过程中会产生成段的中间产物，测试日志、检索原文都属于这一类，这类内容放在主循环里就要每轮都带着；拆分出去之后，中间产物留在子智能体的上下文里，主循环只接收结论。两条都满足时，隔离才真正划算；输入不大、中间产物也少的，拆分出去只是多付一次交接的 token，不划算。

这两条说明该拆什么，还有一条反过来说明不该拆什么。动手之前，先把候选节点的工具清单列出来，新节点的清单如果与某个已有节点重合超过八成，它多半不是新角色，而是同一个角色的提示词变体，合并回去、在输入端更换提示词就够了；工具清单差异明显的，才值得拆成两个节点。拿工具清单作判断，比“感觉是两种专长”可靠，专长不同，终归要体现在调用的工具不同上。

9.3 任务复杂度评估

什么样的任务才真正配得上更高的层级，判断依据是四个任务特征：可拆解、专长多样、上下文庞大、解法靠适应涌现。拆解看的是任务能否分解成若干通向目标的步骤，而且每一步都有明确的完成状态。专长多样看的是这些步骤是否分属不同领域，各自需要不同的知识、工具和指令。上下文庞大看的是单个步骤要处理的信息量是否很大，全部放进一份上下文会互相干扰。解法靠适应涌现指的是，不动手尝试就不知道下一步是什么，环境本身还在变化。

把这四个特征套用到真实任务上，财务报告四条都符合，数据收集、分析和成稿分成几个步骤，对应可拆解；分析师、统计、写作各有分工，对应专长多样；市场数据与行业标准的数据量，对应上下文庞大；新数据源和市场一旦变动就要重新处理，对应解法靠适应涌现。演示文稿设计也一样，内容审阅、版式、交互各是一类专长。

四个特征单独拿出任何一个，都只是在提高任务复杂度。真正让多智能体划算的，是一个任务同时符合多个特征，叠加在一起才够格进入候选范围。

进入候选范围之后，也还不能直接使用多智能体。工程上还有三道关卡要逐一通过，任何一道过不去，就退回低一级。三道关卡按先便宜后昂贵排：前两道查资料就能确认，第三道要动手写伪代码。这套关卡是本书归纳出来的，依据就是前两节的内容。

第一道关卡检查专长多样是否名副其实。方法虽然简单但可靠，把每个设想角色的工具清单和系统提示逐条列出，放在一起比较。工具集不同、指令集不同、调用的数据源也不同，专长才算数。三个角色共用同一套工具，指令的差别只是“资深规划师”“细心审查员”这类人设，那属于角色扮演，不是分工，增加的只是成倍的调用成本。

有一个教学演示正好属于这一类，诗人智能体写俳句，评论家智能体挑毛病，两个角色都不带工具，靠轮流发言把输出打磨出来。把它当作分工来看，就是上一段讲的角色扮演，第一道关卡通不过；把它当作提升产出质量的手段，让多个智能体各自处理同一任务、再互相核对打磨，性质就变了，走的是同一任务的多视角路线，不属于分工。这条路线有研究支持，多个智能体多轮辩论能够改进推理与事实性，分角色的多智能体也能提升产出的多样性和质量。

这些收益来自特定任务上的测量，代价同样是成倍的调用，动手之前先把成本算清楚。

第二道关卡检查上下文是否真的装不下。升级的动机中最常见的一种，就是窗口被塞满，工具描述几十个、历史消息几万字、单次搜索结果几万 token，全部堆在一起。这个动机本身没有错，但首先是一个上下文工程问题。第 7 章的压实、写入和检索应该先尝试，第 8 章的子智能体紧随其后，隔离本来就是多智能体中最便宜的一种方式。

真正到了需要为编排付费的那一步，判断标准可以归结为一条，各步骤需要读取的材料彼此独立、体量都很大，硬放进同一份窗口会互相干扰。以一次售后纠纷为例，调解这一步需要通读完整的聊天记录，查物流这一步需要读取承运商的完整接口数据，两类材料硬凑进一份上下文，除了互相干扰没有别的效果。

第三道关卡检查路径是否真的写不成流程。判断方法就是坐下来写伪代码。几个 if-else 分支加几次模型调用，能覆盖八成情况的话，这个任务最多到第三级工作流，甚至可能更低。写着写着发现下一步总是取决于上一步的结果，分支树越铺越开、无法收拢，才够格考虑第四级。业务流程中的主流部分，退换货、报销审批和开户核验这些，步骤都很清楚，是固定流程的样子，不像自主探索。

闸	怎么检	过不去时
专长多样	逐角色对比工具清单与系统提示	人设不同的同一种专长，退回单智能体
上下文压力	先走压实、写入与子智能体隔离	隔离够用就不编排
路径可写性	写伪代码，看能否覆盖八成情况	覆盖得了就用工作流，控制权留在开发者手里

三道关卡决定是否应该升级，真正升级之后角色怎么划分，是另一套动手实践，名叫白板梳理，方法借鉴自组织设计的做法。做法是先把想交给智能体的工作全部写到白板上，一边写一边追问是否还有遗漏；接着把相近的能力合并起来，合并的依据有三条，是否从同一个数据源获取数据、能否归入同一个岗位名称、能否通过一次 API 调用一起获取；然后寻找天然的分割线，负责的部门不同、任务类型不同、所属业务环节不同，各算一条；最后把线内的能力聚合成智能体，让每个智能体带一套聚焦的工具，整份清单按优先级排列好。

几十个团队都实践过这套方法，白板有实体的，也有虚拟的。进场的那一刻，大家手里只有一张看不出结构的愿望清单；离场时，那张清单已经变成排序清楚、每个智能体配好一套工具的方案。

拆分出来的粒度应该多细、一群智能体应该有多少个，研究方面最近也开始给出说法，只是都还没有形成共识。一篇立场论文提出，现在的拆分方式完全依靠直觉，照人类团队的样子分配角色，没有人计算过哪种拆法在规模扩大之后会最先出问题；它提议把一次模型调用当作原子成本，用算法分析中的渐进分析方法，比较不同拆法的开销走势。另一篇在大规模协作网络上做了实验，报告说整体表现随智能体数量增加，呈现先快后慢、最终趋于平缓的趋势，不规则的拓扑结构比规则的拓扑表现更好。这两条结论都要按各自的立场理解，前一条在提议一套研究议程，后一条的结论来自特定的网络结构与任务。方向倒是与本章一致，粒度和规模是可以计算的问题，不应该完全交给直觉决定。

下面用一家电商店铺的客服系统举例，从最初级逐级走到多智能体的边界附近，看看每一级的边界在哪里、由什么触发。

起点是直连模型。这家店铺销售羽绒服，售前咨询占了大部分，顾客常问零下十度能不能穿、跟另一款比哪件更保暖这类问题。把商品知识和退换规则写进系统提示，直接调用模型就能应付。一天几千次调用，成本可以忽略不计，这一级没有理由继续升级。

第一道界线出现在答案需要从业务系统中获取时。顾客开始提出“我的订单怎么还没发货”“上周退的款到账了没有”这类问题，答案不在模型参数里，需要去订单系统、支付系统中查找。这时候应该增加工具，查订单、查物流和查退款状态，升级到第二级单智能体。绝大多数客服需求到这里就结束了，客服系统也应该停在第二级。

第二道界线是流程变长。退换货一旦进入处理，就要验证订单、核对资格（七天无理由还是定制商品）、创建售后单、通知仓储、跟踪返件物流，五个步骤顺序固定，每一步需要的数据还来自不同的来源，订单接口、售后规则和仓储系统。把流程写成伪代码就是下面这样，五个步骤全部体现在分支和函数调用里，模型调用只出现在需要语言判断的节点，比如生成拒绝理由。

# 伪代码，只示意覆盖度检查，不可直接运行
def 售后处理(订单):
    if 订单.状态 != "已签收":
        return 转人工("未签收不受理")
    if not 售后规则.可退(订单):        # 七天无理由、定制商品等分支
        return 拒绝并说明(订单)        # 这里接一次模型调用生成理由
    售后单 = 创建售后单(订单)
    通知仓储(售后单)
    return 跟踪返件(售后单)

一个任务能写出这样的伪代码，就应该停在第三级，而且第一版不应该拆成五个智能体。应该先用确定性代码写出流程，每个节点配一次模型调用，再加上必要的工具。只有某个节点真的需要独立的大上下文，比如与顾客多轮沟通的纠纷调解，才值得把这个节点单独升级成智能体。第三级的要点，是控制权掌握在开发者手里，智能体数量能少就少。

真正的界线出现在第三道关口。大促当晚，进来一条投诉，用户说物流显示签收了，但他没收到。背后可能是快递异常、仓库漏发、订单状态同步延迟和地址填错中的任何一种情况，四类原因对应四路数据需要查询，而查完一路才知道下一路该查什么。

优惠券叠加引发的投诉是另一种情况，需要把活动规则、订单明细和用户的历史优惠记录同时读取，才能判断这一单是否需要补差价。

这两个例子距离第四个特征还差一步。要查哪几路数据，开始工作前能够列出清单，边执行边确定的只是先后顺序。到这一层，任务已经同时符合四个特征中的三个，步骤确实可以拆分，专长确实不同（物流调查、规则核对和纠纷调解各自需要不同的工具与指令），上下文的量确实很大（整场纠纷的聊天记录，加上四路接口返回的数据）。

即使升级，最外层也只是一个调查工作流，里面放一到两个专项调查智能体，而不是放一群智能体自主协作。真正达到第四级的场景，是连调查路径本身都无法事先确定的少数情况，而且上线之前需要先建立任务集，否则 9.2 那组数字就是教训，多花的 token 换不回相应的分数。

超过这道界线之后，正面的例子也不少。欧洲电动车市场的趋势分析就是典型案例，监管政策、消费者情绪和竞争格局三条线并行推进，研究、数据分析、政策跟踪和综合成稿四种角色各自阅读各自的材料、撰写各自的产出。这类跨领域的调研，最充分地体现了专长多样和上下文庞大这两个特征，是真正配得上多智能体的任务。

拿客服案例中的这几道界线一一对照，会发现升级从来不是因为多智能体更高明，而是因为出现了某个具体的功能缺口，答案存在业务系统里，流程跨越多个系统，调查路径又写不成代码。每缺一处，架构就提升一级；每一级都有前一级无法提供的能力，也都有自己的一份账单。

想要运行得更快，也是常见的升级动机之一，把任务拆成几份，交给几个智能体并行处理。并行确实能缩短总耗时，但首先要看时间究竟消耗在哪里。多数智能体任务的时间主要花在等待模型返回；拆成三路并行，token 三路都要付费，协调与汇总又要额外增加一层。瓶颈如果在某一次很慢的工具调用上，并行对它无能为力。要提速，先做工程优化，用日志找出瓶颈所在，再考虑要不要动架构换速度。

三道关卡全部通过之后，仍然缺少一个前提条件，任务集需要预先建立，让升级带来的变化既能测量出来，也能拿来比较。这正是评测驱动开发直接得出的结论（第 12 章正面阐述这套方法论），升级如果没有度量，就跟盲目花钱没有区别。

客服案例中，任务集取自过去三个月工单的抽样，每一条都附有人工核对过的预期结果。升级前后各运行一轮，用解决率、平均轮次和单次 token 三个数字进行比较，变化才能真正测量出来。走到这一步还没有被任何一道关卡拦下的任务，才值得投入多智能体；投入的时候怎么入手，又回到 9.2 那条原则，从最简单的编排开始，让评测数据决定是否要继续升级。

有一种结局需要提前理解，三道关卡走完，任务仍然留在第二级。评估工作并没有白做，它恰恰在节省将来的一笔冤枉钱。节省的是更高层级的花费和运维开销，换来的是一份能够说清楚为什么不升级的决策记录。架构评审中，持反对意见的人往往比谁都需要这份记录。

本章小结

• 立场：多智能体值得学习，第一步是学会不使用它；从阶梯中尽量靠下的一级开始，是否升级交给证据决定。
• 9.1 四级阶梯：直连模型、单智能体、多智能体工作流、自主多智能体，配三个逐级追问的问题（能否仅凭生成文本完成、步骤能否写成固定流程、下一步是否要边执行边探索）。分级真正的判断依据是控制权在谁手里、上下文分成几份；层级可以下调，停在超出实际需要的层级上，持续的 token 和维护开销远超一次性开发成本。
• 9.2 最简可行架构原则：先从最简单又能运行的架构开始，评测证明收益明确才增加复杂度；设计得当的单智能体常胜过设计糟糕的多智能体。实测口径（GPT-4.1-mini、四配置、四类共 10 个任务）：纯推理任务直连模型 9.7 分高于多智能体的 9.3 分，全场平均 token 355 对 15,343，差 43 倍；需要实时信息的任务里收益属于工具不属于编排，播客调研任务带搜索工具的三个配置都拿到 9.0 分。四项代价逐级变贵：token、延迟、调试和误差面；裁判要校准，单次实验只看趋势不当常数。
• 时间套利：token 花费说明不了盈亏，要换算成替代了多少人的注意力；推理价格在降、人的时间成本在升，值得换算的任务一年比一年多。
• 隔离的省钱空间：只看每轮重复发送的 token，拆分子智能体省约 6.8%，计入前缀缓存后只剩一到两个百分点；真实收益是保护主上下文和注意力质量。值得拆的两条判据：输入量远大于输出量、过程产生成段中间产物；候选节点工具清单与已有节点重合超过八成的不拆。
• 9.3 任务复杂度评估：四个特征（可拆解、专长多样、上下文庞大、解法靠适应涌现）同时符合多个才进候选；三道关卡（专长是否名副其实、上下文是否真装不下、路径是否真写不成流程）任何一道过不去就退回低一级；升级前先建任务集，用解决率、平均轮次和单次 token 对比前后。

参考资料

• Victor Dibia《Designing Multi-Agent Systems》（2025，Manning）第 1 章（四级架构谱系与三问决策框架、复杂任务四特征及任务映射表、Y Combinator 创业公司数据、单多智能体边界）、第 10 章第 10.6 节（四配置乘四任务套件的对比评测、裁判校准过程、token 与效率数字、评测驱动开发）、第 11 章第 11.3.11 节（“你大概不需要多智能体系统”核对清单、最简架构原则、多领域调研正例）、第 14 章（Y Combinator 数据的完整分析）。见 txt-ref-zh/designing-multi-agent-systems/。
• 《AI Agents: The Definitive Guide》第 5 章（串行链可靠率连乘与校验门补救账：单环节 98% 十连跳约 82%，九成校验门回到约 98%）。见 txt-ref-zh/ai-agents-definitive-guide/。
• 阿里云百炼模型定价页（qwen-plus 输入输出价格，北京区起步档，2026-08-28 复核与正文算例一致），https://help.aliyun.com/zh/model-studio/model-pricing ，截至 2026-08，以官方页为准。
• Du 等 2023、Liang 等 2023 的多智能体研究结论系该书第 1 章转引，未核对论文原文。
• 《Claude Code: The Definitive Guide to Agentic Development》（2026，独立出版）第 4 章（治理三幕实录：顾问智能体援引训练数据变过度风险厌恶、CEO 智能体顺从、工程师闲置的结构性瘫痪，四智能体收成一个，三条缓解），见 txt-ref-zh/claude-code-definitive/。
• 《Building AI Agent Platforms》（Ben O'Mahony、Fabian Nonnenmacher，2027 Early Release，O'Reilly）第 1 章（生命周期反模式命名：上帝智能体、本该只是一个工具的应用、为 AI 而 AI），见 txt-ref-zh/building-agent-platforms/。
• 《Patterns for Building AI Agents》（Sam Bhagwat、Michelle Gienow，O'Reilly 2025）模式 1 白板梳理智能体能力（愿望清单全量列出、按数据源/岗位/API 调用归组、找分割线、聚合为智能体，几十个团队的实践），见 txt-ref-zh/patterns-for-building-ai-agents/。
• Julian Soh《Building and Distributing Agentic AI》（2026，Apress）第 2 章（多智能体用例场景 token 消耗表：四项独立研究的单次请求总量区间 6k–25k），见 txt-ref-zh/building-distributing-agentic-ai/。
• 《The Claude Code Operating Model》第 4 章（无状态 API 的 token 算术：大体量输出驻留主上下文会每轮重复计费；拆子智能体账面省 6.8%、计入提示缓存后剩 1–2% 的示意算例，核心收益是上下文保护与注意力质量；启用判据为输入远大于输出、产出会被主循环反复携带），见 txt/claude-code-operating-model.txt（英文原文，第 4 章，行 4122-5383）。
• 《Designing Multi-Agent Systems》第 1 章另有两处口径：时间套利（按人类注意力计价的收益侧论证，推理成本下行与人力时间上行的趋势）；该书第 1 章概述自家评测时称直连模型的 token 效率比多智能体高 24 倍，第 10 章实测为 token 用量 355 对 15,343、约 43 倍，正文 9.2 引用的是后者。见 txt-ref-zh/designing-multi-agent-systems/。
• 《Becoming an Agent-Based Modeller》（Jennifer Badham、Corinna Elsenbroich，Routledge 2026）第 1 章（涌现作为系统行为的解释框架：系统行为由组件交互生成、拆开组件研究拼不出整体、不同微观过程可长出相同宏观格局；谢林隔离模型例证），见 txt/agent-based-modeller.txt（英文原文）。
• 《Multi-Agent Reinforcement Learning》（Stefano V. Albrecht、Filippos Christianos 等，MIT Press 2024）第 3 章（零和、共同奖励、一般和的博弈分类）、第 5 章（独立学习充当重要基线、常与最先进算法相当，引 Papoudakis 等 2021 的比较研究），见 txt-ref-zh/multi-agent-rl/。
• 《Agentic AI for Healthcare》（Sairohith Thummarakoti 编，Routledge 2026）第 9 章（“优化悖论”观察：逐组件优化到高准确率的智能体，端到端表现反不如整合式工作流；该书系转述 Bedi 等 2025 研究，未核对论文原文）、《Agentic GraphRAG》（Anthony Alcaraz，O'Reilly 2026 中译）第 2 章（节点拆分的工具面判据：工具清单重合超过八成即合并、在输入端变换提示词），见 txt/agentic-ai-healthcare.txt（英文原文）与 txt-ref-zh/agentic-graphrag/。
• 《The Agentic Enterprise》（Babak Hodjat、Antoine Blondeau，O'Reilly 2026 Early Release）前言（尺度规律两篇论文的转引）：Meyerson 与 Qiu 2025 立场论文 Position: Scaling LLM Agents Requires Asymptotic Analysis with LLM Primitives（ICML 2025，把模型前向当原子成本、以渐进分析比较智能体拆分效率）、Qian 等 2025 论文 Scaling Large-Language-Model-based Multi-Agent Collaboration（ICLR 2025，协作网络整体表现随智能体数量呈逻辑斯蒂增长、不规则拓扑优于规则拓扑、支持千级规模协作）；两文篇目经 arXiv 摘要复核（2026-09）。见 txt/agentic-enterprise.txt（英文原文）。