Related articles
文 | 智讯智库，作者 | 施展
Open Claw 创造者 Peter Steinberger 在 X 上问了一句：「我们还在谈 Loop，还是已经转向 Graph 了？」 截至 7 月 28 日，这条帖子获得约 307 万次浏览 [1]。仅仅只在一个多月前，正是他用 「不要再亲自提示 Coding Agent，而要设计能够提示它的循环」 这句话，帮 Loop Engineering 走红 [2]。
短短六周，Loop 就被宣布 「过时」 了。
同一天，拥有 20 年经验、曾在 Airbnb 和 GitHub 工作的机器学习工程师 Hamel Husain，发布了一篇题为 《Loop Engineering Is Dead.Enter Graph Engineering》 的调侃文章。正文只有一张写着 「Stop it」 的动图，却也获得了约 68 万次浏览。[3]
Graph Engineering 几乎在一个周末里从一句半开玩笑的提问，变成了新的 AICoding 热词。
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]
到 2026 年，框架层已经把这套思想做得更加明确。LangGraph 将节点、边、共享状态、持久化执行和人工介入作为核心能力，允许确定性代码与模型驱动步骤存在于同一张图中 [9]。Google 在 ADK2.0 中进一步推出 Graph-first 的工作流引擎：开发者可以定义节点和边，由调度器负责并发、状态持久化、暂停、恢复、重试和人工审批 [10]。
从 Prompt 到 Graph，AI Coding 仍在向更高复杂度项目进化
随着对 AI coding 使用的深入，处理任务的复杂度也越来越高，不能只靠 LLM 单打独斗，而是需要通过更多结构化的工程手段（上下文、环境、反馈循环、多 Agent 拓扑） 来不断拓宽 AI 的自治边界。
主流 Coding Agent 已经在用 Graph，只是没有把图画出来
Graph Engineering 听起来像需要先学习一套复杂框架，实际使用中未必如此。2026 年 7 月 25 日，OpenAI Harness Engineering 研究员 Alex Kotliarskyi 在 X 上给出了一份只有两步的教程：先画一张 Graph，画在纸上也可以；再把图交给 Codex，让它编写并运行实现该工作流的脚本。「没有第三步。」[11]
越来越多 Coding Agent 已经把任务拆解、子 Agent、并行执行、隔离工作区、失败重试和结果汇总做进产品，只是不会始终把底层结构展示成流程图。
这些产品更接近 「运行时生成 Graph」：用户给出目标，Agent 临时决定怎样拆解和协作。LangGraph 和 GoogleADK 则允许开发者把关键节点、边、状态和路由显式写出来。
我们更熟悉的 Kimi Agent Swarm 与 Coze Studio，则把类似思想包装成普通用户可以直接调用的 「AI 组织」。
Graph 适合可拆分、可验收的复杂任务，而不是所有复杂任务
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 ADK 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].
