三种协作框架的控制流对比
这三个框架构成什么递进线索？
- 线索: MetaGPT 的控制流其实是固定流水线（伪去中心化，只在通信机制上解耦），AutoGen 群聊是共享对话记录加中心化调度的混合形态，直到 OpenAI Swarm 才在控制流上做到真正的对等去中心化;
| 框架 | 控制流 | 信息共享 | 去中心化程度 |
|---|---|---|---|
| MetaGPT | 固定 SOP 流水线 | 共享消息池 + 按角色订阅 | 通信解耦，控制集中 |
| AutoGen GroupChat | 中心化发言者选择器 | 全体共享同一份公共对话记录 | 混合 |
| OpenAI Swarm | 对等 handoff，无中心调度 | 只传任务包与产物引用 | 真正对等 |
MetaGPT 如何用 SOP 驱动多角色协作？
- 核心洞察: 人类软件公司积累的标准作业程序（SOP，Standard Operating Procedure）本身就是被反复验证过的协作协议;
- 做法: 把 SOP 编码进多 Agent 系统，让每个角色像流水线上的专业工种一样产出标准化交付物，交付物天然构成角色间的通信接口;
- 角色顺序: Product Manager → Architect → Project Manager → Engineer → QA;
| 角色 | 输入 | 产出 |
|---|---|---|
| Product Manager | 需求描述 | 结构化 PRD（功能列表、用户故事、验收标准、优先级排序） |
| Architect | PRD | 设计文档（技术栈、模块划分、接口定义、数据模型） |
| Project Manager | 架构设计 | 任务清单与文件级分工、模块依赖顺序 |
| Engineer（可多实例并行） | 设计文档 | 所负责模块的代码 |
| QA Engineer | 代码与 PRD | 测试用例、bug 记录、测试报告 |
- 移交包要素: 任务描述（做什么、验收标准）、已确认的事实与约束（用户偏好、业务规则、前序敲定的决策）、结构化产物的引用（文件路径而非文件内容，接收方按需读取）;
- 认知要求: 每个 Agent 不需要理解其他 Agent 的"思考过程"，只需要理解移交包和产物的格式与语义;
MetaGPT 对去中心化通信贡献了什么？
- 机制: 共享消息池 + 按角色订阅——每个角色把结构化消息发布到所有角色可见的消息池，其他角色按订阅配置只取用与自身职责相关的消息，而不是点对点传话;
- 发布者视角: 不需要知道谁会消费自己的输出;
- 扩展性: 新增角色只需声明订阅哪些消息类型，无需改动任何现有角色;
- 解耦收益: 把 Product Manager 换成更强的模型，只要它发布的 PRD 仍符合规范，其他所有 Agent 都无需修改;
- 如实澄清: MetaGPT 在控制流上并不是去中心化的——角色顺序由 SOP 预先固定，整体更接近流水线（工作流）;
- 未实现部分: "QA 直接找 Product Manager 澄清需求""Engineer 找 Architect 讨论替代方案"这类多向动态反馈是对该架构的自然扩展设想，原版并未实现;
AutoGen 群聊与 OpenAI Swarm 分别属于哪一形态？
- AutoGen 群聊: 多个 Agent 参与同一场会话，每轮由一个"发言者选择器"决定下一个发言者，可以是简单轮转规则，也可以是 LLM 根据当前对话判断谁最适合接话;
- AutoGen 的可见性: 任何 Agent 的发言对所有参与者可见;
- AutoGen 的集中点: 发言者选择由中心化的 GroupChatManager 统一裁决，而"轮到谁发言"本身就是一种控制流决策;
- AutoGen 的组合: 所有 Agent 看到同一份公共对话记录，但各自保有独立的系统提示词与工具集，调度权集中在选择器手里;
- OpenAI Swarm: 每个 Agent 配备若干 handoff 选项，可以在任意时刻把控制权移交给网络中的任意其他 Agent，路由决策完全分散在每个 Agent 自己的判断里;
- 安全约束: handoff 只传明确的任务包与产物引用，不默认暴露完整私有轨迹；移交次数上限用于防环;
- 协议细节见 去中心化模式;