「LangChain」LangChain 和 LangGraph 的核心区别？

0 前言

本文内容整理自公众号「小林面试笔记」的文章 9. 请你详细说说 LangChain 和 LangGraph 的核心区别是什么？，用于记录与总结 LangChain 框架相关的核心面试知识点。

「请你详细说说 LangChain 和 LangGraph 的核心区别是什么？」，可以这样作答：

先把定位拉平：LangChain v1 是高层 Agent 开发框架，负责提供模型、工具、结构化输出和 middleware 等常用能力；LangGraph 是低层 Agent 编排框架与运行时，让开发者直接设计状态、节点、路由、并行、中断和恢复。最关键的关系是——create_agent 构建在 LangGraph 之上，返回一个编译后的图：LangChain Agent 不是脱离 LangGraph 的另一套引擎，它已经继承了 LangGraph 的状态、持久化、流式输出、durable execution 和 human-in-the-loop 等运行能力。所以真正的区别不在「有没有图、能不能分支」，而在开发者控制哪一层：常见的「模型判断 → 调用工具 → 返回模型」循环优先用 LangChain，配合 middleware 做提示词、重试、护栏和审批定制；若需要显式控制多个阶段、确定性步骤与 Agent 步骤混排、复杂并行、长期暂停和多 Agent 协作，直接下沉 LangGraph，create_agent 生成的 Agent 可作图中的节点或子图复用。一句话：LangChain 帮我快速得到一个好用的 Agent，LangGraph 帮我精确控制整个 Agent 系统怎么运行。

面试对话里藏着这道题的两个雷区：一是拿「能不能分支」当分界线——LCEL 有并行和分支能力，create_agent 本身就是带条件路由和循环的图；二是把「能力归属」当边界——持久化、流式输出、人工审批并不是 LangGraph 的专属，LangChain Agent 通过底层运行时同样能用。前面我们讲过架构里 LangGraph 在执行层的角色、构建 Agent 的 create_agent、以及 Checkpointer 与 Store 的记忆分工，这篇把它与 LangGraph 正面放到一起：层级关系、抽象层级、状态模型、运行时能力归属，以及什么时候该下沉。

1 先定层级：上层框架与下层运行时

很多同学会先问「哪个功能更多」，就像比较一台咖啡机和它内部的控制系统——这忽视了它们根本不在同一层。截至 2026 年 7 月的官方定位是：

  • LangChain v1：高层 Agent 框架，提供模型、工具、常见 Agent 循环和 middleware 等「开箱即用」能力；
  • LangGraph：低层编排框架与运行时，负责有状态流程如何执行、如何暂停和恢复。

人话理解：LangChain 给我们一套装好的 Agent，LangGraph 让我们自己设计整条业务路线。但要注意，LangGraph 并不是 LangChain 的附属品——它能用 LangChain 的模型和工具组件，但不强制依赖，也可以直接接其他模型的 SDK 或普通 Python 函数。

两者的关系不是并列，而是栈式叠放：

1
LangChain 高层 Agent API -> 编译后的 LangGraph -> 检查点、流式事件、中断与执行运行时

咖啡机比喻：LangChain 与 LangGraph 是上下层关系，一个提供装好的 Agent，一个控制整体如何运行

这就像拿到一辆装配好的新能源车（LangChain）：方向盘、刹车、自动泊车都调好了，你改改座椅、加个行车记录仪就能上路；而 LangGraph 相当于底盘的线控平台，转向、刹车、油门怎么联动、传感器信号往哪走，都要你自己接线。用 LangChain 时，框架替你搭好常见 Agent 拓扑，你配置零件和生命周期钩子；用 LangGraph 时，节点怎么拆、状态怎么更新、下一步去哪，都由你决定——上一篇文章说的「LangChain 定协议，LangGraph 跑状态」，在这里就是字面意思。

2 一张表看核心差异

把两个框架各自的抽象做一次对照，差异就清楚了：

