LangGraph vs CrewAI vs AutoGen：2026年AI Agent框架选型指南

一个反直觉的选型结论

在主流AI Agent框架对比中，GitHub星标最多的那个，恰恰是你在新项目中不应该选择的。

AutoGen拥有约6.04万星标，超过CrewAI的5.71万和LangGraph的3.98万。但它已经320天没有发布Python稳定版本，最后一次标记版本（python-v0.7.5）发布于2025年9月30日，仓库最后一次提交停留在2026年4月15日。据GitHub REST API、PyPI发布历史和官方README核实，AutoGen的README已明确标注"维护模式"，官方推荐新用户转向Microsoft Agent Framework。

星标与生产现实之间的巨大鸿沟，才是这份对比真正要揭示的问题。不是功能矩阵，不是无法审计的基准测试，而是每个框架在规模化运行时暴露的故障点、维护状态和真实成本。

核心要点

• AutoGen已进入维护模式：README明确标注不再接收新功能，Python包约320天未发布稳定版。继任者是Microsoft Agent Framework，自2026年4月3日起正式GA。AG2是面向遗留代码库的真实选项，但它是fork而非品牌重塑。
• 星标会说谎，安装量更接近真相：LangGraph约7100万月安装量，约为AutoGen（约108万）的65倍。这个差距在所有合理限定条件下依然成立。
• 星标与安装量的比值是反向新鲜度信号：星标在炒作高峰期累积，安装量追踪当下的生产依赖。高比值意味着项目曾经火热，但如今不再承载关键业务。
• 框架选择只是生产系统的一个输入，很少是决定成败的那个输入。

为什么星标不能作为选型依据

星标是滞后指标。它们记录的是炒作高峰期被收藏的内容，对AutoGen而言是2024年的v0.2发布时代。星标无限累积且永不删除，即使项目已经沉寂。安装量恰恰相反：它是每次CI运行或镜像重建时都在支付的经常性生产成本。

两者的数字已经完全脱钩。

框架	月PyPI安装量	GitHub星标
LangGraph	7110万	4万
CrewAI	2070万	5.7万
MS Agent Framework	160万	1.3万
AutoGen	108万	6万

需要说明的是，PyPI统计包含CI流水线和容器重建，因此不是用户数。应将其视为相对信号而非绝对值。LangGraph受益于更广泛的LangChain生态系统的传递依赖，这相对于独立安装有所膨胀。AutoGen没有这种顺风，而差距依然巨大。65倍的差距经受得住这两个限定条件，1.2倍的差距则不能。

发布节奏从另一个角度讲述了同样的故事。截至2026年8月中旬，距上次发布的天数：AG2为1天，CrewAI和MS Agent Framework为2天，LangGraph为5天，AutoGen为320天。CrewAI在19天内发布了约10个版本，无论这代表快速修复还是快速迭代，都意味着你需要严格锁定版本。

PyPI 安装量为何能反映生产依赖：PyPI 是 Python 官方包仓库，任何 pip install langgraph 类操作（包括 CI 流水线、Docker 镜像重建、依赖解析）都会计入其下载统计。这与 GitHub 星标有本质区别——星标是一次性的、情感驱动的收藏动作，而安装量是每次部署、每次构建都要重复支付的动作，因此更能反映某个包是否仍被真实系统依赖。但需要注意三个限定：其一，统计包含 CI 机器人而非独立用户；其二，像 LangGraph 这样被 LangChain 生态传递依赖的包，安装量会因上游依赖而虚高；其三，PyPI 只统计下载次数，无法区分同一台机器的重复安装。所以在做框架选型时，安装量应被解读为相对信号（谁在被使用、谁在被冷落），而非绝对用户规模。

三种心智模型

每个框架都能调用工具、传递消息，因此功能矩阵无法区分它们。真正的区别在于规模化运行时什么会出问题：LangGraph在检查点增长时崩溃，CrewAI在提示词介导的委派上崩溃，AutoGen在维护上崩溃。

LangGraph是一个以中心状态对象为核心的有向图。Agent是节点，边定义流程，条件边处理分支，reducer合并并发状态更新。你绘制控制流程，LLM在其中执行。心智模型是状态机，框架在代码层面强制执行。内置原语包括持久化执行、人机回环、短期和长期记忆。

