LangGraph 状态图执行模型：State Channel、节点调度与条件分支

还记不记得咱们在第 04 小节看 createAgent() 源码时，遇到过下面这行代码：

new StateGraph(...)

当时咱们只知道，createAgent() 会在底层创建一张 LangGraph，然后把 Model Node、Tool Node 和各种 Middleware 编译进去。

但是，StateGraph 到底是什么，这张图又是怎么搭出来的，当时并没有展开。

这一小节，咱们就自己搭一张。

不过，这一次先不做 Model 和 Tool 之间的 Agent Loop。

咱们从一个更容易看清控制流程的需求开始：读取一个研发任务，再根据任务状态进入不同的处理分支。

大致的流程就是下面这样：

• 任务正在进行中 ---->>>> 生成后续处理建议
• 任务已经完成 ---->>>> 不再进入开发流程
• 任务不存在 ---->>>> 要求用户补充正确的任务编号

这些判断有明确规则，不需要浪费一次模型调用。

这正好可以让咱们先把 LangGraph 里最核心的 State、Node、Edge 和 Conditional Edge 搞明白。

先看一下最终结果

本节代码在：

/Code/Node/第五章/07-langgraph-basics

这个项目不需要配置模型 API，直接执行：

npm run demo

程序会连续输入三个任务编号。

• 第一个任务是：仍在进行中
• 第二个任务是：已经完成
• 第三个任务是：根本不存在

三个任务使用的是同一个程序入口，但是最后的结果却不一样

咱们先把打印出来的三条执行路径单独拿出来：

DEV-1024：load_task → handle_active
DEV-2048：load_task → handle_completed
DEV-9999：load_task → handle_missing

现在应该可以看出规律了。

无论输入哪个任务编号，程序都要先执行 load_task 查询任务。任务查完以后，才会根据查询结果选择不同的处理步骤。

在 LangGraph 中，像 load_task、handle_active 这样真正执行工作的步骤，叫作 Node，也就是节点。

Node 之间的连接关系 叫作 Edge，也就是边。

比如：程序启动以后一定先执行 load_task，这就是一条固定的 Edge。

但是，load_task 后面具体进入哪个 Node 并不固定，需要根据任务查询结果进行选择。

这种 满足不同条件，进入不同节点 的连接关系，就叫作 Conditional Edge，也就是 条件边。

上面的整个内容，就可以直接通过下面的图来进行表示。

不过，只有 Node 和 Edge 还不够。

load_task 查询到的任务信息，必须交给后面的处理 Node；处理 Node 生成的结果，最后也得返回给调用方。

这些在 Node 之间不断传递的数据，就叫作 State。

所以，本节的四个概念说白了就是：

• 程序要保存和传递数据，于是有了 State
• 要把工作拆成步骤，于是有了 Node
• 要规定执行顺序，于是有了 Edge
• 要根据数据选择分支，于是有了 Conditional Edge

简单吧。

接下来，咱们就看看这小节的案例

从 invoke() 开始看整个 Graph

打开