对比维度 LangChain v1 LangGraph
官方定位 高层 Agent 开发框架 低层 Agent 编排框架与运行时
主要入口 create_agent、模型、工具、middleware StateGraph、State、Node、Edge、Command、Send
默认提供 预构建的模型与工具调用循环 + 常用扩展点 编排原语，不替你规定 Prompt 或 Agent 架构
控制流 标准 Agent loop 已搭好，用 middleware 定制 显式定义顺序、条件路由、循环、并行、子图
状态 AgentState + messages 默认核心，可扩展字段 完整 State Schema、输入/输出/内部通道、reducer
持久化与记忆 经底层 LangGraph 使用 checkpointer 和 store 在图编译与运行层直接控制 thread、状态历史
人工介入 HumanInTheLoopMiddleware 审批工具调用 节点内 interrupt() 暂停，Command(resume=...) 恢复
扩展方式 middleware 钩住 Agent、模型、工具生命周期 节点、边、路由函数、Command、Send、子图
更适合 标准工具调用 Agent、快速原型 长流程、多阶段审批、确定性与 Agent 混排、多 Agent

高层套件与图板对比：LangChain 左侧提供预构建组件，LangGraph 右侧由开发者亲手搭建节点与连线

注意表中「持久化」「人工介入」不是写重复了——这两栏的能力由 LangGraph 运行时提供，但也能从 LangChain 的高层接口使用；差别是封装层级和控制粒度，而不是简单的有或没有。这一点是整道题的题眼，后面几节会逐个展开。

3 「LangChain 只能线性执行」错在哪

这个说法混淆了三个概念：传统 Chain 的用法上限、当前 Agent 的真实结构，以及业务拓扑的表达方式。

第一，传统 Chain 不等于只能顺序执行。 LCEL 除了 RunnableSequence，还有表达并发和条件选择的并行、分支 Runnable；固定「Prompt → 模型 → 解析器」的流水线常常写成线性，是用法选择，不是能力上限。

第二，create_agent 本身就不是一条直线。 模型可能直接结束，也可能请求调用工具；工具执行完又回到模型继续决策——这已经是「条件路由 + 循环」；多个工具调用还可能并行执行。拿一条早期 prompt | model | parser 管道代表当前 LangChain Agent，并不公平。

第三，真正拉开差异的是 LangGraph 把业务拓扑变成了一等公民。 比如一个需求：先做权限校验，三个研究节点并行检索，汇总结果，金额超限转人工，失败走补偿节点，次日任务继续——这时你需要明确看到每个节点、每个状态字段和每条路由条件，而不是藏在一个通用循环背后。

所以更准确的边界是：LangChain 也能表达分支和循环，但高层 Agent API 主要围绕通用的模型与工具循环组织；LangGraph 把整个工作流的拓扑控制权直接交给开发者。

4 Middleware 与图编排：改造机器还是重排产线

「该用 middleware 还是该画图」，关键看你在做哪件事：改造同一台机器，还是重新规划整条生产线。

LangChain 的 middleware 适合改造标准 Agent loop：模型调用前动态生成提示词、裁剪消息、选择模型和工具；模型调用后做安全检查；给工具调用加重试和人工审批。这些逻辑都围绕 Agent、Model、Tool 的生命周期，不需要重画整张图。

middleware 运行在编译图内部：中间件钩住 Agent、模型与工具的生命周期，执行仍由 LangGraph 引擎承担

LangGraph 的节点和边处理的则是更一般的流程结构：一个分类节点把请求送进完全不同的子流程、多个节点并行后汇合、把数据库写入、人工表单、规则引擎和一个完整 Agent 放进同一张图——而且每一步不一定是模型或工具调用，甚至可以完全不用 LLM。

这里有个官方文档特别点明的事实：middleware 不是独立运行时，它运行在 create_agent 返回的编译图内部；而这个 Agent 又可以作为节点或子图放进一个更大的 StateGraph，middleware 会跟着一起工作。也就是说两者是两层组合，不是二选一。看一个最小示例——外部业务图里内嵌一个研究 Agent：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
from typing import Literal

from langchain.agents import AgentState, create_agent
from langgraph.graph import END, START, StateGraph


# route 是外层业务流程的状态字段，不属于标准 Agent loop 的固定字段
class WorkflowState(AgentState):
    route: Literal["research", "reject"]


