1. 为什么有了大模型还需要应用框架
1.1 大模型不是完整应用
Qwen、DeepSeek、GPT、Claude 这类大模型,主要负责理解输入和生成内容。
如果只是写一个简单问答程序,直接调用模型接口就可以:
用户问题 -> 模型 -> 模型回答
但真实应用通常不只有一次模型调用,还需要处理很多外围问题:
| 应用能力 | 具体问题 |
|---|---|
| 模型接入 | 使用本地 Qwen,还是在线模型 API |
| 消息组织 | 哪一条是系统规则,哪一条是用户输入,怎样保存历史对话 |
| 提示词管理 | 怎样把固定内容和变量分开,避免到处拼接字符串 |
| 工具调用 | 怎样让模型查询天气、数据库或业务接口 |
| 输出约束 | 怎样让模型稳定返回 JSON 或固定字段 |
| 状态管理 | 多步骤任务执行到哪一步,中断后怎样继续 |
| 调试评估 | 模型为什么这样回答,哪一步耗时,修改后是否真的变好 |
从本质上讲,大模型提供的是能力,应用框架负责把这些能力组织成程序。
把这些外围能力放在一起,可以看到大模型只负责其中的理解与生成,完整应用还需要组织输入、调用外部能力、控制执行过程并观察运行结果:

