【Vibe Coding】初步认识LangChain&LangGraph

🔥个人主页：中草药

Vibe Coding

概述

VibeCoding（氛围编程 / 感觉编程）是 2025 年初由 OpenAI 联合创始人 Andrej Karpathy 提出的新型 AI 辅助编程范式，核心是通过自然语言描述意图，让 AI 生成代码并处理底层实现细节，开发者从 "逐行写码者" 转变为 "需求引导者" 和 "结果验收者"。这种方式彻底重构了软件开发流程，让编程更关注 "做什么" 而非 "怎么做"。

实际上，这与仅仅将 LLM 作为代码输⼊的辅助⼯具不同，Vibe Coding 仍然需要开发者审查、测试和理解每⼀⾏代码。Vibe Coding 的本质是完全沉浸于 AI 助⼿的 "氛围" 中，将详细的实现过程外包给 AI。正如 Karpathy 最初所描述的那样： "这不算真正的编程 -- 我只是看看东西，说说东西，运⾏东西，然后复制粘贴东西，⽽且它⼤多都能⼯作" 。

优势

Vibe Coding 标志着软件开发模式的根本转变：从细致的手动编码，转变更抽象、意图驱动的方法，人类开发者扮演者知道AI的角色

注意

开发者需要更加注重问题定义和规范，清晰地使⽤⾃然语⾔表达需求和期望的结果。确定最佳的Prompt变得⾄关重要。
同时，开发者需要具备指导和审查 AI ⽣成代码的能⼒，评估、完善和测试 AI 产出的代码。开发者更像是扮演指导者或编辑的⻆⾊。
系统设计和架构的理解变得⽐低层次的编码更为重要。批判性思维和问题解决能⼒对于评估和改进 AI ⽣成的代码⾄关重要。
此外，开发者需要学习如何有效地与 AI 沟通，掌握提⽰技巧以获得期望的结果。虽然侧重点有所变化，但对编程基本原理的理解对于有效地指导 AI 和进⾏调试仍然很有价值。

可以看到，清晰地定义问题和指导 AI 的能⼒变得⾄关重要。此外，AI 的输出需要验证，这需要批判性思维和对软件架构的理解。这表明开发者正在从"代码编写者"转变为更像是能够有效利⽤ AI 的"软件架构师"或"产品负责⼈"。

cursor

局限性

实际上，在真正的企业级应用场景里面，程序员们会发现它生成的嗲吗只能说是**"能用"而算不上优秀，甚至达不到及格**

1、代码质量与架构的「黑箱」困境

AI 仅保证代码「能运行」，无法理解「优雅、可维护、可扩展」的架构设计原则。

工程经验的缺失

代码的「优雅」与「可维护性」依赖人类开发者对 SOLID 原则、设计模式、领域驱动设计（DDD）等工程方法论的长期实践。例如，AI 生成的电商订单模块可能为了快速实现功能，将支付、库存扣减、物流通知等逻辑硬编码在一个函数中，表面上功能正常，但后续要新增「预售模式」或「多渠道支付」时，会发现代码完全无法复用，只能大面积重构。

SOLID 是面向对象编程（OOP）的 5 条设计原则的首字母缩写，目标是让代码更健壮、更易扩展、更易复用。分别是：

1. S -- Single Responsibility Principle（单一职责原则）

一个类、一个函数只做一件事

2. O -- Open/Closed Principle（开闭原则）

对扩展开放，对修改关闭。新增功能时，尽量通过扩展代码实现，而不是修改原有代码。

3. L -- Liskov Substitution Principle（里氏替换原则）

子类可以完全替换父类，且不会影响程序的正确性。

4. I -- Interface Segregation Principle（接口隔离原则）

客户端不应该依赖它不需要的接口。一个大接口要拆分成多个小接口，每个接口只包含客户端需要的方法。

5. D -- Dependency Inversion Principle（依赖倒置原则）

依赖抽象，不依赖具体实现。高层模块不应该依赖低层模块，两者都应该依赖抽象。

架构一致性失控

大型项目需要统一的架构风格（如微服务分层、前后端分离规范），但 AI 缺乏全局视角。比如前期生成了基于 RBAC（核心思想是定义不同角色并绑定对应的群贤，再把用户分配到对应的角色）的权限系统，后期新增第三方登录功能时，AI 可能忘记原有权限模型，生成一套独立的鉴权逻辑，导致系统出现「同一用户在不同模块权限不一致」的混乱问题。

二、上下文长度的「金鱼记忆」与知识滞后性

LLM 上下文窗口有限，无法记住大型项目的完整代码；训练数据有截止日期，易生成过时或幻觉代码。

「金鱼记忆」的工程风险

