【AI】LangGraph & AutoGen & CrewAI

核心判断：三者不是同一件事的三种实现，而是对"多智能体系统应该长什么样"的三种根本不同信念。选型的真正主轴，是你需要多少【显式控制】与你想多快上线之间的权衡。

LangGraph —— 控制优先。 把编排显式建模为状态图，执行引擎受 Google Pregel 启发、以离散"超步"推进[1]。开发者亲手写节点、边、状态合并规则，换来生产级的可预测性与可控性[2]，代价是学习曲线陡。
AutoGen —— 交互优先。 把协作建模为智能体之间的对话；v0.4 从零重构为异步、事件驱动架构[3]，消息通过运行时按主题/订阅路由[4]。适合探索性、研究型的多智能体交互。
CrewAI —— 抽象优先。 把编排包装成"角色 + 任务 + 流程"的高层流水线，用 Agent(role/goal/backstory)、Task、Crew 四个原语快速搭出可运行团队[5]。上手最快，控制粒度最粗，但 Flows 补上了事件驱动的精细编排[6]。
一条不能忽略的时效信号： AutoGen 已进入维护模式，并于 2025 年 10 月与 Semantic Kernel 归并为 Microsoft Agent Framework，官方建议新项目改用后者[7]。这直接影响新项目是否应把 AutoGen 作为长期技术底座。

一、三框架出身与定位

三者的"出身"几乎决定了各自的设计基因：LangGraph 生于 LangChain 生态，天然面向需要精细工程控制的开发者；AutoGen 生于微软研究院，带着"研究驱动"的探索气质；CrewAI 是独立创业公司的产物，从第一天就以"让人快速搭起一支 AI 团队"为卖点。

维度	LangGraph	AutoGen	CrewAI
出身 / 维护者	LangChain Inc.（LangChain 的创造者），可脱离 LangChain 独立使用[8]	微软研究院（Microsoft Research）[9]	João Moura 于 2023 年创立的独立公司 CrewAI Inc.[10]
开源协议	核心运行时 MIT[11]	MIT[12]	MIT[13]
核心定位	低级（low-level）编排框架，强调对状态、循环、人机交互的细粒度控制[14]	加速智能体 AI 开发与研究的灵活框架[9]	角色扮演式的多智能体编排框架，四原语快速组队[5]
目标用户	需要对 LLM 工作流做细粒度控制的工程师[14]	研究者与需要探索多智能体交互模式的开发者[9]	希望快速上手、按业务角色建模的应用开发者[5]
商业化路径	LangGraph Platform / Studio + LangSmith 可观测性[15]	AutoGen Studio 无代码 GUI[7]；企业能力并入 Microsoft Agent Framework[16]	CrewAI AMP 企业平台 + 2024 年 10 月 1800 万美元 A 轮融资[10]

Synthesis: 三个协议都是 MIT，所以"开源与否"不是区分点；真正的区分从定位开始——LangGraph 自称"low-level"，AutoGen 自称"research framework"，CrewAI 自称"role-based orchestration"，一句自我介绍就暴露了三种截然不同的抽象层次取向。

1.1 一个反直觉的谱系事实

LangGraph 与 CrewAI 在血缘上都与 LangChain 有过关系，但走向相反。LangGraph 由 LangChain 团队亲自打造、深度复用 LangChain 生态（如直接用 ToolNode 调用 LangChain 工具）[17]；CrewAI 则相反——早期构建于 LangChain 之上，2024 年经过重写、将 LLM 访问改为通过 LiteLLM 路由以走向独立[18]，此后版本进一步完成彻底解耦[19]。关于"何时算完全独立"，不同资料口径不一（有的强调 2024 年重写，有的以后续 1.14 版为里程碑），本文按"2024 年重写走向独立、后续版本完成解耦"的口径叙述，避免把单一时间点当作定论。

二、核心原理逐层拆解

三个框架最本质的差异藏在"执行模型"里。同样是"让多个智能体协作完成任务"，三者的运行形状完全不同，绝不能用"都是多智能体编排"一句话糊过去。

LangGraph：状态图循环 控制流是一张显式的图。引擎受 Pregel 启发，程序以离散【超步】推进，每个超步是对图节点的一次迭代[20]。

