ReaderMX.
alitrack

Loop Engineering的背后：调度理论、学术验证与你想不到的成本故事

aalitrack约 5 分钟
Loop Engineering 的背后：调度理论、学术验证与你想不到的成本故事

上篇聊了 Loop 的五块积木——自动化、工作树、技能、连接器、子Agent审查。这篇把镜头拉远，看看支撑这个范式的理论地基、学术验证和真实数据。

一、为什么"Agent Loop"有结构性弱点？

你可能听过"Agent Loop"这个词——就是那种"想一步、做一步、观察一步"的循环。目前绝大部分 Agent 系统都跑在这个模式上。
但你有没有想过一个问题：这么多Agent都跑同一个模式，这个模式本身有没有天花板？
2026年4月，一篇论文（arXiv:2604.11378）把这层窗户纸捅破了。作者分析了70个开源Agent项目，发现60%都采用Agent Loop模式，而这个模式有三个结构性的软肋：

软肋一：依赖靠"记"，不是靠"结构"

当Agent说"先读文件A，再改文件B"时，"改文件B依赖读文件A"这件事只存在于上下文中。Agent必须在推理时记住这个依赖。没有任何结构上的约束能防止它乱序执行——比如文件还没读完就跑去改了。
想象一个工厂，工人们的工序依赖全都贴在自己脑子里，没有任何传票或流水线来保证顺序。不出错才怪。

软肋二：失败没有"刹车"

某一步失败了——Agent自己决定是重试、跳过还是重新规划。没有明确的上限。它可以重复试10次，也可能一失败就放弃。能不能停下来，完全看它心情。

软肋三：执行历史可以被"涂改"

Agent执行到一半，如果改变了计划，原始计划就被覆盖了。跑完之后，你无法复原"当时按照哪个计划执行了哪些步骤"。审计等于不存在。

解决方案：从"单线程"到"图"

这篇论文提出一个框架：把所有Agent执行系统放在一根轴上衡量——"就绪集"的大小。

  • Agent Loop
     = 单就绪单元调度器。任何时候只能做一件事。下一步做什么来自不透明的LLM推理。
  • 图执行引擎
     = 多就绪单元调度器。多个步骤可以同时准备就绪，并行执行，有条件分支，有界恢复。

这不是量变，是质变——控制流从"LLM在上下文里慢慢推"变成了"拓扑结构上明确画出来的依赖图"。

二、多Agent真的更好吗？94篇论文的回答

一个直觉是：多Agent肯定比单Agent强，专人专事嘛。
学术界的回答是：不一定。这个问题的答案比你想的复杂得多。
AgentPatterns.ai 对94篇多智能体软件工程论文做了系统综述，萃取出16种设计模式、5大类别：

类别
模式
合作
角色分工、层级协调、点对点协作
记忆
共享记忆、个体记忆、外部记忆
执行
串行、并行、条件执行
验证对等审查
、共识投票、迭代改进
通信
结构化消息、共享工作区、广播、请求-响应

其中基于角色的分工是最多见的模式——代码生成、缺陷修复、重构，几乎都用"编码者→审查者→测试者"的拆分。
而对等审查（Peer Review）是被验证最有效的验证模式。理由和我们上篇说的一样：审查Agent没有"沉没成本偏差"，能发现写代码的Agent自己看不到的问题。

但反转来了

同篇综述也揭示了三组令人清醒的数据：
第一，41.8%的多Agent失败源于设计问题，而非模型能力不足。
Agent之间互相误解目标、通信协议错乱、角色漂移——这些问题的根源不是模型不够强，而是架构设计本身引入了新的失败模式。
第二，前沿模型（GPT-4、Claude Sonnet等）在大多数SE任务上可以单挑多Agent团队。
在一个足够强的单Agent和精心编排的多Agent团队之间，差距正在缩小——甚至在某些任务上，单Agent反而更好。
第三，协调开销可能超过质量增益。
每个子Agent都是一次LLM调用。并行越多，Token消耗越大。当质量提升微乎其微时，多Agent的成本增长很少能 justify。

所以多Agent不是银弹。它的最佳使用场景是可验证的任务——代码生成、测试审查这些"对错分明"的工作。在开放式任务（设计、创意）上，收益要弱得多。

三、成本究竟怎么样？一组实测数据

Gradientsys 团队在 GAIA 基准上做了一组对比实验，数据很说明问题。
GAIA 是"通用AI助手"的标杆测试——包含466个真实世界的多步骤任务（文档解析、网页搜索、逻辑推理等）。
对比两个系统：

  • 基线
    ：两模型架构（GPT-4规划 + Llama-2-13B执行，类似 MinionS)
  • Gradientsys
    ：LLM调度器 + ReAct规划 + 并行多Agent分发 + MCP工具注册表

结果：

指标
基线
Gradientsys
差距
准确率
15.0%
24.1%
+60%
平均延迟
52s
35s
1.5x更快
成本（归一化）
1.00
0.224.5x更低

注意那个成本：4.5倍降低，而不是升高。这是最反直觉的地方——多Agent并行反而更省钱。
原因在于：并行 + 本地工具分流 + 弱模型打下手。调度器只在需要时才调用GPT-4做聚合和判断，繁重的搜索、解析工作交给本地轻量工具。这和"让架构师做决策、让实习生做执行"是同一个逻辑。

四、一句总结

回到开头的三个软肋。Loop工程之所以不仅仅是"给Agent加个定时器"，是因为它在根本上重构了人机协作的控制流：

Agent Loop
Loop Engineering
依赖靠LLM"记住"
依赖在图结构上"画出来"
失败无上限
有界恢复协议
历史可涂改
计划版本不可变
串行执行
就绪集≥1，并行+分支
隐式调度
显式拓扑调度

你从"握着AI的手一步一步走"，变成了"设计一张图，让AI在上面自己跑"。
这不是工具升级，是角色转换。

参考：

- Hu Wei — From Agent Loops to Structured Graphs (arXiv:2604.11378, 2026)

- AgentPatterns.ai — Multi-Agent SE Design Patterns: A Taxonomy Across 94 Papers

- Gradientsys — A Multi-Agent LLM Scheduler with ReAct Orchestration (arXiv:2507.06520, 2025)

KEEP THE THREAD GOING

更多来源文章