📃个人主页：island1314

⛺️ 欢迎关注：👍点赞 👂🏽留言 😍收藏 💞 💞 💞

• 生活总是不会一帆风顺，前进的道路也不会永远一马平川，如何面对挫折影响人生走向 – 《人民日报》

---

---

一、 AI 时代下的编程范式

1. 谈谈 Vibe Coding

1.1 背景

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

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

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

其关键特征在于：用户通常在不完全理解代码底层机制的情况下接受AI生成的代码。

实际上，这与仅仅将LLM作为代码输入的辅助工具不同，Vibe Coding 仍然需要开发者审查、测试和理解每一行代码。Vibe Coding 的本质是完全沉浸于 AI 助手的 “氛围” 中，将详细的实现过程外包给 Al。正如Karpathy最初所描述的那样：“这不算真正的编程-- 我只是看看东西，说说东西，运行东西，然后复制粘贴东西，而且它大多都能工作”。

Vibe Coding标志着软件开发模式的根本转变：从细致的手动编码，转向更抽象、意图驱动的方法，人类开发者在此过程中扮演着指导AI的角色。

因此，Vibe Coding的出现对开发者的技能要求产生了显著的影响，并正在改变传统的软件开发方法:

1. 开发者需要更加注重问题定义和规范，清晰地使用自然语言表达需求和期望的结果。确定最佳的提问方式变得至关重要。
2. 同时，开发者需要具备指导和审查AI生成代码的能力，评估、完善和测试AI产出的代码。开发者更像是扮演指导者或编辑的角色。
3. 系统设计和架构的理解变得比低层次的编码更为重要。批判性思维和问题解决能力对于评估和改进AI生成的代码至关重要。
4. 此外，开发者需要学习如何有效地与AI沟通，掌握提示技巧以获得期望的结果。虽然侧重点有所变化，但对编程基本原理的理解对于有效地指导AI和进行调试仍然很有价值。

可以看到，清晰地定义问题和指导AI的能力变得至关重要。此外，AI的输出需要验证，这需要批判性思维和对软件架构的理解。这表明开发者正在从"代码编写者" 转变为更像是能够有效利用AI的 “软件架构师” 或 “产品负责人”

2025年，Vibe Coding 的开发方式发展得迅速且火热。从 Cursor、Trae、Claude Coding,各大厂商纷纷入局，无数自媒体鼓吹开发无用论，这引发了一个普遍的疑问:既然AI能直接写代码，我们还有必要花费精力去学习复杂的开发框架吗?

1.2 局限性

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

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

1. 代码质量与架构的“黑箱”困境
   AI的目标是生成功能上可运行的代码，但它无法理解什么是“优雅”、“可维护”、“可扩展”的代码架构。
2. 上下文长度的“金鱼记忆”与知识滞后性
   • 有限的上下文窗口：即使上下文长度在不断增长，LLM也无法记住并理解一个庞大项目的全部代码。在开发过程中，后期的一个需求可能需要修改前期生成的代码。AI由于“忘记”了之前的完整上下文，很可能会生成与现有架构冲突或重复的代码，导致系统腐化。
   • 知识截止与“幻觉”：LLM的训练数据有截止日期，它可能无法使用最新的语言特性、库版本或最佳实践。更危险的是，它可能会“幻觉”出一些不存在的API、库函数或参数，生成看似正确实则无法运行的代码，这对开发者甄别能力提出了极高要求。
3. 安全性与可靠性的“隐形地雷”
   这是Vibe Coding在企业级应用中最致命的弱点。安全漏洞的无声引入:AI没有“安全”意识。它可能会轻松地生成含有SQL注入、XSS攻击、硬编码密码、不当的权限设置等安全漏洞的代码。对于安全至关重要的系统(如金融、医疗)，这是一个不可接受的风险。

可以看到，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。开发者不需要手动管理对象生命周期或处理繁琐的ServletAPI。
• libcurl：封装了网络协议的复杂性(HTTP, FTP,SMTP等)。开发者不需要使用底层的socketAPI来手动构建HTTP请求。

② 模块化与可组装性

• Spring：通过其强大的依赖注入(DI)和控制反转(loC)容器，将应用程序组织成高度可插拔的Bean(@Component，@Service)。你可以轻松替换数据库实现或服务实现。
• LangChain：核心概念就是"链" (Chain)，它将不同的模块(LLM, Prompts, Tools, Memory,Output Parsers)像乐高积木一样组合起来，构建复杂的AI工作流。

