多智能体并非越多越好：Brooks定律下的AI Agent效率陷阱

前阵子我在做一个自动化分析工具，一开始脑热，把整个流程拆成了六个AI智能体：一个负责读数据，一个负责总结，一个负责提建议，一个负责审查，还有一个负责编排，最后还配了个"兜底"角色。结果验收那天我发现自己不是在用AI写系统，而是在给一群"远程实习生"开会——光是让他们对齐格式就花了三轮对话，中间有个智能体把上游结论理解偏了，后面所有环节都跟着跑偏。

那次之后我突然想起软件工程里那条老规律：向一个已经延误的项目里加人，只会让它更延误，后来被总结成了Brooks定律。我越想越觉得，这条定律在AI智能体（AI Agent）身上几乎是完美复现，而且坑得更深。很多人以为把任务拆给多个智能体就等于"并行加速"，但实际跑下来往往是token翻倍、错误级联、调试成本爆炸。这篇文章我就用自己的实测和拆解，聊聊为什么多智能体系统最容易踩"人月陷阱"，以及到底该怎么控制智能体数量。

1. 先说结论：多智能体系统是最容易踩"人月陷阱"的工程

先说个反直觉的结论：在某些任务上，一个智能体加上几个好用的工具，能打赢三个甚至五个智能体的流水线。不是智能体越多越快，也不是拆得越细越聪明，很多时候多个智能体协作的产出质量，反而不如一个智能体从头干到尾。

Brooks定律的核心思想，翻译成人话就是：项目延误了，你往里加人手，新来的人要先理解现状、要跟老成员沟通、要等前面的活干完才能动手，这些开销加起来，可能比新加的人力能贡献的产能还要大，结果项目反而更慢。软件工程里很多管理者都吃过这个亏，而到了AI智能体领域，这个坑几乎原封不动地存在，甚至因为大模型的特性被放大了。

你可以把每个智能体想象成一个精力有限、记忆有限的"新员工"。多智能体系统就是一个临时拼起来的虚拟团队。团队协作里那些沟通成本、交接损耗、重复劳动，在虚拟团队里一样都不会少，只是表现形式变成了token消耗、上下文漂移、自然语言接口的模糊误解。更麻烦的是，真实团队里的成员好歹共享一套企业文化、一套文档规范，而智能体之间往往连"任务完成"的定义都对齐不了，全靠提示词里那几句软绵绵的约束。

这篇文章适合正在搭智能体系统、纠结"要不要拆多个智能体"的人，也适合那些被多智能体框架的宣传打动、准备把所有任务都"agent化"的技术负责人。我会先用软件工程的视角把Brooks定律讲透，再逐个拆解它在AI智能体场景下的具体表现，然后给出一套可以复现的对照实验和判断标准，最后是我自己在项目里验证过的一些控制智能体数量的实战手段。

2. Brooks定律在软件工程里到底在说什么

2.1 定律的原始表述与三个底层原因

Brooks定律说的是：向一个已经延误的软件项目添加人力，只会让它更延误。这句话看着简单，背后是三个非常扎实的底层原因。

第一，沟通路径是爆炸式增长的。一个团队有N个人，两两之间需要沟通的路径就是N×(N-1)/2条。5个人的团队是10条沟通路径，10个人的团队直接跳到45条。人越多，花在"对齐信息"上的时间就越多，真正写代码的时间反而被压缩了。

第二，新成员的上手成本不是线性的。新来的人不能立刻写代码，他需要先读文档、理解架构、搞清楚代码风格和约定，这些成本需要老成员花时间去带。如果一个项目已经临近交付，老成员的时间本来就紧张，还要抽出宝贵的精力去做"传帮带"，那整体产能不升反降。

第三，很多任务是串行的，根本没法通过加人来加速。比如A模块不改完，B模块就没法动，因为B依赖A的接口。这时候你给B配三个人，也只是三个人一起等A。软件工程把这叫"关键路径"，它决定了项目最短工期，而加人通常改变不了关键路径的长度。

