LangChain 导读：AI 应用开发的瑞士军刀

本章阅读时间：约1小时（共10篇）

1.1 LangChain 是什么

官方定义（来自 LangChain 官方文档）：

LangChain is an open source framework with a prebuilt agent architecture and integrations for any model or tool—so you can build agents that adapt as fast as the ecosystem evolves.

LangChain 是一个开源框架，内置了预构建的 Agent 架构，并提供了对任意模型和工具的集成能力——让你构建的 Agent 能够跟上生态的快速演进。

官方文档进一步说明，LangChain 的核心价值在于三点：

• 标准化模型接口：统一不同提供商（OpenAI、Anthropic、DeepSeek、Google 等）的调用方式，无缝切换模型，不被任何一家厂商锁定（vendor lock-in）
• 快速构建 Agent 和自主应用：用不到 10 行代码即可创建功能完整的 Agent
• 灵活的上下文工程：在保持易用性的同时，支持深度定制

如果这个定义读起来还是有点抽象，可以把 LangChain 理解成 AI 应用开发的"乐高积木"——它提供了一套标准化的零件（模型接口、Prompt 模板、对话记忆、文档处理、检索器……），让你能快速把这些零件拼装成一个完整的 AI 应用，而不用每次都从零造轮子。

1.1.1 它能做什么？

LangChain 在实际项目中最常见的用途：

1.1.2 为什么要学 LangChain？

你可能会问：直接调用 DeepSeek 或 OpenAI 的 API 不就够了吗？

对于简单应用，确实够了。但当你的应用需要：

• 从几百个 PDF 文件里检索相关内容来回答问题
• 维护和用户的多轮对话历史（而且对话可能很长）
• 让 AI 能调用多个工具，并根据结果继续推理
• 随时把 DeepSeek 换成 Claude 而不改动大量代码

这时候，你会发现自己在重复写大量"基础设施代码"——不是业务逻辑，只是让各个部分连接起来的胶水代码。LangChain 就是把这些胶水代码标准化了，让你专注于业务逻辑本身。

LangChain 是目前 GitHub Star 数最多的 LLM 应用开发框架之一，在国内外的 AI 应用开发项目中被广泛使用。学会 LangChain，也意味着能读懂大量开源 AI 项目的代码。

1.2 直接调用 API 的局限

使用 DeepSeek SDK 或 OpenAI SDK 直接调用 LLM API 非常简单：几行代码就能发送一个请求、得到响应。但当应用变得复杂，问题就开始出现：

多模型切换的痛苦：项目需要根据任务选择不同的模型——对话用 Claude，代码用 DeepSeek，嵌入用 text-embedding-3-small。如果直接调用各厂商 SDK，每次切换模型都需要修改不同的接口调用方式、不同的参数格式、不同的错误处理逻辑。十几行代码要重写，测试要重跑。

对话历史管理的重复代码：多轮对话需要维护 messages 数组，手动追加每条消息。对话长了需要截断，需要考虑 Token 限制。这些逻辑在每个对话场景中重复出现，而且因为是手写的，各处实现可能有细微差异，埋下 bug。

工具调用的模板化代码：Function Calling 的 JSON Schema 定义、工具调用结果的回填、多轮工具调用的循环——每个 Agent 项目都要重写这套逻辑，而这套逻辑本身没有什么业务价值，只是基础设施。

Prompt 管理散乱：随着应用规模增长，Prompt 模板散落在代码各处，版本管理困难，复用性差。一个 Prompt 修改了，很难知道影响了哪些功能。

可观测性缺失：直接调用 API 时，没有标准化的方式追踪每次 LLM 调用的输入输出、延迟、Token 消耗。排查问题需要手动加日志，而且日志格式可能每个地方都不一样。

输出解析：LLM 的文本输出需要转换成结构化数据。自己写解析逻辑既繁琐又脆弱——模型输出格式稍微变化就会解析失败。

LangChain 的价值，正是把这些重复性的工程问题提供标准化解决方案。

1.3 LangChain 的核心设计：Runnable 接口与 LCEL

LangChain 的核心设计理念是可组合性：每个组件（ChatModel、Retriever、OutputParser……）都实现了统一的 Runnable 接口，支持三种调用方式：

• invoke：单次调用，返回完整结果
• stream：流式调用，逐 token 返回
• batch：批量调用，并行处理多个输入

LCEL（LangChain Expression Language）是这种可组合性的具体语法——用 | 管道符把组件串联起来：

