LangGraph、AutoGen还是CrewAI？本地部署Agent框架怎么选

准备在自己的电脑上做一个资料整理助手，搜索结果很容易把你带进三套教程：一套画流程图，一套安排研究员和写作者，一套让几个 Agent 轮流对话。代码看起来都能完成任务，真正开始配置后，维护方式和失败时的处理路径却不一样。

我的判断是，先决定需要怎样控制任务，再比较框架。新项目可以重点看 LangGraph 与 CrewAI；AutoGen 则要先处理维护状态这个前提——本次核查时，官方仓库已醒目提示项目归档、不再维护，并建议新用户转向 Microsoft Agent Framework。

下面围绕 Windows 上的 Python 本地开发场景讨论依赖、资源与协作方式，不提供没有测试依据的速度和内存排名。框架在本机运行，也不自动意味着模型和工具全部离线。

本地部署先分层，安装成功还没有回答资源问题

以资料整理助手为例，至少要区分三层：编排框架负责推进任务，模型负责生成或判断，工具负责读取文档、检索和保存结果。三套框架都不能单凭一个安装命令，替你解决模型来源、工具依赖和业务数据这些问题。

LangGraph 的基础包可以单独安装；官方说明，使用它并不强制依赖 LangChain，但如果采用具体模型提供方的集成，还需要对应包。依赖可以围绕实际任务逐步增加，代价是你要自己明确状态、节点和模型调用如何配合。

不同框架在Windows环境下的依赖复杂度差异

CrewAI 官方安装路线使用 uv，并明确当前 Python 范围为3.10及以上、3.14以下，也提供 Windows 说明。它的安装文档还列出某些依赖在 Windows 上可能出现的构建问题，因此“封装程度高”不等于环境配置完全没有成本。

AutoGen 的历史结构区分 AgentChat、Core 和 Extensions，示例中的模型客户端也有各自依赖。对于已有代码，应先核对所用代际与包名；旧版教程、后续 API 和当前归档状态不能混在一起处理。

实际比较时，建议为候选方案各建独立环境，记录模型客户端、文档解析和存储等附加依赖。不要把工具全装齐后的环境体积，误认为某个框架基础包的固定成本。

任务必须按规则推进，LangGraph 的细粒度控制更合适

如果资料整理要求“先提取字段，缺失则补查，通过确认后才能生成报告”，重点是分支、状态和中断点。LangGraph 的定位是较底层的编排框架，可以在同一张图中组合确定性代码步骤与模型驱动步骤，并提供持久执行、流式处理和人工介入等能力。

在这个场景里，读取文件、校验字段可以由明确代码完成，模型只处理需要语义判断的部分。这样更容易说明一份报告走过了哪些路径，以及缺少信息时应该停在哪里；并不需要为每一个处理步骤都创建一个会对话的角色。

LangGraph通过状态机实现细粒度的流程控制

它的门槛也在这里。流程不会因为用了图就自动合理，你仍需设计共享状态、节点输入输出、出错分支和检查点。若只想先做一个简单问答助手，直接从底层编排开始，可能比使用更高层封装需要更多工作。

多 Agent 不是 LangGraph 的禁区，而是需要你结合任务结构组织。适合它的需求，是希望认真规定角色之间如何交接、哪些步骤必须固定、什么时候需要停下来确认。

任务天然按角色分工，CrewAI 更容易表达协作意图

另一种资料整理方式是：让研究角色收集信息，分析角色比较观点，写作角色整理成文。需求本身已经接近岗位分工时，CrewAI 的 Crews 更容易把角色、任务与协作关系直接表达出来。

但 CrewAI 也不只有让角色自由聊天这一条路。当前官方说明同时提供 Flows，用事件驱动方式控制流程，并可将确定步骤、单次模型调用和 Crew 组合。因此，不能简单把它归类为“方便但无法控制”，也不能据此保证任何协作链都会稳定结束。

CrewAI通过角色定义直观表达协作意图

例如，先用 Flow 检查资料是否齐全，再在需要时调用一个整理任务的 Crew，是可以考虑的设计方向。是否值得这样拆，要看角色之间有没有实际不同的职责与输入，而不是看演示里能排出多少个人物名称。

本地资源方面，多个角色往往意味着更多调用、上下文和等待；这是任务设计的影响，不能直接推导为某个框架永远更耗内存。共享一个模型服务与同时加载多个模型，也会形成不同的资源需求，必须按自己的配置测量。

AutoGen 先看存量迁移，再决定新项目的起点

AutoGen 的历史优势是以消息与多 Agent 交互来组织应用。AgentChat 提供较高层的双 Agent 或群组对话模式，Core 面向更底层的事件驱动设计，Extensions 则负责模型等扩展实现。这些概念仍有理解已有系统的价值。

但新选型不能忽略当前维护提示。官方仓库已说明不再提供维护与支持，并把新用户引向 Microsoft Agent Framework。即使页面仍保留安装命令和演示，也不能因此把 AutoGen 当成与持续发展中的候选完全相同的新项目起点。

AutoGen官方仓库的归档状态提示用户转向新框架

已有 AutoGen 项目，不必为了框架名称立刻重写。先整理使用的 API、消息交接、工具和停止条件，再依据官方迁移资料评估改造范围；只做实验复现的代码，与长期维护的业务系统，也应采取不同决策。

最后，用同一小任务比较候选：固定模型、输入资料和输出标准，记录调用次数、失败后的恢复方式及实际耗时，再看哪种组织方式更容易维护。需要明确流程控制，优先研究 LangGraph；角色分工更贴近需求，优先研究 CrewAI；面对 AutoGen，先回答维护与迁移问题。选择能解释、能检查的任务结构，比寻找一个没有条件的总冠军更有用。