做多智能体这行时间也不算短了我见过最多的方案其实就是“把同一个 Prompt 复制给好几个模型实例并行跑几遍最后再把结果拼在一起”。这种套路叫“多开 Agent”很贴切但它根本不是真正的多智能体协作。真正的多智能体协作核心在把“交互”这件事管起来——让谁先跑、结果给谁、冲突怎么定、状态谁来维护。而这个“管理交互”的角色在软件设计模式里有一个非常明确的名字中介者模式。我后来把一个网文创作流水线项目从“8 个 Agent 并行乱跑”重构为“一个中介者 一组专职 Agent”的架构以后才彻底确认一件事多 Agent 项目的复杂度从来不在模型数量而在交互结构。这篇文章适合两类人。一类是刚接触 Agent 开发、被 AutoGen、CrewAI、LangGraph、AgentScope 这些框架绕晕的新手另一类是已经跑过不少 Agent Demo、但总感觉协作过程不可控、一上复杂任务就开始“抽风”的开发者。我会把中介者模式在多智能体场景下的原理、设计取舍、实操步骤、问题排查完整梳理一遍全部来自实际工程经验不是概念堆砌。1. 先想明白多开 Agent 和真正的多智能体协作差在哪里1.1 多开 Agent 的常见做法与隐藏问题先聊“多开 Agent”。市面上一大批“多智能体”教程本质上就是多开把一个大任务拆成多个小任务写好几个 Prompt 模板把每个模板分别丢给模型并行或串行地跑最后用一段拼装逻辑把结果凑在一起。这套做法确实能快速看到效果尤其在任务彼此独立、结果只是做简单拼接的场景里它甚至够用。但它隐藏着三个非常致命的问题。第一结果之间没有相互校验。A Agent 负责收集资料B Agent 负责写初稿但 B 对资料的理解可能完全跑偏A 却没有任何机会指出。第二上下文互相隔离。每个 Agent 只看到自己那一段输入A 不知道 B 写了什么B 不知道 C 改了什么。整个系统没有一个地方存着“当前任务到底进行到哪一步了”。第三任务链条一旦变长错误会直接累积。第一轮的小偏差会在第三轮被放大成完全跑题的结果而排错时你只能靠日志去脑补整个流转过程。我用一个很生活化的例子给同事解释过多开就相当于让一群人同时进厨房各炒各的菜最后把菜堆到一个盘子里端出去。看起来每个人都在干活实际上没有人对最终那道菜负责。1.2 真正协作的三个特征可见、可控、可回溯那真正的多智能体协作应该是什么样我认为至少要满足三个特征。第一个特征是可见。任何一个时刻系统里到底有几个 Agent 在工作它们各自拿到什么输入、期望输出什么以及当前全局任务处于哪个阶段所有信息都应该有一个统一的出口能看得到。而不是全靠隐式的调用链去猜。第二个特征是可控。当多个 Agent 的产出出现冲突比如一个说要删掉某段、另一个说必须保留系统必须有一个明确规则来决定谁说了算。如果没有这个仲裁机制哪怕模型能力再强协作结果也是撞运气的。第三个特征是可回溯。任何一条输出都能追溯到它是怎么被生成、被哪个 Agent 修改过、经过了哪些评审轮次。项目一开始可能不需要精细到这种程度但如果你做的是内容生产、代码审查这类需要质量审计的业务回溯能力就是刚需。说得直白一点多开 Agent 是“让很多人各自干活”多智能体协作是“让一群人围绕同一件事按照一套规则有序地干活”。二者的差别关键在于有没有一个“项目协调人”。1.3 中介者模式为什么是这个问题的标准答案这个“项目协调人”放到软件设计模式里就是中介者模式Mediator Pattern。设计模式里的中介者Mediator模式指的是用一个中介对象封装一组对象之间的交互让这些对象不再直接互相引用。这样做的好处是把网状的多对多依赖降维成星形的一对多依赖交互逻辑全部集中到中介者里单个对象之间变得松散耦合。多智能体协作遇到的麻烦和设计模式要解决的问题几乎一样。两个 Agent 直接对话看起来链路最短但真实工程里 A 找 B、B 找 C、C 又反馈给 A关系一旦变成网状任何一次接口调整都会导致连锁修改更麻烦的是流程控制会失控。你没法预测两个大模型直接对话会聊出什么结果它们可能跑题、可能抬杠、可能会陷入完全无意义的重复。加入中介者之后关系变成了这样中介者 / Coordinator / | \ Agent A Agent B Agent C所有 Agent 不再直接互相传递信息而是把产出交给中介者由中介者统一整理、校验、仲裁再决定下一步派活给谁。交互从不可控的网状结构变成了一条只有中介者一个决策中心的链路。正因为如此一句话就能概括整个项目核心思路多智能体协作本质是中介者模式的落地而不是把多个 Agent 实例同时跑起来。深刻理解这一点后面看任何多智能体框架你都能一眼看穿它的设计意图。2. 中介者模式在多智能体系统里的落地形态2.1 角色划分中介者、执行 Agent、消息通道、共享记忆理论归理论落到工程上一个可运行的多智能体系统需要四个角色。第一个是中介者Coordinator/Mediator。它是整个系统的调度中枢负责接收消息、分配任务、维护全局状态、仲裁冲突。注意中介者不一定是另一个大模型 Agent。它可以是普通代码甚至只是一张路由表加一个状态机。在大量场景里代码实现的确定性中介者比用一个 LLM 当中介者可靠得多。第二个是执行 AgentWorker/Colleague。它们负责具体任务比如收集资料、写草稿、查代码、做审校。执行 Agent 之间不直接通信它们只与中介者交互彼此通过中介者间接触达。第三个是消息通道。它既可以是内存里的事件总线也可以是 Redis 队列、数据库表、消息队列。多智能体系统要稳定消息格式必须先稳定下来。第四个是共享记忆Shared Memory / Global State。这是系统里存储任务状态、事实表、全局约束、阶段性结果的地方。共享记忆是“所有 Agent 都知道的公共事实”但它不能任由每个 Agent 随便写。这四个角色本身不复杂但往后走你会发现绝大部分多智能体项目的崩溃都发生在后两个角色的设计上消息格式混乱共享记忆无权限约束。2.2 通信协议消息与共享引用的正确设计先说消息。多智能体协作是否稳定很多时候不是模型决定的而是消息结构决定的。我在项目里使用的消息结构大致长这样{ message_id: msg_001, sender: coordinator, receiver: [agent_research], type: task, task_id: task_001, content: 请基于 fact_table 中的线索完成资料收集, context_refs: [fact_table, session_001], created_at: 2025-01-01T10:00:00Z }这套字段看起来很简单但它解决了几件很关键的事。第一每条消息都有唯一的 message_id整条流水线可以按 ID 纵向回溯。第二接收方知道自己要引用哪些共享对象比如 context_refs 指向全局记忆里的具体条目消息体本身不携带全文。第三type 字段把消息分成 task、feedback、review_result、summary 等类型中介者拿到不同消息就能走不同处理逻辑。这里我想强调一个坑消息里不要把所有上下文都塞进去。很多刚开始做多 Agent 的开发者习惯把全量历史、全量资料塞进某一条消息让 Agent 处理结果两三轮以后 token 就爆了。正确的做法是让中介者维护一块共享记忆区消息里只写引用 ID。Agent 需要读数据时再到共享记忆区按 ID 取。这样消息轻量、存储集中、回溯也方便。2.3 典型流程研究 - 写作 - 审校 - 修订闭环角色定好了看一个最典型的“闭环”调度流程。假设我们要完成一篇技术文章流程是这样的中介者下发 research 任务把需求文档写入共享记忆然后通知 agent_research 读取agent_research 返回结构化的研究笔记向中介者提交 merge_request中介者校验研究笔记没有冲突后把它合入全局记忆并触发 agent_writer 任务agent_writer 基于最新的全局记忆生成初稿提交给中介者中介者把初稿连同全局资料下发给 agent_reviewer要求做审校agent_reviewer 返回评审意见中介者根据评审意见判断需要修改则再次调度 agent_writer通过则输出最终结果。这个流程和直接串行调用看起来差别不大但关键在于第 3 步和第 5 步。中介者不是在“转发消息”而是先对上一个 Agent 的产出做合并、摘要和冲突处理再决定下一个动作该派给谁。这个“整理后再派发”的动作保证了全局记忆始终是可信的、最新的、无冲突的。2.4 集中式、分布式、混合式如何选中介者本身也不是只有一种形态。我把它分为三类方便你对号入座。形态适用场景优点缺点集中式中介者任务流程稳定、Agent 数量较少、团队规模小简单可控、排错方便单点瓶颈、中介者上下文可能很长分布式中介者Agent 数量多、跨服务部署、需要横向扩展扩展性好、不会单点过热一致性难保证、协议设计成本高混合式中介者既有核心决策链、又有大量并行分支兼顾稳定与灵活实现复杂度最高我自己的经验是大多数中小型项目集中式中介者就完全够用。先跑通别一上来就搞 K8s 部署、消息队列、分布式状态同步这一套。等业务真的到了需要跨服务协调的规模再考虑混合式。中间态永远是最复杂的别为了架构的炫酷去选它。3. 实操记录把一个 8 Agent 并行项目改造成中介者架构3.1 改造前的问题复盘前面说过我接手过一个网文创作流水线项目。最初它非常典型开了 8 个 Agent 并行跑分别负责世界观设定、人物卡、章节大纲、正文写作、剧情审校、润色、敏感词检查、发布准备。听起来阵容豪华实际效果让人崩溃。最典型的问题有三个。世界观 Agent 和人物卡 Agent 各自独立生成结果人物设定和世界观背景经常冲突。比如世界观 Agent 规定主角来自北方寒地人物卡 Agent 却把人写成了热带居民后面正文写作就没有任何机制发现这一点。章节正文和共享背景严重脱节。写作 Agent 每次只看到大纲的一部分它写完一章之后下一章的另一实例又开始从零生成导致前后剧情连续性几乎全靠运气。还有审校 Agent 修改完内容敏感词检查 Agent 又要改一遍。两个 Agent 各自维护自己的“正确版本”完全不知道对方改了什么最后输出结果经常互相覆盖。每次排查问题我只能翻各 Agent 的日志自己脑补它们之间的执行顺序和数据流。那段时间我得到一个非常痛的教训没有中介者的多 Agent 系统本质上就是多个调试困难的独立脚本。3.2 目标架构与核心实现骨架改造方案很简单保留这 8 个执行 Agent新增一个 coordinator 作为中介者。同时引入两个全局数据结构global_memory所有 Agent 都能读快照但只有一个角色能写入这个角色就是 coordinatortask_queuecoordinator 用队列来控制 Agent 的执行顺序。代码骨架大致如下class Coordinator: def __init__(self, agents: dict[str, Agent], memory: SharedMemory): self.agents agents self.memory memory def dispatch(self, task: Task): # 中介者的核心动作先更新全局记忆再选择执行者 self.memory.update(task.context_update) agent self.agents[task.target] result agent.run(task, memory_snapshotself.memory.snapshot()) # 关键执行 Agent 不能直接改全局状态 # 它只能提交一个 merge_request 给中介者 validated self.validate_against_global_state(result) if validated.ok: self.memory.apply(result.merge_request) return self.next_task(task, result) else: return self.resolve_conflict(result, validated.conflicts)这段代码里最核心的是这一行self.memory.apply(result.merge_request)。它表达了一个核心约束执行 Agent 不拥有全局记忆的写权限它只能向中介者提交“合并申请”。合并过程中中介者能做冲突检测。比如两个 Agent 都写了“主角性格”后提交的一方如果要求覆盖coordinator 会检查这是不是合理的覆盖或者需要合并甚至请求人工确认。这个设计带来的变化极其明显。写作 Agent 每次拿到的都是 coordinator 整理过的、无冲突的快照审校 Agent 和敏感词检查 Agent 的修改意见不再直接覆盖原文而是先汇总到 coordinator由协调者统一合并成新版整条流水线也有了统一的决策日志每次“谁在被调度、谁产出了什么、是否通过”都能回溯。3.3 改造后的效果与数据观察改造上线之后最直观的感受是8 个 Agent 总算是在“一个项目”里干活了而不是各自为战。写正文的 Agent 不再频繁产出和世界观设定冲突的内容因为每次任务的 memory_snapshot 里已经带了协调者整理好的设定审校和敏感词检查不再互相覆盖因为它们的修改意见在合并层就被统一处理了更重要的是每一条正文输出都能通过 coordinator 的日志追溯到它基于哪一版设定、经过哪些评审、改了几轮。这个项目让我彻底相信一件事Agent 数量不是协作质量的关键有没有中介者在做调度、仲裁和记忆维护才是关键。4. 落地过程中最难啃的四个技术细节4.1 全局记忆的写入权只能中介者能改多智能体项目踩过的第一个大坑就是全局记忆设计成“大家都能写”。很多团队用共享 dict 或共享数据库所有 Agent 都能往里写数据。初看起来灵活实际上冲突照片堆叠起来以后整个系统就像多人同时编辑一个文档没有一个版本管理机制最后谁都不知道哪个是最终版。我的建议很硬性执行 Agent 只读快照只有中介者才能写全局记忆执行 Agent 如果要改全局状态必须通过 merge_request 来提交。这个设计比“所有 Agent 可读可写”多了一步但正是这一步保全了系统的确定性。如果全局记忆允许每个 Agent 随便写那么每次冲突排查都无异于一场灾难。另外还有一个低级但重要的细节给 Agent 下发记忆快照时一定要做深拷贝或者直接传序列化后的字符串。Python 里如果传的是同一个对象引用Agent 内部哪怕只是修改了一下局部变量也可能污染全局数据。这种 bug 极其隐蔽现象是“没人改数据数据却变了”。4.2 中介者自己的上下文不能无限膨胀中介者是消息汇聚点天然就是上下文最容易膨胀的地方。一边要接收各方打来的 reports一边要维护全局状态如果再把所有历史消息都缓存到自己的上下文窗口里第 10 轮以后基本必然会触发 token 限流。我在项目里用了几种缓解手段。第一状态摘要。每跑几轮让中介者对全局状态生成一段结构化摘要原始过程记录写入外部存储上下文里只留摘要。第二引用替代。消息里只传引用 ID不传全文。第三事实表优先。长期保留的信息尽量收敛成 key-value 结构比如设定表、人物卡、待办列表而不是自然语言聊天记录。第四滑动窗口。只保留当前阶段和上一个阶段的关键信息更早的归档到日志。你会发现在多智能体系统里“记忆”不是越多越好而是在当前任务阶段“刚好够用”最好。4.3 防死循环把对话降级成任务分配多 Agent 项目调试时最让人崩溃的事是两个 Agent 开始“打太极”。A 说“我需要更多资料”B 说“请说明需要哪些资料”A 又说“需要相关资料”。这种循环如果没人打断能一直聊到 token 耗尽。我踩了几次坑以后总结出几招。第一设置最大交互轮次超了就让中介者强行终结把当前结果返回。第二对请求做语义去重如果这次请求和上一轮相似度太高直接合并处理。第三禁止 Agent 之间直接对话所有请求必须落地成任务项走任务队列。把“对话”降级为“任务分配”是我在多智能体系统里学到的最有效的一招。Agent 之间没有自由对话只有中介者派发任务和执行 Agent 提交结果。这种模型天然不容易死循环因为它本质上是把不可预测的自然语言交互变成了可预测的指令流。如果你在建系统的时候发现流程总会卡住优先检查是不是有地方还允许 Agent 之间直连对话了。如果有请把那条链路拆掉一切收口到中介者。4.4 结果仲裁不要依赖 LLM 自由发挥多 Agent 系统跑完一轮经常出现多个 Agent 都输出了一些结果但互相矛盾的情况。谁来当最终裁判我见过不少实现让 coordinator 这个 LLM Agent 自己判断该怎么处理矛盾。运行几次以后会发现结果完全不可预测。上次冲突是 A 赢这次同样的冲突变成了 B 赢中间没有任何可复现逻辑。所以我在项目里的做法是尽量把仲裁规则规则化。用角色权重来定优先级比如 reviewer 的否定权重高于 writer。也就是说评审说“这段不合理”写作 Agent 不能以“我认为合理”原地驳回。用检查清单驱动仲裁而不是自由对话。评审意见必须按“结构、事实、风格、合规”几个维度提交仲裁方按照各项是否通过来下结论。仲裁结论必须落到结构化字段比如 approved、needs_revision、blocked方便后续流程自动化也方便做归集分析。最后每次仲裁记录都要落库。积累足够多以后你可以拿历史仲裁记录去反复调优中介者的 Prompt 和判断规则让系统从“每次靠运气”变成“每次按规则”。5. 框架选型与学习路线建议5.1 AutoGen、CrewAI、LangGraph、AgentScope 的中介者视角很多人问“多智能体框架采用哪一个”我觉得要先看透一件事市面上的框架实质上都在解决同一个问题——Agent 之间怎么交互。差别只在于它们把“中介者”放在不同的位置用不同的方式实现。AutoGen 的 GroupChatManager 本质上就是一个对话型中介者它决定当前该哪个 Agent 说话CrewAI 的 Process 机制负责任务顺序和层级分配是一种流程型中介者LangGraph 把整个流程建模成一张图由 State 承担中介者的职责节点之间按边流转AgentScope 则把消息通信、分布式编排做得很重Msg 对象本身就是一个很标准的通信中介。拿 AgentScope 来说AgentScope 2.0 把通信层单独拎出来设计本质上就是承认“Agent 之间的交互层”是多智能体系统的核心基础设施而不是附属品。这其实是在用工程架构再次验证了标题那句话多智能体协作的本质是中介者模式不是多开 Agent。5.2 按业务形态选框架别按热度选框架到底怎么选我的建议是先判断你的业务到底需要哪种中介者形态。如果你的场景更偏研究探索需要 Agent 之间自由对话、互相激发观点那 AutoGen 的对话管理机制会更顺手。如果你的场景是流程相对固定的产品功能比如写文案、做审查、整理报告那 CrewAI 的树形流程能让你快速跑通原型。如果你的业务流程复杂存在条件分支、循环、多阶段串联LangGraph 的图模型会是更稳的选择。如果你的重点是分布式多 Agent 通信、大规模部署AgentScope 的订阅发布式消息机制值得优先考虑。选框架的原则就一句话你对“中介者”的需求越明确越适合用流程和状态可控的框架你的 Agent 之间越需要自由交流越适合用对话管理类框架。不要因为某个框架热门就去选也不要因为某个 Demo 炫酷就盲目跟随回到你自己的业务里去找答案。5.3 自研中介者与 Agent 学习路线自研中介者还是用框架这是一个不能回避的问题。框架最大的好处是省事消息格式、角色管理、流程流转都替你设计好了。自研最容易被低估的成本则是“通信协议”的维护。自己写一套消息格式、存储、重放、追踪机制工作量比想象中大不少。但如果你的业务里有大量定制化状态、复杂权限审批、强审计需求自研中介者反而更可控。我项目里的 coordinator 很少绑定某一家框架因为很多业务耦合逻辑很难被通用的多智能体框架完整覆盖。顺带聊一下 Agent 开发学习路线。我见过很多新人一上来就啃框架源码效果反而一般。我推荐的学习顺序是先把任务拆解和消息设计练熟知道自己要管的是什么再用一个最笨的 coordinator 把单个闭环任务串起来然后逐步加全局记忆、冲突仲裁、摘要压缩最后再研究框架你会发现自己已经能看懂框架为什么要那么设计。先懂原理再懂框架这条路要顺得多。6. 常见问题与排查技巧实录6.1 多个 Agent 互相覆盖修改怎么办现象两个 Agent 都认为自己改的是最终版本最后一个运行结束的覆盖了前一个的结果系统产出出现丢失。排查步骤先看中介者日志里的 merge_request 记录确认是否真的做了冲突检测。如果中介者每天都在“诚实转发”而不是“合并整理”那冲突是必然结果。解法在中介者里增加字段级冲突检测同一字段在同一轮被两方修改时必须显式指定优先级或直接挂起人工审核不允许静默覆盖。6.2 上下文越跑越大导致限流现象任务跑到第 10 轮左右LLM 报输入超限或链路延迟激增。排查步骤检查发给 Agent 的 context 是否每次都包含全量历史。如果发送的消息里还在带“聊天记录全文”那你一定会遇到这个问题。解法给中介者加“摘要轮次”每 5 轮做一次全局摘要把过程性原始记录落库消息里只放 summary_id。同时把消息里的长内容改成引用 ID。6.3 流程卡死、互相等待怎么破现象任务长时间无输出日志停在某一处A 在等 BB 在等 CC 在等 A。排查步骤画出任务的依赖关系检查是否存在环。多数情况是某两个 Agent 之间还有“直连等待”逻辑。解法禁止 Agent 之间互相发起等待型消息等待关系只能由中介者调度。中介者的天然职责之一就是消除 Agent 之间的间接依赖。只要链路收口到中介者这种死锁的场景会大大减少。6.4 加了中介者之后系统变慢了现象本来 6 个 Agent 并行跑只要 20 秒改成中介者后串行跑要 1 分钟。排查步骤检查是不是中介者把所有并行任务都改成了串行。解法中介者不必所有环节都串行。可以把无依赖的分支任务先下发给一个并行池只有汇合点才需要中介者全局仲裁。这也是混合式中介者最常见的价值场景。记住中介者负责控制交互和状态不等于所有任务都要排成一条线。6.5 多智能体检查清单速查最后整理了一份我每次做多智能体系统评审时必过的清单直接复制去用就行。所有消息是否有 message_id 和引用 ID全局记忆是否仅中介者可写执行 Agent 拿到的记忆是快照还是共享引用是否设置了最大轮次与强制终结机制是否存在 Agent 之间的直连消息或等待关系仲裁结论是否落地为结构化字段过程中介者日志是否可以完整回溯到每条 message_id中介者上下文是否有摘要压缩和滑动窗口策略这份清单里的每一项我都踩过对应的坑。建议你在项目初期就把它们设计进去别等项目跑大了再回头补。7. 写在最后一些只有实践才会懂的经验在这个项目里走完一圈后我的个人体会是中介者模式不是一种“高级技巧”而是多智能体系统里最该优先落地的基础设施。你完全不用一开始就设计得特别复杂哪怕先用一个最简单的 coordinator 把所有 Agent 的输入输出记录下来再慢慢迭代出全局记忆、冲突仲裁、摘要压缩系统都会逐渐进入可控状态。还有一个小技巧想分享。中介者的 Prompt 写作尽量用“检查清单 规则”的方式少给中介者“自由裁量权”。自由裁量权越高你的排错越痛苦。我把中介者 Prompt 写得像一份 SOP 手册以后这个项目从“玄学调参”回到了“工程可复现”这是一次特别大的心态转变。如果你现在正在折腾多智能体我个人建议先从已有的网文创作、资料研究、代码审查这类闭环任务开始把一个“中介者 三个执行 Agent”的骨架跑通再逐步往上叠加。你会发现多智能体的复杂度很少来自模型而是来自交互本身。把交互管住了复杂度的天花板就被你按住了。
