AI Agent 框架横评：LangGraph vs CrewAI vs AutoGen vs Dify 怎么选

2026 年，"AI Agent 框架"这个词已经被用烂了。但凡能调一次 LLM、能串两步工具的项目，都敢自称 agent 框架。真正被开发者反复拉出来对比的，就四个：LangGraph、CrewAI、AutoGen、Dify。但问题在于——它们根本不是同一类东西。拿 star 数比高低、拿"谁更强"做结论，是横评最常见的错误。

先说清楚：下面是四款主流开源 Agent 框架的代表性对比，基于官方文档、GitHub 元数据（star 数经 GitHub API 当日核实）与公开资料，非亲自压测。star 数据截至 2026-08-06，实时变动。本篇只做横评：对比表、逐个拆、选型对号、避坑、FAQ，不教你十分钟搭一个 agent（那是配套 SOP 文的事）。

一个必须前置的提醒：Dify 在本站另一篇《AI 工作流自动化平台横评》里作为"LLM 应用编排平台"出现过。本篇聚焦它作为 Agent 框架的一面——开发者用它编排多 agent 协作、构建带工具调用的 agent 应用，不复述工作流平台那篇的通用编排角度。

一、为什么 2026 年 Agent 框架要横着选

这四款不是同类竞品，而是四个范式。理解范式，比理解功能列表重要十倍。

• LangGraph 是图编排范式。你把 agent 拆成节点和边，用状态机（state machine）显式控制每一步的流转、分支、循环。它的关键词是"可控"——durable execution（持久化执行）、human-in-the-loop（人机协同）、checkpoint（断点恢复）。灵感来自 Google Pregel 和 Apache Beam，本质是把 agent 当成一个可持久化、可中断、可恢复的状态图。适合对流程可控性要求极高、要上生产的复杂 agent。
• CrewAI 是角色协作范式。你定义一组有角色（role）、目标（goal）、背景故事（backstory）的 agent，组成一个 Crew 协作完成任务。它的关键词是"协作"——高层抽象，开发者不用手写每一步的消息传递，agent 自己商量谁干啥。2026 年它还加了 Flows（事件驱动控制），补上了精确编排的能力。适合快速搭建多角色协作的生产级工作流。
• AutoGen 是多 agent 对话范式。它的核心是让 agent 之间对话（conversation）——AssistantAgent、UserProxyAgent、GroupChat，agent 自主或与人协作完成任务。它的关键词是"对话"——agent 通过多轮对话推进任务，研究味最重。但要注意：AutoGen 已于 2026 年进入维护模式，不再接收新功能，微软官方推荐新项目改用继任者 Microsoft Agent Framework（MAF）。
• Dify 是低代码应用平台范式。它不是纯代码框架，而是一个带可视化画布的平台：拖拽编排 workflow、配 RAG、定义 agent（基于 Function Calling 或 ReAct）、挂 50+ 内置工具，再用 API 把整个应用嵌进你的业务。它的关键词是"平台"——从原型到投产不换栈，自带 LLMOps 观测。

理解了这四个范式，选型就不再是"哪个最强"，而是"我要的 agent，用哪种范式表达最顺手"。一个需要严格审计每一步决策的生产级 agent，硬上 CrewAI 的自主协作会失控；一个想三天搭出原型的小团队，硬啃 LangGraph 的状态图会过度工程。先分范式，再对号入座。

二、四位选手入场（star 数据截至 2026-08-06，依据 GitHub API）

三个细节要单独说。第一，Dify star 数最高（超 15 万），但它是平台型产品，受众比纯代码框架广得多，star 高不等于"agent 框架最强"，只说明它作为 LLM 应用平台的社区热度。第二，前三款都是 Python 代码框架，Dify 是 TypeScript 写的平台——这意味着前三者融入你的代码库，Dify 是独立部署再用 API 调用。第三，AutoGen 的许可证是双重的：代码 MIT（见仓库 LICENSE-CODE），文档 CC-BY-4.0（见 LICENSE），代码侧可自由商用。

