【AI开发】从 Vibe Coding 到 LangGraph，AI 开发框架一次看懂

 👋 欢迎阅读

🏠个人主页：愿旖旎 📘专栏传送门：算法专栏 💻当前学习内容：LangChain

一、前置讲解

在进入正文前，先花 10 秒了解本篇会反复用到的核心概念，带着印象去读正文，学习效率更高。

🧠 前置知识一：Vibe Coding

用自然语言让 AI 直接写代码的编程实践，是理解本篇由来的背景。

📐 前置知识二：AI 开发框架

封装 LLM 交互复杂性的"积木箱"，核心原则是抽象封装与模块化组装。

📚 前置知识三：LangChain（链式）

把 LLM 组件（提示词、模型、记忆、工具）串成一条链一次性执行的框架。

🗺️ 前置知识四：LangGraph（图式）

用图结构（节点+边）构建复杂、有状态的 AI 工作流，是 LangChain 的进阶。

🧮 前置知识五：LLM 应用痛点

幻觉、提示词不规范、模型切换难、输出非结构化等，是框架存在的理由。

二、Vibe Coding：AI 时代的新编程范式

2.1 起源

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

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

实际上，这与仅仅将 LLM 作为代码输入的辅助工具不同。Vibe Coding 仍然需要开发者审查、测试和理解每一行代码。Vibe Coding 的本质是完全沉浸于 AI 助手的"氛围"中，将详细的实现过程外包给 AI。正如 Karpathy 最初所描述的那样：

"这不算真正的编程——我只是看看东西，说说东西，运行东西，然后复制粘贴东西，而且它大多都能工作。"

优势

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

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

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

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

三、AI 开发框架：为什么我们需要框架

3.1 框架原则

AI 开发框架与传统框架（如 Java 中的 Spring，C++ 中的 libcurl 库），它们都共享一些框架原则：

抽象与封装

• Spring：封装了 Java EE 开发的复杂性，如依赖注入、事务管理、MVC。

• libcurl：封装了网络协议的复杂性（HTTP, FTP, SMTP 等）。

• LangChain：封装了与不同 LLM（OpenAI, Anthropic 等）、向量数据库（Chroma, Pinecone）、工具（Tools）交互的复杂性。开发者不需要为每个供应商编写不同的 API 调用代码。

  

模块化与可组装性

• Spring（Java）：通过其强大的依赖注入（DI）和控制反转（IoC）容器，将应用程序组织成高度可插拔的 Bean（@Component、@Service）。

• LangChain：核心概念就是 "链"（Chain），它将不同的模块（LLM、Prompts、Tools、Memory、Output Parsers）像乐高积木一样组合起来，构建复杂的 AI 工作流。

3.2 AI 开发框架的价值

如 LangChain、LangGraph 这样的 AI 开发框架正成为开发者的"超级武器"。它们如同智能时代的操作系统，连接着强大的 AI 模型与复杂的现实应用。

为什么重要：

核心收益：

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

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

为什么 C++ 生态没有全栈 LLM 框架？

C++ 生态在 LLM 应用开发的全栈框架领域相对缺失，主要原因是因为 C++ 的角色定位不同：

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

• Python/JS：作为动态语言，具有快速原型设计的优势。这种快速反馈循环对于探索 LLM 能力至关重要。

• C++：作为静态编译型语言，虽然性能极高，但编译时间长，代码修改和测试的周期也更长这种“厚重”的开发体验与当前 LLM 应用需要的“敏捷”开发模式背道而驰。

2. 生态系统的重心不同

• Python 生态：拥有无与伦比的库支持——机器学习框架（PyTorch、TensorFlow、JAX）、数据处理（NumPy、Pandas）、Web 与 API 集成（FastAPI、Requests）、向量数据库客户端、模型提供商 SDK 等。

• C++ 生态：其传统优势领域在于系统编程、游戏开发、高频交易、嵌入式等。

  

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

现代 LLM 应用架构普遍采用 "Python/Java 负责应用层（做什么），C++ 负责底层推理（怎么做）" 的分工模式。一个完美的例子是 llama.cpp（官网: GitHub – ggml-org/llama.cpp: LLM inference in C/C++ · GitHub）：

• 它是用 C/C++ 编写的高性能推理项目，以出色的性能和极低的内存需求（量化）闻名。

• 可以将它作为库链接到 C++ 应用中，在本地直接运行模型，或用其 server 功能启动 HTTP API 服务。

• 上层的 Python/JavaScript 应用通过调用这个 API 使用它，结合了 C++ 的推理性能和 Python 的应用开发效率。

五、LangChain 详解：它如何解决 LLM 应用难题

5.1 复杂场景下，LLM 嵌入应用的问题

尽管大模型在某些方面表现振奋人心，但在复杂的场景下使用，如将 LLM 嵌入应用程序时却遭遇了全新难题：

• 简单提示词（Prompt）得到的答案经常出现幻觉？

• 提示词结构是否可以统一规范？

• 如何实现开发过程中大模型的轻松、灵活切换？

• 大模型输出是非结构化的，怎样与要求结构化数据的程序接口交互？

• 如何克服预训练模型知识陈旧的问题，引入实时更新？

• 如何连接模型与外部工具或系统，执行具体任务？

举个例子：我们要开发一个智能医疗咨询助手，用户向其描述症状，助手提供初步的疾病可能性分析、护理建议和就医提醒。

• 场景1：幻觉风险——用户咨询"三岁孩子吞下纽扣电池怎么办"，模型基于训练数据错误生成"建议"，而正确做法是立即送医。在生产环境中，这种错误无法接受。

  

