Agent 循环真的在跑，还是只留下了配置？

一篇 8 月 26 日修订的 arXiv 预印本，第一次把 Loop Engineering 这个近几个月流行的说法放进了可检验的研究框架：研究团队扫描了 36,710 个工程软件仓库，并逐一核验自动 Agent 循环到底有没有运行。1

本期只追一个问题：Agent 循环真正进入工程系统之后，最该被测量的到底是“它有没有被触发”，还是“它能不能在边界内完成并留下证据”？

论文的研究分两层。第一层是从公开讨论中整理 Loop Engineering 的共同构件：定时或事件触发、机器可检查的停止条件、跨运行状态、独立验证器、预算，以及需要人工接管的升级点。第二层是仓库挖掘：研究团队在 2026 年 8 月 19 日扫描了样本，并对启发式规则命中的 256 个仓库逐一复核。最终，217 个仓库确认存在自主 Agent 循环。12

这个数字不能读成“百分之零点五九的所有软件项目都在使用 Agent”。它只描述这批公开、开源、符合原始数据集筛选条件的仓库；研究团队也明确说，私有仓库、平台原生调度器和动态生成的工作流，会让这个扫描低估真实采用情况。2

论文最有用的判断，不是给“循环工程”贴上一个新名词，而是把争论拆开。调度器、事件触发和维护机器人当然早就存在。新问题在于：现在被反复调用的工作者不是确定性的脚本，而是会自行选择下一步的 Agent。工程重点就从“怎么把任务跑起来”，移到了“怎么限制它、怎么验证它、什么时候让人接手”。2

仓库数据也给了一个很具体的边界。在确认的 217 个循环里，180 个只由仓库事件触发，主要是新拉取请求的自动审查；只有 21 个是纯定时运行。很多事件型循环读完一个拉取请求、发出审查结果就结束，下一次运行直接从下一个事件开始，并不需要把进度写入状态文件。定时的议题分诊，则往往把议题系统本身当成待处理队列。2

所以，“仓库里没有 STATE.md”不等于“没有循环”。它可能只是没有跨运行状态，也可能把状态放在议题系统里。真正要问的是：这次运行产生了什么，下一次运行依赖什么，以及这些依赖能不能被审计和恢复。

这项研究最值得工程团队警惕的一点，是配置很容易被看到，运行过程却很难被看到。扫描到的仓库里，触发器留下了工作流文件，但论文没有发现可靠的已提交停止条件、预算文件、循环验证器或带实测数值的成本日志。研究团队还发现，一次成功的 GitHub Actions 运行并不能证明 Agent 真正执行过：有的工作流几秒就结束，Agent 步骤根本没有运行。2

这也解释了为什么 Agent 的评测单位需要改变。单次任务只看“这次代码通过测试了吗”，而长期循环还要看它是否收敛、累计花了多少 Token、规则有没有漂移、升级给人的问题是否可处理。论文计划用同一组维护任务比较交互式运行、目标驱动运行和定时循环，但这部分仍是计划中的实验，不是已经得到的性能结论。1

如果你要把 Agent 循环接进真实仓库，第一步不是把触发频率调高，而是给每次运行补齐四个问题：什么事件启动了它，什么机器检查决定它完成，哪些改动必须经过人工批准，运行失败后从哪里恢复。然后把 Agent 产出的拉取请求、评论或提交和对应运行绑定起来；没有产物的空跑，也不要伪装成成功。

接着从报告模式开始。让独立验证器先检查测试、风险规则和变更范围，再逐步开放自动修复；给每次运行设置 Token、时间和改动范围预算，并保留一个能立刻暂停的开关。论文自己也承认，独立验证和分阶段提高自治程度是目前最一致的建议，但还没有被它的实验验证。2

最后，别把 217 个仓库当成“Agent 已经普及”的证明。更准确的结论是：自主循环已经在公开软件项目里真实运行，但我们还没有足够好的运行时证据判断它们是否值得长期托管。Loop Engineering 的核心交付物，不是一个会重复调用模型的触发器，而是一条能回答“它为什么继续、为什么停止、出了问题谁接手”的证据链。