什么时候才上 LangGraph：需要显式状态/检查点/复杂图的时候

你跑通了第一个 Agent，给它加了工具、加了记忆，甚至让它调起子代理分工干活。然后你刷到一堆文章说"生产级 Agent 都得上 LangGraph"，于是你打开文档，看到一堆 StateGraph、add_node、add_edge、checkpointer，心里一沉：我现在这个跑得好好的东西，是不是必须推倒重来塞进这个框架？

先把结论给你：大概率不用。 这一节讲清一件事——什么信号出现时才真的该上 LangGraph，以及在那之前，为什么"裸 SDK + 子代理"才是你的默认选项。读完你能用一份决策清单，对着自己的项目给出明确的"上"或"不上"，而不是被氛围裹挟。

这篇适合谁：已经能写出能跑的 Agent、正纠结要不要引入编排框架的人。

---

先继承一条铁律：延迟框架

写 Agent 有条朴素但被反复验证的原则：延迟引入框架（defer the framework）。意思是——能用基础能力解决的，就先别套框架；框架带来的抽象、样板代码和心智负担，要等到"不上它真的疼"的时候再付。

这条原则在编排这一层同样成立。多数人以为"多步、多 Agent"就必须上编排框架，其实绝大多数活，裸着 SDK + 子代理就够了：

• 你用 Claude Agent SDK 起一个主 Agent，给它一组工具。
• 任务复杂了，就让它调起几个子代理（subagent）分别干"查资料""写代码""审稿"。
• 主 Agent 在一个循环里推进，看子代理的返回决定下一步。

这套东西已经能覆盖一大半场景。它没有"图"、没有"状态机"，但它简单、好调、出了问题一眼能看到哪步炸了。在你没遇到下面那些具体信号之前，引入 LangGraph 往往是用复杂度换一个你还用不上的能力。

一句话：编排框架不是"做大就要上"的勋章，而是"特定痛点出现才付"的工具。

---

那到底什么时候该上？认准这 5 个信号

LangGraph 解决的不是"多步"——多步裸循环也能干。它解决的是循环里那些你自己手搓会很痛的硬需求。出现下面任何一个，才是它该登场的时候：

1. 需要显式的共享状态。多个 Agent / 节点要读写同一份结构化状态（不是各自把上下文塞进 prompt 里传），你希望状态是一个有 schema 的对象、每步对它做受控更新。手搓时这块最容易乱。
2. 需要 durable 检查点（checkpoint）。任务跑到一半，进程崩了、机器重启了、API 超时了，你希望它能从断点恢复而不是从头再来。这对长任务、贵任务（每步都烧 token）是刚需。
3. 需要 human-in-the-loop 审批。流程跑到某一步要停下来等人点确认（比如"这封邮件要不要发""这笔退款批不批"），人批了再继续。要可靠地"挂起—等人—恢复"，自己实现很容易出错。
4. 需要可恢复执行 / 时间旅行。你想能回到某个历史状态重跑、想审计每一步状态怎么变的、想在出问题时回放。这是状态机才好给的能力。
5. 需要复杂的分支拓扑。不是简单的 A→B→C，而是有条件分支、循环回退、并行扇出再汇聚（fan-out / fan-in）、动态决定下一个节点。拓扑一复杂，裸代码的 if/else 就开始变成意大利面。

反过来记更省事：如果你的活就是"一个主 Agent 拉几个子代理、顺着把任务做完、崩了大不了重跑"——这五条一条都没踩到，那就别上，继续裸 SDK。

---

LangGraph 的正确心智模型

很多人上手 LangGraph 痛苦，是因为脑子里装错了模型——以为它是"帮我把 Agent 循环包一层的库"。不是。它是一个工作流 / 状态机引擎，你得用工作流引擎的方式去想它。三个核心概念：

概念	是什么	类比
节点（node）	一个干活的单元：一个 Agent、一次工具调用、一段处理逻辑	流程图里的一个"框"
边（edge）	控制流：这个节点干完去哪。可以是固定的，也可以是条件边（按状态决定走哪条）	框之间的"箭头"
状态（state）	一个有类型的字典（typed dict），所有节点读写的共享数据。每个节点返回对状态的更新	在流程里一路传下去的"公文包"

