LangChain 实战：构建 LLM 应用的真实经验

LangChain 目前在 GitHub 上有超过 9 万 Star，是 LLM 应用开发领域最主流的框架。这篇文章不打算翻译官方文档，而是从一个实际写过几个 LLM 应用的开发者的角度，聊聊 LangChain 解决了什么问题，以及使用中真正需要注意的地方。

LangChain 到底解决了什么

直接调用 OpenAI 或 Anthropic 的 API 做一个简单的对话机器人很容易，大概 20 行代码。但当你开始做真实项目的时候，三个问题会立刻冒出来：

  1. 模型不知道你的业务数据。你公司的产品文档、内部规范，大模型的训练数据里没有。
  2. 模型没有记忆。每一轮对话对它来说都是全新的，它不记得三句话前你告诉过它什么。
  3. 一个回答往往需要多个步骤。先查数据库，再根据结果调用模型，再根据模型输出调用另一个 API——这些步骤需要串联。

LangChain 的核心价值就是为这三个问题提供了标准化的组件，让你不用每次从零造轮子。

五大核心组件——按实际重要性排序

1. Retrieval（检索增强生成，RAG）

这是 LangChain 最实用的能力，也是大部分 LLM 应用的核心。

原理不复杂：把你的文档切片，转成向量存进向量数据库。用户提问时，先检索出最相关的几个文档片段，把它们和问题一起拼进 Prompt，再发给模型。

听起来简单，但落地的时候有几个关键细节：

  • 切片策略直接影响回答质量。按段落切、按固定长度切、还是按语义切，结果差异很大。没有一个通用的最优解，需要根据你的文档类型做实验。
  • 检索回来的文档不等于正确答案。RAG 解决了”模型不知道”的问题，但没有解决”模型不会推理”的问题。如果你检索到了三段内容，其中只有一段跟问题真正相关，模型可能照样把三段都用上，得出一个似是而非的答案。
  • Prompt 里必须明确指令。比如告诉模型：”如果检索到的信息不足以回答，就说不知道，不要编造。”这比检索算法本身更容易被忽略，但往往更重要。

2. Chains（执行链）

Chain 把多步操作串联成一个可复用的流程。比如一个典型的问答链：

1
用户提问 → 检索文档 → 拼接上下文 → 调用模型 → 返回结果

实际使用中，Chain 更适合固定流程——你对整个流程的每一步都有掌控，也方便调试。一旦流程开始出现分支（”如果检索不到结果就走另一个 Chain”），就该考虑用 Agent 了。

3. Memory（对话记忆）

让模型记住之前的对话内容。实现方式就是把历史消息存下来，每次新提问的时候附在后面一起发给模型。

一个容易被忽视的限制：Memory 存的内容默认只影响模型推理，不会影响检索。也就是说，即使用户在第 3 轮对话中提到了一些关键信息，到了第 5 轮，检索组件仍然不知道该去搜索什么。如果你需要”记住用户偏好并根据偏好调整检索”，需要自己写逻辑把 Memory 和 Retrieval 桥接起来。

另外，Memory 不是无限容量的。大多数实现只保留最近几轮对话。需要长期记忆的场景（比如用户画像），得额外接一个持久化存储。

4. Model I/O（模型交互层）

这是最基础的组件，封装了各种模型的 API 调用。LangChain 支持几十种模型，从 OpenAI、Anthropic 到国内的文心一言、通义千问都有适配。

这里最大的价值不是封装本身，而是统一的接口。切换模型通常只需要改一行配置，不用改业务代码。这在选型阶段很有用——快速对比不同模型在同一个任务上的表现。

5. Agents（智能代理）

Agent 让模型自己决定”下一步做什么”。它会把可用的工具列给模型，模型根据当前情况选择合适的工具调用，拿到结果后再决定继续还是结束。

Agent 的概念很有吸引力，但在生产环境中使用需要谨慎：

  • 模型可能会选错工具，或者陷入循环反复调用同一个工具
  • 每次决策都增加一次模型调用，延迟和成本都会上升
  • 调试时比 Chain 难追溯——你不知道模型在每一步”想了什么”

一个实用建议：如果你的任务流程是确定的，用 Chain；只有当任务真的需要动态决策时，再上 Agent。

几个被高估的认知

“用了 LangChain 就不用写代码了”

LangChain 提供的是组件和抽象，不是免代码方案。除非你的场景跟官方 Demo 一模一样，否则你大概率需要自己写 Prompt 模板、自定义 Chain、处理边界情况。框架帮你省的是基础设施代码，不是业务代码。

“RAG 搭好就能出准确答案”

RAG 只是把相关资料喂给模型，模型能不能从中提取正确答案，取决于 Prompt 设计和模型本身的推理能力。我在实际项目中花在 Prompt 调优上的时间远比花在搭建 RAG 流程上的时间多。

“LangChain 只能用 OpenAI”

实际上 LangChain 的模型适配层做得很薄，接入国内的主流模型（通义千问、文心一言、DeepSeek 等）都是几行配置的事。你不用被绑在任何一家模型供应商上。

一个实际项目的技术选型参考

做企业知识库问答系统时，我实际用到的是：

  • 文档加载和切片：LangChain 的 Document Loader + Text Splitter
  • 向量存储：Chroma（小规模）或 Milvus（规模上去之后）
  • 检索和生成：LangChain 的 RetrievalQA Chain
  • 前后端：FastAPI + 前端任意框架，跟 LangChain 没关系，自己写

LangChain 在项目中承担的角色更像是”LLM 层的胶水”，而不是项目的骨架。项目的路由、用户管理、前端界面、数据库——这些还是你自己写。别指望一个框架包办一切。