def classify_request(state: WorkflowState) -> dict:
    # 这里用确定性规则演示路由，实际项目也可以换成分类模型
    text = str(state["messages"][-1].content)
    route = "reject" if "删除生产数据" in text else "research"
    return {"route": route}


def choose_route(state: WorkflowState) -> Literal["research_agent", "reject"]:
    # 条件边根据外层业务状态选择下一个节点
    return "research_agent" if state["route"] == "research" else "reject"


def reject_request(state: WorkflowState) -> dict:
    # 确定性的拒绝节点不需要调用模型
    return {"messages": [{"role": "assistant", "content": "该操作不在允许范围内。"}]}


# create_agent 返回编译后的 LangGraph，可直接作为子图嵌入外层图：
# 内层 continue 享受高层抽象，外层图接管业务拓扑
research_agent = create_agent(
    model=research_model,  # 由项目按实际模型实现
    tools=[search_tool],   # 由项目按实际搜索服务实现
)

builder = StateGraph(WorkflowState)
builder.add_node("classify", classify_request)
builder.add_node("research_agent", research_agent)
builder.add_node("reject", reject_request)
builder.add_edge(START, "classify")
builder.add_conditional_edges("classify", choose_route)
builder.add_edge("research_agent", END)
builder.add_edge("reject", END)

workflow = builder.compile()

这段代码不是在把 LangChain「迁移」成 LangGraph，而是在正确分工：内部研究 Agent 继续享受高层抽象（模型、工具、middleware），外部业务流程获得显式路由（规则拒绝、条件跳转）。真实项目还要补上模型、工具、检查点和异常处理，这里只保留能说明层次关系的部分。

5 State：默认骨架与自由建模

模型调用、工具结果、人工意见和中间产物，不可能只靠函数局部变量一路传下去，所以两者都有「状态」，但使用姿势完全不同。

LangChain 为标准 Agent 准备了 AgentState：默认核心是 messages，用户消息、模型工具调用、工具结果、最终回复都会追加进去；可以用 TypedDict 扩展订单号、当前步骤等额外字段。官方更推荐的做法是让相关 middleware 声明自己需要的状态，避免能力和数据散落各处。

LangGraph 把状态设计本身变成了工作流架构的一部分：可以定义整体 State、区分输入/输出/内部 Schema；节点只返回局部更新，reducer 决定并行或多次更新如何合并。

为什么非要有 reducer？多个研究节点同时写入证据，我们希望的是「追加结果」而不是「后写的覆盖前一份」——合并语义必须在 State 里提前定义好，运行时才知道怎么处理并发写入。这就像几个同事同时往同一本台账里补记录：如果没规定「追加到末尾」，后写的就会把先写的盖掉。

AgentState 与业务 State 建模：内层 Agent 用默认消息状态，外层业务流程自建模字段与更新规则

结论是：LangChain 的 Agent State 就运行在 LangGraph 上，区别在于——LangChain 接受一套为标准 Agent loop 设计好的状态骨架，直接用 LangGraph 则要为整个业务工作流设计数据通道和更新规则。自由度越大，责任越大。

6 持久化与记忆：同一套检查点，谁在控制

面试里最易说错的一句话：「LangChain 管记忆、LangGraph 管持久化」，或者「只有 LangGraph 才能断点恢复」——都是在把上下层拆散。

LangGraph 的持久化有两套机制：Checkpointer 按 thread_id 保存图状态快照，适合线程内的短期记忆、人工介入、时间旅行和故障恢复；Store 保存图状态之外、跨线程可读的业务数据，适合用户偏好、事实和共享知识等长期记忆。

而 LangChain 的 create_agent 会把 checkpointer 和 store 交给底层图——所以 LangChain Agent 同样有短期/长期记忆和恢复能力；用 Agent Server 时，持久化基础设施还可以由服务端处理。真正的差异在控制粒度：谁来决定 checkpointer 何时落盘、恢复时回放到哪里。

Checkpoint 故障恢复示意：状态快照按线程保存，中断数天后仍可从保存点恢复执行

