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，换来的可靠性提升，到底值不值。