调查研究-186 LangChain 和 LangGraph 的区别：从快速构建 Agent 到生产级工作流编排

LangChain vs LangGraph：2025 Agent 框架选型全景指南（组件抽象 vs 流程编排）

TL;DR

• 场景：选型时同时遇到 LangChain 和 LangGraph，搞不清谁替代谁、什么时候该用哪个、复杂 Agent 该怎么组合。
• 结论：LangChain 是 LLM 应用开发框架（组件层：模型/Prompt/工具/Retriever/Middleware），LangGraph 是 Agent Runtime（流程层：State/Node/Edge/Checkpoint/Interrupt）；生产级 Agent 通常需要二者组合。
• 产出：七维差异表 + RAG / Tool Calling / 多 Agent 选型策略 + 18 节工程实践建议 + 生产级组合架构图。

版本矩阵

摘要：LangChain 和 LangGraph 不是"谁替代谁"的关系，而是站在不同抽象层级解决不同问题。LangChain 更像 LLM 应用开发框架，负责模型、Prompt、工具、Retriever、Agent、Middleware 等组件抽象，让开发者快速把大模型能力接进应用。LangGraph 更像 Agent runtime / 工作流编排引擎，负责 State、Node、Edge、条件跳转、checkpoint、interrupt、人类介入、持久化和失败恢复。本文从工程选型视角拆解二者差异、典型场景、代码组织方式、RAG/工具调用/多 Agent 选择策略，以及生产级 Agent 为什么通常需要 LangChain + LangGraph 组合。

关键词：LangChain、LangGraph、AI Agent、Agent 工作流、LangChain vs LangGraph、StateGraph、Human-in-the-loop、Durable Execution、RAG、Tool Calling、多 Agent、生产级 Agent、LLM 应用开发

手绘风格对比信息图：左侧 LangChain 用"黄色工具箱"类比，封装 Prompt / Tool / RAG 组件；右侧 LangGraph 用"网格纸上的有向图"类比，含 State / Node / Edge / Checkpoint 四要素；右下角 CSDN @武子康 署名。

1. 先说结论：不是替代关系

如果你最近开始做 AI Agent，大概率会同时看到 LangChain 和 LangGraph。

很多人的第一反应是：LangGraph 是不是 LangChain 的升级版？以后是不是只用 LangGraph，不用 LangChain？或者反过来，LangChain 已经能做 Agent，为什么还要学 LangGraph？

这个问题不能用"谁替代谁"来理解。

更准确的说法是：

• LangChain 关注"怎么更快地构建 LLM 应用"。
• LangGraph 关注"怎么更可靠地编排 Agent 的执行过程"。

简单类比：

LangChain 更像应用开发框架
LangGraph 更像工作流引擎 / 状态机 / Agent Runtime

如果你只是想快速做一个能调用工具的 Agent，LangChain 会更快。
如果你要做一个可控、可恢复、可观测、能插入人工审核、能处理复杂分支的生产级 Agent 系统，LangGraph 更合适。

2. LangChain 是什么

LangChain 最早被大量开发者认识，是因为它提供了一套比较完整的大模型应用开发抽象。

在没有这些封装之前，开发一个 LLM 应用通常要自己处理很多胶水代码：

• 调用不同模型厂商 API。
• 管理 Prompt 模板。
• 组织多轮对话上下文。
• 接入外部工具。
• 接入向量数据库。
• 实现 RAG 检索增强生成。
• 解析模型输出。
• 构建 Agent 循环。

LangChain 把这些能力封装成统一组件，让开发者可以更快组合应用。

例如官方 v1 文档里的风格是：

from langchain.agents import create_agent

def get_weather(city: str) -> str:
    return f"It's always sunny in {city}!"

agent = create_agent(
    model="anthropic:claude-sonnet-4-5",
    tools=[get_weather],
    system_prompt="You are a helpful assistant",
)

agent.invoke(
    {"messages": [{"role": "user", "content": "what is the weather in sf"}]}
)