2.2 超级武器

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

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

框架知识为我们提供了:

• 架构：让我们知道代码应该组织成什么样子。
• 质量：让我们能判断AI生成的代码是否合格。
• 安全：框架内置的最佳实践和模式能规避许多基础风险。
• 集成：让我们能高效地将AI生成的“零件”组装到经过验证的、可靠的大系统中。

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

• 提升效率，快速原型：框架提供了标准化的流程和预构建的模块，大大减少了重复编码的工作量。这意味着我们能更快地完成从概念验证到实际产品的过程。
• 化繁为简，解决痛点：我们以流行的LangChain框架为例，它就把复杂的LLM应用开发拆解成了几个核心模块，专门解决我们常见的难题。
• 强大的生态集成：好的框架(比如LangChain)已经帮我们集成了成百上千种主流工具和服务，包括不同的AI模型、数据库等。这让我们可以像搭积木一样，自由地组合和尝试不同的技术，构建更强大的应用。
• 思维升级：帮助开发者建立从数据到部署的全链路系统思维。
• 职业领先：在AI时代，掌握主流开发框架已成为核心竞争力。

3. 未来展望

对于开发者来说，VibeCoding不会完全取代传统编程技能，而是形成互补。我们可能会看到一种新的平衡，其中开发者专注于高层次的系统设计、架构决策和业务逻辑，而将更多的实现细节委托给Al。这种协作模式将重新定义什么是"编程技能"，从纯粹的代码编写转向有效指导和管理AI工具的能力。未来的开发模式很可能是混合式开发:利用Vibe Coding的速度处理前端和重复性工作，同时依靠扎实的框架知识来构建核心业务逻辑、保证系统架构的健壮性和安全性。

因此，学习像LangChain、LangGraph这样的框架，其战略价值在Vibe Coding时代不降反升，是在AI时代驾驭更复杂项目的必备技能。
最终，“框架思维”驾驭“Vibe工具”，才是未来开发者最强的核心竞争力。

尽管有人担忧AI会取代程序员，但更可能的情况是，那些能够有效使用AI工具的开发者将取代那些不能的开发者。正如历史上其他技术变革一样，新工具不会消除对专业人才的需求，而是改变了对他们的技能要求。

二、LangChain

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

我们之前说过大模型的调用方式有 3 种，而 Gemini、ChatGPT、DS 都采用统一的接入方式，但是 调用的参数、路径都不相同。如果再一个系统里，想要接入多个大模型，需要接入多次。如果要切换模型，很不方便。

向量 [0.3 0.2 …] 是要存在向量数据库中的 LangChain 也封装了底层的复杂向量数据库的接入方式。

1. LLM 驱动的应用程序框架

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

以下是按语言生态划分的主流框架：

① Python 生态（绝对主流）

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

② 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 应用。

③ 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）结合时，这是最自然和推荐的选择。

④ 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、Requestso
     • 向量数据库客户端：种类繁多。
     • 模型提供商SDK：OpenAl、Anthropic等官方SDK首选都是Python。
   • C++生态：其传统优势领域在于系统编程、游戏开发、高频交易、嵌入式等，对于现代WebAPI、云服务集成等领域的库支持远不如Python丰富和易用。