CrewAI是角色化团队。每个Agent携带角色、目标、背景故事和工具。Crew按顺序或层级执行任务。在层级模式下，自动生成的经理Agent进行委派和审查。运行环境提供层级结构，但内部的委派决策是模型介导的，而非编码为开发者定义的条件边。Flows是较新的原语，提供更可预测的生产控制：每步一次LLM调用，无自主委派。

AutoGen在当前维护模式下是对话驱动的多Agent运行时。继任者Microsoft Agent Framework具有相同的模式但不同的架构。AutoGen本身不再开发。其许可证状态值得单独标注：GitHub检测为CC-BY-4.0，README描述为CC-BY-4.0和MIT双许可，PyPI报告为MIT——这对法务团队来说不会是愉快的对话。

LangGraph在生产环境中的断裂点

故障点不在API，也不在工具链，而在检查点存储。

据工程师Tadeo Donegana Braunschweig在2026年4月发布的公开记录，其团队在每周超过12万次对话的规模下，检查点表无限增长。开源检查点器没有原生TTL。平均每次对话在仅两条消息和三次工具调用后，就在四个检查点表中产生约93行记录。在预发环境中，仅checkpoint_blobs一周就达到56MB。

在LangGraphJS跟踪器上，issue #1138自2025年4月开放至今仍然未关闭。LangChain官方文档建议运行cron任务删除旧检查点，这清楚地说明了生命周期管理的责任归属。

厂商发布了修复方案PR #7586，引入DeltaChannel。对于一个500轮的线程：默认add_messages配置写入了221MB，DeltaChannel每50步快照为10.53MB，无快照为1.98MB。但需要注意三个限定条件：它在LangGraph 1.2.0（2026年5月12日）中落地，标记为beta，且是选择性加入——升级不会自动生效，已写入的膨胀数据仍然存在。

Braunschweig的三个修复方案具有普适性：将检查点表创建移入Alembic迁移而非调用LangGraph的setup()；运行定期TTL删除；选择性检查点，仅持久化主管图，保持子图无状态。

类型化状态的争议

StateGraph接受真实的schema：TypedDict、dataclass或Pydantic BaseModel。LangGraph并非无类型。问题在上一层：LangChain文档指出，更高级的create_agent工厂不支持Pydantic状态schema，而这正是大多数团队的起点。类型化在你毕业到达的API上可用，而非你起步的那个。

Issue #5891是一个create_react_agent的bug，恰好是不能接受Pydantic schema的工厂路径。Issue #740命名了相同的根因：状态形状在运行时而非定义时被发现。实用建议是：在重要的边界显式定义schema，这类bug大多会消失。

什么是检查点（Checkpoint）与 TTL：在 LangGraph 这类持久化执行框架中，检查点是指框架在每个超级步（superstep）结束后，将整个图状态序列化并写入外部存储（如 Postgres）的快照。它让长任务可以在崩溃后从断点恢复，也是人机回环、时间旅行调试等功能的基础。问题在于，开源检查点器没有原生的 TTL（time-to-live，生存时间）机制——写入的记录不会自动过期。一篇对话可能产生大量中间状态快照，一个 500 轮的线程在默认配置下可写入 221MB。TTL 是数据库领域常见的过期清理机制，这里意味着团队必须自己写 cron 任务或迁移脚本删除旧检查点。理解这一点很关键：持久化执行带来的可靠性并不是免费的，它把生命周期管理的责任从框架转移到了运维团队身上。

CrewAI在生产环境中的断裂点

委派问题不是理论担忧，而是有据可查、可复现的故障模式。

据Partha Sarkar的记录，一个三Agent支持团队（分诊、技术、账单）在层级模式下收到纯技术查询。经理调用了全部三个Agent，包括账单。账单Agent的响应覆盖了正确的技术答案。运行消耗了38秒和15,759个token，产出约200个token的输出。没有任何错误报出。

根因是层级模式不强制执行条件分支或真正的委派。经理决定，当模型的判断摇摆时，控制流随之摇摆。他的修复是用自定义经理Agent替换内置经理，带有明确的逐步指令。修复后，纯技术运行耗时24秒、约1万token。你通过手动编排恢复了约三分之一的成本。

十一个月内的三个委派bug

Issue #2606（2025年4月）：经理传递dict而schema期望字符串。Issue #4783（2026年3月）：经理用自己的工具执行任务但从不委派，将层级模式坍缩为顺序模式，已关闭为not_planned。Issue #3925（2025年11月）：英文任务描述下经理正确委派，日文描述下经理独自回答不委派，双向可复现。

