从 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 时代下的编程范式](#一、AI 时代下的编程范式 "#%E4%B8%80%E3%80%81AI%20%E6%97%B6%E4%BB%A3%E4%B8%8B%E7%9A%84%E7%BC%96%E7%A8%8B%E8%8C%83%E5%BC%8F")

[1. Vibe Coding 氛围编程](#1. Vibe Coding 氛围编程 "#1.%20Vibe%20Coding%20%E6%B0%9B%E5%9B%B4%E7%BC%96%E7%A8%8B")

[1.1 Vibe Coding 的起源](#1.1 Vibe Coding 的起源 "#1.1%20Vibe%20Coding%20%E7%9A%84%E8%B5%B7%E6%BA%90")

[1.2 Vibe Coding 的局限性](#1.2 Vibe Coding 的局限性 "#1.2%20Vibe%20Coding%20%E7%9A%84%E5%B1%80%E9%99%90%E6%80%A7")

[2. AI 开发框架：新战略高地](#2. AI 开发框架：新战略高地 "#2.%20AI%20%E5%BC%80%E5%8F%91%E6%A1%86%E6%9E%B6%EF%BC%9A%E6%96%B0%E6%88%98%E7%95%A5%E9%AB%98%E5%9C%B0")

[2.1 框架原则](#2.1 框架原则 "#2.1%20%E6%A1%86%E6%9E%B6%E5%8E%9F%E5%88%99")

[2.2 超级武器：当下的框架版图](#2.2 超级武器：当下的框架版图 "#2.2%20%E8%B6%85%E7%BA%A7%E6%AD%A6%E5%99%A8%EF%BC%9A%E5%BD%93%E4%B8%8B%E7%9A%84%E6%A1%86%E6%9E%B6%E7%89%88%E5%9B%BE")

[3. 未来展望](#3. 未来展望 "#3.%20%E6%9C%AA%E6%9D%A5%E5%B1%95%E6%9C%9B")

[二、LangChain：LLM 应用开发的核心框架](#二、LangChain：LLM 应用开发的核心框架 "#%E4%BA%8C%E3%80%81LangChain%EF%BC%9ALLM%20%E5%BA%94%E7%94%A8%E5%BC%80%E5%8F%91%E7%9A%84%E6%A0%B8%E5%BF%83%E6%A1%86%E6%9E%B6")

[1. LLM 驱动的应用程序的框架](#1. LLM 驱动的应用程序的框架 "#1.%20LLM%20%E9%A9%B1%E5%8A%A8%E7%9A%84%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E7%9A%84%E6%A1%86%E6%9E%B6")

[1.1 Python 生态（绝对主流）](#1.1 Python 生态（绝对主流） "#1.1%20Python%20%E7%94%9F%E6%80%81%EF%BC%88%E7%BB%9D%E5%AF%B9%E4%B8%BB%E6%B5%81%EF%BC%89")

[1.2 JavaScript / TypeScript 生态（前端与全栈）](#1.2 JavaScript / TypeScript 生态（前端与全栈） "#1.2%20JavaScript%20%2F%20TypeScript%20%E7%94%9F%E6%80%81%EF%BC%88%E5%89%8D%E7%AB%AF%E4%B8%8E%E5%85%A8%E6%A0%88%EF%BC%89")

[1.3 Java 生态](#1.3 Java 生态 "#1.3%20Java%20%E7%94%9F%E6%80%81")

[1.4 C++ 生态](#1.4 C++ 生态 "#1.4%20C%2B%2B%20%E7%94%9F%E6%80%81")

[1.5 如何选择？](#1.5 如何选择？ "#1.5%20%E5%A6%82%E4%BD%95%E9%80%89%E6%8B%A9%EF%BC%9F")

[2. LangChain 介绍](#2. LangChain 介绍 "#2.%20LangChain%20%E4%BB%8B%E7%BB%8D")

[2.1 复杂场景下，LLM 嵌入应用的问题？](#2.1 复杂场景下，LLM 嵌入应用的问题？ "#2.1%20%E5%A4%8D%E6%9D%82%E5%9C%BA%E6%99%AF%E4%B8%8B%EF%BC%8CLLM%20%E5%B5%8C%E5%85%A5%E5%BA%94%E7%94%A8%E7%9A%84%E9%97%AE%E9%A2%98%EF%BC%9F")

[2.2 LangChain：解决痛点](#2.2 LangChain：解决痛点 "#2.2%20LangChain%EF%BC%9A%E8%A7%A3%E5%86%B3%E7%97%9B%E7%82%B9")

[2.3 LangChain 的技术特点](#2.3 LangChain 的技术特点 "#2.3%20LangChain%20%E7%9A%84%E6%8A%80%E6%9C%AF%E7%89%B9%E7%82%B9")

[3. 起源与发展](#3. 起源与发展 "#3.%20%E8%B5%B7%E6%BA%90%E4%B8%8E%E5%8F%91%E5%B1%95")

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

[1. LangGraph 介绍](#1. LangGraph 介绍 "#1.%20LangGraph%20%E4%BB%8B%E7%BB%8D")

[1.1 LangChain 的局限性](#1.1 LangChain 的局限性 "#1.1%20LangChain%20%E7%9A%84%E5%B1%80%E9%99%90%E6%80%A7")

[1.2 LangGraph：解决痛点](#1.2 LangGraph：解决痛点 "#1.2%20LangGraph%EF%BC%9A%E8%A7%A3%E5%86%B3%E7%97%9B%E7%82%B9")

[1.3 LangGraph 的技术特点](#1.3 LangGraph 的技术特点 "#1.3%20LangGraph%20%E7%9A%84%E6%8A%80%E6%9C%AF%E7%89%B9%E7%82%B9")

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

一、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 的短板暴露无遗：

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

一句话总结：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 组装一条链：

python 复制代码

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 场景下脱颖而出的根本原因。

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

python 复制代码

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 应用开发的道路上探索，欢迎在评论区交流你的实践与思考。