LangGraph 到底有啥用？和 Claude Code、扣子放一起聊聊它的存在意义

用户90496529961
0 阅读10分钟

最近在想一个问题：我已经有 Claude Code 这种超强智能体，也有扣子这种零门槛可视化平台，夹在中间的 LangGraph 到底解决什么问题？

这篇文章不教你怎么用 LangGraph，而是帮你想清楚它的定位——它是什么、不是什么、什么时候该用、什么时候不该用。

一、先把三者分清楚

Claude Code —— 一个训练好的"智能体"

它的核心是四件事：循环机制（LLM 输出 → 工具调用 → 结果回写 → 再决策）、工具渐进式披露（不一次塞几百个工具，按需加载）、记忆系统（session/memory/rules 多层）、上下文管理（压缩、子 agent 隔离等）。

本质：一个超强 Agent 自己规划、自己执行、自己判断。你给它一个模糊的目标，它自己想办法搞定。

扣子（Coze）—— 托管的可视化工作流平台

拖拽节点、连线成流、平台托管、零代码。本质：让非技术人员也能搭 AI 工作流。产品经理、运营、客服都能用。

LangGraph —— 给开发者的工作流编排框架

用 Python 代码定义 Graph，内置状态管理、断点恢复、人工介入。本质：把 LLM 调用工程化嵌进业务系统的底层脚手架。

二、最根本的区别：智能体 vs 工作流

这是理解三者的关键。

Claude Code 的 Agent：
  有自主决策能力，LLM 自己决定下一步做什么

LangGraph / 扣子 里的"Agent"：
  本质 = 一段 system prompt + 一次 API 调用
  下一步走哪是"代码"或"画布"决定的，不是 LLM 决定的

说人话：Claude Code 像"一个全能员工"，LangGraph/扣子像"一条流水线 + 若干工位"。前者靠人的智力，后者靠流程的设计。

所以当你看到 LangGraph 文档里的"Agent"、CrewAI 里的"Agent"，不要把它理解成 Claude Code 那种智能体——它就是一个带着特定 prompt 的 API 调用而已。所谓"编排"就是用代码控制这些 API 调用的顺序、传参、条件分支。

三、LangGraph 的核心功能清单

LangGraph 帮你省了什么"从零开始"的活：

核心功能解决的问题
StateGraph声明式定义流程图，可视化、可观测
State（共享状态）节点间数据传递 + 增量更新
Checkpointer状态持久化，跑到一半挂了可以从断点恢复
Interrupt人工介入（Human-in-the-loop）的完整机制
Conditional Edges基于 LLM 输出动态决定下一步走哪
Streaming实时看到每个节点的中间输出
Time Travel回到历史某一步重新跑
Subgraph子流程封装、嵌套

最值钱的三个：

  1. 状态持久化 —— 工作流跑到第 20 步挂了，下次从第 20 步接着跑
  2. 人工介入 —— 流程中暂停 → 等审批 → 继续，这是 LangGraph 的灵魂功能
  3. 声明式流程图 —— 把 if/else/while 变成可视化、可 replay 的元数据

四、一个最小例子：带条件分支的问答

场景：判断用户问题是技术问题还是闲聊，走不同分支回答。

from typing import TypedDict, Literal
from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o-mini")

# 1. 定义共享状态（贯穿整个流程的"公共黑板"）
class State(TypedDict):
    question: str
    category: str
    answer: str

# 2. 定义节点
def classify(state: State):
    resp = llm.invoke(f"这个问题是 'tech' 还是 'chat'？只返回一个词：{state['question']}")
    return {"category": resp.content.strip().lower()}

def answer_tech(state: State):
    return {"answer": llm.invoke(f"用技术专家口吻回答：{state['question']}").content}

def answer_chat(state: State):
    return {"answer": llm.invoke(f"用朋友聊天口吻回答：{state['question']}").content}

# 3. 路由函数
def route(state: State) -> Literal["tech", "chat"]:
    return "tech" if state["category"] == "tech" else "chat"

