AI 又又造词，Graph 就又要替代 Loop 了？

OpenClaw 的 Peter 是懂嘲讽的，之前也是他提的，Prompt Engineering 已经成为过去，开始要进入 Loop Engineering 了，然后最近他发现，大家已经开始炒 Graph Engineering 了 ？感觉就像是当年的设计模式一样，MVC、MVP、MVVM、MVI 层出不穷····

就连图灵奖得主 Turing Award 都转发了 Graph Engineering 的讨论，那究竟是什么让 AI 又炒起来一个新词？不过在我看来，这实际上严格来说也不算新词，只是通过概念被重新包装，然后就给你带来 FOMO 的感觉。

在相关讨论里，Loop 只是起点，通过 Loop 实现的工作流虽然支持自我改进，但是在真实场景里，业务工作流更多应该是多个循环互相监视、互相约束、互相修正的网络（graph）。

什么是 Loop？

这个我们之前就讨论过了，Loop Engineering 的目的就是让任务工作流可以自我改进，循环迭代，但是这个过程其实可以抽象成同一个四步引擎：

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

也就是 Loop 就是设定目标，设置测试，然后循环工作，每周 eval 后调 prompt，只要业务是可以被测量的，就可以在循环里越变越好。

实际上 Prompt Engineering 变成 Loop Engineering ，就是把"不断催 Agent 干活的人"程序化，也就是现在的长程任务或者 goal 很类似。

也就是用户在工程化上，不需要研究怎么把提示词一次性写好，核心改成研究什么机制可以不断调用、验证、纠正和停止 Agent。

但是 Loop 在目前讨论里，有四个无法规避的问题：

失败模式	本质	典型表现
古德哈特定律	一个指标经过过度优化后，最终会不再衡量它原本所代表的意义，而循环只能看到它的指标	客服机器人把「解决率」刷上去，实际是在把用户劝退/标记为已解决
向上失明	循环无法质疑自己的目标是否正确	恒温器不会怀疑 20°C 是不是合理温度，eval 循环不会质疑 benchmark 是否真的代表用户体验
循环冲突	多个独立循环会互相打架	速度循环 vs 质量循环；增长循环 vs 文化循环
测量本身腐化	没有人在监视测量过程	传感器漂移、数据管道腐烂、数字变成「报告对报告」的自嗨

任务越长跑的越飘这个应该都遇到过吧？一个 Loop 能判断自己有没有接近参考值，但是不能判断这个参考值是否值得追求。

也就是当这些问题发生的时候， Loop 业务流本身看起来依然可以「运行完美」，所以才有接下来大家讨论的 Graph。

Graph

所以在这个讨论里，他觉得相比起调优一个 Loop ，在讨论里大家觉得需要的应该是一个循环的拓扑结构。

这里的 Graph 说的就是把工作类比成流程图，也可以把 Graphs 想象成 n8n，但连接的是你自己开发的引擎，比如 Codex、Claude Code 等等，可以创建"图"或可重用的工作流程，这些流程可以用于执行各类任务。

比如在 Graph 下，一个比较完整的 Agent 系统可能是：

vbnet 复制代码

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

这里每一个节点内部还是 Loop ，但是每个 Loop 之间需要有定向联系：

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

这么一说是不是就清楚了？说白了就是多 Agent 编排和组织方式，所以这根本不是什么新概念，只是另外一次上层包装。

简单来说，上层 Graph 就是让组织关系可编排和循环：

节点代表角色、能力或任务
边代表交接、依赖和控制关系

而且在 Graph 里，不同 Loop 不应该用相同速度运行，比如一个 Agent 系统里可以有四种时间尺度：

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

快 Loop 负责执行，慢 Loop 负责判断方向，如果你把所有东西都放进一个高速循环，Agent 很容易根据短期反馈不断改变策略，最终把长期目标破坏掉。

所以一套长时间运行运行的 Graph Loop 设定应该类似：

快速 Loop：提高 PR 合并数量
慢速 Loop：评估代码质量、线上故障率和维护成本

所以在它这套评估体系列：

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

所以严格来说，这已经不能简单说是 Agent 编排，更多属于业务设计上的控制平面与执行平面的分离。

所以在这次讨论里，画出 LangGraph 或者组织一个非常复杂的工作流图不是主要目的，核心是在于业务设计上：

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

Graph 本身能解决的只是结构，目标正确性这个才是这个讨论里的重点，怎么让目标流转，然后可持续交互验证，在不同时间维度下能互现评判，这才是讨论的重点：

循环都在互相看对方的报告，审计循环核对的是运营系统的数字，而运营数字又来自同一套系统，最终其实还是跳不出虚假的指标。

所以 Graph 必须有锚点，比如：

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

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

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

所以回过头来看，这些都不是什么新东西，只是被新的说辞包装起来，可能会包含

控制论和反馈控制
状态机与工作流引擎
CI/CD 和自动化测试
多 Agent 系统
分层控制系统
数据平面与控制平面
组织管理和 KPI 治理

这些都不是什么新鲜事，或者你在做的就已经是 Graph Engineering 了，所以也不需要 FOMO ，现在的速度，也许下个月还有新词，图个乐就行：