# 多 Agent 架构的六种主流设计模式（研究笔记）

> 来源：flomo 笔记 | memo_id: `MjU5ODA0Mzg2` | 创建时间：2026-10-07 12:51
> 迁移处理：2026-10-07

## 一、笔记原文

> 近期在研究多 agent 架构，目前的几种主流的多 agent 架构设计模式：
>
> **主从协调模式（Supervisor / Coordinator Pattern）** 运作机制：由单一中枢 Agent 面对用户输入，负责任务理解、子任务拆解，并根据各专业 Worker Agent 的专长进行分发。Worker 执行后将结果汇总给 Supervisor，由其评估是否满足终止条件，或决定是否重新分派。代表实现：LangGraph Supervisor 架构、CrewAI（Hierarchical 流程）、MetaGPT 的管理层模式。优势：权限清晰、流程集中可控，可插件化程度高。局限：中心节点容易成为性能与并发瓶颈。
>
> **图编排与状态机模式（Graph-based / StateFlow Pattern）** 运作机制：将多 Agent 系统的协作过程显式建模为一个状态转移图。每个节点可以是一个 Agent、一个确定性函数或一个工具调用；边定义了状态转移的条件。Agent 运行的核心是根据输入更新共享状态（State），并沿预设逻辑边流动。代表实现：LangGraph、AutoGen（GroupChat / StateFlow）、LlamaIndex Workflows。优势：工程确定性最高。局限：相比纯自主 Agent 丧失了一定的探索灵活性。
>
> **流水线与装配线模式（Sequential Pipeline Pattern）** 运作机制：模拟人类标准化协作流水线（如瀑布式软件工程）。各 Agent 各司其职，前序 Agent 的输出经过标准化处理后作为后序 Agent 的输入。代表实现：ChatDev、CrewAI（Sequential 流程）。优势：输入输出标准统一，任务边界明确，上下文隔离好。局限：容错弹性较差，前序步骤出现的幻觉或偏差容易被下游放大。
>
> **环境共享记忆模式（Blackboard / Shared State Pattern）** 运作机制：源自传统人工智能的「黑板架构」。Agent 之间不进行直接的点对点通信，而是共同读写一个共享环境（如状态数据库、文件沙箱、任务看板或向量数据库）。Agent 监听环境变化并自主决定触发动作，产物写回黑板。代表实现：类似 AutoGPT、SWE-agent、Voyager。优势：高度解耦；天然支持异步并发与状态持久化。局限：并发读写冲突控制要求高，黑板数据的索引与状态一致性维护成本高。
>
> **对等辩论与共识模式（Multi-Agent Debate / Consensus Pattern）** 运作机制：多个配置不同模型、不同 Prompt 或持有不同视角的 Agent 针对同一任务发表见解、交叉质询并寻找漏洞，经过设定轮次后由裁判 Agent 或多数投票达成共识。代表实现：CAMEL、Multi-Agent Debate 系列研究、代码审查评审系统。优势：能显著抑制单一模型的事实幻觉与逻辑盲区。局限：多轮对话容易在无实际意义的细节上陷入震荡或死循环，收敛判定较难。
>
> **动态移交模式（Dynamic Handoff / Swarm Pattern）** 运作机制：每个 Agent 仅关注自己的局部职能，但配备了一组移交工具。当检测到用户诉求超出自身范围时，当前 Agent 主动调用移交工具，将对话上下文连同控制权平滑转移给下一个专业 Agent。优势：极度轻量、启动快、延迟低。局限：移交链条较长时可能出现死循环，难以应对强依赖多步规划的复合任务。
>
> 一共是六种基础架构，但是根据近期的研究论文及成果，第五种我个人并未产生很大的兴趣，但是对于第一、二、四这三种，我觉得还是很有进步空间的。
>
> 目前来看工业界的明显趋势是三者架构的融合版，不过仍然有很多问题，比如图结构和概率性模型二者的规划冲突，我对这个很感兴趣。
>
> 因为我目前在基于前段时间卡兹克开源的系统尝试架构一点 agent 的微内核尝试一下效果如何，图结构和概率性二者的结合对于这类信息源任务我觉得会很有帮助。

## 二、相关情报

笔记本身已是六种模式的系统梳理（研究级笔记）。补充背景核验：

- **模式-实现对应关系全部准确**：LangGraph（supervisor 与 graph 两种范式都覆盖）、CrewAI（hierarchical/sequential）、MetaGPT（SOP 化软件公司）、AutoGen（GroupChat）、CAMEL（角色扮演辩论）、ChatDev（瀑布流水线）均为该领域的代表性实现。
- **行业趋势印证**：「融合架构」已经是主流方向——LangGraph 从图编排起家后加入 supervisor 模式；AutoGen 0.4 起重构为事件驱动+分层编排；业界讨论焦点正是笔记指出的「确定性编排 vs 概率性决策」的张力（graph 给骨架，LLM 填判断）。
- **「卡兹克开源系统」**：指科技博主卡兹克（@Khazix0918）此前开源的 agent 系统（信息源追踪方向），笔记作者拟基于其做「agent 微内核」实验。

## 三、深度解读

**1. 这是一篇少见的「有立场的技术研究笔记」。** 六种模式覆盖完整，且作者明确表达了自己的判断（对第一/二/四种感兴趣、第五种不感兴趣、关注融合架构中图结构与概率模型的理论冲突）——这种「梳理+立场」的笔记形态本身就值得保留为个人知识库的范本。

**2. 对用户的实际工作场景映射。** 用户的自动化基础设施（每日评论任务、代聊、巡榜、迁移 pipeline）都是事实上的多 agent 协作：评论任务≈流水线模式（拉取→过滤→生成→发布）；代聊盯守≈动态移交+主从协调；巡榜/选题≈黑板模式（共享信息池+多来源写入）。理论框架的价值在于：当现有脚本化流程遇到瓶颈时（如需要 agent 自决策的环节），能快速定位该换哪种模式，而不是全部推倒重来。

**3. 「图结构 + 概率性结合」的方向与内容选题的接口。** 这个技术命题（确定性骨架 + 概率性填充）其实是一篇高质量的 AI PM 科普选题——《多 agent 系统为什么还没跑通：图给骨架，模型给判断》。用户有自动化实战经验（自己的多 agent pipeline 就是活案例），可以写出比其他科普号更「有体感」的版本。这篇文章的六个模式可以做成一张对比图（适合此前计划的视频化形态）。

**4. 与「不要自己搭 harness」的关系（同日 1503 笔记）需要辩证看。** 1503 说不要自研工作流基建（因模型迭代会吃掉中间层），本篇则是研究架构原理（微内核实验）。两者不矛盾：**原理层的研究要深（决定技术判断力），基建层的自研要省（用现成方案）。** 把研究结论用于「选型与判断」，而非「造轮子」。

## 四、标准化思路

**多 Agent 模式选择速查表**

| 场景特征 | 推荐模式 | 理由 |
|---|---|---|
| 任务可拆解、需集中调度 | 主从协调 | 权限清晰、可控 |
| 流程有明确状态与分支 | 图编排/状态机 | 确定性最高 |
| 标准化重复流程（发布/迁移） | 流水线 | 边界清楚、可复用 |
| 多来源信息汇集（选题库/监控） | 黑板 | 解耦、异步、可持久化 |
| 高风险决策（选型/事实核查） | 辩论共识 | 抑制幻觉 |
| 客服/多技能会话路由 | 动态移交 | 轻量低延迟 |

**动作项**：① 为现有自动化管线标注所属模式（发现混合模式的改进点）；② 「图结构+概率性」命题记入选题池（科普方向）。