chain = prompt | llm | output_parser
result = chain.invoke({"question": "什么是向量数据库？"})

官方文档对 LCEL 的描述：

Runnable objects encompass chat models, retrievers, chains, etc. The | operator connects them so that the output of one becomes the input of the next.

这与 Unix 管道的思路一致——每个命令只做一件事，输出传给下一个命令。chain.invoke() 执行整条链，chain.stream() 则逐步返回结果，适合需要打字机效果的场景。

1.4 LangChain 的生态组成

LangChain 生态系统——四层架构 + LangSmith 可观测性平台贯穿全链路

LangChain 不是单一的库，而是一个分层生态系统。官方文档将其划分为三个层级：

除此之外，还有配套工具：

• langchain-core：核心抽象和接口定义（Runnable 接口、BaseMessage 等）
• langchain-openai、langchain-anthropic、langchain-deepseek 等：各模型厂商的官方适配包
• LangSmith：LLM 应用的可观测性平台，用于追踪请求、调试 Agent 行为、评估输出质量

注意：旧版本中常见的 langchain-community 包（第三方集成的集合）在新版生态中已逐步被各厂商的独立适配包取代，新项目建议直接使用对应厂商的官方包（如 langchain-deepseek）。

LangChain 与 LangGraph 的关系：官方文档明确说明——

LangChain agents are built on top of LangGraph in order to provide durable execution, streaming, human-in-the-loop, persistence, and more.

LangGraph 是 LangChain Agent 的底层运行时，不是竞争关系，而是分层依赖关系。第 13 章单独讲解 LangGraph。

1.5 关于第 14 章缺少 03、04 篇的说明

细心的读者会发现，本章文件编号从 01、02 跳到了 05——缺少 03 和 04 篇。这不是遗漏，而是有意安排。

原本规划在第 14 章的工具调用相关内容（Tools 的定义与使用、OutputParser 与结构化输出）已经整合到第 9 章"工具使用与 Function Calling"中。这样做的原因是：Tools 和 OutputParser 本质上是 Function Calling 的应用层封装，放在 Function Calling 章节里讲解更符合认知顺序。

如果想了解 LangChain 的 Tools 和 OutputParser，请查阅第 9 章相关内容。

1.6 LangChain 核心概念地图

1.7 本章文章的学习路径

本章的结构遵循 LangChain 核心概念的层次：从基础的模型调用和链式组合，到记忆管理、文档处理，最后到可观测性和高级模式。

核心基础（第 01-02 篇）

01 讲 LangChain 的核心概念和 LCEL 链式调用——这是整章的基础，LCEL 的管道语法贯穿后续所有示例。核心概念：Runnable 接口、| 操作符、invoke/stream/batch 三种调用方式、RunnableParallel 并行执行。02 讲 Memory 对话历史管理，涵盖短期记忆的三种管理策略（消息截断、删除、摘要压缩）以及跨会话的长期记忆实现。

这两篇是 LangChain 使用的核心基础，建议按顺序阅读。

文档处理管道（第 05、07-08 篇）

05 讲 Retriever 检索器——官方定义为"an interface that returns documents given an unstructured query"，是 RAG 系统在 LangChain 中的抽象层，包括向量检索、BM25 关键词检索、混合检索的实现。07 讲 DocumentLoader 文档加载，覆盖 PDF、Web、数据库、Office 等各种来源。08 讲 TextSplitter 文本分割策略，官方推荐的默认分块大小为 1000 字符、重叠 200 字符，不同的分割方式对 RAG 效果影响显著。

这三篇是 LangChain 文档处理流水线的核心，也是 RAG 系统的实现基础。

可观测性与运维（第 06、11 篇）

06 讲 Callback 回调与链路追踪，是 LangChain 可观测性的底层机制——理解 Callback 才能理解 LangSmith 是如何收集数据的。11 讲 LangSmith，官方定位为"LLM 应用的全链路可观测性平台"，用于追踪请求、调试 Agent 行为、评估输出质量。这两篇建议在开始实际项目前就读，养成可观测性习惯比出了问题再补容易得多。

实战与高级（第 09-10、12 篇）

09 是 LangChain Agent 完整实战，从工具定义到最终部署，是前几篇内容的综合应用。Agent 的运行遵循官方描述的 ReAct（Reasoning + Acting）模式：推理 → 调用工具 → 观察结果 → 继续推理或输出。10 讲 LCEL 高级模式：分支、降级、自定义 Runnable——处理复杂业务逻辑的高级组合方式。12 讲 Text-to-SQL，让 LLM 直接生成并执行 SQL 查询，是企业数据查询场景的典型应用。

