LangChainAI应用开发框架【LangChain与LangGraph介绍】

🔥承渊政道： 个人主页
❄️个人专栏: 《C语言基础语法知识》《数据结构与算法》《C++知识内容》《Linux系统与网络知识》《算法刷题指南》《测评文章活动推广》《大模型语言路线学习》《MySQL数据库学习》《Python知识内容》《cpolar知识学习》《LangChainAI应用开发框架》《QT、Redis、CMake、Docker、测试、运维》《实战项目开发》
✨逆境不吐心中苦,顺境不忘来时路!✨ 🎬 博主简介:

随着人工智能技术的不断发展,AI已经不再只是一个简单的聊天工具,而是逐渐成为开发者编写代码、处理数据和构建智能应用的重要助手.如今,我们不仅可以通过AI快速生成代码,还可以将大模型的能力接入自己的项目,让应用具备智能问答、文档分析、工具调用等功能.不过,如果想开发一个真正实用的AI应用,仅仅能够调用大模型还远远不够. 例如,当我们希望 AI 能够查询外部数据、调用不同工具,甚至按照指定步骤完成一项复杂任务时,就需要一种更方便的方式来组织和管理这些功能.这时候,LangChain 和 LangGraph 就派上了用场. 简单来说,LangChain 可以理解为一套帮助开发者连接和使用大模型的工具,而 LangGraph 则更擅长管理复杂任务的执行流程. 前者让我们能够方便地组合大模型、工具和数据,后者则可以帮助我们控制任务的执行顺序、判断条件以及处理需要反复执行的操作.两者相互配合,可以让AI应用的开发更加灵活、高效.因此,本文作为 LangChainAI 应用开发系列的框架介绍篇 ,将从AI时代编程方式的变化入手,带大家认识LangChain和LangGraph,了解它们各自的作用、核心特点、适用场景以及两者之间的区别与联系.同时,也会介绍后续的学习路线,帮助大家对整个框架建立一个清晰的认识.通过本篇文章,希望能够帮助大家从"会调用大模型",逐步过渡到"理解如何利用框架开发 AI 应用",为后续深入学习 LangChain、LangGraph 以及构建自己的智能应用打下基础.

