LangGraph vs LangChain：同一生态的两副面孔

深度剖析两大框架的架构基因、适用疆界与协同之道

读完 LangChain 又读完 LangGraph 的文档，我脑子里跳出一个画面：一个木匠的工具箱里，既有锤子又有电钻。你说锤子和电钻哪个更好？没人这么问——因为答案永远是"看你钉钉子还是打孔"。

LangChain 和 LangGraph 的关系，恰如这锤子与电钻。同为一家公司（LangChain Inc.）出品，同属一个生态，却解决截然不同的问题。然而社区里"LangChain vs LangGraph"的争论从未停歇，盖因两者的边界在演进中几经漂移，让人眼花。

本文欲正本清源：不拉踩，不站队，只求把两张面孔描清楚——它们各自的基因是什么，各自的疆界在哪里，何时该独当一面，何时又该联手上阵。

1. 缘起：从一条链到一张图

故事要从 2022 年讲起。

那年 10 月，Harrison Chase 开源了 LangChain。彼时大模型应用开发的痛点极其朴素：你得手动拼接 prompt、调用 API、解析输出、再喂给下一个 prompt——这些"胶水代码"重复且脆弱。LangChain 的答案是一套组件 + 链式编排：把 LLM、提示模板、向量存储、文档加载器这些积木标准化，再用 Chain 把它们串起来。

这个模式在 2023 年大获成功。LangChain 的 GitHub Star 数半年内从零飙到 8 万，成了 LLM 应用开发的事实标准。

但它内置了一个致命假设：数据沿链单向流动，有进无退，有去无回。

这假设在 RAG 管道、文本翻译、摘要生成这类"一次过"场景中完全成立。可一旦你开始构建 Agent——那种需要"搜一搜 → 想一想 → 不够再搜 → 够了再回答"的系统——线性链的局限性就暴露无遗。你要循环，它不给；你要回溯，它不干；你要在某个节点暂停等人工审批，它根本没这个概念。

2023 年秋，LangChain 团队意识到这个问题，基于 Google Pregel 的批量同步并行模型，开源了 LangGraph。这个新框架的核心理念极其简单：把 Agent 工作流建模为有向图，节点是计算函数，边是控制流，支持循环、分支和条件路由。

2025 年 10 月 22 日，两个库同时发布 v1.0 GA。分工从此明确：

• LangChain → Agent 框架：提供模型、工具、提示的抽象与集成
• LangGraph → 编排运行时：提供持久执行、流式传输、人机协同、断点恢复

自此，LangChain 的 create_agent 方法底层就在跑 LangGraph 的图引擎。它们从未被设计为竞争关系——可惜，这个事实不是所有人都知道。

2. 架构基因：DAG 对 StateGraph

欲明其异，先观其骨。

2.1 LangChain：管道的哲学

LangChain 的核心抽象是 Chain——一种将组件串联的声明式管道。其最新表达形式是 LCEL（LangChain Expression Language）：

from langchain.prompts import ChatPromptTemplate
from langchain.chat_models import ChatOpenAI
prompt = ChatPromptTemplate.from_template("将以下文本翻译成英文：{text}")
model = ChatOpenAI()
chain = prompt | model  # 管道操作符
result = chain.invoke({"text": "你好，世界！"})

管道操作符 | 是 LCEL 的灵魂。它让组件组合像 Unix 管道一样直观——A 的输出自动成为 B 的输入。这很美，也很局限。

LCEL 的底层是一个 DAG（有向无环图） 执行模型。每个步骤有确定的后继，数据单向流动，不存在循环。它适合的场景极其精确：输入 → 处理1 → 处理2 → ... → 输出，一步接一步，从不回头。

2.2 LangGraph：状态机的哲学

LangGraph 的核心抽象是 StateGraph——以显式状态为中心的有向图，允许循环。它直接从 Google 的 Pregel 论文汲取灵感，采用批量同步并行（BSP）模型：

每个超步(superstep) = Plan → Execute → Update

与传统链式调用有三大根本区别：