三、六维度对比表

基于官方文档与公开描述的代表性对比，非亲自压测。

最关键的分水岭在"可控性 vs 上手速度"。LangGraph 用可控性换上手难度——你写更多代码，换回每一步可审计、可中断、可恢复；CrewAI 和 Dify 用上手速度换部分可控性——高层抽象或可视化让你快，但 agent 自主协作或画布黑盒让你少了对每一步的精细控制。AutoGen 原本在对话范式里独一份，但维护模式让它更适合已存量项目的过渡，而非新项目首选。

四、逐个拆：各自的最佳射程

LangGraph：图编排，可控性的天花板

LangGraph 自我定位是"构建有状态 agent 的底层编排框架"（low-level orchestration framework for building stateful agents）。你把 agent 的每一步定义成节点（node），用边（edge）连接，共享一个 State 对象，显式控制流转、分支和循环。它把 agent 当成一张可持久化、可中断、可恢复的状态图。

from langgraph.graph import StateGraph, START, END
from typing import TypedDict

class State(TypedDict):
    messages: list[str]

def call_model(state: State) -> State:
    # 节点：处理消息
    return {"messages": state["messages"] + ["model response"]}

graph = StateGraph(State)
graph.add_node("call_model", call_model)
graph.add_edge(START, "call_model")
graph.add_edge("call_model", END)
app = graph.compile()

它的核心卖点：durable execution（agent 跑到一半挂了能从断点恢复）、human-in-the-loop（任意节点插入人工审核与状态修改）、comprehensive memory（短期工作记忆 + 长期持久记忆）、与 LangSmith 集成的执行轨迹可视化。Klarna、Replit、Elastic 都在生产用它。注意它由 LangChain 公司出品，但可以脱离 LangChain 独立使用。

适合谁：要做生产级、长流程、对每一步决策有审计和干预要求的复杂 agent——客服编排、多步研究、需要合规留痕的企业 agent。代价是学习门槛最高，你得懂状态机、图、持久化，初期开发量比其他三个都大。

短板：抽象层级低，简单 agent 也要写不少样板代码；强依赖 LangChain 生态心智，与 LangSmith 绑定较深，想换观测方案有迁移成本。

CrewAI：角色协作，多 agent 上手最快

CrewAI 自我定位是"快速灵活的多 agent 自动化框架"（Fast and Flexible Multi-Agent Automation Framework），提供高层抽象（Crews）和底层 API（Flows）。你给 agent 一个角色、目标、背景故事，把任务分给它，组成 Crew 让它们协作。

from crewai import Agent, Task, Crew

researcher = Agent(
    role="研究员",
    goal="收集指定主题的资料",
    backstory="资深研究员，擅长快速检索与归纳",
    llm="gpt-4o"
)

task = Task(
    description="研究 2026 年主流 Agent 框架并产出摘要",
    expected_output="一份含四款框架对比的摘要",
    agent=researcher
)

crew = Crew(agents=[researcher], tasks=[task])
result = crew.kickoff()

它的核心卖点是"协作抽象到位"——你不用手写 agent 之间怎么传消息，Crew 机制帮你编排；2026 年的 Flows 补上了事件驱动的精确控制，让它在"自主协作"和"确定性流程"之间能切换。官方称已有超过 10 万开发者通过社区课程认证，说明它的学习曲线和社区运营做得不错。MIT 许可，pip 安装，对生产部署友好。

适合谁：要快速搭多角色协作的生产工作流——内容生产管线（研究员+写手+编辑）、多步骤业务自动化、想让 agent 分工又不想手写编排逻辑的团队。它的价值在"多 agent 协作上手最快"——定义角色、分任务、kickoff，比在 LangGraph 里手写状态图快得多。代价是 agent 自主协作时可控性弱于图编排，复杂分支和严格审计要靠 Flows 兜。

短板：高层抽象在极端复杂场景下会"够不着"——当你要精细控制每一步消息传递时，Crew 的黑盒协作会成为束缚；生态规模和工具集成广度不及 LangChain 系。