AutoGen：对话消息循环 控制流是智能体之间的消息往返。v0.4 中智能体通过异步消息通信，支持事件驱动与请求/响应两种模式[21]。

CrewAI：角色任务流水线 控制流是"谁演什么角色、按什么流程干活"。Crew 编排器把 Agent 与 Task 组合起来顺序或分层推进[22]。

2.1 LangGraph：把控制流编译成状态图

LangGraph 的主入口是 StateGraph，它接受一个类型化的状态架构（如 TypedDict 或 Pydantic）[23]。开发者用两种基本元素搭图：节点执行具体逻辑函数，边指示下一步流向；简言之"节点完成工作，边指示下一步该做什么"[24]。真正让它成为"图灵完备编排"的是条件边——它能根据节点返回的当前状态动态决定下一个执行的节点[25]，这正是循环与分支的来源。

状态管理是 LangGraph 最容易被误读的部分。它的每一个状态键本质上是一个通道（Channel），而 Reducer 是该通道的更新函数[26]。默认行为是"最后写入者胜（last-write-wins）"，但通过 Annotated 类型提示可以指定累加等合并逻辑[27]。

执行引擎是理解 LangGraph 的关键。它是 LangGraph 的核心运行时，实现了受 Google Pregel 系统启发的消息传递图计算模型[1]。程序以离散超步推进，其中同一超步内的节点并行执行，不同超步之间顺序执行[20]。这个机制解释了为什么 LangGraph 天然支持"扇出并行 + 汇聚"，而不需要开发者手写线程调度。

LangGraph 的可控性来自"状态显式化 + 执行确定化"两件事叠加。 状态是通道、合并规则由 Reducer 显式声明，执行由超步严格排序——正因如此，它能提供检查点、时间旅行、断点中断这类生产级能力，而不是把这些当作黑盒里的隐藏行为。

状态持久化由**检查点（Checkpointer）**实现，支持从特定配置恢复执行或查看历史状态（get_state / update_state）[28]；对长对话线程，DeltaChannel 只记录每步增量而非完整状态，避免检查点体积随线程线性增长[29]。在此之上，**断点/中断（Interrupts）让执行在指定节点前后暂停以供人工审阅、批准或修改状态[30]，而时间旅行（Time-travel）**允许回溯到任意历史状态、修改后创建不同的执行分支[31]。工具侧则无缝复用 LangChain 生态，用 ToolNode 直接调用现有工具[17]；可观测性由 LangSmith 提供端到端追踪与调试[15]。

2.2 AutoGen：把协作建模成智能体对话

AutoGen v0.2 的核心抽象是可对话智能体（Conversable Agent）——开发者通过自然语言或代码来编程智能体之间的交互[32]。这与 LangGraph 的"先画图再执行"是两种世界观：AutoGen 里没有预先编译的控制流图，行为在对话回合中涌现。

v0.4 是一次从零开始的重构，采用异步、事件驱动架构，专门解决可观测性、灵活性、交互控制与规模化问题[3]。新架构是分层的：底层 Core API 是可扩展的事件驱动 Actor 框架，其上的 AgentChat API 是面向任务的高层框架，再加上扩展性的 Extensions API[33]。

通信机制在 v0.4 中被彻底重写。Core 引入主题（Topic）与订阅（Subscription），由运行时把消息路由到特定智能体实例[4]；智能体之间通过异步消息通信，支持事件驱动与请求/响应两种模式[21]。群聊则是这套机制的应用：每个参与智能体同时订阅群聊主题和自己的个人主题，通过 RequestToSpeak 消息由群聊管理器协调发言权[34]。

Synthesis: 注意这里的精确区别——AutoGen 的"群聊管理器分配发言权"看起来像 CrewAI 的"Manager Agent 分派任务"，但底层完全不同：AutoGen 是异步消息发布/订阅路由，CrewAI 是任务流水线里的委派节点。相似的表象，不同的机制。

