多智能体协同初探：从单Agent瓶颈到三Agent闭环实操

多智能体协同这个话题最近半年在各种技术社区和分享会上出现的频率居高不下。我一开始并不以为意觉得无非是“把一个任务切成几段让模型分别跑”直到自己动手试了一轮才发现里面的门道比想象中多得多。这篇内容是我从零开始的“初探”记录先讲为什么单Agent撑不住复杂任务再拆解多Agent协作里的角色、协议和流程设计接着展示一个最小可运行的三Agent闭环Demo最后聊聊我如何把这些探索整理成一份34页可编辑PPT以及掉进去过的那些坑。如果你正打算研究大模型驱动的多智能体协同或者要准备一份相关主题的内部分享可以直接照着我的路径走一遍。这篇东西对新手友好逐行都能落地对有基础的人也值得扫一眼至少能帮你少碰几次“Agent疯狂抬杠”的鬼事。1. 为什么我会盯上多智能体协同1.1 单个大模型的瓶颈比想象中更明显很多人最开始的想法很简单现在的模型上下文已经很大了一个模型什么都能干为什么还要搞多Agent我起初也这么想但实际一测单模型处理复杂任务的问题就全冒出来了。第一个是上下文窗口的物理限制。上下文再大也有上限而真实任务里要堆进去的信息量增长得更快。比如让模型写一份包含市场背景、竞品分析、预算方案、风险预案的完整商业计划开头塞进去的几十页资料还没读完后面又要求参考另一批数据模型很容易顾此失彼读到后面忘了前面。第二个是职责混杂带来的指令冲突。让同一个模型既负责发散创意又负责严格挑刺它会“精神分裂”。你要求它“大胆想象”它写出来的东西里全是免责声明你要求它“严谨复核”它又开始补充各种新点子。说到底大模型的输出是被系统提示词整体塑造的把相互矛盾的目标塞进同一个上下文最后只能得到一种中庸且模糊的结果。第三个是错误自查能力很弱。单个Agent产生幻觉之后很难自己发现问题。它写出来的论据缺乏出处你再问它“这个数据可靠吗”它很可能不但不承认还会编一个出处来圆场。没有外部检查者这种错误就会一路带到最终结果里。这些瓶颈合在一起指向一个结论复杂任务不该由单个模型“一把梭”而是要把任务拆开交给多个有独立上下文、独立职责的模型实例去协作完成。这正是多智能体协同存在的理由。1.2 协作思路从哪来把软件工程的老经验搬过来多智能体协同并不是什么玄学它的底层思路在软件工程里早就是标准答案了模块化分工、单一职责原则、代码审查、持续集成。一个系统如果所有功能都写在一个几万行的大文件里没人敢维护但如果拆成多个模块每个模块边界清晰、接口明确出了问题可以单独替换整体迭代速度反而快得多。大模型让这套理念有了新的落地形态。传统软件模块是“函数和类”而多智能体系统里一个Agent本质上是一个被提示词约束行为方式的模型调用单元。它的“函数签名”就是输入输出的消息格式它的“内部逻辑”就是模型在给定上下文里的推理过程。你可以把一个Agent设计成信息收集器把另一个设计成反对者把第三个设计成最终决策者让它们像团队一样分工配合。组织管理学里的PDCA循环计划-执行-检查-处理、RACI责任矩阵谁负责、谁批准、咨询谁、通知谁放在多智能体系统里同样成立。我设计的多数协作流程本质上就是把PDCA翻译成Agent之间的消息流转。先有规划Agent产出步骤再有执行Agent干活接着有审查Agent提意见最后由主控Agent决定是否返工。这也是我这次初探最核心的体会不要凭空发明架构多Agent的设计本质上是把已经被验证过的协作方法论往模型世界里搬。2. 角色、分工与协作协议动手前的必修课2.1 角色定义给每个Agent划定行为边界很多初学者的第一个错误是把Agent的角色提示词写得太泛。比如“你是一个聪明的助手”那和直接调模型有什么区别角色定义的作用是给模型划定一个明确的行为边界让它知道自己在什么语境下思考、对什么负责、不碰什么。我在设计Agent时通常会为每个角色写清楚五件事身份、目标、输入、输出、边界。以我这次做的“活动方案三Agent”小实验为例。我设计了三个角色策划Agent负责输出活动创意、流程和执行要点要求天马行空但有可落地性。系统提示词里会明确写“你不是执行者你只输出方案”避免它开始算预算。预算Agent只负责根据方案列出成本项、给出匡算并标记超出阈值的地方。它的边界是“不评价创意好坏只评价钱够不够”。风控Agent负责挑毛病找法律合规与执行风险。它的边界是“只指出问题不直接改方案”。分得越清楚模型越不容易跑偏。反过来如果我在同一个提示词里既要求“大胆想创意”又要求“严谨控成本”模型最后一定会产出两边不讨好的四不像。这也是角色拆分的意义不是把任务切换到不同模型上就算完而是让每个模型可以心无旁骛地只用一个视角想问题。提示词里最好再带一个“输出格式约束”比如“最终回复必须包含建议方案列表、每条理由、风险点三个部分”。这样后面写解析代码时才能拿到干净字段Agent之间的信息才能被程序自动接手。2.2 协作范式串行、并行、群聊与反思角色定好之后下一步是设计它们之间的协作方式。我实际摸过的范式有这么几类各有各的适用场景。首先是串行流水线。就是A做完给BB做完给C像工厂生产线一样。它的好处是结构清晰每一步的输入输出都很明确非常容易调试坏处是总耗时等于所有环节耗时之和而且前面环节一旦出错后面全都跟着错。适合流程稳定、前置依赖强的任务比如“资料收集 → 分析整理 → 报告撰写”这种。其次是并行分组类似Map-Reduce。把一个大任务按维度切成几块分给多个Agent同时干最后再汇聚。比如分析一家公司时可以并行创建行业趋势Agent、财务状况Agent、竞争格局Agent各自分析完后再由一个汇总Agent合成长报告。好处是快坏处是汇总Agent成本高而且分块之间的信息割裂会导致结论缺少全局视角。然后是群聊/头脑风暴模式。多个Agent在共享会话里来回发言互相补充和质疑。这种模式在探索开放问题时很出彩问题不够聚焦时则极其容易跑偏常常聊了十几轮还在原地打转。我在实验里给群聊套了“主持人Agent”的壳由它来控制收敛节奏效果才稍微稳定下来。最后是反思/否决模式。由一个执行Agent产出结果另一个审查Agent负责挑错并给出修改意见执行Agent根据意见重做往复循环。这是对结果质量最有帮助的模式能显著减少幻觉和论据缺失的问题。代价是成本翻倍、时间翻倍而且如果审查Agent一直不点头两边会陷入无限循环所以我都会强制设置最大轮次上限。2.3 消息协议协作时传什么、什么时候传角色和范式定了还差一块地基消息协议。没有协议Agent之间就是鸡同鸭讲靠自然语言传来传去解析全靠运气。我在Demo里定义了一套简单的结构化消息类似于一个极简状态机。每条消息都包含五个字段任务ID、消息类型、发送方、接收方、内容负载。消息类型只有四个任务请求、执行结果、审查意见、完成通知。Agent从收件箱拿到消息做完自己的事再往外发下一条。这个设计相当于给每个Agent一个稳定的接口。无论内部怎么推理对外只知道“我收到了什么该回复什么”。就像公司里跨部门协作别人不关心你部门内部怎么干活只关心你交付的文档是否符合模板。结构化程度越高程序越容易接管流程控制Agent本身只需要专注于生成内容。而且这种协议天然支持前面说的串行、并行等多种模式——同一套消息格式搭配不同的路由策略就是不同的协作范式。协议才是真正让多智能体从“几个模型连在一起聊天”升级为“一个可编程协作系统”的关键。3. 实操记录搭一个能跑的Agent闭环Demo3.1 选一个合适的最小任务理论讲再多不如跑通一个最小Demo来得实在。我选的任务是“市场调研简报生成”。这个任务够复杂单Agent做容易泛泛而谈又够独立不需要接外部系统用大模型自身能力就能闭环非常适合第一次尝试。我设了三个Agent信息萃取Agent接收一堆原始纪要文档和零散数据提炼成结构化的要点列表并标注每条信息的来源。趋势研判Agent拿到要点列表后进行行业趋势分析和结论输出给出判断依据。质量复核Agent最后检查报告里每一个结论是否有依据把“依据不足”和“疑似过度推断”的地方逐一标注出来反馈给趋势研判Agent修改。三个Agent串起来形成“萃取 → 研判 → 复核 → 修改”的小回路。设计成串行的原因也很简单首次跑通流程调试成本最低。后面再想加并行或群聊都是在这次地基上增瓦。3.2 核心代码与流转过程我这次没有用任何现成的Agent编排框架直接用统一的LLM接口手写了一个极简调度逻辑。这样做的最大好处是能把每一步的输入输出都看得清清楚楚框架的黑盒开销暂时不需要引入。import json class Agent: def __init__(self, name, system_prompt): self.name name self.system_prompt system_prompt self.history [{role: system, content: system_prompt}] def run(self, task_payload: str) - str: messages self.history [ {role: user, content: f当前任务\n{task_payload}\n\n请严格按照协议输出。} ] # 这里实际走的是统一的大模型API网关按你的项目渠道配置即可 reply_text call_llm(messages) self.history.append({role: user, content: task_payload}) self.history.append({role: assistant, content: reply_text}) return reply_text.replace(json, ).replace(, ).strip()三个Agent的提示词各有侧重。信息萃取Agent的系统提示词里强调“你是信息整理者不得添加原文之外的内容”趋势研判Agent强调“你是行业分析师结论必须包含依据”质量复核Agent强调“你是审查者只输出问题清单与修改建议不重写分析”。主控逻辑负责把上一个Agent的输出解析成结构化字典再装进下一个Agent的输入里最后把复核意见反馈给研判Agent做一轮修改extract_agent Agent(extractor, EXTRACT_PROMPT) analyze_agent Agent(analyst, ANALYZE_PROMPT) review_agent Agent(reviewer, REVIEW_PROMPT) raw_text open(./meeting_notes.txt, encodingutf-8).read() points json.loads(extract_agent.run(raw_text)) draft analyze_agent.run(json.dumps(points, ensure_asciiFalse)) review json.loads(review_agent.run(draft)) if review[need_revision]: revised_task ( 上一版报告如下\n draft \n复核意见如下\n json.dumps(review[issues], ensure_asciiFalse) \n请根据意见修改保留有价值的结论补齐依据删除无依据的推断。 ) final_report analyze_agent.run(revised_task) else: final_report draft跑起来之后整个链路比我预想中顺。萃取阶段会忠实提炼出原始材料里的关键数字研判阶段会自动补充一些背景性的行业表述复核阶段经常会抓住一些“这个结论似乎只参考了一家公司样本”之类的漏洞。因为加了修改回路最终报告的质量比第一次草稿明显扎实。需要提一句信息萃取Agent给研判Agent的是结构化JSON而不是大段自然语言。这一步非常关键因为JSON字段清晰研判Agent不用从一大段话里找重点生成质量会稳定很多。3.3 实测数据成本、耗时与质量感受每个环节的开销我大概记录了一下。萃取阶段一次调用做了摘要消耗的输入输出Token大约几千研判阶段输出长报告Token消耗明显上升复核阶段是纯输出型任务输出Token也不少。加上可能触发的一轮修改整个流程下来一次完整任务的总Token数大概是单Agent直接写同长度报告的三倍左右。耗时也因为多次串行调用而变成了数倍。听完这个数字先别被吓到多智能体本来就不是为了省Token设计的而是用更多计算换取更稳定的质量。如果任务本身简单单Agent一把梭又便宜又快真正需要多Agent的是“质量要求高、容错率低、信息量大”的场景。所以我后来在分享PPT里也特别强调了一句话不要所有任务都上多Agent先想清楚你的质量瓶颈到底是什么。为了验证这个判断我同一份原始材料做了对比实验。一边让单个模型直接写市场简报另一边跑三Agent协作流程各生成五份请同事盲评。在信息完整度、论据充分性、结构清晰度、可读性、合规性五个维度里协作流程在信息完整度和论据充分性上优势明显可读性上略低主要因为分工后行文风格会带一点拼接感。这个结果也说明多Agent不是银弹它解决的是主问题同时也会引入新问题。4. 34页可编辑PPT如何把探索心得讲成完整故事4.1 页数结构哪部分讲几页为什么探完多Agent光自己会跑还不算完我准备把过程整理成一次内部分享。分享载体就是一份34页的可编辑PPT。为什么是34页因为一场45分钟左右的分享按平均1分多钟一页来估算30到35页正好能讲满又不拖沓页数再多听众就开始走神。我的核心思路是“先讲为什么再讲怎么做最后讲翻车记录”。PPT不是论文堆砌而是帮听众建立认知阶梯。34页的分配我做了如下规划页码区间模块页数内容重点1-5背景与动机5单Agent的三大瓶颈、多Agent的价值假设6-9关键概念4Agent、协同、结构化消息、协作范式10-15五种协作模式6每种模式一页配一个适用场景和反面案例16-24实际操作案例9角色定义、代码流程、运行链路、效果对比25-30成本、质量与边界6Token消耗数据、质量对比表、不要滥用多Agent31-34总结、坑与扩展4教训清单、后续研究方向、QA准备页这样安排的逻辑是前面11页帮听众建立“我们为什么要讨论这件事”的共识中间15页给出方法和实证是整场分享的主体最后4页做收束。页数多不意味着每页都塞满字。很多页我只放一张架构图和一个结论句现场靠嘴讲细节PPT只是提词器。4.2 可编辑与演示设计的实操细节“可编辑PPT”这几个字其实比很多人想象中难。真正的可编辑不是“这页上的文字还能改”而是所有元素——图形、连线、图标、图表——都能被使用者自由拖动和修改。所以我做PPT时给自己定了几个硬规矩。第一所有架构图必须用PPT自带的形状绘制不做任何截图。截图虽然省事但别人拿到文件后改不动只能整图替换。我用圆角矩形代表Agent用带箭头的连接线代表消息流用不同填充色区分角色类型、执行流程和审查流程这样听者一眼就能看懂分工。第二用母版统一字体、配色和版式。做这种技术型分享PPT我倾向保守配色深蓝色配灰色一张页面不超过三种颜色。母版里定好标题栏位置、页码位置和内容边距后面新建页面只需套版式不用每页重新调位置后期改内容也不会版式错乱。第三页面只放结论备注放解释。我在每一页的备注栏里写满了讲稿要点比如这页为什么要讲、演示时该停顿几秒、这个图怎么画出来的。这样既能保证PPT在视觉上干净清爽又能让拿到文件的人在没有我讲解时也能看懂每一页的重点。第四留一个“附录”页放参考文档。分享类PPT的常规做法是吧参考资料放在结尾但我更建议单独设一个非讲述型附录页把值得深挖的文章名称和检索关键词列出来。这样做的好处是真正感兴趣的人知道从哪个方向继续查同时主流程不会被参考资料打断。5. 常见问题与排查技巧实录5.1 Agent互相“抬杠”改到停不下来我真正跑协作流程时遇到的第一个大坑是审查Agent和研判Agent进入循环。审查Agent每轮都提出新问题研判Agent改完一版后审查Agent又基于同样的标准挑出新毛病如此往复调用成本直线上升结果却原地踏步。排查后发现两个原因。一是审查Agent没有“验收通过”的终止条件它只知道挑刺不知道什么时候算合格二是修改任务里没有告知“这是第几轮修改还剩几轮机会”Agent不知道资源有限就会无限追求完美。解决方式很直接给审查Agent的输出加一个硬性字段“是否通过”只有“通过”或“不通过”两个值同时把复审最大轮次设为3次超过次数后即使审查Agent仍不通过也强制执行当前最新版本并把审查意见记录为一个待人工处理事项。这一步之后循环问题基本绝迹。加一个轮次上限是最简单也最有效的止损手段。5.2 上下文窗口爆掉还碰到过一次上下文爆掉的问题。那是因为我把每个Agent的完整对话历史都一直保存着串行流程跑了几轮后历史消息越积越多导致调用直接报错。解决思路是给Agent引入“最小上下文”原则。每个Agent不需要感知全流程的完整历史只需要拿到它的必要输入。比如研判Agent只需要看萃取Agent输出的要点JSON不需要看原始文档审查Agent只需要看当前报告和此前的修改意见不需要看初版萃取结果。把上下文控制到最小既省Token又能提升模型对关键信息的注意力。具体做法是每个Agent的history只保留最近一轮关键会话历史数据另外存到外部存储里。需要追溯时再去查而不是一股脑塞给模型。5.3 结构化输出解析失败结构化输出看起来简单实际操作中翻车概率相当高。模型偶尔会在JSON前后多加几个反引号偶尔会写注释偶尔某个字段少个引号程序一解析就抛异常。我最后用了“格式强调 后处理兜底”的双保险。格式强调是在每个Agent的系统提示词里加上明确的输出格式说明与JSON示例让模型照着填后处理是在解析前统一去头去尾、剥掉代码块标记再尝试解析。如果仍然失败就重试一次重试时告诉模型上一次解析失败。这个策略能把解析成功率拉高到离谱的水平几乎不会再中断流程。5.4 成本预算失控多Agent协作好用但它烧钱也是真的。我前面提到过一个指标同任务Token消耗量约为单Agent的三倍。如果每个环节都用最强模型这个数字还会继续膨胀。我的成本控制三板斧很简单。第一不同难度的任务用不同规格的模型信息萃取这种机械整理的活用小模型即可研判和审查再上强模型。第二开启缓存策略一模一样的输入给缓存结果能省下大笔输入Token。第三设置单任务总调用上限超过就切断并报警。多Agent系统最容易失控的点不是单次调用贵而是循环次数没有刹车所以总预算的兜底必须做。5.5 质量评估只凭感觉最后一个坑是质量评估几乎没有客观标准。我在Demo阶段靠肉眼判断“改过了确实好一点”但说不清到底好在哪里。后来给同事盲评才稍微找到了量化方法。我的建议是建立一个最小验证集选五到十道代表性任务固定一份输入和一套评估维度每次调整角色提示词或协作流程后先在这套集子上批量跑一遍对比各维度得分。即使没有自动化评测手工对比也能很快暴露系统性问题。这套做法我现在还在沿用每次改动提示词都会先跑一遍样例集确认整体分数没掉才放心。这次初探走下来我对多智能体协同最大的感受是它不神秘也不是万能药。真正重要的不是模型本身而是你如何设计角色边界、定义消息协议、设定终止条件。把这些工程细节打磨好大模型协作才能从“几个模型聊天”变成“一条可靠流水线”。最后再分享一个小技巧。我在这份34页PPT的中间插了一页纯“示意图目录”专门画了六种常见协作模式的缩略图每页开头都会先在小目录图上高亮当前讲到的模式。听众的追线成本一下就降下来了。你要是有类似分享需要不妨试着多做这一页效果比直接进入正片好得多。