LangChain 与 LangGraph 全面介绍从 AI 编程范式到链式与图式架构前言1. AI 时代下的编程范式1.1 Vibe Coding 的起源与核心变化1.2 Vibe Coding 的局限性1.3 为什么仍然要学习 AI 开发框架1.4 未来更可能是混合式开发2. LLM 驱动应用的框架生态2.1 Python 生态当前最完整的选择2.2 JavaScript、TypeScript 与 Java 生态2.3 C 生态与现代 LLM 系统的分工2.4 如何选择合适的框架3. LangChainLLM 应用开发的核心框架3.1 把原生 LLM 嵌入应用会遇到什么问题3.2 LLM 应用工程如何解决这些痛点3.3 LangChain 的链式思想3.4 LangChain 的标准化模块与能力3.5 LangChain 的起源与发展4. LangGraph面向复杂工作流的图式架构4.1 为什么 LangChain 的线性链不够用4.2 LangGraph 如何解决这些问题4.3 LangGraph 的核心技术特点4.4 LangChain 与 LangGraph 是互补关系4.5 LangGraph 的起源与发展5. LangChain 与 LangGraph 的学习路径5.1 从核心组件到复杂工作流5.2 学习 AI 开发框架的真正价值总结前言大语言模型的出现正在改变开发者与代码、工具和软件系统之间的关系。过去程序员需要逐行描述计算机“怎样做”现在人可以先用自然语言说明“想得到什么”再让模型辅助完成大量实现细节。Vibe Coding、AI 编程助手和低代码工具由此迅速流行也让一个问题变得越来越常见既然 AI 已经能够生成代码开发者还有没有必要系统学习 LangChain、LangGraph 这样的 AI 开发框架答案并不复杂。模型可以快速生成局部代码却不会自动替开发者完成架构设计、数据治理、安全控制、状态管理和长期维护。真正的 LLM 应用也不是“发送一个问题拿回一段回答”这么简单它往往还要连接提示词、外部知识、向量数据库、业务 API、输出解析器、多轮状态和人工审批。模型只是应用的核心引擎之一框架负责把这些分散能力组织成可维护的系统。LangChain 与 LangGraph 正好对应两个重要层次LangChain 侧重标准化组件与链式组合LangGraph 侧重复杂工作流的图式编排和状态管理。本文将从 AI 时代的编程范式出发依次梳理 LLM 应用框架生态、LangChain 的定位与能力、LangGraph 出现的原因与核心特征最后给出一条由浅入深的学习路径。1. AI 时代下的编程范式1.1 Vibe Coding 的起源与核心变化过去十年低代码、无代码平台和 AI 代码助手一直在降低软件开发门槛。到了 2025 年一种被称为Vibe Coding的实践迅速走红它进一步改变了人们对“程序员到底在做什么”的理解。Vibe Coding氛围编程是一种高度依赖人工智能的编程实践开发者使用自然语言描述目标、问题和预期结果由针对代码优化的大语言模型生成软件实现人则通过运行、观察和继续反馈来推动开发过程。这个术语由 Andrej Karpathy 在 2025 年 2 月提出。它强调的并不只是“用 AI 补全几行代码”而是把大量实现细节交给模型。开发者不再始终从函数、循环和语法开始思考而是先表达意图再根据结果调整方向。Vibe Coding 与普通 AI 辅助编程之间仍有区别。普通辅助编程把模型当作更聪明的补全工具开发者仍然理解并控制代码Vibe Coding 则更强调沉浸在 AI 助手提供的开发节奏中甚至可能在没有完全理解每一行代码的情况下接受结果。也正因为如此它更适合快速探索而生产开发仍然离不开审查、测试和理解。这种模式把软件开发从“手动实现驱动”推向“意图驱动”开发者的角色随之发生变化问题定义能力更加重要需求越清晰模型越容易给出可用结果模糊需求只会更快地产生错误实现。指导与审查能力更加重要模型负责生成候选代码开发者负责评估、修改和验证。架构理解更加重要局部代码可以外包给模型但模块边界、数据流和系统演进仍要由人决定。人机沟通能力更加重要提示方式、上下文、约束条件和验收标准直接影响模型输出质量。传统开发关注点Vibe Coding 时代的关注点没有消失的基础能力手动编写实现细节用自然语言描述意图和约束编程原理与调试能力熟悉语法和库函数拆解问题并组织上下文判断代码是否正确逐行控制程序行为审查模型生成的整体结果架构、安全与性能意识人独立完成编码人负责指导AI 负责部分实现测试、验证与责任判断因此Vibe Coding 并没有让开发者变得无关紧要而是把人的价值从重复编码推向问题定义、系统设计和质量控制。1.2 Vibe Coding 的局限性Vibe Coding 能以极低门槛快速生成 Demo、工具和样板代码但“能够运行”与“适合长期使用”之间存在明显差距。它的局限主要集中在代码质量、上下文、知识时效、安全性和可靠性几个方面。首先是代码质量与架构的黑箱问题。模型通常围绕当前提示完成局部目标它能生成一个看起来正确的函数却未必理解整个项目的模块边界、演进计划和团队规范。需求不断叠加后重复逻辑、强耦合和职责混乱会逐渐积累最终形成难以维护的系统。其次是上下文窗口与知识滞后问题。即使模型能够接收很长的上下文也不意味着它始终理解大型项目的全部历史。后期需求可能要求修改早期代码模型却可能遗漏既有约束生成与现有架构冲突的实现。与此同时训练数据存在截止时间模型可能不了解最新语言特性、框架版本和最佳实践还可能“幻觉”出并不存在的 API、函数或参数。再次是安全与可靠性问题。模型没有天然的安全责任意识。如果提示中没有明确约束它可能生成含有 SQL 注入、XSS、硬编码密码或不当权限设置的代码。某段代码也许能在小规模数据下正常运行却可能在高并发、大数据量或边缘输入下失败。没有完善的日志、监控、异常处理和熔断机制时线上排查会变得非常困难。局限典型现象潜在后果架构黑箱只满足当前功能没有统一模块设计代码腐化、重复逻辑、扩展困难上下文有限忘记早期约束或遗漏跨模块关系新代码破坏旧功能知识陈旧使用过时特性或错误版本代码无法运行、维护成本增加模型幻觉编造不存在的 API 和参数错误难以及时发现安全意识不足生成注入漏洞、硬编码密钥、越权逻辑数据泄露和系统风险可靠性不足缺乏边界测试、日志、监控和容错高负载或异常输入下崩溃更准确地说Vibe Coding 不是传统开发的替代品而是一种效率倍增器。它不适合独立承担架构设计、技术方案、安全治理和质量保证却非常擅长生成样板代码、完成重复任务、解释复杂代码、编写测试草稿和提供思路。随着实践深入对 Vibe Coding 的讨论也逐渐从“万能 AI 工具”回到更现实的分工思路。2025 年 8 月Karpathy 进一步强调不应幻想一个工具解决所有编程问题更可行的方式是建立清晰结构让不同工具在各自擅长的场景中接力协作。这与真实生产开发的情况一致变量重命名、测试草稿和小型 Demo 很适合交给 AI架构与核心函数仍需要工程师持续把关。AI 可以成为优秀的辅助工具却不能自动成为对系统质量负责的软件工程师。1.3 为什么仍然要学习 AI 开发框架构建 LLM 应用早已不只是调用一次模型 API。一个完整系统往往同时涉及数据处理、模型接入、提示词管理、任务编排、状态保存、外部工具和上线运维。模型越强应用能够承担的任务越复杂对框架和工程能力的要求反而越高。AI 开发框架与 Spring、libcurl 等传统框架遵循相似的设计原则。第一项原则是抽象与封装。Spring 封装 Java 企业开发中的依赖注入、事务和 Web 请求处理libcurl 封装 HTTP、FTP、SMTP 等网络协议LangChain 则封装不同大模型、向量数据库和工具之间的调用差异。开发者不必为每一个供应商重新编写整套交互代码。第二项原则是模块化与可组装。Spring 可以通过 Bean 替换不同服务实现LangChain 则把模型、提示词、工具、记忆和输出解析器拆成组件再像积木一样组合成工作流。一个组件发生变化时只要接口保持一致就不必推倒整个应用。框架或工具主要封装对象开发者获得的价值Spring对象生命周期、事务、MVC 等企业开发能力减少底层样板代码形成稳定应用结构libcurlHTTP、FTP、SMTP 等网络协议不必直接使用 Socket 构造协议细节LangChain模型、Prompt、Tool、Memory、Retriever、Output Parser用标准组件组织 LLM 应用流程LangGraph节点、边、状态、循环、分支和持久执行用图结构管理复杂 Agent 工作流框架提供的不只是现成 API还提供一套经过实践沉淀的组织方式架构帮助开发者理解模型、数据、工具和业务代码应该如何分层。质量为审查 AI 生成代码提供接口规范和设计参照。安全通过成熟模式减少底层调用和集成中的常见风险。集成把不同模型、数据库和工具连接成完整应用。效率减少重复开发让团队更快完成从概念验证到产品原型的过程。系统思维让开发者看到从数据进入系统到应用部署运行的完整链路。1.4 未来更可能是混合式开发Vibe Coding 不会完全取代传统编程传统开发也不会拒绝 AI 工具。更可能出现的是一种混合模式开发者使用 AI 处理前端样板、重复代码、小型工具和测试草稿同时依靠框架知识完成核心业务、系统架构、安全治理和长期维护。这种变化重新定义了“编程能力”。未来的核心竞争力不只体现在代码写得多快还体现在能否清楚描述问题、选择合适框架、组织复杂系统、发现模型错误并持续验证结果。用框架思维驾驭 AI 工具才是更稳健的开发方式。2. LLM 驱动应用的框架生态2.1 Python 生态当前最完整的选择LLM 应用框架的目标是为带记忆的 Agent、复杂 RAG 和多步骤工作流提供模型、检索、工具、状态与任务编排能力。当前 Python 生态最为成熟其中 LangChain 和 LlamaIndex 是两个重要代表。框架核心特点适用场景LangChain生态丰富、灵活性高提供模型、链、Agent、Retriever 等大量组件并集成多种模型与向量数据库需要高度定制、连接第三方工具或构建复杂 LLM 应用的场景LlamaIndex重点围绕数据连接、文档索引、查询和检索展开并提供多种 RAG 策略企业知识库、文档问答、私有数据分析和以检索为核心的应用Python 的优势不只来自语言本身还来自完整的周边生态。PyTorch、TensorFlow 和 JAX 提供机器学习能力NumPy、Pandas 负责数据处理FastAPI、Requests 方便连接 Web 服务主流模型 SDK 和向量数据库客户端也通常优先支持 Python。对于仍在快速试验的 LLM 应用这种快速修改、快速运行、快速观察结果的反馈循环尤其重要。2.2 JavaScript、TypeScript 与 Java 生态JavaScript/TypeScript 更适合 Web、全栈和边缘运行环境Java 则更适合既有企业后端和 Spring 体系。语言生态框架特点适用场景JavaScript/TypeScriptLangChain.jsLangChain 的官方 JS/TS 实现核心概念与 Python 版接近全栈开发、浏览器扩展、Edge Runtime、Next.js 等 Web 项目JavaScript/TypeScriptLlamaIndex.TS面向 TypeScript 生态的数据连接和 RAG 能力在 Next.js、Nuxt 等项目中构建文档问答和知识库JavaLangChain4j受 LangChain 启发、面向 JVM 设计API 更符合 Java 习惯将 LLM 能力接入既有 Java 微服务和企业应用JavaSpring AI与 Spring Boot 配置、依赖注入和数据抽象自然结合重视 Spring 原生集成与企业级工程体系的项目JavaSpring AI Alibaba在 Spring AI 基础上加强与特定云模型及云服务的集成已使用相关云生态、需要内网模型服务和配套资源的项目需要特别说明的是LangChain4j 并不是 LangChain 团队开发的 Java 移植版而是一个受其思想影响的社区项目。名称相似不等于维护方和实现完全相同选型时仍要分别评估版本、社区和集成质量。2.3 C 生态与现代 LLM 系统的分工C 在 LLM 应用开发中的角色与 Python、JavaScript 不同。它缺少同等规模的上层“全栈编排框架”背后主要有三方面原因。首先LLM 应用仍处在高频试验阶段。开发者需要不断修改提示词、工作流和外部 API动态语言更适合快速反馈C 的编译和测试周期相对更重与应用层的敏捷迭代节奏不完全匹配。其次两类语言的生态重心不同。Python 拥有数据、机器学习、Web API、模型 SDK 和向量数据库等大量库C 更擅长系统编程、游戏、高频交易、嵌入式和高性能运行时上层云服务集成并不是其传统强项。最重要的是现代 LLM 系统已经形成自然分工Python、Java 或 JavaScript 负责应用层“做什么”C 负责底层推理“怎样更高效地做”。llama.cpp就是典型案例。它使用 C/C 高效运行 LLaMA 等模型并通过量化降低内存需求使消费级硬件也能运行本地模型上层应用既可以把它作为本地库接入也可以启动 HTTP 服务再由 Python 或 JavaScript 调用。因此C 并没有缺席 LLM 技术栈而是更多位于推理引擎、性能优化和端侧部署这一层。2.4 如何选择合适的框架框架选择不应只看热度而要同时考虑团队技术栈、项目目标和生态支持。选择维度判断方式更合适的方向团队技术栈团队最熟悉哪种语言和部署体系优先使用现有成熟栈降低学习与运维成本研究与灵活性是否需要频繁试验模型、Prompt 和 AgentPython LangChain 通常更灵活RAG 为核心是否重点处理私有文档与复杂检索可重点评估 LlamaIndex也可结合 LangChain企业 Java 集成是否已有大量 Spring Boot 服务Spring AI 或 LangChain4j 更自然Web 与边缘运行是否运行在全栈 Web 或 Edge FunctionLangChain.js 更贴近运行环境本地高性能推理是否要求离线、低资源或端侧运行重点评估 llama.cpp 等 C 推理方案混合架构是否同时需要高性能推理与快速业务开发C 提供推理服务Python/Java/TS 负责业务层社区与支持同样重要。Python 和 JavaScript 生态更新快、资料多、第三方集成丰富Java 生态更容易融入成熟企业治理C 则在底层性能和本地运行方面不可替代。框架选型的本质不是选一个功能最多的工具而是为具体业务约束选择最合适的分工方式。3. LangChainLLM 应用开发的核心框架3.1 把原生 LLM 嵌入应用会遇到什么问题直接使用原生模型时开发者往往只需提交一段文本再接收一段回答。这个过程看起来很简单但一旦模型进入真实业务问题就会迅速暴露出来提示词如何统一管理、模型如何切换、自然语言怎样交给程序处理、外部知识怎样更新、模型又怎样调用业务系统可以用一个智能医疗咨询助手来理解这些困难。用户会描述头痛、发烧和咳嗽希望得到初步分析也可能提出儿童误吞异物、药物是否能同时服用等高风险问题。模型的语言能力很强却不意味着它天然具备医疗系统所需的可靠性。问题医疗助手中的表现为什么不能只靠原生模型幻觉面对高风险急救问题时生成听起来合理、实际错误的建议模型按语言概率生成内容不会自动保证专业事实正确Prompt 缺少规范疾病分析、药物咨询、急救建议由不同人编写不同风格提示词输出行为不一致难以调试、复用和持续优化模型切换困难原型期使用成本较低的模型后期希望换成更强或本地模型业务代码与供应商请求格式、消息结构和返回字段强耦合输出非结构化前端需要疾病名称和可信度列表模型却返回一整段自然语言程序难以稳定提取字段正则表达式脆弱且容易失效知识存在截止时间用户询问模型训练时间之后的疫苗研究或变异株信息模型内部知识无法实时更新可能拒答或使用过时信息无法可靠连接工具药物相互作用需要查询专业数据库订单问题需要查询业务 API模型本身不能自动获得外部系统权限也不能保证正确调用其中幻觉是最直接的风险。模型生成文字的机制决定了它可能在证据不足时继续组织语言而且语气越自然错误越容易被用户相信。对于高风险问题系统不能允许模型自由发挥而应识别风险并进入权威信息或人工处理流程。Prompt 的规范化同样重要。提示词并不只是“问模型一句话”它还承载角色、边界、输入数据、输出要求和拒答策略。如果每个业务功能都把提示词硬编码在不同位置系统就会变得难以维护也无法用统一标准评估效果。模型切换问题则体现了抽象层的价值。不同供应商的 URL、鉴权、消息格式、参数和响应结构都可能不同。业务代码如果直接依赖这些细节换模型几乎等于重写所有交互逻辑。理想状态是让业务只面向统一模型接口把供应商差异留给适配层处理。对于药物相互作用这类专业查询一个更合理的过程不是让模型凭内部记忆回答而是模型识别出这是需要专业数据的任务。系统选择并调用受控的权威数据库接口。外部系统返回结构化结果。模型再把专业数据解释成用户能够理解的语言。困难在于如何让模型可靠判断“什么时候调用哪个工具、传什么参数、怎样理解工具结果”本身就是复杂的系统设计问题。3.2 LLM 应用工程如何解决这些痛点面对上述问题业界逐渐形成了一套 LLM 应用工程方法。它不再把模型当作完整系统而是把模型放在提示词、检索、工具、结构化输出和安全控制之间。原始痛点对应方法核心思想幻觉与 Prompt 混乱Prompt Engineering RAG用统一模板规定行为并在回答前检索可信知识模型切换成本高LLM API 抽象层业务面向统一接口供应商差异由框架适配输出无法被程序消费Output Parser Schema要求模型按 JSON 等结构输出再校验为程序对象知识陈旧检索增强生成在请求发生时注入外部、可更新的知识无法执行外部任务Tool Agent让模型负责理解和决策让工具负责查询与执行一个成熟的 LLM 应用是 Prompt、RAG、外部 API、输出解析器和任务编排共同组成的系统原生大模型是核心引擎之一但不是全部。这正是 LangChain 出现的背景。LangChain 是一个用于开发 LLM 驱动应用的框架它把自然语言处理流程拆成标准化组件让开发者能够组合和定制工作流。这里的“组件”指模型、提示词模板、输出解析器、检索器、工具等核心构建块“自然语言处理流程”则是一组按照顺序协作的步骤。例如公司文档问答系统可能经历读取文档、切分文本、生成向量、保存向量、接收问题、检索相关片段、组合问题与片段、调用模型、解析输出、返回答案。3.3 LangChain 的链式思想LangChain 的名称里有一个关键单词Chain。链式思想是它最具代表性的设计之一。与其让提示词、模型和解析器各自独立执行不如把它们连接成一个整体对外只暴露一次调用入口。最简单的提问流程至少包含两个组件Prompt Template保存固定提示结构并把用户输入填入指定位置。LLM/Chat Model接收模板生成的消息再返回模型结果。如果没有链应用需要先执行提示词模板拿到格式化内容再手动把它交给模型如果使用链则可以把二者组合为Prompt Template - Model调用一次链就完成整套流程。执行方式开发者需要处理的过程特点组件独立执行调用模板、保存中间结果、再调用模型过程直观但步骤越多手动连接越繁琐链式执行预先组合组件对外调用整条链结构清晰、易复用也便于替换其中一个组件链式并不意味着所有任务都必须是简单直线。它首先强调的是组件可以组合一个链可以把检索结果交给提示词也可以把模型输出交给解析器还可以作为更大流程中的一个步骤。对于步骤固定、顺序明确的任务链能够显著减少胶水代码。LangChain 后续引入的表达式语言进一步强化了这种组合思想。开发者可以用统一方式描述“上一步输出进入下一步输入”的关系并获得同步、异步和流式等执行能力。其核心仍然不是语法本身而是让每个组件遵守清晰的输入输出契约。3.4 LangChain 的标准化模块与能力LangChain 提供的能力可以分为模型、提示词、链、记忆、检索与工具等几个部分。模块主要作用解决的问题模型接口统一调用大语言模型和 Embedding 模型降低切换不同模型供应商的改造成本Prompt Template管理固定规则、动态变量、少样本示例和提示选择避免提示词散落在业务代码中Chain把多个步骤和组件连接成完整流程减少手动传递中间结果的胶水代码Output Parser把模型输出转换为字符串、JSON 或结构化对象让模型结果可以进入前端、数据库和业务接口Memory/State保存多轮交互中的上下文信息让对话能够保持连续性Document Loader从文件、网页和数据库读取内容统一外部知识的载入形式Text Splitter把长文本切成适合检索的小片段适配上下文窗口并提升检索粒度Embedding把文本转换为表示语义的数值向量让系统能够按语义相似度查找内容Vector Store保存向量和原文并执行相似度搜索支撑知识库与 RAG 检索Retriever按查询返回相关文档的统一接口隔离向量搜索、关键词搜索等底层差异Tool/Agent连接数据库、搜索、计算器和业务 API让模型不仅能回答还能调用外部能力完成任务模型接口的意义是抽象而不是抹平所有差异。开发者可以用相近方式调用不同模型但各模型的上下文长度、工具调用、流式输出和多模态能力仍可能不同切换之后依然需要测试。Prompt Template 则把固定规则与动态数据分开。例如系统角色和输出要求可以保持不变用户问题、检索文档和少样本示例在运行时传入。这种方式比字符串拼接更容易统一维护。早期 LangChain 提供了多种对话 Memory用于保存聊天历史或摘要。随着工作流变得更复杂单纯的对话记忆已经无法覆盖分支、循环、暂停和长期状态因此这部分能力后来更多由 LangGraph 承担。检索与向量存储是构建 RAG 的基础。一个典型知识库流程可以分为两个阶段阶段主要步骤目的知识入库加载文档 → 清洗 → 切分 → Embedding → 写入向量库把原始资料变成可按语义搜索的知识单元用户查询问题向量化 → 检索相关片段 → 组合 Prompt → 模型生成让模型在回答时获得外部知识而不是只依赖训练记忆Embedding 可以理解为一组表示语义的数字。含义相近的文本向量位置通常也更接近。Vector Store 负责保存这些向量、原文和元数据Retriever 则定义“输入查询、返回相关文档”的统一方式。Retriever 的底层不一定只能是向量数据库也可以连接关键词检索或其他搜索系统。LangChain 还形成了围绕调试、监控、评估和部署的配套生态。这些能力帮助开发者观察链路、追踪模型输入输出并评估应用效果但它们不是理解 LangChain 核心概念的前提。核心仍然是用标准组件把模型能力组织成可复用的应用流程。3.5 LangChain 的起源与发展LangChain 由 Harrison Chase 在 2022 年 10 月开源发布最初用于解决开发者调用 GPT 等大模型时遇到的模型抽象和应用编排问题。随着 LLM 应用迅速发展它的语言支持、模型集成和包结构也不断变化。时间主要变化影响2022 年 10 月LangChain 开源发布Prompt、模型与链开始形成系统化开发方式2023 年增加 JavaScript/TypeScript 支持并扩展更多模型提供商和本地模型开发者群体从 Python 扩展到前端与全栈生态2023 年末至 2024 年初核心代码与第三方集成逐步解耦提升模块化程度减少核心包与大量集成之间的耦合2024 年 1 月0.1引入langchain-core核心抽象稳定集成迁移到社区包或独立伙伴包同时加强表达式语言依赖边界更清晰链的组合方式更统一2024 年 5 月0.2加强异步、流式输出以及向量数据库和检索集成更适合 Web 服务和实时交互2024 年下半年0.3持续改进性能并增加向量存储和工具集成生态覆盖范围进一步扩大2025 年 9 月1.x Alpha统一不同提供商的现代模型能力收缩主包范围并用兼容方案承接旧抽象框架开始从“大而全”转向聚焦核心与重要抽象版本提示LangChain 的 API 演进很快历史示例与新版本的包名、导入路径可能不同。理解模型、Prompt、Chain、Retriever、Tool 等核心思想比记住某一版的具体写法更重要。4. LangGraph面向复杂工作流的图式架构4.1 为什么 LangChain 的线性链不够用LangChain 的 Chain 很适合步骤固定、顺序明确的任务。但随着开发者开始构建高级 Agent、多轮对话和多智能体协作系统线性结构的局限逐渐显现真实流程并不总是从 A 走到 B再从 B 走到 C它可能需要根据状态选择不同路径也可能回到前一步重新执行。假设要构建一个自动处理客服工单的 AI Agent。用户可能提交退货请求、产品咨询或投诉。理想流程需要先判断意图再收集必要信息校验订单或问题描述决定由 AI 继续处理还是转交人工最后返回结果。如果使用简单的Chain A - Chain B - Chain C会遇到四个具体问题。第一难以处理循环与反复询问。用户第一次提供的订单号可能不完整系统需要再次请求补充并持续循环直到信息完整。线性链只能继续向前难以自然“跳回”信息收集阶段。常见结果是让整条链失败或者返回僵硬的错误消息。第二状态维护困难。客服对话可能持续几分钟、几小时甚至几天。传统链每次调用通常只关心当前输入历史消息、已收集字段和处理进度需要开发者额外保存。随着状态增多手写数据库读写和恢复逻辑会越来越臃肿。第三人工介入会割裂流程。当 AI 无法处理投诉或高风险问题时流程需要暂停等待人工完成审核再从暂停位置继续。如果使用普通链AI 部分和人工部分往往会被拆成两个系统还需要额外机制通知人工、接收结果并重新触发后续步骤。第四条件跳转容易变成大量if/else。投诉可能走A - B - C产品咨询可能走A - D - E。当所有路由逻辑都堆在一个“主链”中业务流程会隐藏在代码控制语句里难以可视化、调试和维护。线性 Chain 的限制客服场景中的表现工作流真正需要的能力只能顺序向前信息不完整时无法回到收集阶段循环调用之间缺少共享状态多轮对话和工单进度容易丢失状态维护与持久化流程难以暂停恢复AI 转人工后自动化链路中断Human-in-the-loop条件分支依赖大量判断不同意图路径混在主链中动态路由和条件边4.2 LangGraph 如何解决这些问题LangGraph 是 LangChain 生态中面向复杂 Agent 工作流的图式编排框架。它使用图结构和共享状态来描述应用逻辑重点解决循环、分支、长时间状态维护和人工介入等问题。LangGraph 的核心思想是把应用建模为一张会随状态变化而流转的图节点表示处理步骤边表示步骤之间的转移关系状态保存整个流程需要共享的数据。在客服工单中可以先定义一组状态字段状态字段含义示例intent用户意图return、inquiry、complaintcollected_info已收集的业务信息订单号、问题描述、退货原因needs_human是否需要人工介入true或falseis_verified信息是否已经验证true或falseis_complete整个流程是否完成true或falsemessage_history多轮对话历史用户消息与系统回复列表状态对象贯穿整个工作流。意图识别节点写入intent信息收集节点更新collected_info验证节点修改is_verified人工判断则更新needs_human。后续节点不需要重新猜测之前发生了什么只需读取当前状态。图结构还允许把“信息不完整”连接回信息收集节点形成循环把“退货”“咨询”“投诉”分别连接到不同处理节点形成分支当needs_human为真时流程可以进入人工节点等待处理后再回到自动化流程。这种设计把原本隐藏在大量条件语句中的逻辑变成明确拓扑。开发者可以直接看到有哪些节点、可能走哪些路径、什么条件会回退、什么情况会转人工。4.3 LangGraph 的核心技术特点LangGraph 的图式架构由节点、边和状态组成但它的价值不只是“把流程画成图”而是为复杂 Agent 提供一套适合长时间运行的执行方式。**节点Node**代表一个操作步骤。节点可以完成意图识别、信息收集、调用模型、查询工具、验证结果或等待人工。一个节点既可以是普通业务逻辑也可以复用 LangChain 的 Chain、Retriever 或 Agent。**边Edge**表示节点之间的转移和数据流。固定边表示无条件进入下一步条件边则根据当前状态动态选择路径。节点甚至可以连接回自己或之前的节点从而实现循环。**状态State**是图中所有节点共享的数据。每个节点都可以读取状态并更新自己负责的字段用户的消息、已收集的信息和决策结果因此能够在整个流程中保留。技术特点工作方式适用问题循环与分支节点可以连接到其他节点或回到自身信息补全、反思重试、多轮询问动态路由根据当前状态决定下一节点退货、咨询、投诉等不同子流程状态维护状态在整个图中传递和更新保存对话、字段和处理进度持久执行定期保存执行状态从中断位置继续长时间运行任务、故障恢复人机协作在关键节点暂停允许人工检查和修改状态审批、高风险操作和投诉处理全面记忆同时支持当前流程的短期记忆和跨会话长期信息连续对话、用户偏好和历史任务调试与追踪记录执行路径、状态变化和节点指标分析 Agent 为什么选择某条路径生产部署围绕有状态、长时间工作流提供扩展能力大规模运行复杂 Agent 系统持久执行是理解 LangGraph 的一个关键点。普通函数失败后往往只能从头重跑图式工作流可以保存中间状态使流程在故障修复后从上次位置继续。这对于运行几小时甚至几天的任务非常重要。人机协作则让 AI 流程不再是全自动黑箱。系统可以在发送邮件、执行退款、处理投诉等关键节点暂停让人工检查当前状态、修正内容或决定是否继续。人工不是流程之外的补丁而是图中的正式参与者。记忆也不再只等于聊天记录。短期工作记忆用于当前任务的连续推理长期记忆则用于跨会话保存用户信息或历史经验。二者配合才能让 Agent 真正具备持续状态而不是每次都从空白开始。4.4 LangChain 与 LangGraph 是互补关系LangGraph 并不是为了取代 LangChain。它复用了 LangChain 的模型接口、工具、检索器和链等组件也允许开发者把一条 Chain 或一个 Agent 放进图节点中。二者分别解决不同层面的问题。对比维度LangChainLangGraph核心定位LLM 应用组件与链式组合框架有状态 Agent 和复杂工作流编排框架主要结构Chain强调步骤组合Graph强调状态和控制流更适合简单线性任务、固定 RAG、模型调用流程循环、分支、人工介入、长时间任务状态能力早期以对话 Memory 为主以贯穿整张图的 State 为核心组件关系提供模型、Prompt、Tool、Retriever 等构建块在节点中直接复用 LangChain 构建块使用原则简单任务优先保持流程直接控制流确实复杂时再使用对于简单的摘要、分类、固定问答LangChain 的链式结构已经足够高效对于需要动态决策、长期状态和多智能体协作的场景LangGraph 才能体现优势。选择标准不是哪个框架更高级而是业务流程究竟是线性的还是需要一张状态图。4.5 LangGraph 的起源与发展LangGraph 的出现与 LLM 应用复杂度增长密切相关。随着 Agent 从单次工具调用发展为多轮推理、循环修正和长期任务LangChain 原有链式结构需要一个更低层、更可控的编排补充。时间主要变化意义2024 年初LangGraph 以实验性图式框架出现LangChain 从线性链扩展到有状态图结构2024 年中建立独立文档与代码仓库开始独立演进图编排逐渐成为单独工具集2024 年中后期引入并完善 Checkpoint 机制工作流状态可以定期保存支持恢复和审计2024 年下半年0.2、0.3 等版本持续改进异步、并发、类型和错误处理复杂 Agent 的稳定性和开发体验提升2025 年发布 0.4、0.5 等版本Python 与 JavaScript 实现继续完善多语言支持和配套能力逐步成熟2025 年 6 月发布 0.6并启动 v1.0 路线规划开始为稳定版本收集反馈并确定核心能力从这条演进路径可以看到LangGraph 的重点始终围绕状态、可靠性和复杂控制流展开。它不是把简单任务复杂化而是在 LLM 应用真正需要循环、分支、人工和长时间运行时提供更符合问题结构的表达方式。5. LangChain 与 LangGraph 的学习路径5.1 从核心组件到复杂工作流LangChain 和 LangGraph 的知识存在明确的前后关系。模型、Prompt、Chain、Retriever 和 Tool 是基础状态、条件路由、循环和多智能体则建立在这些基础之上。因此更合理的学习顺序可以分为三个阶段。学习阶段核心目标应掌握的内容第一阶段LangChain 核心精通理解 LLM 应用的标准组件与链式思想模型接口、Prompt、Chain、Output Parser、Document、Embedding、Vector Store、Retriever、Tool、Agent第二阶段LangGraph 进阶突破理解有状态图和复杂控制流State、Node、Edge、条件路由、循环、持久化、Human-in-the-loop、短期与长期记忆第三阶段项目实践与持续学习把组件和工作流转换为业务架构需求拆解、数据接入、状态设计、工具边界、调试评估、框架版本演进第一阶段不要急于构建复杂 Agent而要先理解每个组件解决什么问题。只有真正分清 Embedding、Vector Store 和 Retriever 的关系才能理解 RAG只有理解 Prompt、Model 和 Output Parser 的输入输出才能理解 Chain 为什么可以组合。第二阶段的重点也不是背诵图相关名词而是学会把业务流程转换为状态和控制流。开发者需要判断哪些数据必须保存在 State 中哪些步骤是 Node哪些连接是固定 Edge哪些地方需要条件分支什么情况会循环什么操作必须交给人工。第三阶段强调综合能力。一个完整项目会同时遇到模型选择、数据质量、工具权限、状态恢复和上线维护问题。此时框架知识不再是孤立 API而是一套把复杂业务需求转换为 AI 解决方案的架构方法。最终应获得两类能力理解框架能够系统解释 LangChain 与 LangGraph 的核心概念、适用边界和协作关系。解决问题能够从零拆解一个 LLM 应用选择组件、设计数据流并判断什么时候需要图式工作流。5.2 学习 AI 开发框架的真正价值学习框架的价值可以从技术实现和个人成长两个维度理解。在技术实现层面框架通过标准化工具和抽象机制降低模型接入、数据处理、任务编排、部署和运维的复杂度。开发者不必重复处理每个供应商的底层差异可以把更多精力投入业务逻辑和产品创新。在能力成长层面框架凝聚了大量领域实践。理解这些设计可以帮助开发者吸收提示词管理、模型适配、检索、工具调用和状态编排等成熟方法。更重要的是LLM 应用开发横跨数据、模型、API、前端交互和运行维护框架能够推动开发者形成完整的系统架构视角。价值维度具体收获开发效率使用标准组件减少重复实现更快完成原型与验证工程质量用明确接口和工作流结构提高可维护性最佳实践理解模型、检索、工具、记忆和状态的成熟分工架构思维从单次模型调用上升到数据流、控制流和系统边界技术视野理解不同语言生态、模型服务和运行架构的协作方式职业能力能够承担从需求分析到 AI 系统设计的更完整职责AI 工具会持续降低代码生成门槛但能够评估结果、组织系统并为质量负责的人依然不可替代。掌握 LangChain 和 LangGraph 的意义不只是学会两个工具而是建立一套面对复杂 LLM 应用时可复用的工程思维。总结Vibe Coding 让软件开发从手动编码逐渐转向意图驱动但模型生成代码仍然受到架构黑箱、上下文限制、知识滞后、安全风险和可靠性不足的约束。AI 开发框架因此没有失去价值反而成为连接模型与真实应用的重要基础。LangChain 通过模型、Prompt、Chain、Retriever、Tool 和 Output Parser 等标准组件解决模型接入、知识检索和任务组合问题LangGraph 则进一步用 State、Node 和 Edge 表达分支、循环、人工介入和长期状态。二者不是替代关系简单、确定的任务适合链式结构复杂、有状态的 Agent 才需要图式编排。开发者真正需要掌握的也不是某个版本的 API而是如何判断问题边界、选择合适抽象并把模型、数据、工具和业务流程组织成可靠系统。
)