AutoGen：多 agent 对话，研究味重但已维护模式

AutoGen 自我定位是"创建可自主行动或与人协作的多 agent AI 应用的框架"。它的核心是让 agent 对话——AssistantAgent 负责 LLM 推理，UserProxyAgent 代理人类执行代码与反馈，GroupChat 让多个 agent 在一个会话里协作。

import asyncio
from autogen_agentchat.agents import AssistantAgent
from autogen_ext.models.openai import OpenAIChatCompletionClient

async def main():
    client = OpenAIChatCompletionClient(model="gpt-4.1")
    agent = AssistantAgent("assistant", model_client=client)
    result = await agent.run(task="总结 2026 年 Agent 框架趋势")
    await client.close()

asyncio.run(main())

必须强调：AutoGen 已进入维护模式（maintenance mode）。 仓库 README 顶部明确标注：不再接收新功能或增强，转为社区维护；微软官方推荐新项目改用继任者 Microsoft Agent Framework（MAF） 1.0——定位企业级多 agent 编排，支持多模型供应商、A2A 与 MCP 互操作，提供稳定 API 与长期支持。AutoGen 的 star 数（6 万+）仍很高，但这是历史积累，不代表活跃度。

适合谁：已有 AutoGen 存量项目（按官方迁移指南过渡到 MAF）、做多 agent 对话机制的研究与原型验证。它的价值在"对话范式"——当任务适合用 agent 之间多轮对话推进（而不是确定性流程）时，AutoGen 的 GroupChat 抽象曾是最顺手的。AutoGen Studio 还提供 no-code GUI 拖拽搭 agent。代价是：新项目不该再选它，维护模式意味着 bug 修复靠社区、新模型和新工具的适配会滞后。

短板：维护模式是最大短板——没有官方新功能路线，文档停止更新，长期看会被 MAF 取代；对话范式对确定性业务流程的可控性弱，生产环境要额外兜底。

Dify：低代码平台，Agent 框架里唯一的"平台型"

Dify 在本篇的视角下，是四款里唯一的"平台型 Agent 框架"——它不是融进你代码库的 Python 库，而是独立部署的应用平台：可视化画布编排 workflow、配置 RAG 管线、定义 agent（基于 Function Calling 或 ReAct）、挂 50+ 内置工具（Google Search、DALL·E、WolframAlpha 等），最后用 Backend-as-a-Service 的 API 把整个 agent 应用嵌进你的业务系统。

它的 agent 能力体现在：可视化定义 agent 节点、支持 Function Calling 与 ReAct 两种范式、内置工具库 + 自定义工具、RAG 管线开箱即用、100+ 模型供应商集成（GPT/Llama3/Mistral 及任意 OpenAI API 兼容模型）、LLMOps 日志与性能监控。Docker Compose 一键自托管，社区版免费，K8s/Helm 部署方案社区成熟。

# 自托管 Dify 社区版
cd dify/docker
cp .env.example .env
docker compose up -d
# 访问 http://localhost/install 初始化

适合谁：想低代码从原型到投产、团队里有非纯代码角色（产品/运营要参与 agent 设计）、要把 agent 能力快速嵌进现有产品、不想为 RAG/工具调用/观测各拼一套的团队。作为 agent 框架，它的最佳射程是"业务团队主导的 agent 应用"——画布拖拽定义 agent 行为，API 调用投产，比写代码框架快得多地见到成果。代价是黑盒程度高：画布背后的执行细节不如代码框架透明，深度定制要受平台能力边界约束。

短板：许可证是改良 Apache 2.0，附加了两条限制——不得用源码做多租户 SaaS（除非获书面授权）、不得移除前端 LOGO 与版权信息，企业采购前要让法务过一眼；纯代码可控性诉求强、要深度嵌入自有架构的团队，平台型会显得"隔了一层"。

五、场景选型对号入座

一句话决策法：先问"我要的是代码还是平台"——要代码，再问"要可控还是要快"（可控选 LangGraph，快选 CrewAI）；要平台，Dify 基本是唯一项；AutoGen 除非存量项目，否则直接看 MAF。

