LangChain 与 LangGraph:如何选择正确的 LLM 框架?

本文深入比较了LangChain和LangGraph两个主流AI应用框架。LangChain擅长构建线性、顺序的工作流,如RAG系统;而LangGraph则专为需要状态管理、循环和复杂决策的图结构工作流设计。文章通过核心概念、差异对比、适用场景及代码实例,为开发者选择框架提供了清晰的决策指南。

LangChain vs LangGraph: 如何选择正确的框架!

为何这项比较很重要 —— LangChain 与 LangGraph

我构建实用的基于大语言模型的软件,观察到两种模式的出现:直截了当的线性管道和有状态的、具备代理行为的工作流。“LangChain vs LangGraph” 这个问题并非学术探讨。它决定了架构、维护以及系统如何随时间推移进行推理。

当我说 “LangChain vs LangGraph” 时,我指的是比较两种不同的设计理念。LangChain 专为线性序列优化:接受输入,按顺序运行一个或多个LLM调用,存储或返回结果。LangGraph 则为图结构优化:节点、边、循环以及跨越多个步骤的持久状态。

LangChain 的核心思想

当工作流本质上是 A 然后 B 然后 C 时,我使用 LangChain。LangChain 提供了一个标准化框架,让开发者无需硬编码集成、提示词脚手架或手动工具编排。

  • 提示词模板 —— 可重用的模板,接受变量并生成一致的LLM输入。
  • LLM无关的连接器 —— 可以在 OpenAI、Anthropic、Mistral、Hugging Face 等模型间轻松切换。
  • —— 核心抽象:组合多个步骤,使每个输出成为下一个的输入。
  • 记忆 —— 短期或长期会话上下文,对于有状态的聊天有用,但相比完整的状态机有局限。
  • 代理和工具 —— 让模型以结构化方式调用API、计算器或外部服务。

LangChain 让开发者能快速提高生产力。对于原型化提示词、构建简单的RAG系统,或者创建从向量存储读取并返回单一响应的问题解答管道,LangChain 是一个高效的选择。

LangGraph 的核心思想

LangGraph 构建在 LangChain 概念之上,但将工作流重新构想为图。当系统必须保持复杂状态、循环、做出决策或编排多个专业代理时,我会考虑 LangGraph。

  • 节点 —— 离散的任务:调用LLM、从数据库获取数据、运行网络搜索或调用摘要器。
  • —— 定义条件转换、并行分支或循环路径。
  • 状态 —— 在节点间演化的动态上下文:消息、情节记忆和检查点。
  • 决策节点 —— 原生支持条件逻辑和路由到专业代理。

LangGraph 将应用程序视为状态机。节点可以循环、重新访问早期步骤,并执行多轮工具调用。这实现了代理行为,如反思、迭代检索或答案的渐进式改进。

并列差异 —— LangChain 与 LangGraph 的实用清单

我喜欢将技术选择简化为一个清单。对于 “LangChain vs LangGraph”,以下是我在决定采用哪一个时使用的实用比较。

方面 LangChain LangGraph
流程类型 线性和顺序的。 循环的、基于图的,带循环。
状态管理 有限的会话记忆。 跨节点和会话的丰富、持久状态。
条件与循环 简单分支和单次工具调用。 内置的条件边、循环和检查点。
复杂性与代理 适用于简单的聊天机器人、RAG 或类似ETL的LLM管道。 适用于多代理系统、自主代理行为和长时间运行的工作流。
人在循环 可能,但不是原生功能。 检查点和人在循环是一等模式。

当我权衡 “LangChain vs LangGraph” 时,我不仅考虑当前需求,也考虑预期的未来复杂性。如果应用可能发展成多代理编排,或者需要持久状态和重试,那么一开始就使用 LangGraph 可以避免后续的重构。

何时选择 LangChain

我推荐 LangChain,当你需要开发速度且工作流直接明了时。典型场景包括:

  • 文本转换管道:总结、翻译或提取信息并保存结果。
  • 快速原型化提示词和测试链。
  • 单轮用户交互,如客户支持响应。
  • 执行向量存储检索并返回单一合成答案的基本RAG系统。

LangChain 非常适用于这些任务,因为它提供了即插即用的组件——提示词模板、检索器和链组合器——让你可以快速交付,而无需自己构建编排原语。

何时选择 LangGraph

当需要自主性、迭代和状态时,我会选择 LangGraph。在以下情况选择 LangGraph:

  • 系统需要多步骤决策,并能循环直到满足退出条件。
  • 根据上下文将查询路由给专业代理。
  • 跨多个LLM调用和用户交互的持久状态。
  • 复杂的工具使用,包括多轮网络搜索、摘要和外部源聚合。

例如,我构建了一个邮件起草代理,它能检索用户偏好、查阅日历、起草邮件、请求澄清,然后迭代地优化草稿。这类工作流自然映射到 LangGraph。

实践演练 —— 一个实用的 LangChain 示例

我经常用一个使用向量存储的RAG例子来演示概念。LangChain 模式如下:

  1. 安装所需的包并配置API密钥。
  2. 创建接受变量(如"目标"和"主题")的提示词模板。
  3. 通过 Hugging Face、OpenAI 或其他提供商初始化LLM或本地模型连接器。
  4. 将文档存储到向量数据库并创建检索器。
  5. 构建一个检索增强生成链,用于检索上下文并合成答案。

