多智能体协作的核心：中介者模式而非简单调用链-北京尧图网络

最近复盘一个多智能体项目时我确认了一个判断很多人以为多智能体协作就是多开几个Agent让它们前后跑一遍但真正的协作本质是中介者模式而不是把Agent实例堆成一条调用链。这个现象太普遍了——装上Agent框架注册几个角色前后接力跑一遍就觉得是Multi-Agent了。可真到了生产环境链路一长问题全冒出来任务重复执行、上下文互相覆盖、A Agent的产物格式B Agent不认、某个环节失败只能全链条重来。我踩过这些坑之后决定把中介者模式在多智能体协作里到底承担什么角色、怎么落地、怎么选型讲清楚。这篇文章适合正在做Agent应用、纠结要不要上多智能体架构的人参考。1. 两个Agent“直连”问题比你想的多1.1 一个典型的多开现场调用链又长又脆弱先还原一下最典型的“多开式”实现。假设你想做一个自动产出技术调研报告的系统流程是研究Agent查资料 → 写作Agent写文章 → 发布Agent做排版推送。很多人第一版是这样写的research_report researcher_agent.invoke( {task: 调研向量数据库的选型, format: markdown} ) article writer_agent.invoke( {task: 基于调研报告写出技术博客, material: research_report} ) publisher_agent.invoke(article)这段代码看起来干净利落但它只是演示代码。真实项目里第一轮就能暴露问题research_report返回的内容可能是JSON包着Markdown表writer_agent拿到后整个当一个字符串塞进提示词里最后生成的文章全是未消化的原始参考材料。这只是格式层面的错位。更麻烦的是这三行代码把决策流写死了。写作者觉得材料不够怎么办找不到“回退到研究Agent补查”的路径。发布者发现文章不合规怎么办只能报错没有任何机制触发“写作者重写”的动作。这不是智能协作这是三条for循环。我见过不少项目的“多智能体架构”说白了就是这种调用链的变体。有的加了个内存队列有的让Agent之间能互相发消息但整体依然是两个Agent点对点交换数据。框架越上越多问题没有本质变化。1.2 直接互调最容易暴露的三类故障这里我根据自己的项目经验把直连式协作的故障归成三类每一类都在生产环境遇到不止一次。第一类是上下文不一致。每个Agent都有自己的系统提示词和对话历史点对点互传时只传递文本内容不传递调用链的全局状态。结果就是两个Agent各自维护一份“世界模型”天然会互相矛盾。举个例子研究Agent在报告里明明写了“方案A在写入性能上比方案B高40%”写作Agent因为提示词里有一句“选型时要考虑团队熟悉度”直接把结论改写成“方案B更适合长期维护”。它不是有意跑偏是它根本不知道研究Agent得出A结论的前提条件是什么。第二类是失败无处收敛。点对点调用里A Agent一出错调用方只能整体重试或者整体放弃。多智能体系统里的错误往往是局部的比如一个工具调用超时、某个Agent返回了空结果。理想的做法是只重跑出问题的子步骤而不是把前面全部工作推倒重来。这个能力只有独立的协调层能提供。调用链模式下谁都做不到局部恢复。第三类是可观测性极差。你想回答一个简单问题——“当前这个任务进行到哪一步了下一步是谁为什么做出这个路由决定”——在直连模式里没有答案。日志散落在各个Agent函数调用里没有一个地方能看到完整的事件流。排障的时候只能靠一个Agent一个Agent地查对话记录靠猜。这三类故障的根因是同一个缺少一个拥有全局视角的独立协调者。1.3 把“通信权”收回到协调者手里说到这里中介者模式的核心意义就很清楚了。它做的事情本质上是从Agent手里把“通信权”和“决策权”收回来集中到一个独立的协调组件上。我经常用一个项目的比喻来解释这件事。一个开发团队拿到一个需求最差的组织方式是让所有成员互相私聊、各自决定做什么然后期待最后能拼出正确产品。稍微有点管理经验的团队都会安排一个项目经理项目经理收集需求、拆任务、分配给人、检查交付物、协调冲突。多智能体系统里的“项目经理”就是中介者。如果你把这个比喻套回技术系统就会发现中介者不是简单的消息转发器。它至少要具备三件事的能力知道全局状态拥有为下一步做决定的决策逻辑并且能对Agent的产出做质量仲裁。后面的章节我会逐个展开。2. 中介者不是消息队列它要承担三个关键角色2.1 调度中枢路由不是写死的是算出来的很多文章把中介者模式等同于把消息汇总到一个中心再分发出去这其实低估了它。在多智能体协作里中介者首先是一个调度中枢但它和ESB总线、消息队列有本质区别消息队列不关心消息内容中介者必须理解任务上下文才能决定路由。举例来说一次用户请求进来中介者先做任务分解得到三个子任务。它需要判断子任务A适合交给“代码生成Agent”子任务B需要调用“搜索工具”子任务C必须人工审批。这个路由决策不是靠写死的if-else能完成的因为用户的请求是开放的不可能把每种组合都穷举出来。我目前在项目里用的路由策略是三层混合。第一层是能力声明匹配每个Agent在启动时向中介者注册自己擅长什么、能调用什么工具中介者维护一张能力表。第二层是规则路由稳定不变的路径直接走配置例如“调研类任务永远先走检索节点”。第三层是模型决策边界情况由LLM判断把子任务分给谁。三层从快到慢成本可控准确率比单靠一层高很多。2.2 全局上下文已经发生的事中介者比Agent更清楚Agent本质上是有状态但状态短暂的。每个Agent在自己的那一轮调用里拥有完整的上下文窗口但一轮结束后就什么都不记得了。中介者要做的是在整个任务生命周期里维护全局上下文——节点完成了什么、中间产物是什么、谁基于哪个版本改过内容、当前卡在哪个环节。用一个更生活化的类比一群专家轮流修改一份方案文档。如果每个人拿到的是上一版的批注而且都在自己理解的基础上改最终文档一定会乱套。可靠的机制是有一个主编守着唯一一份完整版本文档控制“谁在什么时间基于哪个版本修改”。中介者就是这个主编。技术上这个全局上下文应该设计成结构化的而不是一个大字符串。我用一个TaskState对象统一保存当前状态关键字段包括task_id、completed_steps、pending_steps、artifacts、message_history。每一步Agent调用都先去读全局状态再把自己的产出写回状态。因为这个对象是中介者唯一维护的Agent之间不需要直接通信避免了各自维护一份“真相”的混乱。2.3 仲裁人多个Agent想干同一件事谁来定多智能体系统里冲突是常态不是异常。两个Agent同时向全局状态里写入相矛盾的结论一个Agent请求重跑上游任务另一个Agent还依赖着旧结果两个Agent都认为某个子任务应该由自己来做。中介者的第三个角色就是仲裁。我实际用到的仲裁机制有四种。排队冲突任务按优先级排队避免多个Agent同时操作同一份资源。否决当子任务的产出与已确认的全局结论冲突时直接拒绝并记录理由。合并多个Agent产出的内容可以取交集或做版本对比再传给下一个节点。拆解一个Agent请求的重跑范围太大时中介者只重跑与该请求相关的子步骤。这个仲裁逻辑不需要做得很重但必须有。没有仲裁的中介者只是一个“广播站”Agent之间的冲突不会自动消失只会从“明面上的互踩”变成“上下文里的暗雷”。顺便提一句LLM驱动的Agent比传统分布式节点更不可控因为输出有随机性同样的请求两次调Agent可能给出不同结果。仲裁策略要设计得更宽容给Agent留下重试和纠偏的空间而不是一遇冲突就全链报错。2.4 中介者、黑板、直连三种协作形态的取舍多智能体系统的协作架构不止中介者一种。业界经常提到的还有黑板模式Blackboard Architecture以及前面花了很多篇幅批评的直接互调。我在这里做一个横向对比维度直接互调黑板模式中介者模式Agent间依赖高耦合互相知道接口只依赖共享数据空间只依赖中介者互相不可见决策能力无全局决策弱靠各Agent自主读写强路由与仲裁集中故障恢复无链路断了只能重来中等部分状态可恢复强局部重试易实现可观测性差日志分散中看黑板历史好中介者有完整事件流适用规模2-3个Agent的极简场景并行计算型任务多角色、有流程控制要求的任务黑板模式有一个明显特点Agent之间通过共享空间隐式协作每个Agent在“适当的时候”去读黑板上感兴趣的内容。这个模式非常适合处理并行计算密集的任务比如一个黑板上有十个问题十个Agent各取所需同时干活。但它的弱点在于没有集中决策谁先谁后全凭各Agent自主判断流程顺序很难控制。中介者模式在流程控制和故障恢复上明显更强适合业务上有明确阶段、顺序、质量要求的场景。实际应用中两者不是互斥的。我在自己项目里的做法是中介者控制流程节奏和路由决策把共享产出写入一个持久化的存储节点这个节点本质上就是一块“黑板”。控制面用中介者数据面用黑板两者并行不悖。3. 落地案例让研究Agent和写作Agent产出协作成果3.1 需求与两个Agent的职责定义概念讲得再透不如跑一个具体例子。这里我以实际做过的“自动生成技术调研报告”功能为例把这个流程完整拆开。需求是输入“请帮我调研一下PostgreSQL和MySQL在写入性能上的差异并输出一篇适合技术团队阅读的对比分析报告”。报告要有数据支撑、有适用场景建议、格式工整可以被后续发布流程直接使用。我注册了两个AgentResearchAgent负责检索资料把多来源的事实整理成结构化摘要字段包括topic、evidence、source、conclusion。它不写文章。WriterAgent接收结构化事实和写作任务书把它润色成完整文章。它不做事实核查不自行补充数据。注意这里我把职责边界划得很清楚ResearchAgent只能产出结构化素材WriterAgent只负责文体加工。这个边界由中介者的能力注册表约束Agent之间互相不知道对方的存在。3.2 多开式写法链路短但处处是隐患如果按照“多开”的思路代码会是这样research_output researcher_agent.invoke( 调研 PostgreSQL 和 MySQL 在写入性能上的差异给出数据对比 ) article writer_agent.invoke( f根据以下素材写一篇技术报告\n{research_output} )这段代码最大的问题在于ResearchAgent返回的可能是几百行原始注释、引用片段和未分类的链接WriterAgent的上下文窗口会被塞满最后生成的文章里原始素材占了一半。哪怕ResearchAgent按要求输出了evidence和conclusionWriterAgent也可能因为prompt里的一句“可以根据你的理解补充”就自己编造了一组不存在的数据。更致命的是没有反馈回路。如果WriterAgent发现素材不足它只能硬写。它不能说“我需要补充关于高并发写入场景的数据”因为代码里根本不存在让写作Agent往回传递需求的通信链路。这其实就是1.2里说的“失败无处收敛”的变体——问题不会因为Agent数量变多就消失只会被链路放大。3.3 中介者式写法把决策流收回到一个可审计的地方换成中介者模式后核心是一个Coordinator类。它不生成任何内容只做调度、评估、路由、汇总。class Coordinator: def __init__(self, agents): self.agents agents # {researcher: ..., writer: ...} self.task_state {} # 全局上下文 def run(self, task): task_id uuid.uuid4().hex self.task_state[task_id] { task: task, steps: [research, write], artifacts: {} } # 第一步路由给研究Agent并声明产出格式 raw self.agents[researcher].invoke( TaskRequest(tasktask, output_formatstructured) ) # 第二步质量评估——格式不对就重试最多三次 for attempt in range(3): is_valid, reason self._validate_research(raw) if is_valid: break raw self.agents[researcher].invoke( TaskRequest(tasktask, feedbackreason, output_formatstructured) ) self.task_state[task_id][artifacts][research] raw # 第三步把结构化素材路由给WriterAgent draft self.agents[writer].invoke( TaskRequest(tasktask, materialraw[structured], styletech_report) ) # 第四步汇总结果只有通过校验才放行 self.task_state[task_id][artifacts][article] draft return self._publish(draft)这段代码的骨架体现了中介者的三个职责。调度中枢任务被拆成research、write两步按顺序执行全局上下文所有中间产物都写进task_state仲裁人_validate_research对研究Agent的产出做校验不通过就带着反馈重新请求。注意_validate_research是一个独立的评估节点。它可以是一个简单的schema校验——检查evidence字段是否存在、conclusion是否为空也可以是一个独立的轻量模型对素材的相关性打分。我强烈建议至少先上规则校验成本低、稳定效果立竿见影。3.4 实测对比同样任务两种架构的差别我在同一组任务上分别用两种架构跑了20轮每轮都是同一个Prompt。大致结果如下指标直接互调中介者式首轮产出可用率无需人工改写40%左右75%左右因格式问题导致的失败重跑每轮约1-2次偶尔1次失败后恢复方式整体重新生成局部反馈重试连续5轮运行的稳定性越跑越偏上下文受控结果收敛这里需要说明这不是严谨的基准测试样本量也小但行为差异非常典型。直接互调的40%可用率主要败在格式和上下文污染上中介者式的75%里有一半是第一次评估就通过了另一半是经过一次反馈重试后通过的。这套东西上线后还有一个隐形收益——排障。以前用户反馈“报告写得不对”我需要同时翻ResearchAgent和WriterAgent的日志去猜问题出在哪。现在中介者的task_state里有完整的事件流我可以直接看到“ResearchAgent的原始产出是什么、评估节点为什么让重试、最终是哪个环节产出不达标”。这个收益在维护阶段比前期开发阶段更值钱。4. 框架选型判断它有没有“中介者内芯”就看这四点4.1 为什么“编排层”比“多Agent并发工具”更接近中介者现在市面上的多智能体框架很多名字也乱有的叫Harness有的叫Orchestrator有的叫Pipeline。很多人选型时被这些名词绕晕不知道它们有什么区别。我说句直接的从中介者模式的角度看真正重要的是这个框架有没有给你提供“独立协调层”的能力而不是它管自己叫什么。Harness这类编排层如果它允许你在Agent之外自定义调度逻辑、上下文存储、质量评估节点那么它本质上就是在帮你实现中介者模式。反过来如果框架只提供了“同时启动N个Agent”的并发能力却不给你任何协调机制的房间那它充其量是个多开的加速器离真正的多智能体协作还差一层。4.2 四个判断框架的硬指标根据我自己的实践选框架或者自研中间层时用这四个问题去对照能过滤掉大多数“名义多智能体、实为多开”的方案。第一个指标是否支持动态任务路由。框架允不允许你在运行期根据任务内容决定“下一步交给哪个Agent”还是说只能在启动前用配置把流程写死动态路由是调度中枢的基本能力做不到的话复杂任务只能退化为线性调用。第二个指标是否有独立的全局上下文管理。框架有没有提供一个跨Agent共享的状态存储并且允许你在路由节点读写它还是说上下文只能通过参数传递独立的全局上下文是多智能体协作区别于“多开”的分水岭。第三个指标是否支持插入评估与仲裁节点。在流程中间你能不能加一个“质量校验Agent”或者“规则检查函数”不符合条件时触发重试或改走分支如果框架只支持“调用Agent拿到结果就进下一步”那它根本没有仲裁能力。第四个指标是否有状态持久化和恢复机制。运行中的任务如果因为网络或者模型服务故障中断框架能不能从最近的检查点恢复还是全链路重跑这个指标平时不起眼一旦上生产环境直接决定你半夜要不要爬起来陪跑。下面这个表可以做一个简化对照判断维度达标表现不达标表现动态任务路由运行期可决策下一步配置写死线性执行全局上下文独立状态存储跨Agent共享上下文只能靠参数硬传评估与仲裁可插入校验节点支持重试一步到底无中间检查状态恢复支持断点续跑中断就全链重来4.3 已有系统的改造思路不推翻重来也能落地如果你手头已经有一套“多开式”Agent系统不必急着推倒重来。我这里有一个按优先级排序的渐进式改造路线。第一步加一层薄薄的OrderCoordinator。所有Agent的入口统一从这层走哪怕内部逻辑暂时不动。目标是先把可观测性和调用入口收口让“谁调了谁、结果是什么”有日志可查。第二步统一消息结构。把自由格式的参数传递改成一个TaskRequest和一个TaskResult对象至少包含task_id、sender、target、payload、timestamp。这一步做完之后格式错位的问题会大幅缓解。第三步在关键节点插入评估动作。先做简单的规则校验例如检查返回结果是否包含必需字段不满足就触发一次带反馈的重试。这个改动通常一个晚上就能完成但效果是立竿见影的。第四步把关键状态放持久化存储。把task_state从内存挪到Redis或者PostgreSQL加上恢复逻辑。到了这一步你的系统已经从“多开”进化成了标准的中介者模式后面的扩展都是量变不再是质变。5. 中介者本身也会烂我踩过的四个坑5.1 坑一中介者膨胀成“上帝对象”早期我最容易犯的错误是把所有判断逻辑都堆进Coordinator类。任务拆解放里面prompt模板管理放里面Agent能力描述放里面甚至连业务规则也写进路由决策里。几个月下来Coordinator.py到了两千多行改一处逻辑要小心翼翼担心影响其他流程。后来我意识到中介者的职责边界应该是“协调”而不是“业务”。它需要知道哪一步交给哪个Agent但不需要知道“为什么这一步的业务规则是这样”。修正的做法是把业务规则拆到独立的Policy模块里比如路由策略、质量评估标准、重试策略各自成类中介者只负责按策略执行。这样中介者保持轻量策略可以独立演进。5.2 坑二Agent自由发送消息中介者变翻译有一段时间我没有统一消息协议Agent之间通过自由文本传递内容。结果是中介者每收到一条消息就得先做语义解析猜它想表达什么再翻译给下游Agent。这个解析过程消耗大量token而且极易失败——Agent的表达方式稍有变化解析器就挂了。踩过几次坑之后我把所有Agent的输入输出都改成了结构化格式。研究Agent只能输出JSON发布Agent的回复必须是{status: published, url: ...}这种格式。模型确实偶尔不遵循格式但重试一次基本就回来了比起无休止地解析自然语言成本和稳定性都强太多。最好在系统提示词里给一个输出示例比在解析层做兜底更便宜。5.3 坑三状态外置没做系统一挂就全乱这个坑是上线第一个月被生产事故教育出来的。当时的中介者把状态全部放在内存里某天模型服务因为限流导致整批任务失败服务重启之后所有进行中的任务全部丢失只能从零开始跑。用户体验特别差。教训是中介者本身必须是“无状态可恢复”的。当前正在执行的任务详情、已经完成的步骤、各Agent的产出快照都要放到独立的存储层。我自己现在用Redis保存task_state每个任务一个key里面存放完整的消息trace和产物引用。重启后根据task_id就能知道任务断在哪一步选择性地恢复执行。这个设计不仅提升了可靠性还让系统可以横向扩容——多个中介者实例可以处理不同任务互相不打架。5.4 坑四光路由不评估相当于没有协调最后一个坑比较隐晦。有一段时间中介者的调度做得很好任务分发、路由决策都没问题但整体质量还是上不去。后来排查发现中介者把任务分配给Agent后就直接把结果透传下去了中间没有任何验证和把关。这就像项目经理只管派活、不收作业交付质量完全靠个人自觉。解决的办法是在关键路径上设评估节点验证Agent的输出是否真的满足下一步的输入要求。评估动作可以很轻比如检查结果字段是否完整也可以稍微重一点用一个独立的Critic Agent审查内容与任务的相关性。关键是必须有“不过就重试”。从我的经验看评估节点带来的质量提升往往比换更强的模型还明显因为它把Agent的随机误差锁在了一个可控制的范围内不再向下游扩散。我现在设计多智能体系统时已经把“评估节点、重试预算、状态持久化”当成默认配置了不是可选项。中介者模式的核心价值说到底就是让协作不再是碰运气而是变成一条有校验、有反馈、可恢复的流程管线。

