多 Agent 架构图示例

以下多 Agent 示例展示了协调方式如何变化——从单个 Supervisor 向工作 Agent 委派，到嵌套团队，再到直接对话的对等 Agent——以及人在其中的位置。

真实案例

使用场景: 构建首个多 Agent 系统的开发者

一个 Supervisor 规划并把工作路由给工作 Agent

工作 Agent：研究、编码、写作——各有自己的工具

工作 Agent 向 Supervisor 汇报，而非彼此汇报

共享记忆保存中间结果

Supervisor 决定整体任务何时完成

这样组织的原因: Supervisor 模式是最清晰的起点，因为控制是集中的——一个 Agent 拥有计划，所以你总能知道谁决定了什么，这让调试比群龙无首的方式容易得多。

使用场景: Agent 数量超出少数几个、需要扩展的团队

顶层 Supervisor 委派给团队负责人 Agent

每个团队负责人监督自己的一组工作 Agent

例如：一个「研究团队」和一个「构建团队」归属同一顶层 Agent

记忆按范围划分——团队本地 + 共享全局存储

失败在团队内部被消化后才向上升级

这样组织的原因: 分层是多 Agent 系统在不让单个 Supervisor 成为瓶颈的前提下扩展的方式——子 Supervisor 吸收本地协调，使顶层 Agent 推理的是团队而非单个工作 Agent。

使用场景: 构建直接协商的 Agent 的工程师

没有中央 Supervisor——Agent 之间互相发消息

每个 Agent 自行决定移交什么、移交给谁

共享消息总线或黑板协调状态

适合对等 Agent 之间的辩论 / 评审循环

风险：更难追踪，且可能在没有停止条件时陷入循环

这样组织的原因: 点对点用 Supervisor 的清晰度换取灵活性——Agent 自组织，适合辩论和评审模式，但图表必须画出停止条件，否则系统可能无限循环。

使用场景: 为高风险输出部署 Agent 的团队

Supervisor 照常委派给工作 Agent

在不可逆操作之前设置审批关卡暂停

由人审阅并批准、拒绝或编辑

批准的工作继续；被拒的工作路由回某个工作 Agent

每个决策都记录在案以供审计

这样组织的原因: 当 Agent 输出有真实后果时，人在回路必不可少——图表把审批关卡画明确，让评审者一眼看清系统行动前人必须在何处签字确认。

回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。