LangChain 入门:从大模型调用到 Agent 工程框架

如果你最近在学 AI 应用开发,大概率会反复看到一个词:LangChain。

它经常和 RAG、Agent、工具调用、向量数据库、LangGraph、LangSmith 一起出现。很多教程会把它包装成"开发 AI 应用的标准答案",好像只要装上 LangChain,大模型应用就自动工程化了。

但真实情况没这么神奇。

LangChain 不是模型,也不是数据库,更不是让 AI 突然变聪明的魔法。它更像一套大模型应用开发脚手架:帮你把模型调用、提示词、工具、上下文、检索、结构化输出、流式响应和调试观测这些零散能力组织起来。

一句话:

LangChain 解决的不是"模型会不会回答",而是"一个大模型应用如何被组织、编排、调试和演进"。

为什么会需要 LangChain?

直接调用大模型 API 很简单。

你给模型一段 prompt,模型返回一段文本。写一个 demo,几十行代码就够了。

但当你真的要做一个 AI 应用时,问题会迅速变多:

用户的问题需要先查数据库
回答前要检索知识库
模型要调用天气、搜索、订单、日历等工具
输出必须是稳定 JSON,不能随便发挥
对话要有短期记忆
每一步调用要能追踪、复盘、评估
不同模型供应商的接口格式不一样
失败要重试,超时要兜底,结果要可观测

这时你会发现,真正难的不是"调一次模型",而是围绕模型搭一套可靠的应用流程。

LangChain 就是为这个流程服务的。

它把一个 AI 应用拆成几个可组合的部件:模型、消息、提示词、工具、Agent 循环、中间件、检索、流式输出、结构化输出、观测与评估。你可以按业务需要把这些部件拼起来,而不是每次从零手写一套胶水代码。

LangChain 现在的核心定位

早期 LangChain 最出圈的是"Chain"这个概念:把多个步骤串起来,比如先改写问题,再查向量库,再把检索结果塞给模型回答。

今天再看 LangChain,它的定位已经更偏向 Agent 工程框架。

官方文档里有一个很重要的说法:

Agent = Model + Harness

这里的 model 是大模型本身,harness 则是模型外面那一整套运行外壳:提示词、工具、循环控制、中间件、上下文管理、流式事件、结构化输出和调试能力。

这也解释了 LangChain 的价值边界:

它不替你训练模型
它不保证回答一定正确
它不替你设计业务规则
它负责把模型放进一个更可控的应用结构里

如果你只是做一次简单问答,原生 SDK 足够。如果你要做一个能查资料、调工具、保持上下文、输出可追踪结果的 AI 应用,LangChain 才开始有意义。

一个典型 LangChain 应用长什么样?

可以把 LangChain 应用想成一条流水线:

用户输入
  ↓
消息与上下文整理
  ↓
提示词模板 / 系统约束
  ↓
模型调用
  ↓
工具选择与工具执行
  ↓
检索外部知识或业务数据
  ↓
模型继续推理
  ↓
结构化输出 / 流式返回
  ↓
日志追踪、评估、反馈

这条链路里,模型只是其中一环。

真正的工程复杂度在模型之外:数据怎么进来、工具怎么暴露、错误怎么处理、上下文怎么裁剪、输出怎么约束、线上怎么 debug。

LangChain 的价值就在这里。

核心组件拆解

1. Models:统一不同模型供应商

不同模型供应商的接口并不完全一样。

OpenAI、Anthropic、Google、OpenRouter、本地 Ollama、云厂商模型,它们的请求格式、响应格式、工具调用协议、流式事件都可能不同。

LangChain 提供了一层统一接口,让你可以用相对一致的方式接入模型。

这件事在 demo 阶段看起来不重要,但在真实项目里很有价值:

可以更容易切模型
可以做模型 fallback
可以统一日志和错误处理
可以把模型供应商差异隔离在适配层

当然,统一接口不是银弹。不同模型能力差异、上下文长度、工具调用行为、价格和延迟,仍然需要你自己评估。

2. Messages:把对话变成结构化数据

大模型聊天不是简单字符串拼接。

一轮对话里通常有:

system message:系统规则
user message:用户输入
assistant message:模型回复
tool message:工具执行结果

LangChain 把这些消息抽象成统一结构,方便你维护上下文、插入工具结果、裁剪历史消息。