多智能体协作的核心：中介者模式而非简单调用链

相关推荐

用Codex开发AI Agent技能包：自动化拆解短视频爆款并生成脚本

Godot CurveXYZTexture 完全指南：用一张 1D 纹理承载三条曲线（RGB 通道）

振奋人心！阿里开源Qwen3-Coder-480B大模型，AI编程又上新台阶｜TaoToken统一Key实战接入

更多资讯

MRAM与PIC18F47Q10实战：SPI驱动、数据存储与工业可靠性设计

MRAM工业存储实战：MR25H40CDF与STM32F469II高频写入方案

老码农手把手教你选型AI Agent框架：从LangGraph到MCP协议的多Agent协作落地踩坑指南

2026年4月OpenClaw集成实战：本地8分钟喂奶级教程与阿里云百炼APIKey配置流程

Playwright MCP 入门实战：自动化测试与 Copilot 集成指南（TaoToken 统一 Key 版）

DeepSeek Harness 火了以后，TaoToken 统一 Key 怎么接进 Playwright 无人值守测试链？

今日更新

插件加载失败深度解析：从did not activate到生命周期排查指南

SpringBoot+Vue+MyBatis企业级房屋租赁管理系统源码解析

企业核心数据灾备自动化：用 OpenClaw 备份到本地 + 云端 + 离线存储的 TaoToken 统一通道实践

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？