2.2 "三个厨师一道汤"：为什么任务不是拆得越碎越快

我特别爱用一个生活类比来解释这个现象：一个人做饭，洗菜、切菜、炒菜、装盘，一个人从头到尾做下来，脑子里的上下文是连续的，手头的锅碗瓢盆也是自己熟悉的，一顿饭半小时搞定。这时候你为了"提速"，给他配了三个厨师，一个洗菜、一个切菜、一个炒菜。听起来很合理，但实际会怎样？洗菜的不知道切菜的今天要切什么形状，切菜的不知道炒菜的锅现在温度多高，三个人还要就"洋葱到底切丝还是切丁"开个三分钟小会。如果其中一个人理解错了，整道菜都受影响。最后你会发现，除非这是一场需要同时出几十道菜的大型宴席，否则三个人做一道菜往往比一个人做一道菜更慢、更容易出错。

Brooks定律的本质就在这里：分工带来的收益，只有在任务量足够大、子任务真正可并行的时候才能体现出来。如果任务本身很小，或者子任务之间高度串行，那分工就只剩成本，没有收益。很多人其实没意识到，"拆解"这件事本身是有成本的，而这个成本恰恰不是我们在纸面上画架构图时能看到的部分。

2.3 从软件团队到AI智能体：同一套团队动力学

当我开始把智能体当"虚拟员工"看之后，发现软件团队里那些经典问题，在智能体系统里几乎一一对应。

真实团队里的沟通路径爆炸，对应的是智能体之间传递消息的token开销；真实团队里的新人上手成本，对应的是每个智能体需要把任务背景、历史上下文从头加载一遍；真实团队里的串行依赖，对应的是下游智能体必须等上游输出才能开工。更进一步，真实团队里的"误解"虽然常见，但人可以通过语音语调、肢体语言、公司政治，甚至看对方的表情来消解歧义；而智能体之间的交接完全依赖自然语言，自然语言天然就有模糊性。一旦误解发生，就会沿着链条往下传，直到最后一个人基于错误的信息做出决策。

换句话说，多智能体系统本质上是在软件工程的问题域里，重新复刻了一遍"团队管理"的所有困难，只不过参与者从人变成了模型。这也是为什么我觉得，任何打算上多智能体架构的人，都应该先认真读一读软件工程里关于团队协作和项目管理的那些老经验，而不是直接去看某个新框架的示例代码。

3. AI智能体场景下，Brooks定律以四种方式精准复现

3.1 token带宽：N个智能体的通信开销是乘积不是加法

先说最物理的层面：token。智能体之间传递信息，本质上是把文本从一个模型的上下文搬到另一个模型的上下文。这个过程不产生"价值"，只产生"开销"，但很多人在设计多智能体系统时，完全没有把token当成一等公民来考虑。

这里有个粗糙但是直观的估算：假设你有5个智能体，采用链式流水线，每个智能体完成自己的阶段后，把结果传给下一个。第1个智能体的产出约2000 token，第2个要读这2000 token再产出自己的2000 token，第3个要读前两个的共4000 token，依此类推。整个流水线跑一次，总通信消耗大约是2000×(0+1+2+3+4)=20000 token。如果把智能体翻倍到10个，总通信消耗就变成2000×(0+1+2+3+…+9)=90000 token。智能体数量只翻了一倍，通信开销却涨了4.5倍。这在数学上非常接近团队沟通路径N×(N-1)/2的增长方式——不是线性，是平方级。

而且这还只是理想情况。实际跑起来，智能体之间经常需要来回确认、修改、二次传递，一旦出现"上游没说明白、下游理解错了"的情况，整个链条可能往回重跑。我在下面的实验结果里会给出真实的token数据，那个差距会比理论估算更夸张。

