LangChain 与 LangGraph 详解：Agent 框架技术栈

TL;DR — LangChain 是 Python/JS 的可组合 LLM 应用框架。LangGraph 是它的 Agent 运行时——基于图的编排层，支持持久状态、循环、分支和 human-in-the-loop。2026 年真正出彩的是 LangGraph：Lyft、Replit、Uber、LinkedIn 的 Agent 系统跑在上面。LangChain 提供组件（工具、记忆、检索）；LangGraph 把它们连成有状态的 Agent 工作流。

2026 年的 LangChain 生态

LangChain 已经不是一个东西了，是一个家族：

组件	做什么
LangChain（核心）	可组合组件：模型接口、工具、检索器、记忆、输出解析器
LangGraph	基于图的 Agent 编排运行时，带持久执行
LangSmith	可观测性、评估和调试平台（SaaS）
LangServe	把 chain/graph 部署为 REST API

心智模型：LangChain = 零件。LangGraph = 你把零件连成 Agent 的方式。

先交代立场：2024 年大声吐槽 LangChain 的人里就有我。抽象套抽象，一个简单的 OpenAI 调用变成四层 wrapper 类，API 在小版本之间就给我改了。所以当我说 2026 年的 LangGraph 值得你花时间，这不是粉丝的话——是一个走开过又回来的人说的，因为图这个原语解决了我手搓循环反复撞上的问题。

关键数据：

指标	数值
GitHub stars（langchain）	105K+
OpenRank（2026年5月）	283.94
活跃贡献者	239
LangGraph 月搜索量	33,100+
生产用户	Lyft, Replit, Uber, LinkedIn, GitLab
许可证	MIT

为什么 LangGraph 比 LangChain 本身更重要了

2024 年大家说”我用 LangChain 建”。2026 年说”我用 LangGraph 建”。变化发生是因为 Agent 需要的不只是链。

链是线性的：输入 → 步骤 A → 步骤 B → 输出。Agent 是图：它循环、分支、重试、等人类输入、跨轮次维护状态、并行跑步骤。LangChain 原来的 chain 抽象表达不了这些。

LangGraph 给你：

节点 — 每个节点是一个函数，接收状态、做事（调 LLM、用工具、检查条件）、返回更新后的状态。

边 — 定义节点间的流向。可以无条件（“A 之后总是去 B”）或有条件（“如果工具返回错误，回规划节点”）。

状态 — 共享的、有类型的状态对象，流过整个图。每个节点读写它。状态在整个 Agent 运行期间持久化。

循环 — 图可以回路。Agent 可以重试、反思、迭代。这就是它”agentic”和简单流水线的区别。

from langgraph.graph import StateGraph, END

class AgentState(TypedDict):
    messages: list
    plan: str
    attempts: int

graph = StateGraph(AgentState)
graph.add_node("plan", plan_node)
graph.add_node("execute", execute_node)
graph.add_node("evaluate", evaluate_node)

graph.add_edge("plan", "execute")
graph.add_conditional_edges("evaluate", should_continue, {
    "retry": "execute",
    "revise_plan": "plan",
    "done": END,
})
graph.set_entry_point("plan")

agent = graph.compile()

这是一个 plan-execute-evaluate 循环带重试。Agent 一直跑直到 evaluate 认为完成或需要修改计划。在 LangGraph 里这很简单，从头搭很痛苦。

Agent Builder 的关键功能

持久执行 — 状态有 checkpoint。Agent 跑一半崩了，从最近 checkpoint 恢复。对长时间 Agent 任务关键（多小时 coding session、研究工作流）。

Human-in-the-loop — 在任意节点暂停图，等人类审批或输入，然后继续。暂停之间状态持久化。

流式输出 — 随 Agent 穿过节点流式输出中间结果。用户实时看到 Agent 在想什么，不只是最终输出。

子图 — 把小图组合成大图。“代码审查”子图可以从”PR 流水线”图里调用。模块化 Agent 架构。

多 Agent — 多个 Agent 作为大图的节点。监督者 Agent 把任务路由给专家 Agent（研究员、编码者、审查者）并聚合结果。

LangChain + LangGraph vs 其他选择

框架	范式	最适合	弱点
LangGraph	带持久状态的图	复杂有状态 Agent、生产	学习曲线，简单任务太重
Mastra	TypeScript 优先、有主见	TS/JS 全栈团队	生态更年轻
CrewAI	角色制多 Agent	快速多 Agent 原型	执行流程控制弱
AutoGen	基于对话的多 Agent	研究、实验	难生产化
Dify	可视化工作流	非开发团队、快速原型	代码控制弱

LangGraph 赢在需要精细控制 Agent 行为、持久长时间执行和类型化状态机的场景。在你想要更简单的东西或团队是 TypeScript 为主（Mastra 更合适）时它输。

诚实评价

LangChain 有口碑问题。早期版本（2023-2024）被批评过度抽象、API 频繁变动、感觉增加复杂度但价值不成比例。“LangChain 太复杂”的吐槽是有道理的。

2026 年现实不同了。LangChain 1.0 稳定了 API 面。LangGraph 找到了自己的生态位——有状态 Agent 编排的真实有用原语。框架拆成了清晰结构：要用 LangChain 组件就用，要用 LangGraph 做运行时就用，不需要的忽略。

