状态机、图与 Loop Engineering

模型的价值来自不确定性：它能在开发者没有穷举的情况下理解语言、选择工具和处理例外。

生产系统的问题也来自不确定性：它可能跳过步骤、重复动作、过早宣布完成，或者在错误验证器的鼓励下一直运行。

状态机和图不是为了把 Agent 重新写成死流程，而是给不确定决策划出可达边界。

一个实用原则是：让模型在节点里解决开放问题，让图决定必须经过哪些状态。

一、为什么消息列表不够

很多最小 Agent 把全部状态放进 messages。模型根据消息决定工具，工具结果再追加回消息。

短任务可以这样做。任务一长，系统会遇到：

不知道当前处于哪一阶段；
无法区分已经验证和只是讨论过；
旧计划与新计划同时存在；
两个并行分支更新同一字段；
进程重启后只能重放整段对话；
人工批准很难对应具体动作。

State Schema 把关键事实从文本中提取出来：

{
  "goal": "完成可发布文章",
  "status": "verifying",
  "draft_path": "article.md",
  "revision": 1,
  "max_revisions": 2,
  "evidence": ["citation-check.json"],
  "pending_approval": null
}

模型仍然可以阅读摘要，但程序能明确判断状态。

二、状态机的四个基本对象

State

任务当前的权威数据，包括状态、工件、预算和证据。

Node

执行一个有限责任：生成草稿、调用工具、验证引用、请求审批。

Edge

定义允许的状态转移。验证失败可以进入 revise，预算耗尽只能进入 failed，不能继续生成。

Terminal State

明确成功、失败、暂停、取消或预算耗尽。终态不是一段总结，而是系统状态。

这四个对象把“接下来怎么办”从纯 Prompt 变成可检查的控制结构。

三、Graph 与 Workflow 的区别在哪里

Graph 是表达结构，Workflow 是承载业务过程的运行模型。

一张图可以只有确定性节点，也可以在节点内运行 Agent。图本身不自动提供持久化、幂等和业务补偿，具体能力取决于运行时。

LangGraph 用 State、Node、Edge、Reducer、Checkpoint 和 Interrupt 构建有状态 Agent。[1]

LangGraph 仓库页面

图 1：LangGraph 的核心不是“画图”，而是显式状态、持久化和中断恢复。来源见文末。

Reducer 尤其重要。两个并行节点同时返回更新时，系统要知道列表是追加、覆盖还是拒绝冲突。没有合并语义，共享状态只是一张更隐蔽的全局变量表。

四、把自治限制在“口袋”里

CrewAI 用 Crews 表达自治角色协作，用 Flows 表达事件、状态和确定性控制。官方文档把二者组合描述为在 Flow 中放置 pockets of agency。[2]

这是一个很有用的设计方式。

例如报告流程：

固定：读取任务与权限
Agent：并行研究三个开放问题
固定：合并来源注册表
Agent：撰写综合稿
固定：引用校验与敏感信息检查
人工：终审

模型在研究和写作节点拥有较大自由，但不能跳过引用校验和人工终审。

自由度应该按节点分配，而不是给整个系统一个“全自治”开关。

五、Loop Engineering 怎样进入状态图

第 4 讲给出 Loop Engineering 八字段：Trigger、Goal、Scope、Harness、Verification、State、Budget、Ownership。

映射到图里，可以这样理解：

Loop 字段	图中的位置
Trigger	创建 Run 的入口事件
Goal / Scope	初始 State 与 Policy
Harness	Node 的执行环境
Verification	Gate Node
State	Schema + Checkpoint
Budget	状态字段与条件边
Ownership	Run Lock / Lease
Terminal State	End Nodes

Loop Engineering 提供控制问题，Graph 提供一种表达和执行方式。两者不是同义词。

六、验证 Gate 应该怎样设计

一个 Gate 至少返回：

{
  "verdict": "pass | fail | limited",
  "evidence": [],
  "checked_version": "commit-or-artifact-id",
  "reason": "",
  "retryable": false
}

fail 不能因为 Agent 请求继续而变成 pass。limited 是否允许推进，需要显式 Policy。

