用LangChain还是LangGraph？官方终于站出来表态了

探索构建LLM应用的两大流行框架，LangChain和LangGraph的区别与应用场景。

核心内容：

1. LangChain和LangGraph在构建LLM应用中的角色和区别

2. LangChain的基础组件及其应用方式

3. LangGraph的工作流组织方式和核心优势

无论是个人还是企业，当我们想要用大模型（LLM）开发出有趣或有价值的应用时，第一个冒出来的技术问题通常是：“用什么工具？”

这篇就来聊聊两个最流行的框架：LangChain 和 LangGraph。

眼下生成式AI正处在井喷期，每天都有新框架、新技术冒出来，所以各位在看这篇文章的时候得留个心眼——今天说的这些是对的，明天可能就不一定了。

弄明白这两个框架各自的基本元素，你就能更清楚地看到，它们在处理核心功能时的思路到底差在哪里。这一节不打算罗列每个框架的所有组件，而是要帮大家打下理解它们方法论差异的基础。

LangChain

用LangChain主要分两种方式：一种是按设定好的命令走顺序链（Chain），另一种是用 LangChain Agent。两者在工具和编排方式上不太一样。链是预定义的线性流程，而 Agent 则是充当一个协调者，能做更动态、更非线性的决策。

• Chain（链）
  ：把一系列步骤串起来，这些步骤可以是调用LLM、Agent、工具、外部数据源、过程式代码等等。链可以分支，也就是根据不同的逻辑条件，把单一路径拆成多个分支。

• Agent 或 LLM
  ：LLM能生成自然语言回复，但 Agent 在这个基础之上增加了推理能力、工具调用能力，并且调用失败还能重试——更加强大。

• Tool（工具）
  ：就是能被链调用、或者被Agent触发的代码函数，用来和外部系统打交道。

• Prompt（提示词）
  ：包括系统提示词（告诉模型怎么干、有哪些工具可用）、从外部数据源注入的信息（给模型补上下文）、以及用户的输入需求。

LangGraph

LangGraph构建AI工作流的思路跟前面那个不一样。顾名思义，它用的是图（Graph）来编排流程。正因为它在处理AI Agent、过程式代码和其他工具时非常灵活，所以特别适合那些线性链、分支链、或者简单Agent系统搞不定的复杂场景。LangGraph天生就是为了处理更复杂的条件逻辑和反馈循环而生的，比LangChain更强大。

• Graph（图）
  ：一种很灵活的工作流组织方式，能调用LLM、工具、外部数据源、过程式代码等等。它还支持循环图，也就是说可以创建循环和反馈机制，让某些节点可以被多次访问。

• Node（节点）
  ：代表工作流中的一个步骤，比如一次LLM查询、一个API调用、或者一次工具执行。

• Edge（边）和 Conditional Edge（条件边）
  ：边用来连接节点，定义信息的流向，让一个节点的输出变下一个节点的输入。条件边就厉害了，它能在满足特定条件时，让信息从一个节点流到另一个节点。开发者可以自己定义这些条件。

• State（状态）
  ：表示应用当前的运行状态，随着信息在图里流动会不断更新。State是一个开发者定义的可变TypedDict对象，包含当前执行图所需的全部相关信息。LangGraph会自动在每个节点更新它。

• Agent 或 LLM
  ：在图中，LLM只管对输入生成文本回复。而Agent能力则允许图里有多个节点，分别对应Agent的不同组件，比如推理、工具选择、工具执行。Agent可以决定在图里走哪条路、更新图的状态、干更多比单纯文本生成复杂的事。

说到底，

。

LangGraph和LangChain有些本事是重叠的，但处理问题的方法很不一样。LangChain主要盯着线性工作流（通过链）或者各种AI Agent模式，而LangGraph则专注于创建更灵活、更细粒度的、基于流程的工作流，里面可以塞进AI Agent、工具调用、过程式代码等。

总体来看，

，因为它提供了更多的抽象封装和预定义配置，用来做简单场景很顺手。而LangGraph则允许你对工作流设计做更细粒度的定制，代价就是抽象程度低，上手需要学更多东西。

工具调用（Tool Calling）

在LangChain里，工具怎么调用取决于你是在链里按顺序一步步走，还是光用Agent的能力（不在链里明确定义）。

• 在链里，工具是作为预定义步骤加进去的，也就是说它们不一定是Agent动态调用的，而是在设计链的时候就定好了要调哪些工具。
• 当Agent不在链里定义时，Agent自主性更强，它可以根据自己手头有哪些工具，

  决定调用哪个、什么时候调
  。