这比手写一个长字符串要可靠得多。

3. Tools:让模型能使用外部能力

工具调用是 Agent 的核心。

模型本身不会查你的数据库,不会访问你的订单系统,也不会知道你服务器上的文件。你要把这些能力封装成 tool,告诉模型:

工具叫什么
工具能做什么
入参结构是什么
返回结果是什么

模型再根据用户问题决定是否调用工具。

比如:

search_docs:检索知识库
get_user_order:查询订单
create_ticket:创建工单
send_email:发送邮件
run_sql:查询只读数据

但工具越强,风险越大。凡是涉及写操作、扣费、发消息、删数据的工具,都必须加权限、确认、审计和幂等设计。不要把生产系统的危险按钮裸露给模型。

4. Agents:让模型在循环里思考和行动

普通模型调用是一次输入、一次输出。

Agent 不一样。它会进入一个循环:

看用户问题
判断是否需要工具
调用工具
读取工具结果
再决定下一步
最后生成回答

LangChain 的 create_agent 就是为了搭这种 agent harness。

这类能力很适合:

智能客服
数据分析助手
文档问答
运维排查助手
低风险自动化任务
内部知识库助手

但 Agent 不是越自动越好。越是接近生产业务,越要加边界:工具权限、执行次数、超时、人工确认、输出校验、异常兜底。

5. Retrieval:把外部知识接进来

RAG 是 LangChain 最常见的使用场景之一。

典型流程是:

把文档切块
生成 embedding
存进向量数据库
用户提问时检索相关片段
把片段作为上下文交给模型回答

LangChain 提供了很多围绕检索的抽象,比如文档加载、文本切分、向量存储、retriever、rerank 等。

但要注意,RAG 的效果不取决于"用了 LangChain",而取决于知识库质量:

文档切块是否合理
元数据是否完整
检索召回是否足够
rerank 是否靠谱
prompt 是否能约束引用范围
找不到答案时是否能诚实拒答

LangChain 能帮你搭流程,但不能自动把脏数据变成好答案。

6. Middleware:把横切逻辑放到统一位置

真实应用里,很多逻辑不是某一个工具独有的,而是每次模型调用都可能需要:

记录日志
注入上下文
做权限判断
限制 token
处理敏感词
控制模型选择
加 retry / timeout
做输出 guardrail

这类逻辑适合放进 middleware。

这也是 LangChain 相比手写脚本更工程化的地方:它鼓励你把可复用的横切能力抽出来,而不是散落在每个调用点里。

LangChain、LangGraph、LangSmith 是什么关系?

很多人会被这几个名字绕晕。

可以简单这样理解:

名称	解决什么问题	适合场景
LangChain	组织模型、工具、prompt、中间件和 agent harness	常规 AI 应用、Agent 原型、RAG 应用
LangGraph	更底层的流程编排,支持状态、分支、循环、持久化	复杂 Agent、多步骤工作流、需要可靠状态机的系统
LangSmith	追踪、调试、评估和观测	线上调试、质量评估、回放分析

LangChain 的 agent 能力底层建立在 LangGraph 之上。也就是说,如果你的应用只是普通 agent,用 LangChain 就够;如果你的业务流程很复杂,需要明确的节点、边、状态恢复和人工介入,就应该直接看 LangGraph。

LangSmith 则更像 AI 应用的"调试台"。大模型应用最怕的不是报错,而是"没报错但答得不稳定"。没有 trace,你很难知道问题出在 prompt、检索、工具结果、模型选择还是上下文裁剪。

什么时候适合用 LangChain?

我会把适用场景分成四类。

1. 你需要接多个模型或未来可能换模型

如果项目一开始就可能在 OpenAI、Anthropic、Google、本地模型之间切换,统一模型接口会减少很多胶水代码。

2. 你需要工具调用和 Agent 循环

只问答不一定需要框架。只要模型开始调用工具,尤其是多个工具、多步决策,LangChain 的价值就明显了。

3. 你要做 RAG 或知识库问答

LangChain 提供了比较完整的检索生态,适合快速搭一个文档问答系统。但真正上线前,还是要重点打磨切块、召回、重排、引用和拒答策略。

4. 你需要可观测和评估

AI 应用上线后,只看接口日志不够。