其一，显式状态。 你用 TypedDict 定义全局状态 Schema，每个节点只读状态、只写部分更新：

from typing import Annotated, TypedDict
import operator
class AgentState(TypedDict):
    messages: Annotated[list, operator.add]  # 追加而非覆盖
    research_done: bool
    findings: list

Annotated[list, operator.add] 是个精巧设计——它告诉运行时：当多个节点同时写 messages 时，用加法合并（即追加），而非覆盖。你还可以定义自己的 reducer 函数来实现任意合并策略。

其二，显式控制流。 每个路由决策都是一个命名函数，而非隐藏在运行时内部的魔法：

def should_continue(state: AgentState):
    """是否继续搜索？这是一个你写的显式函数。"""
    if len(state["findings"]) >= 3:
        return "summarize"  # 够了，去总结
    return "search"          # 还不够，继续搜

其三，图即文档。 编译后的图可导出为 Mermaid 图表，也可在 LangSmith Studio 中可视化调试。你一眼就能看懂整个 Agent 的执行逻辑——这在代码审查和合规审计中价值连城。

2.3 一张表看透差异

3. Agent 范式：隐式循环 vs 显式图

这才是两框架真正拉开差距的地方——Agent 的实现方式。

3.1 LangChain：一行搞定（但你不知道它做了什么）

LangChain v1.0 的 create_agent 用极少代码启动一个 Agent：

from langchain.agents import create_agent
from langchain_openai import ChatOpenAI
from langchain_community.tools import TavilySearchResults
agent = create_agent(
    ChatOpenAI(model="gpt-4o-mini"),
    [TavilySearchResults(max_results=3)],
    system_prompt="You are a helpful assistant."
)
result = agent.invoke({"messages": [("user", "What is LangGraph?")]})

四行代码，Agent 就跑起来了。它会自动判断何时搜索、何时回答、如何循环。这适合80% 的常见场景。

但代价是什么？你完全看不到决策过程。 工具调用的路由逻辑被封在运行时里，调试时只能看最终输出，无法检查 Agent 在第三步为什么选择了搜索而非回答。

3.2 LangGraph：二十行代码（但你对每个决策了如指掌）

同一个 Agent，用 LangGraph 原生写法：

from langgraph.graph import StateGraph, END
from langgraph.graph.message import add_messages
from langgraph.prebuilt import ToolNode
from typing import TypedDict, Annotated
class AgentState(TypedDict):
    messages: Annotated[list, add_messages]
model = ChatOpenAI(model="gpt-4o-mini").bind_tools(tools)
tool_node = ToolNode(tools)
def call_model(state: AgentState):
    return {"messages": [model.invoke(state["messages"])]}
def should_use_tool(state: AgentState):
    last_msg = state["messages"][-1]
    return "tools" if last_msg.tool_calls else END
graph = StateGraph(AgentState)
graph.add_node("agent", call_model)
graph.add_node("tools", tool_node)
graph.set_entry_point("agent")
graph.add_conditional_edges("agent", should_use_tool)
graph.add_edge("tools", "agent")
app = graph.compile()

代码量翻了五倍，但每行都在告诉你一件事：图在何时、基于什么条件、把控制权交给哪个节点。 should_use_tool 是你写的 Python 函数，里面可以加日志、埋点、任何你想要的逻辑。

深入一层：create_agent 的底层本身就是在一个 LangGraph StateGraph 上跑的——它不过是帮你写好了那二十行中的十五行，留给你五行定制空间。

4. 独门绝技：LangGraph 的三大杀器

若问 LangGraph 凭什么在 Agent 框架的混战中站稳脚跟，答案绕不开这三样。

4.1 Checkpointer：时间旅行与故障恢复

每个超步完成后，Checkpointer 自动保存完整状态快照到 SQLite 或 Postgres：