3.2 自然语言接口契约：智能体之间的"语义传真"损耗

软件工程里，模块和模块之间靠接口通信，接口有明确的类型定义、参数约束、返回值约定。但智能体和智能体之间，绝大多数情况下靠的是自然语言消息——这相当于让两个程序用散文对话。一篇散文的信息密度、歧义程度、风格差异，都会直接影响下游理解的准确性。

我把这个叫"语义传真损耗"：上游智能体以为自己讲清楚了，下游智能体以为自己听懂了，实际上中间的语义已经变形了。典型的表现有几种：上游输出的"已完成"在下游看来其实是"还没验证过"；上游用"问题严重"表达优先级最高，下游理解成"需要更多分析"；同一个术语在两个智能体的知识体系里指代不同的东西。人对这种事情有纠错能力，因为人知道自己可能会误解，会主动追问；但智能体很少主动追问，它只会在给定的上下文里"猜"，猜错了就直接往下执行。

所以在多智能体系统里，消息的模糊度就是错误的种子。每多一层传递，就多一层误解的机会。这跟传真机传文件一样，传一次可能还清楚，传个三五次之后，字迹基本没法看了。

3.3 编排者成为新的单点瓶颈与错误级联

多智能体系统通常有一个编排者（或叫规划者、协调者），负责把任务拆给各个执行智能体，再汇总结果。听起来很合理，但这个编排者恰恰是整个系统里上下文负担最重、最容易出错的地方。

为什么？因为编排者要"看过所有内容"。每个执行智能体的输入、输出，它都要读一遍才能决策下一步。任务越复杂、执行智能体越多，编排者需要装进上下文窗口的东西就越多。大模型的上下文窗口是有限资源，内容一多，注意力就会被稀释，编排者开始遗漏细节、做出错误的调度判断。它就像一个永远在开会的经理，被各路汇报淹没，最后做出的决策质量反而更低。

更危险的是错误级联：一旦编排者把某个子任务判断错了，或者把某个执行者的错误输出当成正确结果继续往下传，后面所有智能体都会基于这个错误继续工作。这种级联错误在多智能体系统里特别难查，因为你根本不知道是哪个环节开始歪的。调试的时候，你要把这几个智能体的完整对话全部翻出来，人工比对中间结论，成本极高。

3.4 调试矩阵爆炸：每多一个角色，组合验证量翻几倍

最后是调试成本。一个智能体的系统，你要测的就是"输入→输出"这一条线。两个智能体的系统，除了测各自的功能，你还要测两者之间的交互：A的输出B能不能正确理解？A的错误格式B能不能识别出来？A和B对一个中间术语的定义是否一致？这些交互场景加起来，需要验证的路径数量迅速膨胀。三个智能体之间有三条双向交互线加一条三方协同线，四个就是六条双向线加更多组合，这是标准的组合爆炸。

我在实际项目里最深的感受是：每多一个智能体，你的调试矩阵就多一整个维度。你以为你在用智能体解决问题，实际上你在维护一套比单体程序更难调试的分布式系统，而且这个系统的每个节点还都不是确定性的——同一个输入，同一个模型，两次跑出来的结果可能不一样。这种不确定性叠加在组合爆炸的交互上，让多智能体系统的行为变得极其难以预测。

为了让你更直观地看明白这一条，我把软件项目团队和多智能体系统做个对照：

这张表基本就是我后来判断"要不要拆多智能体"的依据清单，大家在设计系统的时候可以直接拿来对照。

4. 一个可以复现的对照实验：1个智能体 vs 3个智能体流水线

4.1 实验任务与两条路线设计

光讲原理有点空，我做一个简单但可复现的实验。任务我故意选了一个日常工作里很典型的需求：把16条散乱的产品反馈笔记，整理成一份带优先级排序的改进建议清单，并给出可执行的下周计划。这类任务不涉及复杂代码，但需要理解、归纳、取舍和结构化输出，非常适合用来观察智能体的协作行为。