# 4. 构建图
graph = StateGraph(State)
graph.add_node("classify", classify)
graph.add_node("answer_tech", answer_tech)
graph.add_node("answer_chat", answer_chat)
graph.set_entry_point("classify")
graph.add_conditional_edges("classify", route,
                             {"tech": "answer_tech", "chat": "answer_chat"})
graph.add_edge("answer_tech", END)
graph.add_edge("answer_chat", END)

app = graph.compile()
print(app.invoke({"question": "Python 的 GIL 是什么？"})["answer"])

不用 LangGraph 的等价代码：

def run(question):
    category = llm.invoke(f"判断：{question}").content.strip().lower()
    if category == "tech":
        return llm.invoke(f"技术口吻：{question}").content
    return llm.invoke(f"聊天口吻：{question}").content

8 行 vs 40 行。对这个简单例子来说，直接写代码完胜。

那 LangGraph 的价值什么时候显现？ 当你的流程满足以下任一条件：节点 >10、需要循环重试、需要中间状态持久化、需要人工介入、需要可视化追踪。这时候那些"多余的代码"就变成省事的了。

五、LangGraph 的灵魂：图编排 + 时间维度

不仅是"图"，更关键的是"时间"

网上大多数对比文章只说到"LangGraph 用图来编排"。但真正的本质差别是时间维度：

CrewAI 的世界观：
  只有"空间维度" —— 谁和谁是什么关系
  流程 = 一次性跑通的数据管道
  Task A output → Task B input → Task C input
  每个 Task 跑完数据就"扔掉"了

LangGraph 的世界观：
  空间维度（节点/边）+ 时间维度（State 的演化历史）
  State 是贯穿整个流程的"公共对象"
  每个节点读它、改它、写回去
  整个执行过程 = State 的演化史

一个类比：

CrewAI 像工厂流水线：
  一个零件从工位1传到工位2传到工位3
  每个工位只看到眼前的零件

LangGraph 像游戏存档：
  整个世界的快照
  随时可以读取、修改、回滚、恢复

时间维度解锁了 CrewAI 做不到的四件事

1. 暂停与恢复（跨越真实时间的状态）

上午 9 点：流程跑到第 5 步，State 保存到 Redis，程序退出
上午 11 点：程序重启，从 Redis 加载 State，从第 6 步继续

2. 时间旅行（回到历史的某个状态）

跑到第 10 步发现第 5 步的决策错了
→ 回退到第 5 步的 State 快照 → 换个决策重跑

3. 循环中的状态累积

"写作→审核→不通过→改写→再审核→..."
每一轮的 feedback 都在 State 里累积，完整保留修改历史

4. 人工介入（时间上的空档）

流程跑到审批节点 → interrupt → State 冻结
等 3 天后人工批准 → State 解冻 → 继续

CrewAI 做不到这些，不是因为它设计得不好，而是因为它根本没有"State 这个对象"这个概念。Task 的 output 是瞬时数据，没人管它持久化、没人管它跨越时间。

更本质的定位

无状态流水线（Stateless Pipeline）
  → CrewAI、普通的 Python 脚本、老版 Airflow
  → 关心的是"数据从 A 流向 B"

有状态机（Stateful State Machine）
  → LangGraph、Temporal、AWS Step Functions
  → 关心的是"State 如何从 S1 演化到 S2 再到 S3"

LangGraph 的真正血统不是"AI Agent 框架"，而是"状态机 + LLM"。它的设计灵感来自 Temporal 这种经典有状态工作流引擎，只是把"节点里的处理逻辑"换成了 LLM 调用。

这也解释了为什么 LangGraph 感觉"复杂"——因为状态机本身就比流水线复杂。你付出这个复杂度，换来的就是对时间维度的完整掌控力。

六、LangGraph vs CrewAI 实战对比

维度CrewAILangGraph
抽象模型Agent + Task + CrewGraph + State + Node
表达力角色化协作为主任意拓扑（含循环）
循环与重试弱，需要 hack原生支持
条件分支通过 Task 依赖模拟conditional_edges 显式
状态管理任务间传递 output显式 State 对象
断点恢复无Checkpointer 原生支持
人工介入有限Interrupt 原生支持
可视化打印日志可导出 Mermaid 图
上手门槛低（5 分钟跑 demo）中（需理解图的思维）
生产就绪度一般高

