本章建立对 LangGraph 的整体认知:它为什么从 LangChain 的链演化而来,核心抽象是什么,又能解决哪些链解决不了的问题。我们先从一个反问切入——当业务流程需要回头反思时,单向链为什么失效。读完后你应能向同事讲清「为什么这张图值得画」,而不只是会调 API。
说清图式编排与线性链的本质区别
解释状态、节点、边三个原语的职责
能列举至少三类适合 LangGraph 的场景
独立完成一个最小可运行图

链是单向轨道,图是带环岛与立交的路网,回路靠回边而非递归。
归约器决定节点返回值如何并入全局状态,累加或覆盖要想清。
适合图的四类特征:循环、长上下文、人工节点、多角色协作。
图的收益是把流程正确性从 prompt 挪到代码与图结构。
1.1 LangGraph 的诞生与核心理念
1.2 相较于 LangChain 的演进与优势
1.3 核心概念:图、节点、边与状态
1.4 典型应用场景与价值主张
本章是后续六章的地基。状态与节点的定义方式直接决定第三章如何建图,而持久化概念的伏笔在第四章展开。理解「为什么有环」比记住 API 更重要。
前置:具备 Python 与基础大模型调用经验即可。延伸:第二章拆解运行时,第三章落地代码。
建议先合上文档自己画一张「写作-自评-改写」的环,再回来对照 1.1 的代码;卡住的地方恰恰是要重点理解的概念。
| 节 | 讲什么 | 最易踩的坑 |
|---|---|---|
| 1.1 诞生与核心理念 | 为什么从链演化、三原语 | 把链当作图的子集,忽略有环的语义差异 |
| 1.2 相较于 LangChain 的演进 | 链与图的取舍、迁移路径 | 以为图一定比链好,轻任务也硬套图 |
| 1.3 核心概念:图、节点、边与状态 | 原语定义、归约器、端点 | 返回 key 与状态通道名不一致,状态静默丢失 |
| 1.4 典型应用场景与价值主张 | 四类场景、打分选型 | 只看「模型能不能做」,忽略控制流复杂度 |
图是节点与边的集合,语言用来表达「流程的正确性」。它把控制流从 prompt 里搬进代码结构,模型只负责生成与判断。节点是接收状态、返回增量的函数,是图里唯一能产生副作用的地方,建议把副作用收口到少数节点。边分普通边与条件边,普通边表达固定顺序,条件边按状态路由,这是图能表达分支与循环的关键。状态是跨节点共享、按通道归约的数据,每次运行(thread)独立,是检查点持久化的对象。
四条主线在第一章就位后,后续每一章都是对某一主线的深化:第二章讲运行时,第三章讲建图,第四章讲状态持久化。
Q:链和图的区别,一句话怎么讲?
A:链是单向管道,数据只能从头流到尾;图是有回边与分支的路网,能表达循环和动态跳转。需要「回头看、反复改」的任务用图,纯单向的任务用链更轻。
Q:为什么说返回增量而不是全量?
A:全量返回会在并行节点同时写状态时互相覆盖。增量加归约器(累加、消息合并、覆盖)让合并规则集中在一处,每个节点只声明自己改了什么,并行安全才可控。
Q:什么时候该认真上图?
A:数任务里「要不要再走一步」的判定点。循环、长上下文、人工介入、多角色这四类特征命中越多越该用图;两个判定点以内,链往往更合适。
第一章的选型结论直接决定后面要不要继续学:确认自己手里是「判定点多、需要留痕」的任务,再投入第二至六章。如果评估下来只是单次摘要或固定问答,把这一章的三原语记住即可,暂时不必往下深入——避免用图的复杂度去解决链能解决的问题。