实验分两条路线，使用同一个底层大语言模型，保证变量只有"架构方式"这一个维度：

路线A，单智能体直接完成：一个智能体接收全部笔记，自主完成整理、排序、制定计划的全过程，最终输出一份清单。

路线B，三智能体流水线：第一个智能体负责阅读全部笔记并提炼关键问题，第二个智能体负责在此基础上做优先级排序和分类，第三个智能体负责把前两步的结果改写成正式的下周计划。

每一条路线都跑了5次，取中位数对比，评测维度是：总输入输出token数、完成时的对话轮次、结果质量人工打分（1到5分）、输出格式一致性。

4.2 评测维度与结果

结果出来的时候，我周围几个同样在做智能体的朋友都有点意外：

三智能体流水线的token消耗差不多是单智能体的三倍，物理时间也明显更长，但最终质量不但没有提升，反而略低。有一次甚至出现了第二个智能体把第一个智能体已经做对的信息搞乱了，第三个智能体基于错乱的信息做计划，最后还得从头修正。

4.3 复盘：这轮里Brooks定律是怎么生效的

我复盘了一下这个结果，发现Brooks定律里的三条底层原因，在智能体流水线里全部应验了。

第一，沟通路径爆炸。三智能体流水线虽然只有两个交接点，但每个交接点都要把完整的中间结果重新写一遍。第二个智能体读到的是第一个智能体"转述"后的信息，而不是原始笔记，这里的信息密度已经下降了。第三个智能体要同时参考前两个智能体的输出风格和内容，token占用加倍。

第二，串行依赖。这个任务本质上是高度串行的：必须先理解所有笔记，才能排列优先级；必须先有优先级，才能制定下周计划。三个智能体之间没有任何一个环节是可以并行的，那拆成三个人的意义就不存在，纯纯只是增加了交接成本。

第三，质量门禁的幻觉。我在路线B里本来期待"多一个智能体多一道审查"能提升质量，但现实是审查者本身也是模型，它依然会犯错。你不能指望用另一个大模型来稳定地纠正前一个大模型的错误，这本质上是两个不确定性叠加。后来我学到一个词：确定性校验才是质量门禁，模型审查只是"参考意见"。

4.4 反转：当任务复杂度上升，拆分才开始有意义

不过我同时做了另一个对照，当任务里加入一个真正可并行的环节之后，结论立刻反转。我把任务改成：除了整理反馈笔记，还要同时从三份外部文档里分别提取数据，再汇总成报告。这时候，三个"提取员"智能体可以真正并行跑，互不等待，各自输出一份局部结果，最后用一个汇总智能体合并。

这个场景下，三智能体的token消耗虽然还是比单智能体高（因为通信存在），但物理时间明显缩短，因为三个提取任务同时启动，单智能体只能串行地一份一份读。这说明Brooks定律不是否定分工，而是警告你：分工只有在真正可并行、且并行收益大于通信成本的时候才成立。判断一个任务能不能拆，关键不是"看起来能不能分成几步"，而是"分成后的每一步是不是真的可以同时进行、互不依赖"。

5. 什么时候该拆，什么时候打死也别拆——决策清单

5.1 值得拆的三种信号

我在自己的实践里总结出三个相对靠谱的"可拆信号"。

第一，子任务之间确实可并行，并且彼此的输入输出没有强依赖。比如上面那个同时从多份文档提取信息的场景，每个提取任务独立完成，最后汇总即可。这种拆分能让物理耗时显著下降，通信成本换并行收益是划算的。

第二，任务涉及差异很大的专业领域，并且每个领域需要不同的提示词策略、不同的工具链。比如一个项目里既要做自然语言总结，又要跑数据分析，还要生成可视化图表，让一个智能体在三种截然不同的工作模式之间切换，效果往往不如三个专职智能体。这就像团队里配前端、后端、测试三个角色，虽然也有沟通成本，但专业化的收益超过了内耗。