状态与记忆方面，v0.4 提供 save_state / load_state 方法保存和加载智能体状态、实现会话恢复[35]，并通过 autogen_ext 集成 Mem0，支持云端与本地后端的持久化记忆[36]。工具集成走 function calling 与代码执行路线，可观测性则内置基于 OpenTelemetry 的链路追踪，可对接任意兼容后端收集分析[37]。此外，微软还基于该框架构建了通用多智能体系统 Magentic-One：由一个 Orchestrator 智能体引导，通过"任务账本（Task Ledger）“管理规划与进度[38]，并配备 WebSurfer、FileSurfer、Coder、ComputerTerminal 四个专用智能体[39]。

2.3 CrewAI：把编排收敛成角色任务流水线

CrewAI 的心智模型建立在四个原语上：Agents、Tasks、Tools 和作为编排器的 Crew[5]。其中 Agent 是由**角色（role）、目标（goal）、背景故事（backstory）**定义的角色化 LLM 工作者[5]——这套拟人化建模正是它上手快的根源：开发者不必先理解图或消息路由，只要"招人、派活”。

流程编排提供两种主策略：**Sequential（线性推进）**与 Hierarchical（管理者主导的委派）[22]。在层级流程里，一个 Manager Agent 协调工作流、按能力委派任务并验证结果[40]。值得注意的是，社区有时提及的"Consensual（共识）“流程截至 2026 年初仍是规划中的特性、尚未在代码库中实现[41]，选型时不应把它当作可用能力。

CrewAI 有两套编排层，别混为一谈。 Crew（Sequential/Hierarchical）是"角色任务流水线”，适合可以委派的协作；而 Flows 是后加的事件驱动编排层——它用 @start、@listen、@router 装饰器把方法接成一张有向图，用 Pydantic 模型承载跨步骤的类型化状态[42]。需要精确流程控制时，真正对标 LangGraph 图的是 Flows，而不是 Crew。

Flows 本身被定位为结构化、事件驱动的工作流原语，用于连接多个 Task 与 Crew、管理状态、控制执行流[6]，其状态通过一个所有步骤都可读写的 Pydantic 模型集中管理[43]。记忆方面，CrewAI 提供统一记忆系统：用单个 Memory 类通过一套 API 提供短期、长期、实体与上下文记忆[44]；其中短期记忆让智能体引用同一次运行内的先前交互，长期记忆则在本地跨多次执行持久化[45]。工具上它兼容 LangChain 生态工具，可直接接入计算器、搜索、文件读取等能力[46]；可观测性依赖第三方集成，如 AgentOps、LangFuse 与 Amazon CloudWatch[47]。

三、设计哲学与取舍

从 API 设计、默认行为与约束程度，可以反推出三支团队对"多智能体系统应该长什么样"的核心信念。它们不是能力高低的差别，而是把复杂度放在哪里的抉择。

LangGraph：控制即显式图 信念是"生产级 Agent 必须可预测"。用显式状态机精确控制每一步、为生产系统提供治理能力[2]。复杂度交给开发者显式承担。

AutoGen：程序即对话 信念是"智能体协作应像人对话一样涌现"。协作通过自然语言消息传递实现，而非传统函数调用或状态机[48]。复杂度藏在对话动态里。

CrewAI：编排即角色扮演 信念是"按人类组队方式建模最直观"。用 role/goal/backstory 拟人化建模[5]，让业务语义直接映射为团队结构。复杂度被高层抽象吸收。

3.1 默认行为暴露的取舍

LangGraph 的默认是"什么都不替你决定"。 状态合并默认 last-write-wins，但要累加就得自己用 Annotated 声明 Reducer[27]；要持久化就得显式挂 Checkpointer[28]。这种"默认最小、能力靠显式声明"的风格，正是 low-level 框架的标志——它假设使用者是要对每一步负责的工程师。

AutoGen 的默认是"让智能体先聊起来"。 v0.2 就允许用自然语言编程交互[32]，v0.4 把这套对话进一步异步化、事件化以支撑规模与可观测性[3]。它假设很多有价值的行为无法预先画成图，而应在交互中被发现——这解释了它在研究与探索场景的天然优势。

CrewAI 的默认是"给你一个能跑的团队"。 四原语加两种流程，几行配置就能起一支 Crew[5]。它把"多智能体系统"翻译成招聘和排班这类人人都懂的隐喻，用高层抽象换取上手速度。

3.2 悖论：越易用，越需要补回控制

