LangChain vs LangGraph2025 Agent 框架选型全景指南组件抽象 vs 流程编排TL;DR场景选型时同时遇到 LangChain 和 LangGraph搞不清谁替代谁、什么时候该用哪个、复杂 Agent 该怎么组合。结论LangChain 是 LLM 应用开发框架组件层模型/Prompt/工具/Retriever/MiddlewareLangGraph 是 Agent Runtime流程层State/Node/Edge/Checkpoint/Interrupt生产级 Agent 通常需要二者组合。产出七维差异表 RAG / Tool Calling / 多 Agent 选型策略 18 节工程实践建议 生产级组合架构图。版本矩阵功能状态说明LangChain v1.0create_agentAPI✅ 已验证2025-10 发布统一 Agent 构建入口model / tools / system_promptLangChain Middleware 系统✅ 已验证内置 Summarization / Human-in-the-loop / Model call limit 等中间件LangChain v1.0 Pydantic v2 State✅ 已验证状态层基于 Pydantic v2与 LangGraph 共享 State 语义LangGraph v1.0 Durable Execution✅ 已验证langgraph1.0.2checkpoint 持久化 断点续传LangGraph Human-in-the-loop✅ 已验证interrupt()API 支持暂停等外部输入后继续LangGraph Checkpoint 多后端✅ 已验证InMemorySaver / SQLite / PostgresSaver 可插拔AgentExecutor 官方标记遗留✅ 已验证官方文档推荐新 Agent 使用 LangGraph 构建Multi-Agent Subgraph✅ 已验证子流程可封装为 subgraph 表达多 Agent 协作LangSmith 调试追踪✅ 已验证与 LangGraph 可视化调试 监控无缝集成摘要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如果你只是想快速做一个能调用工具的 AgentLangChain 会更快。如果你要做一个可控、可恢复、可观测、能插入人工审核、能处理复杂分支的生产级 Agent 系统LangGraph 更合适。2. LangChain 是什么LangChain 最早被大量开发者认识是因为它提供了一套比较完整的大模型应用开发抽象。在没有这些封装之前开发一个 LLM 应用通常要自己处理很多胶水代码调用不同模型厂商 API。管理 Prompt 模板。组织多轮对话上下文。接入外部工具。接入向量数据库。实现 RAG 检索增强生成。解析模型输出。构建 Agent 循环。LangChain 把这些能力封装成统一组件让开发者可以更快组合应用。例如官方 v1 文档里的风格是fromlangchain.agentsimportcreate_agentdefget_weather(city:str)-str:returnfIts always sunny in{city}!agentcreate_agent(modelanthropic:claude-sonnet-4-5,tools[get_weather],system_promptYou 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 continueLangGraph 的模式更像用户输入 ↓ 意图识别节点 ↓ 条件判断 ├── 普通问答 → 直接回答节点 ├── 知识库问题 → 检索节点 → 回答节点 ├── 工单问题 → 创建工单节点 → 人工审核节点 └── 高风险操作 → 人工确认节点 → 执行节点 ↓ 结束每个节点是明确函数每条边是明确流转关系状态在节点之间传递。手绘信息图LangGraph 强在哪中心四要素 State蓝色/ Node绿色齿轮/ Edge黄色箭头/ Bot粉色机器人相互连接左侧 Checkpoint带软盘的剪贴板支持状态回溯与错误恢复与 Interrupt带暂停按钮的虚线框代表 Human-in-the-loop作为扩展能力右下角 CSDN 武子康 署名。6. LangGraph 的核心价值可靠执行过程LangGraph 的核心不是让模型更聪明而是让执行过程更可靠。复杂 Agent 系统里模型只是其中一个组件。生产系统真正难的是状态怎么保存节点怎么重试失败怎么恢复工具调用怎么记录人工审批怎么插入流程分支怎么表达多轮任务怎么延续一个简化 LangGraph 代码大概是fromtypingimportTypedDictfromlanggraph.graphimportStateGraph,START,ENDclassAgentState(TypedDict):question:strroute:stranswer:strdefclassify_node(state:AgentState):if审批instate[question]:return{route:approval}return{route:normal}defnormal_answer_node(state:AgentState):return{answer:这是普通问题回答}defapproval_node(state:AgentState):return{answer:这个问题需要审批}defroute_decision(state:AgentState):returnstate[route]builderStateGraph(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)graphbuilder.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 RuntimeLangChain 让你快速搭应用模型调用封装。工具封装。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_log14. 多 Agent 怎么选多 Agent 不等于先进。很多项目一上来设计Planner Agent Research Agent Coder Agent Reviewer Agent Executor Agent看起来很高级但真正的问题是谁负责调度状态怎么共享任务怎么拆分结果怎么合并冲突怎么处理失败怎么恢复如果这些问题没有解决多 Agent 只是多个黑盒互相甩锅。LangGraph 的图结构适合表达多 Agent 协作。你可以把不同 Agent 当成节点也可以把子流程封装成 subgraph。15. 选型判断表需求推荐快速做 DemoLangChain普通聊天机器人LangChain简单 RAGLangChain简单工具调用 AgentLangChain复杂 RAG 流程LangGraph多步骤业务流程LangGraph有人工审批LangGraph长任务执行LangGraph失败后恢复LangGraph多 Agent 协作LangGraph生产级自动化 AgentLangGraph需要组件生态LangChain LangGraph需要流程编排LangGraph需要快速接模型和工具LangChain最常见的真实答案是早期用 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 负责任务编排 业务代码负责规则边界 基础设施负责稳定运行前者解决能不能跑起来。后者解决能不能可靠地跑下去。错误速查卡症状根因定位修复Agent 第 N 步报错无法从第 M 步重试早期AgentExecutor是 while 循环、无结构化状态检查是否仍使用AgentExecutor迁移到 LangGraph用checkpointthread_id断点续传关键操作退款/删除数据无人审批高层 Agent 封装未暴露 hook 点检查节点是否有interrupt机制用 LangGraphinterrupt()在高风险节点前插入人工审核工具调用有副作用重跑导致重复创建工单/邮件工具未做幂等流程无 checkpoint检查是否有幂等 key、checkpoint 配置工具接入幂等 key LangGraph Checkpoint 持久化中间状态难追踪、状态散落在 message history状态全塞进消息列表无 schema检查状态存储位置用 LangGraphTypedDict State 显式 channel 分层流程分支被模型自由判断、不可控业务规则写进 Prompt 而不是图结构检查是否有显式路由节点把规则写进 LangGraphadd_conditional_edges复杂 RAG 多轮检索链路混乱把 RAG 写成单 chain检查图结构是否包含多分支用 LangGraph 节点化 RAG 流程 跨节点状态共享多 Agent 互相甩锅、调度不清没有显式 planner / 状态层检查是否只有一个 while 循环用 LangGraph 把 Agent 当节点子流程封装 subgraph高风险工具调用无人值守工具调用路径未分层检查是否直接model → tool增加validate_actionrisk_checkhuman_approval节点生产环境 Agent 服务重启就丢状态使用InMemorySaver内存 checkpoint检查 Checkpointer 类型切换PostgresSaver/SQLiteSaver持久化存储调试时无法定位 Agent 走到哪一步、状态怎么变未接入 LangSmith 等 tracing检查是否有 span trace接入 LangSmith记录每节点 input/output/state diff作者武子康的个人博客