这段代码背后的意思是：模型、工具、消息格式、Agent loop 都被统一成高层接口。你不用从零写一套 Agent 框架。

这就是 LangChain 的核心价值：减少重复工程，让开发者快速把大模型能力接入真实应用。

手绘插图"LangChain 快在哪"：模型（机器人）、Prompt（对话气泡）、工具（工具箱）、Retriever（放大镜+文档）四个核心组件，组合快速做出 Agent；右下角 CSDN @武子康 署名。

3. LangChain 适合什么

LangChain 适合普通 LLM 应用，比如聊天机器人、文档问答、总结生成、文本分类、结构化信息抽取。

它也很适合常见 RAG：

用户提问
  ↓
查询向量数据库
  ↓
取回相关文档
  ↓
拼接 Prompt
  ↓
调用大模型
  ↓
返回答案

如果你的流程就是这样，LangChain 的 Document Loader、Text Splitter、Retriever、Vector Store、Prompt Template、Model wrapper 都可以直接用。

它还适合简单工具调用 Agent：

用户问天气 → 调天气 API
用户问汇率 → 调汇率工具
用户问指标 → 调 SQL 工具
用户要报告 → 调文档生成工具

如果 Agent 的主要流程是"模型思考、决定是否调用工具、调用工具、继续思考、最终回答"，LangChain 的高层 Agent 封装会比较省事。

项目早期 Demo / PoC 也适合 LangChain。早期最大问题不是流程是否极致可控，而是能不能快速验证方向。

4. LangChain 的局限：复杂 Agent 会撞到封装边界

LangChain 的优点是快，局限也来自"快"。

简单 Agent 用高层封装很舒服，但复杂 Agent 往往会出现这些问题：

• 流程不够透明。
• 状态不够清晰。
• 失败恢复不好控制。
• 多分支决策难维护。
• 人工审核节点不好插入。
• 工具调用副作用难管理。
• 长任务中断后难恢复。

举个例子：你要做"自动处理客户邮件"的 Agent。

流程可能是：

读取邮件
判断邮件类型
识别紧急程度
检索知识库
生成回复草稿
如果涉及退款则人工审核
如果是技术问题则创建工单
如果是普通问题则直接回复
记录处理日志
失败后允许恢复

这已经不是一个"会自己思考的 Agent"就能优雅解决的问题。你真正需要的是一个可控业务流程：

• 哪些步骤固定执行？
• 哪些步骤交给模型判断？
• 哪些节点可以重试？
• 哪些节点需要人工确认？
• 哪些状态必须持久化？
• 哪些外部副作用必须幂等？
• 失败后从哪个节点恢复？

这就是 LangGraph 出现的意义。

5. LangGraph 是什么

LangGraph 是一个面向 Agent 工作流的低层编排框架。官方文档把它定位为构建 long-running、stateful agents 的 orchestration framework，也明确提到 persistence、human-in-the-loop、durable execution 等能力。

它的核心思想是：把复杂 Agent 拆成图。

图里有几个核心概念：

• State：状态。
• Node：节点。
• Edge：边。
• Conditional Edge：条件边。
• Checkpoint：检查点。
• Interrupt：中断。
• Thread：一次可恢复的执行上下文。

一句话解释：

LangGraph 把 Agent 从"黑盒循环"变成"显式可控的状态图"。

传统 Agent loop 通常像这样：

while not finished:
    model decides next action
    run tool if needed
    append result
    continue

LangGraph 的模式更像：

用户输入
  ↓
意图识别节点
  ↓
条件判断
  ├── 普通问答 → 直接回答节点
  ├── 知识库问题 → 检索节点 → 回答节点
  ├── 工单问题 → 创建工单节点 → 人工审核节点
  └── 高风险操作 → 人工确认节点 → 执行节点
  ↓
结束

每个节点是明确函数，每条边是明确流转关系，状态在节点之间传递。

手绘信息图"LangGraph 强在哪"：中心四要素 State（蓝色）/ Node（绿色齿轮）/ Edge（黄色箭头）/ Bot（粉色机器人）相互连接，左侧 Checkpoint（带软盘的剪贴板，支持状态回溯与错误恢复）与 Interrupt（带暂停按钮的虚线框，代表 Human-in-the-loop）作为扩展能力；右下角 CSDN @武子康 署名。

