企业官网建设流程全解析

做多智能体这行时间也不算短了，我见过最多的方案其实就是“把同一个 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 当中介者可靠得多。

第二个是执行 Agent（Worker/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 典型流程：研究 -> 写作 -> 审校 -> 修订闭环

角色定好了，看一个最典型的“闭环”调度流程。假设我们要完成一篇技术文章，流程是这样的：

1. 中介者下发 research 任务，把需求文档写入共享记忆，然后通知 agent_research 读取；
2. agent_research 返回结构化的研究笔记，向中介者提交 merge_request；
3. 中介者校验研究笔记没有冲突后，把它合入全局记忆，并触发 agent_writer 任务；
4. agent_writer 基于最新的全局记忆生成初稿，提交给中介者；
5. 中介者把初稿连同全局资料下发给 agent_reviewer，要求做审校；
6. agent_reviewer 返回评审意见；
7. 中介者根据评审意见判断：需要修改，则再次调度 agent_writer；通过，则输出最终结果。

这个流程和直接串行调用看起来差别不大，但关键在于第 3 步和第 5 步。中介者不是在“转发消息”，而是先对上一个 Agent 的产出做合并、摘要和冲突处理，再决定下一个动作该派给谁。这个“整理后再派发”的动作，保证了全局记忆始终是可信的、最新的、无冲突的。

2.4 集中式、分布式、混合式，如何选

中介者本身也不是只有一种形态。我把它分为三类，方便你对号入座。

我自己的经验是，大多数中小型项目，集中式中介者就完全够用。先跑通，别一上来就搞 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 都能读快照，但只有一个角色能写入，这个角色就是 coordinator；
• task_queue：coordinator 用队列来控制 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_snapshot=self.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 在等 B，B 在等 C，C 在等 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”的骨架跑通，再逐步往上叠加。你会发现，多智能体的复杂度很少来自模型，而是来自交互本身。把交互管住了，复杂度的天花板就被你按住了。