LangChain vs LangGraph：2026年的变化
简要总结
LangChain 和 LangGraph 不再是真正的竞争对手;自2025年10月22日起,LangChain 的智能体构建功能已在 LangGraph 的执行引擎上运行。
LangGraph 不是 可视化拖放工具。这是一个常见的混淆(实际上那是 LangFlow,一个独立的产品)。LangGraph 是代码优先的:节点、边和共享状态对象。
LangChain 是构建可用智能体的快速路径。LangGraph 是其底层的低级运行时,用于任何需要循环、暂停或从崩溃中恢复的场景。
LangSmith 根本不是一个竞争框架;它是追踪和评估两者运行情况的可观测性层。
开发者最常见的错误: 为一个简单的单轮智能体使用 LangGraph 的完整状态机模型,而基本的工具调用循环就能很好地处理。
快速解答: LangChain 是一个使用预构建组件快速构建 LLM 驱动的应用和智能体的框架。LangGraph 是其底层的低级运行时,专为需要循环、重试、持久状态或人工审核的智能体而构建。自2025年10月 LangChain 1.0 发布以来,LangChain 自己的智能体构建器在内部运行于 LangGraph 之上;现在大多数生产系统将两者结合使用,而不是二选一。
如果你读过较早的 LangChain 与 LangGraph 对比文章,很可能在一个特定方面已经不准确了:它将两者视为两个独立的竞争选择。这种说法在2025年10月22日就不再完全正确了,当时 两个框架同时发布了首个稳定的1.0版本。
最重要的变化: LangChain 的新 create_agent 函数(在 LangChain 1.0 中构建智能体的标准方式)在底层运行于 LangGraph 的执行引擎之上。在该稳定版本发布之前,LangGraph 已经为 Uber、LinkedIn 和 Klarna 等公司的生产环境智能体提供了一年多的支持。
因此2026年真正的问题不是«LangChain 还是 LangGraph»,而是«我实际需要直接使用 LangGraph 的多少控制能力?»
什么是 LangChain
LangChain 是让你快速从零构建可用 LLM 应用的工具包。
它提供了数百个集成、模型提供商、向量存储、文档加载器和工具,因此你可以在一个下午内搭建一个 RAG 管道或工具调用智能体,而不必自己构建每个连接器。
它的 create_agent 抽象(在 v1.0 中引入)是启动可用智能体的最快方式:选择一个模型,提供一些工具,然后开始运行。
对于简单的用例——客户支持机器人、文档摘要器、单轮研究助手——这通常就是你所需要的全部。
什么是 LangGraph
LangGraph 不是可视化、低代码、拖放式工具。一些较早的对比文章这样描述它,这是一个真正的混淆;这个生态系统中实际的可视化构建器是一个名为 LangFlow的独立产品。LangGraph 本身是代码优先的。
LangGraph 将智能体建模为一个 StateGraph:节点是函数,边(包括条件边)决定接下来运行什么,共享状态对象在整个执行过程中流转。
这种结构使得循环、分支和多步推理成为可能,而无需手动编写自己的控制流。
LangGraph 1.0 增加了在对话中途服务器重启后仍能存活的持久状态、用于跨天暂停和恢复工作流的内置持久化,以及对暂停执行以便人工审核或批准步骤后再继续的一流支持。
专业提示: 如果你正在阅读的对比文章或任何资料说 LangGraph 有«拖放界面»,那么它要么是误将 LangFlow 描述成了 LangGraph,要么是基于过时的信息。在围绕它构建心智模型之前,值得再次核实。
LangChain vs LangGraph vs LangSmith:完整技术栈解析
将 LangSmith 纳入全景图可以消除很多困惑,因为它不是第三个竞争框架;它是位于两者之上的可观测性层。
LangChain应用层。提示词、工具、集成以及 create_agent 快捷方式。
LangGraph编排层。循环、分支、重试和状态转换在此变得显式化。
LangSmith真相层。用 @traceable 装饰一个函数,它会捕获每个输入、输出和嵌套调用,形成可供检查、评估和调试的运行记录。
LangChain 团队在 2026 年的建议正是这种分工:LangChain 用于构建模块,LangGraph 用于任何智能体或多步骤任务,LangSmith 用于观察运行后实际发生的情况。
LangChain vs LangGraph:并列对比
LangChain | LangGraph | LangSmith | |
定义 | 应用框架 | 编排运行时 | 可观测性平台 |
最适用于 | 快速原型开发、简单智能体 | 多步骤、有状态、多智能体系统 | 追踪、评估、调试 |
接口 | 代码(Python/JS) | 代码(Python/JS):非可视化 | Web 仪表板 + @traceable 装饰器 |
状态处理 | 有限,请求作用域 | 持久化,重启后存活 | 不适用(观察两者) |
人机协同 | 可能,非原生 | 一等公民,内置 | 不适用 |
自 2025 年 10 月起 | create_agent 运行在 LangGraph 上 | 驱动 LangChain 的智能体执行 | 自动追踪两者 |
有状态 vs. 无状态:真正的技术差异
无状态设置 独立处理每个请求,适用于摘要或翻译等简单的单轮任务,这些任务在调用之间无需记住任何内容。
有状态设置,也就是 LangGraph 的构建基础,在智能体执行的每个步骤中保持共享状态对象的活跃。这使得智能体能够在上下文完整的情况下重试失败的工具调用,暂停等待人工批准,或者在进程重启后从中断处精确恢复。如果你的智能体需要记住三步之前发生的事情来决定下一步做什么,你就需要状态,而这正是 LangGraph 存在的全部理由。
专家见解: 一位开发者在进行 v1.0 迁移时指出了一个值得提前了解的实际细节: LangChain 1.0 中的 agent state 现在必须表示为扩展 AgentState 的 TypedDict,不再支持 Pydantic 模型。如果你的技术栈在其他地方依赖 Pydantic,需要为此调整预留时间。
何时使用各自:Agent 工作流与多 agent 系统
选择 LangChain 的 create_agent 当你需要快速构建一个可用的 agent,且工作流基本是线性的:收集上下文、调用工具、响应。客户支持、基于 RAG 的问答和内容生成都适合这种场景。
直接选择 LangGraph 当你在构建多 agent 系统、需要 agent 循环并重新评估自身进度、需要人工审批步骤,或需要执行状态在长时间运行或跨天工作流中能够从故障中恢复。复杂的研究 agent、审批流程和后台自动化任务是天然的适用场景。
开发者常犯的错误
最常见的错误不是语法错误,而是在一个本质上只是循环的任务上使用 LangGraph 的完整状态机模型:
一位开发者对该生态系统的公开评论说得很好: 一个 AI agent,从本质上讲,往往只是一个循环中的 LLM 调用,决定是调用工具还是返回结果。当一个简单函数就能解决问题时,用完整的图模型来构建会增加实际复杂度而没有实际收益。
第二个常见错误正好相反: 在实际需要自定义重试逻辑、条件路由或暂停审批步骤时,仍然坚持使用 create_agent 的默认设置,然后与框架较劲,而不是直接降级到 LangGraph 的 StateGraph。
常见错误: 认为 LangGraph 取代了 LangChain,或者必须二选一。自 v1.0 起,它们被设计为配合使用;LangChain 的 agent 构建器默认运行在 LangGraph 引擎上。
初学者与生产环境的最佳选择
初学者: 从 LangChain 的 create_agent开始。它能以最少的设置让你获得一个可用的 agent,当你开始与它较劲时,你就会清楚地知道何时已经超出了它的适用范围。
生产环境: 2026 年大多数严肃的系统会同时使用两者,LangChain 用于构建块和集成,LangGraph 用于底层处理任何需要从崩溃中恢复、暂停等待人工操作或可靠循环的场景。将其视为具有两层控制的单一技术栈,而非两个竞争工具。
CyberYozh 如何支持 AI agent 和网络数据采集
无论你选择 LangChain 还是 LangGraph,大多数真实 agent 最终都需要超出模型范围:浏览网页、将数据拉入 RAG 管道,或调用期望真实、干净连接的外部工具。这就是代理处理的层面,也是 agent 架构讨论中常见的盲点。
住宅和 移动代理 适用于进行实时网页浏览或数据采集的智能体,避免共享数据中心 IP 常遇到的基于 IP 的封禁
轮换 IP 起价 $2/GB,适用于为 RAG 管道或智能体工具提供数据的大规模抓取
粘性会话 可用于智能体需要在多步骤浏览任务中保持稳定连接,而非每次请求都使用新 IP 的场景
完整 API 访问 支持 SOCKS5/HTTP/UDP,因此代理轮换可直接插入 LangGraph 工具节点或自定义 LangChain 集成
数据中心代理 起价 $1.90/月,适用于不需要住宅级信任度的高速、成本敏感型自动化
99.9% 正常运行时间,在 Trustpilot 上评分 4.7+ «优秀»,确保智能体管道不会在逻辑本身健全时因基础设施而失败
