小白 / Xiaobai
开发者 · 产品构建者
持续构建 AI 工程系统、开发者工具与长期数字资产。
关于作者与 XBSTACK →
CrewAI vs LangGraph：2026 AI Agent 编排怎么选？
CrewAI vs LangGraph 2026 怎么选？比较 CrewAI Crews/Flows 与 LangGraph durable execution、state、checkpointer、interrupt、HITL 和低层编排能力，给出按任务边界做 PoC 的选型方法。
CrewAI 和 LangGraph 的差异，不再适合用“灵活 vs 确定”“原型 vs 企业级”概括。**CrewAI 当前已经有 Crews 与 Flows 两层：角色化协作和可控业务流程可以组合；LangGraph 则明确定位为低层 Agent orchestration runtime，强调 durable execution、state、persistence、streaming 和 Human-in-the-loop。**选型应从你需要控制的执行语义出发，而不是从框架标签出发。
先把当前定位说清楚
CrewAI：
Crew：Agents + Tasks + Processes，适合表达角色化协作、专业分工和委派；Flow：事件驱动、有状态的流程层，可以处理 deterministic logic、状态和 Crew 调用。
LangGraph：
StateGraph/ Functional API：低层描述状态、节点、边或 durable task；- checkpointer：在 graph execution step/super-step 上持久化状态；
- interrupt / HITL：暂停、检查/修改状态并恢复；
- durable execution：失败后从已记录的执行边界继续，而不是简单从头跑。
所以 CrewAI 不是“完全由 Agent 自主路由”，LangGraph 也不要求每个项目都手工画复杂 DAG。两边都在提供确定性与 agentic 行为的组合，只是抽象重心不同。
CrewAI：角色与业务流程本身就是你的领域模型时更自然
假设业务是：
内容研究 Flow
→ 收集资料
→ Research Crew
→ 事实校验
→ Editor Crew
→ 人工确认
→ 发布
这里 CrewAI 的表达很直接：角色、任务、协作关系和业务 Flow 都是一级概念。
如果你只需要一个简单 Tool Calling Agent，也没必要为了“框架统一”强行加多个 Agent。CrewAI 的价值应来自业务确实有团队式协作，而不是名字里有 Crew。
LangGraph：需要显式执行状态与恢复语义时更自然
LangGraph 适合你需要直接回答这些问题的场景：
- 当前执行在哪个 graph step；
- state 里有哪些 canonical 字段；
- 哪些分支由代码决定；
- 中断后从哪里恢复；
- 哪个工具调用需要 interrupt；
- 某个节点失败时哪些并行结果已经保存；
- 怎样 fork 某个 checkpoint 做调试/替代轨迹。
它更像一个 Agent runtime，而不是“角色团队框架”。这也是为什么 LangChain v1 的 create_agent 直接构建在 LangGraph runtime 上：高层 Agent 可以复用这些执行能力。
Checkpoint 不等于任意节点的事务回滚
旧稿写过“发生中断后直接从最后一次成功节点无缝接续”。这句话太容易让开发者误解。
LangGraph persistence 会保存 graph state checkpoints，并且在 super-step 中对成功完成的并行节点保留 pending writes；但你仍要考虑：
node starts
→ calls payment API
→ payment succeeds
→ process crashes before desired graph state is committed
恢复时不能只“重新跑 node”。你必须先查询外部支付状态或使用稳定 idempotency key。
所以 durable execution 的正确组合是：
checkpointed state
+ idempotent/replay-safe task
+ external result ledger
+ authorization re-check
而不是“有 Checkpointer = 外部世界自动回滚”。
Human-in-the-loop：谁更容易暂停不是唯一问题
LangGraph 的 interrupt/persistence 对长任务暂停恢复非常明确；CrewAI Flow 也可以把人工步骤设计在业务流程中。
生产中更重要的是 approval 的权限语义：
- 哪类 Tool 需要人工；
- 当前 reviewer 是否有资源级权限；
- edit 后的参数是否重新 Schema/Policy 校验；
- approval 是否会过期；
- resume 时外部状态是否仍有效；
- 是否防重复执行。
框架只解决部分执行控制，业务授权仍必须由确定性代码负责。
循环控制：两个框架都必须设置 budget
不要把 CrewAI 描述成“难以硬性控制循环”，也不要把 LangGraph 描述成“有图就不会死循环”。只要 Agent 能反复规划/调用 Tool，都可能无进展。
应该统一配置/测量：
- max model calls / turns；
- wall-clock timeout；
- repeated tool+args；
- 连续 state 无变化；
- token/cost budget；
- external cancellation；
- 明确 termination condition。
具体数字按任务基线定，不要给所有 Agent 都套 3 次、10 次或 15 步。
Token 与延迟：框架品牌不能直接决定
旧文章写“LangGraph 通常更省 Token，因为 Edge 代替模型做决策”。这只能说明更多 deterministic routing 可能减少不必要的模型调用，不能推出 LangGraph 品牌本身更省。
例如 CrewAI Flow 同样可以把确定性分支放在代码里；LangGraph 也完全可以设计一个每个节点都调用模型的昂贵图。
公平实验固定：
same task
same model
same tool set
same initial context
same permissions
same termination budget
same success criteria
记录：
| 指标 | 说明 |
|---|---|
| model_calls | 模型调用次数 |
| input/output/cache tokens | Token 真实用量 |
| tool_calls | 工具调用与重复 |
| task_success | 任务完成 |
| wall_time / P95 | 延迟 |
| recovery_success | 故障后恢复 |
| manual_intervention | 人工接管 |
| cost_per_success | 成功任务成本 |
状态模型：别把 Memory、State、Checkpoint 混在一起
CrewAI Flow state、LangGraph graph state、长期用户 memory 和外部业务数据库解决的是不同问题。
一个财务 Agent 可能同时有：
request context: 当前 user/tenant/auth
workflow state: 当前步骤、已验证证据
checkpoint: 可恢复的 graph/flow execution snapshot
long-term memory: 用户偏好、长期事实
business DB: 订单/发票/审批记录
无论框架，都不要把所有内容塞进“Memory”。状态边界越清晰，恢复、删除、权限和审计越容易。
可观测性：看失败链路，不给品牌打五星
生产比较时，应分别拿一条失败 Trace 回答：
- 哪个模型/Prompt 版本；
- 哪个 Agent/Node/Task；
- 调了什么 Tool；
- 参数是否通过授权；
- 错误类别；
- State 有什么变化；
- 重试/恢复发生几次；
- 人工做了什么决定；
- 最终成本和延迟。
能不能把这些数据稳定拿出来，比“调试体验极佳/较差”的主观评级更有价值。
什么时候优先 CrewAI
优先验证 CrewAI，当：
- 角色/Task/委派是团队沟通的自然语言；
- 希望在一个 Flow 内混合确定性步骤和 Crew；
- 产品团队愿意以 Crew/Flow 作为主要领域抽象；
- 多 Agent 协作是核心，而不是偶尔出现。
什么时候优先 LangGraph
优先验证 LangGraph，当：
- 需要细粒度 state schema；
- 长任务必须可靠 pause/resume；
- checkpoint/thread/fork 是核心能力；
- 复杂条件路由与子图需要直接控制；
- 已在 LangChain 生态，需要从
create_agent下沉 runtime； - 对执行语义的控制比角色抽象更重要。
最终判断
CrewAI 和 LangGraph 都可以进入生产系统，前提是你把权限、幂等、状态、评估和可观测性做完整。CrewAI 不是“只适合运营自动化”，LangGraph 也不是“金融级工业标准”的同义词。
最靠谱的选型方式是做同任务 PoC，主动注入一次 timeout/工具失败/人工 interrupt，再比较恢复行为、状态可解释性、模型调用数和维护成本。如果这组实验没有做，就不要从框架名称提前宣布赢家。
继续阅读
- LangGraph 实战：状态、Checkpoint 与 HITL
- LangGraph 状态隔离
- LangGraph 失败恢复
- CrewAI vs AutoGen
- LangChain vs CrewAI
继续按生产级 LangGraph 路线读，不再重复看泛入门
这一类文章统一沉淀到 LangGraph 专题页，按状态隔离、Checkpointer、HITL、失败恢复、Observability、Supervisor/Worker、Subgraph 和 Memory 顺序阅读。
继续阅读
返回专题 →AI 工程周报
只发真正改变工程判断的变化、故障、实验和新资产。
参与讨论
问题、验证与勘误
登录后可发表评论。所有新评论先进入审核；审核期间仅评论者本人和管理员可见，通过后才公开。