「每一步都合理,项目却做着做着失控了。」——这是最近刷屏的一张漫画的标题:一个小人站在两根摇杆之间,左边写着 Loop,右边写着 Graph,一脸茫然。这篇想说的是:小人茫然的原因,不是他不知道该选哪根摇杆,而是这两根摇杆根本不是两个选项。它们是同一根轴上的两个刻度。
这篇回答三个问题:为什么「每一步都聪明,整体却失控」在数学上是必然的;Loop 和 Graph 到底在争什么(剧透:争的是”下一步由谁决定”,不是”代码长什么样”);以及 2024–2026 年的论文如何给出第三条路——结构不是人写的,也不是模型即兴的,是搜索出来的。
它是《Agent 工程七问》的续篇。那篇的结论是:七个工程难题共享一个答案——把真相移到模型外面。这篇处理它遗留的最后一块真相,也是最烫手的一块:控制流的真相,放在模型里,还是放在代码里?
0. 先把两个词说人话
争论双方都爱用框架名互扔(OpenAI 的 Agents SDK、Claude Code 是 Loop 派;LangGraph 是 Graph 派),先把框架剥掉,两种架构各自只剩几行伪代码。
Loop(循环派):整个 agent 就是一个 while 循环,每一轮把完整历史喂给模型,模型自己决定下一步干什么、什么时候结束。这个形态的源头是 2022 年的 ReAct(Reason + Act):
while not done:
thought, action = LLM(history) # 下一步干什么?模型说了算
observation = execute(action)
history += [thought, action, observation]
done = LLM_says_done(history) # 什么时候结束?也是模型说了算Graph(图派):人先把任务拆成节点(每个节点是一次模型调用或一次工具执行),用边写死”谁做完了轮到谁”,条件分支也显式画出来。模型在节点内部发挥,但节点之间怎么走,由代码决定:
graph.add_node("检索", retrieve)
graph.add_node("起草", draft)
graph.add_node("审校", review)
graph.add_edge("检索", "起草")
graph.add_conditional_edge("审校", # 分支条件显式写在代码里
lambda s: "起草" if s.rejected else END) # 打回重写,还是结束注意一个容易被吵架双方都忽略的事实:Graph 里可以有环(上面”审校→起草”就是),Loop 展开之后就是一张图(每一轮是一个节点,边是”下一轮”)。所以争论的焦点从来不是拓扑形状——两边的拓扑可以画得一模一样。焦点在别处。
1. 换一副眼镜:这是两种调度器,不是两种拓扑
2026 年 4 月的一篇立场论文《From Agent Loops to Structured Graphs: A Scheduler-Theoretic Framework for LLM Agent Execution》提供了我见过最干净的重述。它说:别看拓扑,看调度器。
任何 agent 系统,本质上都在反复回答同一个问题:“下一个执行单元是什么?” 回答这个问题的组件,操作系统里叫调度器。用这副眼镜看:
- Loop 是一个退化的调度器:就绪队列里永远只有一个单元,选择策略是”问模型”——一个不可检查的策略(opaque policy)。你无法在运行前枚举它可能走的路径,也无法在运行后解释它为什么这么走,因为策略本身住在千亿参数里。
- Graph 是一个显式的调度器:就绪队列和选择策略都写在代码里,可以静态检查、可以并行调度、可以在任意一步回答”接下来最多可能发生哪些事”。
这一步重述的价值在于,它把”Loop vs Graph”从二元对立变成了连续谱——同一根轴,轴的名字叫:
控制流的真相放在哪里?
模型权重里 ←──────────────────────────→ 代码里
(不可检查,随模型变强而变强) (可检查,随模型变强而不变)
Loop 带计划文件的 Loop 动态子图 静态 Graph实践中没有系统站在纯粹的端点上。Claude Code 是 Loop 派,但它让模型维护一个任务清单文件——那就是往右挪了一格:把”接下来做什么”的真相从权重里挪到了一个可检查的文件里。LangGraph 是 Graph 派,但它的条件边常常由模型打分决定——那就是往左挪了一格。吵架的双方,身体都很诚实地在往中间走。
2. 为什么”每一步都合理,整体却失控”是数学必然
回到漫画标题里那个真问题。它不是玄学,是三个可以精确指认的机制在叠加。
机制一:成功率按乘法衰减,而 Loop 没有止损点。上一篇立过公理:LLM 是随机函数,每步自带错误概率 。 步全对的概率是 ——单步 95% 的聪明,50 步后只剩 。这条数学对 Loop 和 Graph 一视同仁,但两者的应对能力不同:Graph 可以在固定的节点上安插验证器和重试边界,把长链切成若干段独立结算的短链;纯 Loop 的验证时机也由模型即兴决定——用一个随机过程给另一个随机过程设止损,等于没有止损。
机制二:Loop 的全局结构只存在于模型每一步的即兴重建里。Graph 的任务结构写在代码里,跑一百次结构都一样;Loop 的”结构”是模型每一轮读完历史后临时重建的心智图——它这一轮认为任务该怎么走,下一轮可能就变了。每一步局部合理,连起来却不收敛,因为没有任何组件在为全局结构负责。2026 年的《LLM-as-Code》给这类病症起了个准确的名字:控制流幻觉(control-flow hallucination)——模型幻觉出一个不存在的事实,你能校验;模型幻觉出一个错误的”接下来该干嘛”,它直接变成了执行路径。该论文的观察是,这类病理(还有不可靠的终止判断、token 爆炸)跨模型持续存在,因为它们是架构性的,不是模型不够聪明。
机制三:可变的执行历史让失控无法归因。调度器论文指认的第三个结构问题:Loop 的历史会被 compaction 压缩、被模型重新解读,等你发现项目跑偏,想回答”是哪一步开始偏的”,证据已经被改写了。Graph 的执行轨迹锚定在固定的节点上,天然可审计。
三个机制合起来,就是漫画的答案:“每一步都合理”评价的是节点,“项目失控”评价的是边——而 Loop 把所有的边都交给了一个不可检查、不可归因、无人对全局负责的即兴策略。
3. 灰度:什么时候该信模型,什么时候该信代码
到这里 Graph 看起来赢了,但故事只讲了一半。Anthropic 在《Building effective agents》里给过一个被广泛引用的区分:workflow 是 LLM 被预定义代码路径编排的系统,agent 是 LLM 动态指挥自己的过程和工具使用的系统——并且明确建议:能用 workflow 就别用 agent,agent 留给”无法预先写出步骤”的任务。注意这句话的后半截:存在一类任务,你写不出那张图。
判断标准可以压缩成两个问题:
问题一:任务的依赖结构,能不能在开跑之前写出来?发票处理、客服工单、合规审查——步骤可枚举、分支可预见,写不出图是工程师的懒惰,写得出图却用 Loop 是拿生产环境赌博。而开放式调试、探索性研究、“帮我把这个项目迁移到新框架”——路径本身依赖于沿途的发现,预先画的图要么画不出,要么画出来就是错的,硬套图等于把探索空间剪没了。
问题二:环境能不能提供廉价、客观的反馈?这是被讨论得少但更本质的一条。Loop 的失控病根在”模型自己给自己当裁判”,那么病根的解药就是外部裁判:编译器、测试套件、类型检查器。Coding agent 是 Loop 派的大本营,不是巧合——写代码这个环境每一步都有廉价客观的反馈,乘法衰减的 被”跑一下测试”不断重置。反过来,写研究报告、做投资分析这类没有编译器的任务,Loop 每一步的对错都无人裁决,失控概率按第 2 节的数学原样兑现。
两个问题拼成一张四象限的判断表:
| 环境反馈廉价客观 | 环境反馈昂贵/主观 | |
|---|---|---|
| 依赖结构可预先写出 | 都行,选便宜的(通常是 Graph) | Graph,并在节点里安插人工审核 |
| 依赖结构写不出来 | Loop,让环境当裁判 | 最危险的象限:先想办法造验证器,再谈架构 |
右下角值得多看一眼:任务既开放又没有客观反馈时,换架构救不了你——那是验证器缺失的问题,不是 Loop vs Graph 的问题。
4. 第三条路:结构不是人写的,是搜出来的
前面的框架里藏着一个未经审问的假设:图必须由人来画。2024 年以来的一条论文线,把这个假设拆掉了。
GPTSwarm(Schmidhuber 组,ICML 2024)把多智能体系统显式建模成可优化的计算图:节点是操作,边是信息流,然后用 REINFORCE 直接优化”哪些边该存在”的概率分布——图的拓扑成了可学习参数。AFlow(ICLR 2025)更进一步,把”设计 workflow”本身形式化为搜索问题:用 MCTS 在”代码可表达的工作流”空间里搜,用执行反馈迭代精化,在六个基准上超过人工设计的工作流。同一条线上还有 ADAS(让 meta-agent 直接在程序空间里发明新 agent 设计)。2026 年 3 月的综述《From Static Templates to Dynamic Runtime Graphs》给这条线立了统一坐标:一切 agent 系统都是agentic computation graph,真正的分类变量是结构在什么时候被确定——设计时固定(静态模板)、每次运行前生成、还是运行中动态修订。
看出来了吗?这条轴我们见过。AI 的历史就是一部「人写规则 → 数据说话」的替换史:手工特征输给了学出来的特征,手工语法输给了统计翻译。现在,同样的替换发生在控制流上——
人写特征 → 学出来的特征 (2012, 深度学习)
人写图 → 搜出来的图 (2024–, agentic workflow search)在这个视角下,Loop vs Graph 的争论被溶解了:Loop 只是”结构在运行中逐 token 生成”的极端,静态 Graph 只是”结构在设计时一次性冻结”的极端,中间存在整整一个光谱——离线搜好、在线复用;每个查询生成一张专属的图;运行中按需修订子图。争”该扳哪根摇杆”,不如问”我的任务允许结构在多晚被确定,以及我有没有反馈信号供搜索使用”。
5. 苦涩的教训会站在哪一边?
绿灯思维,接住 Loop 派最强的反驳:“Graph 是给弱模型搭的脚手架。模型一年比一年强,你今天精心画的图,明天就是限制模型发挥的牢笼。The Bitter Lesson,懂?”
这个反驳有一半是对的,值得认真拆。
它对的一半:图里所有补智商的结构,确实会被更强的模型碾平。你为”模型经常忘记先检索再回答”画的强制检索边,为”模型规划能力差”预拆的子任务节点——这类结构的价值随模型能力单调递减,它们就是 agent 时代的手工特征。第 4 节的搜索式方法同样站在苦涩教训一边:AFlow 用搜索+算力替代人的设计直觉,恰恰是”通用方法+算力打败人工巧劲”的教科书应用。
它错的一半:图里还有一类结构,价值与模型智商无关。审计边界(金融合规要求每一步可追溯)、权限边界(这个节点绝不允许碰生产数据库)、并行调度(五个独立子任务同时跑,墙钟时间除以五)、成本封顶(这条链最多烧十次调用)——这些需求来自系统所处的世界,不来自模型的短板。就算模型聪明到不会犯任何错,你依然无法向审计员出示一段”住在权重里的控制流”。上一篇的公理在这里显出它的另一面:把真相移到模型外面,一开始是因为模型不可靠;走到最后你会发现,哪怕模型可靠了,外面的真相依然是唯一可检查、可出示、可问责的真相。
所以苦涩教训的正确应用不是”删掉图”,而是给图里的每条边分类:为模型智商画的边,大方地删,越早删越好;为世界约束画的边,永久保留——它们不是脚手架,是承重墙。
6. 带走的判断
- Loop vs Graph 不是二选一,是一根轴:控制流的真相放在权重里还是代码里。所有实际系统都在中间,吵架双方也在互相靠近。
- “每一步都合理,整体失控”是架构性的,病根是没有组件为全局结构负责、且模型自己当自己的裁判。解药按优先级:外部验证器 > 显式结构 > 更强的模型。
- 选型两问:依赖结构能否预先写出?环境反馈是否廉价客观?写得出就画图,有裁判才敢放 Loop;两者皆无时,先造验证器,别争架构。
- 图可以被搜索出来。“人写图 vs 模型即兴”是假对立,第三条路是把结构本身变成搜索空间——这是”从规则到数据”在控制流上的重演。
- 删边前先给边分类:补模型智商的边随模型变强而贬值,尽早删;承载世界约束(审计、权限、成本、并行)的边永不贬值,那是承重墙。
回到那张漫画。小人真正该问的不是”扳哪根摇杆”,而是:我这个任务的结构,最晚可以在什么时候被确定?每一条我画下的边,是在补模型的智商,还是在承载世界的约束?答出这两问,两根摇杆会合成一根。
论文清单(按出场顺序):ReAct (arXiv:2210.03629) · Scheduler-Theoretic Framework (arXiv:2604.11378) · LLM-as-Code (arXiv:2606.15874) · Building effective agents (Anthropic) · GPTSwarm (arXiv:2402.16823) · AFlow (arXiv:2410.10762) · ADAS (arXiv:2408.08435) · Workflow Optimization Survey (arXiv:2603.22386)