6. LangGraph 的核心价值：可靠执行过程

LangGraph 的核心不是让模型更聪明，而是让执行过程更可靠。

复杂 Agent 系统里，模型只是其中一个组件。生产系统真正难的是：

• 状态怎么保存？
• 节点怎么重试？
• 失败怎么恢复？
• 工具调用怎么记录？
• 人工审批怎么插入？
• 流程分支怎么表达？
• 多轮任务怎么延续？

一个简化 LangGraph 代码大概是：

from typing import TypedDict
from langgraph.graph import StateGraph, START, END

class AgentState(TypedDict):
    question: str
    route: str
    answer: str

def classify_node(state: AgentState):
    if "审批" in state["question"]:
        return {"route": "approval"}
    return {"route": "normal"}

def normal_answer_node(state: AgentState):
    return {"answer": "这是普通问题回答"}

def approval_node(state: AgentState):
    return {"answer": "这个问题需要审批"}

def route_decision(state: AgentState):
    return state["route"]

builder = StateGraph(AgentState)
builder.add_node("classify", classify_node)
builder.add_node("normal_answer", normal_answer_node)
builder.add_node("approval", approval_node)

builder.add_edge(START, "classify")
builder.add_conditional_edges(
    "classify",
    route_decision,
    {"normal": "normal_answer", "approval": "approval"},
)
builder.add_edge("normal_answer", END)
builder.add_edge("approval", END)

graph = builder.compile()

这段代码表达的不是简单对话，而是一个可控流程。你可以清楚知道 Agent 每一步会走到哪里。

7. LangChain 和 LangGraph 的关系

现在可以这样概括：

LangChain 是高层 Agent 框架
LangGraph 是低层 Agent Runtime
LangChain 的 Agent 能力建立在 LangGraph 之上
LangGraph 可以独立使用
二者可以组合使用

你可以只用 LangChain：快速做文档问答、简单工具调用 Agent、自然语言数据库查询助手。

你也可以只用 LangGraph：自己定义状态、节点、边、条件跳转、持久化和恢复。

更常见的生产方式是组合使用：

LangChain 负责模型、工具、Retriever、Prompt
LangGraph 负责编排、状态、分支、恢复、人工介入

LangChain 解决组件层问题，LangGraph 解决流程层问题。

8. 用后端视角理解

如果你是 Java / 后端开发者，可以这样类比：

LangChain 像 Spring Boot + 一批 AI Starter
LangGraph 像轻量级工作流引擎 / 状态机 / DAG Runtime

LangChain 让你快速搭应用：

• 模型调用封装。
• 工具封装。
• Prompt 模板。
• RAG 组件。
• Agent 抽象。
• 第三方集成。

LangGraph 关心流程运行：

• 流程节点。
• 状态流转。
• 条件分支。
• 失败恢复。
• 任务持久化。
• 人工审批。
• 执行轨迹。

这个类比不是完全等价，但能帮助抓住本质：

LangChain 让你更快写 AI 应用
LangGraph 让你更稳地跑 AI 工作流

9. 简单 Agent：优先 LangChain

假设你要做一个简单工具调用 Agent：

用户问问题
Agent 可以调用搜索工具
Agent 可以调用计算器
最后返回答案

这种场景下，LangChain 更合适。

你只需要关心：

• 模型是什么。
• 工具有哪些。
• 系统提示词是什么。
• 用户输入是什么。

如果需求只是这样，强行上 LangGraph 反而会增加状态设计、节点拆分和流程维护成本。

10. 复杂工作流：优先 LangGraph

再看"AI 客服邮件处理系统"。

需求可能是：

读取用户邮件
判断问题类型
判断紧急程度
普通问题 → 检索知识库并生成回复
Bug → 创建工单并回复用户
退款 → 人工审批
信息不足 → 继续追问用户
所有结果记录日志
失败后从中断位置恢复

