文 | 智讯智库，作者 | 施展
Open Claw 创造者 Peter Steinberger 在 X 上问了一句：" 我们还在谈 Loop，还是已经转向 Graph 了？" 截至 7 月 28 日，这条帖子获得约 307 万次浏览 [ 1 ] 。仅仅只在一个多月前，正是他用 " 不要再亲自提示 Coding Agent，而要设计能够提示它的循环 " 这句话，帮 Loop Engineering 走红 [ 2 ] 。
同一天，拥有 20 年经验、曾在 Airbnb 和 GitHub 工作的机器学习工程师 Hamel Husain，发布了一篇题为《Loop Engineering Is Dead.Enter Graph Engineering》的调侃文章。正文只有一张写着 "Stop it" 的动图，却也获得了约 68 万次浏览。 [ 3 ]
Loop 解决不了的新问题？概念是新瓶、技术是旧酒
Loop 并没有真正过时，实际发生的变化是：当 Coding Agent 从一次回答走向连续执行，又从单个 Agent 走向多个执行单元协作时，工程师要处理的问题从 " 怎样让它继续做 " 扩展到了 " 这些工作该怎样连接 "。
Loop 解决的是：一个 Agent 如何根据环境反馈不断检查、修改，再次尝试。
例如代码没有通过测试，就读取报错、修改代码、重新运行，直到通过验收或触发停止条件。
Loop 让一个 Agent 可以自己多干一会儿，但当 Agent 真的可以连续工作，新的问题又出现了：
研究需求的 Agent、写代码的 Agent、做测试的 Agent，谁先开始？哪些工作可以同时进行？测试失败后应该回到哪里？它们怎样看到同一份需求、研究笔记和测试结果？如果审查者不同意实现者，听谁的？
一个 Loop 只有一条主要路径，复杂任务却开始出现分工、并行、回退和交接。这个时候，工程师不再只是设计 " 怎样重复 "，还要设计 " 这些重复工作的单元怎样连接 "。
因此 Graph 实际是一个任务的编排系统，管理多个工作单元之间的连接、共享状态与选择路径。
一个 Graph 通常至少包含四样东西：
黄仁勋在 Startup School 2026 大会上表达了类似的观点，当底层实现越来越多地被 Agent 自动化，人类的核心价值将从 " 亲手完成每个步骤 " 转向 " 设计系统、明确约束、组织信息流，并以细粒度方式控制 Agent"，Graph Engineering 本质上就是设计一个可观察、可路由、可约束、可局部修正的执行系统。
尽管 "Graph Engineering" 最近才成为热词，但状态机、工作流引擎、DAG 调度、任务队列和知识图谱早已存在。新变化不在于发明了 Graph 这种编排模式，而在于今天的节点可以放进能够理解目标、使用工具并自行循环的 Agent。
2024 年进入 ACL 的 ChatDev，把软件开发组织成由不同角色参与的 " 软件公司 "，通过通信完成设计、编码和测试；同年进入 ICLR 的 MetaGPT，则把标准作业流程写入多 Agent 协作框架。 [ 4 ] [ 5 ] 它们当时不叫 Graph Engineering，却已经在实践角色分工、阶段交接和共享产物。
2024 年 12 月，Anthropic 在《Building Effective Agents》中总结了提示链、路由、并行、编排者 / 工作者和评价者 / 优化者等常见结构。把这些结构画出来，得到的正是不同形状的执行图。 [ 6 ]
学术研究走得更早，GPTSwarm 的论文《Language Agents as Optimizable Graphs》发表于 ICML2024：节点负责处理信息或调用模型，边负责在 Agent 之间传递信息；研究者还尝试共同优化节点中的 Prompt 和节点之间的连接。 [ 7 ]
"Graph Engineering" 这一精确说法也并非 2026 年才出现。
2025 年 5 月，Anthony Alcaraz 在 LinkedIn 写道，构建 Agentic AI 最终是一种 Graph Engineering：横向的工作流图记录 Agent 处于多步骤流程的哪一环，以及允许哪些状态转移；纵向的知识图谱则组织实体和关系，用于检索、事实验证与约束检查。 [ 8 ]
从 Prompt 到 Graph，AI Coding 仍在向更高复杂度项目进化
随着对 AI coding 使用的深入，处理任务的复杂度也越来越高，不能只靠 LLM 单打独斗，而是需要通过更多结构化的工程手段（上下文、环境、反馈循环、多 Agent 拓扑）来不断拓宽 AI 的自治边界。
Graph Engineering 听起来像需要先学习一套复杂框架，实际使用中未必如此。2026 年 7 月 25 日，OpenAI Harness Engineering 研究员 Alex Kotliarskyi 在 X 上给出了一份只有两步的教程：先画一张 Graph，画在纸上也可以；再把图交给 Codex，让它编写并运行实现该工作流的脚本。" 没有第三步。" [ 11 ]
这些产品更接近 " 运行时生成 Graph"：用户给出目标，Agent 临时决定怎样拆解和协作。LangGraph 和 GoogleADK 则允许开发者把关键节点、边、状态和路由显式写出来。
我们更熟悉的Kimi Agent Swarm与Coze Studio，则把类似思想包装成普通用户可以直接调用的 "AI 组织 "。
Graph 更常用于复杂任务，但 " 复杂 " 不只是步骤多。真正决定它是否合适的，是任务结构：
例如，一个需要调研需求、选择技术方案、实现前后端、运行测试并通过安全审查的产品，适合组织成 Graph。研究与界面原型可以并行，测试失败可以回到实现节点，资料不足可以退回研究节点。
但修改一个按钮颜色、解释一段代码或生成一个简单页面，通常交给一个 Agent 更快。即使任务很难，如果每一步都严格依赖上一步、所有参与者必须共享完整上下文，也未必适合 Graph，不必为了 " 组队 " 而组队。
2026 年 7 月 24 日，《Nature Machine Intelligence》发表了一项覆盖 260 种配置、六类基准、五种架构和三家模型系列的研究。结果并不支持 "Agent 越多越好 "：在可拆分的金融任务中，多 Agent 相对单 Agent 最高提升 80.8%；在顺序依赖很强的 Plan Craft 规划任务中，最高下降 70%；在 SWE-benchVerified 上，四类多 Agent 架构均出现 1.3% 至 12.8% 的下降 [ 19 ] 。关键变量不是抽象的 " 复杂度 "，而是任务能否被有效拆分，以及协调成本会不会超过任务本身。
与此同时，Graph 也会面临成本的风险：每增加一个 Agent，系统都要准备上下文、调用模型、传递结果并进行汇总。如果职责划分不清，多个 Agent 可能重复搜索同一资料、同时修改相同文件，甚至用大量 Token 讨论彼此制造的问题。Graph 的目标不是召集尽可能多的 Agent，而是用尽可能少的节点稳定完成任务。
如 Anthropic 的 Research 使用一个主 Agent 制订计划，再创建多个子 Agent 并行搜索，最后交给引用检查 Agent 处理来源。内部评测中，这套架构在适合广度搜索的任务上比单 Agent 高 90.2%；代价同样明显：普通 Agent 的 Token 消耗约为聊天模式的 4 倍，多 Agent 系统约为 15 倍。Anthropic 也指出，大量顺序依赖、要求所有 Agent 共享相同上下文的任务，目前并不适合这种架构。 [ 20 ]
Graph Engineering 并没有宣判 Loop 过时。恰恰相反，Graph 的每个节点都可能运行自己的 Loop。它新增的工程问题是：哪些 Loop 应该存在，它们怎样交接，谁能修改共享状态，失败后回到哪里，以及什么时候必须停下来。
这也是从 Prompt 到 Graph 的真正递进：工程师的注意力从 " 怎样写一句更好的指令 "，逐步扩展到 " 怎样准备信息、提供工具、建立反馈，再把多个执行单元组织成一个可观察、可恢复、可控制成本的系统 "。
参考资料：
[ 1 ] Steinberger P. [ Are we still talking loops or did we shift to graphs yet? ] [ EB/OL ] . [ 2026-07-29 ] .
[ 2 ] Osmani A. Loop Engineering [ EB/OL ] . ( 2026-06-08 ) [ 2026-07-29 ] .
[ 3 ] Husain H. Loop Engineering Is Dead. Enter Graph Engineering [ EB/OL ] . [ 2026-07-29 ] .
[ 4 ] Qian C, Liu W, Liu H, et al. ChatDev: Communicative Agents for Software Development [ C/OL ] //Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics ( Volume 1: Long Papers ) . Bangkok: Association for Computational Linguistics, 2024: 15174-15186 [ 2026-07-29 ] .
[ 5 ] Hong S, Zhuge M, Chen J, et al. MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework [ C/OL ] //International Conference on Learning Representations. 2024 [ 2026-07-29 ] .
[ 6 ] Erik S, Zhang B. Building effective agents [ EB/OL ] . ( 2024-12-19 ) [ 2026-07-29 ] .
[ 7 ] Zhuge M, Wang W, Kirsch L, et al. GPTSwarm: Language Agents as Optimizable Graphs [ C/OL ] //Proceedings of the 41st International Conference on Machine Learning. Proceedings of Machine Learning Research, 2024, 235: 62743-62767 [ 2026-07-29 ] .
[ 8 ] Alcaraz A. [ Building an agentic AI is ultimately an act of graph engineering ] [ EB/OL ] . [ 2026-07-29 ] .
[ 9 ] LangChain Inc. LangGraph overview [ EB/OL ] . [ 2026-07-29 ] .
[ 10 ] Klopfenstein T, Maddula S K. Build reliable multi-agent applications with DK Go 2.0. Discover our new graph-based workflow engine, built-in human-in-the-loop, and dynamic orchestration [ EB/OL ] . ( 2026-06-30 ) [ 2026-07-29 ] .
[ 11 ] Kotliarskyi A. [ How to graph-max with Codex and 5.6 Sol ] [ EB/OL ] . ( 2026-07-25 ) [ 2026-07-29 ] .
[ 12 ] OpenAI. Subagents [ EB/OL ] . [ 2026-07-29 ] .
[ 13 ] Anthropic. Create custom subagents [ EB/OL ] . [ 2026-07-29 ] .
[ 14 ] Anthropic. Orchestrate teams of Claude Code sessions [ EB/OL ] . [ 2026-07-29 ] .
[ 15 ] Cursor. Subagents, Skills, and Image Generation [ EB/OL ] . ( 2026-01-22 ) [ 2026-07-29 ] .
[ 16 ] Cursor. New Coding Model and Agent Interface [ EB/OL ] . ( 2025-10-29 ) [ 2026-07-29 ] .
[ 17 ] Moonshot AI. Agent Swarm 能力 [ EB/OL ] . [ 2026-07-29 ] .
[ 18 ] Coze Studio. Add new workflow node types ( backend ) [ EB/OL ] . ( 2025-09-12 ) [ 2026-07-29 ] .
[ 19 ] Kim Y, Gu K, Park C, et al. Capable language models can outgrow the benefits of collaboration [ J/OL ] . Nature Machine Intelligence, 2026, 8: 1157-1172 [ 2026-07-29 ] .
[ 20 ] Hadfield J, Zhang B, Lien K, et al. How we built our multi-agent research system [ EB/OL ] . ( 2025-06-13 ) [ 2026-07-29 ] .