CrewAI 的优势：上手快、角色化隐喻符合人的直觉。写三个 Agent 三个 Task，5 分钟搞出一个"研究员→作者→审稿人"的 demo。但流程一复杂（比如审稿人要求作者改、改完再审、反复三次）就开始别扭。

LangGraph 的优势：循环/反思/条件分支天然表达、显式 State、生产级持久化、完整的人工介入机制。

七、LangGraph vs 扣子：同为工作流，差别在哪

扣子（Coze）LangGraph
形态SaaS 平台 + 可视化画布Python 代码库
使用方式拖拽节点、连线写代码定义 Graph
上手门槛几乎为零需要 Python + LLM 基础
部署平台托管自己部署
数据归属走字节服务器完全自主可控
模型选择主推豆包任意 LLM
定制能力受限于平台节点无限制
集成到产品通过 Bot/API 暴露直接作为库嵌入后端
商业风险平台政策、定价变化开源库，自主可控

扣子 ≈ LangGraph 的"托管可视化版"，用牺牲灵活性换来了零门槛。

八、LangGraph 的存在意义（本文核心）

它不是来抢 Claude Code 生意的

Claude Code：解决"模型能多聪明地自主完成任务"
LangGraph： 解决"如何把 LLM 调用工程化嵌进业务系统"

两者是互补，不是竞争。你用一个 API key + LangGraph 搭不出 Claude Code——因为 Claude Code 的核心壁垒在模型训练质量 + 产品级的工具调教 + 上下文管理的经验，这些都不是框架能给你的。

它和扣子的真正差异不在"代码 vs 拖拽"

真正的差异是控制力、可定制性、数据归属、商业可控性。

LangGraph 不可替代的四个场景

  1. 数据合规 —— 金融、医疗、政企，数据必须留在内网
  2. 深度系统集成 —— 需要和 ERP、CRM、私有数据库、k8s 打通
  3. 构建 AI SaaS 产品 —— 用户进的是你的产品，不是扣子
  4. 极致的灵活性和成本控制 —— 平台节点表达不了的逻辑、只付 LLM API 钱

一个更本质的定位

LangGraph 的核心不是 AI 自主性，而是"把流程固化下来 + 对时间维度的掌控"。

固化的方式有两种：写代码（LangGraph）或拖拽（扣子）。 Claude Code 根本不在这个赛道，它是智能体，不是工作流。

九、选型决策树

你的需求是什么？
│
├── "我自己用，想让 AI 帮我搞定复杂的一次性任务"
│      → Claude Code
│
├── "我要搭一个对外的 Bot / 客服 / 内容生成流水线"
│      │
│      ├── 不会写代码 / 想最快上线 / 数据不敏感
│      │     → 扣子 / Dify
│      │
│      └── 会写代码 / 要嵌入自己的产品 / 数据要自主可控
│            │
│            ├── 简单线性流程
│            │     → 直接写 Python + API，或 CrewAI
│            │
│            └── 需要循环/状态持久化/人工介入
│                  → LangGraph
│
└── "流程很固定，不需要 AI 自主性"
       → 直接写代码，不用任何框架

十、写在最后

Claude Code、LangGraph、扣子，三者不是"谁更好"，而是"谁更适合你的场景"：

  • 个人开发者做一次性复杂任务 → Claude Code 天下无敌
  • 非技术人员快速出活 → 扣子更香
  • 开发者做产品嵌入，要控制力和时间维度 → LangGraph 有它不可替代的位置
  • 流程简单能自己写代码 → 真不需要任何框架

别用智能体的标准去评工作流框架，也别用工作流的标准去评智能体，它们根本不在一个维度上。

LangGraph 的价值也不在于它"能做 AI Agent"——做 Agent Claude Code 做得比它好。它的价值在于：它是一个把 LLM 嵌进状态机的引擎，让你能对流程的空间结构和时间演化同时拥有完整的掌控力。

理解了这一点，你就知道什么时候该用它，什么时候不该用它了。

avatar
文章
阅读
粉丝