★ FEATURED ARTICLE 多智能体协作这几年被聊得很热身边不少团队都在往系统里堆角色——规划者、执行者、审查者、优化者、记录员、协调员……光看名单确实很唬人。但我自己做完一个项目之后得出了一个不太主流的结论多智能体协作的强弱跟角色数量真没有正相关关系很多时候角色越多协作反而越差。这不是说多智能体不行而是说“角色多”这件事本身往往掩盖了协作机制上的偷懒。你以为是分工细化带来了专业度实际上只是把本该由流程解决的问题转移成了角色之间的沟通成本。这篇文章我会把自己踩过的坑、做的对比实验、最后沉淀下来的设计原则完整讲一遍适合正在做多智能体编排、或者准备把单体Agent拆成多角色协作的开发者参考。1. 六角色编排上线后我亲眼看着协作一步步崩掉1.1 我当时是怎么设计这套角色的年初接了一个任务要做一套内部业务流程分析系统输入是一堆非结构化的业务文档输出是结构化的流程图谱和异常风险点。我先用单体Agent跑了一版效果尚可但领导层觉得“一个Agent包打天下”不够专业于是我改成多智能体架构。第一版设计非常“标准”我照着各种论文和框架的推荐一口气设计了六个角色。文档解析Agent负责把PDF、Word、扫描件里的文字抽取出来做初步清洗。知识补充Agent负责补充领域背景知识给后续角色提供上下文。流程识别Agent负责从文本中识别出业务环节和流转关系。风险分析Agent负责对照规则库找出流程中的异常和风险点。报告撰写Agent负责把前面所有结论整理成最终报告。质量审查Agent负责检查最终报告是否遗漏信息。设计时我觉得自己很严谨每个角色有独立的系统提示词有独立的输出字段角色之间通过消息队列传数据。流程图我画得漂漂亮亮每个箭头都有来路。说实话光看架构图确实比单体Agent显得专业得多。1.2 变量失控的那几个晚上真正跑起来之后问题开始一个个冒出来。首先是上下文爆炸。文档解析Agent把原始文档内容解析出来后会完整传递给知识补充Agent知识补充Agent看完之后又要把自己的理解附加上去传给流程识别Agent。每个环节都在原文基础上加一层自己的解读。等传到流程识别Agent手里时输入长度已经膨胀了三四倍。商用大模型的上下文窗口是有限的而且越长的上下文信息密度反而越低关键业务词会被淹没在一大堆“我认为”“根据以上内容”里。然后是重复劳动。流程识别Agent识别出的流程节点风险分析Agent会重新读一遍原始文档再去对照规则库——它不信任前面角色的输出。质量审查Agent呢又会再次回到原始文档做交叉验证。明明是一个流水线结果每个角色都在重复做上游已经做过的事真正产生的增量信息非常有限。最让人崩溃的是角色之间的互相等待。按照我的设计质量审查Agent发现问题后会把报告退回给报告撰写Agent修改。但报告撰写Agent并不知道风险分析Agent当时的判断依据只能对着退回意见猜。改完提交上去质量审查Agent发现新问题和旧问题在不同位置冲突又打回去。两个Agent就这么来回拉锯一轮任务跑了四个小时最终报告的质量反而不如单体Agent跑十五分钟的结果。1.3 回归测试看清的事实角色量与效果呈反比我做了回归测试同一个任务集分别用单体Agent、两角色版本、六角色版本跑。结果很打脸六角色版本在流程识别准确率、风险点召回率两个核心指标上都明显低于两角色版本而token消耗是后者的4.7倍平均任务耗时是5.8倍。两角色版本我当时是怎么设计的其实就是“执行者 审查者”的循环一个角色负责分析和输出另一个角色负责独立审视结果、提出问题问题再回到执行者手里做针对性修改。这个结构简单到不起眼但它恰恰没有浪费任何信息。这次经历让我意识到多智能体协作的设计重点根本不在角色分工表有多漂亮而在于角色之间的信息是怎么流动的、职责边界是不是真的清晰、每个角色的存在是否真的降低了系统的整体复杂度。2. 多角色反而拖慢协作的底层机制2.1 上下文被挤占角色失去了全局视野大模型Agent的所有能力本质上都建立在上下文之上。所谓的角色不过是一个特殊的系统提示词加上一套输入输出约束。当你把任务拆给多个角色时每个角色的上下文窗口里必须有足够的信息来支撑它的判断。问题在于角色数量一多每个角色为了保证自己不犯错都会倾向于把尽可能多的原始信息塞进上下文里。理由也很朴素“我怕漏掉关键信息。”于是同一个任务背景下N个角色各自维护着同一份超大上下文总消耗随角色数量接近线性增长甚至超线性增长。我当时的六角色系统里知识补充Agent为了“全面”把业务背景资料全量塞进提示词里导致流程识别Agent接下来要处理的上下文里真正跟流程识别相关的信息占比极低。你可以把上下文窗口想象成一张书桌桌子上堆了六个人的参考资料真正要用的那张图纸反而被埋在最底下。角色数量越多书桌越乱每个角色找到自己要的东西就越难。2.2 职责重叠区无止境的互相踢皮球理论上角色边界应该在设计时划清楚。但真实业务场景里角色的职责天然是有重叠的。比如“流程识别”和“风险分析”识别流程环节时需要关注异常分支分析风险时又必须先理解流程结构。我在系统提示词里尽量区分了二者的侧重点可一旦输入文本复杂起来两个角色就会做出大量重叠分析。更麻烦的是职责重叠会诱发一种“防御性冗余”。风险分析Agent不信任流程识别Agent的结论会重新从原始文本推导流程流程识别Agent又觉得自己才是流程权威看见风险分析Agent输出里写了流程结论还会在下一轮任务启动时提出质疑。轻则重复劳动重则陷入无限循环。这种问题在设计文档里几乎看不出来只会在真实运行时暴露两个角色开始互相否定对方输出或者在对方的输出基础上做大量无效修正。我当时看消息日志发现同一个流程节点被不同角色反复提及了二十多次而真正新增的有效信息只有最开始那一次。2.3 消息链路变长每个环节都在改别人的话三个及以上角色协作时消息不会老老实实从第1个传到第N个。实际运行时会发生大量跨环节的消息回调、消息复制和结论修正。每个角色在把消息往下传之前都会忍不住“整理”一下内容——把上游的表述改成自己认为更准确的说法。这就像公司里传话游戏。信息经过角色A的解释到了角色B那里变成B的理解B再传给角色C时又带上了B的立场。等角色C看到信息时原始事实已经裹了好几层各角色的主观加工。Agent的生成本身就带有概率性每一层加工都在增加信息震荡的幅度。角色越多链条越长信息的真实度衰减越严重。我后来翻看一次失败任务的完整消息记录看到报告撰写Agent拿到的流程清单和文档解析Agent最初输出的原始清单在细节上已经对不上了。中间每个角色都“顺手修正”了一点点累积下来一个本来准确的流程节点被改到完全偏离原文。所以多角色协作弱不是单个角色能力不行而是信息在这条长链路上被反复污染。这是角色数量增加带来的结构性代价不是靠换更好的模型就能解决的。3. 用同一组任务对角色多和角色少做了次对比3.1 实验设定任务池、评估口径与角色配置受挫之后我没有直接删角色而是先做了一个对照实验把决策依据落到数据上。实验对象就是我负责的那套业务文档分析系统任务池选了40个标准业务文档覆盖了流程识别、风险发现、报告生成三类核心诉求。我对比了三种配置配置角色构成角色数量协作方式配置A无角色单Agent直接输出0一次性生成配置B执行者 审查者2执行后审查审查意见回馈后修订配置C解析者 知识补充 流程识别 风险分析 报告撰写 质量审查6链式传递 审查回退评估指标我定成了四个流程识别准确率提取的节点是否和人工标注一致、风险点召回率标注风险是否被系统找出、单任务平均耗时从提交到最终输出的墙钟时间、总token消耗所有角色调用大模型接口的token总和。3.2 量化结果效果、延迟与成本三项对比结果整理成表格之后结论非常直接。配置流程识别准确率风险点召回率单任务平均耗时总token消耗配置A单Agent76%68%14分钟18万配置B两角色84%79%22分钟26万配置C六角色79%71%81分钟123万配置C在准确率和召回率上不仅没有超过配置B甚至还比配置B低了5个和8个百分点。配置A虽然准确率最低但它的成本和延迟优势巨大。配置B是唯一一个在效果指标上“正收益”的方案。六角色版本的耗时暴涨核心原因不是模型推理慢而是大量的无效来回角色之间传递超大上下文、重复分析、审查回退每一轮都是完整的模型调用。83分钟里有接近一半花在了流程识别Agent和质量审查Agent之间的拉锯上。3.3 翻看对话记录后看到最扎心的两组对话数据只能说明结果真正让我下定决心重构的是翻看对话日志时看到的几段内容。第一段发生在流程识别Agent和风险分析Agent之间。流程识别Agent输出了一份包含六个环节的流程清单风险分析Agent没有直接使用这份清单而是先把原文重新读了一遍然后自己重新梳理出五个环节并且标注“此处与流程识别结果存在差异建议复核”。最终报告里两个版本并存报告撰写Agent不知道听谁的只能两个都写进去。第二段发生在质量审查Agent和报告撰写Agent之间。审查者说“风险部分缺少对供应商环节的描述”报告撰写Agent就把供应商环节的相关原文大段复制进报告。审查者又说“这段内容与流程识别结论矛盾”报告撰写Agent又把那段删掉。这是一场没有共同事实基础的辩论两个角色各自拿着自己对文档的理解在交锋谁也没法说服谁。看到这些记录之后我彻底明白了一个道理**角色多并不会自动产生分工红利分工红利只存在于信息被有效传递、且每个角色确实在做增量工作的系统中。**如果新增角色带来的主要是重复分析和信息折损那么它就是在给系统增加负收益。4. 收敛角色的实操方法和边界判断4.1 先划清决策链谁在输入谁在输出谁在做决定重构第一步我不是去数角色数量而是画了一张新的协作关系图。这张图不画角色分工只画数据流原始输入进来经过哪些处理步骤每一步的输出是什么最终谁对输出负责。你会发现很多角色的存在感其实是靠“参与感”撑起来的。知识补充Agent虽然加了背景知识但流程识别Agent真正需要的只是经过清洗的原始文本和几条明确的识别规则。知识补充Agent存在的意义完全可以通过在系统提示词里增加一小段领域速览来实现。我的做法是把六个角色按职责重新归堆。文档解析和知识补充合并成“输入准备”流程识别和风险分析合并成“业务分析”报告撰写和质量审查合并成“输出把关”。职责本身没有少还是那三类核心工作但角色从六个变成了三个信息传递链路缩短了一半。4.2 合并角色而非删除职责很多人一说精简角色就觉得是砍功能其实是不对的。我强调的是合并不是删除。三组职责一个都不能少但实现方式可以不同。比如“知识补充”这项职责我并没有让一个专门角色去背背景知识而是把领域知识压缩成三千字左右的速览直接放进做业务分析的Agent的系统提示词里。事实证明效果不亚于单独调一个角色来传话。这就是用上下文替代通讯的例子。“质量审查”这项职责我倒是保住了但要变成另一个角色。因为审查者和执行者如果共用同一个上下文和同一套提示词会陷入自我确认偏差——自己检查自己的输出很难发现真正的逻辑漏洞。必须有一个独立的审查Agent站在对结果负责的视角上提反向意见。所以我的建议是先列出所有必须存在的职责再看哪些职责可以通过上下文、流程状态、输出约束等“机制”实现只有那些真正需要独立立场、独立上下文、独立决策的职责才用独立角色承载。4.3 新增角色的判断标准是否会减少全局往返次数我给自己定了一条硬标准之后每次有人提议加角色我都会先问三个问题这个角色提供的增量信息能不能直接写进现有某个角色的系统提示词里如果能就不加。这个角色的输出会不会被下游角色重新验证一遍如果需要重新验证说明它没有建立信任加了就是负资产。引入这个角色后整个任务的消息往返次数是变少还是变多只有显著变少才值得考虑。这三个问题过滤掉了绝大多数“为加而加”的角色。真实的协作系统中很多角色建议的出发点都是“某某事没人专门负责”但归属责任和独立角色是两码事。没人专门负责可以靠标准化流程、检查清单、输出模板来解决不一定需要再养一个吃上下文的Agent。我还把一个经验写进了团队文档**角色的数量应该等于“不得不独立决策的立场数”而不是“职责清单的行数”。**多智能体不是公司组织架构表每一个角色都要消耗上下文、消息和信任成本它的存在必须换来一个不可替代的独立决策能力。5. 角色少的系统又是靠什么撑住协作的5.1 用结构化协议替代角色间的人类式寒暄角色数量收敛之后我着重优化了角色之间的沟通方式。之前六个角色传递消息用的是自然语言长文本每个角色都要在前文基础上重新理解一遍理解偏差在所难免。后来我全部改成结构化协议。每个角色对外只输出一个固定格式的JSON包含四个字段结论、置信度、依据片段索引、待确认问题。下游角色拿到这个JSON后不需要读大段推理过程只需要提取结论和依据索引自己去原文对应位置做针对性验证即可。结构化协议的核心好处是减少了自然语言固有的模糊性。同一句话六个角色可能有六种理解但同一份JSON Schema所有角色都必须按字段填。你在协议里界定好“依据片段索引”的格式是文档段落号列表下游角色就不会再为“依据到底在第几段”扯皮。5.2 让关键信息走共享状态而不是靠传话这算是我这次重构里最值钱的一步。之前所有中间结果都是靠角色之间一条条消息传过去的消息就变成了事实的唯一载体谁传错、谁漏传事实就被污染。后来我引入了一个共享工作区本质是一份可并发读写的全局状态文档。所有角色在开始工作前先到共享工作区读取事实基线工作完成后只更新自己负责的那部分字段。下游角色需要上游结论时不再接收上游角色的“转述”而是直接读取共享工作区里的标准结论。这个设计让我彻底摆脱了传话游戏。共享工作区里的流程清单是流程识别Agent写的原始版本任何角色都不会去修改它。风险分析Agent如果发现需要补充流程细节只能在“补充说明”字段里追加记录而不是直接改写原始结论。这样即使出现分歧系统里也永远存在一个可信的事实基线可以回溯。我把这套机制类比成工地管理施工队不会靠口头传话来确认设计图所有人盯着的都是挂在项目部墙上的那一张蓝图。Agent协作也应该这样信息集中存放角色各取所需而不是每个人都抱着自己那一份被改过的复印本讨论。5.3 给每个角色明确的反悔与交接规则多角色协作还有一个很容易被忽视的细节角色之间如果发生意见冲突冲突升级规则是什么。之前的六角色系统里质量审查Agent一打回报告撰写Agent就盲目改改完还是错两个角色陷入无意义循环。重构后我给每一类协作冲突都定义了明确的交接规则。审查Agent打回报告时必须在结构化协议里写明“具体问题类型”和“可执行修改建议”执行Agent只处理清单里列出的修改点。如果执行Agent认为建议本身有问题不允许直接改回去而是把自己的反驳理由写进“争议登记表”提请更高层的汇总规则处理。更关键的是给每个角色加了一个“终止条件”当某条消息被同一角色处理超过三轮时系统不再让它们继续对话直接把目前信息汇总到最终输出里由人工兜底。这个兜底机制在实际运行中很少触发但它从根上杜绝了Agent之间无限拉扯。6. 几次迭代后我重新相信了多智能体协作的价值重构后的系统角色数量从六个降到三个核心指标反而全面改善。流程识别准确率从79%提升到86%风险点召回率从71%提升到81%单任务平均耗时从81分钟降到29分钟总token消耗从123万降到41万。同样的任务量效果提升、成本大降。我尝试过把角色继续压缩到两个也就是“业务分析 审查把关”的结构发现准确率还能再往上走一点但报告的可读性和解释性会下降。因为独立报告的撰稿视角还是有价值的它能把分析结论转述成更通顺的文档。所以最终我停在三个角色输入准备、业务分析、报告审查。整个过程走下来我最深刻的体会是角色数量从来不是多智能体协作的追求目标信息质量才是。一个角色设计得好不好要看它是否真的在为系统提供增量信息是否真的让某个决策立场独立化了而不是看它的名字多响亮、名单多齐全。如果你现在也在设计多智能体系统我的建议很简单先把角色列表贴到墙上一个角色一个角色地问它到底为什么必须是一个角色如果答案不清晰那就把它合并掉。协作能力的强弱永远取决于信息流动的效率而不是那份看起来很像样的分工表。
阅读完成 · 觉得有帮助？
