从 Vibe Coding 到 LangGraph：AI 时代编程范式的演进与重构

当「写代码」这件事本身被 AI 重新定义，开发者真正需要的，是让自己从「逐行敲代码」升级为「定义目标、驾驭流程」。

开篇：编程范式正在被重写

2025 年初，OpenAI 前研究科学家、Tesla AI 前负责人 Andrej Karpathy 在社交媒体上抛出了一个新词——Vibe Coding。他描述了一种前所未有的编程体验：开发者不再逐行敲击键盘，而是用自然语言向 AI 描述意图，看着代码像「呼吸」一样自然生长，自己只需要「完全沉浸在感觉里」。这个略带浪漫色彩的词，以惊人的速度席卷了全球开发者社区。

紧接着，围绕大语言模型（LLM）构建应用的工程化框架开始占据舞台中央：LangChain 成为「事实上的标准」，LangGraph 则带着图式架构向复杂工作流发起冲击。三条看似独立的线索，其实指向同一个趋势——AI 正在从「辅助写代码」走向「重塑编程范式本身」。

这篇文章将沿着这条演进脉络展开：先看清 Vibe Coding 的兴起与边界，再深入剖析 LLM 应用开发的核心框架 LangChain，最后讲解面向复杂工作流的图式架构 LangGraph。希望帮你建立起对 AI 时代编程版图的系统认知。

目录

开篇：编程范式正在被重写

一、AI 时代下的编程范式

1. Vibe Coding 氛围编程

1.1 Vibe Coding 的起源

1.2 Vibe Coding 的局限性

2. AI 开发框架：新战略高地

2.1 框架原则

2.2 超级武器：当下的框架版图

3. 未来展望

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

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

1.1 Python 生态（绝对主流）

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

1.3 Java 生态

1.4 C++ 生态

1.5 如何选择？

2. LangChain 介绍

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

2.2 LangChain：解决痛点

2.3 LangChain 的技术特点

3. 起源与发展

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

1. LangGraph 介绍

1.1 LangChain 的局限性

1.2 LangGraph：解决痛点

1.3 LangGraph 的技术特点

结语：程序员的下一个十年

---

---

一、AI 时代下的编程范式

1. Vibe Coding 氛围编程

1.1 Vibe Coding 的起源

Vibe Coding 一词由 Andrej Karpathy 于 2025 年 2 月提出。他在推文中描述自己用 AI 辅助开发时的状态：不再逐行编写代码，而是通过自然语言「诉说」需求，让 AI 生成并迭代代码，开发者只需要把控整体感觉与方向——也就是 the vibes。

其核心特征可以概括为三点：

• 自然语言成为第一编程语言：需求描述、修改意见、验收标准都以对话形式呈现。
• 开发者从「代码作者」变成「产品导演」：工作重心从实现细节转向目标定义、反馈循环与方向决策。
• 试错式迭代成为主流程：不满意就让 AI 改，改完再看效果，形成「描述 → 生成 → 验证 → 修正」的快速闭环。

工具层面，Cursor、GitHub Copilot、Claude Code、v0 等 AI 编程产品提供了落地土壤。Vibe Coding 之所以能流行，根本原因在于 LLM 的代码生成能力已经跃迁到「可用」水平——对于原型验证、小工具、个人项目，它确实能把开发效率提升一个量级。

1.2 Vibe Coding 的局限性

然而，「快」不等于「稳」。当项目从 Demo 走向生产，Vibe Coding 的短板暴露无遗：

1. 理解缺失：开发者对自己不理解的代码几乎束手无策，一旦 AI 生成的代码深处埋着 bug，排查和修复都无从下手，只能「推倒重来」。
2. 可维护性差：AI 生成的代码风格不统一、抽象层次混乱、逻辑反直觉，长期维护成本极高，团队协作时尤甚。
3. 缺乏确定性验证：依赖「试错 + 看效果」的验收方式，缺少严格测试与可复现的行为保证，代码在边界情况下往往不可控。
4. 安全隐患：不理解代码语义，就难以识别注入、越权、数据泄露等安全风险——这在生产环境是致命的。
5. 无法承载复杂架构：大型系统的架构设计、跨模块协调、性能优化、并发与容错，远超「对话式编码」的能力边界。

