架构定了框架才好选：把 CrewAI、AutoGen、LangGraph、OpenAI Agents SDK 对回五种多智能体架构
选多智能体框架的文章很多，讲多智能体架构的文章也很多，但两件事往往各说各的：一边列“有哪几种架构”，一边列“有哪几个框架”，中间缺一座桥。这篇文章试着把桥搭上——先从架构拆出结构要素，再拿要素去对照框架的优化方向，最后落成一张可以直接用的选型表。
一、五种架构，各需要什么结构要素
依据《多智能体系统详解：定义、优势与应用》一文，最常见的五种多智能体架构是：层级式（主管与执行者）、协作式（同级协作）、对抗式（竞争与批评）、异构式（混合模型与工具）以及基于图的架构（带分支和循环的状态机）。该文明确指出，选择哪种架构取决于你的任务需要指挥链、同级协作、内置批评机制、多样化能力，还是复杂的条件路由。
这句话本身就给出了每种架构的“结构要素”：
| 架构 | 核心结构要素 | 典型场景 |
|---|---|---|
| 层级式 | 指挥链：主管拆解任务、分配执行者、汇总结果 | 研究与综合、带升级机制的客服工作流 |
| 协作式 | 同级消息：智能体互传消息、共享上下文 | 群聊式头脑风暴、并行分析 |
| 对抗式 | 内置批评：一方产出、一方审查，竞争出结果 | 多视角评审（安全/风格/正确性评审） |
| 异构式 | 混合工具：不同智能体绑定不同模型与工具 | 提取—校验—格式化的数据流水线 |
| 基于图 | 状态机路由：带分支和循环的条件跳转 | 流程可预定义、但路径依赖中间结果的流水线 |
《什么是多智能体系统？| Swarms 博客》补充了一个关键的落地视角：智能体之间的通信——“一个智能体的输出如何变成另一个智能体的输入”——可以简单到把文本回复直接传给下一个智能体的提示词，也可以复杂到维护一份共享消息日志。而交接的具体机制，即传递什么、总结什么、丢弃什么，在实践中非常关键。换句话说，五种架构真正的差别，往往就体现在通信交接的形态上：层级式是“上报—下发”，协作式是“广播—互读”，对抗式是“产出—驳回”，异构式是“结构化传递”，基于图则是“状态驱动的条件跳转”。
二、角色边界与通信交接：检验框架的两把尺子
Swarms 的博客里有一句很锋利的话：清晰的角色边界，正是防止多智能体系统退化成“拆分成多次 API 调用的一个巨大、松散的提示词”的关键。“研究员”智能体的系统提示词不应该同时去规定最终格式，“审阅者”的职责是评审输出，而不是从零生成内容。
把这两把尺子——“角色边界是否清晰”和“通信交接由谁定义”——拿去对照框架，会发现每个框架其实都在优化某一类问题结构：
CrewAI：优化“角色化工作流”的结构。它的核心抽象就是角色（role）、目标（goal）、背景（backstory），天然匹配层级式与协作式架构中“指挥链 + 明确分工”的需求。如果你的任务能自然地写成“谁负责什么、按什么顺序做”，CrewAI 的结构最省力；反过来，如果你的任务需要大量运行时的条件分支，它的抽象就略显不够。
AutoGen：优化“对话式智能体”的结构。它把多智能体协作建模为智能体之间的对话，天然匹配协作式与对抗式架构——同级的来回讨论、一方产出另一方批评，都能用“多轮对话 + 消息日志”表达。代价是指挥链需要你自己在对话编排里搭出来，且对话轮数容易推高 token 成本。
LangGraph：优化“有状态图工作流”的结构。它把智能体协作建模为一张带分支和循环的图，状态显式保存、路由显式定义，是五种架构中对“基于图”这一种最直接的对应。Swarms 博客强调的“传递什么、总结什么、丢弃什么”，在 LangGraph 里基本是对图上的边和状态字段的显式设计，控制力最强，前期设计成本也最高。
OpenAI Agents SDK：优化“轻量级原型”的结构。它面向快速起步，适合在架构尚未定型时验证想法。要素最少意味着自由度最大，但也意味着层级、对抗、状态机这些结构都要靠你自己补。
三、选型表：架构 × 框架 × 团队/任务规模
综合《多智能体系统详解：定义、优势与应用》对框架定位的描述——CrewAI 面向角色化工作流、AutoGen 面向对话式智能体、LangGraph 面向有状态图工作流、OpenAI Agents SDK 面向轻量级原型开发，且“每种框架都针对不同的问题结构和团队规模做了优化”——可以落成这样一张表：
| 你的任务结构 | 对应架构 | 首选框架 | 适用情况 |
|---|---|---|---|
| 有清晰指挥链，角色分工明确 | 层级式 | CrewAI | 小团队快速搭流水线，任务能提前画清楚 |
| 需要同级讨论、来回打磨 | 协作式 | AutoGen | 探索性任务，结果形态事先不定 |
| 需要产出者与批评者制衡 | 对抗式 | AutoGen / CrewAI | 多视角评审、代码与文档审查 |
| 不同步骤需要不同模型与工具 | 异构式 | CrewAI / LangGraph | 提取—校验—格式化类数据流水线 |
| 路由依赖中间结果，有分支循环 | 基于图 | LangGraph | 流程复杂但可预定义，需要可追溯 |
| 还不知道该用哪种架构 | — | OpenAI Agents SDK | 原型验证，跑通再迁移 |
四、适用范围与局限
最后泼点冷水。这张表只回答“结构匹配”问题，不回答成本与稳定性问题。同一篇资料指出的常见故障值得放在选型前想清楚：智能体之间沟通不畅、输出结果相互矛盾且难以调和、编排器出现单点故障，以及随着智能体数量增加而成本呈指数级增长。对应的缓解手段——清晰的路由逻辑、增加审核智能体、监控 token 成本、保持编排过程可追溯——有的恰好是框架原生能力（如 LangGraph 的显式状态），有的则需要你自己在框架之上补。
另外，Swarms 博客提醒得很对：多智能体的意义不在于智能体数量越多越好，而在于让系统的结构去匹配任务本身的结构。很多任务用一次精心设计的单智能体调用就够了；只有当任务真的需要指挥链、同级协作、内置批评、混合能力或条件路由时，多智能体才值得上。架构先想清楚，框架只是把结构写下来的工具——顺序反了，表就成了装饰。
参考资料
以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中；资料内容与适用范围以原始页面为准。
- 多智能体系统详解：定义、优势与应用
- 什么是多智能体系统？ | Swarms 博客