• 场景2：提示词无规范——不同功能的提示词质量参差不齐，导致应用行为不可预测、难以调试。

  

• 场景3：模型切换成本高——一旦选定模型，代码与模型 API 强耦合，切换几乎等于重写所有与 LLM 交互的代码。

  

• 场景4：非结构化输出难对接——程序无法直接解析自然语言提取"疾病名称"和"可信度"，必须写复杂的正则或再调一个模型解析，极大增加了复杂度和出错概率。

  

• 场景5：知识陈旧——训练数据有截止日期（例如 2024 年初）。对于 2024 年下半年或以后的研究，它一无所知，要么拒绝回答，要么基于过时信息给出错误答案。

• 场景6：需要外部工具——"布洛芬和阿司匹林可以同时吃吗"需要调用权威药物相互作用 API，让 LLM 自发地、可靠地决定何时调用哪个工具，是极其复杂的系统设计问题。

  

5.2 LangChain：解决痛点

为了解决上述问题，业界正在形成一整套称为 "LLM 应用工程" 的最佳实践和技术栈：

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

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

• 组件：提供一系列核心构建块，如语言模型、输出解析器、检索器等。

• 自然语言处理流程：完成特定 NLP 任务的一系列步骤，例如"基于公司文档的问答机器人"：读取文档 → 分割文本 → 向量化 → 存储 → 检索 → 组合提示词 → 解析输出。

  

5.3 LangChain 的技术特点

LangChain 框架的设计精髓在于以链式（Chain）的方式整合多个组件，一次性执行"链"上的所有流程。

举一个最简单的例子，若想借助提示词完成一次对 LLM 的提问，至少需要定义两个组件：提示词模板组件 + 大模型组件。链式执行只需执行一次"链"即可。

这相当于，提⽰词模板组件执⾏了⼀次，⼤模型组件也执⾏了⼀次。⽽对于链式执⾏来说，只需执⾏⼀次链即可：

LangChain 提供的标准化模块与接口：

• 统一的模型调用：通过抽象接口支持多种大语言模型和嵌入模型，灵活切换供应商。

• 灵活的提示词管理：提供提示词模板，支持动态生成输入内容，并可管理少样本示例与提示选择策略，以提升模型响应质量。

• 可组合的任务链（Chains）：允许将多个步骤串联成完整流程，如先检索文档再生成回复，或组合多次模型调用。开发者能够通过自定义链实现复杂的任务编排。

• 上下文记忆机制（Memory）：存储多轮对话状态（注：该能力目前已由 LangGraph 支持）。

• 检索与向量存储集成：文档加载 → 分割 → 向量化 → 存储 → 查询检索，构建 RAG 类应用，兼容 FAISS、Pinecone、Chroma 等主流向量数据库。

六、LangGraph：从链式到图式的进化

6.1 LangChain 的局限性

LangGraph 是 LangChain 生态系统中晚些出现的框架，其诞生背景与 LLM 应用日益增长的复杂性密切相关。传统链式结构的局限性逐渐显现：

• 链式流程通常是线性的、预先定义好的步骤，难以处理需要循环、分支或长期状态维护的复杂场景。

• 在构建多智能体协作、需要人工介入或长时间运行的任务时，需要更灵活的工作流管理和状态持久化支持。

举个例子：假设我们要构建一个 AI 代理，来自动处理用户提交的客服工单（例如：退货请求、产品咨询、投诉等）。一个理想的流程是。

如果使用传统的 Chain A -> Chain B -> Chain C 的线性结构来构建客服工单处理系统，会遇到以下具体问题：

6.2 LangGraph：解决痛点

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

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

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

LangGraph 并不是要取代 LangChain，而是对 LangChain 的扩展和补充：

• 底层大量复用 LangChain 的组件（模型接口、工具、记忆等），可在节点中直接使用 LangChain 的链或代理作为子流程。

• 对于简单的线性任务，LangChain 的链式结构已经足够高效；

• 对于需要复杂控制流、长期状态和多智能体的场景，LangGraph 提供了更强大的支持。

6.3 LangGraph 的技术特点

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

• 节点：表示操作或状态（调用 LLM、执行工具、人工审核、数据转换等）。

• 边：表示节点之间的转移和数据流（普通边、条件边、分支边等）。

这种图式架构相比链式结构更加灵活：

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

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

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

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

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

• 全面记忆：兼具短期工作记忆和跨会话的长期持久记忆。

• 使用 LangSmith 进行调试：可视化追踪执行路径、捕获状态转换、提供运行时指标。

七、学习路径与目标

这条学习路径遵循循序渐进的原则。课程结束后，你将获得：

• 两个框架的深度知识：系统掌握 LangChain 和 LangGraph 的核心概念与最佳实践。

• 解决实际问题的能力：能够从零开始设计、构建可处理复杂任务的智能 AI 代理与多步骤工作流应用，具备将复杂业务需求转化为 AI 解决方案的架构能力。

八、复盘（附答案）

💡 思考题

📝 答案

  🎯 闭幕

从 Vibe Coding 的兴起，到 LangChain 的链式封装，再到 LangGraph 的图式进化——AI 应用开发正在从"能用"走向"工程化"。掌握框架，就是掌握将 AI 能力落地的钥匙。

如果本文对你有帮助，欢迎：

👍 点赞 ｜ ⭐ 收藏 ｜ 👤 关注作者 💬 留言交流你的疑问或补充

你的每一次互动都是我继续更新的动力，我们下一篇见！🚀