一句话总结：Vibe Coding 降低了「写代码」的门槛，却没有降低「保证代码正确」的责任。当复杂度上升，开发者迫切需要一种把 LLM 能力工程化、结构化、可控化的方案——这正是 AI 开发框架登场的契机。

2. AI 开发框架：新战略高地

2.1 框架原则

优秀的 AI 开发框架，通常遵循以下几条原则：

• 抽象与复用：把「调 LLM、解析输出、管理上下文、调用工具」等高频动作抽象成可复用组件，避免重复造轮子。
• 模块化与组合性：允许开发者像搭积木一样组合模型、提示词、工具、记忆等模块，按需装配业务能力。
• 显式状态管理：为多轮对话、多步骤流程提供清晰的状态存取机制，告别「上下文全靠手写拼接」。
• 可观测性：支持链路追踪、日志与调试，让 AI 应用不再是一个说不清道不明的「黑盒」。
• 生态集成：与向量数据库、外部工具 API、前端框架等基础设施无缝衔接。

2.2 超级武器：当下的框架版图

围绕这些原则，当前主流框架形成了各具特色的版图：

框架	定位	代表场景
LangChain / LangGraph / LangSmith	链式编排 + 图式工作流 + 全链路观测	通用 LLM 应用、Agent、生产级部署
LlamaIndex	数据接入与检索增强（RAG）	私有知识库问答、文档理解
AutoGen / CrewAI	多智能体（Multi-Agent）协作	多角色分工、群聊式协作任务
Semantic Kernel	微软出品的企业级多语言框架	.NET / Java / Python 企业应用
Vercel AI SDK	前端 / 全栈 LLM 集成	流式聊天 UI、Edge 函数

它们的共同本质是：把「提示词 + 模型 + 工具 + 记忆」这些要素，组合成可靠、可调试、可维护的应用，从而把 LLM 从「能聊天」推向「能干活」。

3. 未来展望

展望未来，几条趋势已经清晰浮现：从单次调用走向复杂 Agent 编排；从「对话」走向「工作流」；从 Prompt Engineering 走向「框架 + 工程体系」。

可以预见，编程范式将演变为：人类定义目标与约束，AI 生成实现，框架保证可控。Vibe Coding 解决「写得快」，框架解决「靠得住」，两者互补而非替代。而这条演进链的下游，就是 LangChain 与 LangGraph 所处的坐标。

---

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

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

在进入 LangChain 之前，先纵览各语言生态中的 LLM 应用框架，理解「为什么是它们」。

1.1 Python 生态（绝对主流）

得益于 AI/ML 领域数十年的积累，Python 是 LLM 应用开发的绝对主战场。几乎所有模型厂商的官方 SDK 都优先支持 Python。代表框架包括 LangChain、LlamaIndex、AutoGen、Haystack、DSPy 等。如果你是 AI 应用开发者，Python 几乎是必选项。

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

代表框架有 LangChain.js、Vercel AI SDK、LlamaIndex.ts。它们让前端工程师可以零门槛构建 AI 功能，在浏览器、Node.js 服务端、Electron 桌面端都能落地，并且能在前后端之间共享类型定义——这对全栈团队极具吸引力。

1.3 Java 生态

代表框架有 LangChain4j、Spring AI、Semantic Kernel（Java 版）。Java 生态面向企业级、金融、后端重型系统，强调类型安全、稳定性与既有 Java 技术栈（尤其是 Spring）的深度整合。适合对代码规范、审计合规要求极高的团队。

1.4 C++ 生态

以 llama.cpp 及其衍生绑定（如 llama-cpp-python）、Oga 等为代表。C++ 领域更接近「推理层」而非「应用层」，核心关注推理性能、内存占用与端侧部署（移动端、嵌入式、边缘设备）。在高吞吐、低延迟场景下不可替代。

