从 Vibe Coding 到智能体工作流：LangChain 与 LangGraph 的工程化实践

大语言模型正在改变软件开发的方式。过去，开发者需要逐行编写代码、阅读文档并手动调试；现在，只要用自然语言描述需求，AI 就能生成函数、测试用例甚至完整的应用原型。这种强调意图表达、快速生成与持续反馈的开发方式，通常被称为 Vibe Coding。

它降低了把想法转化为软件的门槛，却没有消除软件工程本身的复杂性。当应用从演示走向生产，代码质量、系统架构、上下文管理、数据安全、异常处理和长期维护都会重新成为核心问题。尤其是在构建大语言模型应用时，真正困难的往往不是“调用一次模型”，而是如何让模型稳定地参与一个完整、可控、可观测的业务流程。

LangChain 与 LangGraph 正是在这一背景下发挥作用：前者提供可组合的模型应用组件，后者进一步为复杂智能体提供有状态的图式编排能力。

Vibe Coding 改变了什么

Vibe Coding 的核心，是开发者使用自然语言向代码模型说明目标，再由模型完成大量具体实现。开发者的角色由单纯的代码编写者，逐渐转向需求定义者、架构设计者、结果审查者和质量负责人。

这种方式特别适合以下任务：

• 生成样板代码和重复性逻辑；
• 重命名变量、调整函数签名等机械修改；
• 编写单元测试和简单脚本；
• 解释陌生代码并提供修改建议；
• 快速制作概念验证和小型工具。

但“能够运行”不等于“适合生产”。AI 生成的代码可能存在架构不一致、重复实现、异常处理不足和安全边界模糊等问题。模型的上下文窗口也不可能无限容纳一个大型项目的全部代码，后续修改可能与早期设计发生冲突。此外，模型知识存在时间边界，还可能生成并不存在的 API 或错误的库用法。

因此，AI 编程并没有让工程能力失去价值，反而提高了对系统设计、代码评审、测试验证和问题拆解能力的要求。开发者需要知道一个合格系统应当如何组织，才能判断模型生成的结果是否可靠。

为什么 AI 应用需要开发框架

框架的价值，本质上是封装共性复杂度，并为系统提供清晰的组件边界。Spring 封装企业应用中的对象管理和依赖组织，网络库封装底层协议，而 AI 开发框架则负责连接模型、提示词、检索器、向量数据库、外部工具和业务流程。

直接调用大模型 API 看起来很简单：发送一段文本，然后接收一段回答。但一旦进入真实业务，开发者很快会遇到一系列问题：

• 提示词缺少统一结构，效果难以持续优化；
• 模型可能产生事实错误或幻觉；
• 应用代码与某个模型供应商的 API 强耦合；
• 自然语言输出难以被程序稳定解析；
• 模型不了解实时信息和企业私有数据；
• 模型需要调用搜索、数据库或业务接口完成任务；
• 多轮交互中的状态和历史消息难以维护；
• 多步骤流程缺少统一的调试和观测方式。

以智能医疗咨询为例，一个成熟系统不能仅把用户症状直接发送给模型。它需要规范提示词，从权威知识库检索信息，调用药物数据库，验证输出结构，并在高风险情况下明确要求用户就医或转交专业人员。大模型只是其中的推理和语言生成引擎，而不是完整系统。

这类应用工程需要一套标准化的构建方式，LangChain 由此成为常见选择。

LangChain：把模型能力拆成可组合组件

LangChain 是面向大语言模型应用的开发框架。它将常见能力抽象为标准组件，并允许开发者把这些组件组合成可复用的执行流程。

常见组件包括：

• 模型接口：统一调用不同的大语言模型和嵌入模型；
• 提示词模板：动态组织上下文、变量、角色和输出要求；
• 输出解析器：将模型回答转换为 JSON 或程序对象；
• 文档加载器：读取 PDF、网页、数据库等数据源；
• 文本分割器：把长文档切分为适合检索的片段；
• 嵌入模型与向量存储：将内容向量化并支持语义检索；
• 检索器：根据用户问题查找相关资料；
• 工具：让模型调用搜索、计算器、数据库和业务 API；
• 链与智能体：组织多个步骤，并根据目标执行任务。

例如，构建一个企业知识问答应用时，完整流程可能是：加载公司文档，进行文本切分，将片段转换为向量并写入向量数据库；用户提问后，系统检索相关片段，把问题和资料填入提示词，再交给模型生成答案，最后由输出解析器返回标准结果。