即使是 GPT-4o 等大模型，上下文窗口也仅支持约 128k tokens（约 10 万字），而中大型项目的代码量通常在百万行级别。例如，开发一个在线教育平台时，前期生成了课程播放模块的「进度保存」逻辑，后期新增「倍速播放」功能时，AI 可能忘记进度保存的底层实现，生成的倍速逻辑与原有进度同步机制冲突，导致用户切换倍速后进度丢失。

知识滞后的场景痛点

LLM 的训练数据存在时间差（如 2025 年的模型可能未包含 2026 年发布的 React 19 新特性、Next.js 15 的路由优化）。比如用 VibeCoding 生成一个 AI 绘图工具，AI 可能仍使用已废弃的 Stable Diffusion v1.x API，而最新的 v3.x 已经优化了生成速度和安全机制，导致生成的工具性能落后且存在潜在漏洞。

「幻觉」代码的致命影响

AI 可能编造不存在的 API、库函数或参数。例如，生成微信支付回调处理代码时，AI 可能虚构一个wxpay.verifySignV3()方法（实际微信支付官方 SDK 并无此函数），导致支付回调验证完全失效，攻击者可伪造支付通知窃取订单资金。

三、安全性与可靠性的「隐形地雷」

AI 缺乏安全意识，易生成含漏洞的代码；生成的代码未经严格测试，高并发或边缘场景下易崩溃。

安全漏洞的无声入侵

AI 没有「安全左移」的工程思维（核心是，把安全工作从传统的「开发后期 / 上线前」提前到「需求、设计、编码」等软件开发生命周期（SDLC）的更早期阶段 ），生成的代码常包含常见漏洞：

SQL 注入 ：生成的商品搜索接口直接拼接用户输入的关键词到 SQL 语句，如SELECT * FROM goods WHERE name LIKE '%${userInput}%'，攻击者可输入' OR 1=1 --窃取全表数据。
XSS 攻击：生成的评论展示模块未对用户输入的 HTML 标签进行转义，攻击者可嵌入恶意脚本窃取其他用户的 Cookie。
硬编码风险 ：为了快速实现功能，AI 可能将数据库密码、API 密钥直接写在代码中，如const DB_PASSWORD = '123456'，一旦代码泄露将导致核心数据被窃取。

可靠性的场景失效

AI 生成的代码缺乏生产级测试，在极端场景下极易崩溃：

高并发雪崩：生成的秒杀接口未做流量削峰或分布式锁处理，大促时大量请求同时触发库存扣减，导致超卖或数据库死锁。
边缘案例崩溃：生成的用户注册模块未处理「手机号含特殊字符」「邮箱格式超长」等边缘输入，导致用户提交异常数据时系统直接抛出 500 错误。
监控缺失 ：生成的代码通常没有完善的日志、链路追踪或熔断机制，线上出现问题时无法快速定位根因，比如支付失败后无法追溯是接口超时还是签名错误。

总结

Vibe Coding我觉得并不像是一种替代性质的工作模式，而是一个强大的效率倍增器 ，在未来Vibe Coding不会取代传统变成，更多的是形成一个互补的关系，未来的开发模式很有可能是混合模式：利用Vibe Coding处理前端和重复性工作，同时依赖程序员自身的扎实的框架知识来构建相关的核心业务逻辑，保证系统架构的健壮性和安全性。因此，最终，"框架思维"驾驭"Vibe工具"，才是未来我们的核心竞争力

LangChain

解决LLM嵌入应用的痛点

单独使用 LLM（如 GPT-4、Claude 3、文心一言）时，会遇到以下核心问题：

幻觉问题：生成不存在，错误或无事实依据的的内容

模型基于其训练数据中的"吞食异物"相关文本进行了错误生成，产生了幻觉。

提示词结构规范性

提⽰词的质量和⻛格直接决定输出结果的准确性和安全性。没有统⼀的规范会导致应⽤⾏为不可预测、难以调试，且⽆法规模化地优化效果

切换模型困难：切换大模型的成本是极高的，一旦选定一个模型，整个应用程序的代码与该模型的API是强耦合的

知识滞后：训练数据有截止日期，无法获取实时信息（如最新 API 文档、今日股市数据）；

无工具调用能力：不能直接执行代码、查询数据库、调用外部 API；

记忆缺失：单次对话外无长期记忆，无法记住用户历史偏好或上下文；

逻辑能力弱：复杂任务（如多步骤数据分析、代码调试）难以独立完成。

概述

LangChain 是一款专为大语言模型（LLM）应用开发设计的开源框架 ，核心目标是解决 LLM 本身的局限性（如上下文窗口有限、无法直接访问外部数据、缺乏工具调用能力等），通过将自然语言处理（NLP）流程拆解为标准化组件和灵活的 "链（Chain）" 机制，让开发者快速搭建出功能复杂、能力强大的 LLM 应用（如智能知识库、对话机器人、代码生成助手等）。