1.5 如何选择？

选择框架可以从四个维度考量：

• 技术栈匹配：现有团队与系统用什么语言，优先选对应生态，避免引入「第二种语言」的隐性成本。
• 场景匹配：RAG 为主选 LlamaIndex，复杂编排选 LangChain/LangGraph，多智能体协作选 AutoGen/CrewAI，端侧部署走 C++ 系。
• 生态与活跃度：LangChain 生态最全、案例最多，但也要关注项目的维护频率、许可证与商业支持。
• 团队能力与学习成本：框架的抽象层级、文档质量、招人难度，都是实际约束。

结论很朴素：没有「最好」的框架，只有「最合适」的框架。

2. LangChain 介绍

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

简单场景——一个 Prompt 进，一段文本出——直接调 API 就够了。但一旦进入真实业务，问题接踵而至：

• 提示词工程复杂：真实任务往往需要多步 Prompt 拼接、模板化与版本管理，纯手写极易失控。
• 多模型切换成本高：不同厂商 API 格式各异，切换模型意味着大范围改动。
• 上下文与记忆难以管理：多轮对话、跨会话记忆如何存取？上下文爆掉怎么办？
• 工具调用与外部系统集成：LLM 需要查数据库、调 API、读写文件，谁来编排？
• 输出可靠性不足：LLM 输出是文本，如何解析成结构化数据并做校验与重试？
• RAG 落地繁琐：把私有知识库接入 LLM，涉及加载、切分、向量化、检索、再生成一整条链路。

这些痛点，裸调 API 无法优雅解决——LangChain 正是为它们而生。

2.2 LangChain：解决痛点

LangChain 于 2022 年 10 月由 Harrison Chase 创建并开源，它的核心价值在于：

• 统一抽象：用一套接口统一封装不同模型提供商（OpenAI、Anthropic、本地模型等），切换模型几乎零成本。
• 组件化设计：模型（Models）、提示词（Prompts）、输出解析器（Output Parsers）、记忆（Memory）、检索器（Retrievers）、工具（Tools）、智能体（Agents）等模块自由组合。
• 链式编排（Chain）：通过 LangChain Expression Language（LCEL）以声明式方式组合复杂流水线，原生支持流式输出、并行执行、异步调用、自动重试等生产级特性。
• 开箱即用的 RAG：内置文档加载器、文本切分器、向量数据库集成与检索问答链，让知识库应用开箱即用。

看一个最直观的例子——用 LCEL 组装一条链：

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

prompt = ChatPromptTemplate.from_template("用一句话解释：{topic}")
model = ChatOpenAI(model="gpt-4o")
chain = prompt | model | StrOutputParser()   # 管道符串联，声明式组合

result = chain.invoke({"topic": "什么是 LangChain"})
print(result)

2.3 LangChain 的技术特点

• 声明式与可组合：LCEL 让链的构建像管道一样清晰，代码即架构。
• 深度集成生态：拥有数百个第三方集成，覆盖向量库、数据库、工具、模型平台。
• 三层产品矩阵：LangChain（编排）、LangSmith（可观测 / 调试 / 评测）、LangGraph（复杂工作流），形成从开发到部署到观测的闭环。
• 活跃社区：GitHub 数十万 Star，教程与案例资源极其丰富，学习曲线相对平缓。

3. 起源与发展

• 2022 年 10 月：Harrison Chase 创建并开源 LangChain，早期主打链式 Prompt 编排。
• 2023 年：LangChain 迎来爆发式增长，成为 LLM 应用开发的事实标准；同年相继推出 LangServe（部署）与 LangSmith（观测）。
• 2024 年：发布 LangGraph，标志着从「链」向「图」的架构升级；同年完成 2500 万美元融资，估值约 2.5 亿美元。
• 2025 年起：战略重心全面转向 Agent 与 LangGraph，LangChain 逐渐演进为「整套 Agent 工程体系」。

---

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

1. LangGraph 介绍

1.1 LangChain 的局限性