还要提醒一点：durable execution 不只是「把数据存进数据库」。长流程中途失败后从头重跑，发邮件、扣款这类副作用可能重复执行——状态虽然保存了，业务仍可能出事故。可靠恢复要求把非确定性操作和副作用放进可记录的任务边界，并保证可能重试的操作幂等。直接设计 LangGraph 时这些边界更显式；LangChain 标准 Agent 可以借用同一运行时，但复杂业务的副作用仍需认真建模。（Checkpointer 与 Store 的完整机制，见「长短期记忆」那篇。）

7 人工介入与流式输出：控制粒度不同

人工介入的场景是「模型想发送邮件时，先让人确认」。如果审批对象是工具调用，LangChain 的 HumanInTheLoopMiddleware 已经足够：在工具真正执行前暂停，支持批准、修改、拒绝或人工直接回复，底层状态由 LangGraph 持久化，恢复时沿用同一个 thread_id。这像是给 Agent 的大门加了一道安检——所有工具调用都要过闸，但闸口只有一个。

如果人工节点不只是审批工具：理赔流程要展示中间材料让审核员补充字段、营销流程等一周后再继续、多位审核人分别填写意见后按票数路由——这时要用 LangGraph 的 interrupt()，它可以在节点内部的任意业务位置暂停，恢复时再把外部输入送回流程。安检变成全程设卡，每个业务节点都能停下等人。

准确的说法是：LangChain 提供围绕 Agent 工具调用的高层审批体验，LangGraph 提供更通用的中断与恢复原语。前者省事，后者表达范围更广。

流式输出同理。UI 逐字显示只是最表面的一层——用户还想看到「正在搜索」「工具已返回」「等待审批」这类进度，开发者则要观察哪个节点更新了哪些状态、哪个任务失败、何时写入检查点。

  • LangChain Agent 直接用 stream 或 stream_events 输出模型消息、Agent 步骤和工具自定义进度——因为 create_agent 返回编译图，遵循的本来就是 LangGraph 的流式接口；
  • LangGraph 在更低层暴露 values、updates、messages、custom、checkpoints、tasks、debug 等事件类型，还能处理子图命名空间。

用户看到的打字机效果只是仪表盘上的指针，LangGraph 还能把发动机转速、油温和每个气缸的工作状态都给你。

8 部署与调试：共享的 LangSmith

把 LangSmith 当成 LangGraph 的专属控制台也不准确。LangSmith 承担 tracing、evaluation、Studio 和 Deployment，它观察的对象既包括 LangChain Agent，也包括直接编写的 LangGraph 工作流，甚至支持其他框架接入 tracing。

由于 create_agent 本身就是图，LangChain Agent 同样能在 Studio 中查看节点、线程、状态和执行轨迹。直接用 LangGraph 时，业务步骤被拆成更明确的节点，复杂路由走了哪条路径一目了然，还能用 checkpoint 做状态回放和时间旅行调试——但这份可见性来自图的建模粒度，不代表 LangChain 就无法部署或调试。

LangSmith 共享平台：LangChain Agent 与 LangGraph 工作流共用同一套 tracing、Studio 与部署体系

生产部署上，两者都能部署到 LangSmith 的 Agent Server 体系，也可以自行托管。这里要分清两件事：是否用托管平台是部署选择，是否用 LangChain 高层 Agent API 是开发抽象选择——不要混成一个问题。

9 什么时候下沉 LangGraph

需求是「给模型一组工具，循环调用直到完成任务」时，优先 create_agent 更省事——客服问答、数据库查询助手、内部知识助手都属于这一类。提示词动态化、模型切换、工具筛选、上下文摘要、重试、护栏、敏感工具审批，先用 middleware 解决，不值得为此重画一张图。

当主角是业务流程而不是 Agent loop 时，才考虑 LangGraph。典型信号有五个：

  1. 确定性规则与模型决策交替出现（如先校验权限再走 Agent）；
  2. 多条路径并行执行后汇合；
  3. 任务跨小时、跨天暂停与恢复；
  4. 多 Agent 协作；
  5. 必须精确控制失败补偿和人工节点。

还有一条渐进式组合路线：先用 LangChain 做出一个可用的 Agent，拓扑变复杂后，把它作为 LangGraph 的节点或子图——这正是第 4 节代码演示的形态。官方当前推荐「从高层开始，需要时下沉到细粒度控制」。

