大家好，我是为什么叫QQ。为什么你用AI写代码，越写越累？Agent改了十分钟，不但没修好，还把正常代码改崩了。问题不一定是模型不聪明，更可能是控制流、状态和验证出了问题。现在大家都在用Agent，最经典的模式就是“Agent Loop”，也就是给模型一个目标，让它自己观察、思考、行动，循环往复。这招在做简单任务时很管用，但当任务变长，比如你要让它开发一个完整的项目，或者处理复杂的业务逻辑时，很多简陋的Loop实现就容易失控。Agent开始陷入死循环，或者在错误的道路上狂奔。
就在最近，整个AI工程界为了这个问题吵翻了天。有人甚至高呼：Loop已死，Graph当立！这到底是怎么回事？Graph Engineering真的能拯救我们崩溃的Agent系统吗？这场风波的引爆点，发生在2026年7月。知名开发者Peter Steinberger在X上发了一句灵魂拷问：“我们还在谈Loop，还是已经转向Graph了？”这句话就像把曼妥思扔进了可乐里，瞬间引爆了技术圈的焦虑。大家开始疯狂讨论，是不是自己又落后于时代了。
更有意思的是，另一位大佬Hamel Husain马上发了一篇文章，标题极具煽动性：《Loop Engineering Is Dead Enter Graph Engineering》。结果你点进去一看，文章里只有一个句号，还有一段乔丹劝你停下来、找点帮助的搞笑视频。这其实是对技术圈“名词通胀”的一次无情嘲讽。每隔几个月，我们就会发明一个新词汇：有Prompt Engineering、Context Engineering、Loop Engineering，现在又来了个Graph Engineering。但这里要说清楚：Peter引爆了这轮讨论，但他不是概念首创者。工作流图、状态机和DAG更早就已存在。
抛开这些博眼球的标签，多Agent编排、状态持久化、并行和恢复，这些确实是摆在我们面前的真问题。我们不能因为讨厌新名词，就无视了背后的工程挑战。到底什么是Graph Engineering？它并不是一种突然出现的新算法。说白了，它是系统复杂度上升后，对执行编排的一种新概括。Loop关注的是怎么让一个Agent持续推进任务，而Graph关注的是，当系统里有多个Agent、有确定性的代码、有验证器，甚至还需要人工审批时，你怎么把它们组织成一个可控制、可审计的执行网络。
它们不是谁替代谁的关系。一个Agent加上确定性代码、测试和人工审批，也可以形成执行图。Loop可能是节点内部的执行逻辑，也可能是图中的一个环或完整子图。就像Anthropic在《Building Effective Agents》里提到的，路由、并行、编排者-工作者模式，这些其实都已经具备了图的结构。那为什么很多简陋的Loop会失控？那为什么我们需要更好的执行编排？
在很多最简的、以聊天记录为中心的Loop实现里，所有的历史记录、工具调用结果、事实和错误，全都塞进了一个越来越长的对话上下文里。这就好比你把数据库、日志和业务逻辑全写在一个TXT文件里。任务一长，模型就分不清什么是事实，什么是它自己猜的。而且，串行执行太慢了。如果一个步骤失败，整个任务可能得从头再来。让同一个模型既生成又验证，容易出现自我偏好和验证盲区。
Dale Everett就一针见血地指出，很多Agent系统把一长串对话当作状态数据库，这简直是一场灾难。你回想一下，你调试代码的时候，是不是经常得翻看几百行的对话记录，去找出到底哪一步出了错？这根本不是在做工程，而是在看小说。怎样做好执行编排？如果用Graph Engineering来概括这轮讨论，比较有共识的工程做法包括：第一，把状态外置。别再把聊天记录当数据库了，任务的计划、验证过的事实、执行的检查点，这些都要变成结构化的数据存起来。状态字段应该有明确的所有者，模型不能随便覆盖事实。
第二，明确节点和边的契约。谁有权决定下一步？不一定非得是模型。涉及权限、预算和不可逆操作时，必须交给确定性的代码规则或者人工审批。比如你用Claude Code做软件修复，模型负责写代码，但你可以通过/goal设置硬性完成条件，并用/loop定期重复工作流。使用Cursor时，则可以直接给Agent设置验收标准，或者创建自定义命令。在实际的动态工作流里，你甚至可以写一个验证器节点，专门跑单元测试。
第三，小心使用并行和循环。并行能加快速度，但也带来了结果冲突和部分失败。而对于循环，如果验证失败，不要简单地让Agent“再试一次”。回边必须携带具体的失败原因、证据和建议的修改范围，不然，它就会像个无头苍蝇一样，在同一个错误上撞得头破血流。听到这里，你可能会觉得，Graph Engineering简直是万能药。只要我把节点画得足够细，箭头连得足够复杂，Agent就能无所不能。
但这里有个很离谱的地方：Graph无法修复错误的目标、评价标准和外部事实依据。如果你的系统目标本身就是偏的，或者验证器依赖的是同一个有偏见的模型，那么Graph只会让你的系统更快、更系统地做错事。就像Carlos E. Perez指出的，局部循环可能高效完成自己的指标，却让整体目标恶化。现在还有一种趋势，叫“动态图”，就是让模型自己去生成工作流和拓扑结构。这听起来很酷，但如果缺少足够的约束，它可能会生成无限分支，疯狂消耗你的Token，甚至绕过安全审批。这就好比你让一个新手司机去设计高速公路，后果不堪设想。
所以，真正需要认清的是，不要盲目追逐新概念。什么时候该从Loop升级到更复杂的执行图？如果你的任务很短、探索性强、失败了重来成本不高，那就老老实实用Loop。但如果你的任务有可以并行的分支、需要不同Agent隔离上下文、必须有检查点恢复，或者需要准确审计执行路径，这时候，更好的执行编排带来的收益才大于它增加的复杂度。一个务实的做法是：先给单个Agent设置明确的验收标准、迭代上限和停止条件，看看它能不能收敛。如果不能，再把状态外置，加上独立验证和失败回边，最后才考虑复杂编排。不要为了画图而画图，工程的本质是解决问题，而不是堆砌复杂度。
工业级Agent系统会是什么样？绝对不会是模型在里面随意狂奔。一个更稳妥的方向是：模型提议，运行时约束。模型负责生成计划和代码，外层增加可编程的执行引擎，约束节点类型、权限、预算和副作用。把非确定性的能力，放进可验证、可控制的工程边界里。这可能是AI编程走向成熟的重要方向之一。Anthropic的Dynamic Workflows已经展示了这个方向：执行JavaScript工作流，协调子Agent，支持恢复和并行。我们需要的是可控的智能，而不是失控的黑盒。
所以，Loop没死，它只是从整个系统，变成了系统里的一个局部结构。当Agent系统还很简单时，做好Loop；当多个节点、依赖、审批或者局部Loop之间的关系成为瓶颈时，再开始做更复杂的执行编排。你的Agent项目卡在哪个阶段了？把你的痛点打在评论区。如果今天的视频对你有启发，别忘了点赞、投币、收藏，还有关注。我是为什么叫QQ，下期再见。