这就是典型的 deterministic workflow + agentic behavior：

一部分流程由代码控制
一部分决策交给模型

可以设计成：

START
  ↓
read_email
  ↓
classify_intent
  ↓
route_by_intent
  ├── faq → search_docs → draft_reply → send_reply
  ├── bug → create_ticket → draft_reply → send_reply
  ├── refund → human_review → approved? → refund / reject
  └── unclear → ask_followup
  ↓
END

这时每个节点职责明确，状态可测试，失败可恢复，人工审核也能插入。

手绘流程图"客服 Agent 工作流"：横向五个彩色便签依次为 分类（放大镜）→ 检索（文档）→ 工单（剪贴板）→ 人工审核（人形）→ 回复（对话气泡），下方虚线连接 Checkpoint（带软盘勾选）与 Logbook（带心形的打开书本），表示持久化和日志能力；右下角 CSDN @武子康 署名。

11. 七个关键区别

第一，抽象层级不同。

LangChain 是高层抽象，目标是少写代码、快速组合。LangGraph 是低层抽象，目标是显式定义流程。

第二，流程控制不同。

LangChain 的 Agent 更偏模型驱动循环；LangGraph 允许把业务规则写进图结构。比如退款前必须人工审批、删除数据前必须二次确认、执行 SQL 前必须校验权限，这些不应该交给模型自由发挥。

第三，状态管理不同。

复杂 Agent 会产生大量中间状态：任务计划、工具结果、检索结果、审批结果、失败原因、重试次数。LangGraph 强调显式 State，比把所有内容都塞进 message history 更工程化。

第四，失败恢复不同。

Demo 失败可以重跑，生产失败不能随便重跑。重复创建工单、重复发邮件、重复调用付费 API 都会出问题。LangGraph 的 checkpoint 和 durable execution 思路更适合长任务恢复。

第五，human-in-the-loop 不同。

生产系统里，退款、发邮件、数据库修改、执行命令都可能需要人工确认。LangGraph 的 interrupt 模式可以在图执行到某个节点时暂停，保存当前状态，等外部输入后继续。

第六，可观测性不同。

复杂 Agent 调试时，你需要知道走了哪些节点、每个节点输入输出是什么、状态怎么变化、工具返回什么、失败在哪一步。图结构天然更适合 tracing 和回放。

第七，代码组织方式不同。

LangChain 围绕 model、prompt、retriever、tool、agent、chain 组织；LangGraph 围绕 state、node、edge、conditional edge、checkpoint、interrupt 组织。

12. RAG 场景怎么选

简单 RAG：

用户提问 → 检索文档 → 调模型 → 返回答案

用 LangChain 就够。

复杂 RAG：

先判断问题类型
不同类型查不同知识库
检索结果不足时改写 query
多轮检索后合并证据
答案生成后做事实校验
低置信度时转人工
最终答案需要审批

这时 RAG 已经不是一个简单 chain，而是复杂工作流。LangGraph 更适合表达。

13. Tool Calling 怎么选

简单工具调用，比如搜索、计算、查天气、查指标，LangChain 足够。

但工具调用一旦有副作用，就要谨慎：

• 发邮件。
• 删数据。
• 改数据库。
• 下订单。
• 退款。
• 创建工单。
• 执行 Shell 命令。
• 重启服务。

这类动作不能让模型随便调用。你需要权限校验、参数校验、风险识别、人工确认、执行记录、失败回滚、幂等控制。

LangGraph 更适合把这些控制点显式建模：

model_generate_action
  ↓
validate_action
  ↓
risk_check
  ↓
human_approval
  ↓
execute_action
  ↓
audit_log

14. 多 Agent 怎么选

多 Agent 不等于先进。

很多项目一上来设计：

Planner Agent
Research Agent
Coder Agent
Reviewer Agent
Executor Agent

看起来很高级，但真正的问题是：

• 谁负责调度？
• 状态怎么共享？
• 任务怎么拆分？
• 结果怎么合并？
• 冲突怎么处理？
• 失败怎么恢复？