第三，系统里有某些环节必须独立隔离。比如你想让一个智能体的输出不会污染另一个的上下文，或者某个环节的失败不能拖垮整个流程，那么把它单独拆出来作为一个小模块，可以起到故障隔离的效果。这种情况不是为了"加速"，而是为了"控制爆炸半径"。

5.2 打死也别拆的四种信号

反过来，下面这四种情况我基本都劝阻过，包括我自己早期项目也中过招。

第一，任务本身在一个上下文窗口内就能完成。如果一个智能体已经能从头到尾读完所有输入并输出完整结果，那你拆出来的每一步都是在做"无意义的转述"。这个信号最直接：你手上这个任务，单智能体是否能一遍跑通？如果能，就不要为了架构好看而拆分。

第二，子任务之间高度串行。下游每一步都依赖上游的输出细节，没有被压缩成摘要的空间。这时候拆开多个人，除非你能让每个人对中间结果的"原文"做索引而不是转述，否则信息逐层衰减一定发生。

第三，系统对输出格式要求极其严格。多智能体系统的风格漂移是出了名的，每个模型实例的用词习惯、标点风格、结构偏好都可能不同。如果最终输出必须严格对齐模板、字段、枚举值，多智能体反而会让校验成本翻倍。这种情况下，单智能体加严格的输出schema校验，比多智能体协作稳定得多。

第四，调试成本已经主导了你的开发节奏。如果你发现每次结果不对，都要翻遍所有智能体中间的每一轮对话才能定位问题，那就说明这个系统已经复杂到超出你的掌控范围。多智能体的调试成本是指数级增长的，如果当前架构已经开始频繁"考古式排错"，正确的做法是合并智能体，而不是再增加一个协调者。

5.3 "单智能体+工具调用"的隐性优势

我见过一个特别有意思的现象：很多人把"需要调用代码、需要查数据库、需要跑脚本"当成上多智能体的理由。但仔细想想，单智能体加工具调用，完全可以覆盖这些需求。

大模型的工具调用机制，本质上就是把"给团队里配一个程序员"这件事，内化成"给一个人配一套工具箱"。你不需要让一个规划智能体把任务派给"代码智能体"，再让代码智能体把结果回报给规划智能体——你只需要让同一个智能体去调用一个代码执行工具，直接拿到结果，上下文完全连续，没有任何沟通损耗。

这个差别在工程上极其巨大。上下文连续意味着智能体对任务的全局理解从头到尾是一致的，不会因为中间转了两次手就遗忘原始意图。工具调用意味着"技能"被外置，模型不需要在脑子里硬算代码结果，只需要调用工具拿真实返回值即可。我在项目里把不少"多智能体流水线"改成"单智能体+多工具"之后，token消耗普遍降一半以上，结果质量还更稳。

5.4 拆之前先回答的五个问题

所以我建议，任何人在动手拆多智能体之前，先对着下面这五个问题过一遍：

这五个问题都过完之后，如果仍然有强烈的拆分信号，再动手也不迟。

6. 实战手段：把10个智能体压回3个，还跑得更快

6.1 用固定Workflow替代自由编排，只在决策点开Agent

很多人上多智能体是被"自由编排"这个概念吸引的：让一个智能体自动决定怎么拆任务、派给谁。听上去智能，实际跑起来是一场灾难。一个编排智能体在面对复杂任务时，它的任务拆分方式每次可能都不一样，这直接导致系统行为不可预测。

我的做法是反过来：能用固定代码写死的流程，绝对不用智能体去"自由编排"。比如"数据清洗→特征提取→规则过滤→LLM生成→格式校验"这个流程，清洗、过滤、校验这些步骤全部用确定性代码实现，每一步之间用明确的接口传递数据，只有真正需要理解和生成的环节才调用一次模型。这样系统90%的行为是确定的，剩下10%的不确定性被严格限制在几个孤立的决策点上，无论调试还是维护都轻松得多。这相当于把"虚拟团队的自由讨论"降级成"一条流水线上的几个固定工位"——分工还在，但沟通被流程本身取代了。