最后破除一个误区：不要因为 LangGraph 更底层，就默认它更高级、更适合所有项目。控制权越大，要自己设计和测试的状态、路由、恢复与副作用就越多——标准 Agent 用几十个节点重搭一遍，未必比 create_agent 更可靠，反而增加维护成本。LangChain 负责把 Agent 开箱即用，LangGraph 负责让系统按你设计的路线运行，两者各司其职。

10 面试总结

回答这道题，最大的雷是把「能不能分支」「有没有持久化」当成两者的分界线。先避开几个误区：

误区 正解
LangChain 只能线性串步骤，LangGraph 才能分支循环 LCEL 支持并行和分支；create_agent 本身是带条件路由和循环的图；拿旧版 prompt | model | parser 管道代表当前 LangChain Agent 不公平
LangChain 负责开发，LangGraph 负责部署/持久化、流式、人工审批只有 LangGraph 有 create_agent 构建在 LangGraph 之上，检查点、流式、人工审批都能直接使用；真正的差别是封装层级与控制粒度
它们是一套东西，选哪个都差不多 底层运行时可以相同，但抽象层级、控制权和开发成本完全不同
LangGraph 更底层所以更高级，所有项目都应下沉 控制权越大责任越大；标准 Agent 用几十个节点重搭未必更可靠，反而增加维护成本
LangSmith 是 LangGraph 的专属调试台 统一平台：LangChain Agent 同样能在 Studio 里看节点、线程和状态
「用不用托管平台」和「用不用高层 API」是一回事 部署选择与开发抽象选择是两件独立的事

再按「控制粒度」这条主线组织答案（按面试原题《LangChain 和 LangGraph 的核心区别》）：

维度 LangChain v1 LangGraph
官方定位 高层 Agent 开发框架 低层 Agent 编排框架与运行时
默认提供 模型与工具调用循环、middleware 扩展点 状态、节点、边、路由、并行、中断等编排原语
控制流 标准 Agent loop 已搭好，middleware 定制 显式定义顺序、条件路由、循环、并行、子图
状态 AgentState + messages，可扩展字段 完整 State Schema + reducer 合并规则
持久化与记忆 经底层 LangGraph 使用 checkpointer/store 直接控制 thread、状态历史与恢复边界
人工介入 HumanInTheLoopMiddleware 审批工具调用 节点内 interrupt()，任意业务位置暂停
流式输出 模型消息、Agent 步骤、自定义进度 消息之外还有 checkpoint、task、debug 等底层事件
组合方式 当作 LangGraph 的节点或子图复用 外层图给 Agent 编排业务拓扑

追问预案：

  • 「LangChain 和 LangGraph 到底是什么关系？」——上下层关系：create_agent 构建在 LangGraph 之上并返回编译图，LangChain Agent 继承其状态、持久化、流式与恢复能力；LangGraph 可选用但不必需 LangChain 组件。
  • 「LangChain Agent 能分支和循环吗？」——能。LCEL 有并行和分支 Runnable；create_agent 本身就是「条件路由 + 循环」，多个工具调用还会并行执行。
  • 「持久化和记忆到底谁提供？」——运行时（LangGraph）提供 Checkpointer 与 Store；LangChain 高层接口同样能用，差异在控制粒度：谁决定落盘时机、恢复点和状态历史的管理。
  • 「什么时候该下沉 LangGraph？」——五大信号：规则与模型决策交替、多路径并行汇合、跨小时/跨天暂停恢复、多 Agent 协作、必须精确控制失败补偿与人工节点；能用 middleware 解决的先用 middleware。
  • 「两个框架能同时用吗？」——能，且这是官方推荐的渐进式组合：先用 LangChain 构建 Agent，再作为 LangGraph 的节点或子图嵌入外层业务图，middleware 跟着一起工作。

参考

本文图片均来源于公众号「小林面试笔记」，版权归原作者所有。

追逐繁星 > LangChain
#AI #大模型 #LLM #LangChain
「LangChain」LangChain 和 LangGraph 的核心区别？
https://marisamagic.github.io/2026/08/26/20260826_LangChain与LangGraph区别/
作者
MarisaMagic
发布于
2026年8月26日
许可协议