但复杂度批评仍有道理。简单 Agent（单循环、单模型、几个工具），LangGraph 杀鸡用牛刀。30 行 while 循环就能搞定。LangGraph 在这些场景才值得：

• 带分支逻辑的多步工作流
• 状态需要跨故障持久化
• Human-in-the-loop 暂停
• 多 Agent 协调
• 生产要求（streaming、可观测性、checkpointing）

生产教训：真实部署里什么会咬人

教程给你看 graph.compile() 和一次顺利运行。生产环境才让你学到文档一笔带过的部分。

**Checkpointing 不是免费的，后端选择很重要。**LangGraph 的持久执行依赖每个节点后持久化状态的 checkpointer。默认的 MemorySaver 是给 demo 的——重启丢光。生产用 PostgresSaver 或 RedisSaver。坑在于：现在每次节点切换都是一次数据库写。一个 20 节点的话痨 Agent 在负载下，每次运行 20 次 DB 往返。我们见过 checkpoint 写入成为延迟瓶颈，而不是 LLM。缓解：别在琐碎节点后 checkpoint——只在有意义的恢复点 checkpoint（昂贵操作之后、human-in-the-loop 暂停之前）。

**状态悄悄增长直到撑爆上下文。**LangGraph 状态跨节点累积。常见错误：把每个工具结果和每条消息都追加到一个 messages 列表，每轮都传给模型。到第 30 步，你每次调用都发 80K token 的累积历史——又慢又贵。你需要显式状态修剪：总结旧轮次、丢弃过时工具输出、只留下一步需要的。这是和Agent 记忆架构一样的上下文窗口压力，LangGraph 不替你解决。

**条件边以难调试的方式失败。**条件边根据你写的函数路由。如果那个函数返回一个不在路由映射里的 key，LangGraph 运行时抛错——执行中途，在你已经花了 token 之后。永远包含一个兜底路由和一个最大迭代计数器。没有计数器，行为异常的条件边产生无限循环，烧光你的 API 预算直到你发现。

# 每个生产图都需要的护栏
def should_continue(state: AgentState) -> str:
    if state["attempts"] >= MAX_ATTEMPTS:   # 硬上限
        return "done"
    if state.get("error_count", 0) > 3:
        return "escalate_to_human"
    return state.get("next_action", "done")  # 默认，永不崩

graph.add_conditional_edges("evaluate", should_continue, {
    "retry": "execute",
    "escalate_to_human": "human_review",
    "done": END,
})

**Streaming + checkpointing 交互别扭。**当你同时流式输出 token 和 checkpoint 状态，你得决定进程在流中途死掉时怎么办。Checkpoint 捕获的是节点完成的状态，不是流到一半的输出。恢复时节点重跑。对幂等节点没问题；对有副作用的节点（发了邮件、扣了款），恢复时重跑导致重复。让有副作用的节点幂等，或用状态里的”已完成”检查守护它们。

在技术栈中的位置

┌─────────────────────────────────────┐
│  你的应用 / API                      │
├─────────────────────────────────────┤
│  LangGraph（Agent 编排）             │  ← 运行时层
│  LangChain（组件）                   │  ← 工具、检索器、记忆
├─────────────────────────────────────┤
│  模型网关（LiteLLM / SandBase）      │
├─────────────────────────────────────┤
│  推理引擎（vLLM / SGLang / 云 API）  │
└─────────────────────────────────────┘

LangGraph 是编排运行时。它不服务模型——它调用模型。它不管基础设施——它依赖你配好的模型端点。配合 LiteLLM 做多模型路由，配合 SandBase 这样的沙箱做代码执行。

FAQ

该学 LangChain 还是 LangGraph？

LangGraph。它解决的是难问题（有状态 Agent 编排）。LangChain 组件有用但可选——你可以用 LangGraph 搭配原生 OpenAI SDK 调用。

2026 年 LangChain 还有用吗？

有，但方式不同了。它不再是”LLM 应用的框架”，而是”LangGraph 用的组件库”。生态（LangSmith、集成、社区）在 Python Agent 领域仍然最大。

LangGraph vs 自建 Agent 循环？

简单 ReAct agent：自建，30 行。任何有分支、重试、状态持久化、human-in-the-loop 或多 Agent 协调的：LangGraph 省你几周基础设施工作。

LangGraph 支持 TypeScript 吗？

支持。LangGraph JS/TS 版本活跃维护。但如果你是 TypeScript 为主，也看看 Mastra——专为 TS 生态打造。

LangSmith 必须用吗？

不。LangSmith 是付费可观测平台。LangGraph 不依赖它。但生产调试（为什么 Agent 选了这条路？第 7 步时状态是什么？）需要可观测性——不管是 LangSmith 还是开源替代品。

核心要点

• LangGraph 是 LangChain 生态的生产级 Agent 运行时。它把 Agent 建模为状态机（图），带节点、边和持久状态。
• Lyft、Uber、LinkedIn、Replit 等公司的 Agent 系统跑在上面——真实生产验证。
• 需要持久执行、分支逻辑、human-in-the-loop 或多 Agent 协调时用它。简单单循环 Agent 不需要。
• LangChain 提供组件；LangGraph 提供运行时。互补但可分离。
• 主要竞争：Mastra（TypeScript 优先）和 CrewAI（更简单的多 Agent）。LangGraph 以简单换控制。