图中的几类能力不一定要一次全部引入。它们的作用是帮助我们判断:程序当前只是一次模型调用,还是已经发展成需要框架组织的应用。
1.2 不是所有程序都必须使用框架
如果程序只有一次模型调用,直接使用 OpenAI SDK 或模型厂商 SDK 更简单。
当代码开始反复处理消息、提示词、模型切换、工具调用和多步骤任务时,再引入框架更合适。框架的价值不是让一行代码变得更短,而是让不断扩大的应用仍然有统一结构。
2. LangChain 是什么
在开始学习 LangChain 之前,需要先分清楚三个经常一起出现的名字:LangChain、LangGraph 和 LangSmith。
它们都属于大模型应用开发生态,但解决的问题并不相同。
先给出一个简单结论:
| 组件 | 主要作用 | 可以先理解成 |
|---|---|---|
| LangChain | 连接模型、消息、提示词和工具,构建大模型应用 | 应用开发框架 |
| LangGraph | 管理复杂任务中的状态、步骤、分支、循环和恢复 | 工作流编排框架 |
| LangSmith | 记录调用过程,帮助调试、评估和监控应用 | 观测与评估平台 |
大部分简单程序只需要模型 SDK,或者只使用 LangChain。任务变得复杂以后,才需要考虑 LangGraph;需要看清应用每一步执行情况时,再接入 LangSmith。
本文先介绍三者的定位、关系和适用场景,不展开具体代码。
2.1 LangChain 的定位
LangChain 是一个开源的大模型应用开发框架。
LangChain 1.0 文档把它定位为带有预构建 Agent 架构,并提供模型和工具集成的框架。对于刚开始学习的人,不需要一上来就理解 Agent,可以先把 LangChain 看成一组统一的大模型应用组件。
例如,不同模型服务的 Python SDK 写法通常不一样。LangChain 会在这些服务之上提供相对统一的聊天模型接口:
应用代码
-> LangChain Chat Model
-> 本地 Qwen
-> OpenAI
-> Anthropic
-> Google
更换模型时,业务代码不一定完全不变,但消息调用、流式输出和模型组合方式会更一致。
2.2 LangChain 包含哪些基础能力
结合本系列后续内容,可以先认识下面这些组件:
| 组件 | 作用 |
|---|---|
| Chat Model | 连接本地或在线聊天模型 |
| Message | 表示系统消息、用户消息、AI 消息等聊天内容 |
| Prompt Template | 把提示词中的固定内容和变量组织成模板 |
| Structured Output | 约束模型返回固定的数据结构 |
| Tool | 把普通函数或外部接口包装成模型可以调用的工具 |
| Agent | 让模型根据任务决定是否调用工具以及下一步做什么 |
| Middleware | 在模型调用和 Agent 执行前后增加控制逻辑 |
LangChain 还有大量独立集成包。例如 OpenAI 相关组件位于 langchain-openai,其他模型厂商也通常有各自的 langchain-* 包。
因此,使用下面的导入方式仍然是在使用 LangChain:
from langchain_openai import ChatOpenAI
2.3 什么时候适合使用 LangChain
适合使用 LangChain 的场景:
- 需要用统一方式接入不同聊天模型。
- 需要组织系统消息、用户消息和多轮对话。
- 提示词中有变量,需要复用模板。
- 需要结构化输出、工具调用或 Agent。
- 后续准备接入 LangGraph 或 LangSmith。
如果只是测试模型接口是否可用,直接使用原生 SDK 会更清楚。LangChain 更适合应用开始出现组合逻辑以后再使用。
3. LangGraph 是什么
3.1 LangGraph 的定位
LangGraph 是一个低层级的编排框架和运行时,主要用于构建长时间运行、带状态的 Agent 或工作流。
LangChain 解决的是“有哪些组件可以使用”,LangGraph 更关心“这些步骤按照什么顺序执行”。
例如,一个任务可能需要:
接收用户请求
-> 判断请求类型
-> 查询外部信息
-> 生成回答
-> 检查回答是否合格
-> 不合格则重新生成
-> 必要时等待人工确认
-> 返回最终结果
这里已经不再是一次简单模型调用。流程中出现了状态、条件分支、循环、暂停和恢复,这正是 LangGraph 主要解决的问题。
3.2 LangGraph 中的基本概念
先不写代码,只理解四个基础概念:
| 概念 | 作用 |
|---|---|
| State | 保存当前任务的数据和执行状态 |
| Node | 执行某一步操作,例如调用模型或查询接口 |
| Edge | 决定一个节点执行完以后走向哪里 |
| Checkpoint | 保存执行进度,支持中断后继续运行 |
如果把一个任务画成流程图,Node 就是流程中的方框,Edge 是方框之间的连线,State 是整个流程不断读取和更新的数据。
3.3 LangGraph 适合解决什么问题
| 场景 | 为什么需要 LangGraph |
|---|---|
| 多步骤任务 | 每一步都有明确的输入、输出和执行顺序 |
| 条件分支 | 不同结果进入不同处理节点 |
| 循环与重试 | 结果不合格时返回前面的步骤重新执行 |
| 人工介入 | 流程暂停,等待用户审批或补充信息 |
| 长时间运行 | 一个任务可能跨多次请求才能完成 |
| 故障恢复 | 程序重启后从保存的状态继续执行 |
LangGraph 可以单独使用,并不强制依赖 LangChain。不过在实际项目中,经常使用 LangChain 接入模型和工具,再使用 LangGraph 编排这些组件。
如果只是一次问答,或者固定执行两三个简单函数,没有必要为了“看起来完整”而引入 LangGraph。
4. LangSmith 是什么
4.1 LangSmith 的定位
LangSmith 是大模型应用的观测、调试和评估平台。
普通程序出错时,通常可以看异常栈和日志。但大模型应用即使没有抛异常,结果也可能不符合预期。例如:
程序执行成功
模型也返回了内容
但是回答不准确,或者没有按要求调用工具
这时只看最终回答,很难判断问题出现在哪一步。
4.2 LangSmith 可以看到什么
LangSmith 的 Trace 会记录一次请求从输入到输出的执行过程。常见信息包括:
| 信息 | 可以解决的问题 |
|---|---|
| 用户输入 | 应用实际接收到了什么 |
| 最终 Prompt | 模型真正看到的提示词是什么 |
| 模型调用 | 使用了哪个模型,输入输出是什么 |
| 工具调用 | 调用了什么工具,参数和结果是什么 |
| 执行步骤 | Agent 或工作流依次经过哪些步骤 |
| 耗时与 Token | 哪一步慢,调用成本是否异常 |
| 错误信息 | 失败发生在哪一个步骤 |
LangSmith 中几个常见概念可以这样理解:
| 概念 | 含义 |
|---|---|
| Project | 一组相关 Trace 的集合,通常对应一个应用或环境 |
| Trace | 一次完整操作的执行链路 |
| Run | Trace 中的一个具体步骤,例如一次模型调用 |
| Thread | 由多次 Trace 组成的一段多轮对话 |
除了查看 Trace,LangSmith 还可以使用数据集和评估器比较不同提示词、模型或应用版本的效果,并监控生产环境中的延迟、错误和调用情况。
4.3 LangSmith 是否只能配合 LangChain
不是。
LangChain 和 LangGraph 可以较方便地接入 LangSmith,但 LangSmith 也支持 OpenAI、Anthropic 等其他模型客户端和框架,还可以通过手动埋点记录普通函数。
对于刚开始学习的简单脚本,可以先不接入 LangSmith。当一次请求开始包含多个模型调用、工具调用或工作流节点时,观测能力才会明显体现价值。
5. LangChain、LangGraph、LangSmith 的关系
三者在大模型应用中的位置如下:

这张图重点表达的不是固定调用顺序,而是三者的职责边界和协作关系:
- LangChain 负责组织模型、消息、提示词、工具和结构化输出等应用组件。
- LangGraph 负责复杂流程中的状态、节点、分支、循环和恢复。它可以复用 LangChain 组件,也可以独立编排普通 Python 函数和外部服务。
- LangSmith 位于观测链路,不负责执行模型或推进工作流,而是记录 LangChain、LangGraph 或其他框架的运行过程,用于调试、评估和监控。
三者的边界可以归纳为:
| 问题 | 对应组件 |
|---|---|
| 模型怎样接入应用 | LangChain |
| 消息和提示词怎样组织 | LangChain |
| 工具怎样提供给模型 | LangChain |
| 多个步骤怎样编排 | LangGraph |
| 流程状态怎样保存和恢复 | LangGraph |
| 每一步到底执行了什么 | LangSmith |
| 不同版本效果怎样比较 | LangSmith |
5.1 用一个简单流程理解三者
假设要开发一个周末出行助手,用户问:
周末适合去公园吗?请帮我安排一个简单计划。
应用可能这样处理:
- LangChain 把系统消息和用户问题交给模型。
- LangChain 把天气查询函数包装成工具。
- LangGraph 先执行天气查询,再根据天气结果选择室外或室内方案。
- 如果用户要求确认,LangGraph 暂停流程并等待用户选择。
- LangSmith 记录模型输入、工具参数、天气结果、流程分支和最终回答。
不是每个出行助手都必须同时使用三者。这个例子只是说明:应用复杂度增加后,三者分别在哪个位置发挥作用。
6. 常见误解
6.1 LangChain、LangGraph 和 LangSmith 都不是模型
它们不会替代 Qwen、DeepSeek、GPT 或 Claude。模型负责生成内容,这三个组件负责开发、编排和观测应用。
6.2 它们不负责训练模型
预训练、微调和量化属于模型训练与部署工具链。LangChain 生态主要处理模型已经可以调用以后,应用应该怎样组织。
6.3 使用 LangGraph 不代表必须使用 LangChain
LangGraph 可以独立使用,只是在很多项目中会复用 LangChain 的模型和工具接口。
6.4 使用 LangSmith 不代表应用必须是 LangChain 编写的
LangSmith 可以观测多种框架和模型客户端。LangChain、LangGraph 与 LangSmith 的集成更直接,但不是唯一使用方式。
6.5 简单程序不需要一次引入全部组件
| 当前需求 | 建议选择 |
|---|---|
| 只验证模型是否可用 | 模型 SDK 或 OpenAI 兼容接口 |
| 需要消息、提示词和统一模型接口 | LangChain |
| 需要状态、分支、循环和恢复 | LangGraph |
| 需要追踪、评估和监控 | LangSmith |
框架越多,配置和排查成本也越高。应该根据问题选择组件,而不是为了使用框架而增加框架。
7. 总结
最后记住三句话:
LangChain 负责把模型能力接入应用。
LangGraph 负责把复杂任务编排成有状态的流程。
LangSmith 负责记录、调试、评估和监控应用执行过程。
实际项目中应该根据任务复杂度选择组件,不需要为了使用完整生态而一次引入全部工具。