LangGraph：一张图的样貌
目录
在LLM应用早期，Agent=Prompt+循环。
随着任务复杂度上升，这种方式很快暴露出问题：不可控、不可调试、不可复用。
LangGraph的出现，并不是为了“换一种写法”，而是
从底层抽象上，重构了LLM工作流的组织方式。
本文将从设计动机 → 抽象模型 → 图构建原理三个层面，系统讲清楚：
LangGraph的图到底是什么，以及为什么必须这样构建。
LangGraph要解决的根本问题
LLM是无状态的，但真实任务是有状态的
LLM的计算模型是：
Input → Output
而真实任务是：
输入
↓
中间推理
↓
工具调用
↓
结果判断
↓
是否继续？
如果把这些都塞进Prompt，就会导致：
- Prompt无限膨胀
- 状态不可持久化
- 无法中断 / 回放 / 调试
LangGraph的第一性原则：状态必须存在于LLM之外
Agent的行为本质不是线性的
传统Pipeline假设：
A → B → C → END
而Agent的真实形态是：
- 判断
- 分支
- 回环
- 不确定何时结束
例如ReAct：
Thought → Action → Observation
↖───────────────┘
这是一个循环图，而不是线性流程。
控制逻辑不能藏在Prompt里
Prompt内部的控制逻辑有致命问题：
- 不可视化
- 不可审计
- 不可复用
- 不可外部干预
LangGraph的核心立场是：控制流属于系统，而不是模型
LangGraph的核心抽象
LangGraph并没有引入复杂的新概念，它只做了三件事的明确分离：
| 抽象 | 含义 |
|---|---|
| State | 系统的真实状态 |
| Node | 对状态的纯计算 |
| Edge | 状态驱动的执行路径 |
为什么State是LangGraph的核心
State是唯一的真相源
在LangGraph中：
- Prompt只是State的一种投影
- 工具结果写回State
- 是否结束由State决定
一个典型State结构：
State = {
"messages": [],
"tool_results": [],
"step": 0,
"done": False
}
这意味着：
- 状态可序列化
- 状态可持久化
- 状态可回放
系统的行为可以被完整复现。
Node 只能返回“状态增量”
LangGraph要求：
node(state) → partial_state_update禁止在Node中直接修改State，否则会破坏可回放性与确定性。
这样设计是为了：
- 可预测性（相同State→ 相同结果）
- 支持中断恢复
- 支持未来分布式执行
从抽象上看：
- Node≈纯函数
- State≈上下文快照
Graph为什么一定要是显式图
Edge本质是状态转移规则
LangGraph中有两类边：
普通边（确定执行）
A → B
表示逻辑与状态无关，执行路径是确定的。
条件边（状态驱动）
A → (条件判断) → B / C / END
判断函数本质是：
State → NextNode
这在抽象层面等价于有限状态机（FSM）。
LangGraph是数据驱动的状态机
对照来看：
| 状态机 | LangGraph |
|---|---|
| 状态 | State |
| 动作 | Node |
| 转移条件 | Conditional Edge |
| 终止态 | END |
LangGraph≠简单流程图，而是结构化状态机。
为什么必须Compile
在构建Graph后，必须调用Compile：
graph = builder.compile()
这一步完成了：
- 拓扑合法性校验
- 路径完整性校验
- 从“描述”到“可执行体”的转换
没有Compile，Graph只是配置，不是系统。
为什么END是显式的
LangGraph不允许“自然结束”。
原因只有一个：Agent不能靠“我觉得差不多了”来结束。
显式END带来的能力包括：
- 可控终止
- 可审计
- 可与UI/调度系统同步
从ReAct反推：Agent天然是Graph
经典Agent循环：
Thought → Action → Observation → 判断是否完成
拆解后可以发现：
- 每一步都在修改State
- 是否继续由State决定
- 行为存在回环
这本质上就是一个图结构。
总结
LangGraph不是让模型更聪明，而是让系统更理性。
-
State把“记忆”从Prompt中解放出来
-
Graph把“流程”从模型中解耦出来
-
Agent从黑盒，变成可控的状态机
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
6
0- 0
已为社区贡献2条内容
所有评论(0)