← 返回概念解读

Concept Fable精修版

状态图

State Graph · Agent orchestration pattern

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

棋盘镇的每一格都要改同一本账

棋盘镇的驿站像一张方格棋盘。信件从南门进来,可能去账房、仓库、县学或码头。过去信少,驿卒凭经验转送,走错了也能很快找回来。

后来信件变复杂了。有的信要先验身份再进账房,有的要仓库回执后才能去码头,有的需要县学批注后再回到原处。每封信都带着不同材料,路线也会被中途结果改变。

驿长先画了一条总路线:南门、账房、仓库、码头。可很多信根本不该按这条路走。需要县学批注的信被送到码头,码头又退回来;缺身份的信进了账房,账房不敢动。

于是驿长给每类信写不同路线。墙上很快挂满纸条,纸条之间还互相打架:仓库退回的信到底回账房,还是回南门?县学补完批注后是否还要重验身份?

一位修路匠提议,不再从一条路线开始,而是把每个地方画成节点,把信件携带的材料画成同一本账。每个节点只能读取账上的内容、补充自己的结果,再根据账的新状态决定下一条边。

南门节点负责身份,账房节点负责金额,仓库节点负责库存,县学节点负责批注,码头节点负责发运。边上写明条件:身份通过才进账房,库存不足回采购,批注缺失去县学,全部齐备才到码头。

新图运行后,驿卒不再背整条复杂路线。他只看当前节点、同一本账和下一条满足条件的边。信被退回时,退回原因也写到账里,下一次不会当成新信从头乱走。驿站还在关键节点设了封存点。走到仓库前保存一次,发运前保存一次。路上出错,可以从最近状态恢复,而不是把所有步骤重演一遍。修路匠还规定,节点不能私自藏纸条。所有新增材料都写回同一本账,否则下一站看不到前一站的判断。共享状态让路线变化有依据,也让复盘能重走当时路径。

棋盘镇后来发现,这张图最重要的不是漂亮,而是每一步都围绕共享状态更新。复杂工作不再是一堆互相传话的人,而是一张能根据状态决定下一步的执行图。

揭示

这个故事讲的是:状态图

状态图把 Agent 工作流建模为一组节点和边:节点读取并更新共享状态,边根据状态决定下一步执行。它适合表达会分支、循环、等待、重试和恢复的 Agent 流程。企业系统使用状态图时,关键是定义共享状态结构、节点职责、边的条件、检查点和恢复策略,避免把复杂流程写成难以维护的提示词链或一次性脚本。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 棋盘镇驿站:多步骤、多分支的 Agent 执行环境
  • 信件携带的材料:任务状态、上下文、工具结果和中间产物
  • 一条总路线:线性链式流程难以处理动态分支
  • 墙上挂满纸条:分支逻辑散落各处导致维护困难
  • 节点:读取和更新状态的执行步骤或 Agent/工具单元
  • 边:根据状态选择下一步的路由条件
  • 同一本账:State Graph 中的共享状态
  • 封存点:checkpoint,让任务可以恢复和断点续跑

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

LangGraphstate machineDAGcheckpointorchestration