LangChain、LangGraph、LangSmith 到底什么关系？不是三选一，是三层

一句话总结：LangChain 写逻辑，LangGraph 管状态，LangSmith 看全过程。 它们是「框架 → 运行时 → 观测平台」的三层叠放，不是三个互相替代的竞品——而且你用的 LangChain Agent，底层本来就在跑 LangGraph。

---

📋 目录

1. 一句话分清三者
2. 反常识：它们本来就叠在一起
3. LangChain：十行跑起一个 Agent
4. LangGraph：什么时候才真的需要它
5. LangSmith：改两个环境变量就能看全程
6. 三个坑
7. 到底该用哪个
8. 总结

---

一、一句话分清三者

名字	它是什么	一句话记忆
LangChain	上层框架：模型、工具、Agent 循环的抽象	怎么写
LangGraph	底层运行时：状态图、持久化、中断、流式	怎么跑
LangSmith	外部平台：追踪、评测、Prompt 管理	怎么查

版本参考（2026 年 11 月核对）：langchain 1.4.9、langgraph 1.2.20、langsmith 0.14.17，均要求 Python 3.10+。

---

二、反常识：它们本来就叠在一起

大部分人问的是"该学 LangChain 还是 LangGraph"——这是个伪命题。

官方文档写得很直接：

LangChain agents are built on top of LangGraph … You do not need to know LangGraph for basic LangChain agent usage.

翻译一下：LangChain 的 Agent 就是跑在 LangGraph 上的，只是把那张状态图藏起来了，不让你看见。

所以三者的真实关系是这样叠的：

LangSmith     ← 观测层：追踪 / 评测 / Prompt（不参与运行）
LangChain     ← 框架层：model / tool / agent 循环
LangGraph     ← 运行时：状态图、检查点、中断、流式

这也解释了一个常见困惑：为什么只装了 langchain，却在依赖里看到 langgraph？ 因为它就在下面托着你。

---

三、LangChain：十行跑起一个 Agent

uv add langchain

from langchain.agents import create_agent
from langchain.chat_models import init_chat_model

model = init_chat_model("openai:gpt-5.4")   # 换成你账号可用的模型
agent = create_agent(
    model,
    tools=[],
    system_prompt="你是一个简洁的助手",
)

result = agent.invoke({"messages": [{"role": "user", "content": "你好"}]})
print(result["messages"][-1].text)

它的价值在于省事：模型接入、消息格式、工具调用循环、流式输出，全都封装好了。

代价是你只能改参数，改不了流程。当业务需要"先查库、再判断、失败重试、人工确认"这种有分支和循环的逻辑时，Agent 循环就不够用了。

---

四、LangGraph：什么时候才真的需要它

LangGraph 把流程显式画成图：节点是函数，边是流转，状态在节点之间传递。

from typing import TypedDict
from langgraph.graph import StateGraph, START, END

class State(TypedDict):
    question: str
    answer: str

def answer(state: State):
    return {"answer": f"收到：{state['question']}"}

builder = StateGraph(State)
builder.add_node("answer", answer)
builder.add_edge(START, "answer")
builder.add_edge("answer", END)

graph = builder.compile()
graph.invoke({"question": "你好"})

看起来比 LangChain 麻烦，但它换来了四样东西：

能力	解决什么问题
条件边	根据结果决定走哪条分支
循环	失败重试、工具多轮调用
检查点	中断后从上次的位置继续
中断	暂停等人审批，再恢复执行

给图加上检查点，就能跨请求保存状态：

from langgraph.checkpoint.memory import InMemorySaver

graph = builder.compile(checkpointer=InMemorySaver())
graph.invoke(
    {"question": "你好"},
    {"configurable": {"thread_id": "user-1"}},
)

判断标准很简单：如果你的流程能用一段 while 循环写完，就用 LangChain；如果需要画在纸上才说得清，就上 LangGraph。

---

五、LangSmith：改两个环境变量就能看全程

LangSmith 不是框架，不参与运行，它是外挂在旁边的一台"X 光机"。

export LANGSMITH_TRACING=true
export LANGSMITH_API_KEY=ls_xxx

就这两行，langchain / langgraph 里的每次模型调用、工具调用、耗时、Token 数、输入输出，都会自动上报到网页上。

它能回答的问题，恰恰是调试时最费时间的那些：

• 这次回答为什么错了？模型到底收到了什么 Prompt
• 哪一步最慢、最贵？是检索还是生成
• 改了 Prompt 之后，效果是变好还是变差

它不绑定 LangChain。 官方明确说兼容任何 LLM 应用，甚至可以用 wrap_openai() 直接包住原生 OpenAI SDK：

from langsmith.wrappers import wrap_openai
from openai import OpenAI

client = wrap_openai(OpenAI())

所以即使你的项目完全不用 LangChain，也可以单独用它做观测。

---

六、三个坑

坑 1：环境变量改名了，旧教程的开关不生效

网上大量文章还在写：

export LANGCHAIN_TRACING_V2=true
export LANGCHAIN_API_KEY=ls_xxx

现在是 LANGSMITH_TRACING 和 LANGSMITH_API_KEY。写旧名字不会报错，只是不上报任何数据——你很容易误以为是网络或 Key 的问题，白查半天。

坑 2：InMemorySaver 重启就丢

它把检查点存在内存里，进程一重启全没了。开发调试够用，生产要换成 SqliteSaver 或 PostgresSaver。

坑 3：一上来就画图

LangGraph 很灵活，但灵活是有成本的——节点、边、状态、reducer 都要自己设计。简单的 Agent 用 create_agent 十行就够，官方也说了不会 LangGraph 也能正常用。

先跑通，再重构，别反过来。

---

七、到底该用哪个

你的情况	选谁
想半天内跑通一个能用的 Agent	LangChain
流程有分支 / 循环 / 人工审批 / 断点续跑	LangGraph
要查"为什么答错"、要跑评测、要管 Prompt	LangSmith
只想看看模型调用的耗时和 Token	LangSmith（不用换框架）

注意这不是单选题。一个正常的生产项目，通常是三个一起用：LangChain 写业务、LangGraph 管流程、LangSmith 看数据。

---

八、总结

应该做

• 先用 LangChain 把功能跑通，别提前上复杂度
• 流程画不清的时候，再换 LangGraph
• 从第一天就开 LangSmith，出了问题才有数据可查
• 环境变量用 LANGSMITH_* 新名字

不要做

• 别把三者当成"三选一"的竞品
• 别用 InMemorySaver 上生产
• 别为了显得高级，给一个线性流程硬画状态图

一句话记住：LangChain 是手，LangGraph 是骨架，LangSmith 是 X 光。

---

数据说明：版本号取自 PyPI 项目页（2026 年 11 月），示例模型名来自官方文档，请替换成你账号实际可用的模型。LangChain 1.x 相对 2024 年的教程有大量破坏性变更，老代码可能直接 ImportError。

---

如果这篇帮你理清了三者关系，欢迎点赞收藏。