抓住这句话你就懂它了：节点干活、边决定流向、状态贯穿全程，整张图就是一台显式的状态机。 它和"包个循环"的本质差别在于——循环是隐式的、藏在代码控制流里的；而图是显式的、可声明、可序列化、可在任意一步存档恢复的。检查点能做、human-in-loop 能做、时间旅行能做，全都因为状态被显式管理了。

代价也来自这里：你要先把流程画成图（定义状态 schema、注册节点、连边），样板代码比裸写多不少，学习曲线也更陡。这就是为什么它不该当入门首选——它给的控制力，你得用前期的复杂度去换。

---

最小可读的图骨架

下面是一段最小可读的 LangGraph 风格骨架，帮你建立画面感。重点看结构（状态 / 节点 / 边怎么拼），具体 API 名以官方文档为准——框架在演进，方法签名可能和你装到的版本略有出入。

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

# 1) 状态：一个有 schema 的 typed dict，所有节点共享读写
class State(TypedDict):
    topic: str
    draft: str
    approved: bool

# 2) 节点：每个就是个普通函数，吃 state、返回对 state 的"更新"
def research_node(state: State) -> dict:
    # 这里通常调一个 Agent 去查资料；演示先写死
    return {"draft": f"关于「{state['topic']}」的初稿……"}

def review_node(state: State) -> dict:
    # 审稿节点：判断初稿够不够好
    ok = len(state["draft"]) > 10
    return {"approved": ok}

# 3) 条件边：按状态决定下一个节点（这就是"复杂分支拓扑"的来源）
def route_after_review(state: State) -> Literal["research", "done"]:
    return "done" if state["approved"] else "research"  # 没过就回去重写

# 4) 把图拼起来
graph = StateGraph(State)
graph.add_node("research", research_node)
graph.add_node("review", review_node)
graph.add_edge(START, "research")          # 入口 → research
graph.add_edge("research", "review")        # research → review
graph.add_conditional_edges(                # review → 按状态分流
    "review", route_after_review,
    {"research": "research", "done": END},
)

app = graph.compile()  # 想要 durable 检查点：compile(checkpointer=...) —— 具体以官方为准
result = app.invoke({"topic": "Agent 编排", "draft": "", "approved": False})
print(result)

逐步预期：调 invoke 后，流程从 START 进 research（写初稿）→ 进 review（判断够不够好）→ 条件边看 approved：不够好就回 research 重写，够好就到 END 收工。你能清楚看到——状态在节点间流动，边在决定走向，整张图是声明出来的而不是埋在 while 里的。把 compile 加上 checkpointer，这台状态机就能在任意节点存档、崩了从断点恢复，这正是裸循环给不了的。

---

一段必须说清的风险提示：CrewAI 这类角色制框架

你搜"多 Agent 框架"时一定会撞到 CrewAI 这类**角色制（role-based）**框架。它的卖点很迷人：你只要声明几个"角色"——researcher / writer / reviewer，给每个角色写 role（身份）、goal（目标）、backstory（背景设定），它就帮你把协作跑起来。做快速原型，它确实是上手最快的那个。

但你要清醒地知道它的代价，别脑子一热当主力：

• token 开销最高。每次调用，它都会把角色的 role / goal / backstory 重新塞进上下文。角色越多、轮次越多，这部分固定开销越滚越大——实测可达 LangGraph 的约 3 倍。任务一上规模，账单很难看。
• 控制力弱。角色制把"怎么协作"抽象掉了，方便是方便，但当你需要显式状态、检查点、精细分支时，它给不了——而这些恰恰是你做大之后最需要的。
• 团队做大常要迁走。很多团队的路径是：CrewAI 飞快搭出原型验证想法 → 上量后被 token 成本和控制力卡住 → 迁到 LangGraph 或裸 SDK。

所以给它一个准确的定位：CrewAI 适合快速原型，不值得当主力。 用它三两下验证"这个多 Agent 协作想法行不行"很香；一旦要进生产、要可控、要算账，就该换骨架。

---

增量一：上框架前的 3 个必答问题

别凭感觉决定。引入 LangGraph（或任何编排框架）前，逼自己回答这三个问题，全是"否"就别上：

1. 崩了要不要从断点恢复？ —— 否：不需要 checkpoint，裸循环重跑就行，少一大块复杂度。
2. 流程中间要不要停下来等人审批？ —— 否：不需要 human-in-loop 的挂起恢复机制，普通函数返回就够。
3. 拓扑是不是真的复杂（条件分支 + 回环 + 并行汇聚）？ —— 否：就是顺序几步，if/else 加循环裸写更清楚。

