LangChain 系列 1:先搞懂 LangChain、LangGraph、LangSmith 是什么


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 的场景:

  1. 需要用统一方式接入不同聊天模型。
  2. 需要组织系统消息、用户消息和多轮对话。
  3. 提示词中有变量,需要复用模板。
  4. 需要结构化输出、工具调用或 Agent。
  5. 后续准备接入 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、LangSmith 在大模型应用中的位置

这张图重点表达的不是固定调用顺序,而是三者的职责边界和协作关系:

  1. LangChain 负责组织模型、消息、提示词、工具和结构化输出等应用组件。
  2. LangGraph 负责复杂流程中的状态、节点、分支、循环和恢复。它可以复用 LangChain 组件,也可以独立编排普通 Python 函数和外部服务。
  3. LangSmith 位于观测链路,不负责执行模型或推进工作流,而是记录 LangChain、LangGraph 或其他框架的运行过程,用于调试、评估和监控。

三者的边界可以归纳为:

问题 对应组件
模型怎样接入应用 LangChain
消息和提示词怎样组织 LangChain
工具怎样提供给模型 LangChain
多个步骤怎样编排 LangGraph
流程状态怎样保存和恢复 LangGraph
每一步到底执行了什么 LangSmith
不同版本效果怎样比较 LangSmith

5.1 用一个简单流程理解三者

假设要开发一个周末出行助手,用户问:

周末适合去公园吗?请帮我安排一个简单计划。

应用可能这样处理:

  1. LangChain 把系统消息和用户问题交给模型。
  2. LangChain 把天气查询函数包装成工具。
  3. LangGraph 先执行天气查询,再根据天气结果选择室外或室内方案。
  4. 如果用户要求确认,LangGraph 暂停流程并等待用户选择。
  5. 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 负责记录、调试、评估和监控应用执行过程。

实际项目中应该根据任务复杂度选择组件,不需要为了使用完整生态而一次引入全部工具。


文章作者: hnbian
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 hnbian !
评论
  目录