引言：AI写代码越写越累的真相
大家好，我是为什么叫QQ。你是否发现，用AI写代码时，越写越累？很多时候，Agent修改代码十分钟，不仅没修好Bug，反而把原本正常的代码改崩了。这背后的问题，不一定是模型不够聪明，更可能是控制流、状态管理和验证机制出现了根本性缺陷。当前，AI工程界最经典的Agent模式是“Agent Loop”，即给模型一个目标，让它通过“观察-思考-行动”的循环往复来推进任务。这种模式在处理简单任务时非常有效，但当任务复杂度上升，例如开发完整项目或处理复杂业务逻辑时，简陋的Loop实现极易失控，导致Agent陷入死循环或在错误道路上狂奔。
“Agent改了十分钟，不但没修好，还把正常代码改崩了，问题不一定是模型不聪明，更可能是控制流、状态和验证出了问题。”
最近，整个AI工程界为了这一困境吵翻了天，甚至有人高呼“Loop已死，Graph当立”。这场争论的引爆点发生在2026年7月，知名开发者Peter Steinberger在X上发问：“我们还在谈Loop，还是已经转向Graph了？”这句话瞬间引爆了技术圈的焦虑，大家纷纷担心自己是否落后于时代。然而，另一位大佬Hamel Husain随即发表了一篇极具煽动性的文章《Loop Engineering Is Dead Enter Graph Engineering》，但文章正文仅有一个句号，并附带一段乔丹劝人停下来的搞笑视频。这其实是对技术圈“名词通胀”的一次无情嘲讽，揭示了大家对于新概念的盲目追逐往往掩盖了真正的工程问题。
概念辨析：Graph Engineering并非新算法
抛开博眼球的标签，我们需要厘清的是：Graph Engineering并不是一种突然出现的新技术或新算法，它是系统复杂度上升后，对执行编排的一种新概括。Peter Steinberger引爆了讨论，但他并非概念首创者，工作流图、状态机和DAG早已存在。Graph Engineering关注的核心是：当系统中有多个Agent、确定性代码、验证器甚至需要人工审批时，如何将这些组件组织成一个可控制、可审计的执行网络。这与Loop Engineering有本质区别：Loop关注如何让单个Agent持续推进任务，而Graph关注多组件间的协作与编排。
“Graph Engineering真的能拯救我们崩溃的Agent系统吗？... 抛开这些博眼球的标签，多Agent编排、状态持久化、并行和恢复，这些确实是摆在我们面前的真问题。”
实际上，Loop和Graph不是替代关系，而是包含与演进的关系。一个Agent加上确定性代码、测试和人工审批，本身就可以形成一个执行图。Loop可以是节点内部的执行逻辑，也可以是图中的一个环或完整子图。正如Anthropic在《Building Effective Agents》中提到的，路由、并行、编排者-工作者模式等，其实都已经具备了图的结构。因此，我们不应因厌恶新名词而忽视背后的工程挑战，而应理解系统复杂度提升后，对执行编排提出的更高要求。
痛点分析：简陋Loop为何必然失控
为什么很多简陋的Loop实现会失控？核心原因在于以聊天记录为中心的上下文管理方式存在致命缺陷。在最简的Loop实现中，所有的历史记录、工具调用结果、事实和错误都被塞进一个越来越长的对话上下文中。这就像把数据库、日志和业务逻辑全部写在一个TXT文件里，随着任务变长，模型无法区分什么是既定事实，什么是自己的猜测。串行执行效率低下，且一旦某个步骤失败，整个任务可能需从头重来，容错率极低。
“在很多最简的以聊天记录为中心的Loop实现里，所有的历史记录、工具调用结果、事实和错误，全都塞进了一个越来越长的对话上下文里。”
此外，让同一个模型既生成代码又验证代码，极易产生自我偏好和验证盲区。Dale Everett一针见血地指出，许多Agent系统将长串对话当作状态数据库，这是一场灾难。回想调试代码的经历，我们常需翻看几百行对话记录以定位错误，这根本不是工程实践，而是在“看小说”。这种缺乏结构化状态管理的模式，导致错误难以追溯，状态难以持久化，最终使得Agent在复杂任务中迷失方向，无法形成有效的闭环反馈。
工程实践一：状态外置与结构化存储
要做好执行编排，首要原则是把状态外置，绝不再把聊天记录当作数据库。任务的计划、验证过的事实、执行的检查点等，都必须转化为结构化数据存储起来。状态字段应有明确的所有者，模型不能随意覆盖事实数据。这种设计确保了系统状态的确定性和可追溯性，避免了因上下文窗口溢出或模型幻觉导致的状态丢失。
“第一，把状态外置，别再把聊天记录当数据库了，任务的计划、验证过的事实、执行的检查点，这些都要变成结构化的数据存起来。”
在具体实施中，这意味着需要引入独立的状态管理模块。例如，在软件修复场景中，可以使用Claude Code，通过/goal设置硬性完成条件，并利用/loop定期重复工作流。在Cursor中，则可以直接为Agent设置验收标准或创建自定义命令。这些工具的使用，本质上都是在将非结构化的对话转化为结构化的任务状态，从而让Agent的执行过程更加可控和可预测，减少因上下文混乱导致的错误累积。
工程实践二：明确节点契约与验证机制
第二点关键做法是明确节点和边的契约，决定下一步的权力不一定非在模型手中。在涉及权限、预算和不可逆操作时，必须将决策权交给确定性的代码规则或人工审批。这种设计引入了确定性约束，防止模型在敏感操作中产生不可控的副作用。通过定义清晰的输入输出接口，系统能够更精准地控制Agent的行为边界。
“第二，明确节点和边的契约，谁有权决定下一步？不一定非得是模型，涉及权限、预算和不可逆操作时，必须交给确定性的代码规则或者人工审批。”
在实际的动态工作流中，可以编写专门的验证器节点来运行单元测试。例如，当Agent生成代码后，验证器节点自动执行测试套件，只有测试通过才能进入下一步。这种机制将验证过程从模型内部剥离，转为外部确定性代码的执行，极大地提高了结果的可靠性。同时，对于需要人工介入的环节，如代码审查或关键配置修改，通过审批节点确保人类专家的最终控制权，形成人机协同的高效闭环。
工程实践三：谨慎使用并行与循环
第三点建议是小心使用并行和循环。并行虽然能加速执行，但也带来了结果冲突和部分失败的风险，需要复杂的冲突解决机制。对于循环，如果验证失败，绝不能简单地让Agent“再试一次”。回边必须携带具体的失败原因、证据和建议的修改范围，否则Agent会像无头苍蝇一样，在同一个错误上反复撞墙，陷入无效的死循环。
“第三，小心使用并行和循环... 对于循环，如果验证失败，不要简单地让Agent‘再试一次’，回边必须携带具体的失败原因、证据和建议的修改范围。”
这种设计强调了反馈的质量而非数量。在Graph结构中，错误反馈应包含具体的堆栈信息、失败用例和可能的修正方向，指导Agent进行针对性修改。相比之下，简陋的Loop往往只传递“失败”这一模糊信号，导致模型重复尝试相同的错误逻辑。通过提供丰富的上下文反馈，Graph结构能够显著提升Agent的自我修正能力和收敛速度，避免资源浪费。
局限性与风险：Graph并非万能药
尽管Graph Engineering提供了更强大的编排能力，但它无法修复错误的目标、评价标准和外部事实依据。如果系统目标本身存在偏差，或者验证器依赖于同一个有偏见的模型，Graph只会让系统更快、更系统地做错事。Carlos E. Perez指出，局部循环可能高效完成其自身指标，却导致整体目标恶化。这种局部最优与全局最优的冲突，是复杂系统中常见的问题。
“Graph无法修复错误的目标、评价标准和外部事实依据... 如果你的系统目标本身就是偏的，或者验证器依赖的是同一个有偏见的模型，那么Graph只会让你的系统更快、更系统地做错事。”
此外，当前流行的“动态图”趋势，即让模型自行生成工作流和拓扑结构，存在巨大风险。若缺乏足够约束，模型可能生成无限分支，疯狂消耗Token，甚至绕过安全审批。这如同让新手司机设计高速公路，后果不堪设想。因此，动态生成的图必须受到严格的静态约束和安全审查，确保其结构的可控性和安全性，避免陷入不可预测的复杂陷阱。
选型指南：何时从Loop升级到Graph
那么，什么时候该从Loop升级到更复杂的执行图？如果任务短小、探索性强、失败重来成本低，老老实实用Loop即可。但如果任务包含可并行分支、需不同Agent隔离上下文、必须有检查点恢复或需准确审计执行路径，更好的执行编排带来的收益才大于其增加的复杂度。
“什么时候该从Loop升级到更复杂的执行图？如果你的任务很短... 那就老老实实用Loop。但如果你的任务有可以并行的分支... 这时候，更好的执行编排带来的收益才大于它增加的复杂度。”
一个务实的升级路径是：首先为单个Agent设置明确的验收标准、迭代上限和停止条件，观察其收敛能力；若不行，再引入状态外置、独立验证和失败回边；最后才考虑复杂的多Agent编排。不要为了画图而画图，工程的本质是解决问题，而非堆砌复杂度。只有在瓶颈出现时，引入Graph结构才能发挥其真正价值，避免过度工程化。
未来展望：工业级Agent系统的形态
工业级Agent系统绝不会是模型随意狂奔的黑盒，而是一个模型提议、运行时约束的混合体。模型负责生成计划和代码，外层增加可编程的执行引擎，约束节点类型、权限、预算和副作用。这种架构将非确定性能力放入可验证、可控制的工程边界内，是AI编程走向成熟的重要方向。
“一个更稳妥的方向是：模型提议，运行时约束... 把非确定性的能力，放进可验证、可控制的工程边界里。”
Anthropic的Dynamic Workflows已展示这一方向：通过执行JavaScript工作流协调子Agent，支持恢复和并行。我们需要的是可控的智能，而非失控的黑盒。Loop并未死亡，它只是从整个系统退化为系统内的局部结构。当Agent系统简单时，做好Loop；当多节点依赖、审批或局部Loop关系成为瓶颈时，再引入复杂编排。这种分层治理的思路，将是构建稳定、高效AI应用的关键。
“Loop没死，它只是从整个系统，变成了系统里的一个局部结构。当Agent系统还很简单时，做好Loop；当多个节点、依赖、审批或者局部Loop之间的关系成为瓶颈时，再开始做更复杂的执行编排。”