3. 技术架构的天然分工(核心原因)
   现代LLM应用架构普遍采用“Python/JAVA负责应用层(做什么)，C++负责底层推理(怎么做)”的分工模式。

   一个完美的例子是 llama.cpp （官网：https://github.com/ggerganov/llama.cpp）：

   • 它本身是一个用C/C++编写的热门项目，用于高效推理LLaMA系列及众多其他架构的模型。它以其出色的性能和极低的内存需求(通过量化）而闻名。
   • 你可以将几lama.cpp作为库链接到你的C++应用程序中，从而在本地直接运行模型。我们可以自行提供的 server功能，启动一个HTTPAPI服务。
   • 然后，上层的Python或JavaScript应用通过调用这个API来使用它，从而结合了C++的推理性能和Python的应用开发效率。

虽然缺少“全栈框架”，但可以看到C++在LLM技术栈中是不可或缺的基石，llama.cpp 就是最成功的案例，使在消费级硬件上运行大模型成为可能。

如何选择？

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

1. 团队技术栈:
   • 优先选择团队最熟悉的语言生态，以降低开发和学习成本。
   • 如果你所在的团队和技术栈是Java，想快速为企业应用添加AI功能，LangChain4j和SpringAI是绝佳的选择。
   • 如果你的需求是极致性能、离线运行或在资源受限的环境(如手机、嵌入式设备)中部署模型，那么C++生态的 llama.cpp 是你的不二之选。
   • 在大多数情况下，一个混合架构也很常见:例如，用C++实现高性能推理引擎，然后用Java或 Python构建业务层和API接口。
2. 项目需求：
   • 如果项目是研究性质或需要最大灵活性，Python(LangChain)是不二之选。
   • 如果项目是以RAG为核心，Llamalndex(Python/TS)提供了更专业的工具。
   • 如果项目需要深度集成到现有企业级后端(如Spring应用)，则选择对应的SpringAl
   • 如果项目是面向Web的全栈应用或边缘函数，LangChain.js是最佳选择。
3. 社区与支持:
   • Python和JS生态的框架(LangChain)更新最快、社区最活跃，遇到问题更容易找到解决方案，是大多数人的选择。

2. LangChain 介绍

2.1 LangChain 是什么？

简单来说，LangChain 是一个用于开发由语言模型驱动的应用程序的框架。

在大模型出现之前，应用开发主要是“确定性”的（输入 A 必然得到输出 B）。而大模型是“概率性”的，且存在幻觉、上下文限制、无法访问私有数据等问题。LangChain 的核心价值在于将 LLM 与其他组件（数据、工具、记忆）连接起来，使开发者能够构建复杂、可靠的应用。

它的口号是：“Chain thought together”（将思维链接起来）。

2.2 核心组件与概念

LangChain 的架构设计非常模块化，主要包含以下几个核心概念：

• Models (模型层):
  • 提供了统一的接口来调用不同的 LLM（如 OpenAI, Anthropic, 本地 Llama 等）。
  • 分为 LLM (纯文本补全) 和 Chat Model (聊天对话，支持 System/User/AI 角色)。
• Prompts (提示词管理):
  • 提供模板化、动态管理 Prompt 的工具。解决了硬编码 Prompt 难以维护的问题。
• Chains (链):
  • 这是 LangChain 名字的由来。它将多个组件串联起来。例如：输入 -> Prompt 模板 -> LLM -> 输出解析器。
  • 简单的链可以是顺序执行，复杂的链可以包含逻辑判断。
• Agents (智能体):
  • 这是 LangChain 最强大的功能之一。Agent 允许 LLM 自主决定使用什么工具（如搜索 Google、查询数据库、运行代码）来完成任务。
  • 核心逻辑：LLM 思考 -> 选择工具 -> 执行工具 -> 观察结果 -> 循环直到完成任务。
• Memory (记忆):
  • 让无状态的 LLM 拥有“短期”或“长期”记忆。例如在对话中保留历史聊天记录，或者将关键信息存入向量数据库。
• Indexes & Retrievers (索引与检索 / RAG 核心):
  • 这是构建知识库问答的基础。
  • 流程：文档加载 (Document Loaders) -> 文本分割 (Text Splitters) -> 嵌入 (Embeddings) -> 向量存储 (Vector Stores) -> 检索 (Retrievers)。
  • 实现了 RAG (检索增强生成)，让 LLM 能回答私有数据的问题。

2.3 为什么它如此流行？

1. 抽象与解耦： 它屏蔽了不同 LLM 提供商 API 的差异。你想从 GPT-4 切换到 Claude 3，通常只需改一行代码。
2. 丰富的集成： 它支持数百种向量数据库（Pinecone, Milvus, Chroma）、工具（Google Search, WolframAlpha）和文档加载器。
3. 快速原型开发： 对于想验证想法的开发者，LangChain 能用极少的代码跑通一个 RAG 或 Agent 流程。
4. 社区生态： 遇到问题容易找到教程、解决方案和现成的 Chain 模板。

3. 争议、挑战与批评

随着 LangChain 的成熟，社区对它的批评也日益增多，主要集中在以下几点：

• 过度抽象 (Leaky Abstractions)： LangChain 封装了很多层，当出错时，调试非常困难。你往往不知道是框架的问题还是模型的问题。
• 复杂性膨胀： 为了支持所有功能，代码库变得极其庞大。简单的任务（如调用一个 API）在 LangChain 里可能变得比直接写 requests 更复杂。
• 版本不稳定： 早期版本迭代极快，API 经常破坏性更新（Breaking Changes），导致旧教程代码无法运行。
  • 注：近期 LangChain 进行了重构，将包拆分为 langchain-core, langchain-community, langchain-openai 等，以缓解依赖问题。
• “杀鸡用牛刀”： 对于简单的 LLM 调用，引入 LangChain 可能增加了不必要的依赖和延迟。很多资深开发者建议：如果逻辑简单，直接调 API 更好。

3.1 LLM 六大问题

复杂场景下，LLM 嵌入应用面对问题？

使用过一些原生大模型的人可能会发现一些问题，尽管大模型的在某些方面表现振奋人心，例如将其当作搜索引擎去使用，LLM生成的答案可能要比其他搜索引擎查到的答案更符合你的预期，但要是在复杂的场景下使用，如将LLM嵌入应用程序时却遭遇了全新难题:

1. 幻觉问题：简单提示词(Prompt)得到的答案经常出现幻觉?
2. 统一提示词：提示词结构是否可以统一规范?
3. 切换模型：如何实现开发过程中大模型的轻松、灵活切换?
4. 大模型输出是非结构化的，怎样与要求结构化数据的程序接口交互?
5. 无法获得实时信息：如何克服预训练模型知识陈旧的问题，引入实时更新?
6. 针对非常专业知识，只能参考 LLM 结果：如何连接模型与外部工具或系统，执行具体任务?

举个例子，我们要开发一个智能医疗咨询助手，用户可以向其描述症状(例如:“我最近头痛、发烧，还有些咳嗽”)，助手能提供初步的疾病可能性分析、建议的日常护理方法，并提醒是否需要立即就医。

场景1：用户想咨询“我三岁的孩子吞下了一枚纽扣电池，该怎么办?

问题分析：这个建议是完全错误且致命的。纽扣电池会卡在食道并快速泄漏化学物质，灼烧内脏，必须立即送医。模型基于训练数据中的“吞食异物”相关文本进行了错误生成，产生了“幻觉”。在生产环境中，这种错误是无法接受的。

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

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

场景3：项目开始时使用GPT-3.5Turbo进行原型开发，成本较低。后期为了提升准确性，希望切换到更强大的GPT-5或开源模型如Llama3。

问题分析：发现切换成本极高。这意味着一旦选定一个模型，整个应用程序的代码就与该模型的API强耦合。切换模型几乎等于重写所有与LLM交互的代码，严重阻碍了技术选型的灵活性。

场景4：非结构化输出难以与程序接口交互。应用程序需要将模型分析的“可能疾病”结果，结构化地展示在前端UI的列表里。

问题分析：程序无法直接解析这段自然语言文本来提取“疾病名称”和“可信度”。必须编写复杂且脆弱的正则表达式或再用一个模型来解析第一个模型的输出，极大增加了复杂度和出错概率。

场景5：用户询问：“针对奥密克戎XBB.1.5变种，最新的加强针效果如何？

问题分析：主流大模型的训练数据截止于某个特定时间点(例如2024年初)。对于2024年下半年或以后的最新疫苗研究和变异株情况，它一无所知，要么拒绝回答，要么基于过时信息给出错误答案。医疗信息的实时性至关重要，模型的滞后性是巨大缺陷。

场景6：用户问：“布洛芬和阿司匹林可以同时吃吗?"

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

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

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

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

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

LangChain 可以解决上述所有问题

3.2 解决痛点

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

• 组件(Components)：用来帮助当我们在构建应用程序时，提供一系列的核心构建块，例如语言模型、输出解析器、检索器等。
• 自然语言处理流程(NLP)：指的是完成一个特定NLP任务所需的一系列步骤。例如，构建一个 “基于公司文档的问答机器人” 的流程可能包括：读取文档、分割文本、将文本转换为向量(嵌入)、存储向量、接收用户问题、搜索相关文本段、将问题和文本段组合发送给大语言模型(LLM)、解析模型输出并返回答案等。

3.3 技术特点

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

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

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

使用时，我们可以，示例如下：

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

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

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

对于上述技术内容，LangChain的开源组件和第三方集成可以轻松支持快速上手，帮助我们构建应用程序。除此之外，使用LangGraph可以构建支持人机交互的有状态代理。

LangChain公司也在围绕框架构建完整的生态系统，包括推出LangSmith(一个用于调试、监控和评估LLM应用的平台)以及LangGraph Platform(用于LangChain应用的部署、运维)等，为开发者提供从开发到生产的一站式支持。

4. 起源与发展

LangChain由Harrison Chase 于2022年10月开源发布，旨在解决开发者在使用LLM (如GPT-3)时遇到的核心问题。项目迅速获得社区关注。

• 2023年成立LangChain公司并获数千万美元融资，估值达2亿美元
• 2023年中，LangChain推出了对JavaScript/TypeScript 的支持，使其开发者社区从 Python扩展到了前端和全栈开发者。此外，LangChain不断增加对各种LLM模型的支持，从最初的OpenAIAPI扩展到Anthropic、HuggingFace等模型提供商，以及本地部署的模型(如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.xAlpha内测版，在各提供商之间统一了现代LLM功能，包括推理、引用、服务器端工具调用等。还新增了预构建的Langgraph链和代理。Langchain包的范围已缩小，专注于流行和重要的抽象概念。为保持向后兼容性，新增了langchain-legacy包。

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

三、LangGraph

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

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 路径。

在链式结构中，实现这种条件分支非常笨拙，通常需要编写一个巨大的“主链”，内部用一系列 if-else 语句来调用不同的子链。

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

类比理解：LangChain 的 Chain 像一条单行道🚗，适合线性任务：

用户输入 → 提示词 → LLM → 工具调用 → 输出

但真实业务往往是立交桥🛣️：

用户输入 → 判断意图 → [分支A: 查天气] ↘
                      [分支B: 写代码] → 结果汇总 → 人工审核? → 输出
                           ↗
                      [分支C: 多轮追问] ←(循环)

这时候就需要 LangGraph 登场了！

2. 引进 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 提供了更强大的支持。

核心概念

概念	通俗解释	类比
State（状态）	整个工作流的"共享内存"，所有节点都能读写	📋 白板，每个步骤都能往上写字
Node（节点）	执行具体任务的单元，比如调用 LLM、跑工具函数	👷 工人，每人负责一道工序
Edge（边）	定义节点之间的跳转逻辑，支持条件分支	🚦 交通信号灯，决定下一步往哪走
Cycle（循环）	允许工作流"走回头路"，实现重试/迭代	🔄 游戏存档读档，不满意就重来
Human-in-the-loop	关键节点暂停，等人确认后再继续	✋ “老板您看下这个方案行不行？”

3. LangGraph 的技术特点

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

• 节点：表示操作或状态
• 边：表示节点之间的转移和数据流。

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

• 循环与分支：LangGraph 中的节点（Node）可以连接到其他任何节点，包括自己。你可以轻松设置一个“信息收集”节点，如果信息不完整，就让流程再次循环回这个节点本身，直到条件满足为止。

• 动态路由：通过条件边，可以根据当前状态的值，动态决定下一个要执行的节点。例如，在“分类”节点之后，可以根据分类结果，自动路由到“处理退货”、“处理咨询”或“处理投诉”等完全不同的子图中去。

• 状态维护：LangGraph 有一个核心的状态对象，在整个图的执行过程中自动持久化和传递。每个节点都可以读取和修改这个状态。这意味着用户的对话历史、已收集的信息都会自动保留，轻松支持长时间运行的任务。

• 持久执行：构建能够经受住故障并能长时间运行的代理，自动从上次中断的地方恢复。

• 人机协作：通过在执行过程中的任何时刻检查和修改代理状态，无缝融入人工监督。

• 全面记忆：创建真正具有状态的代理，兼具用于持续推理的短期工作记忆和跨会话的长期持久记忆。

• 使用 LangSmith 进行调试：借助可视化工具深入洞察复杂代理行为，这些工具可追踪执行路径、捕获状态转换并提供详细的运行时指标。

• 生产级部署：借助专为处理有状态、长时间运行工作流的独特挑战而设计的可扩展基础设施，自信地部署复杂的代理系统。

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

4. 起源与发展

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

【★,°:.☆(￣▽￣)/$:.°★ 】那么本篇到此就结束啦，如果有不懂 和 发现问题的小伙伴可以在评论区说出来哦，同时我还会继续更新关于【LangChain】的内容，请持续关注我 ！！