六、三个避坑

坑一：拿 star 数当选型依据。 Dify 15 万 star 远超其他三个，但它是平台型产品，受众面广，不代表它作为"agent 框架"比 LangGraph/CrewAI 强。同理 AutoGen 6 万 star 是历史积累，维护模式下活跃度已大幅下降。star 衡量的是社区热度，不是你的场景适配度。

坑二：忽视 AutoGen 的维护模式。 2026 年新项目选 AutoGen 是明确的风险——没有新功能、文档停止更新、bug 修复靠社区。如果你的团队正在用 AutoGen，尽早按官方迁移指南评估过渡到 Microsoft Agent Framework；如果还没选，别因为 star 高就入坑。

坑三：混淆"框架"和"平台"的部署心智。 LangGraph/CrewAI/AutoGen 是 pip 装进代码库的 Python 框架，跟你的应用同进程；Dify 是独立部署的平台，你的应用通过 HTTP API 调它。这意味着 Dify 多一层网络与运维（要管 Docker/数据库/升级），但也意味着非代码角色能直接在画布上改 agent。把平台当框架用（嫌它黑盒、嫌它隔层）或把框架当平台用（嫌它没有 GUI、嫌它要写代码），都会别扭。

FAQ

Q1：新手入门第一个 agent 框架选哪个？ A：想最快见到成果选 CrewAI——角色抽象直观，几行代码跑通一个多 agent 协作；想打牢可控性基础选 LangGraph，但要准备好啃状态机。Dify 适合不想写太多代码、要可视化操作的入门者。AutoGen 不建议新手选，已维护模式。

Q2：AutoGen 进入维护模式，我现有的项目怎么办？ A：短期内可继续运行，官方仍维护关键 bug 修复（社区驱动）。建议按微软官方的 AutoGen → Microsoft Agent Framework 迁移指南评估过渡，尤其是生产项目——MAF 1.0 已是稳定版，提供长期支持与多模型/A2A/MCP 互操作，越早迁移技术债越小。

Q3：Dify 的许可证能商用吗？ A：可以商用，但有附加条件。它是改良 Apache 2.0：允许商用（包括作为后端服务或企业开发平台），但两条限制需注意——不得用源码运营多租户 SaaS（除非获书面授权）、不得移除前端 LOGO 与版权信息。自托管内部使用一般无碍，做对外 SaaS 产品要让法务过条款。

Q4：LangGraph 和 CrewAI 能一起用吗？ A：技术上可以——两者都是 Python 库，能在同一项目里各管一段。但范式不同（图编排 vs 角色协作），混用会增加心智负担。更实际的做法是按场景主次选一个为主，另一个补短板：比如主用 CrewAI 做协作，复杂可控分支用 LangGraph 兜底。多数项目选一个范式贯彻到底更省心。

Q5：这四个都需要自己准备 LLM API Key 吗？ A：是的。四者本身不提供模型，你需自备 API Key（如 sk-xxx）接入 OpenAI、Anthropic 或开源模型。Dify 的优势是内置 100+ 模型供应商集成，配 Key 的体验最顺；其余三个在代码里直接传 client。自托管开源模型（如 Ollama）四者都支持。

参考来源

• LangGraph 仓库与文档：https://github.com/langchain-ai/langgraph 、https://docs.langchain.com/oss/python/langgraph/overview
• CrewAI 仓库与文档：https://github.com/crewAIInc/crewAI 、https://docs.crewai.com/introduction
• AutoGen 仓库（含维护模式声明）：https://github.com/microsoft/autogen 、https://microsoft.github.io/autogen/
• Microsoft Agent Framework（AutoGen 继任者）：https://github.com/microsoft/agent-framework
• Dify 仓库与文档：https://github.com/langgenius/dify 、https://docs.dify.ai 、https://dify.ai/pricing
• GitHub API（star 数据核实，2026-08-06）：https://api.github.com/repos/{owner}/{repo}