一、AI时代下的编程范式
- [1.1Vibe Coding的起源](#1.1Vibe Coding的起源)
- [1.2Vibe Coding的局限性](#1.2Vibe Coding的局限性)
- 1.3AI开发框架:新战略⾼地？
- - (1)框架原则
  - (2)超级武器
- 1.4未来展望
二、LangChain:LLM应⽤开发的核⼼框架
- 2.1LLM驱动的应⽤程序的框架
- - (1)Python⽣态(绝对主流)
  - [(2)JavaScript/TypeScript ⽣态(前端与全栈)](#(2)JavaScript/TypeScript ⽣态(前端与全栈))
  - (3)Java⽣态
  - (4)C++⽣态
  - (5)对于框架如何选择?
- 2.2LangChain介绍
三、LangGraph:⾯向复杂⼯作流的图式架构

一、AI时代下的编程范式

1.1Vibe Coding的起源

在过去⼗年间,低代码/⽆代码平台和AI代码助⼿持续冲击着软件开发⾏业.如今,⼀种被称为 VibeCoding 的新兴实践突然⾛红,甚⾄颠覆了⼈们对 "程序员到底在做什么" 的认知.

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能直接写代码,我们还有必要花费精⼒去学习复杂的开发框架吗？

1.2Vibe Coding的局限性

尽管Vibe Coding以其惊⼈的速度和低⻔槛带来了⾰命性的开发体验,但它并不能完全取代传统的框架开发.使⽤过它们⼈可能会发现,它们⽣成的代码往往只是"能⽤"⽽⾮"优秀".

主要体现在以下⼏个⽅⾯：

代码质量与架构的"⿊箱"困境：AI的⽬标是⽣成功能上可运⾏的代码,但它⽆法理解什么是"优雅"、"可维护"、"可扩展"的代码架构.
上下⽂⻓度的"⾦⻥记忆"与知识滞后性：有限的上下⽂窗⼝：即使上下⽂⻓度在不断增⻓,LLM 也⽆法记住并理解⼀个庞⼤项⽬的全部代码.在开发过程中,后期的⼀个需求可能需要修改前期⽣成的代码.AI 由于"忘记"了之前的完整上下⽂,很可能会⽣成与现有架构冲突或重复的代码,导致系统腐化.知识截⽌与"幻觉"：LLM的训练数据有截⽌⽇期,它可能⽆法使⽤最新的语⾔特性、库版本或最佳实践.更危险的是,它可能会"幻觉"出⼀些不存在的 API、库函数或参数,⽣成看似正确实则⽆法运⾏的代码,这对开发者甄别能⼒提出了极⾼要求.
安全性与可靠性的"隐形地雷"：这是Vibe Coding在企业级应⽤中最致命的弱点.安全漏洞的⽆声引⼊:AI没有 "安全" 意识.它可能会轻松地⽣成含有SQL 注⼊、XSS 攻击、硬编码密码、不当的权限设置等安全漏洞的代码.对于安全⾄关重要的系统(如⾦融、医疗),这是⼀个不可接受的⻛险.可靠性难以保障：⽣成的代码缺乏经过严格测试的可靠性.它可能在⼩规模数据下运⾏良好,但在⾼并发、⼤数据量或边缘案例下表现不稳定甚⾄崩溃.缺乏完善的⽇志、监控和熔断机制,使得线上排查问题变得极其困难.

可以看到,Vibe Coding不是⼀个替代品,⽽是⼀个强⼤的效率倍增器.它的正确定位是：

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

实际上,⽬前真正跑在⽣产线上的代码,依旧是⼯程师⼀个函数⼀个函数敲出来的.但像是改函数签名、重命名变量、写⼀个测试⽤例、⼩的Demo、⼯具等这些"接地⽓"的⼯程活,恰恰是AI最佳的⽤武之地.

因此,在同年8⽉底,Karpathy改变了⼝径,他发⽂表示： "不要幻想有⼀个万能的 AI ⼯具能解

决所有编程问题,更可⾏的做法是建⽴⼀个结构,让不同的⼯具在不同场景各司其职,像接⼒赛⼀样完成开发任务" .

1.3AI开发框架:新战略⾼地？

我们正站在⼈⼯智能⾰命的中⼼.⼤语⾔模型(LLM)如ChatGPT的崛起,不仅改变了⼈机交互的⽅式,更彻底重塑了软件开发的游戏规则.如今,构建⼀个AI应⽤早已不再是简单地调⽤API,⽽是需要应对数据处理、模型交互、任务编排和状态管理等复杂挑战.

即使AI代码⽣成⼯具(Vibe Coding)⽇益强⼤,但它们⽣成的代码往往只是"能⽤"⽽⾮"优秀".真正的专业开发者需要理解架构设计、系统权衡与⼯程最佳实践⸺这正是框架学习的核⼼价值.

(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)超级武器

在这场AI时代的变⾰中,如LangChain、LangGraph这样的AI开发框架正成为开发者的"超级武

器".它们如同智能时代的操作系统,连接着强⼤的 AI 模型与复杂的现实应⽤,让开发者能够以更⾼效率构建更强⼤的AI应⽤.

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

• 架构：让我们知道代码应该组织成什么样⼦.

• 质量：让我们能判断 AI ⽣成的代码是否合格.

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

• 集成：让我们能⾼效地将 AI ⽣成的"零件"组装到经过验证的、可靠的⼤系统中.

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

• 提升效率,快速原型：框架提供了标准化的流程和预构建的模块,⼤大减少了重复编码的⼯作

量.这意味着我们能更快地完成从概念验证到实际产品的过程.

• 化繁为简,解决痛点：我们以流⾏的LangChain框架为例,它就把复杂的 LLM 应⽤开发拆解成

了⼏个核⼼模块,专⻔解决我们常⻅的难题.

• 强⼤的⽣态集成：好的框架(⽐如LangChain)已经帮我们集成了成百上千种主流⼯具和服务,包括不同的AI模型、数据库等.这让我们可以像搭积⽊⼀样,⾃由地组合和尝试不同的技术,构建更强⼤的应⽤.

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

• 职业领先：在AI时代,掌握主流开发框架已成为核⼼竞争⼒.

1.4未来展望

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

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

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

最终,"框架思维"驾驭"Vibe⼯具",才是未来开发者最强的核⼼竞争⼒.尽管有⼈担忧 AI 会取代程序员,但更可能的情况是,那些能够有效使⽤ AI ⼯具的开发者将取代那些不能的开发者.正如历史上其他技术变⾰⼀样,新⼯具不会消除对专业⼈才的需求,⽽是改变了对他们的技能要求.

二、LangChain:LLM应⽤开发的核⼼框架

2.1LLM驱动的应⽤程序的框架

由LLM驱动的应⽤程序的框架,它们的⽬标是提供构建复杂LLM应⽤(如带有记忆的代理、复杂的RAG 系统、多步骤⼯作流)所需的全套⼯具.以下是按语⾔⽣态划分的主流框架.

(1)Python⽣态(绝对主流)

框架	核心特点与优势	适用场景
LangChain	生态最丰富，灵活性极高。提供了最全面的组件（链、代理、检索器等），社区活跃，集成工具众多（大量向量数据库、模型提供商）。	几乎任何复杂的 LLM 应用，尤其是需要高度定制化和集成第三方工具的场景。是大多数项目的首选。
LlamaIndex	专注于 RAG 和数据连接。在文档索引、查询、检索方面性能优异，提供了从简单到高级的多种检索策略。现已扩展为全功能框架。	以查询和分析私有数据为核心的应用，如企业知识库、文档智能问答、数据增强的聊天机器人。

(2)JavaScript/TypeScript ⽣态(前端与全栈)

框架	核心特点与优势	适用场景
LangChain.js	Python LangChain 的官方 JS/TS 移植版本。API 与 Python 版高度相似，支持大多数核心功能（链、代理、工具）。	全栈开发、浏览器扩展、Edge Runtime（如 Vercel Edge Functions）、Next.js 等现代 Web 框架的集成。
LlamaIndex.TS	LlamaIndex 的 TypeScript 版本，专注于 TS 生态中的 RAG 应用。	在 Next.js、Nuxt 等全栈框架中构建强大的 RAG 应用。

(3)Java⽣态

框架	核心特点与优势	适用场景
LangChain4j	一个受 LangChain 启发为 JVM 设计的框架。API 设计符合 Java 习惯。注意它不是 LangChain 团队开发的，是一个社区项目。	需要将 LLM 能力集成到现有 Java 企业应用中的场景，如微服务、大型后端系统。
Spring AI	Spring 官方项目，与 Spring 生态无缝集成。提供统一的 API 和数据抽象，生产就绪特性强。	所有基于 Spring Boot 的项目，尤其是企业级生产系统，追求稳定性和框架原生集成。
Spring AI Alibaba	Spring AI 的扩展项目，由阿里云官方支持。核心优势在于对阿里云灵积模型服务平台（及通义千问等模型）的深度集成和优化。它提供了开箱即用的配置，方便 Java 开发者以 Spring 的方式便捷、安全地调用阿里云的各种大模型。	深度依赖阿里云生态和服务的 Spring 项目。当需要直接、高效地使用通义千问系列模型、在阿里云 VPC 内网访问模型服务以获取更低延迟和成本，或者需要与阿里云的其它云服务（如 OSS、NAS）结合时，这是最自然和推荐的选择。

(4)C++⽣态

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

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

LLM 应⽤开发⽬前仍处于⾼度实验性和快速迭代的阶段.

• Python/JS：作为动态语⾔,具有快速原型设计的优势.开发者可以快速修改提示词、调整⼯作流逻辑、集成新的API,并⽴即看到结果.这种快速反馈循环对于探索LLM能⼒⾄关重要.

• C++：作为静态编译型语⾔,虽然性能极⾼,但编译时间⻓,代码修改和测试的周期也更⻓.这

种"厚重"的开发体验与当前LLM应⽤需要的"敏捷"开发模式背道⽽驰.

2.⽣态系统的重⼼不同

LLM 应⽤开发严重依赖丰富的第三⽅库和服务.

• Python ⽣态：拥有⽆与伦⽐的库⽀持,包括但不限于：

◦ 机器学习框架：PyTorch, TensorFlow, JAX(它们虽然底层有C++,但主要API是Python).

◦ 数据处理：NumPy, Pandas.

◦ Web 和 API 集成：FastAPI, Requests。

◦ 向量数据库客⼾端：种类繁多.

◦ 模型提供商 SDK：OpenAI, Anthropic等官⽅SDK⾸选都是Python.

• C++ ⽣态：其传统优势领域在于系统编程、游戏开发、⾼频交易、嵌⼊式等,对于现代WebAPI、云服务集成等领域的库⽀持远不如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就是最成功

的案例,使在消费级硬件上运⾏⼤模型成为可能.

(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.2LangChain介绍

(1)复杂场景下,LLM嵌⼊应⽤的问题？

使⽤过⼀些原⽣⼤模型的⼈可能会发现⼀些问题,尽管⼤模型的在某些⽅⾯表现振奋⼈⼼,例如将其当作搜索引擎去使⽤,LLM⽣成的答案可能要⽐其他搜索引擎查到的答案更符合你的预期,但要是在复杂的场景下使⽤,如将LLM嵌⼊应⽤程序时却遭遇了全新难题.

举个例⼦,我们要开发⼀个智能医疗咨询助⼿,⽤户可以向其描述症状(例如："我最近头痛、发

烧,还有些咳嗽"),助⼿能提供初步的疾病可能性分析、建议的⽇常护理⽅法,并提醒是否需要⽴

即就医.

场景1：⽤户想咨询"我三岁的孩⼦吞下了⼀枚纽扣电池,该怎么办？"

问题分析：这个建议是完全错误且致命的.纽扣电池会卡在⻝道并快速泄漏化学物质,灼烧内脏,必须⽴即送医.模型基于训练数据中的"吞⻝异物"相关⽂本进⾏了错误⽣成,产⽣了"幻觉"。在⽣产环境中,这种错误是⽆法接受的.

场景2：开发团队需要为"疾病诊断"、"药物咨询"、"急救建议"等不同功能编写提示词.

问题分析：提示词的质量和⻛格直接决定输出结果的准确性和安全性.没有统⼀的规范会导致应⽤⾏为不可预测、难以调试，且⽆法规模化地优化效果.

场景3：项⽬开始时使⽤GPT-3.5Turbo进⾏原型开发,成本较低.后期为了提升准确性,希望切

换到更强⼤的GPT-5或开源模型如Llama3.

问题分析：发现切换成本极⾼.这意味着⼀旦选定⼀个模型,整个应⽤程序的代码就与该模型的 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)LangChain:解决痛点

LangChain是⼀个⽤于开发由⼤语⾔模型(LLM)驱动的应⽤程序的框架.它通过将⾃然语⾔处理(NLP)流程拆解为标准化组件,让开发者能够⾃由组合并⾼效定制⼯作流.

(3)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:⾯向复杂⼯作流的图式架构

3.1LangGraph介绍

(1)LangGraph的局限性

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 语句来调⽤不同的⼦链.结果：流程图的逻辑变成了代码中的控制流语句,⽽不是清晰可⻅的图形化结构.这使得⼯作流难以设计、调试和可视化.

(2)LangGraph:解决痛点

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

LangChain 团队将 LangGraph 定位为"低层次的编排框架",⽤于构建可控、可靠的 AI 代理⼯作流.⽬前,LangGraph已经在⼀些⽣产环境中得到应⽤,例如 LinkedIn、Uber、GitLab等公司据报道使⽤LangGraph来构建复杂的⽣成式AI代理系统.例如,我们将上述链式示例改为图结构：

在上述示例中,我们可以定义图状态,⽤于存储流程中的临时数据和决策点.LangGraph并不是要取代LangChain,⽽是对LangChain的扩展和补充.LangGraph底层⼤量复⽤了LangChain的组件(如模型接⼝、⼯具、记忆等),开发者可以在LangGraph的节点中直接使⽤LangChain 的链或代理作为⼦流程.因此,LangGraph与LangChain是互补关系：对于简单的线性任务,LangChain 的链式结构已经⾜够⾼效.⽽对于需要复杂控制流、⻓期状态和多智能体的场景,LangGraph提供了更强⼤的⽀持.

(3)LangGraph的技术特点

LangGraph将应⽤逻辑建模为图(Graph)结构,其中：节点,表示操作或状态.边:表示节点之间的转移和数据流.

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

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

总结来说,构建AI代理应⽤时,如果⽤传统链式结构构建,会变成⼀个僵硬、脆弱、难以维护的"⾯条代码".⽽LangGraph则能将其建模为⼀个灵活、可靠、可视化程度⾼、且⽀持复杂逻辑(循环、分⽀、⼈⼯)的⼯作流图,这正是它为了解决⽇益复杂的LLM应⽤⽽诞⽣的价值所在.

3.2起源与发展

LangChain 团队于2024年推出了LangGraph框架,旨在提供⼀种图结构的、状态化的⽅式来构建复杂的AI代理应⽤.

LangGraph最初作为LangChain 0.1.0 版本的⼀部分被引⼊,标志着LangChain从链式架构向图式架构的扩展.

在 2024 年初,LangGraph 作为实验性功能发布,随后在 2024 年中开始独⽴演进.LangChain团队为LangGraph建⽴了专⻔的⽂档和代码仓库,并逐步将其打造为⼀个独⽴于LangChain主框架的⼯具集.在2024年中发布的版本中,LangGraph引⼊了Checkpoint(检查点)机制,允许将执⾏状态定期保存,以便故障恢复和审计.

2024 年下半年,LangGraph 发布了多个版本(如 0.2.x、0.3.x 等),不断改进其核⼼功能和稳定性.

2024 年底的版本增强了对异步执⾏和并发的⽀持,并提供了更完善的类型定义和错误处理.

2025 年,LangGraph发布了0.4.x、0.5.x 等版本,发展出完善的Python和JavaScript实现,并推出了LangGraph Platform等配套产品,⽤于简化复杂代理应⽤的部署和管理.

2025年6⽉,LangGraph发布了0.6版本,并启动了LangGraph v1.0的路线图计划,收集社区反馈

以确定正式版的功能特性.

可以预⻅,LangGraph 将在未来继续演进,成为构建⾼级 AI 代理和复杂⼯作流的重要框架.

版本发布：https://github.com/langchain-ai/langgraph/releases

🚀真正的勇者不是流泪的人,而是含泪奔跑的人!

敬请期待下一篇文章内容

每日心灵鸡汤: 生活是自己的,不必活给别人看!

人生最好的状态,不是拥有多少财富,也不是得到多少掌声,而是内心安定,活得自在.不要总是羡慕别人的生活,你看到的光鲜背后,也许藏着不为人知的辛酸.每个人都有自己的节奏,有人年少成名,有人大器晚成.走得快不一定赢,走得稳才能走得远.余生最重要的事,就是把日子过成自己喜欢的模样.不为过去遗憾,不为未来焦虑.珍惜眼前的幸福,善待努力的自己.愿你不慌不忙,不卑不亢,心有所向,步履从容.早安!新的一天,愿你心有阳光,所遇皆温暖.