跳到主要内容

LangChain：是什么、解决什么问题、什么时候该用

很多人第一次接触 LangChain，会把它理解成“做 Agent 的库”。这个说法不算错，但还不够准。更准确的说法是：LangChain 是一个面向 LLM 应用和 Agent 应用的上层开发框架，它负责把模型、提示词、工具、检索、结构化输出、运行链路组织起来。

0. 面试速答（30 秒版 TL;DR）​

  • LangChain 不是模型，也不是向量数据库，而是 LLM 应用框架。
  • 它最核心的价值是：把“调用模型”升级成“编排模型周边能力”，例如工具调用、RAG、结构化输出、Agent 循环。
  • 如果你只做一次简单补全，直接用模型 SDK 往往更轻。
  • 如果你要把模型和工具、检索、状态、观测串起来，LangChain 的抽象会明显省事。
  • 现在官方定位里，LangChain 更偏高层应用框架，LangGraph 更偏底层编排层；前者追求开发效率，后者追求可控性。

1. 先建立正确心智模型​

不要把 LangChain 理解成“帮你多调几次模型”。

它真正解决的问题是：

  • 模型供应商接口不统一
  • 提示词、工具、检索、输出解析容易散落在业务代码里
  • 应用一复杂，就会出现大量“上下文拼装代码”
  • 想换模型、换工具、加 tracing 时，改动面会很大

所以 LangChain 的价值本质上是：

  • 统一模型调用接口
  • 把上下文工程抽成可组合模块
  • 让 LLM 应用从脚本演进成可维护工程

2. LangChain 里最常见的几类构件​

2.1 Model​

这是最底层的一层，负责真正调用模型。

你可以把它理解成：

  • 对 OpenAI、Anthropic、Google 等模型接口做了统一封装

这样做的好处是：

  • 业务代码不必强绑定某一个供应商
  • 切模型、切参数、切响应格式更容易

2.2 Prompt​

Prompt 在 LangChain 里不是一段普通字符串，而更像：

  • 模板
  • 变量插槽
  • 消息列表
  • 可组合的上下文片段

这层的价值是把提示词从“散落字面量”提升为“可管理资产”。

2.3 Tool​

Tool 是 Agent 能真正“做事”的能力入口，例如：

  • 查询天气
  • 搜索知识库
  • 读数据库
  • 调内部 API

面试里可以直接说：

  • 没有 Tool，模型主要只能“说”；有 Tool，模型才开始具备“做”的能力。

2.4 Retriever​

Retriever 负责“取相关资料”，常见于 RAG。

注意：

  • Retriever 不是数据库
  • Retriever 也不是 Embedding 模型

它更像一层检索接口，负责把“用户问题”转成“最相关的上下文片段”。

2.5 Agent​

Agent 代表“模型可以在循环里决定下一步动作”的运行模式。

它和普通 Chain 的区别是：

  • Chain 往往是你提前写死步骤
  • Agent 会根据当前上下文自己决定：
    • 回答
    • 调工具
    • 继续推理
    • 结束

3. 一条典型的 LangChain 执行链路​

这张图对应一个关键理解：

  • LangChain 管的不是单次推理，而是“围绕模型的一整套应用流程”。

4. 一个最小示例：为什么它适合“比 SDK 复杂一点”的场景​

下面是一个简化后的 TypeScript 示例：

import * as z from "zod";
import { createAgent, tool } from "langchain";

const searchDocs = tool(
  async ({ query }) => {
    return `文档搜索结果: ${query}`;
  },
  {
    name: "search_docs",
    description: "搜索内部文档",
    schema: z.object({
      query: z.string(),
    }),
  },
);

const agent = createAgent({
  model: "openai:gpt-4.1",
  tools: [searchDocs],
});

const result = await agent.invoke({
  messages: [{ role: "user", content: "帮我查一下前端性能优化最佳实践" }],
});

这段代码真正省掉的是：

  • 自己维护工具描述格式
  • 自己处理模型工具调用协议
  • 自己写循环，让模型反复决定“要不要继续查”

5. LangChain 最适合哪些场景？​

比较典型的有：

  • 聊天助手接工具
  • 文档问答接 RAG
  • 结构化抽取
  • 代码助手
  • 工单、知识库、搜索、数据库的统一编排

如果是下面这些情况，收益通常更高：

  • 你已经不是“一个 prompt 调一次模型”了
  • 你需要多种外部能力接入
  • 你想要可替换模型和统一 tracing
  • 你希望应用层代码别直接写满 provider 细节

6. 什么情况下不一定要上 LangChain？​

这是面试里很容易加分的一点。

并不是所有 LLM 应用都要上框架。

如果你的场景只是：

  • 一个系统提示词
  • 一个用户输入
  • 一次模型调用
  • 一次结果返回

那直接用模型官方 SDK 往往更简单，原因是：

  • 依赖更少
  • 抽象更薄
  • 出问题时更好排查

所以更准确的工程判断是：

  • LangChain 适合“应用编排复杂度已经出现”的场景，不适合为了用框架而用框架。

7. LangChain 和 LangGraph 是什么关系？​

这题很常见。

可以直接这样答：

  • LangChain 更像上层开发框架
  • LangGraph 更像底层 Agent 编排运行时

两者不是互斥关系，而更像上下层关系：

  • 想快速起 Agent，用 LangChain
  • 想精细控制状态、分支、恢复、人工介入，用 LangGraph

一句话概括：

  • LangChain 负责“好用”，LangGraph 负责“可控”。

8. 面试高频追问​

8.1 LangChain 和直接调 OpenAI SDK 的区别是什么？​

标准答法：

直接调 SDK 更接近底层模型接口，适合简单、透明的调用；LangChain 提供的是应用层抽象，把模型、工具、检索、输出解析、Agent 流程组织起来，适合复杂一点的 LLM 应用。

8.2 LangChain 里的 Chain 和 Agent 有什么区别？​

标准答法：

Chain 偏确定性流程，步骤大多由开发者提前定义；Agent 偏非确定性决策流程，模型会在运行时决定下一步是回答、调用工具还是继续规划。

8.3 LangChain 为什么容易“看起来很方便，后面又觉得重”？​

标准答法：

因为它解决的是中大型 LLM 应用的编排问题。如果项目本身很简单，就会觉得抽象层数多、学习成本高；但当工具、RAG、状态和可观测性都上来之后，这些抽象反而能降低复杂度。

9. 常见误区​

  • 误区一：把 LangChain 当成模型能力增强器。 实际上它增强的是应用编排能力，不是模型本身智力。
  • 误区二：以为接了 LangChain 就自动变成 Agent。 实际上 Agent 只是其中一种组织方式。
  • 误区三：把所有逻辑都塞进 Prompt。 真正可维护的做法应该是区分提示词、工具、检索、状态和业务规则。
  • 误区四：没有 tracing 就直接堆工具。 LLM 应用一旦复杂，观测缺失会让问题非常难排查。

10. 速记要点​

  • LangChain 是 LLM 应用框架
  • 核心价值是 统一模型周边编排
  • 适合 工具 + 检索 + Agent + 结构化输出
  • 简单场景可直接用 SDK
  • 和 LangGraph 的关系是 上层易用抽象 vs 底层可控编排