如果你刚开始接触大语言模型应用开发大概率会同时遇到 LangChain 和 LangGraph 这两个名字。它们都带着“Lang”前缀都出现在各种教程和项目里甚至很多文章会把它们混在一起讲。这很容易让人困惑它们到底是一个东西的两个部分还是两个完全不同的工具我应该先学哪个我的项目到底该用哪个这种困惑非常普遍但背后的原因其实很简单LangChain 和 LangGraph 解决的是大模型应用开发中两个不同层级、但又紧密相关的问题。一个帮你“组装”静态的、线性的任务链另一个帮你“编排”动态的、有状态的、可能循环的工作流。理解这个核心区别远比记住一堆 API 调用更重要。今天我们就用最直白的方式帮你理清 LangChain 和 LangGraph 的从属关系、核心区别以及各自的适用场景。无论你是零基础的新手还是已经用过 LangChain 但对 LangGraph 感到好奇的开发者这篇文章都会给你一个清晰的路线图。1. 先搞明白它们各自的“本职工作”组装零件 vs. 设计流水线要理解关系首先要抛开名字看看它们各自被设计出来是干什么的。LangChain 的核心是“链”Chain。你可以把它想象成一个高级的“胶水”或者“组装工具箱”。大模型本身就像一个功能强大但有点“傻”的万能工人它很能干但不知道先干什么后干什么也不知道怎么跟数据库、搜索引擎、计算器这些专业工具配合。LangChain 的作用就是帮你定义好一套固定的工作流程也就是“链”告诉这个工人“你先去数据库查资料Retrieval然后把查到的资料和用户问题一起给我Combining我再根据这些信息生成最终答案Generation。” 这个过程通常是线性的、一步接一步的像一个预设好的剧本。它的重点是把不同的模块模型、工具、记忆、数据源连接成一个可执行的、端到端的应用程序。LangGraph 的核心是“图”Graph。它解决的是一个更复杂的问题当你的工作流程不是一条直线而是一个需要根据中间结果动态决定下一步怎么走的网络时该怎么办比如一个客服机器人需要根据用户情绪决定是安抚还是转接一个数据分析任务需要循环执行“查询-判断-再查询”直到满足条件一个游戏NPC需要根据对话历史和当前状态选择不同的行为分支。LangGraph 允许你定义多个“节点”Node每个节点执行特定任务比如调用模型、运行工具、更新状态然后用“边”Edge来定义节点之间的流转规则。最关键的是流转规则可以基于上一个节点的执行结果来动态决定这就形成了“有状态”的、可能包含循环或条件分支的工作流。它更像是在设计一个智能流水线或一个决策流程图。所以最形象的比喻是LangChain 帮你把螺丝刀、扳手、电钻各种工具组装成一个好用的“多功能螺丝刀”一个链而 LangGraph 则帮你设计一整条汽车装配流水线这条线上有多个工位节点并且能根据上一道工序的结果动态决定下一辆车是送去喷漆还是直接检测有条件的工作流。2. 理清从属关系LangGraph 是 LangChain 生态中的“高级模块”从项目归属上看关系非常明确LangGraph 是 LangChain 项目旗下的一个库。你可以认为 LangChain 是一个“全家桶”里面包含了很多子工具langchain-core: 基础抽象和接口。langchain: 主库包含了大量的链Chains、代理Agents、检索器Retrievers等核心组件。langgraph: 专门用于构建有状态、多参与者的工作流图。还有其他如langchain-community社区贡献集成、langchain-text-splitters文本处理等。因此在安装时你通常会pip install langchain langgraph技术上的从属与互补基础依赖LangGraph 构建在 LangChain 的核心抽象之上。一个 LangGraph 的节点Node其内部完全可以执行一个 LangChain 的链Chain或者调用一个 LangChain 的工具Tool。也就是说LangGraph 用 LangChain 的“零件”来构建更复杂的“机器”。功能演进在 LangGraph 出现之前LangChain 用“代理”Agent来模拟一些简单的动态决策。但代理的复杂逻辑隐藏在内部难以定制和可视化。LangGraph 可以看作是对“代理”模式的一种显式化、模块化和增强化的实现。它把代理内部隐式的决策逻辑变成了外部可清晰定义和调试的图结构。使用场景对于简单的、线性的任务直接用 LangChain 的链就足够了。只有当你需要处理复杂的、有状态的、带循环或分支的逻辑时才需要请出 LangGraph。简单来说LangChain 提供了构建智能应用的基础积木和简单组合方式链而 LangGraph 提供了用这些积木搭建复杂、动态系统的蓝图和引擎图。3. 核心区别对比一张表看清何时该用谁光说概念可能还是有点模糊我们通过一个具体的对比表格从多个维度来看它们的区别特性维度LangChain (链)LangGraph (图)核心抽象链 (Chain)将多个组件按固定顺序连接。图 (Graph)由节点(Node)和边(Edge)组成支持条件流转。工作流状态无状态 (Stateless)每次调用独立不自动保留中间状态需额外配置记忆。有状态 (Stateful)内置状态管理在整个图执行过程中传递和更新上下文。执行流程线性/定向A - B - C像执行一个函数。动态/条件性根据节点结果决定下一步走X、Y还是Z甚至循环回到A。复杂度相对简单适合定义明确、步骤固定的任务。相对复杂适合需要决策、循环、多分支的复杂场景。可视化较难直观展示链的内部步骤。原生支持可视化可以将整个工作流图渲染出来便于理解和调试。典型应用- 问答链检索后生成- 文档总结链- 简单数据提取链- 复杂对话机器人带状态和分支- 多步骤决策系统- 循环执行直到满足条件的数据处理- 模拟仿真如游戏NPC学习曲线较低概念直观易于上手构建简单应用。较高需要理解图、节点、边、状态管理等概念。与代理关系包含“代理”作为实现动态性的一种但较黑盒。可视为“代理”的显式、可定制化实现。甚至可以用 LangGraph 来构建更强大的自定义代理。一个更具体的例子客服对话系统用 LangChain你可以构建一个“检索增强生成RAG链”。用户提问 - 检索知识库 - 生成回答。这个流程每次都是固定的。用 LangGraph你可以构建一个完整的对话流程。用户提问 - 节点A意图识别- 根据意图边决定路由如果是“查询”走到节点BRAG链如果是“投诉”走到节点C安抚并记录工单如果是“闲聊”走到节点D闲聊模式。节点C执行后可能还会根据用户情绪边决定是否循环回节点A继续安抚或走到结束节点。整个对话的历史和状态比如用户是否已生气都在图中被维护和传递。4. 零基础上手路径从链到图一步步来如果你是完全的新手按照以下路径学习可以避免很多困惑第一步先用 LangChain 搞定“单次任务”不要一开始就想着复杂的工作流。你的第一个目标应该是环境搭建安装langchain和你的大模型API包如openai。Hello World学会用ChatModel发起一次最简单的对话。构建第一个链尝试一个经典的LCELLangChain Expression Language链比如prompt | model | output_parser。感受一下如何把提示词、模型调用和输出解析串起来。引入工具尝试让链调用一个简单的工具比如计算器或者网络搜索需要配置API。尝试代理用 LangChain 内置的create_react_agent体验一下代理如何自动选择工具。这时你会初步感受到“动态性”。关键体会在这一步你要理解PromptTemplate、LLM、Tool、Chain这些核心组件是如何通过 LCEL 的管道符 (|) 组合在一起的。这是所有后续工作的基础。第二步当链不够用时认识 LangGraph当你发现你的需求开始出现以下信号时就该考虑 LangGraph 了“如果……那么……”需要根据模型或工具的输出来决定下一步做什么。“重复直到……”需要循环执行某些步骤直到满足某个条件比如解析结果合格。“记住之前……”需要在整个多轮交互中维护一个不断更新的状态比如对话历史、已执行步骤列表、临时变量。“多角色协作”需要模拟多个“参与者”可以是不同的模型实例也可以是工具按照一定规则进行交互。第三步从 LangGraph 的核心概念学起学习 LangGraph不要直接复制复杂例子。从最核心的三个概念入手状态 (State)定义一个字典类型明确你的工作流需要跟踪哪些信息。比如{messages: list, step_count: int, data: dict}。节点 (Node)一个普通的函数它接收当前状态执行一些操作比如调用一个 LangChain 链然后返回一个对状态的更新。这是你放置业务逻辑的地方。def call_model(state: State): # 从state中获取消息 messages state[“messages”] # 调用模型这里可能封装了一个LangChain链 response chat_model.invoke(messages) # 返回更新后的状态部分 return {“messages”: messages [response]}边 (Edge)定义规则决定一个节点执行完后下一个该执行哪个节点。可以是固定的always_go_to_node_b也可以是条件的lambda state: node_b if some_condition else node_c。一个极简的 LangGraph 工作流构建流程如下from langgraph.graph import StateGraph, END # 1. 定义状态类型 class State(TypedDict): messages: list # 2. 创建图构建器 builder StateGraph(State) # 3. 添加节点上面定义的call_model函数 builder.add_node(“model”, call_model) # 4. 设置入口点 builder.set_entry_point(“model”) # 5. 添加边这里简单设置为执行完model后就结束 builder.add_edge(“model”, END) # 6. 编译图得到可执行对象 graph builder.compile()现在你可以像调用函数一样运行这个图final_state graph.invoke({“messages”: [“Hello”]})。第四步实现循环和分支在上面极简图的基础上实现复杂逻辑循环添加一个边从某个节点指回它自己或之前的节点。通常需要配合一个“条件节点”来判断是否继续循环。分支添加多个不同的节点并使用add_conditional_edges方法根据某个节点的输出结果决定下一步走哪条边。5. 项目选型决策指南我到底该用哪个最后我们来回答最实际的问题。面对一个新项目如何选择毫不犹豫选择 LangChain 的情况你的任务流程是线性、确定、无状态的。例如输入文档 - 分割 - 向量化 - 存储这是一条预处理流水线用链清晰明了。你需要快速构建一个RAG 问答系统流程就是“检索 - 生成”。你正在学习大模型应用开发想先理解基础组件模型、提示词、检索器、输出解析器如何协同工作。项目原型期追求最快速度验证核心功能。需要考虑引入 LangGraph 的情况你的应用本质是一个有状态的对话系统需要根据完整对话历史做决策。你需要构建一个复杂的多步骤代理这个代理需要规划、执行工具、检查结果、并可能重新规划。业务流程中天然存在**“是/否”判断、循环审批、条件分支**。例如“生成报告 - 审核是否通过 - (是)发送邮件 / (否)返回修改”。你需要清晰的可视化来向团队或客户解释整个工作流的逻辑。你对工作流的可控性、可调试性要求极高希望每一步的流转都明确定义和可见。一个实用的建议从 LangChain 链开始。当你在用链开发的过程中发现代码里开始出现大量的if...else...来控制流程或者发现需要手动维护一个全局变量来传递状态时这就是一个强烈的信号——你的项目可能更适合用 LangGraph 来重构。此时引入 LangGraph不仅能简化代码还能使你的业务逻辑变得更加清晰和健壮。总结一下 LangChain 是你的基础工具箱和粘合剂用于组装静态功能单元。而 LangGraph 是高级的流程设计器和执行引擎用于编排动态的、智能的业务工作流。它们不是二选一的关系而是相辅相成。在复杂的生产级应用中你很可能同时使用两者用 LangChain 构建链和工具再将它们作为节点组装进 LangGraph 的蓝图中。理解这种层次关系你就能在技术选型和架构设计上做出更明智的决策。