LangChain 与 LangGraph 介绍

一AI 时代下的编程范式1. Vibe Coding 氛围编程1.1 Vibe Coding 的起源在过去十年间低代码 / 无代码平台和 AI 代码助手持续冲击着软件开发行业。如今一种被称为 Vibe Coding 的新兴实践突然走红甚至颠覆了人们对 程序员到底在做什么 的认知。Vibe Coding (氛围编程) 是一种依赖人工智能的计算机编程实践其核心在于开发者使用自然语言提示向针对代码优化的大语言模型 (LLM) 描述问题由 LLM 生成软件从而使程序员摆脱编写和调试底层代码的需要。这个术语由 OpenAI 联合创始人兼特斯拉前人工智能主管 Andrej Karpathy 于 2025 年 2 月提出并迅速成为一种新兴的编码方式Vibe Coding 的倡导者认为即使是业余程序员也能在无需大量培训和技能的情况下生成软件这代表了一种更为直观和便捷的开发模式。Vibe Coding 工作流程开发者通过自然语言描述需求AI 即可生成代码开发者测试后提供反馈形成迭代循环。其关键特征在于用户通常在不完全理解代码底层机制的情况下接受 AI 生成的代码。实际上这与仅仅将 LLM 作为代码输入的辅助工具不同Vibe Coding 仍然需要开发者审查测试和理解每一行代码。Vibe Coding 的本质是完全沉浸于 AI 助手的 氛围 中将详细的实现过程外包给 AI。正如 Karpathy 最初所描述的那样:这不算真正的编程 -- 我只是看看东西说说东西运行东西然后复制粘贴东西而且它大多都能工作 Vibe Coding 标志着软件开发模式的根本转变从细致的手动编码转向更抽象意图驱动的方法人类开发者在此过程中扮演着指导 AI 的角色。因此Vibe Coding 的出现对开发者的技能要求产生了显著的影响并正在改变传统的软件开发方法:开发者需要更加注重问题定义和规范清晰地使用自然语言表达需求和期望的结果。确定最佳的提问方式变得至关重要。同时开发者需要具备指导和审查 AI 生成代码的能力评估完善和测试 AI 产出的代码。开发者更像是扮演指导者或编辑的角色。系统设计和架构的理解变得比低层次的编码更为重要。批判性思维和问题解决能力对于评估和改进 AI 生成的代码至关重要。此外开发者需要学习如何有效地与 AI 沟通掌握提示技巧以获得期望的结果。虽然侧重点有所变化但对编程基本原理的理解对于有效地指导 AI 和进行调试仍然很有价值。可以看到清晰地定义问题和指导 AI 的能力变得至关重要。此外AI 的输出需要验证这需要批判性思维和对软件架构的理解。这表明开发者正在从 代码编写者 转变为更像是能够有效利用 AI 的 软件架构师 或 产品负责人。2025 年Vibe Coding 的开发方式发展得迅速且火热。从 CursorTraeClaude Coding各大厂商纷纷入局无数自媒体鼓吹开发无用论这引发了一个普遍的疑问既然 AI 能直接写代码我们还有必要花费精力去学习复杂的开发框架吗1.2 Vibe Coding 的局限性尽管 Vibe Coding 以其惊人的速度和低门槛带来了革命性的开发体验但它并不能完全取代传统的框架开发。使用过它们人可能会发现它们生成的代码往往只是 能用 而非 优秀。主要体现在以下几个方面:代码质量与架构的 “黑箱” 困境AI 的目标是生成功能上可运行的代码但它无法理解什么是 “优雅”“可维护”“可扩展” 的代码架构上下文长度的 “金鱼记忆” 与知识滞后性1. 有限的上下文窗口即使上下文长度在不断增长LLM 也无法记住并理解一个庞大项目的全部代码。在开发过程中后期的一个需求可能需要修改前期生成的代码。AI 由于 “忘记” 了之前的完整上下文很可能会生成与现有架构冲突或重复的代码导致系统腐化。2. 知识截止与 “幻觉”LLM 的训练数据有截止日期它可能无法使用最新的语言特性库版本或最佳实践更危险的是它可能会 “幻觉” 出一些不存在的 API库函数或参数生成看似正确实则无法运行的代码这对开发者甄别能力提出了极高要求安全性与可靠性的 “隐形地雷”这是 Vibe Coding 在企业级应用中最致命的弱点。1. 安全漏洞的无声引入AI 没有 “安全” 意识。它可能会轻松地生成含有 SQL 注入XSS 攻击硬编码密码不当的权限设置等安全漏洞的代码。对于安全至关重要的系统 (如金融医疗)这是一个不可接受的风险。2. 可靠性难以保障生成的代码缺乏经过严格测试的可靠性。它可能在小规模数据下运行良好但在高并发大数据量或边缘案例下表现不稳定甚至崩溃。缺乏完善的日志监控和熔断机制使得线上排查问题变得极其困难可以看到Vibe Coding 不是一个替代品而是一个强大的效率倍增器。它的正确定位是:糟糕的 程序员: 它无法负责架构设计制定技术方案保证代码质量确保系统安全。这些核心的战略性的工作必须由拥有扎实框架知识丰富工程经验和深刻判断力的开发者来完成优秀的辅助工具它擅长生成样板代码完成重复性任务编写单元测试解释复杂代码提供灵感建议。它可以极大提升开发效率解放开发者去专注于更有价值的任务实际上目前真正跑在生产线上的代码依旧是工程师一个函数一个函数敲出来的。但像是改函数签名重命名变量写一个测试用例小的 Demo工具等这些 “接地气” 的工程活恰恰是 AI 最佳的用武之地。因此在同年 8 月底Karpathy 改变了口径他发文表示不要幻想有一个万能的 AI 工具能解决所有编程问题更可行的做法是建立一个结构让不同的工具在不同场景各司其职像接力赛一样完成开发任务 。2. AI 开发框架新战略高地我们正站在人工智能革命的中心。大语言模型 (LLM) 如 ChatGPT 的崛起不仅改变了人机交互的方式更彻底重塑了软件开发的游戏规则。如今构建一个 AI 应用早已不再是简单地调用 API而是需要应对数据处理模型交互任务编排和状态管理等复杂挑战。即使 AI 代码生成工具 (Vibe Coding) 日益强大但它们生成的代码往往只是 能用 而非 优秀。真正的专业开发者需要理解架构设计系统权衡与工程最佳实践 —— 这正是框架学习的核心价值2.1 框架原则AI 开发框架与传统框架 (如 JAVA 中的 Spring,C 中的 libcurl 库)它们都共享一些框架原则抽象与封装Spring: 封装了 Java EE 开发的复杂性如依赖注入事务管理MVC。开发者不需要手动管理对象生命周期或处理繁琐的 Servlet API。libcurl: 封装了网络协议的复杂性 (HTTP, FTP, SMTP 等)。开发者不需要使用底层的 socket API 来手动构建 HTTP 请求。LangChain: 封装了与不同 LLM (OpenAI, Anthropic 等)向量数据库 (Chroma, Pinecone)工具 (Tools) 交互的复杂性。开发者不需要为每个供应商编写不同的 API 调用代码模块化与可组装性Spring: 通过其强大的依赖注入 (DI) 和控制反转 (IoC) 容器将应用程序组织成高度可插拔的 Bean (Component , Service )。你可以轻松替换数据库实现或服务实现。LangChain: 核心概念就是 “链”(Chain)它将不同的模块 (LLM, Prompts, Tools, Memory, Output Parsers) 像乐高积木一样组合起来构建复杂的 AI 工作流。2.2 超级武器在这场 AI 时代的变革中如 LangChainLangGraph 这样的 AI 开发框架正成为开发者的 超级武器。它们如同智能时代的操作系统连接着强大的 AI 模型与复杂的现实应用让开发者能够以更高效率构建更强大的 AI 应用AI 开发框架就像是一个万能工具箱它把那些复杂底层的技术都封装好了提供了各种现成的工具和模块。这让我们不需要从轮子开始造起能更轻松更快速地构建 AI 应用把想法变成现实框架知识为我们提供了:架构让我们知道代码应该组织成什么样子质量让我们能判断 AI 生成的代码是否合格安全框架内置的最佳实践和模式能规避许多基础风险集成让我们能高效地将 AI 生成的 “零件” 组装到经过验证的可靠的大系统中。学习这些框架不仅是掌握新技术更是一项关键的战略投资它有以下这些好处:提升效率快速原型框架提供了标准化的流程和预构建的模块大 减少了重复编码的工作量这意味着我们能更快地完成从概念验证到实际产品的过程化繁为简解决痛点我们以流行的 LangChain 框架为例它就把复杂的 LLM 应用开发拆解成了几个核心模块专门解决我们常见的难题强大的生态集成好的框架 (比如 LangChain) 已经帮我们集成了成百上千种主流工具和服务包括不同的 AI 模型数据库等这让我们可以像搭积木一样自由地组合和尝试不同的技术构建更强大的应用思维升级帮助开发者建立从数据到部署的全链路系统思维职业领先在 AI 时代掌握主流开发框架已成为核心竞争力3. 未来展望对于开发者来说Vibe Coding 不会完全取代传统编程技能而是形成互补。我们可能会看到一种新的平衡其中开发者专注于高层次的系统设计架构决策和业务逻辑而将更多的实现细节委托给 AI。这种协作模式将重新定义什么是 编程技能从纯粹的代码编写转向有效指导和管理 AI 工具的能力。未来的开发模式很可能是混合式开发利用 Vibe Coding 的速度处理前端和重复性工作同时依靠扎实的框架知识来构建核心业务逻辑保证系统架构的健壮性和安全性。因此学习像 LangChainLangGraph 这样的框架其战略价值在 Vibe Coding 时代不降反升是在 AI 时代驾驭更复杂项目的必备技能。最终“框架思维” 驾驭 “Vibe 工具”, 才是未来开发者最强的核心竞争力。尽管有人担忧 AI 会取代程序员但更可能的情况是那些能够有效使用 AI 工具的开发者将取代那些不能的开发者。正如历史上其他技术变革一样新工具不会消除对专业人才的需求而是改变了对他们的技能要求二LangChain:LLM 应用开发的核心框架1. LLM 驱动的应用程序的框架由 LLM 驱动的应用程序的框架它们的目标是提供构建复杂 LLM 应用 (如带有记忆的代理复杂的 RAG 系统多步骤工作流) 所需的全套工具。以下是按语言生态划分的主流框架:1.1 Python 生态 (绝对主流)框架核心特点与优势适用场景LangChain生态最丰富灵活性极高提供了最全面的组件 (链代理检索器等), 社区活跃集成工具众多 (大量向量数据库模型提供商)几乎任何复杂的 LLM 应用尤其是需要高度定制化和集成第三方工具的场景是大多数项目的首选LlamaIndex专注于 RAG 和数据连接在文档索引查询检索方面性能优异提供了从简单到高级的多种检索策略现已扩展为全功能框架以查询和分析私有数据为核心的应用如企业知识库文档智能问答数据增强的聊天机器人1.2 JavaScript/TypeScript 生态 (前端与全栈)框架核心特点与优势适用场景LangChain.jsPython LangChain 的官方 JS/TS 移植版本API 与 Python 版高度相似支持大多数核心功能 (链代理工具)全栈开发浏览器扩展Edge Runtime (如 Vercel Edge Functions)Next.js 等现代 Web 框架的集成LlamaIndex.TSLlamaIndex 的 TypeScript 版本专注于 TS 生态中的 RAG 应用在 Next.js, Nuxt 等全栈框架中构建强大的 RAG 应用1.3 Java 生态框架核心特点与优势适用场景LangChain4j一个受 LangChain 启发为 JVM 设计的框架API 设计符合 Java 习惯注意它不是 LangChain 团队开发的是一个社区项目需要将 LLM 能力集成到现有 Java 企业应用中的场景如微服务大型后端系统Spring AISpring 官方项目与 Spring 生态无缝集成 提供统一的 API 和数据抽象生产就绪特性强所有基于 Spring Boot 的项目尤其是企业级生产系统追求稳定性和框架原生集成Spring AI AlibabaSpring AI 的扩展项目由阿里云官方支持核心优势在于对阿里云灵积模型服务平台 (及通义千问等模型) 的深度集成和优化它提供了开箱即用的配置方便 Java 开发者以 Spring 的方式便捷安全地调用阿里云的各种大模型深度依赖阿里云生态和服务的 Spring 项目当需要直接高效地使用通义千问系列模型在阿里云 VPC 内网访问模型服务以获取更低延迟和成本或者需要与阿里云的其它云服务 (如 OSSNAS) 结合时这是最自然和推荐的选择1.4 C 生态C 生态在 LLM 应用开发的全栈框架领域相对缺失但这背后有深刻的技术生态和商业原因主要原因是因为 C 的角色定位不同开发效率与快速迭代的需求不匹配LLM 应用开发目前仍处于高度实验性和快速迭代的阶段。Python/JS: 作为动态语言具有快速原型设计的优势。开发者可以快速修改提示词调整工作流逻辑集成新的 API并立即看到结果。这种快速反馈循环对于探索 LLM 能力至关重要。C: 作为静态编译型语言虽然性能极高但编译时间长代码修改和测试的周期也更长。这种 “厚重” 的开发体验与当前 LLM 应用需要的 “敏捷” 开发模式背道而驰生态系统的重心不同LLM 应用开发严重依赖丰富的第三方库和服务。Python 生态拥有无与伦比的库支持包括但不限于:机器学习框架PyTorch, TensorFlow, JAX (它们虽然底层有 C, 但主要 API 是 Python)数据处理NumPy, PandasWeb 和 API 集成FastAPI, Requests向量数据库客户端种类繁多模型提供商 SDK:OpenAI, Anthropic 等官方 SDK 首选都是 PythonC 生态其传统优势领域在于系统编程游戏开发高频交易嵌入式等对于现代 Web API云服务集成等领域的库支持远不如 Python 丰富和易用技术架构的天然分工 (核心原因)现代 LLM 应用架构普遍采用 “ Python/JAVA 负责应用层 (做什么)C 负责底层推理 (怎么做)” 的分工模式。一个完美的例子是 llama.cpp (官网: https://github.com/ggerganov/llama.cpp)它本身是一个用 C/C 编写的热门项目用于高效推理 LLaMA 系列及众多其他架构的模型。它以其出色的性能和极低的内存需求 (通过量化) 而闻名。你可以将 llama.cpp 作为库链接到你的 C 应用程序中从而在本地直接运行模型。我们可自行提供的 server 功能启动一个 HTTP API 服务。然后上层的 Python 或 JavaScript 应用通过调用这个 API 来使用它从而结合了 C 的推理性能和 Python 的应用开发效率虽然缺少 “全栈框架”但可以看到 C 在 LLM 技术栈中是不可或缺的基石llama.cpp 就是最成功的案例使在消费级硬件上运行大模型成为可能1.5 如何选择对于框架的选择核心逻辑有以下几点团队技术栈优先选择团队最熟悉的语言生态以降低开发和学习成本如果你所在的团队和技术栈是 Java想快速为企业应用添加 AI 功能LangChain4j 和 Spring AI 是绝佳的选择。如果你的需求是极致性能离线运行或在资源受限的环境 (如手机嵌入式设备) 中部署模型那么 C 生态的 llama.cpp 是你的不二之选。在大多数情况下一个混合架构也很常见例如用 C 实现高性能推理引擎然后用 Java 或 Python 构建业务层和 API 接口项目需求:如果项目是研究性质或需要最大灵活性Python (LangChain) 是不二之选。如果项目是以 RAG 为核心LlamaIndex (Python/TS) 提供了更专业的工具。如果项目需要深度集成到现有企业级后端 (如 Spring 应用), 则选择对应的 Spring AI。如果项目是面向 Web 的全栈应用或边缘函数LangChain.js 是最佳选择。社区与支持:Python 和 JS 生态的框架 (LangChain) 更新最快社区最活跃遇到问题更容易找到解决方案是大多数人的选择。2. LangChain 介绍2.1 复杂场景下LLM 嵌入应用的问题使用过一些原生大模型的人可能会发现一些问题尽管大模型的在某些方面表现振奋人心例如将其当作搜索引擎去使用LLM 生成的答案可能要比其他搜索引擎查到的答案更符合你的预期但要是在复杂的场景下使用如将 LLM 嵌入应用程序时却遭遇了全新难题:简单提示词 (Prompt) 得到的答案经常出现幻觉提示词结构是否可以统一规范如何实现开发过程中大模型的轻松灵活切换大模型输出是非结构化的怎样与要求结构化数据的程序接口交互如何克服预训练模型知识陈旧的问题引入实时更新如何连接模型与外部工具或系统执行具体任务举个例子我们要开发一个智能医疗咨询助手用户可以向其描述症状 (例如:“我最近头痛发烧还有些咳嗽”)助手能提供初步的疾病可能性分析建议的日常护理方法并提醒是否需要立即就医场景 1用户想咨询 “我三岁的孩子吞下了一枚纽扣电池该怎么办”问题分析这个建议是完全错误且致命的。纽扣电池会卡在食道并快速泄漏化学物质灼烧内脏必须立即送医。模型基于训练数据中的 “吞食异物” 相关文本进行了错误生成产生了 “幻觉”。在生产环境中这种错误是无法接受的场景 2开发团队需要为 “疾病诊断”“药物咨询”“急救建议” 等不同功能编写提示词。问题分析提示词的质量和风格直接决定输出结果的准确性和安全性。没有统一的规范会导致应用行为不可预测难以调试且无法规模化地优化效果场景 3项目开始时使用 GPT-3.5 Turbo 进行原型开发成本较低。后期为了提升准确性希望切换到更强大的 GPT-5 或开源模型如 Llama 3。问题分析发现切换成本极高。这意味着一旦选定一个模型整个应用程序的代码就与该模型的 API 强耦合。切换模型几乎等于重写所有与 LLM 交互的代码严重阻碍了技术选型的灵活性。场景 4非结构化输出难以与程序接口交互。应用程序需要将模型分析的 “可能疾病” 结果结构化地展示在前端 UI 的列表里。问题分析程序无法直接解析这段自然语言文本来提取 “疾病名称” 和 “可信度”。必须编写复杂且脆弱的正则表达式或再用一个模型来解析第一个模型的输出极大增加了复杂度和出错概率场景 5用户询问“针对奥密克戎 XBB.1.5 变种最新的加强针效果如何”问题分析主流大模型的训练数据截止于某个特定时间点 (例如 2024 年初)。对于 2024 年下半年或以后的最新疫苗研究和变异株情况它一无所知要么拒绝回答要么基于过时信息给出错误答案医疗信息的实时性至关重要模型的滞后性是巨大缺陷场景 6用户问“布洛芬和阿司匹林可以同时吃吗”问题分析这是一个非常专业的药物相互作用问题模型的内在知识可能不准确或不全理想的流程是:模型识别出这是一个需要查询专业数据库的任务调用一个权威的药物相互作用 API将 API 返回的结构化数据翻译成用户能听懂的语言困难让 LLM 自发地可靠地决定在何时如何调用哪个外部工具并正确解析工具返回的结果是一个极其复杂的系统设计问题这个医疗助手例子集中体现了所有描述中的难题。为了解决它们业界正在形成一整套称为 “LLM 应用工程” 的最佳实践和技术栈:针对幻觉提示词规范采用 “提示词工程” 和 “检索增强生成 (RAG)”。为医疗助手设计严谨系统的提示词模板并强制模型在回答前先从权威实时的医疗知识库中检索信息而不是仅凭记忆回答针对模型切换使用 LLM API 抽象层 (如 LangChain)。这些中间件统一了不同模型的接口让开发者通过配置而非修改代码来切换模型针对非结构化输出采用 “输出解析” 技术。强制要求模型以 JSON 等格式输出并在提示词中严格定义 JSON 的 Schema。一些框架 (如 LangChain) 可以自动将模型输出解析为预定义的 Pydantic 对象针对知识陈旧主要依靠 RAG 来注入实时外部的知识针对连接外部工具采用 “智能体 (Agent)” 框架。让 LLM 作为大脑根据用户请求规划步骤选择工具 (如计算器数据库 API搜索引擎)并执行任务。最终一个成熟的 “智能医疗咨询助手” 不会是直接调用原生大模型而是一个由精心设计的提示词RAG 系统外部工具 API输出解析器等共同组成的复杂系统。原生大模型只是这个系统的核心引擎之一而非全部2.2 LangChain: 解决痛点LangChain 可以解决上述所有问题LangChain 是一个用于开发由大语言模型 (LLM) 驱动的应用程序的框架。它通过将自然语言处理 (NLP) 流程拆解为标准化组件让开发者能够自由组合并高效定制工作流组件 (Components)用来帮助当我们在构建应用程序时提供一系列的核心构建块例如语言模型输出解析器检索器等自然语言处理流程 (NLP)指的是完成一个特定 NLP 任务所需的一系列步骤。例如构建一个 “基于公司文档的问答机器人” 的流程可能包括读取文档分割文本将文本转换为向量 (嵌入)存储向量接收用户问题搜索相关文本段将问题和文本段组合发送给大语言模型 (LLM)解析模型输出并返回答案等。2.3 LangChain 的技术特点LangChain 框架的设计精髓在于以链式 (Chain) 的方式整合多个组件从而构建出功能丰富的大语言模型应用。链式表示 LangChain 允许将多个步骤或多个组件串联起来无需各个组件各自完成其能力而是一次性执行这个 链 上的所有流程举一个最简单的例子若我们想借助提示词完成一次对于 LLM 的提问在 LangChain 中至少需要定义两个组件:提示词模板组件大模型组件使用时我们可以这相当于提示词模板组件执行了一次大模型组件也执行了一次。而对于链式执行来说只需执行一次链而已LangChain 框架提供了一系列标准化模块与接口主要包括以下方面:统一的模型调用通过抽象化的接口支持多种大语言模型 (例如 OpenAI GPT-4/5Anthropic Claude 等) 和嵌入模型使开发者可以灵活切换不同模型供应商灵活的提示词管理提供提示词模板 (Prompt Templates)支持动态生成输入内容并可管理少样本示例与提示选择策略以提升模型响应质量可组合的任务链 (Chains)允许将多个步骤串联成完整流程如先检索文档再生成回复或组合多次模型调用。开发者能够通过自定义链实现复杂的任务编排上下文记忆机制 (Memory)用于存储多轮对话中的状态信息。LangChain 曾提供多种记忆管理方案 (如对话历史记忆和摘要记忆)以实现连贯的交互体验 (注该功能目前已由 LangGraph 支持原有实现已过时)检索与向量存储集成支持从外部加载文档经分割和向量化处理后存储至向量数据库在查询时检索相关信息并输入大语言模型帮助构建检索增强生成 (RAG) 类应用。LangChain 兼容多种主流向量数据库 (如 FAISSPineconeChroma) 和文档加载工具简化知识库应用的开发流程。对于上述技术内容LangChain 的开源组件和第三方集成可以轻松支持快速上手帮助我们构建应用程序。除此之外使用 LangGraph 可以构建支持人机交互的有状态代理。LangChain 公司也在围绕框架构建完整的生态系统包括推出 LangSmith (一个用于调试监控和评估 LLM 应用的平台) 以及 LangGraph Platform (用于 LangChain 应用的部署运维) 等为开发者提供从开发到生产的一站式支持3. 起源与发展LangChain 由 Harrison Chase 于 2022 年 10 月开源发布旨在解决开发者在使用 LLM (如 GPT-3) 时遇到的核心问题。项目迅速获得社区关注2023 年成立 LangChain 公司并获数千万美元融资估值达 2 亿美元。2023 年中LangChain 推出了对 JavaScript/TypeScript 的支持使其开发者社区从 Python 扩展到了前端和全栈开发者。此外LangChain 不断增加对各种 LLM 模型的支持从最初的 OpenAI API 扩展到 AnthropicHuggingFace 等模型提供商以及本地部署的模型 (如 Llama 等)并提供了统一的接口来调用这些模型。2023 年底至 2024 年初LangChain 进行了重大的架构调整将核心代码与第三方集成解耦。LangChain 0.1.0 版本 (2024 年 1 月发布), 也是第一个稳定版本其引入了 langchain-core 库其中包含稳定的抽象接口和核心功能而将具体的第三方集成移至 langchain-community 或独立的伙伴包中。这一拆分提高了框架的模块化程度和依赖管理的清晰度。这一版本还带来了许多新功能和改进例如 LangChain 表达式语言 (LCEL), 支持用户高度定制链 (Chains) 的执行流程。2024 年 5 月LangChain 发布了 0.2.0 版本引入了一系列新特性和改进同时也包含一些 API 的调整。0.2.0 版本进一步增强了对异步调用流式输出的支持并优化了与向量数据库检索系统的集成。2024 年下半年LangChain 发布了 0.3.x 版本持续改进性能和增加新的集成 (如更多的向量存储工具插件等)。2025 年 9 月LangChain 发布了 1.x Alpha 内测版在各提供商之间统一了现代 LLM 功能包括推理引用服务器端工具调用等还新增了预构建的 Langgraph 链和代理。Langchain 包的范围已缩小专注于流行和重要的抽象概念。为保持向后兼容性新增了langchain-legacy包。版本发布:https://github.com/langchain-ai/langchain/releases三LangGraph: 面向复杂工作流的图式架构1. LangGraph 介绍1.1 LangChain 的局限性LangGraph 是 LangChain 生态系统中晚些出现的一个框架其诞生背景与大型语言模型应用日益增长的复杂性密切相关。随着开发者尝试构建更高级的 AI 代理和多轮对话系统传统链式结构的局限性逐渐显现:链式流程通常是线性的预先定义好的步骤难以处理需要循环分支或长期状态维护的复杂场景此外在构建多智能体协作需要人工介入 (Human-in-the-loop) 或长时间运行的任务时需要更灵活的工作流管理和状态持久化支持。举个例子假设我们要构建一个 AI 代理来自动处理用户提交的客服工单 (例如退货请求产品咨询投诉等)一个理想的流程是如果用传统的Chain A - Chain B - Chain C的线性结构来构建会遇到以下具体问题问题 1: 难以处理循环和分支 (无法动态路由和多次询问)在 “信息收集” 阶段用户第一次可能提供了一个不完整的订单号。链式流程是单向的它无法自动 “跳回” 上一步再次请求用户补充信息。结果只能让整个链失败或者生成一个僵硬的错误消息用户体验非常差。无法实现 “只要信息不完整就持续询问直到完整” 这样的逻辑。问题 2: 状态维护困难 (无法长时间运行和记忆上下文)客户服务对话通常是多轮的可能持续几分钟几小时甚至几天。传统的链在每次调用时都是 “无状态” 的。结果状态管理 (记忆) 的重担完全落在了开发者身上需要依赖外部数据库或缓存来手动存储和读取对话状态代码会变得非常臃肿和脆弱问题 3: 难以融入人工介入 (Human-in-the-loop)当 AI 无法处理时需要无缝地转交给人。在链式流程中这意味着链的执行到此中断。无法优雅地实现暂停 AI 流程等待人工处理完毕再将结果返回继续执行后续自动化步骤。结果整个流程会断裂成两半AI 部分和人工部分。你需要构建另外的系统来通知人工接收人工处理结果并重新触发后续的链这完全破坏了工作流的完整性和可管理性问题 4: 僵化的流程 (无法根据条件动态跳转)不同的用户意图需要完全不同的子流程。例如判断用户意图:是 “投诉”。我们的链可能预先设计为走 A-B-C 路径是 “产品咨询”, 可能需要走 A-D-E 路径在链式结构中实现这种条件分支非常笨拙通常需要编写一个巨大的 “主链”, 内部用一系列 ifelse 语句来调用不同的子链。结果流程图的逻辑变成了代码中的控制流语句而不是清晰可见的图形化结构这使得工作流难以设计调试和可视化1.2 LangGraph: 解决痛点为了解决这些问题LangChain 团队于 2024 年推出了 LangGraph 框架旨在提供一种图结构的状态化的方式来构建复杂的 AI 代理应用。LangChain 团队将 LangGraph 定位为 “低层次的编排框架”, 用于构建可控可靠的 AI 代理工作流。目前LangGraph 已经在一些生产环境中得到应用例如 LinkedInUberGitLab 等公司据报道使用 LangGraph 来构建复杂的生成式 AI 代理系统。例如我们将上述链式示例改为图结构:在上述示例中我们可以定义图状态用于存储流程中的临时数据和决策点例如:ntent : 用户意图 (字符串如 return, inquiry, complaint)collected_info : 字典存储收集到的信息 (如订单号问题描述)needs_human : 布尔值表示是否需要人工介入 (默认 False)is_verified : 布尔值表示信息是否已验证 (默认 False)is_complete : 布尔值表示流程是否完成 (默认 False)message_history : 列表存储对话历史用于多轮交互LangGraph 并不是要取代 LangChain而是对 LangChain 的扩展和补充。LangGraph 底层大量复用了 LangChain 的组件 (如模型接口工具记忆等)开发者可以在 LangGraph 的节点中直接使用 LangChain 的链或代理作为子流程。因此LangGraph 与 LangChain 是互补关系:对于简单的线性任务LangChain 的链式结构已经足够高效而对于需要复杂控制流长期状态和多智能体的场景LangGraph 提供了更强大的支持1.3 LangGraph 的技术特点LangGraph 将应用逻辑建模为图 (Graph) 结构其中:节点表示操作或状态边表示节点之间的转移和数据流这种图式架构相比 LangChain 的链式结构更加灵活主要体现在循环与分支LangGraph 中的节点 (Node) 可以连接到其他任何节点包括自己。你可以轻松设置一个 “信息收集” 节点如果信息不完整就让流程再次循环回这个节点本身直到条件满足为止动态路由通过条件边可以根据当前状态的值动态决定下一个要执行的节点。例如在 “分类” 节点之后可以根据分类结果自动路由到 “处理退货”“处理咨询” 或 “处理投诉” 等完全不同的子图中去状态维护LangGraph 有一个核心的状态对象在整个图的执行过程中自动持久化和传递。每个节点都可以读取和修改这个状态。这意味着用户的对话历史已收集的信息都会自动保留轻松支持长时间运行的任务持久执行构建能够经受住故障并能长时间运行的代理自动从上次中断的地方恢复人机协作通过在执行过程中的任何时刻检查和修改代理状态无缝融入人工监督全面记忆创建真正具有状态的代理兼具用于持续推理的短期工作记忆和跨会话的长期持久记忆使用 LangSmith 进行调试借助可视化工具深入洞察复杂代理行为这些工具可追踪执行路径捕获状态转换并提供详细的运行时指标生产级部署借助专为处理有状态长时间运行工作流的独特挑战而设计的可扩展基础设施自信地部署复杂的代理系统总结来说构建 AI 代理应用时如果用传统链式结构构建会变成一个僵硬脆弱难以维护的 “面条代码”。而 LangGraph 则能将其建模为一个灵活可靠可视化程度高且支持复杂逻辑 (循环分支人工) 的工作流图这正是它为了解决日益复杂的 LLM 应用而诞生的价值所在。2. 起源与发展LangChain 团队于 2024 年推出了 LangGraph 框架旨在提供一种图结构的状态化的方式来构建复杂的 AI 代理应用。LangGraph 最初作为 LangChain 0.1.0 版本的一部分被引入标志着 LangChain 从链式架构向图式架构的扩展。在 2024 年初LangGraph 作为实验性功能发布随后在 2024 年中开始独立演进LangChain 团队为 LangGraph 建立了专门的文档和代码仓库并逐步将其打造为一个独立于 LangChain 主框架的工具集。在 2024 年中发布的版本中LangGraph 引入了 Checkpoint (检查点) 机制允许将执行状态定期保存以便故障恢复和审计。2024 年下半年LangGraph 发布了多个版本 (如 0.2.x0.3.x 等), 不断改进其核心功能和稳定性。2024 年底的版本增强了对异步执行和并发的支持并提供了更完善的类型定义和错误处理。2025 年LangGraph 发布了 0.4.x0.5.x 等版本发展出完善的 Python 和 JavaScript 实现并推出了 LangGraph Platform 等配套产品用于简化复杂代理应用的部署和管理。2025 年 6 月LangGraph 发布了 0.6 版本并启动了 LangGraph v1.0 的路线图计划收集社区反馈以确定正式版的功能特性。可以预见LangGraph 将在未来继续演进成为构建高级 AI 代理和复杂工作流的重要框架。版本发布:https://github.com/langchain-ai/langgraph/releases