Agent 开发框架的选型是最近半年被问得最多的问题之一。不管是做企业内部工具、自动化流程还是搞多智能体协作的 Demo绕来绕去总会撞上这几个名字LangGraph、AutoGen、CrewAI还有微软新推的 Microsoft Agent Framework。网上的对比文章不少但大多停留在功能列表层面——列一堆特性最后来一句根据需求选择看完还是不知道该用哪个。我自己这几个框架都实际跑过项目踩过不少坑也经历过选错框架重写的惨痛教训。这篇不打算做那种面面俱到的功能罗列而是从实际开发者的视角把每个框架的设计哲学、适用边界、真实上手体验讲清楚再给出可操作的选型判断标准。如果你正在纠结用哪个框架搭 Agent或者已经用了一个但感觉别扭想换这篇应该能帮你省下不少试错时间。1. 先搞清楚这四个框架到底在解决什么问题选框架之前得先明白一件事它们虽然都叫Agent 开发框架但设计出发点完全不同。这就像同样是交通工具卡车、跑车、越野车都能上路但你不会用跑车去拉货。搞混了定位后面怎么写都别扭。1.1 从编排和协作两个维度看差异我把这四个框架放在两个维度上理解流程编排的精细度和多智能体协作的原生程度。LangGraph 的核心是图结构的状态机。它把 Agent 的执行过程建模成一张有向图节点是操作边是流转条件。这个设计的好处是流程完全可控、可回溯适合那种步骤明确但需要动态分支的场景。它本质上是一个低层编排引擎给你足够的自由度但很多轮子得自己造。AutoGen 的出发点是对话驱动的多智能体协作。它把 Agent 之间的交互抽象成对话多个 Agent 通过消息往来完成任务。微软研究院出品学术味比较重早期版本用起来偏研究性质但概念很清晰——让 Agent 像人一样开会讨论。CrewAI 主打角色扮演式的团队协作。它给每个 Agent 分配角色Role、目标Goal和背景故事Backstory然后像组建一个团队一样让它们协作。上手极快几行代码就能跑起来一个内容创作小组或市场调研团队。Microsoft Agent Framework 是微软把之前的 Semantic Kernel 和 AutoGen 的能力做了一次整合定位是企业级、生产就绪的 Agent 开发底座。它强调可观测性、类型安全、与 Azure 生态的集成明显是冲着把 Agent 部署到生产环境去的。1.2 一个容易踩的认知坑很多人一开始会把 CrewAI 当成最简单的 AutoGen或者把 LangGraph 当成更复杂的 CrewAI。这是典型的认知误区。我见过一个团队需求是做一个需要人工审批介入的审批流 Agent——流程里有明确的步骤某些节点需要暂停等待人工确认确认后再继续。他们一开始选了 CrewAI因为上手快。结果发现 CrewAI 的协作模型是Agent 自主对话推进很难在中间插入一个暂停等人的环节最后不得不重写成 LangGraph。反过来另一个需求是模拟一个产品评审会让产品、开发、测试三个角色互相辩论用 LangGraph 写就非常痛苦因为你要手动管理每个角色的发言顺序和上下文而 CrewAI 几行配置就搞定了。所以选型的第一步不是看哪个功能多而是先想清楚你的任务本质是流程编排还是角色协作。框架核心抽象最适合的任务形态学习曲线LangGraph状态图节点边流程明确、需动态分支、需人工介入中高AutoGen对话消息多智能体讨论、代码生成与执行中CrewAI角色任务角色分工明确的团队协作低Microsoft Agent Framework类型化 Agent 工作流企业级生产部署、可观测性要求高中高2. LangGraph把 Agent 当成状态机来写LangGraph 是我个人在生产项目里用得最多的一个。原因很简单它的可控性最强出问题最好排查。2.1 图结构到底解决了什么痛点传统的 Agent 框架包括早期的 LangChain Agent大多是循环调用 LLM 直到任务完成的模式。这个模式在简单任务上没问题但一旦流程复杂就会出现几个致命问题第一不可预测。你不知道 LLM 下一步会调用哪个工具可能陷入死循环可能跳过关键步骤。第二不可中断。任务一旦开始就得跑完没法在中间暂停等人工确认。第三不可回溯。出了问题很难知道是哪一步出的错。LangGraph 用图结构把这些问题一次性解决了。每个节点是一个明确的操作调用 LLM、执行工具、处理数据边定义了流转条件。整个执行过程就是在这张图上走走到哪一步、当前状态是什么全都清清楚楚。from langgraph.graph import StateGraph, END from typing import TypedDict class AgentState(TypedDict): messages: list next_step: str def call_model(state: AgentState): # 调用 LLM 的逻辑 return {messages: state[messages] [response]} def should_continue(state: AgentState): # 决定下一步走向 if need_tool(state): return tools return END graph StateGraph(AgentState) graph.add_node(agent, call_model) graph.add_node(tools, tool_node) graph.add_conditional_edges(agent, should_continue) graph.set_entry_point(agent) app graph.compile()这段代码看起来简单但关键在于should_continue这个条件边——它把下一步做什么的决定权从 LLM 手里部分收回到了代码手里。这是 LangGraph 最核心的价值。2.2 状态管理和检查点机制LangGraph 另一个让我离不开的功能是Checkpointer检查点。它能在每一步执行后自动保存状态这意味着任务可以暂停后恢复适合需要人工审批的场景出错了可以从上一个检查点重跑不用从头来支持时间旅行调试回看任意一步的状态我在一个客服工单处理项目里用过这个机制。流程是Agent 先分类工单然后生成回复草稿草稿需要人工审核审核通过后发送。用 LangGraph 的interrupt功能可以在生成草稿后暂停等人工确认后再继续。这个在 CrewAI 里几乎没法优雅实现。提示Checkpointer 需要配合持久化存储如 SQLite、Postgres使用生产环境建议用数据库而非内存存储否则进程重启状态就丢了。2.3 LangGraph 的真实上手门槛说实话LangGraph 的学习曲线是这四个里最陡的。你需要理解状态、节点、边、条件边、检查点这一整套概念还要熟悉 LangChain 的生态虽然它现在可以脱离 LangChain 用但很多工具还是绑定的。我踩过的一个坑是状态设计。一开始我把所有东西都塞进一个大的 state 字典里结果节点之间互相污染调试极其痛苦。后来学乖了state 只放真正需要跨节点共享的数据每个节点的输入输出尽量明确。另一个坑是条件边的返回值。LangGraph 的条件边函数必须返回一个明确的字符串或字符串列表对应到目标节点名。如果返回了不存在的节点名会在运行时才报错而且报错信息不直观。建议把节点名定义成常量避免手写字符串。3. AutoGen让多个 Agent 像开会一样解决问题AutoGen 的定位很独特——它不关心流程怎么走它关心Agent 之间怎么聊。3.1 对话式协作的核心机制AutoGen 的基本单位是ConversableAgent。每个 Agent 能发消息、收消息、根据消息决定下一步动作。多个 Agent 组成一个GroupChat由一个GroupChatManager决定下一个发言的是谁。这个模型特别适合需要多轮讨论才能得出结论的任务。比如代码生成一个 Agent 写代码一个 Agent 审查代码一个 Agent 执行代码并反馈错误循环直到代码跑通。这种写-审-跑的循环用 AutoGen 表达非常自然。from autogen import AssistantAgent, UserProxyAgent, GroupChat, GroupChatManager coder AssistantAgent(nameCoder, llm_configllm_config) reviewer AssistantAgent(nameReviewer, llm_configllm_config) executor UserProxyAgent(nameExecutor, code_execution_config{work_dir: coding}) groupchat GroupChat(agents[coder, reviewer, executor], messages[], max_round10) manager GroupChatManager(groupchatgroupchat, llm_configllm_config) executor.initiate_chat(manager, message写一个快速排序并测试)3.2 代码执行能力是它的杀手锏AutoGen 最早出圈很大程度上是因为它的代码执行能力。UserProxyAgent可以配置成自动执行代码把 LLM 生成的代码真正跑起来把结果反馈回去。这个生成-执行-反馈的闭环在数据分析、算法验证类任务上非常好用。但这里有个必须注意的安全问题自动执行代码意味着 LLM 生成的任意代码都会在你的机器上跑。生产环境一定要用 Docker 容器隔离AutoGen 提供了DockerCommandLineCodeExecutor别图省事直接用本地执行。3.3 AutoGen 的版本动荡问题用 AutoGen 的人大概都知道它在 0.2 到 0.4 之间做了一次大规模重构API 变化很大。0.2 的ConversableAgent那套写法到 0.4 变成了基于autogen-agentchat和autogen-core的新架构。网上大量教程还是 0.2 的照着写会各种报错。我的建议是新项目直接用 0.4 的版本虽然资料少但架构更清晰而且微软后续的维护重心在这里。如果维护老项目就锁死版本别乱升级。注意AutoGen 的 GroupChat 在 Agent 数量多的时候token 消耗会急剧上升因为每轮对话都要把所有历史消息塞进上下文。Agent 超过 4 个就要考虑用嵌套对话或自定义发言选择策略来控制成本。4. CrewAI用招人组队的思路搭 AgentCrewAI 是这四个里上手最快的没有之一。它的心智模型特别符合直觉你要完成一个任务就组建一个团队给每个人分配角色和职责然后让他们协作。4.1 角色、任务、流程三件套CrewAI 的核心概念就三个Agent角色、Task任务、Crew团队。定义一个 Agent 就是描述它是谁、目标是什么、背景故事是什么。定义一个 Task 就是描述要做什么、预期输出是什么、交给谁做。from crewai import Agent, Task, Crew researcher Agent( role市场研究员, goal收集并分析目标市场的竞品信息, backstory你是一位有十年经验的市场分析师擅长从杂乱信息中提炼关键洞察, verboseTrue ) research_task Task( description调研三款同类产品的定价、功能和用户评价, expected_output一份结构化的竞品对比报告, agentresearcher ) crew Crew(agents[researcher], tasks[research_task]) result crew.kickoff()就这么几行一个能跑的 Agent 就出来了。backstory这个设计很有意思——它通过给 Agent 一个人设让 LLM 的输出更符合角色定位。实测下来有 backstory 的 Agent 输出质量确实比干巴巴的指令要好。4.2 顺序流程和层级流程CrewAI 支持两种流程模式Sequential顺序和Hierarchical层级。顺序模式就是任务一个接一个执行前一个的输出作为后一个的输入。层级模式会有一个经理Agent 来协调其他 Agent决定谁做什么。顺序模式适合流水线式的任务比如调研→写作→校对。层级模式适合任务边界不太清晰、需要动态分配的场景。但层级模式的实际效果不太稳定经理 Agent 的决策质量直接影响整体我一般还是用顺序模式加明确的任务依赖。4.3 CrewAI 的能力边界在哪CrewAI 的优点是快缺点是控制粒度粗。它把很多决策权交给了 LLM你很难精确控制第几步做什么。这在简单任务上是优点省事在复杂任务上就是缺点不可控。我遇到过的具体问题需要在一个任务中间插入外部 API 调用并等待返回CrewAI 的 Task 模型里没有天然的暂停点。你只能把 API 调用包装成一个 Tool 让 Agent 去调但调不调、什么时候调还是 LLM 说了算。所以我的判断是CrewAI 适合做原型验证和相对简单的协作任务一旦流程复杂到需要精确控制就该考虑 LangGraph 了。5. Microsoft Agent Framework冲着生产环境来的Microsoft Agent Framework 是这几个里最重的也是定位最明确的——企业级生产部署。5.1 它整合了什么微软之前有两条 Agent 相关的线Semantic Kernel偏企业集成、插件体系和 AutoGen偏多智能体研究。Microsoft Agent Framework 把两者的能力做了整合提供统一的 Agent 抽象和工作流编排。它的几个特点很突出类型安全用 Pydantic 或 dataclass 定义输入输出、可观测性内置 OpenTelemetry 支持、多模型支持不绑定特定 LLM 供应商、与 Azure 生态深度集成。5.2 什么时候该考虑它如果你的项目满足以下条件Microsoft Agent Framework 值得认真评估需要部署到生产环境对稳定性和可观测性有要求团队已经在用Azure 或 .NET 生态需要类型安全的 Agent 定义避免运行时才发现的类型错误需要标准化的追踪和监控接入现有的 APM 系统但如果只是做个 Demo 或者内部工具它的重反而是负担。配置项多、概念多上手成本比 CrewAI 高不少。5.3 生态绑定的权衡Microsoft Agent Framework 和 Azure 生态的集成是双刃剑。好处是如果你本来就在 Azure 上接入各种服务很顺。坏处是迁移成本——一旦深度使用了它的 Azure 特定功能想换到其他云平台就比较麻烦。我的建议是如果团队没有明确的 Azure 绑定可以先观望。这个框架还在快速演进中API 稳定性还需要时间验证。等它更成熟了再上生产不迟。6. 一张表说清选型决策讲了这么多最后落到最实际的问题到底怎么选。我整理了一个决策表按最常见的几种场景给出建议。你的场景推荐框架理由流程明确、需要人工审批介入LangGraph检查点机制天然支持暂停恢复多角色讨论、辩论、评审CrewAI 或 AutoGen角色协作是它们的强项代码生成自动执行验证AutoGen代码执行闭环最成熟快速原型验证CrewAI上手最快几行代码出效果企业级生产部署、要可观测性Microsoft Agent Framework类型安全追踪生态集成需要精细控制每一步LangGraph图结构控制粒度最细数据分析、多步骤推理LangGraph 或 AutoGen看是否需要多 Agent 讨论6.1 一个实用的选型流程我自己的选型流程是这样的第一步判断任务本质。是流程编排还是角色协作前者偏 LangGraph后者偏 CrewAI/AutoGen。第二步判断控制需求。需不需要精确控制每一步需不需要暂停恢复需要的话LangGraph 基本是唯一选择。第三步判断部署环境。是内部工具还是生产系统生产系统且用 Azure 的话Microsoft Agent Framework 值得考虑。第四步判断团队熟悉度。团队熟悉 LangChain 生态就选 LangGraph熟悉 .NET 就选 Microsoft Agent Framework都没有偏好就按前几步的判断来。6.2 别忽视的迁移成本最后提醒一个很多人忽略的点框架迁移成本。这几个框架的概念模型差异很大从一个迁到另一个基本等于重写。所以选型时不要只看当前需求还要想想半年后需求会不会变。如果需求可能从简单变复杂建议一开始就选控制力强的LangGraph哪怕前期多写点代码。反过来如果确定就是简单任务选 CrewAI 快速出活别过度设计。我个人的经验是宁可前期多花两天学 LangGraph也别后期花两周重写。这个账踩过坑的人都懂。