六周就被判死刑的 Loop Engineering，和它催生的 Graph Engineering
alitrack约 5 分钟2026 年 7 月 18 日凌晨，Peter Steinberger 发了一句话，575K 人看到了它：
"Are we still talking loops or did we shift to graphs yet?"
四个半小时后，Hamel Husain 发布了一篇文章：《Loop Engineering Is Dead. Enter Graph Engineering.》
问题是，Loop Engineering 这个概念才诞生六周。
今年 6 月 7 日，同样是 Steinberger 的一条推文让 "Loop Engineering" 成了 AI 开发者圈最热的话题。Addy Osmani 接着写了一篇长文，把 Prompt → Context → Harness → Loop 这条演进路径讲清楚了。六周后，它就被宣告死亡了。
这不是技术演进，这是内容生产的速度。
但在这场闹剧般的「讣告」背后，有一个真实的工程问题正在浮出水面：当一个 Agent 已经不够用了，多个 Agent 之间怎么分工、怎么交接、失败了退回到哪里？
● ● ●
Loop 解决的事，Graph 解决不了的事
先搞清楚 Loop Engineering 到底做了什么。
Loop 的核心是一个反馈回路：Trigger 启动 → Agent 执行 → Verification 检查 → 通过就下一步，失败就带着错误返回，达到目标就结束，超出权限就交给人。
它解决的核心问题是：你不需要每完成一步都发一句「继续」。 系统自己判断：测试通过了就下一步，测试失败了就带着错误日志回去修。
这条回路对于中小任务完全够用。但任务变大以后，问题就出来了。
所有工作被排成一条线——本来可以同时做的事情只能等着。调查、开发、测试、审核共享同一份越来越长的上下文，早期的日志和失败的旧结论不断积累。同一个 Agent 既负责实现，又负责判断自己的实现是否正确。一个局部问题可能导致整条回路重跑。
这时候你需要的不再是「一个 Agent 怎么持续工作」，而是「多个执行单元之间怎么连接」。
这就是 Graph Engineering。
● ● ●
Graph 包含 Loop，不是替代它
很多人把 Graph 理解成「一个 Agent 不够就加十个」。这是最常见也最贵的误解。
Google Research 和 MIT 在今年初做了一项实验：180 个 Agent 配置，5 种架构，3 个 LLM 家族，4 个基准任务。结论很明确——
能并行拆分的任务，多 Agent 比单 Agent 好 81%。严格顺序依赖的任务，所有多 Agent 变体都比单 Agent 差 39% 到 70%。
Graph Engineering 决策流程
| +81% | |||
| 17.2× | |||
| -70% |
三个反直觉的发现：
第一，没协调者的并行 Agent 会把错误放大 17 倍。 Agent A 犯了个错，Agent B 拿来继续加工，Agent C 在错误基础上再做判断——到输出端，一个小错已经变成了系统性错误。有中心协调者的情况好得多，但也还有 4.4 倍放大。
第二，单 Agent 基线超过 45% 准确率后，加 Agent 基本没用。 如果单个模型已经能把这个任务做到七八成，协调开销吃掉的多于新增 Agent 带来的。
第三，Graph 和 Loop 不是互斥的。 一个图里，每个节点内部都可以运行自己的 Loop——"修改代码 → 跑测试 → 根据错误修正 → 再跑测试"就是一条 Loop，它只是 Graph 的一个节点。
● ● ●
Graph Engineering 到底工程化了什么
画几个方框和箭头不难。难的都在图完成之后。
写代码的 Agent 和审查代码的 Agent 之间，传一段 "已完成，请继续" 的文本，和传一个结构化的 {status, changes, evidence, risks} 对象，效果完全不同。前者让下游猜，后者让下游判断。
三个节点同时跑——前端完成、后端完成、数据库失败。系统要决定：已完成的结果是否保留？后端结果是否依赖失败的数据库修改？要不要回到规划节点重新安排？
一个 "发送邮件" 节点执行成功了，但系统在保存成功状态之前崩了。恢复以后，如果节点重新执行，邮件就发了两次。
这些是分布式系统里老生常谈的问题，在多 Agent Graph 里同样存在。Graph Engineering 的工程价值，就在于迫使你在画画阶段就回答这些问题——而这些问题在大脑里思考「一个 Agent 搞定一切」时根本不会出现。
● ● ●
你的系统可能已经是一张隐式 Graph
如果你已经在用 Agent 框架，很可能你已经是 Graph Engineering 的实践者了。
LangGraph 把 Agent 工作流建模为带状态的图遍历——add_node 加节点，add_edge 连线，checkpointer 在每一步保存状态，支持中断、恢复和人工审批。
Claude Code 的 Dynamic Workflows 更进一步：它让 Claude 把计划写成 JavaScript 脚本，循环、分支、中间结果全在脚本变量里，不回流到对话上下文。这就是文章里反复强调的那句话——"Context 应该退出 Control Plane"。
Anthropic 早在 2024 年就定义了五种 workflow 模式：Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer。这些名字听起来新，但图的概念本身比你想象的老得多。
● ● ●
什么时候该用 Graph？什么时候不该？
五个问题就够了：
- 01
任务能拆成互不依赖的并行分支吗？ - 02
失败后需要局部恢复，而不是从头重跑？ - 03
中间状态必须跨会话、跨 Agent 存活？ - 04
执行者、检查者和授权者应该分开？ - 05
当前的验证步骤接触了外部结果，还是只在模型自己的输出里打转？
只有一个成立，就只为那个问题加一条边。 不要一上来画二十个节点的图。先建一条能工作的 Loop，从真实失败点开始拆分。
Google 那项研究的预测模型只有 87% 的准确率，但你不需要模型也能用核心逻辑：任务是什么形状，Graph 就应该是什么形状。
Graph Engineering 这个名字可能会留下来，也可能会被下一个六周的 cycle 替换掉。名字不重要。
重要的是它让你开始问那几个问题：谁负责规划，谁负责执行，谁能修改哪些状态，问题应该退回哪里，什么情况必须交给人。
这些决定，不能靠 Agent 在运行时临时商量。
参考
Towards AI: what the hell is graph engineering really (2026-07-20) Google Research: Towards a Science of Scaling Agent Systems (2026-01) Anthropic: Building Effective Agents (2024-12) arXiv:2607.00038: Loop Specification (2026-06-28) Claude Code Dynamic Workflows
你现在的 Agent 系统，是 Loop 还是 Graph？或者说——你已经在用 Graph 了，只是还没给它起名字？