如果你最近在接触大模型应用开发大概率听过这两个名字LangChain和LangGraph。它们经常被一起提及但很多开发者尤其是刚入门的同学会感到困惑它们到底是什么关系是同一个框架吗是升级版吗还是完全不同的东西更关键的是当你准备为自己的项目选择技术栈时这个困惑会直接影响你的决策我到底该学哪个用哪个还是两个都用这篇文章不会给你一个模糊的“都重要”的答案。我会直接给出一个清晰的判断LangChain 是一个用于构建大模型应用的“工具箱”和“脚手架”而 LangGraph 是 LangChain 这个工具箱里专门用来构建复杂、有状态、多步骤工作流的“高级引擎”。你可以只用 LangChain但当你需要处理像智能客服、数据分析Agent、自动化审批流这类需要“记忆”和“决策循环”的场景时LangGraph 就是那个不可或缺的核心部件。接下来我将用最直白的语言和动画讲解的思路带你彻底理清它们的关系、区别和各自的适用场景。无论你是零基础还是已经用过 LangChain 但对 LangGraph 感到陌生这篇文章都能让你在 5 分钟内建立起清晰的认知并知道下一步该怎么做。1. 核心关系从“积木”到“自动化流水线”理解它们关系的最好方式是类比一个汽车制造厂。LangChain 就像是整个工厂的“标准化零件库”和“基础组装车间”。它提供了生产一辆车所需的所有标准件发动机LLM调用、轮胎向量数据库连接器、方向盘提示词模板、螺丝刀工具调用等等。它还提供了把这些零件初步组装成模块如车门、座椅的流水线Chains。你可以用 LangChain 快速造出一辆能跑的“原型车”。LangGraph 则是工厂里那条最核心的“智能总装流水线”。这条流水线决定了生产的流程和逻辑先装底盘再装发动机然后根据发动机型号决定安装哪种排气系统接着进行质检如果质检不合格则返回上一步重修。它是一个有向图定义了不同工序节点之间的流转规则边并且整个流水线是有“记忆”的——它知道当前车架处在哪个工位之前做过哪些处理。所以关系一目了然从属关系LangGraph 是 LangChain 项目的一部分是 LangChain 框架下的一个子库langchain-graph。你可以通过pip install langgraph来安装它。功能关系LangChain 解决“用什么”和“怎么简单连接”的问题LangGraph 解决“如何复杂、智能地控制流程”的问题。演进关系你可以从 LangChain 的简单链Chain开始当业务逻辑变得复杂、需要循环、分支或持久化状态时很自然地演进到使用 LangGraph。下面这张图清晰地展示了它们在整个大模型应用开发生态中的位置和关系[大模型应用] | |--- 核心编排与流程控制 (由 LangGraph 主导) | | | |--- 复杂工作流 (多步骤、有状态、循环) | |--- Agent 运行时 (推理、执行、循环) | |--- 长期运行进程 | |--- 基础组件与集成 (由 LangChain 提供) | |--- 模型调用 (LLM, ChatModel) |--- 提示词工程 (PromptTemplate) |--- 记忆 (Memory) |--- 检索 (Retrievers) |--- 工具 (Tools) |--- 简单链 (Chains)一句话总结LangChain 为你准备了所有建筑材料砖瓦、钢筋和简单砌墙方法而 LangGraph 给了你一张可以设计摩天大楼的自动化施工蓝图和指挥系统。2. LangChain 详解你的大模型应用“瑞士军刀”在深入 LangGraph 之前我们必须先扎实理解 LangChain 到底做了什么。它远不止是一个调用 OpenAI API 的封装。2.1 核心价值标准化与集成没有 LangChain 之前开发一个大模型应用可能是这样的# 伪代码原始、繁琐的方式 import openai from some_vector_db_lib import connect import json # 1. 自己拼接提示词 prompt f请回答以下问题{user_question}\n 参考上下文{context} # 2. 手动处理 API 调用和错误 response openai.ChatCompletion.create(modelgpt-4, messages[{role:user, content:prompt}]) # 3. 自己解析结果 answer response.choices[0].message.content # 4. 如果需要记忆自己管理对话历史列表 history.append({user: user_question, assistant: answer}) # 5. 如果需要检索自己写连接向量数据库、embedding、查询的代码 # ... 非常冗杂LangChain 的出现将这些通用模式抽象成了可复用的组件# 使用 LangChain 的方式 from langchain_openai import ChatOpenAI from langchain.chains import RetrievalQA from langchain.prompts import PromptTemplate from langchain_community.vectorstores import Chroma # 1. 模型变成标准化组件 llm ChatOpenAI(modelgpt-4) # 2. 提示词变成可复用的模板 prompt PromptTemplate.from_template(基于上下文{context}\n回答{question}) # 3. 检索器也是标准化组件 retriever vectorstore.as_retriever() # 4. 用 Chain 把一切连起来一行代码完成复杂流水线 qa_chain RetrievalQA.from_chain_type(llmllm, retrieverretriever, promptprompt) # 5. 执行 result qa_chain.invoke({query: user_question})它的核心价值在于“降本增效”降低了构建常见LLM应用模式如检索增强生成RAG、对话机器人、摘要等的成本提高了开发效率。2.2 关键组件拆解LangChain 主要提供六大模块你可以像搭积木一样使用它们Models (模型)统一接口调用各种 LLMOpenAI, Anthropic, 本地模型等。Prompts (提示词)管理、优化和复用提示词模板。Indexes (索引/检索)简化文档加载、文本分割、向量化存储和检索流程。这是实现 RAG 的基石。Memory (记忆)管理对话或交互的历史状态包括简单的缓冲区、摘要记忆等。Chains (链)将多个组件模型、提示词、工具等按预定顺序组合起来执行一个任务。这是 LangChain 早期核心的编排方式。Agents (代理)引入“推理”能力让 LLM 能够自主决定何时、如何使用哪些工具如搜索、计算、查数据库来完成任务。2.3 经典模式Chain 的局限性Chain 是线性的、预定义的。想象一个LLMChain输入 - 提示词模板 - LLM - 输出。或者一个SequentialChain步骤A - 步骤B - 步骤C。这种模式在遇到需要“循环”或“动态路由”的场景时就力不从心了。例如你想构建一个数据分析 Agent用户问“分析一下我们上周的销售数据。”Agent 需要决定先调用“查询数据库”工具获取数据。拿到数据后它要判断数据是否完整是否需要先调用“数据清洗”工具清洗后再决定是调用“生成图表”工具还是直接让 LLM “总结洞察”在总结过程中LLM 可能发现某个指标异常需要再次调用查询工具获取更细粒度的数据。这个过程充满了“判断 - 执行 - 再判断”的循环。用简单的SequentialChain很难优雅地实现代码会变得复杂且难以维护。而这正是LangGraph要解决的核心问题。3. LangGraph 详解为复杂思维过程建模如果说 Chain 是“流水线”那么 Graph 就是“流程图”或“状态机”。LangGraph 引入了“图计算”的思想来编排工作流。3.1 核心概念图、节点、边与状态图代表整个工作流。节点图中的一个步骤或一个功能单元。它可以是一个 LLM 调用、一个工具调用或者任何自定义函数。边连接节点的箭头定义了工作流的走向。边可以是有条件的根据当前“状态”决定下一步走哪条路。状态这是 LangGraph 的灵魂。它是一个共享的、在节点间传递的数据结构。每个节点都可以读取和修改状态。这解决了 Chain 之间传递复杂数据的难题。3.2 工作原理一个简单的动画讲解让我们把上面那个数据分析 Agent 的工作流画出来[开始] | v [理解用户意图] (LLM节点) | v [决策需要什么工具] (路由节点) / \ v v [查询数据库] [直接回答] (工具节点) (LLM节点) | | v v [更新状态 [更新状态 获得数据] 准备回答] | | v v [是否需要清洗] (条件边) / \ v v (是) (否) | | v v [数据清洗] [生成分析] (工具节点) (LLM节点) | | v v [更新状态] [更新状态] | | ---------- | v [结束] (输出节点)动画过程解析初始状态包含用户问题。进入理解用户意图节点LLM 分析问题在状态中标记任务类型: “数据分析”。决策节点查看状态中的任务类型决定走向查询数据库分支。查询数据库工具运行将查询到的原始数据写入状态。流向是否需要清洗这条条件边。这里会运行一个判断函数可以是规则也可以是另一个LLM调用检查状态中的原始数据质量。如果数据脏走“是”分支执行数据清洗节点并将清洗后数据更新到状态。无论是否清洗最终都汇聚到生成分析节点。该节点读取状态中的最终数据调用 LLM 生成报告并将最终答案写入状态。到达结束节点从状态中提取最终答案返回给用户。这个流程的关键是状态贯穿始终路由动态决定。这正是复杂 Agent 和自动化工作流所需要的。3.3 与 LangChain Agent 的对比你可能知道 LangChain 也有Agent和AgentExecutor。它们与 LangGraph 是什么关系LangChain Agent (旧架构)它本质上是一个特殊的 Chain。其内部通过 LLM 的“函数调用”或“ReAct”格式来决定动作AgentExecutor负责循环执行。这个架构在实践中暴露出一些问题状态管理隐式且复杂错误处理困难自定义工作流如强制先执行A再执行B不直观。LangGraph Agent (新架构)LangGraph 重新实现了 Agent 运行时。现在Agent 的每一步思考、行动、观察都明确地定义为图上的节点状态流转清晰可见。LangGraph 已经成为 LangChain 中构建 Agent 的官方推荐方式它更强大、更灵活、也更易调试。4. 实战对比分别用 LangChain Chain 和 LangGraph 实现同一个需求假设我们要实现一个“安全审查助手”用户输入一段代码助手先检查代码安全性如果安全则解释代码如果不安全则拒绝并说明理由。4.1 使用 LangChain 的 SequentialChain 实现传统方式# 文件chain_approach.py from langchain_openai import ChatOpenAI from langchain.prompts import PromptTemplate from langchain.chains import LLMChain, SequentialChain llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # 定义第一个 Chain安全检查 security_prompt PromptTemplate( input_variables[code], template请严格检查以下代码是否存在安全风险如SQL注入、命令注入、路径遍历等。只回答安全或不安全并简要说明原因。\n代码{code} ) security_chain LLMChain(llmllm, promptsecurity_prompt, output_keysecurity_check) # 定义第二个 Chain代码解释 explain_prompt PromptTemplate( input_variables[code], template请解释以下代码的功能和工作原理\n{code} ) explain_chain LLMChain(llmllm, promptexplain_prompt, output_keyexplanation) # 定义第三个 Chain拒绝解释 reject_prompt PromptTemplate( input_variables[code, security_reason], template对于以下代码{code}\n由于安全原因{security_reason}我无法提供解释。 ) reject_chain LLMChain(llmllm, promptreject_prompt, output_keyrejection) # 尝试组合成 SequentialChain - 这里会遇到问题 # 因为我们需要根据第一个chain的输出动态选择执行第二个还是第三个chain。 # SequentialChain 是线性顺序无法实现条件分支。我们只能在外部用if-else逻辑包裹这破坏了链的封装性。 overall_chain SequentialChain( chains[security_chain], # 只能先运行安全检查 input_variables[code], output_variables[security_check], verboseTrue ) # 运行 result overall_chain.invoke({code: user_input input(); os.system(user_input)}) print(安全检查结果:, result[security_check]) # 然后在外部根据结果手动判断 if 安全 in result[security_check]: # 手动调用解释链 explain_result explain_chain.invoke({code: result[code]}) print(explain_result[explanation]) else: # 手动调用拒绝链 reject_result reject_chain.invoke({code: result[code], security_reason: result[security_check]}) print(reject_result[rejection])痛点SequentialChain无法处理分支逻辑。业务逻辑被拆分到了 Chain 外部导致流程割裂状态安全检查的原因传递麻烦。4.2 使用 LangGraph 实现现代方式# 文件graph_approach.py from typing import TypedDict, Annotated, Literal from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI from langchain_core.messages import HumanMessage # 1. 定义状态结构明确工作流中需要共享和传递的所有数据 class AgentState(TypedDict): code: str # 用户输入的代码 security_check_result: Annotated[str, 安全检查结果] # 例如安全 或 不安全: 原因... final_response: str # 最终给用户的回复 decision: Literal[explain, reject] # 路由决策 # 2. 初始化模型 llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # 3. 定义各个节点函数 def security_check_node(state: AgentState) - AgentState: 节点1安全检查 prompt f请严格检查以下代码是否存在安全风险如SQL注入、命令注入、路径遍历等。只回答安全或不安全并简要说明原因。\n代码{state[code]} response llm.invoke([HumanMessage(contentprompt)]) result response.content # 更新状态 return {security_check_result: result} def decision_node(state: AgentState) - AgentState: 节点2根据安全检查结果做出路由决策 if 安全 in state[security_check_result]: decision explain else: decision reject # 更新状态 return {decision: decision} def explain_code_node(state: AgentState) - AgentState: 节点3解释代码 prompt f请解释以下代码的功能和工作原理\n{state[code]} response llm.invoke([HumanMessage(contentprompt)]) # 更新状态 return {final_response: response.content} def reject_code_node(state: AgentState) - AgentState: 节点4拒绝并说明原因 reason state[security_check_result] response f对于您提供的代码由于安全原因{reason}我无法提供详细解释。 # 更新状态 return {final_response: response} # 4. 构建图 workflow StateGraph(AgentState) # 添加节点 workflow.add_node(security_check, security_check_node) workflow.add_node(make_decision, decision_node) workflow.add_node(explain, explain_code_node) workflow.add_node(reject, reject_code_node) # 设置入口点 workflow.set_entry_point(security_check) # 添加边定义节点间的流转 workflow.add_edge(security_check, make_decision) # 检查完就做决策 # 条件边根据决策结果路由到不同节点 workflow.add_conditional_edges( make_decision, # 这是一个路由函数根据 state[decision] 的值返回下一个节点名 lambda state: state[decision], { explain: explain, # 如果 decision 是 explain去 explain 节点 reject: reject, # 如果 decision 是 reject去 reject 节点 } ) # 设置终点解释或拒绝节点完成后都结束 workflow.add_edge(explain, END) workflow.add_edge(reject, END) # 编译图 app workflow.compile() # 5. 执行图 inputs {code: user_input input(); os.system(user_input)} # 一段不安全的代码 final_state app.invoke(inputs) print(最终回复:, final_state[final_response]) print(\n--- 完整状态追踪 ---) # LangGraph 内置了可视化工具这里打印关键步骤 for step in final_state.get(__intermediate_steps, []): print(f步骤: {step})优势流程内聚整个业务逻辑检查-决策-分支执行被封装在一个Graph对象中是一个完整的可执行单元。状态清晰所有中间数据security_check_result,decision都在明确定义的AgentState中流转一目了然。动态路由add_conditional_edges轻松实现了条件分支这是 Chain 难以做到的。易于扩展如果要增加一个“代码优化”节点只需添加节点并修改路由逻辑即可不影响原有结构。可调试性__intermediate_steps或 LangGraph 的可视化工具可以清晰展示执行路径便于调试。5. 如何选择LangChain vs LangGraph 适用场景指南现在你理解了它们的区别选择标准就非常清晰了特性/需求推荐使用 LangChain推荐使用 LangGraph任务复杂度简单、线性任务如问答、翻译、简单摘要复杂、多步骤、有循环或分支的任务如多轮对话Agent、数据分析流水线、审批流程流程控制预定义的固定流程需要动态决策、条件分支、循环while-loop的流程状态管理简单的输入输出或使用基础的Memory模块管理对话历史需要在多个步骤间共享和修改复杂的结构化数据如当前分析结果、已执行工具列表、用户会话上下文架构偏好快速原型、脚本、简单的微服务需要清晰定义、可维护、可扩展的长期运行服务或复杂应用学习曲线相对平缓易于上手需要理解图、状态等概念曲线更陡峭典型场景- 单次调用的 RAG 系统- 基础的聊天机器人- 文档摘要工具- 格式转换工具-自主智能体能规划、使用工具、从错误中恢复的 Agent-复杂工作流涉及多个 LLM 调用和工具调用且有严格顺序或条件逻辑的业务流程-模拟与游戏需要维持长期状态和环境交互的应用-编排层作为多个 LangChain Chain 的顶层调度器决策流程图开始 | v 我的任务是否需要“判断-执行-再判断”的循环 ---是--- 选择 LangGraph | 否 | v 我的任务流程是否简单、线性、无分支 ---是--- 选择 LangChain Chain | 否 | v 我需要清晰管理多个步骤间的复杂数据吗 ---是--- 选择 LangGraph | 否 | v 我追求极致的开发速度和简单性 ---是--- 选择 LangChain Chain | 否 | v 我构建的是长期运行、需要高可维护性的服务 ---是--- 选择 LangGraph给你的建议初学者从 LangChain 开始。先掌握Models,Prompts,Chains和RAG的基本用法用它完成几个小项目如个人知识库问答。这能帮你建立对大模型应用开发的基本感知。进阶开发者当你发现你的 Chain 变得臃肿里面塞满了if-else来处理不同情况或者你需要实现一个能自主使用工具的 Agent 时就是学习 LangGraph 的最佳时机。用它来重构你的复杂流程你会获得更清晰、更强大的控制能力。生产环境对于关键业务逻辑尤其是涉及复杂决策和状态管理的部分强烈建议使用 LangGraph 来构建。它的显式状态和图形化结构支持导出为PNG可视化极大地提升了代码的可读性、可测试性和可维护性。6. 常见问题与排查思路在实际使用中你可能会遇到以下问题问题现象可能原因排查方式解决方案LangGraph 报错状态字段未定义在节点函数中访问了AgentState中未声明的字段。检查TypedDict的定义和节点函数中state字典的键。确保所有在节点间传递的数据都在AgentState类中明确定义。使用Annotated添加描述。条件边路由错误路由函数返回的值与add_conditional_edges中映射的键不匹配。打印路由函数的返回值检查是否与预定义的节点名一致。确保路由函数返回Literal类型中定义的值或与映射键完全相同的字符串。图编译或执行速度慢1. 节点函数中有耗时操作如大型文件IO。2. LLM调用未做异步或批处理。使用性能分析工具定位瓶颈节点。1. 优化节点内逻辑。2. 对于LLM调用考虑使用ainvoke异步接口或在节点内进行批处理。无法实现“循环直到条件满足”不熟悉add_conditional_edges和END的用法。回顾动画讲解中“是否需要清洗”的循环逻辑。设计一个“检查条件”的节点和一条指向自身的条件边。当条件满足时路由到END或其他节点不满足时路由回处理节点。这正是 LangGraph 处理循环的核心能力。与 LangChain 现有组件不兼容认为用了 LangGraph 就要重写所有 LangChain 代码。查看 LangGraph 官方文档关于集成 LangChain 组件的部分。LangGraph 节点函数可以完全兼容 LangChain 的Runnable对象如LLMChain,Retriever。你可以直接将现有的 LangChain Chain 作为一个节点嵌入到图中。状态过于庞大影响性能在AgentState中存储了不需要共享的大对象如整个文档内容。审查状态结构区分“共享数据”和“节点局部数据”。遵循最小状态原则。只将需要在节点间传递的数据放入AgentState。节点内部的中间计算结果如果不需共享应作为局部变量。7. 最佳实践与工程建议状态设计最小化AgentState应只包含必要的数据。避免将整个对话历史或大型文档直接塞入状态考虑存储引用或摘要。节点功能单一化每个节点应只做一件事如调用一次LLM、执行一个工具、做一次判断。这有利于测试、复用和调试。善用可视化LangGraph 可以将编译好的图导出为 PNG 或使用get_graph().draw_mermaid()生成 Mermaid 图。在文档中保存这些图表它们是理解复杂工作流的最佳蓝图。错误处理与持久化对于生产环境需要考虑节点的错误处理try-catch和状态的持久化保存到数据库以便工作流可以中断后恢复。与 LangChain 生态结合不要抛弃 LangChain。LangChain 丰富的Tools、Retrievers、Document Loaders是巨大的宝藏。在 LangGraph 节点中调用这些组件是最高效的开发方式。从简单开始不要一开始就设计庞大的图。从一个简单的线性流程开始逐步添加分支和循环。先用 LangGraph 实现一个核心循环再扩展其能力。8. 总结与后续学习方向让我们回到最初的问题LangChain 和 LangGraph 到底是什么关系现在你可以自信地回答它们是“基础生态”与“高级引擎”的互补关系。LangChain 提供了构建大模型应用所需的一切原材料和标准件而 LangGraph 提供了将这些零件组装成能处理复杂、动态任务的智能系统的设计和执行框架。学 LangChain是学习“如何与 LLM 及周边工具交互”。学 LangGraph是学习“如何为 LLM 的思维过程和工作流建模”。对于开发者而言正确的路径是掌握 LangChain 基础理解模型、提示词、索引、链和代理的基本概念。识别复杂度瓶颈当你的链变得难以维护或需要实现动态路由和循环时。引入 LangGraph用它来重新设计和编排你的核心业务逻辑享受清晰的状态管理和强大的流程控制能力。你的下一个实践步骤可以是用 LangChain 构建一个简单的 RAG 系统然后尝试用 LangGraph 为其添加一个“根据答案质量决定是否重新检索或追问用户”的反馈循环。这将让你亲身体会到从“链”到“图”的威力。这篇文章为你理清了概念并提供了可运行的代码示例。真正的掌握始于动手实践。建议收藏本文在遇到具体场景时回来对照指南和示例你将能更快地做出正确的技术选型并构建出更强大、更稳健的大模型应用。