如果完全手写这套流程，开发者不仅要处理多个供应商的 API 差异，还要维护大量数据转换和控制代码。LangChain 的意义在于为这些环节提供统一抽象，让开发工作更集中于业务逻辑。

链式组合如何工作

LangChain 最具代表性的思想是“链”。链把多个组件按照确定顺序连接起来，让一个组件的输出成为下一个组件的输入。

一个最简单的流程可以写成：

用户输入 -> 提示词模板 -> 大语言模型 -> 输出解析器

一个 RAG 流程则可能是：

用户问题 -> 检索器 -> 相关文档 -> 提示词模板 -> 大语言模型 -> 最终答案

这种组合方式带来几个直接收益。

首先，模型调用得到统一封装。应用可以通过相似的接口接入不同供应商的模型，减少业务代码与特定 SDK 的耦合。切换模型仍然需要重新评估提示词、成本和输出差异，但不必重写整个调用层。

其次，提示词可以模板化管理。开发者能够把系统角色、业务背景、输入变量和输出规范集中定义，避免提示词散落在代码中。

再次，输出解析器可以把非结构化回答转换为明确的数据结构。相比依赖脆弱的正则表达式，基于 Schema 的输出约束更适合与前端和业务接口集成。

最后，LangChain 对检索器、文档处理和向量数据库提供了丰富集成，可以显著缩短 RAG 系统的开发周期。

如何选择语言与框架

大语言模型应用并不只有一种技术栈。选择框架时，团队现有能力和项目需求通常比流行度更重要。

技术生态	常见选择	适用方向
Python	LangChain、LlamaIndex	快速原型、复杂 AI 应用、RAG、丰富的模型与数据生态
JavaScript / TypeScript	LangChain.js、LlamaIndex.TS	Next.js 等全栈应用、浏览器扩展、边缘运行环境
Java	LangChain4j、Spring AI、Spring AI Alibaba	企业后端、Spring Boot 系统、已有 Java 业务集成
C / C++	llama.cpp 等推理工具	本地推理、离线运行、资源受限设备、性能敏感场景

Python 拥有最成熟的机器学习和数据处理生态，适合研究、快速迭代和高度定制的 AI 项目。JavaScript 与 TypeScript 更适合 Web 全栈开发。Java 团队通常可以通过 LangChain4j 或 Spring AI 将模型能力接入现有企业系统，而无需为了使用 AI 重写业务技术栈。

C++ 的角色有所不同。它不一定负责上层工作流编排，却是高性能推理的重要基础。常见架构是由 C++ 运行本地模型和推理服务，再由 Python 或 Java 负责业务层与 API 编排，从而兼顾性能与开发效率。

线性链为什么会遇到瓶颈

链非常适合步骤明确的线性任务，但复杂智能体并不总是从起点一路执行到终点。

假设系统需要自动处理客服工单。它首先识别用户意图，再收集订单号和问题描述，然后验证信息，根据结果处理退货、咨询或投诉。如果信息不完整，系统应继续询问；如果风险较高，则暂停自动流程并交给人工；人工处理结束后，系统还要接着执行剩余步骤。

在线性链中，这些需求会暴露出明显限制：

• 无法自然返回上一步重复收集信息；
• 多轮对话与长期任务的状态维护困难；
• 条件分支容易演变成大量嵌套的 if-else；
• 人工介入往往会让自动流程直接中断；
• 故障恢复、暂停和继续执行需要额外实现；
• 多个智能体之间的协作关系难以表达。

当工作流包含循环、动态路由、长时间运行和人工审批时，单向的“链”已经不足以准确描述业务。此时，更合适的抽象是“图”。

LangGraph：用图管理复杂智能体

LangGraph 是面向有状态、长时间运行的智能体工作流的编排框架。它把应用建模为由节点和边组成的图：

• 节点表示一次操作，例如识别意图、查询订单、调用模型或请求人工审核；
• 边表示节点之间的转移关系和数据流；
• 条件边根据当前状态动态决定下一步；
• 状态对象在整个执行过程中保存和传递数据。

客服工作流可以被描述为：

接收请求
   |
识别意图
   |-- 退货请求 --> 收集订单信息 --> 验证订单
   |                         ^          |
   |                         | 信息不足 |
   |                         +----------+
   |                                    |
   |                              验证成功
   |                                    |
   |                              执行退货流程
   |
   |-- 产品咨询 --> 检索产品知识 --> 生成回答
   |
   +-- 投诉 ------> 风险判断 ------> 人工处理

