1. 从一次翻车的多智能体协作实验说起去年下半年我接手了一个内部知识库问答系统的重构任务。需求本身不算复杂把散落在多个文档仓库里的技术资料整合起来做一个能回答某个接口怎么调用某个配置项默认值是多少这类问题的助手。单智能体方案跑了两周效果勉强能用但遇到需要跨文档对比、多步骤推理的问题时准确率就掉得厉害。当时团队里有人提了一句要不试试多智能体协作让一个负责检索、一个负责推理、一个负责校验三个臭皮匠顶个诸葛亮。这个想法听起来很合理毕竟人类团队分工协作确实能解决单个人搞不定的复杂问题。于是我们花了一周时间搭了一套三角色协作框架结果跑完对比测试所有人都沉默了。多智能体方案的总耗时是单智能体的32倍Token消耗是13倍而最终答案的准确率反而下降了约7个百分点。这个数字不是我编的是我们用同一批200条测试问题、同一套底层模型、同一台机器跑出来的真实对比。更让人难受的是失败案例里有一大半不是答错了而是答得又慢又贵还答偏了——三个智能体在互相确认、互相纠正的过程中把原本正确的答案改错了。这篇文章不是要否定多智能体协作这个方向。恰恰相反我认为它在某些场景下确实有价值。但我想把这次翻车的完整过程拆开讲清楚为什么32倍和13倍这两个数字会出现为什么更多智能体不等于更好结果以及在什么条件下多智能体协作才真正划算。如果你正在考虑给自己的项目加多智能体架构或者已经被老板问过为什么不用多智能体这篇内容应该能帮你省下不少试错成本。2. 32倍时间和13倍Token到底花在了哪里2.1 一次完整请求的调用链路拆解先看单智能体方案。用户提问进来系统做一次意图识别判断是查接口还是查配置还是查流程然后走对应的检索路径把检索到的文档片段拼进提示词调用一次大模型生成答案返回。整个链路里大模型调用只有一次检索调用一到两次总耗时在2到4秒之间Token消耗主要来自检索到的文档片段加上用户问题平均在1500到2500之间。多智能体方案就完全不一样了。我们设计的三角色框架是这样的检索智能体负责根据问题去知识库里捞相关文档推理智能体负责基于文档生成初步答案校验智能体负责检查答案是否准确、是否有遗漏、是否需要补充检索。听起来分工明确但实际运行时一次请求的调用链路变成了这样检索智能体接收问题调用一次大模型做查询改写再调用检索接口再调用一次大模型做结果筛选。推理智能体接收检索结果调用一次大模型生成初步答案。校验智能体接收问题和初步答案调用一次大模型做校验输出通过或需要补充。如果校验不通过推理智能体要重新生成校验智能体再校验一次。如果校验智能体认为需要补充检索检索智能体要再跑一轮。最后还要有一个汇总环节把多轮结果合并成最终答案。实测下来平均一次请求触发了4.7次大模型调用和3.2次检索调用。大模型调用次数多了单次调用的输入Token也变长了——因为每个智能体都要带上完整的上下文包括原始问题、历史检索结果、前序智能体的输出。这就导致Token消耗不是线性增长而是接近指数级膨胀。2.2 时间都耗在了智能体之间的对齐上32倍的时间开销里真正花在思考上的时间其实只占一小部分大头是智能体之间的通信和等待。每个智能体调用大模型都是串行的检索智能体跑完才能轮到推理智能体推理智能体跑完才能轮到校验智能体。如果校验不通过还要回退重跑。这种串行结构下单次大模型调用的延迟被放大了将近5倍。更隐蔽的是上下文膨胀带来的延迟增加。大模型的响应时间跟输入长度强相关输入从2000 Token涨到8000 Token响应时间可能从1.5秒涨到4秒。多智能体框架里每个智能体都要带上完整的历史上下文导致每次调用的输入都比单智能体方案长得多。我们统计过多智能体方案的平均单次调用输入长度是单智能体的3.8倍这直接推高了每次调用的耗时。还有一个容易被忽略的点智能体之间的确认和纠偏会触发额外的调用。校验智能体说这个答案可能不完整推理智能体就要重新生成重新生成后校验智能体再校验如果还不满意可能再来一轮。我们测试集里有大约18%的问题触发了至少一次重跑其中又有约6%触发了两次以上重跑。这些重跑在单智能体方案里根本不存在因为单智能体没有校验这个环节。2.3 Token消耗的13倍是怎么算出来的Token消耗的膨胀来自三个层面。第一层是角色提示词的固定开销。每个智能体都需要一套独立的系统提示词描述它的角色、职责、输出格式。检索智能体的提示词大约400 Token推理智能体大约600 Token校验智能体大约500 Token。这些提示词每次调用都要带上属于纯开销。第二层是上下文重复传递。检索智能体捞到的文档片段要传给推理智能体推理智能体生成的初步答案要传给校验智能体校验智能体的反馈又要传回推理智能体。同一份信息在多个智能体之间反复传递每次传递都算一次Token消耗。我们统计过一份平均800 Token的检索结果在整个链路里被传递了3.4次相当于多花了2700 Token。第三层是重跑带来的额外消耗。每次重跑都要重新走一遍推理和校验流程输入上下文还要再膨胀一轮。18%的重跑率意味着平均每5个问题就有1个要多花一轮完整调用的Token。这三层叠加起来13倍的Token消耗就不难理解了。对比维度单智能体方案多智能体方案倍数关系平均大模型调用次数1.0次4.7次4.7倍平均单次输入Token约2000约76003.8倍平均总Token消耗约2000约2600013倍平均端到端耗时约2.8秒约89秒32倍测试集准确率78.5%71.2%下降7.3个百分点3. 为什么三个臭皮匠反而把答案改错了3.1 校验智能体的过度纠偏现象多智能体方案准确率下降的最主要原因是校验智能体太敬业了。它的系统提示词里写着请仔细检查答案是否准确、完整、无遗漏结果它把很多本来正确的答案判成了需要补充。我们人工复核了所有被校验智能体打回重做的案例发现其中约62%的答案是原本正确的校验智能体提出的补充建议要么是无关紧要的细节要么是它自己理解错了。举个例子。用户问某个配置项的默认值是多少推理智能体从文档里找到了明确答案默认值是30秒校验智能体却说建议补充该配置项的生效范围说明。推理智能体老老实实去补充结果补充的内容里混进了另一个同名配置项的信息最终答案反而错了。单智能体方案直接给出30秒就完事了多智能体方案绕了一圈把对的改成了错的。这种过度纠偏的根源在于校验智能体没有知足的能力。人类专家校验时如果答案已经准确回答了问题就会说可以了。但大模型驱动的校验智能体它的训练目标里没有适可而止这一项它被设计成尽量找出问题于是它总能找出一些可以更好的地方。这些可以更好的改动在缺乏全局判断的情况下很容易引入新错误。3.2 智能体之间的信息衰减与语义漂移多智能体协作还有一个隐蔽的坑信息在传递过程中会衰减和漂移。检索智能体捞到的原始文档片段经过推理智能体的理解和转述再经过校验智能体的修正最后汇总出来的答案可能已经跟原始文档对不上了。我们做过一个对照实验让推理智能体直接输出它看到的检索结果原文再让它输出基于检索结果的答案对比两者与原始文档的语义相似度。结果发现推理智能体输出的答案与原始文档的相似度平均下降了约15%而经过校验智能体修正后的最终答案相似度又下降了约8%。也就是说每经过一个智能体信息就失真一次。三个智能体串下来最终答案跟原始文档的语义距离已经相当远了。这种衰减在需要精确引用原文的场景里特别致命。比如用户问某个接口的错误码1001代表什么原始文档写的是参数校验失败推理智能体可能转述成请求参数有问题校验智能体再改成输入数据格式错误最终答案虽然意思相近但已经偏离了文档的精确表述。如果用户是要拿这个答案去写代码或做配置这种偏差就可能造成实际问题。3.3 角色冲突与责任分散效应我们设计的三角色框架里检索智能体、推理智能体、校验智能体各自有独立的系统提示词但它们的知识来源是同一个底层模型。这意味着三个智能体其实共享同一套偏见和盲区。如果底层模型对某个领域的知识掌握得不好三个智能体都会在这个领域犯错而且它们会互相确认对方的错误。更麻烦的是责任分散效应。单智能体方案里如果答错了就是这一个模型的问题优化方向很明确。多智能体方案里答错了之后你很难定位到底是检索没捞到、推理没理解、还是校验改错了。我们排查失败案例时经常出现三个智能体互相甩锅的情况检索智能体说我捞到的文档是对的推理智能体说我是按文档写的校验智能体说我是按规则校验的。最后发现是校验规则本身有歧义但这条规则是三个智能体共同认可的。这种责任分散还会导致优化无从下手。单智能体方案准确率低你可以换模型、改提示词、加检索数据。多智能体方案准确率低你改检索智能体的提示词可能影响推理智能体的输入改校验智能体的规则可能影响整体流程的稳定性。牵一发而动全身调优成本远高于单智能体。4. 多智能体协作真正划算的三种场景4.1 任务本身可以并行拆解且子任务独立多智能体协作不是完全没用但它有明确的适用边界。第一种真正划算的场景是任务可以拆成多个相互独立的子任务且子任务之间不需要频繁通信。比如你要分析一份长文档让一个智能体负责提取所有日期一个负责提取所有人名一个负责提取所有金额。这三个子任务互不依赖可以并行跑最后合并结果。这种情况下多智能体的时间开销不会线性叠加Token消耗也主要是并行产生的没有反复传递的浪费。关键判断标准是子任务之间是否需要对齐。如果子任务各自独立产出结果最后简单合并就行那多智能体是划算的。如果子任务之间需要反复确认、互相修正那多智能体大概率会翻车。我们那个知识库问答系统就属于后者——检索、推理、校验三个环节高度耦合必须串行执行所以时间开销直接叠加了。4.2 需要多视角交叉验证且错误代价极高第二种场景是单次错误的代价极高值得用额外的时间和Token去换更高的可靠性。比如医疗诊断辅助、法律文书审核、金融风控决策这类场景答错的代价远大于多花几倍时间和Token。这时候多智能体协作的交叉验证机制就有价值了——让多个智能体独立给出答案再对比差异差异大的地方重点人工复核。但这里有个前提多个智能体必须是真正独立的。如果它们共享同一个底层模型、同一套提示词模板、同一个知识库那它们的独立只是形式上的错误会高度相关。真正有效的交叉验证需要智能体在模型、数据源、推理路径上都有差异。比如一个用大模型、一个用规则引擎、一个用检索增强这样它们的错误才不容易同时发生。4.3 任务复杂度超出单智能体上下文窗口第三种场景是任务需要的上下文长度超出了单智能体的窗口限制必须分而治之。比如你要分析一份几百页的技术文档单智能体塞不进去就可以让多个智能体各负责一部分分别提取关键信息最后汇总。这种情况下多智能体不是为了协作而是为了分片处理本质上是工程上的妥协。但这种场景下智能体之间的通信要尽量少。每个智能体独立处理自己的分片输出结构化结果最后由一个汇总环节合并。如果让智能体之间频繁传递原始文本Token消耗会爆炸而且信息衰减会很严重。我们的经验是分片处理时每个智能体只输出结构化摘要不传递原始文本这样能把Token消耗控制在可接受范围内。适用场景核心特征推荐架构预期开销并行独立子任务子任务无依赖可并行并行智能体结果合并时间接近单智能体Token约1.5到2倍高代价交叉验证错误代价极高需多视角独立智能体差异对比时间约3到5倍Token约4到6倍超长上下文分片单窗口塞不下需分片分片智能体结构化汇总时间约2到3倍Token约2到3倍串行协作推理环节耦合需反复对齐不推荐时间10倍以上Token10倍以上5. 如果非要用多智能体怎么把开销压下来5.1 用路由代替全量协作最常见的浪费是所有问题都走完整的多智能体流程。但实际上大部分问题单智能体就能搞定只有少数复杂问题才需要多智能体介入。我们后来改成了路由架构先用一个轻量级分类器判断问题复杂度简单问题直接走单智能体复杂问题才触发多智能体流程。这样整体平均开销降到了原来的三分之一左右。路由分类器不需要很复杂用一个小模型或者甚至规则引擎就能做。判断依据可以是问题是否涉及多个文档、是否需要多步推理、是否包含对比或因果类问法。我们实测下来大约70%的问题可以被路由到单智能体路径只有30%需要多智能体。这30%里又只有一部分真正需要完整的三角色协作很多只需要检索推理两个角色就够了。5.2 给智能体之间的通信瘦身多智能体Token消耗的大头是上下文重复传递。优化方向很明确每个智能体只传递必要信息不传完整历史。比如检索智能体给推理智能体传结果时不要传原始文档全文而是传结构化摘要——文档ID、关键段落、置信度。推理智能体给校验智能体传答案时不要传检索过程只传答案和引用来源。我们还做了一个优化给每个智能体的输出加长度限制。检索智能体的输出限制在500 Token以内推理智能体的输出限制在800 Token以内校验智能体的输出限制在300 Token以内。超过限制就截断或要求重新生成。这个简单的限制把Token消耗压下来了约40%而且因为强制智能体说重点信息衰减反而减轻了。5.3 设置止损机制避免无限重跑校验智能体的过度纠偏必须用机制约束。我们后来加了两条规则第一每个问题最多允许一次重跑第二次校验不管结果如何都直接输出第二校验智能体只能提出事实性错误的修正不能提出补充说明类的建议。这两条规则把重跑率从18%压到了4%左右准确率反而回升了。止损机制的核心逻辑是多智能体协作的收益递减很快但成本递增很快。第一轮校验可能能发现一些真问题第二轮、第三轮的边际收益几乎为零但每轮都要花掉完整的时间和Token。所以必须设一个硬性上限超过就强制结束。这个上限具体设多少要根据你的场景容忍度来定但我的经验是重跑次数不要超过一次。6. 几个容易踩的坑和我的实操心得6.1 不要用智能体数量衡量架构先进性我见过不少团队在方案评审时把我们用了5个智能体当成亮点来讲。这其实是个误区。智能体数量多不代表架构先进反而往往意味着通信开销大、调试难度高、故障点多。真正好的架构是用最少的智能体解决问题而不是用最多的智能体展示技术。我们后来把三角色精简成了两角色去掉校验智能体把校验逻辑合并到推理智能体的提示词里效果反而更好。6.2 先跑通单智能体基线再考虑多智能体这是我最想强调的一点如果你连单智能体方案都没调优到极限就不要碰多智能体。我们当时犯的错误就是单智能体方案只跑了两周就急着上多智能体结果多智能体方案的问题里有一大半其实是单智能体方案就存在的——检索不准、提示词有歧义、知识库覆盖不全。这些问题在多智能体框架里被放大了但根源不在架构在基础工作没做扎实。正确的顺序应该是先把单智能体的检索、提示词、知识库都调到最优记录下准确率和开销基线。然后针对单智能体确实搞不定的那部分问题再考虑用多智能体补充。如果单智能体已经能解决80%的问题多智能体只需要处理剩下的20%整体开销就可控了。6.3 监控要细到每个智能体的调用多智能体方案的调试难度远高于单智能体因为出问题时你很难定位是哪个环节的锅。我们后来加了一套细粒度监控每个智能体的每次调用都记录输入Token、输出Token、耗时、是否触发重跑。这样出问题时能快速定位是检索没捞到、推理没理解、还是校验改错了。没有这套监控调优基本靠猜。监控数据还能帮你发现一些反直觉的现象。比如我们通过监控发现校验智能体的耗时跟输入长度几乎无关而是跟它是否决定打回重做强相关——决定打回时它要生成详细的修正建议耗时是直接通过的3倍。这个发现让我们优化了校验智能体的输出格式要求它打回时只输出打回原因代码不输出详细建议耗时立刻降下来了。6.4 多智能体不是免费的可靠性提升最后一个心得多智能体协作带来的可靠性提升往往被它引入的新故障模式抵消了。单智能体方案只有一种故障模式模型答错了。多智能体方案至少有四种检索智能体没捞到、推理智能体理解偏了、校验智能体改错了、智能体之间通信丢失了。每多一个智能体就多一种故障模式而每种故障模式都需要额外的监控和容错机制来覆盖。所以我的建议是除非你的场景明确落在前面说的三种适用场景里否则优先考虑单智能体方案。单智能体方案简单、快、便宜、好调试而且随着底层模型能力的提升它的上限还在不断抬高。多智能体协作是一个用复杂度换特定能力的工具不是更先进的代名词。用之前先算清楚账多花的时间和Token换来的可靠性提升到底值不值。
1. 从一次翻车的多智能体协作实验说起去年下半年我接手了一个内部知识库问答系统的重构任务。需求本身不算复杂把散落在多个文档仓库里的技术资料整合起来做一个能回答某个接口怎么调用某个配置项默认值是多少这类问题的助手。单智能体方案跑了两周效果勉强能用但遇到需要跨文档对比、多步骤推理的问题时准确率就掉得厉害。当时团队里有人提了一句要不试试多智能体协作让一个负责检索、一个负责推理、一个负责校验三个臭皮匠顶个诸葛亮。这个想法听起来很合理毕竟人类团队分工协作确实能解决单个人搞不定的复杂问题。于是我们花了一周时间搭了一套三角色协作框架结果跑完对比测试所有人都沉默了。多智能体方案的总耗时是单智能体的32倍Token消耗是13倍而最终答案的准确率反而下降了约7个百分点。这个数字不是我编的是我们用同一批200条测试问题、同一套底层模型、同一台机器跑出来的真实对比。更让人难受的是失败案例里有一大半不是答错了而是答得又慢又贵还答偏了——三个智能体在互相确认、互相纠正的过程中把原本正确的答案改错了。这篇文章不是要否定多智能体协作这个方向。恰恰相反我认为它在某些场景下确实有价值。但我想把这次翻车的完整过程拆开讲清楚为什么32倍和13倍这两个数字会出现为什么更多智能体不等于更好结果以及在什么条件下多智能体协作才真正划算。如果你正在考虑给自己的项目加多智能体架构或者已经被老板问过为什么不用多智能体这篇内容应该能帮你省下不少试错成本。2. 32倍时间和13倍Token到底花在了哪里2.1 一次完整请求的调用链路拆解先看单智能体方案。用户提问进来系统做一次意图识别判断是查接口还是查配置还是查流程然后走对应的检索路径把检索到的文档片段拼进提示词调用一次大模型生成答案返回。整个链路里大模型调用只有一次检索调用一到两次总耗时在2到4秒之间Token消耗主要来自检索到的文档片段加上用户问题平均在1500到2500之间。多智能体方案就完全不一样了。我们设计的三角色框架是这样的检索智能体负责根据问题去知识库里捞相关文档推理智能体负责基于文档生成初步答案校验智能体负责检查答案是否准确、是否有遗漏、是否需要补充检索。听起来分工明确但实际运行时一次请求的调用链路变成了这样检索智能体接收问题调用一次大模型做查询改写再调用检索接口再调用一次大模型做结果筛选。推理智能体接收检索结果调用一次大模型生成初步答案。校验智能体接收问题和初步答案调用一次大模型做校验输出通过或需要补充。如果校验不通过推理智能体要重新生成校验智能体再校验一次。如果校验智能体认为需要补充检索检索智能体要再跑一轮。最后还要有一个汇总环节把多轮结果合并成最终答案。实测下来平均一次请求触发了4.7次大模型调用和3.2次检索调用。大模型调用次数多了单次调用的输入Token也变长了——因为每个智能体都要带上完整的上下文包括原始问题、历史检索结果、前序智能体的输出。这就导致Token消耗不是线性增长而是接近指数级膨胀。2.2 时间都耗在了智能体之间的对齐上32倍的时间开销里真正花在思考上的时间其实只占一小部分大头是智能体之间的通信和等待。每个智能体调用大模型都是串行的检索智能体跑完才能轮到推理智能体推理智能体跑完才能轮到校验智能体。如果校验不通过还要回退重跑。这种串行结构下单次大模型调用的延迟被放大了将近5倍。更隐蔽的是上下文膨胀带来的延迟增加。大模型的响应时间跟输入长度强相关输入从2000 Token涨到8000 Token响应时间可能从1.5秒涨到4秒。多智能体框架里每个智能体都要带上完整的历史上下文导致每次调用的输入都比单智能体方案长得多。我们统计过多智能体方案的平均单次调用输入长度是单智能体的3.8倍这直接推高了每次调用的耗时。还有一个容易被忽略的点智能体之间的确认和纠偏会触发额外的调用。校验智能体说这个答案可能不完整推理智能体就要重新生成重新生成后校验智能体再校验如果还不满意可能再来一轮。我们测试集里有大约18%的问题触发了至少一次重跑其中又有约6%触发了两次以上重跑。这些重跑在单智能体方案里根本不存在因为单智能体没有校验这个环节。2.3 Token消耗的13倍是怎么算出来的Token消耗的膨胀来自三个层面。第一层是角色提示词的固定开销。每个智能体都需要一套独立的系统提示词描述它的角色、职责、输出格式。检索智能体的提示词大约400 Token推理智能体大约600 Token校验智能体大约500 Token。这些提示词每次调用都要带上属于纯开销。第二层是上下文重复传递。检索智能体捞到的文档片段要传给推理智能体推理智能体生成的初步答案要传给校验智能体校验智能体的反馈又要传回推理智能体。同一份信息在多个智能体之间反复传递每次传递都算一次Token消耗。我们统计过一份平均800 Token的检索结果在整个链路里被传递了3.4次相当于多花了2700 Token。第三层是重跑带来的额外消耗。每次重跑都要重新走一遍推理和校验流程输入上下文还要再膨胀一轮。18%的重跑率意味着平均每5个问题就有1个要多花一轮完整调用的Token。这三层叠加起来13倍的Token消耗就不难理解了。对比维度单智能体方案多智能体方案倍数关系平均大模型调用次数1.0次4.7次4.7倍平均单次输入Token约2000约76003.8倍平均总Token消耗约2000约2600013倍平均端到端耗时约2.8秒约89秒32倍测试集准确率78.5%71.2%下降7.3个百分点3. 为什么三个臭皮匠反而把答案改错了3.1 校验智能体的过度纠偏现象多智能体方案准确率下降的最主要原因是校验智能体太敬业了。它的系统提示词里写着请仔细检查答案是否准确、完整、无遗漏结果它把很多本来正确的答案判成了需要补充。我们人工复核了所有被校验智能体打回重做的案例发现其中约62%的答案是原本正确的校验智能体提出的补充建议要么是无关紧要的细节要么是它自己理解错了。举个例子。用户问某个配置项的默认值是多少推理智能体从文档里找到了明确答案默认值是30秒校验智能体却说建议补充该配置项的生效范围说明。推理智能体老老实实去补充结果补充的内容里混进了另一个同名配置项的信息最终答案反而错了。单智能体方案直接给出30秒就完事了多智能体方案绕了一圈把对的改成了错的。这种过度纠偏的根源在于校验智能体没有知足的能力。人类专家校验时如果答案已经准确回答了问题就会说可以了。但大模型驱动的校验智能体它的训练目标里没有适可而止这一项它被设计成尽量找出问题于是它总能找出一些可以更好的地方。这些可以更好的改动在缺乏全局判断的情况下很容易引入新错误。3.2 智能体之间的信息衰减与语义漂移多智能体协作还有一个隐蔽的坑信息在传递过程中会衰减和漂移。检索智能体捞到的原始文档片段经过推理智能体的理解和转述再经过校验智能体的修正最后汇总出来的答案可能已经跟原始文档对不上了。我们做过一个对照实验让推理智能体直接输出它看到的检索结果原文再让它输出基于检索结果的答案对比两者与原始文档的语义相似度。结果发现推理智能体输出的答案与原始文档的相似度平均下降了约15%而经过校验智能体修正后的最终答案相似度又下降了约8%。也就是说每经过一个智能体信息就失真一次。三个智能体串下来最终答案跟原始文档的语义距离已经相当远了。这种衰减在需要精确引用原文的场景里特别致命。比如用户问某个接口的错误码1001代表什么原始文档写的是参数校验失败推理智能体可能转述成请求参数有问题校验智能体再改成输入数据格式错误最终答案虽然意思相近但已经偏离了文档的精确表述。如果用户是要拿这个答案去写代码或做配置这种偏差就可能造成实际问题。3.3 角色冲突与责任分散效应我们设计的三角色框架里检索智能体、推理智能体、校验智能体各自有独立的系统提示词但它们的知识来源是同一个底层模型。这意味着三个智能体其实共享同一套偏见和盲区。如果底层模型对某个领域的知识掌握得不好三个智能体都会在这个领域犯错而且它们会互相确认对方的错误。更麻烦的是责任分散效应。单智能体方案里如果答错了就是这一个模型的问题优化方向很明确。多智能体方案里答错了之后你很难定位到底是检索没捞到、推理没理解、还是校验改错了。我们排查失败案例时经常出现三个智能体互相甩锅的情况检索智能体说我捞到的文档是对的推理智能体说我是按文档写的校验智能体说我是按规则校验的。最后发现是校验规则本身有歧义但这条规则是三个智能体共同认可的。这种责任分散还会导致优化无从下手。单智能体方案准确率低你可以换模型、改提示词、加检索数据。多智能体方案准确率低你改检索智能体的提示词可能影响推理智能体的输入改校验智能体的规则可能影响整体流程的稳定性。牵一发而动全身调优成本远高于单智能体。4. 多智能体协作真正划算的三种场景4.1 任务本身可以并行拆解且子任务独立多智能体协作不是完全没用但它有明确的适用边界。第一种真正划算的场景是任务可以拆成多个相互独立的子任务且子任务之间不需要频繁通信。比如你要分析一份长文档让一个智能体负责提取所有日期一个负责提取所有人名一个负责提取所有金额。这三个子任务互不依赖可以并行跑最后合并结果。这种情况下多智能体的时间开销不会线性叠加Token消耗也主要是并行产生的没有反复传递的浪费。关键判断标准是子任务之间是否需要对齐。如果子任务各自独立产出结果最后简单合并就行那多智能体是划算的。如果子任务之间需要反复确认、互相修正那多智能体大概率会翻车。我们那个知识库问答系统就属于后者——检索、推理、校验三个环节高度耦合必须串行执行所以时间开销直接叠加了。4.2 需要多视角交叉验证且错误代价极高第二种场景是单次错误的代价极高值得用额外的时间和Token去换更高的可靠性。比如医疗诊断辅助、法律文书审核、金融风控决策这类场景答错的代价远大于多花几倍时间和Token。这时候多智能体协作的交叉验证机制就有价值了——让多个智能体独立给出答案再对比差异差异大的地方重点人工复核。但这里有个前提多个智能体必须是真正独立的。如果它们共享同一个底层模型、同一套提示词模板、同一个知识库那它们的独立只是形式上的错误会高度相关。真正有效的交叉验证需要智能体在模型、数据源、推理路径上都有差异。比如一个用大模型、一个用规则引擎、一个用检索增强这样它们的错误才不容易同时发生。4.3 任务复杂度超出单智能体上下文窗口第三种场景是任务需要的上下文长度超出了单智能体的窗口限制必须分而治之。比如你要分析一份几百页的技术文档单智能体塞不进去就可以让多个智能体各负责一部分分别提取关键信息最后汇总。这种情况下多智能体不是为了协作而是为了分片处理本质上是工程上的妥协。但这种场景下智能体之间的通信要尽量少。每个智能体独立处理自己的分片输出结构化结果最后由一个汇总环节合并。如果让智能体之间频繁传递原始文本Token消耗会爆炸而且信息衰减会很严重。我们的经验是分片处理时每个智能体只输出结构化摘要不传递原始文本这样能把Token消耗控制在可接受范围内。适用场景核心特征推荐架构预期开销并行独立子任务子任务无依赖可并行并行智能体结果合并时间接近单智能体Token约1.5到2倍高代价交叉验证错误代价极高需多视角独立智能体差异对比时间约3到5倍Token约4到6倍超长上下文分片单窗口塞不下需分片分片智能体结构化汇总时间约2到3倍Token约2到3倍串行协作推理环节耦合需反复对齐不推荐时间10倍以上Token10倍以上5. 如果非要用多智能体怎么把开销压下来5.1 用路由代替全量协作最常见的浪费是所有问题都走完整的多智能体流程。但实际上大部分问题单智能体就能搞定只有少数复杂问题才需要多智能体介入。我们后来改成了路由架构先用一个轻量级分类器判断问题复杂度简单问题直接走单智能体复杂问题才触发多智能体流程。这样整体平均开销降到了原来的三分之一左右。路由分类器不需要很复杂用一个小模型或者甚至规则引擎就能做。判断依据可以是问题是否涉及多个文档、是否需要多步推理、是否包含对比或因果类问法。我们实测下来大约70%的问题可以被路由到单智能体路径只有30%需要多智能体。这30%里又只有一部分真正需要完整的三角色协作很多只需要检索推理两个角色就够了。5.2 给智能体之间的通信瘦身多智能体Token消耗的大头是上下文重复传递。优化方向很明确每个智能体只传递必要信息不传完整历史。比如检索智能体给推理智能体传结果时不要传原始文档全文而是传结构化摘要——文档ID、关键段落、置信度。推理智能体给校验智能体传答案时不要传检索过程只传答案和引用来源。我们还做了一个优化给每个智能体的输出加长度限制。检索智能体的输出限制在500 Token以内推理智能体的输出限制在800 Token以内校验智能体的输出限制在300 Token以内。超过限制就截断或要求重新生成。这个简单的限制把Token消耗压下来了约40%而且因为强制智能体说重点信息衰减反而减轻了。5.3 设置止损机制避免无限重跑校验智能体的过度纠偏必须用机制约束。我们后来加了两条规则第一每个问题最多允许一次重跑第二次校验不管结果如何都直接输出第二校验智能体只能提出事实性错误的修正不能提出补充说明类的建议。这两条规则把重跑率从18%压到了4%左右准确率反而回升了。止损机制的核心逻辑是多智能体协作的收益递减很快但成本递增很快。第一轮校验可能能发现一些真问题第二轮、第三轮的边际收益几乎为零但每轮都要花掉完整的时间和Token。所以必须设一个硬性上限超过就强制结束。这个上限具体设多少要根据你的场景容忍度来定但我的经验是重跑次数不要超过一次。6. 几个容易踩的坑和我的实操心得6.1 不要用智能体数量衡量架构先进性我见过不少团队在方案评审时把我们用了5个智能体当成亮点来讲。这其实是个误区。智能体数量多不代表架构先进反而往往意味着通信开销大、调试难度高、故障点多。真正好的架构是用最少的智能体解决问题而不是用最多的智能体展示技术。我们后来把三角色精简成了两角色去掉校验智能体把校验逻辑合并到推理智能体的提示词里效果反而更好。6.2 先跑通单智能体基线再考虑多智能体这是我最想强调的一点如果你连单智能体方案都没调优到极限就不要碰多智能体。我们当时犯的错误就是单智能体方案只跑了两周就急着上多智能体结果多智能体方案的问题里有一大半其实是单智能体方案就存在的——检索不准、提示词有歧义、知识库覆盖不全。这些问题在多智能体框架里被放大了但根源不在架构在基础工作没做扎实。正确的顺序应该是先把单智能体的检索、提示词、知识库都调到最优记录下准确率和开销基线。然后针对单智能体确实搞不定的那部分问题再考虑用多智能体补充。如果单智能体已经能解决80%的问题多智能体只需要处理剩下的20%整体开销就可控了。6.3 监控要细到每个智能体的调用多智能体方案的调试难度远高于单智能体因为出问题时你很难定位是哪个环节的锅。我们后来加了一套细粒度监控每个智能体的每次调用都记录输入Token、输出Token、耗时、是否触发重跑。这样出问题时能快速定位是检索没捞到、推理没理解、还是校验改错了。没有这套监控调优基本靠猜。监控数据还能帮你发现一些反直觉的现象。比如我们通过监控发现校验智能体的耗时跟输入长度几乎无关而是跟它是否决定打回重做强相关——决定打回时它要生成详细的修正建议耗时是直接通过的3倍。这个发现让我们优化了校验智能体的输出格式要求它打回时只输出打回原因代码不输出详细建议耗时立刻降下来了。6.4 多智能体不是免费的可靠性提升最后一个心得多智能体协作带来的可靠性提升往往被它引入的新故障模式抵消了。单智能体方案只有一种故障模式模型答错了。多智能体方案至少有四种检索智能体没捞到、推理智能体理解偏了、校验智能体改错了、智能体之间通信丢失了。每多一个智能体就多一种故障模式而每种故障模式都需要额外的监控和容错机制来覆盖。所以我的建议是除非你的场景明确落在前面说的三种适用场景里否则优先考虑单智能体方案。单智能体方案简单、快、便宜、好调试而且随着底层模型能力的提升它的上限还在不断抬高。多智能体协作是一个用复杂度换特定能力的工具不是更先进的代名词。用之前先算清楚账多花的时间和Token换来的可靠性提升到底值不值。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
