OpenClaw 的 Peter 确实很会抓痛点。上次他刚抛出“Prompt Engineering 已成过去，该进 Loop Engineering 了”，转眼大家就开始炒“Graph Engineering”了。

这场景像极了当年的设计模式：MVC、MVP、MVVM、MVI，一个接一个，名字换得比翻书还快。

连图灵奖得主都转发了 Graph Engineering 的讨论。这阵仗让人不得不琢磨：AI 江湖又造了个什么新词？

其实严格来说，这算不上新概念。只是把老东西重新包装，给你制造点儿 FOMO（错失恐惧）而已。

在那场讨论里，Loop 只是个起点。通过 Loop 实现的工作流虽然能自我改进，但到了真实业务场景中，光靠一个闭环远远不够。

真正需要的是多个循环互相监视、互相约束、互相修正的网络，也就是 Graph。

什么是 Loop？

Loop 的核心引擎

这个我们之前聊过。Loop Engineering 的核心，就是让任务工作流能自我改进、循环迭代。

不管具体怎么实现，这个过程都可以抽象成同一个四步引擎：

• 选择一个要控制的东西（metric / capability）
• 设定目标值（reference / setpoint）
• 测量当前值与目标的差距
• 采取行动缩小差距，然后重复

说白了，Loop 就是定好目标、设好测试，然后循环跑起来——每周做一次评估，调一调 prompt。

只要业务指标能被测量，就能在循环里越变越好。

对于工程化来说，用户不再需要死磕“一次写好提示词”。而是把精力放在研究“什么机制能不断调用、验证、纠正和停止 Agent”上。

Loop 的四个失败模式

不过，Loop 在实际讨论中暴露了四个绕不开的问题：

当这些问题发生时，Loop 业务流本身看起来依然“运行完美”——这才是最要命的。

所以大家才把目光转向了 Graph。

Graph

在讨论中，大家觉得与其只调优一个 Loop，不如构建一个循环的拓扑结构。

这里的 Graph，就是把工作流类比成流程图。有点像 n8n，但连接的是你自己开发的引擎（比如 Codex、Claude Code 等），用来创建可重用的工作流程，执行各类任务。

举个例子，一个比较完整的 Agent 系统可能是这样的：

产品目标 / 人类负责人
    ↓
任务规划 Loop
    ↙     ↘
代码执行 Loop   检索 Loop
    ↓
编译与测试 Loop
    ↓
代码审查 / 安全验证 Loop
    ↙      ↘
退回修改      人类确认
    ↓
发布与部署 Loop
    ↓
线上监控 Loop
    ↓
产品反馈与目标修订 Loop

你会发现，每个节点内部还是 Loop。但 Loop 之间需要有定向联系：

• 谁给谁提供反馈？
• 谁可以否决谁？
• 谁负责更新目标？
• 谁负责发现指标失真？
• 谁在失败后回滚？
• 谁决定继续、停止或者升级给人类？
• 哪些 Loop 可以并行，哪些必须等待依赖完成？

这么一说就清楚了：这本质上就是多 Agent 的编排和组织方式。

所以根本不是什么新概念，只是又一次上层包装。

简单来说，上层 Graph 让组织关系变得可编排、可循环：节点代表角色、能力或任务；边代表交接、依赖和控制关系。

Graph 的时间尺度

而且，在 Graph 里，不同 Loop 不应该用相同速度运行。

一个 Agent 系统里可以有四种时间尺度：

• 秒级 Loop：调用工具、读取结果、修正参数
• 分钟级 Loop：执行任务、运行测试、生成补丁
• 小时或天级 Loop：批量 Eval、质量分析、失败归因
• 周或月级 Loop：修改目标、更新指标、调整权限和系统架构

所以，一套长时间运行的 Graph Loop 设定应该类似这样：快速 Loop 提高 PR 合并数量，慢速 Loop 评估代码质量、线上故障率和维护成本。

Graph 的关键原则

按照这套评估体系，有几个关键原则：

• 指标不能单独存在，必须有制衡指标
• 目标必须有负责人，不能让执行 Loop 自己随意改写
• 不同时间尺度必须隔离，快速 Loop 不能直接重写长期目标

这次讨论的核心，不是画个 LangGraph 或者组织一个复杂的工作流图。而是要在业务设计上想清楚：

• 谁检查指标是否可信？
• 谁处理不同目标之间的冲突？
• 谁能够修改目标？
• 谁拥有最终否决权？

Graph 本身能解决的只是结构，目标正确性才是重点。即怎么让目标流转，可持续交互验证，在不同时间维度下能互相评判。

Graph 的锚点

所以 Graph 必须有锚点：

• 不可变的参考数值：真正进账的钱、真正跑通的测试、真正续费的客户、物理盘点
• 冻结节点：某些规则优化循环永远不能碰，就像训练循环永远不能碰 held-out set
• 来自系统外部的判断：什么叫“更好”这个最根本的问题，不可能让循环网络自己生成判断，必须让人通过真实失败场景来供给参考

这不是什么技术变革。Graph 只是在过去的基础上探讨怎么编排业务循环，怎么让业务循环的目标可以流转和迭代：

• 哪些循环可以互相看见？
• 哪些评估必须对优化循环严格隔离？
• 哪里需要冻结规则？
• 最终“什么叫好”通过什么定义，能不能被 agent 自己修改？

回过头来看，这些都不是新东西，只是被新的说辞包装起来。

里面包含了控制论与反馈控制、状态机与工作流引擎、CI/CD 与自动化测试、多 Agent 系统、分层控制系统、数据平面与控制平面、组织管理与 KPI 治理……全都不新鲜。

甚至你已经在做的，可能就是 Graph Engineering 了。

所以不用 FOMO。

按照现在的节奏，下个月保准还有新词，图个乐就行。

《夸克》非常好用的免费AI浏览器

下载APP查看