6.2 用结构化消息协议代替自由长文本交接

如果你确实需要多个智能体协作，我还强烈建议：给它们定义一套结构化的消息协议，而不是让它们自由地写长篇自然语言。这个做法可以大幅降低"语义传真损耗"。

举个例子，上游智能体不再输出一段自然语言段落，而是输出一个固定结构的JSON：

{ "status": "done", "summary": "一句话结论", "findings": [ "关键发现1", "关键发现2" ], "risk_flagged": false, "next_required": "review_final_draft" }

下游智能体只需要读固定的几个字段，再结合summary和findings做决策。status字段直接把"任务完成"的状态信息从散文里剥离出来，findings字段限制了自由发挥的空间，risk_flagged字段是一个显式的布尔信号。这样信息传递就从"传一篇作文"变成了"传递一张标准表格"，误解概率大幅下降。

这个做法本质上是在给智能体团队定"文档规范"。真实项目团队里，大家开会讨论可以自由发言，但写进正式文档的东西一定要走模板、走评审，为的就是减少歧义和让信息可检索。智能体之间也该一样：自由的讨论可以放在一个智能体的内部思维里，但跨智能体的正式交接，必须走结构化协议。

6.3 共享记忆与结果缓存，切断"转述式"信息传递

多智能体系统里有一个很隐蔽的浪费：同一个信息被不同智能体反复转述。上游加载了全部原始文档，吐出一段摘要；下游为了理解这段摘要，又得从摘要里"脑补"回去。整个链条上，原始信息的很多细节就在转述中丢失了。

解决思路是引入共享记忆和结果缓存。具体来说，就是让所有需要读取原始信息的智能体，直接访问同一个共享上下文或外部存储，而不是依赖上一个智能体"带话"。比如把原始文档向量化之后存起来，任何一个智能体要查原始细节，直接用检索工具去查，而不是让上游把整段原文贴在消息里。这样既降低了每个智能体的上下文负担，又避免了信息在转述中变形。

这一招的实际效果非常显著。我做过对比，同样的任务，有共享记忆的架构比纯链式转述架构，token消耗能降40%以上，而且下游智能体因为能直接检索原始信息，结论准确率明显提升。原理上很简单：通信不应该传递数据本身，而应该传递数据的引用和指针，让需要的人自己去看原文。这不只是针对AI智能体的技巧，它其实是分布式系统设计里最基本的原则。

6.4 给项目设"智能体预算"：先单后多，按瓶颈拆分

我给自己的每个项目都设了一个很土但极其有效的规则：项目启动时，默认不超过2个智能体。只有在系统跑起来、并且用数据证明某个瓶颈确实需要新增智能体时，才允许加一个。

具体策略是"先单后多"：第一步，用一个智能体加所有必要的工具，把整个流程跑通。第二步，观察这个智能体在哪里卡住了。卡住的原因通常有几种：上下文太长导致遗忘（这时候不是加智能体，而是该加检索或摘要工具）；输出格式不稳定（该加规则校验）；需要同时并行处理多路独立数据（这时候才考虑加提取员或检索员智能体）。说白了，要先用数据和事实确认瓶颈，再动手加人，而不是在开工前就按组织架构图把团队画好。

这个习惯救了我很多次。每次我忍不住想"这里再拆一个智能体吧"的时候，先逼自己回答一个问题：这个环节用工具能不能解决？用规则能不能解决？用提示词改进能不能解决？在绝大多数情况下，这些更便宜的手段都够用，根本轮不到加智能体。

6.5 质量门禁优先用规则：schema校验、测试、静态检查

