多智能体并非越多越好：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×(01234)20000 token。如果把智能体翻倍到10个总通信消耗就变成2000×(0123…9)90000 token。智能体数量只翻了一倍通信开销却涨了4.5倍。这在数学上非常接近团队沟通路径N×(N-1)/2的增长方式——不是线性是平方级。而且这还只是理想情况。实际跑起来智能体之间经常需要来回确认、修改、二次传递一旦出现上游没说明白、下游理解错了的情况整个链条可能往回重跑。我在下面的实验结果里会给出真实的token数据那个差距会比理论估算更夸张。3.2 自然语言接口契约智能体之间的语义传真损耗软件工程里模块和模块之间靠接口通信接口有明确的类型定义、参数约束、返回值约定。但智能体和智能体之间绝大多数情况下靠的是自然语言消息——这相当于让两个程序用散文对话。一篇散文的信息密度、歧义程度、风格差异都会直接影响下游理解的准确性。我把这个叫语义传真损耗上游智能体以为自己讲清楚了下游智能体以为自己听懂了实际上中间的语义已经变形了。典型的表现有几种上游输出的已完成在下游看来其实是还没验证过上游用问题严重表达优先级最高下游理解成需要更多分析同一个术语在两个智能体的知识体系里指代不同的东西。人对这种事情有纠错能力因为人知道自己可能会误解会主动追问但智能体很少主动追问它只会在给定的上下文里猜猜错了就直接往下执行。所以在多智能体系统里消息的模糊度就是错误的种子。每多一层传递就多一层误解的机会。这跟传真机传文件一样传一次可能还清楚传个三五次之后字迹基本没法看了。3.3 编排者成为新的单点瓶颈与错误级联多智能体系统通常有一个编排者或叫规划者、协调者负责把任务拆给各个执行智能体再汇总结果。听起来很合理但这个编排者恰恰是整个系统里上下文负担最重、最容易出错的地方。为什么因为编排者要看过所有内容。每个执行智能体的输入、输出它都要读一遍才能决策下一步。任务越复杂、执行智能体越多编排者需要装进上下文窗口的东西就越多。大模型的上下文窗口是有限资源内容一多注意力就会被稀释编排者开始遗漏细节、做出错误的调度判断。它就像一个永远在开会的经理被各路汇报淹没最后做出的决策质量反而更低。更危险的是错误级联一旦编排者把某个子任务判断错了或者把某个执行者的错误输出当成正确结果继续往下传后面所有智能体都会基于这个错误继续工作。这种级联错误在多智能体系统里特别难查因为你根本不知道是哪个环节开始歪的。调试的时候你要把这几个智能体的完整对话全部翻出来人工比对中间结论成本极高。3.4 调试矩阵爆炸每多一个角色组合验证量翻几倍最后是调试成本。一个智能体的系统你要测的就是输入→输出这一条线。两个智能体的系统除了测各自的功能你还要测两者之间的交互A的输出B能不能正确理解A的错误格式B能不能识别出来A和B对一个中间术语的定义是否一致这些交互场景加起来需要验证的路径数量迅速膨胀。三个智能体之间有三条双向交互线加一条三方协同线四个就是六条双向线加更多组合这是标准的组合爆炸。我在实际项目里最深的感受是每多一个智能体你的调试矩阵就多一整个维度。你以为你在用智能体解决问题实际上你在维护一套比单体程序更难调试的分布式系统而且这个系统的每个节点还都不是确定性的——同一个输入同一个模型两次跑出来的结果可能不一样。这种不确定性叠加在组合爆炸的交互上让多智能体系统的行为变得极其难以预测。为了让你更直观地看明白这一条我把软件项目团队和多智能体系统做个对照软件项目团队的现象多智能体系统的对应表现沟通路径N×(N-1)/2爆炸token通信消耗近似平方级增长新成员要读文档、理解架构每个智能体要把历史上下文重新加载一遍串行任务无法靠加人加速下游智能体必须等上游输出才能启动人员之间用自然语言对齐语义智能体之间用自然语言消息传递误解率更高团队成员有风格差异代码风格不统一多个智能体输出风格漂移格式难保持一致项目经理成为信息汇聚瓶颈编排者的上下文被各路汇报填满决策质量下降一个环节出错后续环节连锁反应错误级联且观察者难以定位错误源头这张表基本就是我后来判断要不要拆多智能体的依据清单大家在设计系统的时候可以直接拿来对照。4. 一个可以复现的对照实验1个智能体 vs 3个智能体流水线4.1 实验任务与两条路线设计光讲原理有点空我做一个简单但可复现的实验。任务我故意选了一个日常工作里很典型的需求把16条散乱的产品反馈笔记整理成一份带优先级排序的改进建议清单并给出可执行的下周计划。这类任务不涉及复杂代码但需要理解、归纳、取舍和结构化输出非常适合用来观察智能体的协作行为。实验分两条路线使用同一个底层大语言模型保证变量只有架构方式这一个维度路线A单智能体直接完成一个智能体接收全部笔记自主完成整理、排序、制定计划的全过程最终输出一份清单。路线B三智能体流水线第一个智能体负责阅读全部笔记并提炼关键问题第二个智能体负责在此基础上做优先级排序和分类第三个智能体负责把前两步的结果改写成正式的下周计划。每一条路线都跑了5次取中位数对比评测维度是总输入输出token数、完成时的对话轮次、结果质量人工打分1到5分、输出格式一致性。4.2 评测维度与结果结果出来的时候我周围几个同样在做智能体的朋友都有点意外指标单智能体路线A三智能体流水线路线Btoken总消耗约32000约96000对话轮次约18轮约34轮质量打分4.2 / 54.0 / 5格式一致性高自始至终同一风格中三个智能体风格明显割裂5次实验中的失败回退次数0次2次其中1次是审查环节推翻重来三智能体流水线的token消耗差不多是单智能体的三倍物理时间也明显更长但最终质量不但没有提升反而略低。有一次甚至出现了第二个智能体把第一个智能体已经做对的信息搞乱了第三个智能体基于错乱的信息做计划最后还得从头修正。4.3 复盘这轮里Brooks定律是怎么生效的我复盘了一下这个结果发现Brooks定律里的三条底层原因在智能体流水线里全部应验了。第一沟通路径爆炸。三智能体流水线虽然只有两个交接点但每个交接点都要把完整的中间结果重新写一遍。第二个智能体读到的是第一个智能体转述后的信息而不是原始笔记这里的信息密度已经下降了。第三个智能体要同时参考前两个智能体的输出风格和内容token占用加倍。第二串行依赖。这个任务本质上是高度串行的必须先理解所有笔记才能排列优先级必须先有优先级才能制定下周计划。三个智能体之间没有任何一个环节是可以并行的那拆成三个人的意义就不存在纯纯只是增加了交接成本。第三质量门禁的幻觉。我在路线B里本来期待多一个智能体多一道审查能提升质量但现实是审查者本身也是模型它依然会犯错。你不能指望用另一个大模型来稳定地纠正前一个大模型的错误这本质上是两个不确定性叠加。后来我学到一个词确定性校验才是质量门禁模型审查只是参考意见。4.4 反转当任务复杂度上升拆分才开始有意义不过我同时做了另一个对照当任务里加入一个真正可并行的环节之后结论立刻反转。我把任务改成除了整理反馈笔记还要同时从三份外部文档里分别提取数据再汇总成报告。这时候三个提取员智能体可以真正并行跑互不等待各自输出一份局部结果最后用一个汇总智能体合并。这个场景下三智能体的token消耗虽然还是比单智能体高因为通信存在但物理时间明显缩短因为三个提取任务同时启动单智能体只能串行地一份一份读。这说明Brooks定律不是否定分工而是警告你分工只有在真正可并行、且并行收益大于通信成本的时候才成立。判断一个任务能不能拆关键不是看起来能不能分成几步而是分成后的每一步是不是真的可以同时进行、互不依赖。5. 什么时候该拆什么时候打死也别拆——决策清单5.1 值得拆的三种信号我在自己的实践里总结出三个相对靠谱的可拆信号。第一子任务之间确实可并行并且彼此的输入输出没有强依赖。比如上面那个同时从多份文档提取信息的场景每个提取任务独立完成最后汇总即可。这种拆分能让物理耗时显著下降通信成本换并行收益是划算的。第二任务涉及差异很大的专业领域并且每个领域需要不同的提示词策略、不同的工具链。比如一个项目里既要做自然语言总结又要跑数据分析还要生成可视化图表让一个智能体在三种截然不同的工作模式之间切换效果往往不如三个专职智能体。这就像团队里配前端、后端、测试三个角色虽然也有沟通成本但专业化的收益超过了内耗。第三系统里有某些环节必须独立隔离。比如你想让一个智能体的输出不会污染另一个的上下文或者某个环节的失败不能拖垮整个流程那么把它单独拆出来作为一个小模块可以起到故障隔离的效果。这种情况不是为了加速而是为了控制爆炸半径。5.2 打死也别拆的四种信号反过来下面这四种情况我基本都劝阻过包括我自己早期项目也中过招。第一任务本身在一个上下文窗口内就能完成。如果一个智能体已经能从头到尾读完所有输入并输出完整结果那你拆出来的每一步都是在做无意义的转述。这个信号最直接你手上这个任务单智能体是否能一遍跑通如果能就不要为了架构好看而拆分。第二子任务之间高度串行。下游每一步都依赖上游的输出细节没有被压缩成摘要的空间。这时候拆开多个人除非你能让每个人对中间结果的原文做索引而不是转述否则信息逐层衰减一定发生。第三系统对输出格式要求极其严格。多智能体系统的风格漂移是出了名的每个模型实例的用词习惯、标点风格、结构偏好都可能不同。如果最终输出必须严格对齐模板、字段、枚举值多智能体反而会让校验成本翻倍。这种情况下单智能体加严格的输出schema校验比多智能体协作稳定得多。第四调试成本已经主导了你的开发节奏。如果你发现每次结果不对都要翻遍所有智能体中间的每一轮对话才能定位问题那就说明这个系统已经复杂到超出你的掌控范围。多智能体的调试成本是指数级增长的如果当前架构已经开始频繁考古式排错正确的做法是合并智能体而不是再增加一个协调者。5.3 单智能体工具调用的隐性优势我见过一个特别有意思的现象很多人把需要调用代码、需要查数据库、需要跑脚本当成上多智能体的理由。但仔细想想单智能体加工具调用完全可以覆盖这些需求。大模型的工具调用机制本质上就是把给团队里配一个程序员这件事内化成给一个人配一套工具箱。你不需要让一个规划智能体把任务派给代码智能体再让代码智能体把结果回报给规划智能体——你只需要让同一个智能体去调用一个代码执行工具直接拿到结果上下文完全连续没有任何沟通损耗。这个差别在工程上极其巨大。上下文连续意味着智能体对任务的全局理解从头到尾是一致的不会因为中间转了两次手就遗忘原始意图。工具调用意味着技能被外置模型不需要在脑子里硬算代码结果只需要调用工具拿真实返回值即可。我在项目里把不少多智能体流水线改成单智能体多工具之后token消耗普遍降一半以上结果质量还更稳。5.4 拆之前先回答的五个问题所以我建议任何人在动手拆多智能体之前先对着下面这五个问题过一遍问题如果是否结论子任务之间是否真正可以并行执行否高度串行不应该拆每个子任务的输出是否可以被下游直接使用而不需要大量转述否需要解释和重述不该拆信息衰减多智能体之间的通信token开销是否明显小于任务本身的处理开销否通信开销占大头不该拆单个智能体工具调用是否已经能完成任务是先用单智能体任何一个中间智能体出错时你能接受返工成本吗否损失太大不要加不可靠的中间环节这五个问题都过完之后如果仍然有强烈的拆分信号再动手也不迟。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消耗以及一次失败之后的平均排查时间。这两个数字能治住几乎所有加智能体的冲动。别迷信人多力量大能让流程解决的就别让智能体去开会能用工具解决的就别再派一个模型去解释。

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

相关推荐

用Dify零代码实现双模型分栏同步流式输出，替代OpenWebUI

AI重塑神经科学：数据处理、模型选型与避坑实战指南

7-Zip安装教程：从下载到使用的干净解压软件完全指南

更多资讯

自托管Sentry升级遇Django迁移冲突：table already exists排查与修复

小程序安全评估：解析mtgsig1.2 w1.6动态签名机制与排查思路

Spring Bean Scope 全解析：从 singleton 到 prototype 的创建机制与实战陷阱

Qwen 27篇论文深度复盘：从架构选型到垂直分支的技术决策

模型超越榜单背后：评测方法、开源部署与真实应用

随机森林预测电池RUL：不依赖电化学方程的稳定建模方法

今日更新

悟空开源无代码平台实战：从实体建模到应用设计避坑指南

基于.NET9的多租户权限系统：数据权限与动态API落地实践

场地预约小程序毕设实战：SSM+微信小程序+MySQL数据库设计到避坑

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？