LangChain 应用开发（一）：LangChain 概述与 AI 应用开发生态

目录

一、为什么需要 LangChain

1. AI 应用的发展历程

2. 单一大语言模型的局限性

二、LangChain 的定位

1. 什么是 LangChain

2. LangChain 能解决什么问题

三、LangChain 的应用场景

四、大模型应用开发

1. 大模型应用开发方向

2. RAG 开发简介

五、Agent 基本组成

1. 什么是 Agent

2. Agent 架构

3. Agent 工作流程

六、LangChain 家族

1. 家族成员关系

2. 各组件职责与定位

七、LangChain 版本介绍

1. v0.3 与 v1.x 版本

2. LangChain v1.2 核心模块组成

八、大模型时代下的就业方向

1. 核心岗位职责

总结

一、为什么需要 LangChain

数据处理与清洗构成了传统数据工程的下半场，而随着大语言模型的全面普及，软件开发模式正在经历一场根本性的重塑。以LangChain为代表的智能开发框架，将引领我们进入构建智能化应用的新时代

1. AI 应用的发展历程

回看软件开发的历史，AI 应用的演进经历了三个标志性阶段：

• 传统软件时代：以 if-else 为骨架，程序的每一个路径都需要程序员显式预定义。系统具备极高的确定性，但也极其僵硬

• 大模型时代（自然语言交互）：ChatGPT 的诞生打破了这一现状。我们可以用自然语言代替代码作为输入，LLM 凭借海量的预训练知识与理解能力，能够完成总结、翻译、意图识别等复杂任务

• 智能体（Agent）时代：单纯的文本问答远不能满足生产诉求。应用需要具备感知环境、规划步骤、调用工具、持久记忆并最终执行任务的能力

大模型的核心改变在于：它将计算能力从底层的 CPU/GPU 指令转移到了高层的概率推理上。软件开发者从撰写逻辑分支转变为推理流程与环境约束的编排

2. 单一大语言模型的局限性

尽管 GPT-4、Claude 等模型展现出了惊人的推理能力，但作为一个概率文本生成器，单体 LLM 存在着难以逾越的瓶颈：

• 为什么 ChatGPT 不能直接操作数据库？

  LLM 的本质是预测下一个 Token，它运行在封闭的推理服务器内，既没有与你的私有数据库建立连接，也不掌握具体的数据表结构。即使它输出了正确的 SQL 语句，也没有权限和环境去实际执行它

• 为什么不能主动调用天气 API？

  LLM 是被动接收输入的。如果不通过代码去抓取实时 Weather API 的 JSON 响应，并重新作为 Context 塞回 Prompt 中，大模型就只能根据训练截止日期前的历史数据进行幻觉回答

• 为什么不会长期记忆？

  大模型的上下文窗口是无状态且有限的。每次 HTTP 请求都是独立的，模型无法自动感知半个月前你对它说过的话，除非有外部存储系统不断帮它维护并注入历史对话线索

单体 LLM 就像是一个大脑——智商高，却断手断脚、没有记忆、不连网络。我们需要一个中间件来为这个大脑装上双手、双眼与存储器

这正是 LangChain 存在的根本原因

二、LangChain 的定位

在大模型技术爆发式增长的背景下，许多刚接触 AI 应用开发的工程师常常会对概念产生混淆。要准确理解 LangChain，首先需要划清它与底层大语言模型（LLM）之间的界限

核心定位：LangChain 不是大模型，而是连接大模型与外部的开发框架

它自身不训练、不提供任何底层的神经网络模型，而是以中间件的形式，将各种散落的大模型 API、数据源、第三方工具与业务逻辑无缝缝合在一起

1. 什么是 LangChain

LangChain是一个开源的 AI 应用开发框架，旨在为开发者提供一套标准化的中间层

如果把 GPT-4、Claude 或 DeepSeek 这种大模型比作计算机的CPU，那么 LangChain 就是操作系统的SDK 和驱动程序：

• 输入/输出适配：将统一的 Prompt 转换为各家模型支持的 API 格式

• 外设连接器：提供接口去连接数据库（硬盘）、搜索引擎（网络）和本地文件系统

• 流程调度器：控制多步骤任务的处理顺序与数据流向

2. LangChain 能解决什么问题

在没有应用开发框架之前，开发者想要用原生代码构建一个 AI 应用，会面临诸多痛点。LangChain 正是为解决这些工程难题而生的：

• 打破数据孤岛：原生 LLM 无法读取本地的商业合同、内部数据库。LangChain 提供了上百种文档加载器与向量数据库集成，能够高效构建私有 knowledge base

• 赋予行动能力：LLM 本身只能生成文本。LangChain 封装了结构化的工具调用机制，让模型可以主动发起 HTTP 请求、执行 Python 代码、查询 MySQL 数据库

