【LangChain】LangChain 与 LangGraph 介绍

🌈个人主页： 秦jh__https://blog.csdn.net/qinjh_?spm=1010.2135.3001.5343
🔥 系列专栏： https://blog.csdn.net/qinjh_/category_13137010.html

[AI 时代下的编程范式](#AI 时代下的编程范式)

[Vibe Coding 氛围编程](#Vibe Coding 氛围编程)

[Vibe Coding 的起源](#Vibe Coding 的起源)

[Vibe Coding 的局限性](#Vibe Coding 的局限性)

[AI 开发框架：新战略高地？](#AI 开发框架：新战略高地？)

框架原则

超级武器

未来展望

[LangChain：LLM 应用开发的核心框架](#LangChain：LLM 应用开发的核心框架)

[LLM 驱动的应用程序的框架](#LLM 驱动的应用程序的框架)

[Python 生态（绝对主流）](#Python 生态（绝对主流）)

[JavaScript/TypeScript 生态（前端与全栈）](#JavaScript/TypeScript 生态（前端与全栈）)

[Java 生态](#Java 生态)

[C++ 生态](#C++ 生态)

如何选择？

[LangChain 介绍](#LangChain 介绍)

[复杂场景下，LLM 嵌入应用的问题？](#复杂场景下，LLM 嵌入应用的问题？)

LangChain：解决痛点

[LangChain 的技术特点](#LangChain 的技术特点)

LangGraph：面向复杂工作流的图式架构

[LangGraph 介绍](#LangGraph 介绍)

[LangChain 的局限性](#LangChain 的局限性)

LangGraph：解决痛点

[LangGraph 的技术特点](#LangGraph 的技术特点)

前言

💬 hello! 各位铁子们大家好哇。

今日更新了LangChain相关内容

🎉 欢迎大家关注🔍点赞👍收藏⭐️留言📝

AI 时代下的编程范式

Vibe Coding 氛围编程

Vibe Coding 的起源

在过去十年间，低代码/无代码平台和 AI 代码助手持续冲击着软件开发行业。如今，一种被称为 Vibe Coding 的新兴实践突然走红，甚至颠覆了人们对 "程序员到底在做什么" 的认知。

Vibe Coding（氛围编程）是一种依赖人工智能的计算机编程实践，其核心在于：开发者使用自然语言提示向针对代码优化的大语言模型（LLM）描述问题，由 LLM 生成软件，从而使程序员摆脱编写和调试底层代码的需要。

这个术语由 OpenAI 联合创始人兼特斯拉前人工智能主管 Andrej Karpathy 于 2025 年 2 月提出，并迅速成为一种新兴的编码方式。Vibe Coding 的倡导者认为，即使是业余程序员也能在无需大量培训和技能的情况下生成软件，这代表了一种更为直观和便捷的开发模式。

其关键特征在于：用户通常在不完全理解代码底层机制的情况下接受 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 的开发方式发展得迅速且火热。从 Cursor、Trae、Claude Coding，各大厂商纷纷入局，无数自媒体鼓吹开发无用论，这引发了一个普遍的疑问：既然 AI 能直接写代码，我们还有必要花费精力去学习复杂的开发框架吗？

Vibe Coding 的局限性

尽管 Vibe Coding 以其惊人的速度和低门槛带来了革命性的开发体验，但它并不能完全取代传统的框架开发。使用过它们人可能会发现，它们生成的代码往往只是"能用"而非"优秀"。

主要体现在以下几个方面：

代码质量与架构的"黑箱"困境

AI 的目标是生成功能上可运行的代码，但它无法理解什么是"优雅"、"可维护"、"可扩展"的代码架构。

上下文长度的"金鱼记忆"与知识滞后性

有限的上下文窗口：即使上下文长度在不断增长，LLM 也无法记住并理解一个庞大项目的全部代码。在开发过程中，后期的一个需求可能需要修改前期生成的代码。AI 由于"忘记"了之前的完整上下文，很可能会生成与现有架构冲突或重复的代码，导致系统腐化。

知识截止与"幻觉"：LLM 的训练数据有截止日期，它可能无法使用最新的语言特性、库版本或最佳实践。更危险的是，它可能会"幻觉"出一些不存在的 API、库函数或参数，生成看似正确实则无法运行的代码，这对开发者甄别能力提出了极高要求。

安全性与可靠性的"隐形地雷"

这是Vibe Coding在企业级应用中最致命的弱点。

安全漏洞的无声引入：AI没有 "安全" 意识。它可能会轻松地生成含有 SQL 注入、XSS 攻击、硬编码密码、不当的权限设置等安全漏洞的代码。对于安全至关重要的系统（如金融、医疗），这是一个不可接受的风险。

可靠性难以保障：生成的代码缺乏经过严格测试的可靠性。它可能在小规模数据下运行良好，但在高并发、大数据量或边缘案例下表现不稳定甚至崩溃。缺乏完善的日志、监控和熔断机制，使得线上排查问题变得极其困难。

可以看到，Vibe Coding 不是一个替代品，而是一个强大的效率倍增器。它的正确定位是：

糟糕的"程序员"：它无法负责架构设计、制定技术方案、保证代码质量、确保系统安全。这些核心的、战略性的工作必须由拥有扎实框架知识、丰富工程经验和深刻判断力的开发者来完成。
优秀的辅助工具：它擅长生成样板代码、完成重复性任务、编写单元测试、解释复杂代码、提供灵感建议。它可以极大提升开发效率，解放开发者去专注于更有价值的任务。

实际上，目前真正跑在生产线上的代码，依旧是工程师一个函数一个函数敲出来的。但像是改函数签名、重命名变量、写一个测试用例、小的 Demo、工具等这些"接地气"的工程活，恰恰是 AI 最佳的用武之地。

AI 开发框架：新战略高地？

我们正站在人工智能革命的中心。大语言模型（LLM）如 ChatGPT 的崛起，不仅改变了人机交互的方式，更彻底重塑了软件开发的游戏规则。如今，构建一个 AI 应用早已不再是简单地调用 API，而是需要应对数据处理、模型交互、任务编排和状态管理等复杂挑战。

即使 AI 代码生成工具（Vibe Coding）日益强大，但它们生成的代码往往只是"能用"而非"优秀"。真正的专业开发者需要理解架构设计、系统权衡与工程最佳实践------这正是框架学习的核心价值。

框架原则

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 工作流。

超级武器

在这场 AI 时代的变革中，如 LangChain、LangGraph 这样的 AI 开发框架正成为开发者的"超级武器"。它们如同智能时代的操作系统，连接着强大的 AI 模型与复杂的现实应用，让开发者能够以更高效率构建更强大的 AI 应用。

AI 开发框架就像是一个万能工具箱，它把那些复杂、底层的技术都封装好了，提供了各种现成的工具和模块。这让我们不需要从轮子开始造起，能更轻松、更快速地构建 AI 应用，把想法变成现实。框架知识为我们提供了：

架构：让我们知道代码应该组织成什么样子。

质量：让我们能判断 AI 生成的代码是否合格。

安全：框架内置的最佳实践和模式能规避许多基础风险。

集成：让我们能高效地将 AI 生成的"零件"组装到经过验证的、可靠的大系统中。

学习这些框架不仅是掌握新技术，更是一项关键的战略投资，它有以下这些好处：

提升效率，快速原型：框架提供了标准化的流程和预构建的模块，大大减少了重复编码的工作量。这意味着我们能更快地完成从概念验证到实际产品的过程。

化繁为简，解决痛点：我们以流行的 LangChain 框架为例，它就把复杂的 LLM 应用开发拆解成了几个核心模块，专门解决我们常见的难题。

强大的生态集成：好的框架（比如LangChain）已经帮我们集成了成百上千种主流工具和服务，包括不同的AI模型、数据库等。这让我们可以像搭积木一样，自由地组合和尝试不同的技术，构建更强大的应用。

思维升级：帮助开发者建立从数据到部署的全链路系统思维。

职业领先：在 AI 时代，掌握主流开发框架已成为核心竞争力。

未来展望

对于开发者来说，Vibe Coding 不会完全取代传统编程技能，而是形成互补。我们可能会看到一种新的平衡，其中开发者专注于高层次的系统设计、架构决策和业务逻辑，而将更多的实现细节委托给 AI。这种协作模式将重新定义什么是"编程技能"，从纯粹的代码编写转向有效指导和管理 AI 工具的能力。

未来的开发模式很可能是混合式开发：利用 Vibe Coding 的速度处理前端和重复性工作，同时依靠扎实的框架知识来构建核心业务逻辑、保证系统架构的健壮性和安全性。

因此，学习像 LangChain、LangGraph 这样的框架，其战略价值在 Vibe Coding 时代不降反升，是在 AI 时代驾驭更复杂项目的必备技能。

最终，"框架思维"驾驭"Vibe工具"，才是未来开发者最强的核心竞争力。

LangChain：LLM 应用开发的核心框架

LLM 驱动的应用程序的框架

由 LLM 驱动的应用程序的框架，它们的目标是提供构建复杂 LLM 应用（如带有记忆的代理、复杂的 RAG 系统、多步骤工作流）所需的全套工具。以下是按语言生态划分的主流框架：

Python 生态（绝对主流）

JavaScript/TypeScript 生态（前端与全栈）

Java 生态

C++ 生态

C++ 生态在 LLM 应用开发的全栈框架领域相对缺失，但这背后有深刻的技术、生态和商业原因，主要原因是因为 C++ 的角色定位不同：

开发效率与快速迭代的需求不匹配

LLM 应用开发目前仍处于高度实验性和快速迭代的阶段。

Python/JS：作为动态语言，具有快速原型设计的优势。开发者可以快速修改提示词、调整工作流逻辑、集成新的 API，并立即看到结果。这种快速反馈循环对于探索LLM能力至关重要。
C++：作为静态编译型语言，虽然性能极高，但编译时间长，代码修改和测试的周期也更长。这种"厚重"的开发体验与当前LLM应用需要的"敏捷"开发模式背道而驰。

生态系统的重心不同

LLM 应用开发严重依赖丰富的第三方库和服务。

Python 生态：拥有无与伦比的库支持，包括但不限于：

机器学习框架：PyTorch, TensorFlow, JAX（它们虽然底层有C++，但主要API是Python）。
数据处理：NumPy, Pandas。
Web 和 API 集成：FastAPI, Requests。
向量数据库客户端：种类繁多。
模型提供商 SDK：OpenAI, Anthropic 等官方 SDK 首选都是 Python。

C++ 生态：其传统优势领域在于系统编程、游戏开发、高频交易、嵌入式等，对于现代Web API、云服务集成等领域的库支持远不如Python丰富和易用。

3. 技术架构的天然分工（核心原因）

现代 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 就是最成功的案例，使在消费级硬件上运行大模型成为可能。

如何选择？

对于框架的选择，核心逻辑有以下几点：

团队技术栈：

优先选择团队最熟悉的语言生态，以降低开发和学习成本。

如果你所在的团队和技术栈是 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）更新最快、社区最活跃，遇到问题更容易找到解决方案，是大多数人的选择。

LangChain 介绍

复杂场景下，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：用户问："布洛芬和阿司匹林可以同时吃吗？"

问题分析：这是一个非常专业的药物相互作用问题。模型的内在知识可能不准确或不全。理想的流程是：

模型识别出这是一个需要查询专业数据库的任务 2. 调用一个权威的药物相互作用 API 3. 将 API 返回的结构化数据翻译成用户能听懂的语言。

困难：让 LLM 自发地、可靠地决定在何时、如何调用哪个外部工具，并正确解析工具返回的结果，是一个极其复杂的系统设计问题。

这个医疗助手例子集中体现了所有描述中的难题。为了解决它们，业界正在形成一整套称为 "LLM 应用工程" 的最佳实践和技术栈：

针对幻觉、提示词规范：采用 "提示词工程" 和 "检索增强生成（RAG）"。为医疗助手设计严谨、系统的提示词模板，并强制模型在回答前先从权威、实时的医疗知识库中检索信息，而不是仅凭记忆回答。
针对模型切换：使用 LLM API 抽象层（如 LangChain）。这些中间件统一了不同模型的接口，让开发者通过配置而非修改代码来切换模型。
针对非结构化输出：采用 "输出解析" 技术。强制要求模型以 JSON 等格式输出，并在提示词中严格定义 JSON 的 Schema。一些框架（如 LangChain）可以自动将模型输出解析为预定义的 Pydantic 对象。
针对知识陈旧：主要依靠 RAG 来注入实时、外部的知识。
针对连接外部工具：采用 "智能体（Agent）" 框架。让 LLM 作为大脑，根据用户请求规划步骤、选择工具（如计算器、数据库API、搜索引擎），并执行任务。

最终，一个成熟的 "智能医疗咨询助手" 不会是直接调用原生大模型，而是一个由精心设计的提示词、RAG 系统、外部工具 API、输出解析器等共同组成的复杂系统。原生大模型只是这个系统的核心引擎之一，而非全部。

LangChain：解决痛点

LangChain 可以解决上述所有问题！

LangChain 是一个用于开发由大语言模型 (LLM) 驱动的应用程序的框架。它通过将自然语言处理（NLP）流程拆解为标准化组件，让开发者能够自由组合并高效定制工作流。

组件（Components）：用来帮助当我们在构建应用程序时，提供一系列的核心构建块，例如语言模型、输出解析器、检索器等。

自然语言处理流程（NLP）：指的是完成一个特定 NLP 任务所需的一系列步骤。例如，构建一个"基于公司文档的问答机器人"的流程可能包括：读取文档、分割文本、将文本转换为向量（嵌入）、存储向量、接收用户问题、搜索相关文本段、将问题和文本段组合发送给大语言模型（LLM）、解析模型输出并返回答案等。

LangChain 的技术特点

LangChain 框架的设计精髓在于以链式（Chain）的方式整合多个组件，从而构建出功能丰富的大语言模型应用。链式表示 LangChain 允许将多个步骤或多个组件串联起来，无需各个组件各自完成其能力，而是一次性执行这个"链"上的所有流程！

举一个最简单的例子，若我们想借助提示词完成一次对于 LLM 的提问，在 LangChain 中至少需要定义两个组件：

提示词模板组件
大模型组件

使用时，我们可以：

这相当于，提示词模板组件执行了一次，大模型组件也执行了一次。而对于链式执行来说，只需执行一次链即可：

LangChain 框架提供了一系列标准化模块与接口，主要包括以下方面：

统一的模型调用：通过抽象化的接口支持多种大语言模型（例如 OpenAI GPT-4/5、Anthropic Claude 等）和嵌入模型，使开发者可以灵活切换不同模型供应商。
灵活的提示词管理：提供提示词模板（Prompt Templates），支持动态生成输入内容，并可管理少样本示例与提示选择策略，以提升模型响应质量。
可组合的任务链（Chains）：允许将多个步骤串联成完整流程，如先检索文档再生成回复，或组合多次模型调用。开发者能够通过自定义链实现复杂的任务编排。
上下文记忆机制（Memory）：用于存储多轮对话中的状态信息。LangChain 曾提供多种记忆管理方案（如对话历史记忆和摘要记忆），以实现连贯的交互体验（注：该功能目前已由 LangGraph 支持，原有实现已过时）。
检索与向量存储集成：支持从外部加载文档，经分割和向量化处理后存储至向量数据库，在查询时检索相关信息并输入大语言模型，帮助构建检索增强生成（RAG）类应用。LangChain 兼容多种主流向量数据库（如 FAISS、Pinecone、Chroma）和文档加载工具，简化知识库应用的开发流程。

对于上述技术内容，LangChain 的开源组件和第三方集成可以轻松支持快速上手，帮助我们构建应用程序。除此之外，使用 LangGraph 可以构建支持人机交互的有状态代理。LangChain 公司也在围绕框架构建完整的生态系统，包括推出 LangSmith（一个用于调试、监控和评估 LLM 应用的平台）以及 LangGraph Platform（用于 LangChain 应用的部署、运维）等，为开发者提供从开发到生产的一站式支持。

LangGraph：面向复杂工作流的图式架构

LangGraph 介绍

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 语句来调用不同的子链。

结果：流程图的逻辑变成了代码中的控制流语句，而不是清晰可见的图形化结构。这使得工作流难以设计、调试和可视化。

LangGraph：解决痛点

为了解决这些问题，LangChain 团队于 2024 年推出了 LangGraph 框架，旨在提供一种图结构的、状态化的方式来构建复杂的 AI 代理应用。

LangChain 团队将 LangGraph 定位为"低层次的编排框架"，用于构建可控、可靠的 AI 代理工作流。目前，LangGraph 已经在一些生产环境中得到应用，例如 LinkedIn、Uber、GitLab 等公司据报道使用 LangGraph 来构建复杂的生成式 AI 代理系统。

例如，我们将上述链式示例改为图结构：

在上述示例中，我们可以定义图状态，用于存储流程中的临时数据和决策点，例如：

intent : 用户意图（字符串，如 "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 提供了更强大的支持

LangGraph 的技术特点

LangGraph 将应用逻辑建模为图（Graph）结构，其中：

节点：表示操作或状态

边：表示节点之间的转移和数据流。

这种图式架构相比 LangChain 的链式结构更加灵活，主要体现在：

循环与分支：LangGraph 中的节点（Node）可以连接到其他任何节点，包括自己。你可以轻松设置一个"信息收集"节点，如果信息不完整，就让流程再次循环回这个节点本身，直到条件满足为止。
动态路由：通过条件边，可以根据当前状态的值，动态决定下一个要执行的节点。例如，在"分类"节点之后，可以根据分类结果，自动路由到"处理退货"、"处理咨询"或"处理投诉"等完全不同的子图中去。
状态维护：LangGraph 有一个核心的状态对象，在整个图的执行过程中自动持久化和传递。每个节点都可以读取和修改这个状态。这意味着用户的对话历史、已收集的信息都会自动保留，轻松支持长时间运行的任务。
持久执行：构建能够经受住故障并能长时间运行的代理，自动从上次中断的地方恢复。
人机协作：通过在执行过程中的任何时刻检查和修改代理状态，无缝融入人工监督。
全面记忆：创建真正具有状态的代理，兼具用于持续推理的短期工作记忆和跨会话的长期持久记忆。
使用 LangSmith 进行调试：借助可视化工具深入洞察复杂代理行为，这些工具可追踪执行路径、捕获状态转换并提供详细的运行时指标。
生产级部署：借助专为处理有状态、长时间运行工作流的独特挑战而设计的可扩展基础设施，自信地部署复杂的代理系统。

总结来说，构建 AI 代理应用时，如果用传统链式结构构建，会变成一个僵硬、脆弱、难以维护的"面条代码"。而 LangGraph 则能将其建模为一个灵活、可靠、可视化程度高、且支持复杂逻辑（循环、分支、人工）的工作流图，这正是它为了解决日益复杂的 LLM 应用而诞生的价值所在。