一个月，Loop就过时了？
我第一反应是：又来了。
前脚还在聊Loop Engineering，后脚就有人宣布Loop已死，Graph Engineering上位。Agent圈造新词的速度，已经快赶上模型发版了。
我先顺着X把这句话往回找。
今年6月，Claude Code负责人Boris Cherny在访谈里说，自己现在的工作就是“写Loop”。Peter Steinberger也跟着发了一条：别只顾着给Agent写Prompt，要开始设计那些驱动Agent的Loop。
到了7月18日，Peter问了一句：我们还在聊Loop，还是已经转向Graph了？
四个多小时后，Hamel Husain把它写成了一个很适合转发的标题：
“Loop Engineering Is Dead. Enter Graph Engineering.”
注意，Peter原话只是问句。Loop“死了”，是后来加上去的。
如果写到这里就收手，这篇文章会很好写：又是一轮X造词，别当真。
可我继续查了下去，事情就没那么简单了。
Google真的把Graph做进了ADK 2.0；OpenAI真的在用任务DAG调度Codex；Anthropic虽然很少说Graph，却已经让JavaScript Workflow接管分支、并行和状态。
也就是说，这个标题说得太满，却没有完全说空。
Loop和Graph，根本不在抢同一把椅子
先拿一个最普通的Coding Agent来说。
你让它修一个Bug。它先搜代码，改一版，跑测试；测试报错，再读错误、继续改，直到测试通过或者预算耗尽。
这就是Loop。每一步拿到的新结果，都会影响下一步怎么走。路径很难提前写死。
Graph处理的是另一类问题。
比如一个需求要先经过方案确认，前后端可以并行，支付改动必须多一道安全Review，测试失败要退回开发，部署生产前还要等人批准。这里已经不只是“Agent下一步想做什么”，还涉及谁依赖谁、什么时候能开始、失败往哪退、哪些状态必须保存。
这些关系画出来，就是Graph。
而且Graph的一个节点里，完全可以放一个正在跑Loop的Agent；Graph自己也可以有回边。只有DAG不允许循环，Graph并不天然排斥Loop。
所以问题从来不是二选一。
真正需要选的是：哪些下一步交给Agent临场判断，哪些下一步根本不该让模型猜。
三家公司都在分层，只是分法不同
它一边在讲Loop，一边已经搭出了很明显的Graph结构。
Claude Research里，Lead Researcher会先拆问题，再派出多个Subagent并行搜索。每个Subagent都在自己的工具调用Loop里查资料、看结果、换方向；信息汇总回来以后，Lead Researcher再决定继续开新任务，还是交给Citation Agent整理引用。
Anthropic把这叫Orchestrator-worker，不叫Graph。名字不同，分叉、并行、汇合和退出条件都在。
那个16个Claude一起写C编译器的实验更直接。近2000个Claude Code会话，Harness里真的有一段while true：一个会话结束，马上启动下一个。
但那篇复盘里，最值得看的并不是这行循环。真正麻烦的是测试能不能给出可靠反馈，任务会不会互相踩文件，Git冲突怎么处理，Agent怎么知道前一个人干到了哪里。
Loop只负责“继续干”。让它不至于一直瞎干的，是外面的环境和验证。
今年5月，Anthropic又上线了Dynamic Workflows。Claude先生成一段JavaScript编排脚本，真正执行时，由独立Runtime保存中间状态，处理循环、分支、并行和汇合。复杂流程不再全靠对话Context记着。
这已经很像Graph了，只是Anthropic更愿意让代码来表达，而不是先给开发者一块画布。
Codex的底层一直是Agent Loop：模型推理、调用工具、拿回结果、继续推理，直到完成。OpenAI今年1月拆解Codex内部机制时，直接把它称为核心逻辑。
可当很多Codex同时工作，光有Loop就不够了。人盯着几个并行会话，很快就会忘记谁卡在哪、谁在等谁。
OpenAI内部用的Symphony，做法是把Linear任务板变成控制面。Ticket状态构成状态机，任务依赖组成DAG，没有被阻塞的任务可以并行启动；每个任务里面，再放一个Codex，让它自己读代码、改文件、跑测试，循环到完成或进入人工Review。
外面管任务关系，里面保留Agent的自由度。
OpenAI的选择也很说明问题：它后来不再把Agent当成刚性状态机节点，而是用外层流程管理任务，把目标、工具和上下文交给Agent自己处理。就连拖拽节点的Agent Builder也将在今年11月底停止服务，代码型Workflow转向Agents SDK。
Graph这个抽象有用，不代表画节点的产品一定好用，更不代表要把Agent重新做成传统流程机器人。
再看Google。ADK 2.0直接加入Graph Workflow Runtime，Agent、函数和工具都可以成为节点，调度器负责分支、并行、循环、重试、暂停审批和进程恢复。Google甚至写了一句：“A graph is an agent.”
但同一份文档里，Google没有删掉Loop。
它同时保留Graph Workflow、直接用while和条件编写的Dynamic Workflow，以及Sequential、Parallel、Loop这些常用模板。官方还提醒，路径变化太多时，硬塞进静态Graph反而会变笨重。
Google自己的AlphaEvolve也是这么搭的：生成程序、自动评估、保留好结果，然后继续生成。
图负责把可能走的路说清楚，循环负责真的沿着反馈往前走。
如果让我现在搭一套
我不会先问“该用Loop还是Graph”。我会先看，这个任务里有什么东西不能靠模型记忆。
如果是开放式研究、修Bug、探索一个陌生代码库，下一步取决于刚拿到的证据，我会先上Loop。但这个Loop至少要有真实的验证器、预算和退出条件。没有测试、评分或明确完成标准，跑得久不代表做得好。
如果流程里出现了资金、权限、人工审批、跨天等待、多个任务依赖，或者失败后必须从中间恢复，我会把这些状态拉出Prompt，放进代码或Workflow。需要模型判断的地方，再把Agent放进去。
至于多Agent，我只会在任务确实能拆开并行时用。Google测了180种Agent配置，也发现连续依赖很强的任务上，多Agent反而可能拖后腿。
所以，Loop过时了吗？没有。
Graph是什么？它也不是更高级的Loop。它只是承认一件事：一个Agent系统里，有些下一步应该让模型探索，有些下一步必须由系统说了算。
这轮资料让我更确定一件事：给Agent一个好目标，再让它不断行动、检查和修正，只解决了“怎么继续干”。调度、权限、恢复和停止，不能全塞进Context里等模型自己记住。
下一步我想真搭两版试试：同一个长任务，一版只用Loop，一版把审批、重试和恢复拉到外层。到底哪版更稳、哪版更贵，不靠名词判断，跑完再说。