1.8 LangChain vs 直接调用 API 的选择建议

官方文档对此的建议是：

Start with LangChain for building agents and autonomous applications requiring quick implementation. Choose LangGraph when needing advanced customization combining deterministic and agentic patterns.

结合实际项目经验，以下是一个实用的决策框架：

适合使用 LangChain 的场景

• 需要快速构建 Agent 或自主应用，不想从零实现 ReAct 循环
• 项目需要集成多个不同厂商的 LLM，希望统一接口、避免厂商锁定
• 需要构建 RAG 系统，LangChain 的文档处理管道能显著减少工作量
• 需要 LangSmith 的可观测性能力（追踪、调试、评估）

适合直接调用 API 的场景

• 应用逻辑简单：单轮或少轮对话，没有复杂的工具调用
• 对性能极度敏感：LangChain 的抽象层有额外开销，通常是毫秒级，但高并发场景下可能显著
• 需要完全控制：不希望框架的抽象层遮蔽底层行为

适合使用 LangGraph 的场景

• 需要精确控制 Agent 的执行流程（确定性步骤与 Agent 步骤混合）
• 需要持久化状态、支持中断恢复（human-in-the-loop）
• 构建多 Agent 协作系统

一个务实的建议：从直接调用 API 开始，在感受到重复性痛点时引入 LangChain 的对应组件。很多时候，只需要 LangChain 的某一两个组件（比如只用 Prompt Template 管理 Prompt），不需要引入整个框架。

1.9 LangChain 的版本说明

LangChain 的 API 在 v0.1 到 v0.3 之间经历了较大的变化。本章所有代码基于 2026 年的稳定版本：

langchain>=0.3.0
langchain-openai>=0.2.0
langchain-core>=0.3.0
langgraph>=0.2.0

如果遇到废弃警告（DeprecationWarning），通常是使用了 v0.1/v0.2 时代的旧接口。主要变化：

1.10 与其他章节的关联

与 Python 基础（第 2 章）的关系

LCEL 的管道操作符依赖 Python 运算符重载的理解；LangChain 工具定义大量使用 pydantic；LangChain 的异步调用需要 asyncio 基础。Python 基础章节的第 3、4、5、6 篇是学习 LangChain 的前置内容。

与工具使用与 Function Calling（第 9 章）的关系

LangChain 的 Tools 和 OutputParser 已整合到第 9 章。读完第 9 章的工具调用内容，再学本章的 LCEL 和 Memory，能更清楚地看到 LangChain 的完整能力版图。

与 LangGraph（第 13 章）的关系

LangGraph 是 LangChain Agent 的底层运行时，官方文档明确说明两者是分层依赖关系，不是替代关系。本章是理解 LangGraph 的概念基础——LangGraph 的节点里通常使用 LangChain 的 ChatModel、Retriever、Tools 等组件。

与 RAG（第 11 章）的关系

LangChain 的文档处理管道（DocumentLoader → TextSplitter → Embeddings → VectorStore → Retriever）是 RAG 系统的标准实现路径。第 11 章会在 LangChain 基础上进一步讲解 RAG 系统的优化和生产化。

与 Prompt 工程（第 8 章）的关系

LangChain 的 PromptTemplate 是 Prompt 工程模板管理的框架实现。读完 Prompt 工程章节，再看 LangChain 的 Prompt 模块，会对其设计动机有更深的理解。

1.11 学完本章能做什么

• LCEL 链式调用：能用 | 管道符把 Prompt、Model、Parser、Retriever 等组件串联成处理流水线，熟练使用 invoke/stream/batch 三种调用方式
• 对话历史管理：理解短期记忆（消息截断、摘要压缩）与长期记忆（跨会话语义记忆、情节记忆）的区别，能为应用选择合适的策略
• 文档处理管道：能构建从文档加载到向量化检索的完整 RAG 流水线
• 可观测性：能接入 LangSmith 追踪 LLM 调用的完整链路，快速定位生产问题
• 高级模式：能在 LCEL 里实现条件分支、降级处理、自定义 Runnable 等复杂逻辑

理解了 LangChain 的组件体系，使用 LangGraph 时会顺畅很多——LangGraph 的节点本质上就是装在图里的 LangChain 组件。