











Deep Agents:快速开发各种执行复杂任务的Agent,自带了复杂任务的拆解、跟踪、尝试记忆等功能,可以当成半成品的Agent+个性化定制
LangChain:自定义Agent的各个模块,这样可以实现个性化的 Agent 的开发
LangGraph:可以自己安排工作流,内存控制,人机交互,自定义Agent 开发的每一个环节
Deep Agent 底层依赖 LangChain 底层依赖 LangGraph
LangChain 和 LangGraph 分别适用什么场景?
LangChain 像一条自动化的流水线,解决“自动化”问题
LangGraph 不仅有记忆还懂得反复思考,能开会讨论的决策室。解决“自主化”问题
LangChain:有向无环图,DAG模式,就是路只能往前走,无法回头
LangChain 最拿手的场景:最基础的知识问答RAG,流程固定,用户提出问题,系统去库里检索资料,丢给大模型生成,最后格式化输出给用户
开发成本低,上手快
LangGraph: 任务复杂,模型没算对需要倒回去重来,或者好几个智能体在那互相配合,核心是循环+状态
任务跑一半没关系,下次直接从断点那接着跑。
AI写了一封给客户的邮件,发之前先停那,需要人工审批,等人工点发送



LangChain 和 LangGraph 的关系,更像是 “工具箱” 与 “流水线设计图” 的关系。它们不是二选一的对手,而是一个强大技术栈的不同层面。
你的选择核心取决于流程的复杂度。这里为你总结了它们的区别和选型建议:
| 维度 | LangChain | LangGraph |
|---|---|---|
| 定位 | 模块化工具箱:提供各类组件(模型、解析器、向量库等) | 编排引擎:用于设计组件间的复杂流转关系 |
| 设计哲学 | 链式思维:线性执行 A → B → C,像一条流水线 |
图式思维:状态机模型,支持灵活的条件分支与循环 |
| 核心优势 | 快速开发:生态丰富,代码简洁,集成方便 | 精细控制:状态管理出色,支持动态路由、重试和“人机协同” |
| 复杂处理 | 弱:处理分支/循环需额外代码,易变成复杂的“意大利面式”代码 | 强:原生支持条件边、循环和并行节点 |
| 状态管理 | 隐式:通过链或内存传递,管理较为简单 | 显式:全局状态对象,提供快照、持久化与时间旅行能力 |
| 错误恢复 | 脆弱:单点失败可能导致整体中断 | 健壮:内置重试、回滚与备用路径 |
| 学习曲线 | 平缓:API直观,文档丰富,上手快 | 较陡:需理解状态机、图结构等概念 |
通常,我们从LangChain快速起步,当遇到瓶颈时,再在LangGraph中寻求突破。
当你的任务流程是线性的,或是快速原型验证时,LangChain是最高效的选择。
检索 -> 增强 -> 生成 三步走。实例:微软官方教程就展示了用LangChain仅用几行代码,就能快速构建一个能调用工具、管理记忆的AI旅行社Agent。
当你的智能体需要自我反思、多轮决策或长期运行时,LangGraph是更可靠的方案。
实例:全球薪酬平台Remote的真实案例中,他们先用LangChain的“工具箱”调用工具,再用LangGraph这张“设计图”编排了文件摄入 -> 分析 -> 代码执行 -> 校验的复杂流转,自动化了原本需要手动处理数千张表格的客户 onboarding 流程。
在生产环境中,这两个框架常常是合作共存的:
loader 加载文档、调 API 查天气。有趣的是,从 LangChain v1.0 开始,其高级 create_agent 方法底层正是由 LangGraph 驱动的。这表明两者在 LangChain 生态中的地位——未来并不是非此即彼,而是基于 LangGraph 核心,享受 LangChain 的便捷。
你目前打算用它们构建什么类型的应用呢?比如是简单的知识库问答,还是需要多轮决策的复杂智能体?告诉我你的具体场景,我可以帮你进一步判断哪个框架更适合作为起点。
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。