多智能体框架怎么选:LangGraph、CrewAI、AutoGen 与 open-multi-agent 的取舍
选框架别盯着 star 数,看它的抽象方式跟你合不合。粗暴版:要能精确控住流程,LangGraph;想一下午搭出个角色分工的原型,CrewAI;研究 Agent 之间怎么对话,AutoGen;后端是 TypeScript、想给个目标让它自己拆任务,open-multi-agent。往下展开说。
这几个框架最大的差别不在功能列表,在它逼着你怎么想问题。同样是「让三个 Agent 协作写份报告」,换个框架,你脑子里要装的东西完全不一样——有的让你先画流程图,有的让你先定义角色,有的让你先设计对话。选型选的其实是这个,不是 feature 多少。
LangGraph
核心是一张你自己画的状态图:定义好节点(每一步干什么)、边(什么条件跳到哪),剩下的执行、断点续跑、流式输出、人工介入,框架帮你兜。四个里它生产打磨最狠,要精确控流程、要能恢复能审计,基本就是它。代价也直接:学习曲线最陡,你得先把问题想透了才画得出图。主力语言是 Python,JS 版(langgraphjs)也有。
CrewAI
换个路子——不画图,定义角色。给每个 Agent 一个 role、一个 goal、一段 backstory,凑成一个 crew 让它们协作。上手最快,想在一下午里搭出个「多角色分工」的原型,门槛它最低。后来补的 Flows 加上了事件驱动的编排,生产上也撑得住。纯 Python,用的人非常多。
AutoGen
微软的思路是让 Agent 互相聊——群聊、辩论、吵到达成共识,靠对话把任务往前推,对话花样是几个里最多的。但有件事得摊开说:2026 年初微软已经把 AutoGen 转进了维护模式(现在由社区维护),新特性都挪去了 Microsoft Agent Framework。现在拿它做研究、做原型没问题,要押一个新的生产项目,得三思。纯 Python。
open-multi-agent
前三个都要你先设计点什么——图、角色、或对话流程。这个反过来:你只给一个目标,协调器在运行时自己把它拆成任务 DAG,交给确定性调度器并行跑。它是这几个里唯一 TypeScript 原生的,三个运行时依赖,直接塞进 Node 后端就行,不用 Python、不用云端 Sidecar。API 分了层,从单 Agent 的 runAgent,到自动组队的 runTeam,再到互相验证的 runConsensus。这是我们自己维护的项目,所以下面这张表我尽量按客观维度摆,别光听我一面之词。
摆一张表
| 维度 | LangGraph | CrewAI | AutoGen | open-multi-agent |
|---|---|---|---|---|
| 核心抽象 | 状态图(节点+边) | 角色 crew | Agent 对话 | 目标 → 任务 DAG |
| 主语言 | Python(+JS) | Python | Python | TypeScript |
| 上手难度 | 最陡 | 最低 | 中 | 低 |
| 控制粒度 | 最强(手工) | 较弱 | 中 | 中(自动拆解) |
| 生产成熟度 | 最成熟 | 稳 | 维护模式* | 取决于团队/场景 |
| 最适合 | 精确可控的流程 | 快速角色原型 | 对话式研究 | TS 后端、目标驱动 |
*AutoGen 已于 2026 初转入维护模式,新特性在 Microsoft Agent Framework。
被低估的一条:语言和部署
多数对比只比功能,很少有人提落地时最卡人的一条:你的团队用什么语言。LangGraph、CrewAI、AutoGen 都以 Python 为主。如果你的产品后端是 Node/TypeScript,硬塞一个 Python 框架进来,就是多一套运行时、多一个要部署和监控的东西、多一层桥。这笔账在选型时特别容易漏,上线的时候才疼。我们当年做 open-multi-agent,起因就是被这条逼的。Python 框架不差,只是这笔集成成本得先算进去。
所以到底怎么挑
真要挑,先想两件事:后端什么语言、你想手工控制到多细。TypeScript 技术栈,基本可以直接看 open-multi-agent;Python 而且要对流程有极致控制,LangGraph;Python 只是想快点搭出来,CrewAI;AutoGen 现在更适合研究,别押生产。至于还在 Dify、扣子上、纠结要不要上代码级框架的——那是另一个问题,我单写了一篇:《Dify、扣子之后,什么时候该上代码级框架》。
有具体场景想聊,或想评估可行性?