LangChain 的 Chain 本质上是 DAG（有向无环图）：数据流单向、无环、状态隐式封装。这在简单场景下足够优雅，但在构建真正的 Agent 时却捉襟见肘：

• 无法表达循环：Agent 的「思考 → 行动 → 观察 → 再思考」天然是循环结构，DAG 无法建模。
• 无法处理动态分支：真实业务中的条件跳转、多路径路由，需要图的表达能力。
• 状态管理薄弱：多步流程间的状态传递依赖内部封装，难以细粒度控制与持久化。
• 调试与中断困难：无法在任意节点暂停、人工介入、恢复执行。
• Agent 是「黑盒」：早期 Agent 循环内置于框架内部，用户很难干预其决策过程。

一句话：Chain 适合「固定流水线」，不适合「会思考、会迭代、会分支的 Agent」。

1.2 LangGraph：解决痛点

LangGraph 由 LangChain 团队于 2024 年推出，核心思路是把应用建模为一张有状态的计算图：

• **节点（Node）**是执行单元，可以是 LLM 调用、工具调用或普通函数；
• **边（Edge）**定义流转方向，支持条件边（Conditional Edge）实现动态路由；
• 图结构显式表达循环、分支、并行与人工介入。

它带来的关键能力：

• 显式循环：轻松建模 Agent 的 ReAct 循环，不再依赖框架内部魔法。
• 条件路由：根据中间结果动态决定下一步走向，行为可控可预期。
• 状态管理与持久化：基于 Checkpoint 机制，支持跨会话状态恢复与断点续跑。
• 人工介入（Human-in-the-loop）：可随时暂停流程，等待人工审批、修正或补充信息后再恢复。
• 细粒度可观测：每个节点都可观测、可替换、可调试，告别黑盒。
• 流式输出与并行执行：复杂工作流也能高效运行。

设计上，LangGraph 借鉴了 Google Pregel 图计算框架与 Actor 模型的思想，用「节点 + 边 + 共享状态」重构了 LLM 应用的执行模型——这也是它能在复杂 Agent 场景下脱颖而出的根本原因。

看一个最小示例——定义一张两节点的图：

from typing import TypedDict
from langgraph.graph import StateGraph, END

class AgentState(TypedDict):
    input: str
    result: str

def call_llm(state: AgentState):
    return {"result": f"已处理：{state['input']}"}

graph = StateGraph(AgentState)           # 以状态为中心的图
graph.add_node("llm", call_llm)          # 添加节点
graph.set_entry_point("llm")             # 设置入口
graph.add_edge("llm", END)               # 连线到结束

app = graph.compile()
print(app.invoke({"input": "你好，LangGraph"}))

1.3 LangGraph 的技术特点

• StateGraph：以状态为中心的图定义 API，全局状态用 TypedDict 显式声明，类型安全且可预测。
• 节点 + 边 + 条件边：支持顺序、分支、循环、并行四种基本控制流。
• Checkpointer（持久化层）：保存每个节点的执行状态，支持「时间旅行」式调试——回到任意历史节点重放。
• 与 LangChain 无缝兼容：Retriever、Memory、Tools 等既有组件可以直接复用，迁移成本低。
• 流式执行：支持节点级与结果级流式输出，交互体验友好。

---

结语：程序员的下一个十年

从 Vibe Coding 到 LangChain，再到 LangGraph，我们看到的不仅是工具的迭代，更是 AI 编程范式的一次次跃迁：

• Vibe Coding 把编程的「入口」降到最低——人人皆可编程；
• LangChain 把 LLM 应用变得「可组装」——开发有章可循；
• LangGraph 把复杂工作流变得「可驾驭」——Agent 真正走向生产。

对开发者而言，真正的竞争力不在于「会用哪个框架」，而在于理解范式演进的逻辑：什么时候该放手让 AI 写，什么时候该用框架兜底，什么时候该用图式架构建模。理解这条脉络，就是为下一个十年构建属于自己的技术护城河。

如果你也在 AI 应用开发的道路上探索，欢迎在评论区交流你的实践与思考。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/2502_94387000/article/details/163513233