不要用框架名称来分类多 Agent 模式，用工程维度来分类。任何真实系统通常同时组合多种模式——例如：监督者 + 并行扇出 + 黑板 + 验证器 + 人工审批 + MCP。
| 类型 | 控制权所在位置 | 代表模式 | 适用场景 |
|---|
| 集中式 | 一个协调者/管理者掌控流程 | 监督者、代理即工具、路由 | 稳定的生产流程、工单分诊、企业任务 |
| 转移式 | 当前活跃 Agent 可移交控制权 | 交接 | 多领域专家切换、长对话 |
| 层次化 | 管理者管理工作者；工作者可进一步分解 | 层次化 | 大型项目、跨团队、多阶段工作 |
| 去中心化 | 无固定中心；Agent 自行通信或中继 | 点对点、群集 | 开放式探索、自治网络 |
| 类型 | 信息如何流动 | 代表模式 |
|---|
| 线性的 | A 的输出给 B，B 的输出给 C | 顺序管道 |
| 并行的 | 多个 Agent 并发运行；结果合并 | 并行扇出 / 汇聚 |
| 共享线程的 | 多个 Agent 在同一线程中对话 | 群聊 |
| 内部会话的 | 一个 Agent 触发内部子对话 | 嵌套对话 |
| 共享状态的 | Agent 不直接对话；它们读写同一工作区 | 黑板 |
| 事件流的 | 通过主题/队列/事件总线通信 | 事件总线 / 发布-订阅 |
| 类型 | 如何做出决策 | 代表模式 |
|---|
| 管理者拍板 | 协调者选择下一步 | 监督者、路由 |
| 评审者评判 | 评审者/验证器给质量打分 | 生成器-评审者 |
| 迭代式 | 循环直到某个条件满足 | 精炼循环 |
| 对抗式 | 正反方辩论；由裁判下结论 | 辩论 / 裁决 |
| 集体式 | 多个 Agent 投票或集成 | 投票 / MoA |
| 市场式 | Agent 竞标、出价或谈判 | 市场 / 合同网 |
| 类型 | 侧重点 | 代表模式 |
|---|
| 角色驱动 | Agent 拥有职业角色和 SOP | 角色扮演 / 虚拟公司 |
| 环境隔离 | Agent 在不同工作区/沙箱中运行 | 工作区隔离 |
| 人在回路 | 人是一个特殊 Agent——批准、纠正 | 人在回路 |
| 环境中介 | Agent 通过修改共享环境来协作 | 共识主动性 |
| 模拟学习 | Agent 在模拟环境中交互或训练 | 社会模拟 / MARL |
| 协议 | 谁连接谁 | 用途 |
|---|
| MCP | Agent ↔ 工具 / 资源 / 提示 | 标准化暴露工具、数据、提示 |
| A2A | Agent ↔ Agent | 跨框架、跨供应商的 Agent 协作 |
| ACP / ANP | Agent ↔ Agent / 网络 | Agent 通信、身份、网络发现 |
| Agent Client Protocol | IDE / 客户端 ↔ 编码 Agent | 编辑器和编码 Agent 之间的标准化连接 |
当任务规模超出单轮对话、甚至超出少量子智能体的稳定范围时，编排逻辑应当从「每轮临场判断」固化为显式代码。
| 类型 | 编排逻辑在哪里 | 代表模式 |
|---|
| 对话式编排 | 隐含在主智能体每轮推理中 | 监督者、子智能体即工具 |
| 团队协作 | 共享任务列表 + 互发消息 + lead | Agent Teams（参见监督者 / 管理者） |
| 代码编排 | 一段可执行脚本持有计划、循环、扇出、验证与收敛 | 动态工作流 / 代码编排子智能体 |
代码编排把计划变成一等产物（脚本），中间状态留在脚本变量、可恢复、可保存复用，规模可达数百个子智能体。完整工程实践见工作流板块。
不要问"哪种多 Agent 模式最强大"——要问：
- 任务是否需要分解？
- 子任务能否并行运行？
- 是否需要某个专家来主导对话？
- 是否需要审查和回滚？
- 是否需要跨系统互操作？
- 是否需要长生命周期状态和可观测性？
如果以上答案大多是"否"，那还不需要多 Agent。一个拥有合适工具和正确上下文的单一 Agent 通常更可靠。