三者存在一个共同的张力：抽象层次越高，越容易上手，也越容易在复杂场景撞上控制天花板。CrewAI 最能说明这一点——正是因为 Crew 的角色流水线难以表达复杂分支与循环，团队才追加了基于装饰器和有向图的 Flows 来补回精细编排[42]。

Synthesis: 反过来看 LangGraph 也在向易用性妥协：它在 2025 年初引入函数式 API，用 @entrypoint 和 @task 装饰器简化简单流程的构建[49]。两个方向相向而行——高层框架下探控制力，低层框架上探易用性——说明"控制 vs 易用"不是非此即彼，而是每个框架都在自己的原点附近向对方靠拢。

四、多维度交叉对比

下表在十个工程维度上对齐三者。阅读要点：没有"全面胜出"的框架，每一格的差异都能追溯回第二、三章的机制差异。

维度	LangGraph	AutoGen	CrewAI
控制粒度	最细：节点/边/条件边逐步显式控制[24]	中：对话回合与消息路由驱动[21]	粗（Crew）→ 细（Flows 有向图）[42]
灵活性 / 可控性	可控性极高，为生产系统提供治理[2]	交互模式灵活，行为在对话中涌现[32]	高层灵活、低层受抽象约束
学习曲线	陡：需理解图、通道、Reducer[26]	中：需理解异步消息与订阅模型[4]	平缓：四原语快速上手[5]
适用任务规模	复杂、长周期、需循环与分支的工作流[14]	可分布式、可跨语言的大规模交互[9]	中小型、可按角色拆解的协作任务[5]
人工介入（HITL）	原生最强：断点中断 + 时间旅行[31][30]	经 UserProxy/对话回合介入，无原生时间旅行	依赖流程设计，无原生中断/回溯
多 Agent 编排模式	状态图 + 超步（Pregel）[1]	异步消息 + 主题/订阅群聊[34]	顺序/层级流程 + Flows 事件编排[22][6]
状态与持久化	Checkpointer + DeltaChannel 增量存储[29][28]	save_state/load_state + Mem0 集成[36][35]	统一记忆系统（短/长/实体/上下文）[44]
可观测性 / 调试	LangSmith + LangGraph Studio IDE[15]	内置 OpenTelemetry 追踪 + Studio[37]	第三方集成：AgentOps/LangFuse/CloudWatch[47]
生态成熟度	依托 LangChain 生态，Python + TS 双版本[50]	微软背书，但核心已进入维护模式[7]	独立生态，A 轮融资 + 企业平台 AMP[10][51]
许可与治理	核心 MIT，商业化靠 Platform/LangSmith[11]	MIT，企业能力迁往 Microsoft Agent Framework[12][16]	MIT，企业版含 SOC2 Type II、PII 脱敏[13][52]

Synthesis: 把这张表压成一句话——HITL 和状态治理选 LangGraph，探索式交互与微软生态选 AutoGen（但注意维护模式），快速交付与角色化建模选 CrewAI。 三个"最强"格分布在不同行，恰恰证明它们不可互换。

五、场景匹配与选型建议

选型的第一原则不是"哪个更强"，而是"你的任务形状更像图、更像对话，还是更像流水线"。任务形状对了，框架的默认行为就是助力而非阻力。

5.1 三类典型场景的对号入座

框架	最擅长的 2-3 类场景	底层原因
LangGraph	① 需强人工审批/回溯的生产级 Agent；② 含复杂循环与条件分支的长流程；③ 对可预测性、可追溯性要求高的关键系统	状态显式化 + 超步确定执行 + 断点/时间旅行[31][30]
AutoGen	① 多智能体交互模式的研究与原型；② 需异步、分布式、跨语言的大规模智能体系统；③ 对话涌现式的问题求解（如 Magentic-One 式通用任务）	异步事件驱动 Actor 架构 + 对话涌现[3][38]
CrewAI	① 可按角色拆分的业务自动化（研究、内容、分析流水线）；② 需要快速验证的中小型多智能体 PoC；③ 需企业级部署（SOC2/PII）的角色化团队	四原语高层抽象 + Flows 补精细编排 + 企业平台[5][52]

5.2 需求混合时如何权衡

