Loop Engineering 这次“死”得有点快哦。
6 月 7 日，Addy Osmani 发布了一篇系统介绍 Loop Engineering 的文章：不要再由人一轮轮提示 Agent，而是设计一个能够发现任务、分发任务、检查结果、记录状态并决定下一步的系统。
7 月 18 日，Peter Steinberger 在 X 上问了一句：
“我们还在讨论 Loop，还是已经转向 Graph 了？”
几个小时后，Hamel Husain 直接发出了“讣告”：
“Loop Engineering Is Dead. Enter Graph Engineering.”
随后一两天，课程、路线图、工具栈和解释文章就都冒出来了。从 Addy 的文章发布，到 Loop Engineering 被宣告“死亡”，一共 41 天，距离整六周只差一天。这个速度放在传统软件工程里，可能连一个版本的灰度周期都走不完。
来扯个犊子：
Loop Engineering 还没死，Graph Engineering 也不是突然被发明出来的新大陆。它只是说明 AI Agent 的工程关注点，又从一个闭环扩展到了多个闭环之间的协作而已。
Loop 解决局部任务如何持续收敛，Graph 解决多个任务、多个 Agent、多个验证器之间如何分工、并行、交接和回退。
图里本来就可以有环。
所以 Graph 不是把 Loop 拍死在沙滩上，而是把它放进了更大的协作结构里。
一、这场“Loop 已死”的舆论，到底在说什么
咱首先得把大佬的传播话术和真实技术变化分开。
“Loop Engineering Is Dead”是一个有很强传播性的标题。Peter 和 Hamel 的原帖更像两个行业梗，后续讨论才迅速把 Graph Engineering 包装成一套新说法。
它抓住了 AI 圈一个典型的命名节奏：
Prompt Engineering 还没学明白，Context Engineering 来了；
Context 还没治理好，Harness Engineering 来了；
Harness 刚开始落地，Loop Engineering 又来了；
Loop 才热了六周，Graph Engineering 已经站在门口敲钟了。
但这次舆论背后，也确实有一个真实问题：
单个 Agent 的长任务能力在变强。我们已经能让它读取上下文、调用工具、修改代码、运行测试，根据失败结果继续修，直到成功或者触发停止条件。
这就是一个 Loop。
可一旦我们同时跑多个 Agent，问题马上变了：
•谁负责规划，谁负责实现，谁负责验证？•哪些任务可以并行，哪些任务存在前后依赖？•一个 Agent 的输出，以什么格式交给下一个 Agent？•安全审查和代码审查意见冲突时，听谁的？•一个分支失败，是局部重试、整体回滚，还是转人工？•多条执行路径什么时候汇合，谁来判断全局目标已经完成？
人虽然退出了局部执行循环，却又变成了多个 Loop 之间的“人工路由器”：开三个窗口、复制三份上下文、搬运结果、判断下一步、处理冲突。
工作自动了，协调其实还没有自动。
Graph Engineering 的热度，真正击中的就是这个新瓶颈。
二、Graph Engineering 到底是什么
目前这个词还没有一个公认的正式定义。有人把它理解为“多 Agent 工作流”，有人强调“多个反馈闭环组成的网络”，也有人把任务依赖图、评测图、权限图和人工审批都算进去。
但有一说一，把这些说法取一个最大公约数，大概就是这样：
Graph Engineering 是把多个 Agent、确定性程序、工具、验证器和人工节点组织成一张显式的工作图，并设计它们之间的状态传递、路由规则、并行关系、质量门和失败恢复。
一张最小的 Agent 工作图，应该有以下几类东西：
1.节点：真正干活的单元。它可以是一个 Agent，也可以是一段确定性代码、一次测试、一个审批人，甚至是内部还带着 Loop 的完整子流程。2.边：工作怎么流动。它不只是“把一段聊天转给下一个 Agent”，还应该包含触发条件、输入输出契约和权限边界。3.状态：系统当前知道什么、完成了什么、失败在哪里。状态必须存在于单次对话之外，能够持久化、恢复和审计。4.路由：根据结果决定下一步。通过就向前，失败就回到局部节点，高风险就转人工，不确定就补充上下文。5.并行与汇合：能拆开的任务同时做，但在进入下一阶段前，需要有明确的汇合条件和冲突处理规则。6.局部验证与全局目标：每个节点要证明自己的输出合格，整张图还要证明最终业务目标已经完成。7.预算和停止条件：限制时间、token、重试次数、工具调用和影响范围，防止一张图把“自动干活”变成“自动烧钱和自动制造事故”。
举个软件研发中的简化例子。
一个需求通过评审后，规划 Agent 先把任务拆分。接口实现、前端适配、测试用例和安全分析可以部分并行。各自完成后，集成节点汇总变更，验证节点运行测试并核对验收标准。如果安全审查失败，只把相关分支退回；如果接口契约发生变化，则重新触发受影响的上下游节点；最后由人完成高风险发布审批。
这里每个开发或审查 Agent 内部仍然可能运行自己的 Loop。
Graph 负责的不是替代它，而是决定这些小 Loop 如何连接。
PS. Graph Engineering 不是 GraphRAG。GraphRAG 主要解决知识如何按实体和关系组织、检索与推理；这里的 Graph 主要描述工作如何流动。
三、Graph 不是新发明，新的是节点开始变得不确定
如果稍微看一下历史，就会发现 Graph Engineering 的很多“新概念”，软件行业早就在用了。
构建系统用依赖图决定编译顺序，CI/CD 用 DAG 编排任务，工作流引擎用状态机处理分支和回退，数据平台用有向图调度计算，分布式系统用消息在节点之间传递状态。
连 AI Agent 领域也不是 2026 年 7 月才开始画图。
Anthropic 在 2024 年底介绍 Agent 系统时，就已经把 prompt chaining、routing、parallelization、orchestrator-workers、evaluator-optimizer 画成了不同的工作流结构。LangGraph 更是直接用 State、Node 和 Edge 来表达长时间运行的 Agent 工作流。OpenAI 的 Agents SDK 也已经把 manager、agents as tools、handoff，以及由代码或 LLM 负责 orchestration 做成基础模式。
2025 年，Anthropic 公开过其多 Agent Research 系统：主 Agent 负责规划，多个子 Agent 并行搜索，最后再汇总和补充引用。在该内部 Research 评测中，多 Agent 系统的表现比单 Agent 高 90.2%；但与此同时，多 Agent 系统消耗的 token 大约是普通聊天的 15 倍，而且高度依赖共享上下文、难以并行的任务并不适合这种架构。
Codex 增强的并行任务、subagent、worktree 和 automation；Claude Code 通过 subagent、实验性的 agent team、worktree 等机制加强并行协作。OpenAI Agents SDK 中的 handoff 与 agents as tools，则把跨 Agent 的委派和路由变成了基础模式。这些能力名称不同，本质上都在把这种结构产品化。
所以，新的并不是“图”。
真正的新变化是：过去图中的节点大多是确定性程序，现在越来越多节点变成了会推理、会调用工具、会改变计划、也会犯错的 Agent。
这会带来三种传统工作流里没那么尖锐的问题。
第一，节点的输出不稳定。同样的输入，两次执行可能走向不同结果。
第二，边的语义不再天然可靠。一个 Agent 说“已经完成”，只是一个主张，不是证据。
第三，图本身可能动态变化。规划 Agent 会临时拆出新任务、增加子 Agent、调整路线，静态 DAG 不一定提前画得出来。
因此 Graph Engineering 真正值得研究的，不是怎么画一张更漂亮的图，而是怎么让这张由不确定节点组成的图仍然可观察、可验证、可恢复、可接管。
节点变聪明之后，系统工程会变得更重要。——老登福音。
四、从顺序控制、任务图到分布式协作：来猜猜下一个会不会是 Protocol Engineering
换一个更准确的观察角度：从顺序控制流，到任务依赖图，再到分布式协作；从单 Agent 到多 Agent，从 Loop 到 Graph。
后者从来不是把前者替换掉：数组、链表、树、图解决的是不同形状的问题；顺序、分支、循环、并行也一直同时存在。DAG 调度也没有让 while 循环消失。
真正的发展是计算系统复杂度不断外扩的必经之路：
•单机顺序程序，重点是下一条指令执行什么；•复杂数据结构和计算图，重点是谁依赖谁；•并发与分布式系统，重点变成多个节点如何在延迟、失败和状态不一致的情况下协作；•大规模社会技术系统，还要处理权限、信任、治理、成本和责任。
所以沿着这条线推演，让我来猜猜下一个“XXX Engineering”会不会是：
Protocol Engineering。
市场传播上，也许会再次把 Swarm Engineering 推到台前，强调大量 Agent 动态组队、自主协作。但当大家真把它放进生产环境后，最难的不会是再多加几个节点，而是给节点之间建立协议，这其实也是 Swarm 的核心。
Graph 只告诉我们谁和谁相连。
Protocol 才要解决：
•Agent 如何声明自己的能力、身份和权限？•一个任务通过什么契约委派，交付物必须带哪些证据？•多个 Agent 对同一事实判断冲突时，如何仲裁？•消息重复、超时、乱序、丢失时，如何保证幂等和恢复？•一个节点失败后，是重试、补偿、降级，还是熔断？•谁可以修改整张图，谁只能在局部范围行动？•token、时间和工具调用预算如何分配？•哪些决策必须由人批准，出了问题由谁解释和负责？
这和分布式系统的发展很像。
当机器只有一台时，我们主要关心算法。机器连成网络后，拓扑当然重要，但真正让互联网、数据库集群和微服务能够工作的，是 TCP/IP、共识算法、消息协议、事务语义、超时重试、幂等和故障恢复。
同样，当 Agent 从一个变成一群，图只是骨架，协议才是神经和规则。
所以我对下一阶段的推测不是“大家会开始画更大的图”，而是：
大家会开始为 Agent 之间的协作定义可执行的契约，并把权限、验证、冲突、成本和责任写进协议。
名字未必真叫 Protocol Engineering。也可能叫 Policy Engineering、Governance Engineering 或 Agent Organization Engineering。
名字嘛，叫什么无所谓，方向大概率不会错。
五、Prompt、Context、Harness、Loop、Graph，到底在递进什么
那么再来温习下之前文章的内容：
Prompt Engineering：控制一次表达
解决“这次要对模型说什么”。它定义目标、约束、格式和判断标准。
Context Engineering：控制一次认知
解决“模型这次能看到什么”。代码、PRD、日志、接口契约、历史决策、样例和失败记录，都属于上下文。
Harness Engineering：控制一次行动
解决“Agent 在什么环境里干活”。工具、权限、沙箱、Skill、hook、测试、文件系统、MCP、审批和观测，都在这一层。
Loop Engineering：控制一段时间
解决“Agent 如何根据反馈持续推进”。触发、执行、验证、重试、记忆、停止和人工升级，组成一个局部闭环。
Graph Engineering：控制一个组织
解决“多个工作单元如何形成结构”。分工、依赖、并行、路由、交接、汇合、局部回退和全局完成条件，都属于图。
Protocol Engineering：控制协作秩序
解决“这些节点如何在不完全可信、可能失败、动态变化的情况下共同工作”。契约、身份、权限、冲突、成本、审计和责任，会成为重点。
这几个概念不是一茬一茬替代，而是一层一层向外扩。
Prompt 和 Context 是 Harness 管理的输入；Harness 支撑每一次 Loop；多个 Loop 和确定性节点被组织成 Graph；Protocol 与治理则约束这些结构如何跨 Agent、跨系统长期协作。
它们递进的本质只有一句话：
我们控制的对象，正在从模型的一次回答，扩展为一个能够持续交付结果的复杂系统。
每出现一个新词，本质上都是因为上一个层次跑起来以后，新的失控变量暴露了。
Prompt 解决表达失控。
Context 解决信息失控。
Harness 解决行动失控。
Loop 解决时间和反馈失控。
Graph 解决依赖和协作失控。
接下来，就轮到权限、冲突、成本和责任失控了。
六、怎样快速适应 AI 时代层出不穷的新名词
新名词只会越来越多。模型厂商要讲差异，工具公司要定义品类，培训机构要卖路线图，一个实践刚有点苗头，很快就会被包装成一门新学科。
还有大佬们要收学费。
我们没必要排斥新词，毕竟我们也可以拿着这些词去忽悠、去要资源。
但别真把自己忽悠进去。看到新词，我一般只做三步。
1. 先找它在解决什么问题
找原始文章、产品文档和真实案例，不要从二手“全景路线图”开始。一个词如果说不清对应的失败场景，大概率只是旧概念换了包装。
2. 再翻译回成熟的软件工程
Graph 可以翻译成工作流、状态机、DAG、消息传递和多 Agent 编排；Loop 可以翻译成反馈控制、重试、评测和停止条件。
翻译完，再看它新增了哪个控制变量：指令、上下文、工具、状态、反馈、依赖、权限，还是成本？没有新增量，就没必要另立一门“学科”。
最近不少新词，本质上是成熟工程领域（软件工程、机械工程、控制工程等）的实践经验，向 AI 场景迁移后的重新命名。所以去温习下以前经验、理论对我们理解AI的新概念很有帮助。
3. 最后跑一个小场景
自己有时间就跑，没时间就看别人跑的效果和结果。
最后的最后
Loop Engineering 还没死。
它只是从整套系统的主角，变成了 Graph 里的局部结构。
Graph Engineering 也不是 AI 时代突然发现了图算法，而是当多个 Agent 真正开始并行工作后，我们终于不得不正视协调、状态、交接和全局验证。
再往下走，市场可能会重新喊热 Swarm Engineering，也可能把下一阶段叫作 Protocol Engineering 等新的“XXX Engineering”。
叫什么并不重要。真正重要的是，它是否暴露并解决了一个此前没有被控制住的 AI 工程问题。
大炮也经历过从狂轰滥炸到精确制导。AI 系统从“能干活”走向“可控地交付结果”，经历这段过程很正常。
判断一个新词有没有价值，不看名字有多新，只看它有没有让 AI 交付变得更稳定、更可控。