：

Agent方式的流程示例：

在LangGraph里，工具通常被看成

。如果图里包含一个Agent，那Agent就负责根据推理能力决定调用哪个工具。当Agent选定工具后，工作流就会跳到对应的“工具节点”去执行操作。Agent和工具节点之间的边可以带上条件逻辑，从而增加额外的判断，决定要不要执行某个工具。这么一来，开发者的控制能力就精细多了。如果图里没有Agent，工具调用方式就跟LangChain的链差不多，按预定义的条件逻辑在工作流里干活。

包含Agent的图流程示例：

没有Agent的图的流程示例：

LangChain有内置的抽象层来处理对话历史和记忆。它支持不同粒度级别的记忆管理，可以控制传给LLM的token数量，主要有以下几种方式：

• 完整的会话历史
• 摘要版本的对话历史
• 自定义定义的记忆

此外，开发者还能自定义长期记忆系统，把对话历史存在外部数据库里，需要的时候再检索出来。

在LangGraph里，

，它通过记录每个时刻定义的变量来跟踪状态信息。State可以包括：

• 对话历史
• 任务执行的各个步骤
• 语言模型上一次的输出结果
• 其他重要信息

State能在节点之间传递，这样每个节点都能拿到系统当前的状态。但需要注意的是，

。如果开发者需要持久化存储记忆，需要自己引入特定节点，把记忆和变量存到外部数据库里，方便后面检索。

LangChain原生支持复杂的RAG工作流，还提供了一套挺成熟的工具，方便开发者把RAG集成到应用里。比如文档加载、文本解析、Embedding生成、向量存储、检索能力等等。开发者可以直接用LangChain提供的API（比如 langchain.document_loaders、langchain.embeddings 和 langchain.vectorstores）来实现RAG工作流。

在LangGraph里，RAG需要开发者自己设计，把它作为图结构的一部分来实现。比如可以创建单独的节点，分别用来做文档解析、Embedding计算、语义检索。这些节点之间可以通过普通边或条件边连接，各个节点的状态可以用来传递信息，在RAG流水线的不同步骤之间共享数据。

LangChain允许并行执行多个链或Agent，可以用 RunnableParallel 类实现基本的并行处理。但如果需要更高级的并行计算或异步工具调用，开发者得用Python库（比如 asyncio）自己动手实现。

LangGraph天然支持并行执行节点，只要这些节点之间没有依赖关系（比如一个LLM的输出不能是下一个节点的输入）。这就意味着多个Agent可以同时跑，前提是它们不是相互依赖的。此外，LangGraph也支持用 RunnableParallel 跑多个Graph，或者通过Python的 asyncio 库并行调用工具。

LangChain的错误处理需要开发者显式定义，可以在链里引入重试逻辑，或者在Agent里处理工具调用失败的情况。

LangGraph可以直接在工作流里嵌入错误处理逻辑，方法就是把错误处理当成一个独立的节点。当某个任务失败时，可以跳转到另一个错误处理节点，或者在当前节点直接重试。失败的节点会被单独重试，而不是让整个工作流从头再来。这样，图可以从失败的地方继续往下走，不用从零开始。如果你的任务涉及多个步骤和工具调用，这种错误处理机制就显得特别重要。

你可以：

✅ 只用 LangChain

✅ 只用 LangGraph

✅ 同时用 LangChain 和 LangGraph

另外，还能把LangGraph的图结构编排能力和别的Agent框架（比如微软的AutoGen）结合起来，比如把AutoGen的Agent当成LangGraph的一个节点。

LangChain和LangGraph各有千秋，选哪个有时候确实让人犯晕。

那么，应该在什么情况下使用？

✅ 你需要快速搭建AI工作流，比如：

• 线性任务：文档检索、文本生成、摘要这种预定义好的工作流
• AI Agent需要动态决策，但你不需要对复杂流程做精细控制

✅ 你的应用场景需要非线性工作流，比如：

• 任务涉及多个组件的动态交互
• 需要条件判断、复杂的分支逻辑、错误处理或并行执行
• 你愿意自己实现LangChain没有提供的部分功能

✅ 你希望：

• 利用LangChain现成的抽象能力（比如RAG组件、对话记忆等）
• 同时享受LangGraph的非线性编排能力

两者结合，可以充分发挥各自的优势，打造更灵活、更强大的AI工作流。