# 9 - LangChain 概述与架构 --- **本章课程目标：** - 建立对 **LangChain** 的整体认识，知道它是什么、解决什么问题、在 AI 应用开发里处于什么位置。 - 理解 LangChain 在 **1.x 时代**的产品边界、包结构、版本演进，以及它与 **LangGraph、LangSmith、Deep Agents** 的关系。 - 建立对 **Model I/O、Chains、Memory、Retrieval、Tools/Agents、Callbacks** 这六类教学视角的整体认知。 **学习建议：** 这一章先当成 LangChain 的地图，不急着记 API。读完最好能说清三件事：LangChain 帮你组织哪些能力、它不负责哪些底层能力、1.x 写法和旧资料里的 0.x 写法为什么会不一样。看完后直接进入 [第 10 章](10-LangChain快速上手与HelloWorld.md) 跑一次最小调用，抽象概念会落得更稳。 **官方文档与资源**：详见 [工具导航与参考资料索引 - LangChain](工具导航与参考资料索引.md#LangChain)。 --- ## 1、LangChain 简介 ### 1.1 定义 **LangChain** 是一个面向 **LLM 应用开发**的开源框架。它本身**不是大模型**，也**不是数据库**，更**不是知识库平台**；它更像一层“**应用编排层**”，负责把模型、提示词、外部知识、工具、记忆、输出解析、调试追踪等能力组织成一个完整、可维护、可扩展的 AI 应用。 举个例子，在一个“企业知识库问答助手”里，用户提问后，系统需要先去向量库检索相关资料，再把检索结果和问题一起组装成 Prompt，随后调用大模型生成答案，最后把结果整理后返回前端。这里真正扮演“连接者”和“组织者”角色的，就是 LangChain。 一句话来说，**LangChain = 用代码把大模型和外部世界连接起来的应用开发框架。** 其中，**Lang** 指 Language Model，**Chain** 指把多个环节串起来形成流程。最早的 LangChain 确实以“链式调用”闻名，但发展到今天，它已经不只是“链”，而是围绕 **Agent、RAG、工具调用、状态管理、可观测性** 形成了一整套生态。官方在发展历程中提到，LangChain 作为 Python 包公开发布于 **2022 年**，比 ChatGPT 正式发布还早约一个月，因此它几乎伴随了生成式 AI 应用开发的整个爆发期。 LangChain 在 GitHub 上的热度变化如下图所示： ![LangChain 主仓库（langchain-ai/langchain）GitHub Star 历史增长曲线，2023 初至 2025 初由近零增长至约 10 万+（star-history.com 风格图）](images/9/9-1-1-1.png) 从工程视角看，LangChain 的价值不在于“替你发一次请求”，而在于帮你把下面这些原本零散的东西组织起来： - 不同厂商的大模型调用方式 - Prompt 与多角色消息 - 结构化输出与解析 - 检索增强生成（RAG） - 工具调用、Agent、多步任务 - 记忆、会话状态、持久化 - 日志、追踪、调试、评估 这也是为什么它会被很多人看作 AI 应用开发里的“基础框架”。 ### 1.2 为什么需要 LangChain 如果你只是偶尔调一下模型 API，直接用 OpenAI、阿里百炼、DeepSeek、智谱等厂商 SDK 完全没问题；但一旦进入真实项目，单纯“把一个字符串发给模型，再拿回一段文本”的开发方式很快就会暴露出一批工程问题。 ![大语言模型单独使用时的典型局限：知识截止、无实时联网、难接私有数据与数据库、输出稳定性与工具调用等（示意图）](images/9/9-1-2-1.png) 常见问题包括： - **模型接口不统一**：不同厂商 SDK、参数命名、返回结构各不相同，切换模型成本高。 - **输入输出不稳定**：今天让它输出 JSON 成功，明天稍微换个问题就可能跑偏。 - **很难连接外部知识**：企业文档、数据库、向量库、内部 API 都需要手动接。 - **多步任务难维护**：例如“先检索，再总结，再调用工具，再组织回复”，靠手写流程容易乱。 - **多轮对话难管理**：你需要决定哪些历史消息保留、何时裁剪、何时持久化。 - **线上排查困难**：模型为什么答错、工具为什么没调、哪一步慢、哪里丢上下文，光看日志很难定位。 LangChain 并不会神奇地消灭这些复杂度，但它给你提供了一套统一抽象，让你能用更规范的方式去解决它们。 ### 1.3 已经能直接调模型了，为什么还要学 LangChain 答案很简单：**直接调 API 可以，做简单任务时甚至更直接；但只要你开始做“应用”，框架就会越来越有价值。** 最典型的类比，就是 Java 里的 **JDBC** 或 **Spring**。你的业务代码不想被某一个数据库或某一个中间件写死，于是你希望中间有一层统一接口来隔离差异。在大模型应用里，这一层统一抽象、统一编排、统一接入的角色，LangChain 很大程度上就在承担。 ![JDBC 与 LangChain 的类比：左侧为 Java 经 JDBC 对接多种数据库；右侧为 AI 应用经 LangChain 对接多种模型 API（直连单一 API「可行但不建议」的示意）](images/9/9-1-3-1.jpg) 放到项目开发里，两种路线的边界大致是： - **只调 API**：适合单次文本生成、简单脚本、快速验证。 - **用 LangChain**：适合做成真实应用，例如客服助手、知识库问答、数据分析助手、工具调用 Agent、多轮对话系统。 所以，LangChain 不是“必须学”，但如果你的目标是做 **RAG、Agent、企业级 AI 应用、AI 服务接入现有业务系统**，它会显著降低你后续的组织成本。 ### 1.4 LangChain 与 Coze / Dify 的区别 很多人第一次接触 LangChain 时，都会问一句：**“我不是已经会用 Coze 或 Dify 了吗，为什么还要学这个？”** 本质上，它们不是同一类东西： | 维度 | Coze / Dify 等平台 | LangChain | | ------------ | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | **是什么** | **产品 / 平台**：通过网页可视化界面、工作流节点、知识库管理等方式搭建 AI 应用 | **代码框架 / 库**：在 Python 或 JS 中以代码方式编排模型、工具、RAG、Agent | | **使用方式** | 打开浏览器，拖拽节点、配置模型、填写提示词、连接知识库，最后发布应用或 API | 在本地或服务器写代码，安装依赖，调用 LangChain API 构建自己的 AI 应用 | | **适合谁** | 产品、运营、低代码开发者，或希望快速验证业务想法的人 | 开发者、后端、算法工程师，需要把 AI 能力深度接入已有系统的人 | | **灵活性** | 受限于平台已有节点、插件、部署方式和权限设计 | 由代码完全控制，可接内部 API、自建数据库、私有模型、定制工具链 | | **典型场景** | 快速做一个客服机器人、知识库问答、流程自动化 Demo | 做企业内部 AI 中台、复杂 RAG 服务、可定制 Agent、与业务系统深度耦合的服务 | 实际项目里，这两类工具经常不是“二选一”，而是**先平台、后框架；先低代码验证，再代码化落地**： - 在业务探索阶段，用 **Coze / Dify** 快速验证需求。 - 在需要深度定制、接公司内部系统、做复杂编排时，用 **LangChain / LangGraph** 重构为代码服务。 这个思路，和你在本套教程里前半部分先学 Coze / Dify，后半部分再进入 LangChain / LangGraph，正好是一致的。 ### 1.5 为什么现在更适合学 现在学习 LangChain，时机其实比前两年更合适。原因不是“它更简单了”，而是**它的边界变清晰了**。 - **官方主线已经进入 1.x 时代**：相比早期 0.x 快速迭代、命名变动频繁的阶段，1.x 的学习入口更清晰，重点放在 `create_agent`、统一模型初始化、消息、工具、记忆、检索和可观测性上。 - **LangChain、LangGraph、LangSmith 的分工更明确**：你更容易理解“什么时候用高层框架，什么时候用底层图编排，什么时候做调试与评估”。 - **生态成熟**：官方文档、Reference、Learn 教程、Academy 课程已经形成闭环，不再只是零散博客和社区笔记。 - **应用场景更真实**：过去很多教程停留在 Demo 级别；现在官方内容和社区实践都更强调生产可用性，例如人审、持久化、Tracing、评估、部署等。 简单说，**现在学 LangChain，不再只是学一个“会不会调模型”的库，而是在学一套 AI 应用工程化方法。** ### 1.6 优势、边界与不足 LangChain 的优势很明显，但它也不是银弹。学习时要同时看到它的“能做什么”和“不能替你做什么”。 **优势：** - 统一模型接口，降低模型切换和多模型共存成本。 - 提供 Prompt、Message、Parser、Retriever、Tool、Agent 等常用抽象。 - 能把“单次调用”提升为“可维护流程”。 - 与 LangGraph、LangSmith、MCP 等生态衔接紧密，利于走向复杂应用。 - 资料多、案例多、社区活跃，适合建立体系化认知。 **边界：** - 它**不会替你设计业务逻辑**，只是帮你更好地实现。 - 它**不会替你训练模型**，模型能力强弱仍取决于底层模型。 - 它**不会替你存业务数据**，向量库、数据库、对象存储仍要你自己选型。 - 它**不会天然让效果变好**，Prompt、知识质量、工具设计、评估流程依然是关键。 **不足与槽点：** 1. **版本变化快**：老教程里的类名、导入路径、写法，很可能在新版本里已经迁移。 2. **抽象多，学习成本不低**：初学时容易觉得“明明只是调个模型，为什么多了这么多概念”。 3. **历史包袱真实存在**：很多文章还在讲 `LLMChain`、`ConversationChain`、旧版 AgentExecutor，但新项目未必应照搬。 4. **文档存在新旧并存现象**：官方文档已经比早期稳定很多，但生态广，仍会碰到版本语境不一致的问题。 所以结论很明确：**LangChain 适合做 AI 应用，但要用“工程框架”的心态去学，不要把它当成一个简单工具函数库。** ### 1.7 扩展：LangChain4J 简介 如果你的技术栈主要是 Java，可以了解 **LangChain4J**。它本质是“Java 生态里的 LangChain 风格框架”，常与 Spring Boot、Spring AI、企业中台场景搭配使用，适合 Java 团队把 LLM、RAG、Tools、Agent 等能力整合进现有系统。 - **等价理解**：LangChain for Java - **官方地址**：https://github.com/langchain4j/langchain4j - **补充学习**：若你未来要做企业 Java 项目接入大模型，LangChain4J 会是一个很常见的关键词 - **视频教程**：https://www.bilibili.com/video/BV1mX3NzrEu6/ （尚硅谷-周阳） --- ## 2、LangChain 定位 ### 2.1 大模型开发体系分类 如果把大模型相关工作从底到顶做一个粗略分层，大致可以分为三类： - **基础模型层**：预训练、对齐、推理优化、模型架构设计，例如 GPT、Qwen、DeepSeek、GLM 等背后的模型研发。门槛高、投入大，通常要求较强的数学、深度学习和大规模工程背景。 - **模型定制层**：在「基础模型层」的基础上做领域微调或专用优化（金融、医疗、法律等），偏模型训练/微调与行业落地。 - **应用开发层**：把模型接入业务流程，做成聊天助手、知识库问答、Agent、工作流系统、数据助手等应用。 **LangChain 主要服务的，就是第三层：应用开发层。** 它不负责训练模型，也不直接替代推理服务平台；它负责的是：**如何把模型能力变成一个能工作的应用系统。**这里要先分清边界：LangChain 更接近 **AI 应用开发框架**，不是模型研究工具。 ### 2.2 应用技术架构 下面这张图可以帮助你理解 LangChain 在系统架构中的位置： ![LLM 应用四层架构：UI 交互层、服务/链层、模型层、存储层及数据流方向；LangChain 主要处于服务/链层](images/9/9-2-2-1.png) | 层级 | 这层负责什么 | 常见对象 / 产品 | LangChain 在哪里 | | ----------------- | ---------------------------------------------------------------------------- | --------------------------------------------------- | -------------------------------------- | | **UI 交互层** | 用户交互入口，例如网页、App、管理后台、聊天界面、表单页面、可视化工作流界面 | Web 前端、管理后台、Langflow、聊天窗口 | 不在这一层 | | **服务 / 编排层** | 负责把模型、Prompt、检索、工具、记忆、输出解析、状态流转等能力组织成业务流程 | **LangChain**、LangGraph、自研 AI 服务层 | **LangChain 主要就在这一层** | | **模型层** | 提供 LLM、Embedding、Rerank、多模态模型等基础能力 | OpenAI、阿里百炼、DeepSeek、Ollama、Hugging Face 等 | LangChain 通过统一接口调用这一层 | | **存储层** | 存储原始文档、向量、会话、用户状态、业务数据 | MySQL、Redis、Pinecone、Chroma、Milvus、对象存储等 | LangChain 会访问这一层，但不替代这一层 | **数据流**：请求 **自上而下**（用户 → 服务/链 → 模型 → 存储），结果 **自下而上**返回用户；LangChain 处在 **服务/编排层**，串联 UI、模型与存储，而不是替代其中任一层。 > **为什么说 LangChain 相当于 Java 里的 Spring Boot？** > 因为**干的事很像**：都是「**把多种异构组件整合到一个应用里，用统一抽象让你写业务逻辑，框架管连接和编排**」。 > > - **Spring Boot**：在 Java 里整合数据库（MySQL）、缓存（Redis）、消息队列（Kafka）、HTTP 接口等——你写业务代码，Spring 管配置、依赖注入、生命周期；换数据源或加中间件时改配置即可，不必手写一堆连接代码。 > - **LangChain**：在大模型应用里整合各种模型（GPT、通义）、向量库（Pinecone）、工具、记忆等——你写「链怎么串、Agent 用什么工具」，LangChain 管何时调模型、何时查库、怎么拼 prompt；换模型或加 RAG 时改配置与链即可，不必手写每次请求和拼装。 > 所以常说：**LangChain 是 AI 应用开发里的「Spring」**——站在「服务/链层」，把下层模型和存储、上层交互串起来，你专注业务编排，框架负责对接各组件。 ### 2.3 使用场景 理解“位置”之后，再看“职责”就会清晰很多。真实项目里，LangChain 往往承担下面几件事： 1. **统一接模型**：同一个项目同时接入通义、DeepSeek、OpenAI、Ollama，本质上是在做多模型编排。 2. **统一处理输入输出**：用 PromptTemplate、消息对象、输出解析器来规范请求与结果。 3. **组织固定流程**：把“提问 → 检索 → 生成 → 解析”做成稳定链路。 4. **接入工具与外部系统**：比如天气查询、数据库查询、内部 API、工单系统、邮件系统。 5. **管理状态与记忆**：多轮聊天、会话上下文、用户偏好、长期记忆。 6. **做调试和评估**：把调用过程 trace 出来，定位哪一步出了问题。 如果结合你这套教程的项目场景来看，就非常好理解了： - 在 **Coze / Dify** 阶段，我们做了商品评论分析、客户投诉分类、客服对话记录分析等平台化应用。 - 进入 **LangChain** 阶段后，我们开始把这些“AI 能力”落到代码服务里，例如多模型接入、输出解析、记忆管理、Tools、RAG、MCP、Agent。 - 再往后到 **LangGraph** 阶段，本质上是在进一步解决“流程更复杂、状态更多、控制更细”的问题。 这条路线，本质是从“会用 AI 平台”走向“会做 AI 系统”。 ### 2.4 岗位与招聘对标 目前在招聘平台上，越来越多岗位会明确写出： - 熟悉 LangChain / LangGraph / RAG / Agent - 有大模型应用开发经验 - 能接入向量库、知识库、工具调用 - 熟悉 Prompt、模型调用、可观测性、评估 换句话说，**LangChain 已经不是“可选了解项”，而是很多 AI 应用工程岗位的高频关键词**。当然，不同公司未必只用 LangChain，但你一旦掌握这套思维，再迁移到其他框架会快很多。 > 附：从事「基础通用大模型」开发者简历（示意） ![招聘场景中简历片段示意](images/9/9-2-4-1.png) --- ## 3、LangChain 包与版本对比 ### 3.1 版本演进：从“链”到“Agent + 图 + 生态” LangChain 的演进大致可以分成三个阶段来理解： **第一阶段：0.0.x / 0.1 早期阶段，特点是“链优先”。** 这一时期大家更多把 LangChain 理解成“Prompt + LLM + Chain”的组合工具，很多经典写法例如 `LLMChain`、`ConversationChain`、各种旧版 AgentExecutor 都是从这里来的。 ![LangChain V0.1 时期架构示意：以链（Chain）与组件组合为主线的经典教学图](images/9/9-3-1-1.gif) **第二阶段：0.2 / 0.3 阶段，开始重视生态拆分和工程边界。** 这一时期官方逐渐把 LangChain、集成包、部署与调试能力拆开，形成更清晰的产品层次。你也会在很多 2024 年左右的教程里看到这套结构图。 ![LangChain V0.2/V0.3 生态：架构、组件、部署三层示意](images/9/9-3-1-2.gif) > **说明**：上图将 LangChain 生态分为三层——**架构（Architecture）**、**组件（Components）**、**部署（Deployment）**。 > > - **最底层（架构）**：LangChain + LangGraph，均开源。LangChain 负责链式编排与基础抽象，LangGraph 提供图结构、循环与多步推理。 > - **中间层（组件）**：Integrations 等与外部 API、数据库、第三方模型的集成。 > - **最顶层（部署）**：LangGraph Cloud（云部署）、LangSmith（调试、测试、监控、提示管理等商业化能力）。 **第三阶段：1.x 阶段，重点变成“精简主包、强化 Agent、与 LangGraph 深度融合”。** 官方文档在 1.x 里强调：`langchain` 主包只保留核心高层能力，集成拆到独立 provider 包，旧能力迁到 `langchain-classic`，Agent 则建立在 LangGraph runtime 之上。 ![LangChain 1.x 轻核心示意：langchain-core 为底座，主包精简、集成拆至各 provider 包并与 LangGraph 等协作](images/9/9-3-1-3.gif) 如果记一个时间点即可： - **2024 年 2 月**：LangGraph 开源发布 - **2025 年 10 月 20 日**：LangChain 官方发布 **v1.0.0** - **现在**：学习 LangChain 应以 **1.x 文档语境**为主 ### 3.2 当前官方产品线理解 现在官方已经不只是在讲一个 `langchain` 包，而是在讲一整套产品线。在入门阶段来说，最重要的是把这几个名字区分开： | 名称 | 角色定位 | 你可以怎么理解 | | --------------- | ------------------------------ | -------------------------------------------------------------------- | | **LangChain** | 高层应用框架 | 快速构建 Agent 和 AI 应用的主入口，屏蔽大量底层细节 | | **LangGraph** | 低层图编排与运行时 | 当你的流程更复杂、需要强状态控制、循环、持久化、人审时使用 | | **LangSmith** | 可观测性、评估、调试、部署平台 | 用来追踪、调试、评估和上线应用 | | **Deep Agents** | “开箱即用”的复杂 Agent 方案 | 官方当前推荐的复杂 Agent 起步方案，建立在 LangChain / LangGraph 之上 | 这和早期“LangChain = 一切”的印象已经不一样了。现在可以这样区分： - 想快速做 Agent：可以从 **LangChain** 入手 - 想做更复杂、更可控的 Agentic Workflow：用 **LangGraph** - 想做追踪、评估、部署：用 **LangSmith** - 想快速做更“重型”的复杂 Agent：可以关注 **Deep Agents** **本套教程的主线仍然是：LangChain → LangGraph → MCP / 多智能体。**这条路线对入门更友好，因为你先掌握基础抽象，再进入图编排，知识是连贯的。 ### 3.3 0.x 与 1.x 的核心差异 下面这张图对应的是大家最容易感受到的变化：**写法变了，重点也变了。** ![LangChain 0.x 与 1.x 核心差异：旧写法多步组装，新主线强调统一入口、create_agent 与 LangGraph Runtime](images/9/9-3-3-1.jpeg) 先用一句话总结： > **0.x 更像“很多高层类 + 组合式积木”，1.x 更像“精简主包 + 统一入口 + Agent 建立在 LangGraph 之上”。** 以 Agent 为例，变化尤其明显： ```text # 约 0.x：常见需要分多步组装 [Model] → [Tools] → [Prompt] → [Agent] → [Executor] # 约 1.x：常见收敛为高层入口 create_agent(模型、工具、提示等) → [Agent] ``` 核心变化可以概括为： | 对比项 | 0.x / 旧写法 | 1.x / 新写法 | | --------------- | ------------------------------------- | ---------------------------------------- | | **Agent 创建** | 常见要手动组装 Agent + Executor | 以 `create_agent` 为主入口 | | **模型初始化** | 常见直接记忆具体类或旧导入路径 | 更强调统一入口，如 `init_chat_model` | | **主包内容** | `langchain` 中内容很多，历史包袱重 | `langchain` 主包被精简，只聚焦核心能力 | | **旧能力去向** | `LLMChain`、老 Retriever 等混在主包里 | 迁到 `langchain-classic` | | **底层运行时** | 以前很多人只感受到“链” | 现在 Agent 明确建立在 **LangGraph** 之上 | | **Python 版本** | 老资料中常见 3.8 / 3.9 | 官方 1.x 要求 **Python 3.10+** | 这里有一个容易混淆的点： **并不是说 1.x 以后“链”就没用了，而是说很多旧式高层 Chain 类不再是官方推荐主线。**课程后面的 [第 15 章 LCEL 与链式调用](15-LCEL与链式调用.md) 仍然是主线内容，因为“把多个步骤组合起来”的思想从来没有过时，只是实现方式从“某个现成 Chain 类”逐渐转向 **Runnable / LCEL / Graph**。 ### 3.4 LangChain 常见包分类 这一部分是原来最容易写乱的地方，因为 **1.x 的包划分和早期已经不一样了**。下面按当前官方主线重新梳理一遍。 | 包 / 模块 | 作用 | 说明 | | ---------------------------------------------------------------- | ----------------------- | ------------------------------------------------------------------------ | | **langchain-core** | 核心抽象层 | 包含消息、Runnable、工具基础、Prompt 基础、模型接口等，是整个生态的底座 | | **langchain** | 高层应用框架主包 | 1.x 中聚焦核心高层能力，如 Agent、统一模型初始化、消息与工具等 | | **langchain-openai / langchain-anthropic / langchain-ollama** 等 | 厂商 / provider 集成包 | 每个模型厂商或平台通常有自己的独立集成包，便于独立版本管理 | | **langchain-community** | 社区集成包 | 放置大量社区维护的集成，例如某些工具、loader、向量库、第三方连接器等 | | **langchain-classic** | 旧版 / 兼容包 | 承载许多从主包迁出的经典能力，如旧 Chains、旧 Retrievers、旧 Indexing 等 | | **langgraph** | 图编排与运行时 | 用于构建更复杂、可控、可持久化的 Agentic Workflow | | **langsmith** | 调试、评估、Tracing SDK | 对接 LangSmith 平台，常用于可观测性与实验评估 | | **langchain-text-splitters** | 文本切分组件 | RAG 常用，负责把长文本拆分成合适片段 | | **langchain-mcp-adapters** | MCP 适配包 | 用于在 LangChain / LangGraph 应用中接入 MCP 工具 | 这里特别纠正一个常见误区： > **`langchain-openai`、`langchain-anthropic` 这类包不是 `langchain-community` 里的别名，它们现在是独立 provider 包。** 这也是官方当前强调“独立集成包”的原因：模型厂商变化太快，拆开后更利于单独维护。 ### 3.5 学习时如何面对版本差异 因为互联网上大量资料还停留在 0.x 语境，所以你学习时几乎一定会碰到“视频里这样写，为什么我这里不一样”的情况。建议按下面的原则处理： 1. **新项目、新代码，优先学习 1.x。** 2. **看到 `LLMChain`、`ConversationChain`、旧 AgentExecutor，先把它们理解为历史写法。** 3. **看到旧教程时，重点学“思路”，不要死记“类名”。** 4. **以官方文档的当前导入路径和当前 API 为准。** 5. **如果课程示例兼容旧写法，目的是帮助你读懂旧生态，不代表新项目都要这么写。** --- ## 4、LangChain 核心模块 ### 4.1 先建立一张“全景图” 学习 LangChain 时，最容易乱的地方在于：一会儿看到 **Model I/O**，一会儿看到 **Chains**，一会儿又看到 **Messages、Tools、Memory、Retrieval、Callbacks**，感觉像一堆名词堆在一起。其实它们可以放回同一条主线里理解。 先用下面这张图把知识块铺开。它不要求你现在全部掌握，只需要看懂后面章节会沿着哪条路线展开： ![LangChain 完整知识体系：从模型接入、Prompt、Parser、LCEL 到 Retrieval、Tools、MCP、Agent 的学习路线](images/9/9-4-1-1.png) 你可以先把一个典型 AI 应用想成这样一条链路： 1. 用户发来问题 2. 系统决定要不要带上提示词、历史记录、外部知识 3. 如果需要，先检索文档或调用工具 4. 把整理后的上下文交给模型 5. 得到输出后做解析、格式化或后处理 6. 整个过程中记录日志、追踪执行链路 从这个视角看，LangChain 的核心模块其实是在回答六个问题： - **怎么接模型**：Model / Model I/O - **怎么组织固定流程**：Chains / LCEL - **怎么记住上下文**：Memory - **怎么接外部知识**：Retrieval / RAG - **怎么让模型会做事**：Tools / Agents - **怎么观测与调试**：Callbacks / LangSmith 下面按这个顺序来理解。 ### 4.2 Model I/O（模型输入输出） Model I/O 说的就是“**围绕模型调用本身的一圈能力**”。它解决的是：**输入怎么组织、模型怎么调、输出怎么拿得稳。** ![LangChain Model I/O：Format（输入格式化）→ Predict（调用模型）→ Parse（解析输出）三阶段关系示意](images/9/9-4-2-1.png) 从学习路径上看，它主要包含三件事： - **Format（输入格式化）**：把原始输入组织成 Prompt 或多角色消息 - **Predict（模型调用）**：用统一接口调用不同厂商模型 - **Parse（输出解析）**：把自然语言输出转成更稳定的结构化结果 对应章节： - [第 10 章 HelloWorld](10-LangChain快速上手与HelloWorld.md)：先学会把模型调起来 - [第 11 章 Model I/O](11-Model-I-O与模型接入.md)：理解模型接入与参数 - [第 13 章 提示词与消息模板](13-提示词与消息模板.md)：理解 Prompt、Message - [第 14 章 输出解析器](14-输出解析器.md)：理解结构化输出 从真实开发角度看，**Model I/O 是所有 LangChain 学习的基础层**。后面学的链、记忆、RAG、Agent，本质上都还是围绕“如何更好地调用模型”展开。 ### 4.3 Chains（链）：固定流程编排 **Chain** 的核心思想很简单：把多个步骤按固定顺序串起来。例如“用户问题 → Prompt 模板 → 模型调用 → 输出解析”就是一个最基础的链；“先检索，再生成”也是链；“先分类，再走不同分支”依然是链。 早期 LangChain 之所以叫 LangChain，就是因为它最著名的能力就是“把这些步骤串起来”。到了今天，虽然很多旧式高层 Chain 类已经不是主角，但**链式思维仍然是 LangChain 的基础能力**。 你需要重点区分两个概念： - **固定流程**：更适合用 Chain / LCEL - **动态决策流程**：更适合用 Agent / Graph 也就是说，如果你的业务过程是确定的，例如： - 先提炼关键词，再查库，再总结 - 先清洗输入，再分类，再结构化输出 - 先识别意图，再调用特定处理链 这类流程通常优先考虑 **Chain / LCEL**，因为它更稳定、可控、好调试。 对应章节： - [第 15 章 LCEL 与链式调用](15-LCEL与链式调用.md) ### 4.4 Memory（记忆）：记忆与上下文状态 **Memory** 指的是应用如何“记住”过去发生过什么。注意，这里的“记忆”不是让模型变得更聪明，而是让系统在多轮交互中保留必要上下文，例如历史对话、用户偏好、会话状态、阶段性结果等。 初学者常见误区是把 **Memory** 和 **RAG** 混在一起，实际上它们关注点不同： - **Memory**：更偏“这次会话里发生过什么、这个用户之前说过什么” - **RAG**：更偏“系统到外部知识库里查到了什么” 举个真实项目里的例子： - 用户前一轮说“我开的是淘宝店” - 当前轮又问“那我这个退款率高吗” 如果系统没有记忆，就不知道“这个”指的是哪个店铺、哪个上下文。 这时需要 Memory 来保存对话历史或用户状态，而不是去知识库里做文档检索。 在官方当前语境里，记忆通常会区分为 **Short-term Memory** 和 **Long-term Memory**。在本教程里，你会先学最常见的会话历史管理，再接触 Redis 持久化等更贴近项目实战的做法。 对应章节： - [第 16 章 记忆与对话历史（含 Redis 基础）](16-记忆与对话历史（含Redis基础）.md) ### 4.5 Retrieval（检索）：检索与 RAG **Retrieval** 模块解决的是“模型不知道的知识从哪里来”的问题。它是 RAG 的核心组成部分，负责从外部知识源中检索和当前问题相关的信息，再把检索结果交给模型辅助生成答案。 ![LangChain Retrieval：外部知识接入与检索增强生成（RAG）在应用中的位置示意](images/9/9-4-5-1.png) 这一块你可以先把它拆成两段理解： 1. **索引阶段**：把文档加载进来，切分、向量化、存入向量库 2. **查询阶段**：用户提问时，先检索相关片段，再交给模型生成答案 这也是为什么 RAG 学习通常不会只讲一个 Retriever，而是会串起整条流程： - Document Loaders - Text Splitters - Embeddings - Vector Stores - Retrievers - 最终生成 对应章节： - [第 18 章 向量数据库与 Embedding 实战](18-向量数据库与Embedding实战.md) - [第 19 章 RAG 检索增强生成](19-RAG检索增强生成.md) 并且你已经能在源码目录里看到很多具体案例，例如： - TXT / Markdown / JSON / CSV / PDF / Word 文档加载 - 文本切分 - Redis 向量存储 - RAG 问答链路 这也说明一件事：**RAG 不是一个单点 API，而是一条完整工程链路。** ### 4.6 Tools/Agents（工具/智能体）：让模型不只是“会说”，还“会做” 如果说 RAG 让模型“会查”，那么 **Tools 与 Agents** 则让模型进一步“会做事”。 #### 4.6.1 Tool 是什么 **Tool** 本质上是一个可以被模型调用的外部能力。它可以是：查询天气，调数据库，调公司内部 API，发邮件，查订单，做数值计算，调搜索引擎。也就是说，Tool 负责把“语言世界”连接到“行动世界”。 #### 4.6.2 Agent 是什么 **Agent** 则是在 Tool 之上再多一层：它不是简单执行固定步骤，而是让模型根据当前任务自主决定“下一步该做什么”。例如：先判断是否需要查天气；如果需要，就调用天气工具；看到结果后，再决定是否需要继续问用户；最后组织最终回复。 ![LangChain Agents：在工具（Tools）之上由模型进行规划、选工具与多步执行的典型关系示意](images/9/9-4-6-1.png) 在 1.x 官方语境下，**LangChain 的 Agent 已经明确建立在 LangGraph 运行时之上**。这意味着你即使只是调用 `create_agent`，底层也不再只是一个松散的“工具循环”，而是带有状态、节点、流转、持久化能力的图式运行逻辑。 所以，可以这样区分： | 场景 | 更适合什么 | | ---------------------------------- | ------------ | | 步骤固定、顺序明确 | Chain / LCEL | | 需要模型动态决策 | Agent | | 需要更强状态控制、循环、分支、人审 | LangGraph | 对应章节与案例： - [第 17 章 Tools 工具调用](17-Tools工具调用.md) - [第 21 章 Agent 智能体](21-Agent智能体.md) ### 4.7 Callbacks（回调）：日志、调试与可观测性 在很多老资料里，你会看到 **Callback** 被列为 LangChain 的六大模块之一。这个说法在教学上仍然有价值，因为它提醒你：**一个可用的 AI 应用，不只是“能跑”，还要“能看见它怎么跑”。** 旧语境下，Callback 更像“运行时钩子”： - 记录模型输入输出 - 统计耗时与 Token - 打印中间步骤 - 追踪工具调用 - 上报日志与监控 到了现在，官方更强调的是 **LangSmith + Tracing + Evaluation** 这一整套可观测性能力。也就是说，Callback 的思想还在，但它在工程实践中往往已经进一步体现在：Tracing；Runtime events；Middleware hooks；LangSmith 可视化调试。 这一块在真实项目里很关键。AI 应用最难排查的问题，通常不是“程序报错”，而是：为什么这次没检索到？为什么调了错误工具？为什么模型理解偏了？为什么这轮成本突然变高？为什么线上效果和本地不一致？ 如果没有可观测性，很多问题只能靠猜。所以，对企业项目来说，**Callbacks / Tracing / LangSmith 不是可有可无的附属能力，而是系统可维护性的关键。** ### 4.8 六大模块总览 虽然官方当前文档导航不再严格使用老版本那种“六大模块总图”来组织内容，但在入门阶段，这套图依然有助于建立整体认知，因此本教程继续保留这套视图。 四大块侧重“**模型 I/O → 链 → 检索 → 智能体**”这条主线；六大模块则补上 **Memory** 和 **Callbacks**，让你的系统视角更完整。 ![LangChain 六大核心模块关系总览：Models、Memory、Retrieval、Chains、Agents、Callbacks（教学向总图，与官方 1.x 文档栏目划分是粗粒度对应关系）](images/9/9-4-8-1.jpeg) > **说明**：这张图属于“教学视图”，适合入门时建立全局感。到了官方 1.x 文档中，你会看到这些能力被拆到 Agents、Models、Messages、Tools、Memory、Retrieval、Streaming、Structured Output、Middleware、Runtime、LangSmith 等更细的栏目里。两者不是冲突关系，而是“粗粒度总图”和“细粒度产品化视图”的区别。 这六块可以重新对应为： - **Models**：模型与模型调用，对应本教程的 Model I/O、模型接入 - **Memory**：对话历史、会话状态、长期记忆 - **Retrieval**：文档加载、切分、向量化、检索、RAG - **Chains**：固定流程组合、LCEL、Runnable - **Agents**：工具调用、自主决策、多步任务 - **Callbacks**：日志、Tracing、调试、监控、评估 下面这张图把这些模块进一步展开了： ![LangChain 六大模块展开小结：Agent、Chain、Memory、Data Connection、Model I/O、Callbacks 及其子组件在一页上的关系](images/9/9-4-8-2.jpg) **虚线表示什么**：图中虚线表示**数据流或依赖关系**——例如链会用到 Memory 和 Data Connection，会通过 Model I/O 调模型；Document Loaders 产出给 Transformers/Splitters，再进 Vector Stores；Document Retrievers 从 Vector Stores 里查。看虚线就能看出「谁用谁、数据怎么流」。 | 图中区域 | 对应能力 | 应该怎么理解 | 图中在说什么 | | -------------------- | ---------------------------- | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **最上方（紫色）** | **Agents 智能体** | 负责决策、规划、选择工具，是最「像智能体」的部分 | 最上层是「做决策、选动作」的智能体。下面挂了两类东西：**Executors（执行器/链）**——如 ReAct（先推理再行动）、Plan-Execute（先规划再执行）、OpenAI 等；**Tools（工具）**——Standalone 单工具、Collection 工具集。箭头 in/out 表示工具可以接收输入、返回输出。 | | **中间偏上（粉色）** | **Chains 链** | 负责把固定步骤串起来，是稳定流程编排层 | 链是把「调模型、查文档、多步流程」串起来的编排。图中包括：Foundational LLM（直接调基座模型）、Conversational QA（带对话记忆的问答）、Retrieval QA（先检索再回答，即 RAG）、Document（文档处理）、Sequential（按顺序执行的多步链）。虚线连到右侧 LangSmith，表示链的执行可被监控、追踪。 | | **左侧（绿色）** | **Memory 记忆** | 负责保存对话历史、用户状态、阶段性上下文 | 存「对话历史、会话状态」等。图中列了：Buffer（简单缓冲）、Vector DB（用向量存对话/上下文，可语义检索）、KV DB、SQL DB。链和智能体在需要时会从这些记忆里读、写。 | | **中间（橙色）** | **Data Connection 数据连接** | 负责文档加载、切分、向量化、检索，是 RAG 的底盘 | 负责「数据从哪来、怎么加工、存到哪」。包含：**Vector Stores**（Embedding 把文本变向量 → 存进 Vector DB / Memory / Self-Hosted / BaaS）；**Document Retrievers**（用 Vector DB、Web API、BaaS 按查询取文档）；**Document Loaders**（从 Folder、File、Web 加载原始数据）；**Document Transformers/Splitters**（对文档做切分、转换，如按 Text/Code/Token 切块）。RAG 的「建库、检索」都在这块。 | | **右侧偏下（蓝色）** | **Model I/O 模型输入输出** | 负责 Prompt、模型调用、输出解析 | 和「怎么调大模型」有关：**Prompts**（Template 模板、Selector 动态选提示）；**Language Models**（Chat 对话模型、LLM 通用模型）；**Output Parsers**（把模型输出变成结构化，如 Structured、JSON）。链和智能体通过这里把「提示 → 模型 → 解析结果」串起来。 | | **最右侧（灰色）** | **Callbacks 回调** | 负责日志、追踪、调试、监控 | 在链/智能体执行过程中「插一脚」做日志、监控、调试。图中：LangSmith（官方调试与监控平台）、Console（控制台输出）、Custom（自定义回调）。虚线表示这些回调可以挂到链、模型等环节。 | 这页图的作用，不是让你死记每个框，而是帮你建立一个直觉： > **LangChain 做的不是某一件事，而是把“模型调用、知识接入、流程编排、状态管理、工具执行、调试追踪”这些原本分散的环节串成一个工程系统。** ### 4.9 怎么记这套框架 如果你现在看完还是觉得概念多，可以只记住这套口诀： - **想把模型调起来**：先学 **Model I/O** - **想把固定步骤串起来**：学 **Chain / LCEL** - **想让系统记住上下文**：学 **Memory** - **想让模型接外部知识**：学 **Retrieval / RAG** - **想让模型调用工具、做多步任务**：学 **Tools / Agents** - **想知道系统为什么答成这样**：学 **Callbacks / Tracing / LangSmith** --- **章节思考题：** 1. 如果不用“框架”这个词，你会怎样向新人解释 LangChain 在应用里做什么？ **参考思路：** 可以说它是一层把模型、提示词、输出解析、知识检索、工具、记忆和追踪组织起来的代码工具箱。它不提供模型参数，而是帮你把模型接进业务流程。 2. 为什么学习 LangChain 时要同时知道 1.x、provider 包和 LangGraph？ **参考思路：** 1.x 是当前主线，provider 包负责具体模型接入，LangGraph 承担复杂流程和 Agent 的底层编排。只看旧版链式 API，会读不懂现在的项目结构和官方推荐路径。 3. 六大模块里，你会先从哪条最小闭环开始？为什么？ **参考思路：** 通常先从 Model I/O、Prompt、Parser 开始，形成 `prompt | model | parser` 的最小闭环。能稳定输入、调用和解析后，再扩展到 RAG、Tools、Memory、Agent 和可观测性。 4. 什么时候不需要引入 LangChain，直接用模型 SDK 反而更合适？ **参考思路：** 如果只是一次简单模型调用、没有复杂编排、没有多模型切换、没有检索和工具链路，原生 SDK 可能更轻。框架的价值在复杂度上来以后才明显。 **本章小结：** - **LangChain** 不是大模型本身，而是位于 AI 应用架构中“**服务 / 编排层**”的开源框架，核心作用是把模型、Prompt、知识、工具、记忆、输出解析和调试能力组织成一个可维护的应用系统。它与 **Coze / Dify** 的关系不是替代，而是分工不同：前者偏代码框架，后者偏低代码平台；真实项目里常常先用平台验证，再用框架落地。 - 现阶段学习 LangChain，应以 **1.x 官方文档**为主线。要重点理解：`langchain` 主包已精简，很多旧能力迁移到了 `langchain-classic`；Agent 以 `create_agent` 为高层入口，底层建立在 **LangGraph** 之上；集成能力则通过 `langchain-openai`、`langchain-ollama` 等独立 provider 包扩展。 - 在入门阶段，最重要的不是一开始记住所有 API，而是先建立 **六块认知地图**：**Model I/O、Chains、Memory、Retrieval、Tools / Agents、Callbacks**。后续章节会按这张地图一块一块展开，并且已经在项目目录中配好了对应案例源码。 **建议下一步：** 直接进入 [第 10 章 LangChain 快速上手与 HelloWorld](10-LangChain快速上手与HelloWorld.md)，先把 **API Key、模型名、Base URL、HelloWorld 调用、多模型共存、企业级封装与流式输出** 跑通。等你真正把第一个 LangChain 调用写出来，再回头看这一章的“定位、架构、模块”，理解会明显更扎实。