现实项目常常"既要可控、又要快上手"。此时不必二选一，可按控制力需求分层组合：

控制力主导型（如金融、医疗审批链）： 以 LangGraph 为骨架，把人工介入做成断点中断[30]，牺牲一点开发速度换取可审计性。
速度主导型（如内容/研究自动化）： 以 CrewAI Crew 快速搭出角色团队[5]，当某段流程需要精确分支时，用 Flows 局部升级为有向图[42]，避免一开始就上重型框架。
探索主导型（如新交互模式研究）： 用 AutoGen 快速试验对话编排[32]，但若要沉淀为长期生产系统，需重新评估其维护模式状态（见第六章）。

一个务实的组合心法：用高层框架搭原型、用低层框架做生产。 CrewAI/AutoGen 适合把"能不能跑通"验证出来，LangGraph 适合把"跑通的东西变成可运维、可审计的系统"。三者可以是项目不同阶段的接力，而非互斥的一次性抉择。

六、演进方向与生态现状

三个框架当前的走向，共同勾勒出多智能体框架设计的几个明确趋势——也直接改变了"新项目该押哪个"的答案。

6.1 AutoGen：进入维护模式，能力上移到 Microsoft Agent Framework

这是本轮对比中最具决策分量的变化。微软已宣布 AutoGen 与 Semantic Kernel 归并为新的 Microsoft Agent Framework，以整合两者的经验教训、提供企业级支持[16]；随之，原始 AutoGen 框架已进入维护模式，官方明确建议新项目使用新的集成框架[7]。

对选型的直接含义：把 AutoGen 作为全新长期生产底座需要谨慎。 它的 v0.4 异步 Actor 架构与 OpenTelemetry 追踪仍是优秀工程范例[3][37]，AutoGen Studio 也仍提供无代码 GUI 用于快速构建[7]；但既有能力的持续演进已转向 Microsoft Agent Framework。用于学习、研究、既有系统维护没问题；用于新建长期项目，应把迁移成本纳入评估。

6.2 LangGraph：低层框架向"工程稳态"打磨

LangGraph 的演进方向是把生产级能力做深做稳。可确认的当前主线是 1.2.x 系列（1.2.6 于 2026 年 6 月发布），核心更新包括支持崩溃持久化的错误处理程序恢复与节点级超时控制[53]。与此同时，它也在降低门槛——2025 年初引入函数式 API，用 @entrypoint / @task 简化简单流程的构建[49]，并维护 Python 与 TypeScript 双版本、共享 StateGraph 等核心概念[50]。

需要说明的是，社区中存在关于"LangGraph 2.0"的说法（称其以状态机范式革新编排）[54]，但这一版本号未能与公开发布记录对齐，本文按可核验的 1.2.x 主线叙述，不将"2.0"作为已确定的事实采用。

6.3 CrewAI：从开源框架走向企业平台

CrewAI 的演进有两条线：一是产品能力，用 Flows 的事件驱动编排补齐 Crew 在精细控制上的短板[6]；二是商业化与合规，推出企业平台 CrewAI AMP 用于生产环境的部署、监控与扩展[51]，并提供可在自有基础设施（AWS/Azure/GCP 私有云或本地）安全部署的 AMP Factory[55]，企业版含 SOC2 Type II 认证与 PII 检测脱敏[52]。2024 年 10 月由 Insight Partners 领投的 1800 万美元 A 轮融资，为这条企业化路线提供了资本支撑[10]。

6.4 共同趋势：三个信号

Synthesis: 把三条演进线放在一起看，多智能体框架的设计正朝三个方向收敛：

高层与低层相向而行。 CrewAI 用 Flows 下探控制力，LangGraph 用函数式 API 上探易用性——“控制 vs 易用"正从对立走向可调节的连续谱[49][42]。
可观测性成为标配而非加分项。 从 LangSmith 到 OpenTelemetry 再到第三方集成，三家都把"能追踪每一步决策"当作生产前提[47][15][37]。
框架整合加速，生态开始洗牌。 AutoGen 并入 Microsoft Agent Framework 是标志性事件[16]——单打独斗的实验性框架正让位于有企业级支持与治理能力的整合平台，这也是新项目选型时必须纳入的长期变量。