最后一个issue的含义值得深思：生产系统的控制流因为任务描述的自然语言变化而改变。任何在代码中强制执行编排的框架都不可能出现这种行为。如果你在非英语市场运行CrewAI，请将此作为发布前的回归测试。

未关闭的安全问题

Issue #5057，"内存内容未经净化注入系统提示词，导致间接提示注入"，自2026年3月开放至今。机制上，lite_agent.py将检索到的记忆直接拼接到系统提示词中，任何写入记忆的内容都继承了系统级指令权限。评级为中等，引用OWASP Agentic Security Index。近五个月后仍未关闭。如果你使用CrewAI记忆功能处理任何受用户影响的内容，请在发布前应用推荐缓解措施。

什么是提示词注入（Prompt Injection）与 OWASP Agentic Security Index：提示词注入是一类针对 LLM 应用的攻击，攻击者通过可控输入（网页文本、用户消息、被检索到的记忆）注入额外指令，从而劫持模型行为。在 Agent 系统中，风险被放大，因为 Agent 拥有工具调用权限，一次成功的注入可能导致数据泄露或未授权操作。Issue #5057 描述的正是这种攻击的“间接”变体：CrewAI 的 lite_agent.py 把检索到的记忆直接拼接到系统提示词中，而系统提示词在语义上拥有最高权限。任何被写入记忆的内容（可能来自用户）因此继承了系统级指令权限。OWASP Agentic Security Index 是 OWASP 针对 Agentic AI 场景提出的安全风险清单，用于给这类漏洞定级。这意味着使用 CrewAI 记忆功能时，输入净化不是可选项，而是发布前的必经环节。

AutoGen为何应该被替换

AutoGen处于维护模式，这句话对任何新项目来说就应该结束讨论。但理解这在实际中意味着什么很重要，因为已有团队需要知道退出路径的形状。

README逐字标注："AutoGen现已进入维护模式。它将不会接收新功能或增强，今后由社区管理。新用户应该从Microsoft Agent Framework开始。"最后标记版本为2025年9月30日，最后仓库提交为2026年4月15日。仓库没有存档横幅，所以乍看之下项目不像是死了，但它就是。

血统值得了解。原始作者Chi Wang和Qingyun Wu于2024年11月离开微软并将项目fork为AG2，现在v1.0.x，Apache-2.0许可。微软于2026年4月3日发布Microsoft Agent Framework 1.0 GA，由AutoGen和Semantic Kernel核心团队开发，Python和.NET双版本，MIT许可，支持A2A和MCP互操作，具有稳定API和LTS承诺。

迁移是重写，且有一个静默变化

微软的迁移指南读起来像从零开始的指南而非升级指南。AssistantAgent变为Agent，状态语义在重命名之下反转。AssistantAgent将对话历史作为其状态的一部分维护。Agent是无状态的，不在调用之间维护历史。移植代码时不会报错，Agent只是停止记忆，你从客户投诉中发现这一点。

同一个重命名中还有第二个反转：AssistantAgent默认单轮，除非提高max_tool_iterations；Agent默认多轮。迁移将一个组件从"记住但行动一次"变成"行动多次但什么都不记得"。

还有一个需要提前评估的缺口：AutoGen支持本地代码执行工具，微软指南声明此功能计划在未来版本中提供。目前这是一个空洞。

字符串匹配终止

AutoGen在LLM生成精确token TERMINATE时终止。由于模型对精确token不严谨，它们会输出terminate、Terminate.、Task terminated或用markdown包裹。这些都不匹配，循环继续，你为每一轮付费。发言者选择以相同方式失败：如果选择器的输出不完全匹配Agent名称，同一个Agent会被反复重选，产生单Agent无限循环。Issue #12追溯到2023年7月，在维护模式的框架中不会有修复。

为什么 LLM 不擅长精确字符串匹配：大语言模型输出的是概率分布的采样结果，它对“必须原样输出某个 token”这种约束天然不可靠。即便提示词明确要求生成 TERMINATE，模型也可能输出 terminate、Terminate.、Task terminated，或者用代码块、引号包裹。底层原因是 tokenizer 会把同一个语义单位切分成不同的 token 序列，而采样温度和上下文又会影响选择。因此在工程上，判断终止或路由不应依赖字符串精确匹配，而应采用结构化输出（JSON schema、函数调用）、模糊匹配或显式状态标志。AutoGen 用字符串匹配做终止和发言者选择，正是把这种模型特性当成了可靠接口，一旦不匹配就会陷入反复重选或无限循环，而每轮循环都在消耗 token。