最后这条我特别想强调：质量门禁尽量不要用智能体。很多人在多智能体流程里配一个"审查智能体"或者"质检智能体"，指望大模型来抓前一个智能体的错。想法很好，但效果通常有限，因为审查者也同样会犯错，而且审查者也会消耗大量token。

更靠谱的做法是：能用规则校验的，绝对不用模型判断。比如输出JSON格式校验，用schema定义好字段类型和必填项，程序直接校验；代码生成任务，用单元测试和静态检查去验证，而不是再问另一个模型"这代码对不对"；数据聚合任务，用断言检查总和、去重数量这类硬性指标。这些校验是确定性的，不管模型输出什么样，规则都会稳定地给出对错结论，而且几乎不消耗token。

把规则校验作为第一道门禁，把智能体审查作为可选的第二道门禁，系统的稳定性会有一个质的提升。我把这个原则叫做"给智能体配上安全网，而不是派一个保安盯着另一个保安"。在我所有的项目里，这条带来的投资回报率最高。

7. 把软件工程团队管理经验搬过来：三条"反Brooks定律"实践

7.1 小步快跑：让每个智能体只返回最小可用结果

多智能体系统里的一个大毛病是：每个智能体都喜欢"一次给全"。它会在一次输出里把所有想到的东西都倒出来，哪怕下游根本用不到。这跟新手员工喜欢交一份超长周报差不多，看着很努力，但信息密度很低。

我后来的要求是：每个智能体的输出必须遵守"最小可用结果"原则，只返回当前阶段决策所必需的信息，其余内容一律不放出来。如果它觉得有额外信息重要，可以提供一份摘要附件，而不是把正文撑爆。这个原则直接控制了通信token数量，同时让下游智能体的注意力能被集中到真正重要的字段上。别看这个改动小，它往往能把token消耗降下来一大截。

7.2 合并岗位：执行+自检放在同一个智能体里

我再分享一个合并岗位的实操经验：把"执行"和"自检"放在同一个智能体里，而不是拆成两个角色。很多人喜欢设计一个"执行智能体"加一个"审查智能体"，觉得这样可以互相制衡。但测试下来，同一个智能体在执行完任务后，紧接着用一套自检提示词检查自己的输出，效果往往比另一个人审查更好。

原因也很简单：同一个智能体的上下文是连续的，它记得自己当初为什么这么写，自检的时候可以直接对照自己的推理过程；而另一个审查智能体只能看到最终输出，它没有完整的内部思维链，审查纯靠"猜"。而且让同一个智能体自检，不需要重新传递一遍上下文，通信开销为零。我在代码生成任务上做过对比，"执行+自检同一体"的最终通过率，明显高于"执行者+审查者"的流水线。

7.3 Token预算当项目预算管

最后一个实践可能有点土：我要求自己把token消耗当项目预算来管，每周过一遍，看看每个智能体角色各花了多少钱、带来了多少产出。有了这个数字，很多关于架构的判断就自动变清晰了。

如果你发现某个智能体的token消耗占整个系统50%，但对最终结果的贡献几乎没有，那不管它当初设计时听起来多必要，都应该被干掉或合并。Token预算就是多智能体系统的"人力成本表"，它能逼你在做大刀阔斧的架构精简时有数据可依，而不是凭感觉砍人。之前那个"六个智能体"项目，我就是在拉出token账单之后才发现，真正有价值的角色只有三个，其余的全是会议记录员和转述员。

我自己现在的项目，默认只开一个智能体加必要的工具，只有当"可并行的信息采集"和"强专业分化"这两种明确信号出现时，我才考虑拆第二、第三个。衡量架构好坏，我只看两个数字：每单位有效产出的token消耗，以及一次失败之后的平均排查时间。这两个数字能治住几乎所有加智能体的冲动。别迷信人多力量大，能让流程解决的，就别让智能体去开会；能用工具解决的，就别再派一个模型去解释。