目标读者：有 Python/AI 基础、正在或即将构建 LLM 应用的中级开发者 |预计阅读时间：10 分钟 |字数：约 2800 字
开篇：从"调一次 API"到"多步 Agent"，越做越乱
很多人接触 LLM 应用开发，路径都差不多：先用 OpenAI SDK 调一次聊天接口，觉得不过瘾，加上检索做 RAG，再加工具调用做 Agent。单轮还好，一旦要"多步骤、能循环、多 Agent 协作"，代码就开始拧巴——状态散在变量里，循环靠 while True，分支靠 if else，人工审核插不进去，跑挂了没法恢复。
这时候你会搜到两个名字：LangChain 和 LangGraph。文档都挺长，概念都不少，最让人困惑的是——它俩到底什么关系？是替代？是互补？我该学哪个？
这篇就讲清四件事：两者各自是什么、什么关系、差异在哪、你的场景该选哪个。读完能直接动手。
💡 全文导览
- LangChain：把组件串成链
- LangGraph：把流程画成图
- 它俩什么关系
- 正面对比
- 怎么选：一张决策表
一、LangChain：把组件串成链
LangChain 是构建 LLM 应用的开源框架（Python / JS 双版本），核心做两件事：一是提供一套标准接口把 LLM、提示词、检索器、工具、输出解析等组件统一起来；二是攒起一个庞大组件生态，向量库、文档加载器、各种模型适配器开箱即用。
它的核心抽象是"链"——把组件像水管一样一段段接起来。最典型的写法是LCEL（LangChain Expression Language），用管道符|把 Runnable 串起来：
# LangChain LCEL 最小示例：一个带检索的问答链from langchain_core.prompts import ChatPromptTemplatefrom langchain_openai import ChatOpenAIfrom langchain_core.output_parsers import StrOutputParser# 1. 提示词模板：把检索到的上下文和问题拼进 promptprompt = ChatPromptTemplate.from_template( "根据以下资料回答问题。\n资料：{context}\n问题：{question}")# 2. 模型model = ChatOpenAI(model="gpt-4o-mini")# 3. 输出解析器：把模型消息转成纯字符串parser = StrOutputParser()# 用 | 串成链：prompt -> model -> parserchain = prompt | model | parser# 调用：统一同步/异步/批量/流式接口answer = chain.invoke({"context": "LangGraph 用图编排 Agent", "question": "LangGraph 是什么？"})print(answer)这段代码体现了 LangChain 的哲学：线性、声明式、组件可替换。换模型只改一行，加解析器接一段管道。除了 LCEL，LangChain 还有 Retriever（RAG 的核心，从向量库取相关文档）、Tool / ToolCalling（让 LLM 调外部函数）、Agent（LLM 自主决定调哪个工具、循环执行直到完成）等抽象。
什么时候用 LangChain？
- 单轮问答 / 线性 RAG：检索→生成一条链走完，没有分支循环，LCEL 最舒服。
- 快速原型 / 组件拼装：要接十几种向量库试效果，LangChain 生态最省事。
- 结构化输出 / 文档处理：把 LLM 输出强类型成 Pydantic，或加载切分一批文档。
边界：一旦你的 Agent 需要"根据上一步结果决定走哪条路、可能循环重试、多个 Agent 共享状态"，链式抽象就开始别扭——这正是 LangGraph 要解决的。
⚠️ 边界提示：链式抽象适合"一条道走到黑"的流程。一旦出现分支、循环、多 Agent 共享状态，就该换 LangGraph 了。
二、LangGraph：把流程画成图
LangGraph 由 LangChain 团队出品，定位是构建有状态、多步骤、可循环的 LLM 应用（尤其多 Agent 系统）的编排框架。关键转变是：把应用抽象成有向图，而不是链。
核心抽象有这么几个：
| 抽象 | 作用 |
|---|---|
| StateGraph | 以一个共享State（TypedDict 或 dataclass）为中心的图。所有节点读写同一个状态 |
| Node（节点） | 每个节点是一个函数，接收 state、返回 state 的更新 |
| Edge（边） | 节点间的跳转。条件边根据当前 state 动态决定下一个节点——分支与循环的关键 |
| Reducer | 定义 state 字段如何被多个节点合并（覆盖 / 追加 / 求和），避免状态被无脑覆盖 |
| Checkpoint | 每步保存 state 快照，支持中断恢复、时间旅行（回放历史状态） |
| Human-in-the-loop | 图执行中可暂停等待人工审批或输入，再继续 |
一段最小代码感受下：
# LangGraph StateGraph 最小示例：一个带条件分支的 Agent# 以下示意结构，省略了真实 LLM/工具调用from typing import TypedDict, Annotatedfrom operator import addfrom langgraph.graph import StateGraph, START, END# 1. 定义共享状态：messages 用追加 reducer（列表拼接），step 用覆盖class State(TypedDict): messages: Annotated[list, add] # reducer=operator.add，多步消息累加而非覆盖 step: int# 2. 节点：模型生成一步def call_model(state: State) -> dict: # ...调用 LLM，返回对状态的更新... return {"messages": ["模型回复"], "step": state["step"] + 1}# 3. 条件边：根据状态决定下一步def should_continue(state: State) -> str: if state["step"] >= 3: return"end" # 步数够了，结束 return"tools" # 否则继续调工具# 4. 组装图graph = StateGraph(State)graph.add_node("agent", call_model)graph.add_node("tools", lambda s: {"messages": ["工具结果"]})graph.add_edge(START, "agent")graph.add_conditional_edges("agent", should_continue, {"tools": "tools", "end": END})graph.add_edge("tools", "agent") # 工具结果回灌 agent，形成循环app = graph.compile()# 运行：状态在节点间流转，条件边控制走向result = app.invoke({"messages": ["用户问题"], "step": 0})注意tools -> agent这条边形成了显式的循环，而循环走向由should_continue这个条件边决定。在 LangChain 的链里表达这种"调完工具再回模型、达到条件才停"得靠 AgentExecutor 的隐式循环，难观测也难插手；在 LangGraph 里，循环、分支、状态都是图上看得见的东西。
💡 关键对比
- 链式（LangChain）：循环藏在 AgentExecutor 内部，隐式、难插手
- 图式（LangGraph）：循环是显式边，每步可断点、可回放、可观测
什么时候用 LangGraph？
- 多 Agent 协作：supervisor 分派任务、多个 Agent 讨论汇总，需要共享状态和条件跳转。
- 循环重试 / 条件分支的复杂 Agent：生成→校验→不通过就改→再校验，直到达标。
- 人工审核节点 / 断点续跑：流程跑到某步暂停等人确认，或长任务挂了从 Checkpoint 恢复。
边界：如果流程是线性的、没有循环分支、状态也不复杂，上 LangGraph 是给自己加学习成本——直接用 LangChain LCEL 就够。
⚠️ 边界提示：流程线性、无循环分支、状态简单 → 直接用 LangChain LCEL，别上 LangGraph 给自己加学习成本。
三、它俩什么关系
理清三点就够了：
- 同源：都由 LangChain 团队（LangChain AI）维护。LangGraph 是 LangChain 生态在"Agent 编排"方向的延伸与升级，不是另一个团队另起炉灶。
- 解决痛点：早期 LangChain 的
AgentExecutor用链式抽象处理 Agent，难以表达循环、分支、多 Agent 状态共享与人工介入。LangGraph 用"图"把这些显式建模出来，可控性和可调试性大幅提升。自 2024 年起，官方把 LangGraph 定为构建"超过单次 LLM 调用"应用的首选；LangChain v1.0（2025）只保留一个建在 LangGraph 之上的 agent 抽象，复杂 Agent 全面迁移到 LangGraph。 - 可独立、可混用：LangGraph 不强依赖 LangChain 的链，可以只用它的节点/状态机制。但实践中最常见的是混用——节点内部用 LangChain 的组件（prompt、model、retriever、tool）做单步逻辑，外层用 LangGraph 编排整张图。
图1｜LangChain 组件装进 LangGraph 节点，由 StateGraph 统一编排
一句话：LangChain 给你零件，LangGraph 给你图纸。零件可以单独用，图纸也可以装别的零件，但搭配起来最顺。
💡 一句话记忆：LangChain = 零件库，LangGraph = 图纸。混用最顺。
四、正面对比
| 维度 | LangChain（LCEL/链） | LangGraph（图） |
|---|---|---|
| 抽象模型 | 链（线性 Runnable 管道） | 有向图（节点+边+共享状态） |
| 状态管理 | 弱，靠 Memory / 外部 | 强，显式 State + Reducer + Checkpoint |
| 循环 / 多步 | AgentExecutor 可循环但难控 | 条件边原生支持循环，可控 |
| 分支 | 不直观 | 条件边天然支持 |
| 可控性 / 可调试 | 中等 | 高，每步可观测、可中断、可回放 |
| 持久化 / 恢复 | 需自己实现 | Checkpoint 内置 |
| 人工介入 | 难 | 内置 human-in-the-loop |
| 学习曲线 | 平缓 | 较陡 |
| 适用复杂度 | 简单 ~ 中等 | 中等 ~ 复杂 |
图2｜链式（线性）vs 图式（条件边 + 循环）
最该记住的三条差异：
- 状态管理：链里状态是"流过去就没了"，要跨步共享得塞进 Memory 或外部存储；图里 State 是一等公民，所有节点读写同一个状态，Reducer 定义怎么合并。
- 循环可控性：链的循环藏在 AgentExecutor 内部，想插个审核、改个走向很费劲；图的循环是显式边，每步可断点、可回放。
- 调试可观测性：图有 Checkpoint 快照和时间旅行，跑挂了能回放历史状态定位问题；链得自己加日志。
五、怎么选：一张决策表
| 场景 | 推荐 | 理由 |
|---|---|---|
| 单轮问答 / 线性 RAG | LangChain | 一条链走完，无分支循环 |
| 固定步骤的链式处理 | LangChain | 步骤已知，LCEL 声明式最简洁 |
| 快速原型 / 组件拼装 | LangChain | 生态最全，换组件成本低 |
| 多 Agent 协作 | LangGraph | 需共享状态 + 条件分派 |
| 循环重试 / 条件分支 Agent | LangGraph | 条件边原生支持，循环可控 |
| 人工审核节点 / 断点续跑 | LangGraph | 内置 human-in-the-loop + Checkpoint |
| 强可观测 / 可控流程 | LangGraph | 每步可中断、可回放 |
| 长任务需要状态回放 | LangGraph | Checkpoint 时间旅行 |
图3｜选型决策树
决策依据一句话：是否需要"循环 + 共享状态 + 多步骤可控"？需要 → LangGraph；不需要、线性即可 → LangChain。
混用建议：最常见也最推荐的模式是"节点内 LangChain，外层 LangGraph"。用 LangChain 的 prompt/model/retriever/tool 写单步逻辑，用 LangGraph 的 StateGraph 编排整体。这样既享受 LangChain 的生态，又拿到 LangGraph 的可控性。
两个常见误区：
⚠️ 避坑
- “LangGraph 要替代 LangChain”——不是。简单链/RAG 官方仍推荐 LangChain，LangGraph 只在复杂 Agent 层接棒。
- “用了 LangChain 就不能用 LangGraph”——恰恰相反，两者混用才是官方推荐的实践。
收尾
一句话总结：线性用链，复杂用图，混用最常见。LangChain 给你组件和链式拼装的能力，LangGraph 给你图式编排的可控性；前者解决"把零件接起来"，后者解决"把流程管起来"。
动手建议：如果你手头是 RAG 或单轮问答，先用 LangChain LCEL 写个 20 行的链跑通；如果你在做多 Agent 或带审核的复杂流程，用 LangGraph 画一张三节点的小图，感受下条件边和 Checkpoint。从最小 demo 起步，比读十遍文档管用。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～