Loop才火了六周，AI Coding为什么又开始谈图？

文 | 智讯智库，作者 | 施展 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]。关键变量不是抽象的“复杂度”