from langgraph.checkpoint.sqlite import SqliteSaver
checkpointer = SqliteSaver.from_conn_string("checkpoints.db")
app = graph.compile(checkpointer=checkpointer)
# 如果执行崩溃了，用同一个 thread_id 恢复
config = {"configurable": {"thread_id": "user-123"}}
app.invoke({"messages": [("user", "复杂任务...")]}, config)
# 💥 崩溃了，没关系
app.invoke(None, config)  # 从上一个检查点继续

这意味着长时间运行的 Agent 任务不再是噩梦。你的 Agent 可以跑几分钟、几小时、甚至跨会话——Checkpointer 保证状态不丢。

更妙的是时间旅行调试：你可以回放到第 N 步的状态，检查当时 Agent 在想什么、工具返回了什么、为什么做了那个决策。这不叫调试，这叫"拿着回放按钮看 Agent 的灵魂"。

4.2 Human-in-the-Loop：精确中断与人工审批

人和 Agent 协作的最高境界不是"人看 Agent 跑完再检查"，而是"Agent 跑到关键点时主动停下来问人"。LangGraph 的 interrupt() 让这变得极其优雅：

def sensitive_action_node(state: AgentState):
    proposed = "发送批量邮件给 10000 个用户"
    # 🛑 在此暂停，等待人工审批
    approval = interrupt({"proposed_action": proposed})
    if approval.get("approved"):
        send_emails()  # 实际发送
        return {"messages": [f"已发送: {proposed}"]}
    return {"messages": ["用户取消了操作"]}

人工审批者看到中断信息后：

# 审批通过，恢复执行
app.invoke(Command(resume={"approved": True}), config)

你可以把 interrupt() 放在图的任意节点，实现任意粒度的 HITL。CrewAI 和 AutoGen 做不到这种精确度——它们通常只能在整个任务完成后插入审查。

4.3 流式输出的七种武器

LangGraph 支持七种流模式，每种服务于不同的调试和交互需求：

这七种模式可以组合使用，比如同时用 messages 做打字机效果、updates 做进度条——你在构建生产级 Agent 时才会意识到这有多重要。

5. 多 Agent 竞技场：LangGraph vs CrewAI vs AutoGen

LangGraph 不是唯一的 Agent 编排框架。把它放进竞技场，和 CrewAI、AutoGen 同台对比，更能看清各自的基因。

5.1 三种哲学

CrewAI 的门槛最低——定义 Agent 的角色和背景故事，框架自动调度。AutoGen 则擅长需要代码执行和多轮对话优化的场景。LangGraph 的学习曲线最陡，但也赋予你最大的控制自由度。

5.2 能力雷达图

              可观测性
                  ▲
                  │ LangGraph ⭐⭐⭐⭐⭐
                  │
    状态持久化 ────┼──── 学习曲线（越低越好）
    LangGraph ✅   │      CrewAI ⭐⭐⭐⭐
    CrewAI   ⚠️    │      AutoGen ⭐⭐⭐
    AutoGen  ❌    │      LangGraph ⭐⭐
                  │
                  │
              部署灵活性 ←──→ Token 效率
                             LangGraph ⭐⭐⭐⭐⭐
                             CrewAI   ⭐⭐⭐⭐
                             AutoGen  ⭐⭐⭐

具体到数字：同一任务，LangGraph 每次循环约 2000 tokens，CrewAI 约 3500，AutoGen 因对话式驱动常达 8000。在高频 Agent 调用场景中，Token 效率直接转化为成本差异。

5.3 选型决策树

你的场景需要什么？
       │
 ┌─────┼──────┬──────────┐
 ▼     ▼      ▼          ▼
精确  角色化  代码执行   Microsoft
控制  协作   迭代优化   生态集成
 │     │      │          │
 ▼     ▼      ▼          ▼
Lang- CrewAI AutoGen  AutoGen/
Graph              MAF

关键更新：2025 年 10 月，Microsoft 将 AutoGen 与 Semantic Kernel 合并为 Microsoft Agent Framework（MAF）。AutoGen 不再作为独立库接收重大更新，但其对话驱动思想被 MAF 继承。

6. 迁移路线：从旧世界到新世界