它不是一个 LLM 模型，而是连接 LLM 与外部资源、工具的 "桥梁"，目前已成为 AI 应用开发领域的主流工具之一，支持 Python（绝对主流）和 JavaScript/TypeScript 双语言生态。

核心

组件（Components）：⽤来帮助当我们在构建应⽤程序时，提供⼀系列的核⼼构建块，例如语⾔模型、输出解析器、检索器等。

⾃然语⾔处理流程（NLP）：指的是完成⼀个特定 NLP 任务所需的⼀系列步骤。例如，构建⼀个"基于公司⽂档的问答机器⼈"的流程可能包括：读取⽂档、分割⽂本、将⽂本转换为向量（嵌⼊）、存储向量、接收⽤⼾问题、搜索相关⽂本段、将问题和⽂本段组合发送给⼤语⾔模型（LLM）、解析模型输出并返回答案等

通过将自然语言处理（NLP）流程拆解为标准化组件和灵活的 "链（Chain）" 机制

比如

此时相对来说，提示词模板组件执行力一次，大模型组件也执行了一次，此链执行了一次

统一的模型调用：通过抽象化的接口支持多种大语言模型（例如 OpenAI GPT-4/5、Anthropic Claude 等）和嵌入模型，使开发者可以灵活切换不同模型供应商。

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

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

上下文记忆机制（Memory）：用于存储多轮对话中的状态信息。LangChain 曾提供多种记忆管理方案（如对话历史记忆和摘要记忆），以实现连贯的交互体验（注：该功能目前已由 LangGraph 支持，原有实现已过时）。

检索与向量存储集成：支持从外部加载文档，经分割和向量化处理后存储至向量数据库，在查询时检索相关信息并输入大语言模型，帮助构建检索增强生成（RAG）类应用。LangChain 兼容多种主流向量数据库（如 FAISS、Pinecone、Chroma）和文档加载工具，简化知识库应用的开发流程。

对于上述技术内容，LangChain 的开源组件和第三⽅集成可以轻松⽀持快速上⼿，帮助我们构建应⽤程序。除此之外，使⽤ LangGraph 可以构建⽀持⼈机交互的有状态代理。LangChain 公司也在围绕框架构建完整的⽣态系统，包括推出 LangSmith（⼀个⽤于调试、监控和评估 LLM 应⽤的平台）以及 LangGraph Platform（⽤于 LangChain 应⽤的部署、运维）等，为开发者提供从开发到⽣产的⼀站式⽀持。

LangGraph

解决LangChain的局限性

链式流程通常是线性的、预先定义好的步骤，难以处理需要循环、分⽀或⻓期状态维护的复杂场景。在构建多智能体协作、需要⼈⼯介⼊（Human-in-the-loop）或⻓时间运⾏的任务时，需要更灵活的⼯作流管理和状态持久化⽀持，它的主要局限性如下：

问题 1：难以处理循环和分支（无法动态路由和多次询问）

在 "信息收集" 阶段，用户第一次可能提供了一个不完整的订单号。链式流程是单向的，它无法自动 "跳回" 上一步再次请求用户补充信息。

结果：只能让整个链失败，或者生成一个僵硬的错误消息，用户体验非常差。无法实现 "只要信息不完整，就持续询问直到完整" 这样的逻辑。

问题 2：状态维护困难（无法长时间运行和记忆上下文）

客户服务对话通常是多轮的，可能持续几分钟、几小时甚至几天。传统的链在每次调用时都是 "无状态" 的。

结果：状态管理（记忆）的重担完全落在了开发者身上，需要依赖外部数据库或缓存来手动存储和读取对话状态，代码会变得非常臃肿和脆弱。

问题 3：难以融入人工介入（Human-in-the-loop）

当 AI 无法处理时，需要无缝地转交给人。在链式流程中，这意味着链的执行到此中断。无法优雅地实现暂停 AI 流程，等待人工处理完毕，再将结果返回，继续执行后续自动化步骤。

结果：整个流程会断裂成两半：AI 部分和人工部分。你需要构建另外的系统来通知人工、接收人工处理结果，并重新触发后续的链，这完全破坏了工作流的完整性和可管理性。

问题 4：僵化的流程（无法根据条件动态跳转）

不同的用户意图需要完全不同的子流程。例如判断用户意图：

是 "投诉"。我们的链可能预先设计为走 A->B->C 路径。
是 "产品咨询"，可能需要走 A->D->E 路径。

在链式结构中，实现这种条件分支非常笨拙，通常需要编写一个巨大的 "主链"，内部用一系列 if-else 语句来调用不同的子链。