• 维系多轮对话状态：HTTP 接口是无状态的。LangChain 提供了灵活的记忆组件，能够自动对历史对话记录进行滑动窗口裁剪、摘要压缩，并在每次请求时自动注入 Context

• 编排复杂业务工作流：对于多步骤任务，LangChain 提供了专用的表达语言与状态机机制，极大降低了复杂链条的编写门槛

三、LangChain 的应用场景

借助 LangChain 强大的工具连接与逻辑编排能力，大模型应用已经从简单的一问一答走向了深度融合业务流程的自动化阶段。以下是当下最主流的场景与真实落地案例

检索增强生成（RAG）

RAG 通过将企业私有文档向量化存储，在用户提问时检索相关切片作为上下文喂给大模型，彻底解决大模型知识过期和产生幻觉的问题

• 真实案例（企业文档问答）：某公司将上千页的 HR 制度与技术手册接入知识库。员工提问 "年假怎么扣除" 时，系统能迅速匹配对应条款并生成带有原文页码引用的准确回答

Agent 智能体

Agent 赋予了大模型自主规划、记忆与工具调用的能力，让模型能够像人类员工一样，接收一个模糊目标后自发完成多步骤的复杂任务

• 真实案例（数据分析助手）：数据分析师输入 "帮我分析上季度华东区销售额下滑的原因"，Agent 能自主将自然语言转为 SQL 查询数据库、清洗数据，并调用绘图库生成可视化图表

对话系统

利用 LangChain 的记忆模块与意图路由，可以搭建具备长上下文理解能力、能随时对接业务系统的多轮对话智能体

• 真实案例（电商智能客服）：客服不仅能解答常见疑问，当用户提出 "我要修改收货地址" 时，系统能识别意图并自动调用底层 API，直接在后端帮用户完成地址修改

AI 自动化办公

将确定性的业务流程与大模型的语义理解能力结合，构建跨系统、跨平台的智能化操作流水线

• 真实案例（AI 办公自动化）：系统自动监控客户反馈邮箱，收到邮件后提取关键诉求、进行情感分类，生成回复草稿的同时自动向 Slack 频道发送摘要提醒

AI 编程助手

结合代码库语义检索与 AST 解析，协助开发团队快速理解已有项目架构、生成单元测试以及定位潜在 Bug

• 真实案例（代码库问答）：新员工加入项目组后，直接向 AI 助手提问 "订单支付逻辑在哪个模块？是如何处理异常重试的"，AI 能够准确定位相关代码文件并输出完整的调用链路解析

四、大模型应用开发

AI 应用开发是指以大语言模型为核心大脑，结合提示词工程、上下文管理、外部数据源与工具 API，将原生的模型推理能力转化为能够稳定解决业务问题的完整软件系统的工程实践

1. 大模型应用开发方向

当下大模型应用的开发实践主要沿着四个方向演进，它们代表了从简单文本交互到高自治系统的能力层级：

• Chat（对话系统）：聚焦多轮上下文管理、提示词约束与意图识别的基础交互形态

• RAG（检索增强生成）：结合向量检索与私有知识库，解决大模型知识过期和幻觉问题

• Agent（智能体）：具备规划、记忆与工具调用能力，能够自主完成复杂多步骤任务

• Workflow（工作流编排）：将确定性的业务图谱与大模型的智能节点结合，构建高鲁棒性的自动化流水线

2. RAG 开发简介

RAG 是目前企业落地最广泛的方向。其核心逻辑是在调用大模型生成回答之前，先从外部知识库中检索（Retrieve）出相关的背景资料，作为上下文增强（Augment）填充给 Prompt，最后交由模型生成（Generate）精准答复

为什么需要 RAG

大语言模型虽然强大，但在处理业务时存在两大缺陷：

• 知识冻结：大模型训练成本高、周期长，模型权重无法实时学习最新的动态信息（如无法回答 "今天有哪些热门电影"）

• 大模型幻觉：面对未学习过或不熟悉的陌生领域时，模型无法给出准确答复，容易编造答案

RAG 工作链路

RAG 的完整运作包含 "离线知识入库"与 "在线检索生成"两条主线，涵盖检索（Retrieval）、增强（Augmentation）与生成（Generation）三大核心步骤

• 离线知识入库（知识更新）

  • 文件解析：通过加载器提取 PDF、Word、二维表等非结构化或半结构化数据

  • 文件切割：将长文本拆分为固定长度的文本块

  • 向量化与入库：调用嵌入模型（Embedding Model）将文本块转化为高维数值向量，存入向量数据库建立索引

