OpenClaw 的 Peter 确实善于捕捉行业痛点——上次他刚提出“Prompt Engineering 已成过去，该进 Loop Engineering 了”，转眼间大家又开始热议“Graph Engineering”。这场景像极了当年的设计模式更迭：MVC、MVP、MVVM、MVI，一个接一个，名称变换比翻书还快。
连图灵奖得主都转发了 Graph Engineering 的讨论，如此阵仗让人不得不深思：AI 江湖又造出了什么新名词？其实严格来说，这算不上全新概念，只是把旧有元素重新包装，刻意制造一些 FOMO（错失恐惧）情绪罢了。
在那场讨论里，Loop 仅仅是个起点。通过 Loop 实现的工作流虽然具备自我改进能力，但到了真实业务场景中，仅靠一个闭环远远不够——真正需要的是多个循环互相监视、互相约束、互相修正的网络，也就是 Graph。
什么是 Loop？
这个问题我们之前探讨过。Loop Engineering 的核心，就是让任务工作流能够自我改进、循环迭代。无论具体实现方式如何，这个过程都可以抽象为同一个四步引擎：
- 选择一个要控制的对象（metric / capability）
- 设定目标值（reference / setpoint）
- 测量当前值与目标的差距
- 采取行动缩小差距，然后重复
简而言之，Loop 就是定好目标、设置测试，然后循环运行起来——每周做一次评估，调整 prompt。只要业务指标能被测量，就能在循环中持续优化。
对于工程化而言，用户不再需要死磕“一次性写好提示词”，而是把精力放在研究“什么机制能不断调用、验证、纠正和停止 Agent”上。
不过，Loop 在实际讨论中暴露了四个绕不开的问题：
| 失败模式 | 本质 | 典型表现 |
|---|---|---|
| 古德哈特定律 | 一个指标过度优化后，不再代表原本的意义，循环只认指标本身 | 客服机器人把“解决率”刷上去，实际是把用户劝退或者标记为已解决 |
| 向上失明 | 循环无法质疑自己的目标是否正确 | 恒温器不会怀疑 20°C 是不是合理温度；eval 循环不会质疑 benchmark 是否真的代表用户体验 |
| 循环冲突 | 多个独立循环会互相打架 | 速度循环 vs 质量循环；增长循环 vs 文化循环 |
| 测量本身腐化 | 没有人在监视测量过程 | 传感器漂移、数据管道腐烂、数字变成“报告对报告”的自嗨 |
当这些问题发生时，Loop 业务流本身看起来依然“运行完美”——这才是最要命的。所以大家才把目光转向了 Graph。
Graph
在讨论中，大家认为与其只调优一个 Loop，不如构建一个循环的拓扑结构。这里的 Graph，就是把工作流类比成流程图，有点像 n8n，但连接的是你自己开发的引擎（比如 Codex、Claude Code 等），用来创建可重用的工作流程，执行各类任务。
举个例子，一个比较完整的 Agent 系统可能是这样的：
产品目标 / 人类负责人
↓
任务规划 Loop
↙ ↘
代码执行 Loop 检索 Loop
↓
编译与测试 Loop
↓
代码审查 / 安全验证 Loop
↙ ↘
退回修改 人类确认
↓
发布与部署 Loop
↓
线上监控 Loop
↓
产品反馈与目标修订 Loop
你会发现，每个节点内部还是 Loop，但 Loop 之间需要有定向联系：谁给谁提供反馈？谁可以否决谁？谁负责更新目标？谁负责发现指标失真？谁在失败后回滚？谁决定继续、停止或者升级给人类？哪些 Loop 可以并行，哪些必须等待依赖完成？
这么一说就清楚了：这本质上就是多 Agent 的编排和组织方式。所以根本不是什么新概念，只是又一次上层包装。
简单来说，上层 Graph 让组织关系变得可编排、可循环：节点代表角色、能力或任务；边代表交接、依赖和控制关系。
而且，在 Graph 里，不同 Loop 不应该用相同速度运行。一个 Agent 系统里可以有四种时间尺度：
- 秒级 Loop：调用工具、读取结果、修正参数
- 分钟级 Loop：执行任务、运行测试、生成补丁
- 小时或天级 Loop：批量 Eval、质量分析、失败归因
- 周或月级 Loop：修改目标、更新指标、调整权限和系统架构
所以，一套长时间运行的 Graph Loop 设定应该类似这样：快速 Loop 提高 PR 合并数量，慢速 Loop 评估代码质量、线上故障率和维护成本。
按照这套评估体系，有几个关键原则：
- 指标不能单独存在，必须有制衡指标
- 目标必须有负责人，不能让执行 Loop 自己随意改写
- 不同时间尺度必须隔离，快速 Loop 不能直接重写长期目标
这次讨论的核心，不是画个 LangGraph 或者组织一个复杂的工作流图，而是在业务设计上想清楚：谁检查指标是否可信？谁处理不同目标之间的冲突？谁能够修改目标？谁拥有最终否决权？
Graph 本身能解决的只是结构，目标正确性才是重点——怎么让目标流转，可持续交互验证，在不同时间维度下能互相评判。
所以 Graph 必须有锚点：
- 不可变的参考数值：真正进账的钱、真正跑通的测试、真正续费的客户、物理盘点
- 冻结节点：某些规则优化循环永远不能碰，就像训练循环永远不能碰 held-out set
- 来自系统外部的判断：什么叫“更好”这个最根本的问题，不可能让循环网络自己生成判断，必须让人通过真实失败场景来供给参考
这不是什么技术变革。Graph 只是在过去的基础上探讨怎么编排业务循环，怎么让业务循环的目标可以流转和迭代：哪些循环可以互相看见？哪些评估必须对优化循环严格隔离？哪里需要冻结规则？最终“什么叫好”通过什么定义，能不能被 agent 自己修改？
回过头来看，这些都不是新东西，只是被新的说辞包装起来——里面包含了控制论与反馈控制、状态机与工作流引擎、CI/CD 与自动化测试、多 Agent 系统、分层控制系统、数据平面与控制平面、组织管理与 KPI 治理……全都不新鲜。甚至你已经在做的，可能就是 Graph Engineering 了。所以不用 FOMO。按照现在的节奏，下个月保准还有新词，图个乐就行。