这种模式保持线性:检索相关文档然后生成答案。它适用于许多FAQ机器人、文档助手和单次处理管道。代码紧凑且易于迭代,这是在比较"LangChain vs LangGraph"时的核心优势之一。

实践演练 —— 一个实用的 LangGraph 示例

现在想象同样的任务,但增加了当本地语料库缺乏最新信息时需要获取新鲜网络结果的需求。LangGraph 工作流如下:

  1. 从URL或文档将静态内容加载到向量存储。
  2. 创建图节点:检索、网络搜索、决策和生成。
  3. 定义状态:跟踪检索结果是否回答了用户,存储中间摘要,并记录工具输出。
  4. 用条件边连接节点:如果本地检索失败,路由到网络搜索;如果网络搜索结果噪音太多,请求澄清;根据需要循环返回。
  5. 运行图,允许其迭代直到满足停止条件,然后返回最终合成结果。

这种模式支持多轮工具使用和代理推理。在我的测试中,询问一个 LangGraph 代理"本月最新的AI进展"时,当本地知识过时会触发网络搜索节点。代理获取、总结,并在呈现前检查摘要是否充分。这种行为凸显了比较"LangChain vs LangGraph"时的区别。

常见模式与反模式

随着时间的推移,我发现了一些有助于决定"LangChain vs LangGraph"的模式。可以将它们作为启发式方法。

  • 模式:从简单开始 —— 如果问题是单次处理的,使用 LangChain 快速构建以验证你的提示词。
  • 模式:演进到图 —— 如果你的单次处理管道积累了条件语句和有状态的检查点,逐步将其重构为 LangGraph 图。
  • 反模式:过早复杂化 —— 当不需要循环或持久状态时,避免实现完整的图。过度工程会降低清晰度并增加维护成本。
  • 反模式:一次性工具调用 —— 如果你需要重复或多阶段的工具编排,线性链会变得脆弱。LangGraph 的原生边和状态更合适。

示例架构模板

以下是我根据"LangChain vs LangGraph"决定时经常重用的两个模板。

模板 A —— LangChain RAG 管道 用户查询 → 检索器 → LLM提示词 → 结果 → 存储会话(可选) 适用于文档问答、帮助中心和聊天机器人,其中每个请求基本独立。

模板 B —— LangGraph 代理管道 用户查询 → 检索 → 决策节点(是否足够?)→ 如果否,网络搜索节点 → 总结 → 反思/循环 → 最终生成 → 持久化情节记忆 适用于动态信息请求、研究助手以及需要迭代推理的多代理工作流。

迁移与扩展的实用技巧

如果你从 LangChain 开始,但需要迁移到 LangGraph,我建议如下:

  1. 识别你 LangChain 中出现决策逻辑的分支点。
  2. 将提示词模板和检索器提取为可由图节点使用的独立模块。
  3. 引入轻量级状态存储,以便节点输出能在多次调用间持久化。
  4. 用封装单一职责的节点(检索、网络搜索、摘要或验证)替换单体链。

扩展 LangGraph 系统需要考虑运维因素:持久状态存储、节点的幂等性、边的可观测性以及用于昂贵操作的人工检查点。早期规划这些可以防止工作流长时间运行时出现意外。

最终决策指南 —— 快速清单

当我决定"LangChain vs LangGraph"时,我会运行这个清单:

  • 工作流是单次处理吗?选择 LangChain。
  • 是否需要循环或复杂决策?选择 LangGraph。
  • 系统是否需要随时间调用多个工具?倾向 LangGraph。
  • 你是在原型设计或探索提示词吗?从 LangChain 开始。
  • 你预期需要长时会话和持久上下文吗?LangGraph 更可取。

结语

两个框架拥有共同的目标:让使用LLM构建应用更容易。区别在于架构意图。LangChain 在线性编排和快速原型设计方面表现出色。LangGraph 在需要有状态、具备代理行为、循环工作流以及需要协调、持久化和多轮工具使用的情况下表现出色。

当我为产品评估"LangChain vs LangGraph"时,我会权衡交付时间和未来复杂性。如果你预期你的系统将发展成为自主助手或协调器,就从图思维开始并逐步迁移组件。如果你今天需要一个快速、可维护的管道,LangChain 很可能就能很好地为你服务。

LangChain 是这样的 —— A 然后 B 然后 C,遵循预定义的路径。而 LangGraph 则遵循动态路径。它从 A 开始,然后决定是否需要 B 或 C。根据场景,它可以直接跳到 C。循环,重复,直到目标满足。

如果你想复现我描述的例子,对于 LangChain,可以从提示词模板和小型向量存储开始。对于 LangGraph,将节点建模为单一职责的组件,并为流经图的数据定义清晰的状态模式。

完整代码示例

LangChain RAG 教程: https://github.com/pavanbelagatti/LangChain-SingleStore-Package

代理工作流教程: https://github.com/pavanbelagatti/LangGraph-Agentic-Tutorial

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计