当「写代码」这件事本身被 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. 未来展望二、LangChainLLM 应用开发的核心框架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 的短板暴露无遗理解缺失开发者对自己不理解的代码几乎束手无策一旦 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 所处的坐标。二、LangChainLLM 应用开发的核心框架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 KernelJava 版。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 LanguageLCEL以声明式方式组合复杂流水线原生支持流式输出、并行执行、异步调用、自动重试等生产级特性。开箱即用的 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(modelgpt-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 与 LangGraphLangChain 逐渐演进为「整套 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 应用开发的道路上探索欢迎在评论区交流你的实践与思考。
当「写代码」这件事本身被 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. 未来展望二、LangChainLLM 应用开发的核心框架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 的短板暴露无遗理解缺失开发者对自己不理解的代码几乎束手无策一旦 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 所处的坐标。二、LangChainLLM 应用开发的核心框架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 KernelJava 版。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 LanguageLCEL以声明式方式组合复杂流水线原生支持流式输出、并行执行、异步调用、自动重试等生产级特性。开箱即用的 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(modelgpt-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 与 LangGraphLangChain 逐渐演进为「整套 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 应用开发的道路上探索欢迎在评论区交流你的实践与思考。