与线性链相比，图中的节点可以连接到任意节点，也可以连接回自身。因此，“信息不完整就继续询问”不再需要用复杂的外部控制代码拼接，而是工作流本身的一部分。

状态是 LangGraph 的核心

复杂智能体不能只依赖模型的临时上下文。系统需要一个明确的状态对象，记录执行过程中的数据和决策。例如：

state = {
    "intent": "return",
    "collected_info": {
        "order_id": "A1024",
        "reason": "商品损坏",
    },
    "needs_human": False,
    "is_verified": True,
    "is_complete": False,
    "message_history": [],
}

每个节点都可以读取状态、执行自己的职责，再把更新后的内容传递给后续节点。这样，用户意图、已收集信息、验证结果和对话历史都能在工作流中持续存在。

状态还为检查点和故障恢复提供了基础。长时间运行的任务可以定期保存执行进度，在程序重启或服务异常后从中断位置继续，而不是从头开始。

循环、分支与人工介入

LangGraph 的价值主要体现在复杂控制流上。

循环可以让智能体反复执行某个节点。例如，模型生成答案后进入质量检查节点；如果结果不合格，流程返回生成节点重新尝试，直到满足条件或达到最大次数。

动态路由可以根据状态选择不同路径。系统识别出退货、咨询或投诉后，可以分别进入不同子流程，而不必让所有请求执行同一组步骤。

人工介入则允许工作流在关键节点暂停。人工审核人员可以查看并修改状态，提交处理结果后，系统从原位置继续执行。这对于医疗、金融、客服和内容审核等高风险场景尤其重要。

此外，LangGraph 还适合组织多智能体协作。不同节点可以分别由规划智能体、检索智能体、代码智能体和审核智能体负责，图负责管理它们的执行顺序、共享状态与退出条件。

LangChain 与 LangGraph 应该如何配合

LangGraph 并不是 LangChain 的替代品。二者解决的问题层次不同：

• LangChain 更关注模型、提示词、检索器、工具和输出解析等能力组件；
• LangGraph 更关注这些组件如何在复杂、有状态的流程中被调度。

在实际项目中，可以在 LangGraph 的节点中直接使用 LangChain 构建的链、检索器或工具。一个节点负责执行 RAG 查询，另一个节点调用业务 API，还有一个节点负责校验模型输出。LangGraph 将这些节点组织成完整工作流，并维护执行状态。

选择时可以遵循一个简单原则：如果任务是固定顺序、一次性完成的线性流程，使用 LangChain 的链通常已经足够；如果任务涉及循环、条件分支、长期状态、故障恢复、人工审批或多智能体协作，则更适合使用 LangGraph。

从开发走向生产

智能体应用的难点不只在于实现功能，还在于理解系统为什么做出某个决定。普通应用可以通过日志定位函数调用，而智能体的运行路径可能受到模型输出、检索结果、工具响应和状态变化的共同影响。

因此，生产环境需要对以下信息进行观测：

• 每次模型调用的输入、输出、延迟与消耗；
• 检索器返回了哪些文档以及相关度如何；
• 智能体选择了哪个工具，工具返回了什么；
• 工作流经过了哪些节点和条件分支；
• 状态在节点之间发生了哪些变化；
• 哪些任务失败、重试、暂停或转交人工。

LangSmith 等工具可以用于追踪、调试和评估执行过程，帮助开发者观察复杂智能体的实际行为。对于需要长期运行的流程，还应设计检查点、幂等操作、超时、重试、权限控制和数据审计机制。

写在最后

AI 生成代码让开发变得更快，但速度不是软件工程的最终目标。真正可靠的 AI 应用，需要清晰的架构、可替换的组件、受约束的模型输出、可验证的数据来源，以及能够被调试和恢复的工作流。

LangChain 把大语言模型应用拆解为模型、提示词、检索、工具和解析器等标准组件，让开发者能够像搭建软件模块一样组合 AI 能力。LangGraph 则进一步引入图、状态、循环、分支和人工介入，使复杂智能体从一段难以维护的控制代码，转变为结构清晰、可以持久执行的工作流。

从 Vibe Coding 到智能体工程，开发者的价值正在从“写出更多代码”转向“定义正确问题、设计可靠系统并验证最终结果”。掌握模型只是起点，能够把模型组织成稳定、可控的应用，才是 AI 软件开发真正的核心能力。