LangChain、LangGraph 与 CrewAI 的定位对比
从控制层、运行时、角色协作和工程边界角度比较 LangChain、LangGraph 与 CrewAI 的分工和选型。
#tech / ai
#resource / langchain
#resource / langgraph
#resource / crewai
#type / synthesis
#status / growing
[!info] related notes
- 所属 MOC: AI MOC, Agent MOC, Python 大模型应用开发 MOC
- 相关概念: Agent, Augmented LLM, Orchestration, Agent Runtime
- 易混淆概念: Agentic Workflow Patterns, 多 Agent 编排模式
- 相关资源: langchain, langgraph, crewai
LangChain、LangGraph 与 CrewAI 的定位对比
范围
这篇关系笔记讨论的不是某个框架 API 怎么写，而是三者在 LLM 应用控制层里分别承担什么角色，以及什么时候该选哪一个。
为什么要放在一起理解
这三个名字经常在同一段讨论里出现，但它们解决的问题并不在同一层：
- 有的更像通用开发框架
- 有的更像低层运行时
- 有的更像多智能体团队与流程编排框架
如果层级不分清，系统设计就很容易把“单 agent loop”“状态机控制”“多角色协作”混成一团。
依赖路径 / 调用链 / 演进链
先从控制层看，可以把成熟 LLM 应用粗略理解成：
用户输入 -> 上下文构建 -> 模型推理 -> 工具调用 / 检索 / 状态更新 -> 输出校验 / 审核 / tracing
这条链里：
如果再往下拆：
- LangChain 重点解决模型、消息、tools、retrieval、structured output、middleware 的统一开发接口
- LangGraph 重点解决 state、nodes、edges、checkpoint、durable execution、HITL
- CrewAI 重点解决 Agent、Task、Crew、Flow 这套团队协作和流程骨架
对比与易混淆点
| 维度 | LangChain | LangGraph | CrewAI |
|---|---|---|---|
| 核心定位 | 通用 LLM / agent 开发框架 | stateful agent / workflow 运行时 | 多智能体团队与流程编排框架 |
| 主要抽象 | model、messages、tools、agent、retrieval、middleware | state、node、edge、checkpoint | agent、task、crew、flow |
| 最擅长的问题 | 快速搭 RAG、tool agent、结构化输出 | 长流程、状态控制、恢复执行、人工介入 | 多角色协作、任务拆分、流程表达 |
| 更像什么 | 上层开发框架 | 底层执行骨架 | 有观点的团队协作框架 |
| 主要风险 | 抽象很多，容易把架构做复杂 | 图和状态设计需要工程纪律 | 多 agent 容易 token 膨胀，角色表演大于收益 |
几个实用判断：
- 如果你主要在做 RAG、tool calling、structured output，通常先看 LangChain
- 如果你已经进入复杂状态流、审批点、checkpoint、durable execution，通常该看 LangGraph
- 如果任务天然像团队协作，例如研究员、分析师、写作者串联，通常更适合看 CrewAI
还有一个更重要的边界：
- 单 agent 问题，不要硬做成多 agent
- 能由确定性代码完成的规则，不要交给框架里的 agent 自由决定
- framework 只是控制层，不是模型能力本身