LangGraph 是什么：把 AI 应用从「一次性函数调用」变成「持续运行的系统」

读完本文你会理解：为什么单个大模型撑不起复杂任务、LangGraph 用「图」建模 AI 流程的三要素是什么、它和 LangChain 是什么关系，以及它的五大核心能力各自解决什么问题。

一个上线即翻车的场景

设想你给团队做了一个 AI 调研助手：输入一个主题，它自动拆解问题、查资料、校验事实、输出报告。本地跑得很顺，上线第三天，用户投诉来了——

报告生成到一半，服务进程因为一次 OOM 重启了。用户重新提交主题，助手从头开始查资料，之前二十分钟的成果全部作废。

模型没问题，代码逻辑也没问题，问题出在编排方式：传统写法把 AI 应用当成一个函数——输入进去、输出出来，中间状态用完即弃。函数一挂，什么都留不下来。

LangGraph 要解决的就是这一类问题。

一、单智能体的天花板：全能选手为什么做不好复杂任务

把一个大模型当成"全能选手"，让它既查资料、又写报告、还做事实核查，听起来省事，实际效果很尴尬：它每样都能做一点，但每样都不精。

更麻烦的是三个固有缺陷：

• 长链路里容易丢东西：任务超过十几步之后，早期的上下文被挤出注意力窗口，模型开始"断片"；
• 单一视角容易一错到底：没有第二双眼睛检查它的产出，幻觉会沿着流程一路放大；
• 职责混在一起没法定位问题：报告写得差，你分不清是检索环节没做好，还是写作环节没做好。

于是业界转向了一个朴素的思路：让专业的人干专业的事。多智能体系统就是给 AI 组建一个"专业团队"——研究员负责找资料、核查员负责挑毛病、写作助手负责成稿、编辑负责润色。每个智能体只干自己最擅长的一件事，出错面小、容易调试、方便替换。

打个比方：单个大模型像一位独奏者，什么乐器都摸过，但没有一样精到能开专场；多智能体系统像一支乐团，小提琴、大提琴、管乐各司其职，合在一起才能演完一部完整的作品。

但乐团还需要一样东西——总谱和指挥。谁先演奏、谁后进、声部之间怎么衔接、哪里反复、哪里休止，这些调度问题，正是编排框架要解决的。这就是 LangGraph 的位置。

二、LangGraph 是什么：一句话和一张图

LangGraph 是 LangChain 团队推出的开源编排框架，官方定位很直接：

LangGraph is a low-level orchestration framework for building, managing, and deploying long-running, stateful agents.

拆开理解这句话：

• low-level（低层）：它不替你封装业务细节，而是把底层控制权交给你，像搭积木一样组装 AI 系统；
• long-running（长时运行）：面向的不是"问一句答一句"的调用，而是持续数分钟甚至数小时的任务；
• stateful（有状态）：每一步的中间结果都被显式保存，中断之后可以接着跑，而不是从头再来。

它的核心思想用一句话概括：用"图"来建模 AI 行为——节点是动作，边是跳转逻辑，状态是记忆。

一张典型的 LangGraph 图长这样（A → B → END 的最小示例）：

from langgraph.graph import StateGraph, END

graph = StateGraph(dict)

def node_a(state):
    return {"value": "from A"}

def node_b(state):
    return {"value": "from B"}

graph.add_node("A", node_a)
graph.add_node("B", node_b)
graph.set_entry_point("A")
graph.add_edge("A", "B")
graph.add_edge("B", END)

app = graph.compile()

这张图表达了：流程从 START 出发 → 执行节点 A 并把它返回的 {"value": "from A"} 合并进状态 → 按边进入节点 B → 再合并 {"value": "from B"} → 到达 END 结束。

三、图的三要素：节点、边、状态

LangGraph 的一切能力都建立在三个基本元素上。我用一个"快递分拣中心"的类比来理解它们：

要素	在 LangGraph 里是什么	一句话职责	分拣中心里的对应物
节点（Node）	一个可调用的函数或对象	执行一个独立动作：调大模型、查数据库、跑工具	一个分拣工位，只干自己那道工序
边（Edge）	一个路由函数，读状态决定下一步去哪	控制流程走向，支持固定跳转、条件分支、循环回退	工位之间的传送带，带道岔可以分流
状态（State）	全局共享的数据结构	记录所有关键信息，是所有节点的公共上下文	贴在包裹上的快递单，每个工位都能读、都能改

三者配合产生了一个关键性质：执行路径不再由代码的嵌套结构决定，而是由图结构决定。你想加一步、改一个分支、让某个环节失败时重试，都是改图，而不是推翻重写业务代码。

四、LangChain 与 LangGraph：不是替代，是升级

一个高频问题：既然都是 LangChain 团队的产品，二者什么关系？

答案是：LangGraph 不取代 LangChain，而是补上了 LangChain 缺的那块——流程控制。LangChain 的 Chain 适合把几个步骤串成一条直线；LangGraph 适合把流程画成一张可以拐弯、可以回头的图。

维度	LangChain Chain	LangGraph
执行形态	单向直线，进料出成品	有向图，支持分支、循环、并行
记忆方式	本轮调用内的局部传递	显式全局状态，可持久化到存储
中断恢复	无，挂了从头再来	检查点续跑，断电不丢进度
人工介入	无内置机制	可在流程中途暂停等待人类确认
适合的任务	单次加工：查询 + 生成	长流程、多轮决策、多智能体协作

一句话总结：Chain 是单行道，图是导航地图——单行道只能往前，地图可以随时决定"接下来去哪"。

五、五大核心能力

LangGraph 的能力可以归纳为五项，每一项都对应一个真实的生产痛点：

1. 持久执行（Durable Execution）

每一步状态都落盘。服务崩了，重启之后从最近的检查点接着跑。这对"调研 + 写报告"这类小时级任务不是加分项，是及格线。

2. 人机协同（Human-in-the-loop）

模型拿不准的时候，可以让人类介入：审阅当前状态、修正参数、点击确认，流程再继续。审批流、高危操作（转账、发布）天然需要这种"人在回路"的兜底。

3. 分层记忆（Comprehensive Memory）

同时管理短期记忆（本次会话的状态）和长期记忆（跨会话的历史，配合向量库或数据库）。AI 不仅能"接话"，还能"认人"。

4. 可调试（Debugging）

配合 LangSmith 生成可视化轨迹：每一步走到了哪个节点、状态变成了什么样，一目了然，不用靠打日志猜迷宫。

5. 工具集成与多智能体（Tools & Multi-Agent）

查天气、订机票、写报告，接 API 即可；同时天生支持多个 AI 分工协同——一个分析、一个决策、一个汇报。

六、多智能体：从独奏到乐团

把第一节的"分工协作"落到 LangGraph 上，就是一张多智能体的图——每个智能体是一个节点，边定义它们的协作顺序：

每个节点内部可以是一个独立的模型调用甚至一张子图，而整条链路由 LangGraph 统一调度。哪个智能体质量不行，单独换掉即可——这就是"专业团队"在工程上的意义。

小结

LangGraph 的本质是一个带记忆的、图结构的 AI 任务执行器。它的设计哲学是：

把 AI 应用当成一个永远在线的"活系统"，而不是一次性的函数调用。

记住三要素——节点干活、边定路线、状态存记忆——你就抓住了整个框架的骨架。下一篇，我们用一个有记忆的聊天机器人，把这三要素变成可运行的代码。