• 在线检索生成

  • 检索：将用户输入的 Query 转换为向量，在向量数据库中进行相似度计算，召回相关度较高的文本片段

  • 增强：将召回的文本片段作为 Context，与用户 Query 一起填充进提示词模板中

  • 生成：把组装好的最终 Prompt 发送给 LLM，大模型依据上下文输出有据可查的回答

RAG 的难点与 Reranker

在实际工程开发中，简单的 RAG 往往难以达到要求，主要集中在以下环节：

• 文件解析难：PDF 文件中常常混杂有复杂表格、排版图片，提取精准文本难度大

• 文件切分难：切分粒度没有固定标准。切得太碎会丢失语义上下文，切得太长会导致无关噪声过多

• 知识检索与重排序（Reranker）：随着向量数据库中文档数量的激增，仅靠基于向量距离的粗检索，召回准确率会明显下降

为了提升召回质量，工程上通常会引入Reranker（重排序模型）：

五、Agent 基本组成

RAG 为大模型配备了一个可随时查阅的知识库，而Agent（智能体）则是为大模型装上了手和脚，使其能够独立思考、规划任务并主动执行动作的自主系统

1. 什么是 Agent

在传统的应用模式中，大模型只是一个被动的问答终端——用户发问，模型输出文本，流程终止

而在Agent 模式下，大模型充当的是一个自主决算的大脑。面对用户给出的复杂或模糊的目标，Agent 能够自发地将大任务拆解为若干子步骤，主动选择并调用外部工具获取实时数据，根据返回的结果不断反思与调整策略，直到最终完成任务

2. Agent 架构

在学术界的通用定义中，Agent 的组成可以总结为如下公式：

以下是整个系列中都将反复调用的Agent 经典架构图：

为了让 Agent 在真实的业务场景中稳定运行，五大模块各自承担着明确的分工：

• LLM（核心大脑）

  • 职责：负责整个智能体的意图识别、逻辑推理与决策分发。它是智能体思维能力的根本

• Planning（规划与思考）

  • 职责：包含任务分解和自我反思

  • 常见模式：如ReAct，指导模型按照 "思考下一步该做什么 -> 执行动作 -> 观察结果 -> 修正下一步思考" 的循环持续推演

• Tools（工具库）

  • 职责：大模型与软件系统交互的接口集

  • 典型分类：谷歌搜索、Python 解释器、数据库 SQL 执行器、公司内部 RESTful API、高德地图 API 等

• Memory（记忆系统）

  • 短期记忆：当前的 Context Window 区域，保存正在进行的多轮对话记录和思考步骤

  • 长期记忆：借助向量数据库或持久化存储，让 Agent 在跨会话场景中记住用户的偏好、历史习惯与长效知识

• Action（动作执行与反馈）

  • 职责：将 LLM 决策出的工具指令转化为实际的代码运行或 API 请求，并将拿到的数据/状态重新回传给 Memory 与 LLM，形成封闭式的感知-决策-行动控制环

3. Agent 工作流程

以用户提问“帮我查询明天北京的天气，并根据天气推荐一套穿搭”为例，Agent 的执行流程如下

六、LangChain 家族

LangChain 已从单一开发框架进化为覆盖智能体系统全生命周期的完整技术生态。该生态系统由四大核心组件支撑：LangChain、LangGraph、Deep Agent 以及 LangSmith 组成

1. 家族成员关系

我们可以将 LangChain 家族的整体生态拆解为如下结构：

2. 各组件职责与定位

1. LangChain：生态基石与基础组件

• 定位：整个生态的起点与底层标准库

• 主要功能：提供标准化的模型接口、提示词模板、文档加载器、向量库连接器，以及基础的 LCEL 链式管道语法

• 适用场景：适合构建简单的问答系统、单步 RAG 知识库或线性工作流

2. LangGraph：复杂的 Agent 编排

• 定位：专为复杂、循环、多角色协同 Agent 打造的状态机图编排框架

• 主要功能：传统 LangChain 无法优雅地处理 "循环重试" 和 "状态记忆"；而 LangGraph 引入了节点（Nodes）、边（Edges）与全局状态（State），支持定义分支、循环、持久化 Checkpoint 以及人工干预

• 适用场景：多 Agent 协作系统、带有自我反思机制的复杂 Agent、长流程业务工作流

3. LangSmith：调试评估

• 定位：大模型应用的可观测性、调试与评估平台

• 主要功能：大模型的运行过程如同黑盒。LangSmith 能够完整记录每一次调用的 Prompt 输入、Token 消耗、内部工具调用链条，并支持设置测试集对回答质量进行自动化评估

• 适用场景：应用开发阶段的 Bug 排查、性能瓶颈分析，以及线上生产环境的监控运维

4. Deep Agents：高阶框架

