9-LangChain概述与架构
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 章 跑一次最小调用，抽象概念会落得更稳。
官方文档与资源：详见 工具导航与参考资料索引 - 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 的价值不在于“替你发一次请求”，而在于帮你把下面这些原本零散的东西组织起来：
- 不同厂商的大模型调用方式
- Prompt 与多角色消息
- 结构化输出与解析
- 检索增强生成（RAG）
- 工具调用、Agent、多步任务
- 记忆、会话状态、持久化
- 日志、追踪、调试、评估
这也是为什么它会被很多人看作 AI 应用开发里的“基础框架”。
1.2 为什么需要 LangChain
如果你只是偶尔调一下模型 API，直接用 OpenAI、阿里百炼、DeepSeek、智谱等厂商 SDK 完全没问题；但一旦进入真实项目，单纯“把一个字符串发给模型，再拿回一段文本”的开发方式很快就会暴露出一批工程问题。
常见问题包括：
- 模型接口不统一：不同厂商 SDK、参数命名、返回结构各不相同，切换模型成本高。
- 输入输出不稳定：今天让它输出 JSON 成功，明天稍微换个问题就可能跑偏。
- 很难连接外部知识：企业文档、数据库、向量库、内部 API 都需要手动接。
- 多步任务难维护：例如“先检索，再总结，再调用工具，再组织回复”，靠手写流程容易乱。
- 多轮对话难管理：你需要决定哪些历史消息保留、何时裁剪、何时持久化。
- 线上排查困难：模型为什么答错、工具为什么没调、哪一步慢、哪里丢上下文，光看日志很难定位。
LangChain 并不会神奇地消灭这些复杂度，但它给你提供了一套统一抽象，让你能用更规范的方式去解决它们。
1.3 已经能直接调模型了，为什么还要学 LangChain
答案很简单：直接调 API 可以，做简单任务时甚至更直接；但只要你开始做“应用”，框架就会越来越有价值。
最典型的类比，就是 Java 里的 JDBC 或 Spring。你的业务代码不想被某一个数据库或某一个中间件写死，于是你希望中间有一层统一接口来隔离差异。在大模型应用里，这一层统一抽象、统一编排、统一接入的角色，LangChain 很大程度上就在承担。
放到项目开发里，两种路线的边界大致是：
- 只调 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、知识质量、工具设计、评估流程依然是关键。
不足与槽点：
- 版本变化快：老教程里的类名、导入路径、写法，很可能在新版本里已经迁移。
- 抽象多，学习成本不低：初学时容易觉得“明明只是调个模型，为什么多了这么多概念”。
- 历史包袱真实存在：很多文章还在讲
LLMChain、ConversationChain、旧版 AgentExecutor，但新项目未必应照搬。 - 文档存在新旧并存现象：官方文档已经比早期稳定很多，但生态广，仍会碰到版本语境不一致的问题。
所以结论很明确：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 在系统架构中的位置：
| 层级 | 这层负责什么 | 常见对象 / 产品 | 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 往往承担下面几件事：
- 统一接模型：同一个项目同时接入通义、DeepSeek、OpenAI、Ollama，本质上是在做多模型编排。
- 统一处理输入输出：用 PromptTemplate、消息对象、输出解析器来规范请求与结果。
- 组织固定流程：把“提问 → 检索 → 生成 → 解析”做成稳定链路。
- 接入工具与外部系统：比如天气查询、数据库查询、内部 API、工单系统、邮件系统。
- 管理状态与记忆：多轮聊天、会话上下文、用户偏好、长期记忆。
- 做调试和评估：把调用过程 trace 出来，定位哪一步出了问题。
如果结合你这套教程的项目场景来看，就非常好理解了：
- 在 Coze / Dify 阶段，我们做了商品评论分析、客户投诉分类、客服对话记录分析等平台化应用。
- 进入 LangChain 阶段后，我们开始把这些“AI 能力”落到代码服务里，例如多模型接入、输出解析、记忆管理、Tools、RAG、MCP、Agent。
- 再往后到 LangGraph 阶段，本质上是在进一步解决“流程更复杂、状态更多、控制更细”的问题。
这条路线，本质是从“会用 AI 平台”走向“会做 AI 系统”。
2.4 岗位与招聘对标
目前在招聘平台上，越来越多岗位会明确写出：
- 熟悉 LangChain / LangGraph / RAG / Agent
- 有大模型应用开发经验
- 能接入向量库、知识库、工具调用
- 熟悉 Prompt、模型调用、可观测性、评估
换句话说，LangChain 已经不是“可选了解项”，而是很多 AI 应用工程岗位的高频关键词。当然，不同公司未必只用 LangChain，但你一旦掌握这套思维，再迁移到其他框架会快很多。
附：从事「基础通用大模型」开发者简历（示意）
3、LangChain 包与版本对比
3.1 版本演进：从“链”到“Agent + 图 + 生态”
LangChain 的演进大致可以分成三个阶段来理解：
第一阶段：0.0.x / 0.1 早期阶段，特点是“链优先”。
这一时期大家更多把 LangChain 理解成“Prompt + LLM + Chain”的组合工具，很多经典写法例如 LLMChain、ConversationChain、各种旧版 AgentExecutor 都是从这里来的。
第二阶段：0.2 / 0.3 阶段，开始重视生态拆分和工程边界。
这一时期官方逐渐把 LangChain、集成包、部署与调试能力拆开，形成更清晰的产品层次。你也会在很多 2024 年左右的教程里看到这套结构图。
说明：上图将 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 之上。
如果记一个时间点即可：
- 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 的核心差异
下面这张图对应的是大家最容易感受到的变化：写法变了，重点也变了。
先用一句话总结：
0.x 更像“很多高层类 + 组合式积木”，1.x 更像“精简主包 + 统一入口 + Agent 建立在 LangGraph 之上”。
以 Agent 为例，变化尤其明显：
1 | # 约 0.x：常见需要分多步组装 |
核心变化可以概括为：
| 对比项 | 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 与链式调用 仍然是主线内容，因为“把多个步骤组合起来”的思想从来没有过时，只是实现方式从“某个现成 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.x。
- 看到
LLMChain、ConversationChain、旧 AgentExecutor，先把它们理解为历史写法。 - 看到旧教程时，重点学“思路”，不要死记“类名”。
- 以官方文档的当前导入路径和当前 API 为准。
- 如果课程示例兼容旧写法，目的是帮助你读懂旧生态，不代表新项目都要这么写。
4、LangChain 核心模块
4.1 先建立一张“全景图”
学习 LangChain 时，最容易乱的地方在于：一会儿看到 Model I/O，一会儿看到 Chains，一会儿又看到 Messages、Tools、Memory、Retrieval、Callbacks，感觉像一堆名词堆在一起。其实它们可以放回同一条主线里理解。
先用下面这张图把知识块铺开。它不要求你现在全部掌握，只需要看懂后面章节会沿着哪条路线展开：
你可以先把一个典型 AI 应用想成这样一条链路：
- 用户发来问题
- 系统决定要不要带上提示词、历史记录、外部知识
- 如果需要，先检索文档或调用工具
- 把整理后的上下文交给模型
- 得到输出后做解析、格式化或后处理
- 整个过程中记录日志、追踪执行链路
从这个视角看，LangChain 的核心模块其实是在回答六个问题：
- 怎么接模型：Model / Model I/O
- 怎么组织固定流程：Chains / LCEL
- 怎么记住上下文：Memory
- 怎么接外部知识：Retrieval / RAG
- 怎么让模型会做事：Tools / Agents
- 怎么观测与调试：Callbacks / LangSmith
下面按这个顺序来理解。
4.2 Model I/O（模型输入输出）
Model I/O 说的就是“围绕模型调用本身的一圈能力”。它解决的是：输入怎么组织、模型怎么调、输出怎么拿得稳。
从学习路径上看，它主要包含三件事：
- Format（输入格式化）：把原始输入组织成 Prompt 或多角色消息
- Predict（模型调用）：用统一接口调用不同厂商模型
- Parse（输出解析）：把自然语言输出转成更稳定的结构化结果
对应章节：
- 第 10 章 HelloWorld：先学会把模型调起来
- 第 11 章 Model I/O：理解模型接入与参数
- 第 13 章 提示词与消息模板：理解 Prompt、Message
- 第 14 章 输出解析器：理解结构化输出
从真实开发角度看，Model I/O 是所有 LangChain 学习的基础层。后面学的链、记忆、RAG、Agent，本质上都还是围绕“如何更好地调用模型”展开。
4.3 Chains（链）：固定流程编排
Chain 的核心思想很简单：把多个步骤按固定顺序串起来。例如“用户问题 → Prompt 模板 → 模型调用 → 输出解析”就是一个最基础的链；“先检索，再生成”也是链；“先分类，再走不同分支”依然是链。
早期 LangChain 之所以叫 LangChain，就是因为它最著名的能力就是“把这些步骤串起来”。到了今天，虽然很多旧式高层 Chain 类已经不是主角，但链式思维仍然是 LangChain 的基础能力。
你需要重点区分两个概念：
- 固定流程：更适合用 Chain / LCEL
- 动态决策流程：更适合用 Agent / Graph
也就是说，如果你的业务过程是确定的，例如：
- 先提炼关键词，再查库，再总结
- 先清洗输入，再分类，再结构化输出
- 先识别意图，再调用特定处理链
这类流程通常优先考虑 Chain / LCEL，因为它更稳定、可控、好调试。
对应章节：
4.4 Memory（记忆）：记忆与上下文状态
Memory 指的是应用如何“记住”过去发生过什么。注意，这里的“记忆”不是让模型变得更聪明，而是让系统在多轮交互中保留必要上下文，例如历史对话、用户偏好、会话状态、阶段性结果等。
初学者常见误区是把 Memory 和 RAG 混在一起，实际上它们关注点不同：
- Memory：更偏“这次会话里发生过什么、这个用户之前说过什么”
- RAG：更偏“系统到外部知识库里查到了什么”
举个真实项目里的例子：
- 用户前一轮说“我开的是淘宝店”
- 当前轮又问“那我这个退款率高吗”
如果系统没有记忆，就不知道“这个”指的是哪个店铺、哪个上下文。
这时需要 Memory 来保存对话历史或用户状态，而不是去知识库里做文档检索。
在官方当前语境里，记忆通常会区分为 Short-term Memory 和 Long-term Memory。在本教程里，你会先学最常见的会话历史管理，再接触 Redis 持久化等更贴近项目实战的做法。
对应章节：
4.5 Retrieval（检索）：检索与 RAG
Retrieval 模块解决的是“模型不知道的知识从哪里来”的问题。它是 RAG 的核心组成部分，负责从外部知识源中检索和当前问题相关的信息，再把检索结果交给模型辅助生成答案。
这一块你可以先把它拆成两段理解：
- 索引阶段：把文档加载进来，切分、向量化、存入向量库
- 查询阶段：用户提问时，先检索相关片段，再交给模型生成答案
这也是为什么 RAG 学习通常不会只讲一个 Retriever，而是会串起整条流程：
- Document Loaders
- Text Splitters
- Embeddings
- Vector Stores
- Retrievers
- 最终生成
对应章节：
并且你已经能在源码目录里看到很多具体案例，例如：
- 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 之上再多一层：它不是简单执行固定步骤，而是让模型根据当前任务自主决定“下一步该做什么”。例如：先判断是否需要查天气；如果需要，就调用天气工具；看到结果后，再决定是否需要继续问用户；最后组织最终回复。
在 1.x 官方语境下，LangChain 的 Agent 已经明确建立在 LangGraph 运行时之上。这意味着你即使只是调用 create_agent，底层也不再只是一个松散的“工具循环”，而是带有状态、节点、流转、持久化能力的图式运行逻辑。
所以，可以这样区分：
| 场景 | 更适合什么 |
|---|---|
| 步骤固定、顺序明确 | Chain / LCEL |
| 需要模型动态决策 | Agent |
| 需要更强状态控制、循环、分支、人审 | LangGraph |
对应章节与案例：
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，让你的系统视角更完整。
说明：这张图属于“教学视图”，适合入门时建立全局感。到了官方 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、调试、监控、评估
下面这张图把这些模块进一步展开了：
虚线表示什么：图中虚线表示数据流或依赖关系——例如链会用到 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
章节思考题：
如果不用“框架”这个词，你会怎样向新人解释 LangChain 在应用里做什么？
参考思路： 可以说它是一层把模型、提示词、输出解析、知识检索、工具、记忆和追踪组织起来的代码工具箱。它不提供模型参数，而是帮你把模型接进业务流程。
为什么学习 LangChain 时要同时知道 1.x、provider 包和 LangGraph？
参考思路： 1.x 是当前主线，provider 包负责具体模型接入，LangGraph 承担复杂流程和 Agent 的底层编排。只看旧版链式 API，会读不懂现在的项目结构和官方推荐路径。
六大模块里，你会先从哪条最小闭环开始？为什么？
参考思路： 通常先从 Model I/O、Prompt、Parser 开始，形成
prompt | model | parser的最小闭环。能稳定输入、调用和解析后，再扩展到 RAG、Tools、Memory、Agent 和可观测性。什么时候不需要引入 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，先把 API Key、模型名、Base URL、HelloWorld 调用、多模型共存、企业级封装与流式输出 跑通。等你真正把第一个 LangChain 调用写出来，再回头看这一章的“定位、架构、模块”，理解会明显更扎实。