结果：流程图的逻辑变成了代码中的控制流语句，而不是清晰可见的图形化结构。这使得工作流难以设计、调试和可视化。

概述

LangGraph 是 LangChain 团队在 2024 年推出的低层次编排框架 ，核心目标是解决传统 LangChain Chain（链式流程）的四大痛点：无法处理循环 / 分支、状态维护困难、难以融入人工介入、流程僵化。它通过图结构 + 状态化 + 可控的节点编排，让你能构建更复杂、更可靠的 AI 代理工作流。

在上述⽰例中，我们可以定义图状态，⽤于存储流程中的临时数据和决策点，例如：

intent : ⽤⼾意图（字符串，如 "return", "inquiry", "complaint"）。
collected_info : 字典，存储收集到的信息（如订单号、问题描述）。
needs_human : 布尔值，表⽰是否需要⼈⼯介⼊（默认 False）。
is_verified : 布尔值，表⽰信息是否已验证（默认 False）。
is_complete : 布尔值，表⽰流程是否完成（默认 False）。
message_history : 列表，存储对话历史，⽤于多轮交互。

核心定位：不是替代 LangChain，而是 "增强"

LangGraph 并非独立于 LangChain 的新框架，而是 LangChain 生态的延伸：

LangChain Chain：适合简单、线性的任务（如 "检索文档→生成回答"），开发快但灵活性不足。
LangGraph：适合复杂、非线性的任务（如多轮客服对话、代码生成 + 调试闭环、需要人工介入的审核流程），支持循环、分支、状态管理和人工干预。

简单来说：

简单任务用 Chain，复杂任务用 LangGraph。

核心概念：用 "图" 重新定义工作流

LangGraph 基于 "有向图" 模型设计，核心概念非常清晰，我们用客服对话场景（收集订单号→验证订单→处理问题→人工介入）来拆解：

概念	定义	客服场景示例
状态（State）	工作流的全局 "记忆"，存储所有节点的输入输出、对话历史、业务数据等，自动在节点间传递	存储用户输入的订单号、订单验证结果、对话历史、是否需要人工介入等信息
节点（Node）	工作流的最小执行单元，每个节点对应一个函数（如调用 LLM、调用工具、人工处理）	「收集订单号」节点（调用 LLM 询问用户）、「验证订单」节点（调用订单系统 API）、「人工处理」节点（触发人工客服弹窗）
边（Edge）	节点之间的连接关系，定义流程的走向	「收集订单号」→「验证订单」（订单号完整时）、「验证订单」→「人工处理」（订单验证失败时）
条件分支（Conditional Edge）	根据状态动态选择下一个节点，实现 "if-else" 逻辑	若订单号完整→进入「验证订单」节点；若订单号不完整→回到「收集订单号」节点（循环询问）
人工介入节点（Human-in-the-loop）	专门用于暂停 AI 流程、等待人工处理的节点，处理完成后自动恢复流程	当 AI 无法处理复杂投诉时，触发「人工处理」节点，人工客服回复后流程继续

它的优势主要体现在

循环与分支：LangGraph 中的节点（Node）可以连接到其他任何节点，包括自己。你可以轻松设置一个 "信息收集" 节点，如果信息不完整，就让流程再次循环回这个节点本身，直到条件满足为止。
动态路由：通过条件边，可以根据当前状态的值，动态决定下一个要执行的节点。例如，在 "分类" 节点之后，可以根据分类结果，自动路由到 "处理退货"、"处理咨询" 或 "处理投诉" 等完全不同的子图中去。
状态维护：LangGraph 有一个核心的状态对象，在整个图的执行过程中自动持久化和传递。每个节点都可以读取和修改这个状态。这意味着用户的对话历史、已收集的信息都会自动保留，轻松支持长时间运行的任务。
持久执行：构建能够经受住故障并能长时间运行的代理，自动从上次中断的地方恢复。
人机协作：通过在执行过程中的任何时刻检查和修改代理状态，无缝融入人工监督。
全面记忆：创建真正具有状态的代理，兼具用于持续推理的短期工作记忆和跨会话的长期持久记忆。
使用 LangSmith 进行调试：借助可视化工具深入洞察复杂代理行为，这些工具可追踪执行路径、捕获状态转换并提供详细的运行时指标。
生产级部署：借助专为处理有状态、长时间运行工作流的独特挑战而设计的可扩展基础设施，自信地部署复杂的代理系统。

要为重活而高兴，不要为死去的忧伤。 ------林清玄

🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀🍀

以上，就是本期的全部内容啦，若有错误疏忽希望各位大佬及时指出💐

制作不易，希望能对各位提供微小的帮助，可否留下你免费的赞呢🌸