• 定位：基于 LangChain 与 LangGraph 构建的更高层级的自治 Agent 解决方案

• 主要功能：内置了文件系统支持、深度任务规划器以及长时间运行的调度能力，进一步降低了构建类似 AutoGPT 或 Devin 式复杂智能体的门槛

• 适用场景：需要进行跨文件操作、长周期规划与高度自主决策的项目

在实际的项目工程落地中，这四个组件通常以如下方式协同配合，贯穿 AI 应用开发的生命周期：

七、LangChain 版本介绍

如果查阅网上的教程，你会发现 LangChain 的代码写法存在极大的差异，甚至很多代码放到最新的 Python 环境中会直接报错。这是因为 LangChain 经历了一场剧烈的架构重构

1. v0.3 与 v1.x 版本

• v0.x 早期时代：所有的核心代码、第三方工具（如各类向量库、大模型 SDK）都挤在同一个 包中。只要某个第三方 API 发生更新，整个包就可能产生破坏性更新，导致项目频繁崩塌

• v1.x 现代时代：实现了彻底的模块化解耦。核心抽象独立出来，确保了极其出色的向下兼容性与项目稳定性

为什么推荐使用最新版（v1.2+）

1. 接口稳定：核心语法与基础设施在 langchain-core 中固化，企业级项目升级不再崩溃

2. 依赖轻量化：你可以根据项目需求按需安装包，无需被迫下载几百个用不上的第三方依赖

3. 彻底摒弃过时 API：旧版本的 LLMChain 等传统写法在 v1.x 中已被全量替代为更高效的 Runnable 与 LCEL 表达式

2. LangChain v1.2 核心模块组成

在最新的 v1.2 中，LangChain 的代码库被拆分为以下四个核心模块：

• langchain-core：框架最底层的核心抽象（如 BaseModel 等）。轻量且绝对稳定

• langchain-community：由社区共同维护的通用第三方扩展库（上百种文本加载器、向量数据库连接器）

• 官方 Partner 专有包：由官方重点维护的高频模型包（如 langchain-openai、langchain-anthropic 等），升级维护速度最快

• langchain：高阶组件组合层，包含预置的通用链和检索逻辑

八、大模型时代下的就业方向

随着 LLM 全面走向工程落地，大模型应用开发不再仅是算法工程师的专利，传统后端、数据工程师与前端开发也纷纷迎来技术栈升级。围绕 LangChain / LangGraph 衍生出的岗位正在快速演进

1. 核心岗位职责

• AI 应用开发工程师

  • 核心职责：负责企业级 AI 业务功能的快速落地，将大模型能力引入现有的业务系统与工作流中

  • 核心技能：Python / TypeScript、LangChain / LCEL 管道语法、Prompt 工程、FastAPI / Web 框架集成

• RAG 工程师

  • 核心职责：专注于企业私有知识库的搭建、非结构化文档解析切片、混合检索算法设计与精准度调优

  • 核心技能：向量数据库、Embedding 模型选型、Reranker 重排序、Chunking 策略与评估指标

• Agent 工程师

  • 核心职责：负责设计高自治智能体、复杂状态机工作流以及多 Agent 协同系统，解决长周期任务的自主规划与执行

  • 核心技能：LangGraph、状态机设计、Tool Calling（ReAct 模式）、人机协同设计

• MCP 工程师

  • 核心职责：基于 Anthropic 发起的 MCP（Model Context Protocol，模型上下文协议），开发标准化的上下文连接器与工具插件，打破大模型与企业内网数据的访问壁垒

  • 核心技能：MCP 协议标准、JSON-RPC 通信、系统级 API 接入、高并发工具服务设计

• AI 后端工程师

  • 核心职责：将大模型推理能力融合至传统微服务架构，解决长文本流式响应、高并发异步任务调度与系统级可观测性

  • 核心技能：AsyncIO / 协程高并发、SSE / WebSocket 流式传输、LangSmith 调试评估、向量数据库集群运维

总结

本章作为 AI 应用开发系列的开篇，首先介绍了大语言模型的发展背景以及从传统软件开发向 AI 应用开发演进的过程，分析了单一大语言模型在知识获取、工具调用、任务规划和长期记忆等方面的局限性，并引出了 LangChain 在 AI 应用开发中的定位与价值。同时，我们认识了 LangChain 家族的核心组件、典型应用场景以及当前主流的大模型应用开发方向，对 RAG、Agent 等重要概念建立了初步认识，并完成了开发环境的搭建，为后续学习做好准备

从下一篇开始，我们将正式进入LangChain 核心组件的学习，逐步掌握模型调用、Prompt 构建、Runnable、Tool Calling、Agent 等核心技术，最终完成现代 AI 应用的开发与实践