你需要看到每次请求里:

prompt 是什么
检索到了哪些文档
调用了哪些工具
模型中间输出是什么
最后答案为什么变成这样

这时 LangSmith 这类观测工具会比普通日志好用很多。

什么时候不建议一上来就用?

我反而建议初学者不要第一天就上 LangChain。

原因很简单:抽象会遮住底层。

如果你还没搞懂:

原生模型 API 怎么调
function calling / tool calling 协议长什么样
embedding 是怎么生成和检索的
prompt 怎么影响输出
流式响应怎么处理
JSON 输出为什么会不稳定

那一上来用框架,很容易变成"代码能跑,但不知道为什么"。

更合理的路线是:

先用原生 SDK 写一个最小聊天接口
再手写一次工具调用
再手写一次最小 RAG
最后引入 LangChain,对比它帮你省掉了哪些胶水代码

这样你会知道框架在解决什么问题,也知道出问题时该往哪一层排查。

学 LangChain 应该怎么学?

可以按这个顺序来。

第一阶段:先理解模型调用

目标是能独立写出:

普通聊天
流式输出
结构化 JSON 输出
工具调用
错误重试

这一步尽量用原生 SDK,不要急着封装。

第二阶段:用 LangChain 重写同一个功能

把第一阶段的聊天和工具调用改成 LangChain 版本。

重点观察:

模型接口怎么统一
message 怎么组织
tool schema 怎么写
agent 是怎么循环的
middleware 能拦截什么

这时你就会开始理解 LangChain 的抽象边界。

第三阶段:做一个 RAG 小项目

选一个真实资料源,比如:

个人博客文章
公司内部文档
产品 FAQ
开源项目 README
服务器运维手册

做一个能问答的知识库。

不要只追求"能回答",要重点看:

能否引用来源
找不到时是否拒答
长文是否会漏召回
相似问题是否稳定
文档更新后是否可增量索引

第四阶段:接入观测和评估

AI 应用没有评估,就很难长期维护。

至少要记录:

输入
检索结果
prompt
工具调用
模型输出
用户反馈

然后挑一批典型问题做回归测试。每次改 prompt、换模型、调整切块策略,都跑一遍对比。

这一步才是真正从 demo 走向工程。

它的坑在哪里?

1. 抽象层变厚,排查难度会上升

框架帮你省代码,也会多一层黑盒。

当结果不对时,你要能判断问题在:

模型
prompt
tool schema
检索结果
agent 循环
中间件
框架封装

如果没有底层理解,排查会很痛苦。

2. Agent 容易失控

Agent 最迷人的地方是自动决策,最危险的地方也是自动决策。

如果工具权限太大、循环次数不限制、结果不校验,它就可能做出奇怪甚至危险的操作。

生产环境里,Agent 应该被当成"不完全可信的自动化执行器",而不是绝对可靠的员工。

3. RAG 效果经常被高估

很多人以为接上向量库就是 RAG。

实际上 RAG 的难点在检索质量和答案约束。检索错了,模型会基于错误上下文一本正经地回答;检索少了,模型会补脑;检索太多,模型会被噪声带偏。

框架能搭管道,不能替你保证知识质量。

4. 版本变化快,代码要跟着迁移

AI 应用框架还在快速演进。

LangChain 从早期 Chain 到今天更强调 Agent、LangGraph 和 LangSmith,抽象重点已经变过几轮。写生产代码时,不要只复制旧教程,要优先看官方文档和当前版本 API。

我对 LangChain 的判断

LangChain 适合用来搭 AI 应用的工程骨架,尤其适合这些场景:

需要快速验证 Agent 原型
需要接多个模型供应商
需要把工具调用组织起来
需要做 RAG 知识库
需要 trace、debug 和评估

但它不适合被当成学习大模型开发的第一层。

初学时先学原生协议,再学框架抽象。做项目时先把业务边界想清楚,再决定要不要引入 LangChain。这样你用的是工具,不是被工具牵着走。

真正成熟的大模型应用,不是"用了 LangChain",而是做到:

数据来源可靠
工具权限清晰
输出可验证
行为可追踪
失败可恢复
质量可评估

LangChain 可以帮你更快搭起这些能力,但最后的工程质量,仍然取决于你对业务、数据、安全和系统边界的理解。