做 LLM 应用的人大概率绕不开 LangChain 这个名字，但今天它早已不是一个库，而是一条产品线：LangChain、LangGraph、LangSmith 各管一段。第一次接触很容易被相似的名字搞混，甚至用错位——拿组件库硬扛复杂编排，或者把观测平台当库来装。
三者关系有个好记的类比：造一辆 agent 的话，LangChain 是零件目录，LangGraph 是底盘和传动系统，LangSmith 是行车记录仪加诊断电脑。本文按概览、组件库、编排引擎、观测平台、选型建议的顺序逐个拆开；文中信息截至 2026 年中，具体接口以官方文档为准。
1、三件套概览
按诞生顺序排列，三者的定位差异一目了然：
| 产品 | 诞生 | 形态 | 一句话定位 |
|---|---|---|---|
| LangChain | 2022 | Python 与 JS 组件库 | 常见零件的现成积木 |
| LangSmith | 2023 | SaaS 平台 | 全链路追踪、评测与监控 |
| LangGraph | 2024 | 编排引擎 | 把应用建模成可循环的状态图 |
发展脉络决定了分工：先是 2022 年把搭 LLM 应用的常见零件做成库；应用上线后冒出"为什么这么答、改了提示词是变好还是变坏"的新问题，观测平台在 2023 年补位；接着大家发现复杂 agent 的行为是循环，单向流水线表达不了，2024 年又造了图引擎。三者独立可用，也可以任意组合。
2、LangChain 组件库
LangChain（GitHub 仓库）是最早的产品，定位是零件目录：把构建 LLM 应用的常见零件做成现成积木。主要积木如下：
| 组件 | 解决什么 |
|---|---|
| 模型接入 | 各家模型统一接口，换模型不动业务码 |
| 提示词模板 | 提示词变量化，统一管理复用 |
| 文档加载器 | 各格式文档读成统一文本 |
| 向量检索 | 切片、嵌入、向量库对接，RAG 一条龙 |
| 输出解析器 | 把自由文本解析成结构化数据 |
积木用 LCEL（LangChain Expression Language）拼装，声明式管道的写法如下：
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain.chat_models import init_chat_model
llm = init_chat_model("openai:gpt-4o-mini") # 换任意厂商的模型串
prompt = ChatPromptTemplate.from_template("用一句话解释{concept}")
chain = prompt | llm | StrOutputParser() # 竖线把零件串成管道
chain.invoke({"concept": "向量检索"})
竖线的含义是数据从左往右流：填模板、调模型、解析输出，一条链就成型了，同步异步通用。这套写法适合快速搭原型和问答、摘要、RAG 类标准场景。早期版本还有"链（Chain）"的概念，把提示词、模型、后处理串成固定流水线——但链是单向的，走一遍就结束，这个局限在 agent 场景会致命，见下一节。
3、LangGraph 状态图编排
LangGraph（GitHub 仓库）专治链搞不定的场景。agent 的本质行为是循环：模型思考、调工具、看结果、再思考、再调工具……单向流水线表达不了循环，LangGraph 的答案是状态图：节点是步骤（调模型、执行工具），边可以带条件和回路，中间维护共享状态。最小 agent 循环的结构如下：
图中"工具节点回到模型节点"那条边，正是链做不到的回路。对应的最简实现如下：
from langgraph.graph import StateGraph, MessagesState, START, END
from langgraph.prebuilt import ToolNode
def call_model(state: MessagesState):
return {"messages": [llm.invoke(state["messages"])]}
def should_continue(state):
return "tools" if state["messages"][-1].tool_calls else END
graph = StateGraph(MessagesState)
graph.add_node("model", call_model)
graph.add_node("tools", ToolNode(tools)) # 预置工具执行节点
graph.add_edge(START, "model")
graph.add_conditional_edges("model", should_continue) # 条件边决定走向
graph.add_edge("tools", "model") # 回路在此
agent = graph.compile()
除了循环，LangGraph 还补上两个生产级刚需：断点续跑——每步状态持久化，进程崩了从断点恢复；人工介入——执行到指定节点暂停，等人批准后继续。这两点是把 agent 从 demo 带到生产的分水岭。现在复杂 agent 的官方推荐都是 LangGraph，LangChain 新版的 create_agent 底层也是它。
4、LangSmith 观测平台
LangSmith（官方文档）不是库，是 SaaS 平台，管"跑起来之后"的事。上线后迟早会撞上三个问题：模型这次为什么这么答？哪一步耗时最长？改了提示词之后效果是变好还是变坏？LangSmith 的能力围绕这三问展开：
| 能力 | 说明 |
|---|---|
| 全链路追踪 | 每个节点的输入输出、耗时、token 消耗 |
| 数据集评测 | 一批测试用例，给新旧版本打分对比 |
| 线上监控 | 流量、错误率、成本看板 |
| 提示词管理 | 版本化、回滚、团队共享 |
它相当于 LLM 应用的 APM 加实验室。接入成本很低，打开追踪开关即可自动上报，示例如下：
import os
os.environ["LANGSMITH_TRACING"] = "true" # 开关一开，自动全链路追踪
配置后无需改业务代码，每次调用自动挂到追踪时间线上。有一点需要注意：
LangSmith 是云服务，调用数据会上报云端；隐私敏感场景要确认合规口径，或考虑自托管部署选项。
5、选型与组合建议
三者独立可用，按场景组合即可，常见搭配如下：
| 场景 | 建议 |
|---|---|
| 问答、摘要、RAG 等标准流程 | LangChain 组件拼装即可，不必上图 |
| 多步循环、人工审批、要可恢复 | 用 LangGraph 做编排 |
| 已上线，需要调优与回归 | 尽早接入 LangSmith 做观测评测 |
实际工程里有个明显趋势：不少团队跳过 LangChain 直接用 LangGraph。原因不复杂——零件自己拼往往更干净，而编排与观测才是真正难以自研的部分，精力应该花在刀刃上。回到开头的类比：
LangChain 是零件目录，LangGraph 是底盘和传动系统，LangSmith 是行车记录仪加诊断电脑——三者独立可用，组合起来才是完整工作流。
6、总结
回顾全文：LangChain 是组件库，解决零件有没有的问题，适合原型与标准场景；LangGraph 是编排引擎，用状态图表达循环、支持断点续跑与人工介入，是复杂 agent 的正确底座；LangSmith 是观测平台，把"为什么这么答"从玄学变成可查的追踪与可比较的评测。对于正在选型的团队，建议标准场景直接用组件库，一旦出现循环或审批需求就果断切 LangGraph，并在第一次上线前把 LangSmith 接上——提示词调优没有追踪数据，等于闭着眼睛调。
