Enivia 几天前 OpenClaw（龙虾）的创始人 Peter 发布了一则推文，没想到在开发者社区引起了不小的共鸣。
过去一个月，大家谈论最多的是 Loop Engineering（循环工程）：
AI 观察当前状态 -> 决定下一步行动 -> 调用工具 -> 读取工具返回结果 -> 继续思考/行动 -> 直至任务完成。
而当开发者真正开始构建更长、更复杂的 Agent 工作流时，会发现问题主要在于：
- 谁负责判断任务已经完成？
- 失败以后应该重试、换模型、换工具，还是移交给人类？
- 两个子任务能不能并行？
- 哪些结果可以覆盖，哪些状态必须保留？
- …
当这些问题越来越多，单一循环就开始显得不够用了，图（Graph）应运而生。
循环是 Agent 的最小原子单位
一个最简单的 Agent，通常可以被描述为下列过程：
- 模型读取任务和当前上下文
- 模型选择行动或工具
- 系统执行工具
- 工具结果返回给模型
- 模型决定继续还是结束
这就是一个循环。
它代码少、路径灵活，也不需要提前预测任务究竟要执行多少步。对于搜索资料、修改代码、操作电脑这类开放任务，我们很难预先写出完整流程，因此把下一步交给模型决定非常合理。
Agent 会以更高的延迟、成本和错误风险换取灵活性。系统会从最简单的方案开始，只在效果确实需要改善时增加复杂度。
模型为什么选择这个工具，为什么重试，为什么跳过某项检查，往往只有模型自己知道。任务之间的依赖关系没有被明确表达，恢复机制也可能变成没有边界的不断重复尝试。
Graph 会改变什么？
Graph 并不意味着循环消失。
一个图里完全可以存在很多循环。真正发生的变化，是开发者开始将原本隐藏在模型上下文里的控制关系，提升到架构层面。
以 LangGraph 为例，它将 Agent 工作流拆成三个基本部分：
- State：整个系统共享和持续更新的状态
- Node：执行具体工作的节点，可以是模型、工具，也可以是普通代码
- Edge：决定执行路径的边界
Node 负责做事，Edge 负责决定下一步。Graph 中可以串行、并行、分支，也可以重新回到前面的节点形成循环。
它更接近于：显式设计 Agent 之间的状态、依赖、分支、监督、恢复和终止关系。
假设我们需要开发一个客服 Agent，最初的系统可能只有一个循环：
阅读用户问题 -> 查询资料 -> 生成回复 -> 判断是否解决
然后我们会用「解决率」之类的指标去评估它。如果解决率下降，就需要修改提示词、工具和策略。
这个循环可能会持续优化数据，却不一定持续改善用户体验。Agent 可能学会尽快关闭对话、减少追问，或者把用户放弃的问题标记为已经解决。
单纯增加一次反思，未必能解决这个问题。因为生成答案和反思结果的仍然可能是同一个模型，共享同一段上下文，也可能共享同样的理解偏差。
更可靠的做法，是把系统拆成多个相互约束的节点：
用户请求
↓
意图与风险分类
↓
资料检索 → 证据检查
↓
答案生成 → 独立评估
↓ ↓
通过 修改或升级
↓
执行操作 → 结果验证
↓
用户反馈与长期指标在这张图里，答案生成只是其中一个节点。
- 证据检查节点负责确认回答是否有确切来源
- 风险节点决定某些操作是否需要人工批准
- 评估节点检查答案质量
- 执行节点真正修改订单或发起退款
- 结果验证节点确认操作是否成功
- 延迟评估则关注用户是否再次联系、续订或投诉
可靠性主要源于这些节点之间的关系，而不只看一个节点的决策。
Graph 应该包含哪些内容？
节点边界
首先决定，哪些任务放在同一个节点，哪些工作需要拆开。
检索、规划、生成、验证和执行拥有不同的输入、权限。把所有能力都塞进一个 Agent，会让上下文越来越混乱，也会让错误难以定位。
节点的划分不应该取决于使用了多少个模型，而应该取决于职责是否清晰、结果是否能够独立验证。
状态保存
其次要明确，每个节点可以读取什么、修改什么。
相比不断增长的对话记录，更可靠的方式，是把任务目标、当前计划、已确认事实、中间产物、错误记录、执行预算和审批结果分别保存。每个节点只读写自己需要的部分，状态变化也能够被追踪和恢复。
下一步决定
节点任务完成后，可能继续执行，可能进入验证，也可能退回重试或交给人工。分支条件不能全部隐藏在模型的临时判断中，而应该尽量成为显式规则。
当两个节点意见冲突时，也必须提前定义谁拥有最终决定权。
终止与恢复
只要图中存在循环，就必须明确终止条件。例如最大步骤数、重试次数、时间和 token 成本。
恢复后的执行路径也应该与正常执行路径分开，不能全部通过“再试一次”处理。
监督
复杂 Agent 系统除了记录结果，还需要记录完整的执行过程。
系统需要记录任务经过了哪些节点、状态如何变化，以及为什么选择某条路径。否则图越复杂，问题越难定位。
外部锚点
多个 Agent 可以互相检查，却可能共同确认同一个错误。因此，图中必须保留真实测试、数据库状态、用户反馈、人工抽查等外部依据，防止系统只在内部自洽。
Graph Engineering 设计的并不只是节点与关系。它同时设计职责、状态、控制权、失败边界、监督机制，以及系统与现实之间的连接。
最后
Graph 这个概念一出，很容易演变成新的“复杂度崇拜“。
原本一个模型调用能够完成的任务，被拆成十几个节点；每个节点都使用不同 Agent；它们互相评审、投票和修改，最终消耗几十倍的 token，只得到差不多的答案。
Graph 不能替代好的模型，不能替代可靠的工具，也不能替代明确的成功标准。它的意义在于，让我们学会更宏观地去把控 AI 的运行过程。
过去我们关心：
怎样写提示词才能让 AI 更聪明？
而现在我们会关心：
谁可以做决定，谁负责检查，错误如何传播，状态如何更新，系统在哪里停止，以及什么样的结果才算真的成功？
从 Loop 到 Graph 听起来像一种数据结构的变化，但实际上是我们正在把 AI 从工具改造成一个拥有状态、边界、监督、恢复机制的真正系统。
这就是我对 Graph Engineering 的理解。