多Agent编排的真实成本

据Kulkarni和Kulkarni在SEC文件上对多Agent架构的基准测试，反思性自纠正循环达到最高字段级F1（0.943），成本为顺序基线的2.3倍。层级主管-工作者达到F1 0.921，成本1.4倍，是研究中最佳的性价比点。混合方案以1.15倍基线成本恢复了89%的反思收益。

这些模式直接映射到框架：CrewAI的层级过程对应主管-工作者行，LangGraph的循环图用于构建反思循环，AutoGen的群聊是第三种形态，纪律性不如前两者。实用建议：如果你为文档中每个字段的反思支付2.3倍成本，你付多了，因为混合方案以15%的溢价恢复了大部分准确性。

没有框架能阻止超支

一个应该影响你预算方式的发现：在LangGraph、CrewAI和Microsoft Agent Framework中，每个可用的控制旋钮都约束结构，没有一个约束金钱。

框架	旋钮	默认值	实际约束
CrewAI	max_iter	20	每个Agent的迭代次数
CrewAI	max_retry_limit	2	重试，会倍增支出
LangGraph	recursion_limit	1000	每次执行的超级步数
Agent Framework	max_iterations	100	工作流迭代次数

默认上限相差50倍，却没有人比较它们。结构限制还将200token调用和20万token长上下文调用视为相同事件。这就是为什么团队提交"我们设置了max_iter，为什么账单还是很高"的工单。你限制了步数，但账单在计算token，两者独立变动。

如果支出是硬约束，将上限放在网关或代理层，那里你才能真正在花费时计算token。

何时完全跳过框架

有时正确的Agent框架就是没有框架。

Gartner预测到2027年底超过40%的Agentic AI项目将被取消，成本、不明确的业务价值和不足的风险控制是主要原因。成本和风险控制恰恰是这些框架不原生提供的两样东西。

Anthropic Engineering的"Building Effective AI Agents"最直接地论证了这一点：最成功的实现没有使用复杂框架，而是使用简单、可组合的模式。如果你的工作流是三次LLM调用的固定序列加上重试，框架增加了一个抽象层、依赖树和迁移风险，收益甚微。

一个有用的测试：先将工作流写为普通函数。如果该函数读起来清晰，你就不需要框架。当它开始积累重试、分支和共享状态时，你就需要了，那时Agent开发变成了架构问题而非库选择。

最终选型建议

维度	赢家	理由
生产可靠性	LangGraph	控制流在代码中强制执行而非提示词
首次可用团队速度	CrewAI	更高级抽象，原型最快
真实生产使用	LangGraph	7100万月安装量，承载关键业务
发布响应性	CrewAI	19天内10个版本
许可证清晰度	LangGraph / CrewAI	均为MIT；AutoGen报告三个不同答案
成本控制	无	三者均不能在支出时终止运行
运维负担	CrewAI	LangGraph检查点器需要前期生命周期管理
企业支持路径	MS Agent Framework	2026年4月GA，稳定API，LTS承诺

选择LangGraph：如果你需要显式、可审计的控制流，需要持久化执行或人机回环步骤，工作流有真实分支和共享状态，团队将承担持久化工作。前期预算这些工作：检查点TTL删除、仅在主管图上选择性持久化、将检查点包与核心分开锁定。

选择CrewAI：如果你在本季度交付多Agent原型，想要更高级抽象，能吸收运营风险。锁定版本，在测试套件中写入委派断言，在用户内容触及Agent记忆前应用#5057缓解措施。

不要在新项目中选AutoGen：如果你今天选择框架且没有遗留投资。如果已经在用，将MAF迁移作为重写来评估，将无状态Agent行为放在测试计划首位。

选择Microsoft Agent Framework：如果你是微软技术栈，正在从AutoGen或Semantic Kernel迁移，或者供应商支持路径的LTS承诺是项目获批的关键。

选择无框架：如果你的工作流是几个确定性LLM调用，普通函数加重试仍然可读。写那个函数，加个重试，只有当函数不再可读时才引入框架。

AutoGen的教训不是微软放弃了一个项目，而是一个卡在v0.x的框架从来就不是真正的产品：它是一个碰巧出了名的研究原型。在承诺之前检查维护状态、发布节奏和维护者的路线图。