只要有一个"是"，LangGraph 开始值得；全是"否"，恭喜你，继续享受裸 SDK 的简单。把这三问贴在工位上，能挡掉一大半"为上而上"的过度设计。

---

增量二：LangGraph vs 裸 SDK 取舍表

维度	裸 SDK + 子代理	LangGraph
上手成本	低，没有额外抽象	高，要先学图/状态/边的模型
样板代码	少	多（定义 state、注册节点、连边）
控制力	够用，但状态/分支靠自己管	最强，状态/拓扑/恢复全显式
共享状态	手动传，复杂时易乱	有 schema 的 typed state，受控更新
崩溃恢复	没有，得自己实现或重跑	内建 checkpoint，断点恢复
human-in-loop	自己实现挂起/恢复，易出错	一等公民，机制成熟
复杂拓扑	if/else 易变面条	声明式条件边/并行/回环，清楚
适合场景	多数活、原型、流程简单可重跑	需要显式状态/检查点/审批/复杂图的生产编排

怎么用这张表：从左列默认起步，每往右走一格都得有具体理由（对应上面 5 个信号 / 3 个问题）。没有理由就待在左列——这是省钱又省心的姿势。

---

故障与避坑表

坑	表现	怎么破
为上而上，简单流程也套 LangGraph	样板代码淹没业务逻辑，开发变慢	过"3 个必答问题"，全否就回裸 SDK
把 LangGraph 当"循环包装器"	用着别扭、处处不顺	换心智模型：它是状态机引擎，先把流程画成图
状态 schema 设计太随意	节点间字段对不上、更新互相覆盖	先想清 state 里有哪些字段、谁写谁读，再写节点
拿 CrewAI 当生产主力	token 账单暴涨（可达 ~3 倍）、要可控时使不上劲	只拿它做快速原型，上量迁到 LangGraph/裸 SDK
上了 LangGraph 却不用 checkpoint	付了复杂度成本，却没拿到恢复能力	要么用上 checkpointer 这些核心能力，要么干脆别上
一上来就追求"复杂多 Agent 拓扑"	调试地狱，问题定位极难	从最小图起步，跑通两三个节点再加分支

---

动手挑战

1. 拿你手上一个真实 Agent 任务，过一遍"3 个必答问题"，写下每问的答案和理由，给出明确的"上/不上"结论——并说清判断依据是哪个信号。
2. 把上面那段图骨架跑起来（先用写死的节点），观察 route_after_review 怎么在 approved=False 时把流程拉回 research。然后把 review_node 的判断改严一点，看它多绕几圈。
3. 进阶：给 compile 接上一个 checkpointer（具体配置以官方文档为准），故意在中途中断再恢复，亲眼确认它从断点继续而不是从头跑。
4. 思辨：找一篇鼓吹"CrewAI 几行搞定多 Agent"的文章，对照本文的 token 开销与控制力分析，判断它适不适合那篇文章描述的场景。

---

小结 · 你现在掌握了什么

• 你把"延迟框架"原则用到了编排层：多数活裸 SDK + 子代理就够，框架等痛点出现再付。
• 你记住了真正该上 LangGraph 的 5 个信号：显式共享状态、durable 检查点、human-in-loop 审批、可恢复执行、复杂分支拓扑。
• 你建立了正确心智模型：节点干活、边定流向、状态贯穿全程，它是工作流引擎不是"包个循环"。
• 你拿到了"3 个必答问题"决策清单和取舍表，能对项目给出明确的上/不上判断。
• 你看清了 CrewAI 的定位：快速原型最快，但 token 开销可达 ~3 倍、控制力弱，不值得当主力。

LangGraph 是好东西，但它的价值是"控制力"，代价是"复杂度"。别在你还用不上控制力的时候，先付了复杂度的账。

下一步：如果你判断确实该上图，看下一节最佳组合：LangGraph 当骨架 + Claude Agent SDK 在节点里干重活——把图的可控和 SDK 的执行力各取所长。想看整条阶梯就对照三支柱路线图。

👉 看看 AI 数字员工落地指南，或了解 数字员工搭建实战课。需要为企业落地方案，欢迎找我们聊 企业服务。