如果这些问题没有解决，多 Agent 只是多个黑盒互相甩锅。

LangGraph 的图结构适合表达多 Agent 协作。你可以把不同 Agent 当成节点，也可以把子流程封装成 subgraph。

15. 选型判断表

最常见的真实答案是：

早期用 LangChain
复杂后引入 LangGraph
生产级系统二者组合

手绘决策图"Agent 框架怎么选"：三栏对比——黄色栏 LangChain（工具箱图标，主打"快速搭建 / Demo / RAG"）；蓝色栏 LangGraph（白板流程图+终点旗帜，主打"复杂编排 / 长任务 / 审核"）；绿色栏"组合使用"（三层堆叠图标，象征二者叠加）；右下角 CSDN @武子康 署名。

16. 什么时候从 LangChain 迁移到 LangGraph

如果你的 Agent 出现下面这些信号，就应该考虑 LangGraph：

• 流程开始出现多个分支。
• 不同任务需要不同路径。
• 中间状态越来越多。
• 工具调用有副作用。
• 需要人工审核。
• 失败后不能简单重跑。
• 需要记录完整执行轨迹。
• 需要长时间运行。
• 需要多个 Agent 协作。
• 需要可视化流程和调试。

尤其是三个信号最关键：

需要状态持久化
需要人工介入
需要失败恢复

只要出现这三个需求，LangGraph 的价值就会明显提升。

17. 工程实践建议

第一，先把业务流程画出来，不要一上来就写 Agent。

先问：

• 这个任务有哪些步骤？
• 哪些步骤固定？
• 哪些步骤需要模型？
• 哪些步骤需要工具？
• 哪些步骤有副作用？
• 哪些步骤需要人工审核？
• 失败后能不能重试？

第二，不要把所有状态塞进 message history。Message history 适合对话，不适合承载所有业务状态。

第三，高风险工具调用必须加防护节点。

第四，节点要小。每个节点只做一件事。

第五，副作用操作要幂等。创建工单、发送邮件、执行命令，都要考虑重复执行问题。

第六，尽早接入 tracing。Agent 系统没有执行轨迹，很难排查问题。

第七，先做单 Agent，再考虑多 Agent。多 Agent 是复杂度放大器，不是万能药。

18. 一个生产级组合架构

一个比较合理的生产级 Agent 架构可以这样设计：

前端 / API
  ↓
任务入口服务
  ↓
LangGraph 工作流
  ↓
LangChain 组件层
  ├── Model
  ├── Tool
  ├── Retriever
  ├── Prompt
  └── Output Parser
  ↓
外部系统
  ├── 数据库
  ├── 向量库
  ├── 搜索服务
  ├── 工单系统
  ├── 邮件系统
  └── 内部 API
  ↓
日志 / 监控 / 评估

在这个架构里：

LangGraph 负责流程怎么跑
LangChain 负责组件怎么接
业务代码负责规则和边界
基础设施负责稳定性和治理

这比"让一个大模型自己决定所有事情"更像真正的 Agent 工程。

19. 最终结论

LangChain 和 LangGraph 的区别，本质是抽象层级和工程目标不同。

LangChain 解决 LLM 应用开发效率问题。它让你快速接入模型、Prompt、工具、检索器和 Agent。

LangGraph 解决复杂 Agent 执行可靠性问题。它让你把 Agent 拆成状态图，用节点、边、条件跳转、持久化和中断机制来控制执行过程。

如果你的需求是快速构建、简单问答、简单 RAG、简单工具调用，优先 LangChain。

如果你的需求是复杂流程、长期运行、失败恢复、人工介入、多分支决策、生产级 Agent，优先 LangGraph。

如果你要做真正工程化的 AI Agent 系统，最合理的方式通常不是二选一，而是组合使用：

LangChain 负责组件抽象
LangGraph 负责任务编排
业务代码负责规则边界
基础设施负责稳定运行

前者解决"能不能跑起来"。
后者解决"能不能可靠地跑下去"。

错误速查卡

作者：武子康的个人博客