本文来自微信公众号： 智讯智库 ，作者：施展
Graph Engineering不是Loop的替代品，而是AI Coding从“单个Agent反复执行”走向“多个节点协同工作”的下一层工程问题，本文将从以下几个视角拆解Graph Engineering： Peter Steinberger再次带火了新概念，但Graph是新瓶装旧酒，其在Agent时代有了新的定义和意义。 从Prompt到Graph，核心逻辑是AI Coding仍在向更高复杂度项目进化。 主流Coding Agent已经在用Graph，只是多数没有把图画出来。 Graph更常用于复杂任务，但“复杂”不只是步骤多，需要任务能够独立拆分、存在分支或回退、中间状态值得保存、结果能够验收、协作收益高于协调成本。
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如何根据环境反馈不断检查、修改，再次尝试。（详见7月10日智讯智库文章《还在写Prompt？AI编程进入Loop新阶段》）
例如代码没有通过测试，就读取报错、修改代码、重新运行，直到通过验收或触发停止条件。
Loop让一个Agent可以自己多干一会儿，但当Agent真的可以连续工作，新的问题又出现了：
研究需求的Agent、写代码的Agent、做测试的Agent，谁先开始？哪些工作可以同时进行？测试失败后应该回到哪里？它们怎样看到同一份需求、研究笔记和测试结果？如果审查者不同意实现者，听谁的？
一个Loop只有一条主要路径，复杂任务却开始出现分工、并行、回退和交接。这个时候，工程师不再只是设计“怎样重复”，还要设计“这些重复工作的单元怎样连接”。
因此Graph实际是一个任务的编排系统，管理多个工作单元之间的连接、共享状态与选择路径。
一个Graph通常至少包含四样东西：
节点（Node）：承担某种职责的工作单元。它可以是一段确定性代码、一次模型调用、一个工具，也可以是一个会自行循环的完整Agent。
边（Edge）：说明节点之间如何交接。它不只是“先做A，再做B”，还能表达并行、条件、失败、重试和回退。
共享状态（State）：像项目的公共工作台，保存需求、研究笔记、代码版本、测试结果和审查结论。
路由规则（Routing）：决定下一步去哪里。例如“测试通过就交付；测试失败就回到实现节点；信息不足就回到研究节点”。
黄仁勋在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的自治边界。
Prompt阶段：你输入“生成网页”，它凭预训练记忆盲猜。就像给实习生一句话命令，写出来的代码全凭运气。
Context阶段（带入项目）：把技术栈、设计稿和API文档塞给它。有了项目上下文记忆，写出来的代码终于不再“鸡同鸭讲”。
Harness阶段（给到工具）：接入终端、沙箱、Git和MCP。AI拥有了行动能力，从“写代码的文员”进化成能去运行和测试的CodingAgent。
Loop阶段（自我闭环）：引入检查和控制逻辑。报错了不用人插手，它自己看Log、改代码、再跑测试，完成了自我纠错（Self-Correction）。
Graph阶段（多Agent组队）：面对大项目，拆解成专业节点。如研究节点负责调研写笔记，把状态通过路由传给实现节点去落地，实现多Agent或Agent与人的标准化协同。
主流Coding Agent已经在用Graph
只是没有把图画出来
Graph Engineering听起来像需要先学习一套复杂框架，实际使用中未必如此。2026年7月25日，OpenAI Harness Engineering研究员Alex Kotliarskyi在X上给出了一份只有两步的教程：先画一张Graph，画在纸上也可以；再把图交给Codex，让它编写并运行实现该工作流的脚本。“没有第三步。”[11]
越来越多Coding Agent已经把任务拆解、子Agent、并行执行、隔离工作区、失败重试和结果汇总做进产品，只是不会始终把底层结构展示成流程图。
OpenAI Codex可以让主Agent把探索、测试、日志分析等独立工作委派给多个子Agent，并行完成后返回摘要。官方也提醒，并行更适合读密集型任务；多个Agent同时修改代码会增加冲突和协调成本[12]。对用户而言，这可能只是一句“分别研究、实现和审查，最后汇总”；对系统而言，已经临时形成了一张“主节点—工作节点—汇总节点”的执行图。
Claude Code的Subagents各自拥有独立上下文，可以承担代码审查、调试和资料分析等专门任务[13]。实验性的AgentTeams又加入团队负责人、共享任务列表、任务依赖和成员间通信：前置任务未完成时，下游任务不能领取；成员可以自行认领任务并交换结果[14]。
Cursor在2.4版本中加入默认与自定义Subagents，让它们分别处理代码库研究、终端命令和并行工作流；每个子Agent使用独立上下文[15]。Cursor2.0还允许同一Prompt最多启动八个Agent，在独立GitWorktree或远程机器中尝试不同方案，避免文件直接冲突[16]。
这些产品更接近“运行时生成Graph”：用户给出目标，Agent临时决定怎样拆解和协作。LangGraph和GoogleADK则允许开发者把关键节点、边、状态和路由显式写出来。
我们更熟悉的Kimi Agent Swarm与Coze Studio，则把类似思想包装成普通用户可以直接调用的“AI组织”。
Kimi Agent Swarm走的是“运行时动态成图”：面对适合拆分的复杂任务，主Agent临时决定创建哪些子Agent、哪些任务并行，以及结果怎样汇总。官方称它最多可协调300个子Agent，单个任务可完成4,000次以上工具调用，适合大规模搜索、长文写作和批处理[17]。
Coze Studio则把图直接摆在用户面前：开发者可以在可视化画布上连接模型、插件、代码和子工作流等节点，再用条件分支与变量映射规定执行路径。Coze Studio的官方开源文档明确将这套工作流描述为同时包含控制流和数据流的有向无环图（DAG）[18]。
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].
本内容由作者授权发布，观点仅代表作者本人，不代表虎嗅立场。如对本稿件有异议或投诉，请联系 tougao@huxiu.com。
本文来自虎嗅，原文链接：https://www.huxiu.com/article/4879987.html?f=wyxwapp
配资门户提示：文章来自网络，不代表本站观点。