如果你已有 LangChain 旧版（AgentExecutor）代码，官方推荐的演进路径很清晰：

Step 0: AgentExecutor（旧版，2025 年前）
   │  隐藏的 agent_scratchpad，调试如盲人摸象
   │
   ▼
Step 1: create_agent（LangChain v1.0，2025.10 起）
   │  4 行代码启动 Agent，底层跑 LangGraph
   │  适合 80% 的场景
   │
   ▼
Step 2: 自定义 StateGraph（需要完全控制时）
      显式节点、条件边、检查点、HITL
      适合复杂生产系统

判断标准极其简单：如果你的 Agent 需要——循环（重试 / "不够再搜"）、分支（不同输入不同路径）、中断（人工审批）、持久化（跨会话恢复）——四项中任何一项，就该写自定义 StateGraph。一项都不需要，create_agent 足够。

6.1 增量迁移：2-4 周

不推倒重来，而是渐进式把旧 Chain 包装为 LangGraph 节点：

• 识别现有代码中使用 while 循环或 if-elif 路由的变通方案
• 定义 TypedDict 状态模式，捕获所有数据流
• 将现有 Chain 包装为 LangGraph 节点函数
• 用条件边替换手动路由逻辑
• 接入 Checkpointer 以持久化状态

6.2 全量重写：4-8 周

适用于两种情况：代码库已被变通方案搞得难以维护，或正在从零构建新的多 Agent 系统。此时应直接从 StateGraph 起步，充分利用调试和可视化工具。

7. 实战选型矩阵

8. 2026 年的格局与趋势

8.1 框架不是问题，可靠性才是

LangChain 2026 年开发者调查显示：32% 的团队认为不可靠的性能是扩展 Agent AI 的最大障碍。框架选择排不进前四。 真正的问题是——Agent 能不能稳定产出正确结果，以及失败时能不能优雅恢复。

这正是 LangGraph 发力的方向：通过 Checkpointer 做故障恢复，通过 interrupt() 做人机协同，通过七种流模式做可观测性。框架之争正在退潮，可靠性之争才是主战场。

8.2 框架融合正在发生

三大框架的优秀设计理念正在互相渗透：

• LangGraph 的精确控制 → CrewAI v2 引入了 Flows（类图结构）
• CrewAI 的角色隐喻 → LangGraph 社区发展出基于角色的多 Agent 模式
• AutoGen 的对话驱动 → LangGraph 通过 Send API 支持动态消息路由

框架选型越来越不是"三选一"，而是在理解各框架基因的基础上、根据场景需求做组合。

8.3 最终建议

用 LangChain 的地方：一切线性任务。翻译、摘要、RAG 管道、单轮 Q&A。LCEL 管道的简洁性在这些场景中无可替代。

用 LangGraph 的地方：一切有循环、有分支、有中断、有多 Agent 的系统。研究型 Agent、客服流程、审批工作流、长时任务。

用两者结合的地方：绝大多数生产系统。LangChain 提供组件集成和 create_agent 快速启动，LangGraph 提供状态管理和编排控制。它们本就是同一个栈的两个层，协同使用才是设计者的初衷。

9. 结语

回到文章开头的比喻：锤子和电钻。

LangChain 是那把锤子——简单、直接、一锤定音。对于钉钉子的活（线性管道），它完美无缺。

LangGraph 是那把电钻——需要学习、需要接线、一键启动不够。但当你面对钢筋水泥（循环、分支、持久化、多 Agent），它才是你手里能打的工具。

真正成熟的工程师不会问"锤子和电钻哪个好"，他们会把两样都放进工具箱，然后根据眼前的活，伸手去拿对的那把。

2026 年的 LLM 应用开发亦是如此。

写作时间：2026 年 7 月
主要参考：LangChain 官方文档、LangGraph 官方文档、Zilliz 技术博客、Atlan AI Agent Memory Guide、DigitalApplied 对比分析、掘金技术社区 Multi-Agent 框架横评
风格：深度技术对比

AI #LangChain #LangGraph #Agent #LLM #框架对比