证据必须绑定被检查的版本。如果源码、Prompt、工具配置或数据发生变化，旧 Gate 结果会过期。

这正是旧稿中 Proof-or-Stop 的核心：没有与当前状态绑定的证据，就不能进入成功终态。[3]

七、循环怎样保证有界

最常见的图是：

draft -> verify -> success
             \-> revise -> verify

如果 revise 没有次数和进展判断，这张图仍然可能无限循环。

至少要加入：

最大修订次数；
总预算和截止时间；
连续相同失败检测；
每轮必须新增的证据；
不可恢复错误；
人工接管入口。

loop.js 等新项目强调 goal、verify、limits 和 typed exit，就是把这些约束写成运行时对象。[4]

loop.js 的 goal、verify 与 limits

图 2：loop.js 将目标、验证和限制放在循环定义里。它代表新兴实践，不是统一行业标准。

八、状态外置为什么重要

如果状态只存在某个 Agent 的上下文里，换模型、换 Runtime 或跨 Session 都很困难。

LoopX、OSpec、Loom 等项目探索把目标、证据、预算、工件和 Handoff 独立保存。[5]

LoopX 状态内核

图 3：LoopX 代表把状态内核放在具体 Agent Runtime 之外的探索。来源见文末。

状态外置的收益包括：

可以更换执行 Harness；
人类能检查当前事实；
多轮运行不依赖聊天记录；
证据和预算容易审计；
失败后能从明确 Checkpoint 恢复。

代价是需要 Schema、并发控制、版本迁移和数据治理。

九、真实实验：同一张图，既能成功也能有界失败

本讲的 state_graph_loop.py 实现 draft -> verify -> revise 状态机。

第一个案例初始分数 60，每次修订增加 15。两轮后到达 90，验证通过：

{"status": "success", "revisions": 2, "score": 90}

第二个案例初始分数 20，两轮后只有 50。虽然仍可继续修改，系统因为达到 max_revisions=2 进入失败终态：

{"status": "failed", "revisions": 2, "score": 50}

完整轨迹见 experiment-result.json。

这个实验说明：失败不是图没工作。在限制内无法达到标准，然后诚实停止，本身就是正确行为。

十、什么时候值得使用状态图

适合：

有明确阶段和分支；
必须人工审批；
需要暂停恢复；
多 Agent 有共享状态；
验证失败需要有限修订；
业务需要审计路径。

不一定适合：

两三步只读任务；
所有逻辑都能用普通函数清楚表达；
团队无法维护状态迁移和版本；
任务本身没有可定义的状态。

不要为了“看起来像 Agent 架构”画图。图应该减少隐含控制，而不是增加形式。

十一、状态图设计检查表

State 是否只保存必要事实；
每个 Node 是否只有有限责任；
Edge 是否覆盖失败、暂停和取消；
并行更新是否有 Reducer；
Gate 是否返回证据和版本；
循环是否有预算和无进展检测；
Checkpoint 是否能恢复；
外部副作用是否幂等；
Schema 变化是否有迁移方案；
人工能否查看和纠正状态。

十二、这一讲的结论

状态机和图不是限制模型思考，而是限制系统在没有证据时继续推进。

模型处理开放问题，状态保存事实，边规定可达路径，Gate 决定是否通过，终态让循环诚实结束。

下一讲处理图仍未自动解决的问题：进程会崩、网络会断、审批可能隔夜返回。Durable Execution 怎样让长任务在故障后继续，而且不重复副作用？

参考资料

[1] LangChain, LangGraph Graph API. https://docs.langchain.com/oss/python/langgraph/graph-api

[2] CrewAI, Core Concepts. https://docs.crewai.com/core-concepts/Agents

[3] Proof-or-Stop. https://arxiv.org/abs/2607.14890

[4] loop.js. https://github.com/loop-js/loop.js

[5] LoopX. https://github.com/huangruiteng/loopx

[6] Wu et al., StateFlow. https://arxiv.org/abs/2403.11322

[7] Microsoft, Agent Framework Workflows. https://learn.microsoft.com/en-us/agent-framework/workflows/