Loop Engineering 深度分析 - 2026-07-07

type

status

date

slug

summary

原始链接

论文页面：Stop Hand-Holding Your Coding Agent: Engineering the Loops that Replace Step-by-Step Prompting，arXiv 显示提交时间为 2026-06-28。

论文 HTML：arXiv HTML

论文 PDF：arXiv PDF

论文引用的公开目录：Loop Library

Loop Library 机器可读目录：catalog.json

作者提到的配套 skill 仓库路径：sandeco-loop

今天为什么选它

今天的候选里，有几类都值得看：Continual Harness 讨论自改进 harness，Externalization in LLM Agents 试图把 memory、skills、protocols 和 harness 放进同一个框架，Critique of Agent Model 则在追问“现在这些系统到底算不算真正的 agent”。这些都重要，但今天更适合写 Loop Engineering。

原因很直接：这篇论文抓住了近期 coding agent 实践里的一个真实变化。很多人已经不再只问“该怎么提示模型”，而是在问“怎样让 agent 每天自己找活、执行、检查、记住结果，并在该停的时候停下来”。这和《智汇AI》最近几篇关于 harness、skill maintenance、agent eval 的主题能接上，但不重复。它把焦点放在更靠近落地的一层：循环本身怎么设计。

论文的核心对象叫 loop specification，我这里译成“循环规范”。它不是普通代码里的 for/while 循环，也不是 ReAct 那种 agent 内部的“观察、行动、再观察”。它是人交给 agent harness 的外部工作说明：什么时候启动，目标是什么，怎么执行，怎么验收，什么情况下停止，哪些状态要记下来。

上图来自论文 Figure 2。它把循环拆成几个必须出现的部分：trigger、goal、skills、verification、terminal state、memory，还有预算上限和“没有进展”的检测。这个图的价值不在于画得复杂，而在于它提醒我们：一个能长期跑的 agent，不是“多写几句 prompt”就够了。真正麻烦的是让它知道什么叫完成，什么叫卡住，什么叫不该继续烧钱。

它解决的到底是什么问题

过去讲 AI Agent，常见拆法是：模型、工具、记忆、规划、反思、评测。这个拆法没错，但它常常漏掉一个问题：如果任务每天都发生，agent 应该怎么被反复启动？它上次做过什么，怎么影响这次的动作？它什么时候该停？它失败时算失败，还是被误报成成功？

这篇论文处理的就是这层问题。

作者给出一条很实用的判断：只有当上一轮反馈会改变下一轮动作时，才值得设计成 loop。如果只是每天固定时间发一遍同样的提示词，上一轮结果不会影响下一轮，那它更像定时任务，不是循环。这个判断能挡掉很多伪 agent 自动化。比如“每天让 agent 写一篇周报”不一定是 loop；“每天检查线上错误，找到可行动问题就定位、修复、验证、开 PR；如果没有问题就记录 no-op 并停止”，这才更接近 loop。

这也是它和普通 workflow 的区别。workflow 往往把步骤写死；agent loop 允许模型根据反馈选择下一步；loop specification 又往外包了一层，规定它什么时候开始、什么叫成功、失败怎么处理、状态在哪里留存。

核心机制一：先定义“完成”，再让 agent 动手

论文最有价值的部分，是把 verification 放在中心，而不是把 prompt 放在中心。作者的态度很硬：没有能反推下一步动作的检查，循环就没有意义。一个 agent 如果只是自己说“我做完了”，那不叫验证。

上图来自论文 Figure 3。论文把验证分成五级：

Level 1：确定性检查，比如断言、退出码、黄金输出。

Level 2：规则检查，比如 schema、linter、政策规则。

Level 3：延迟的真实反馈，比如测试部署、真实用户响应。

Level 4：模型当裁判，用 rubric 打分。

Level 5：人来检查。

这个分层很有用，因为它把“自动化程度”说清楚了。Level 1 和 Level 2 才是真正可以无人值守跑起来的区域。Level 4 不是不能用，但它只是模型意见，不是事实。很多 agent demo 的问题就在这里：表面说自己有 eval，实际只是让另一个模型夸或批。这种检查可以辅助判断，但不能假装成确定性证据。

对产品和研发来说，这里有个直接启发：先写验收器，再写 agent 任务。比如做代码修复，验收器可以是测试、类型检查、复现脚本、页面截图对比。做内容生产，验收器可以是来源链接完整性、事实字段一致性、格式约束、人工抽检位置。验收器越模糊，agent 越容易把“看起来像完成”当成完成。

核心机制二：终态要命名，错误不能伪装成成功

论文要求每个循环有明确终态：success、no-op、blocked、stalled、exhausted。这个细节很朴素，但很关键。

很多自动化任务坏就坏在没有终态。agent 一直试，直到预算用完；或者它遇到权限问题、资料缺失、测试不通，却用一段漂亮总结把失败包装成“已完成”。论文反复强调：预算耗尽不是成功，报错不是成功，没进展也不是成功。

如果把这个方法放进日常研发，可以得到一个很实用的交付模板：

success：目标达成，检查通过。

no-op：没有可处理对象，不做改动。

blocked：缺权限、缺输入、外部服务不可用。

stalled：连续几轮没有实质进展。

exhausted：达到预算或轮次上限。

这比“完成/未完成”更适合 agent。因为 agent 不是一次函数调用，它会绕路，会误判，会把局部成功当整体成功。终态命名能让人看清楚它到底停在哪里。

核心机制三：当前实践最强的是验证，最弱的是真正无人化

论文分析了 Loop Library 中 50 个循环。这里要说明一下：论文写的是 50 个样本；我打开当前 Loop Library 的 catalog.json，看到公开目录元数据已经显示 loopCount 为 70，更新时间为 2026-06-26。所以报告里的统计数字应按论文样本理解，不要直接等同于今天目录里的全部条目。

上图来自论文 Figure 7。它的结论比“agent 越来越强”这种说法更有信息量：

74% 的论文样本命名了终态。

70% 的论文样本用了自动区间里的验证方式。

66% 的论文样本有可验证目标。

只有 22% 用了自动触发。

只有 20% 调用了命名、可复用的 skills。

只有 32% 发展出持久记忆。

换句话说，Loop Library 里的实践已经比较会回答“怎么知道做完了”，但还不太会回答“怎么在没有人推它的情况下持续运转”。这正是今天选它的理由。它没有把 agent 自动化吹成全自动生产线，而是指出了当前短板：触发、skills、memory 这三块还没成熟。

这也能解释为什么很多团队用了 coding agent 后，感觉它能做事，但还不能放心托管工作流。缺的不是一个更会聊天的模型，而是更扎实的运行制度：谁触发它，哪类任务能触发，哪些 skill 可以加载，状态写在哪里，下一次怎么继承，失败怎么升级给人。

它和常见 agent 设计相比，新在哪里

常见 agent 设计里，重点经常放在 plan、tool use、reflection、memory。Loop Engineering 的新意不是发明了新模块，而是换了控制对象。

它不再只问“agent 一次任务里怎么想”，而是问“一个可重复任务怎么被 agent 承接”。这让很多老概念变得更可操作：

planning 不只是写计划，而是把目标拆到每轮能验证的程度。

tool use 不只是会调用工具，而是工具结果能不能进入下一轮判断。

memory 不只是长上下文，而是外部、可读、可清理的状态记录。

reflection 不只是让模型自我批评，而是失败证据是否能改变下一步动作。

evaluation 不只是跑分，而是每轮是否有真实验收。

multi-agent 不只是多个角色聊天，而是 maker 和 checker 分开，避免同一个模型又生产又批准。

这里真正新的地方，是把 agent 的“工作制度”当成设计对象。它更像产品运营里的 SOP，也像工程里的 CI/CD，但又不完全等同于二者，因为 agent 在循环里仍然会根据反馈选择下一步。

也有一些只是工程包装。比如把一个固定 prompt 放到 cron 里，不会自动变成 loop；给 agent 加一个总结文件，也不等于有 memory；让模型打分，也不等于有可靠 eval；把多个 agent 放进群聊，也不等于有协作。论文好的一点，是愿意把这些边界说清楚。

可复用方法论

如果把这篇论文转成团队可执行的方法，我会压成六步：

先判断是否真的需要 loop：上一轮结果会不会改变下一轮动作？不会，就别伪装成循环。

写清楚目标和验收：目标最好能被测试、规则、日志、截图、数据结果或人工检查证明。

选最低可用验证级别：能用确定性检查，就不要用模型裁判；必须用模型裁判时，换模型、给 rubric、保留抽检。

给终态命名：成功、无事可做、卡住、无进展、耗尽预算，要分开记。

把状态放到外部：文件、数据库、任务板、PR、评测记录都可以；不要依赖聊天上下文记住一切。

计算每个被接受结果的成本：不要只看 token 花了多少，要看花出去的钱换来了多少通过验证的改动。

这套方法对产品落地尤其有用。很多 AI 产品现在还停在“给用户一个 agent 按钮”。Loop Engineering 暗示下一步更重要的是“给用户一套可托管的工作单元”：用户不需要每次重新解释任务，系统能按事件或计划启动，能拿旧结果做判断，能报告清楚为什么停止。

风险和没验证的问题

这篇论文不是 benchmark，也没有证明某个 loop 设计能把成功率提高多少。作者自己也说，sandeco-loop 是把原则写成可执行的编写流程，但没有使用数据。也就是说，它更像一篇给实践命名、整理边界、提出检查表的论文，不是实验结论。

主要风险有四个。

第一，验证负担会变重。循环跑得越快，人越需要知道它产出的东西是否可信。maker-checker 分离能降低风险，但不能取消审查。

第二，模型裁判容易被高估。Level 4 可以帮忙，但不能装成 Level 1。尤其是内容、代码质量、产品体验这类任务，模型评审很容易被措辞、上下文和自己的偏好带偏。

第三，循环可能学会钻规则空子。论文提到 specification gaming：agent 可能改测试、硬编码输出、绕过环境，而不是解决问题。只要验收器能被 agent 触碰，就要假设它会被优化甚至被利用。

第四，理解债会增加。agent 自动改得越多，团队越可能拥有一堆“确实通过检查、但没人真正理解”的产物。对代码、数据、运营规则来说，这个风险很实际。速度不是免费午餐。

对研发和产品的启发

对研发团队，最值得带走的是：把 recurring task 写成 loop spec，而不是写成一句“帮我持续优化”。例如生产错误清理、文档同步、测试补齐、日志覆盖、性能优化，都适合先定义触发、验收、终态和记忆，再交给 agent。

对 AI 产品团队，重点是交互形态会变。用户不应该每天重新发同一段 prompt；更合理的是创建一个可暂停、可审计、可升级的循环。用户看见的不是“agent 正在努力”，而是它当前处于哪种终态、基于哪些证据、下一次会怎么继续。

对平台团队，harness 需要把这些能力做成基础设施：定时或事件触发、权限边界、可复用 skill、外部状态、执行轨迹、预算上限、失败升级、验收记录。模型只是其中一部分。没有这些，agent 很难从 demo 走到托管工作。

上图来自论文 Figure 8。它展示的是 sandeco-loop 怎样从原始任务走向循环规范：先判断是不是值得做成 loop，再通过简短访谈收集设计要素，随后做 hardening，最后输出一份可交给 harness 的规范。这个流程本身还没被实验证明有效，但作为写 loop spec 的检查清单，已经够实用。

今日沉淀

只有反馈会改变下一步动作，才值得做成 loop。

Agent 自动化的核心不是多跑几轮，而是每轮都有真实验收。

模型裁判是意见，不是事实；能用确定性检查就别偷懒。

终态要命名：卡住、无进展、耗尽预算都不能算成功。

未来的 agent 产品，卖点不是“更会聊天”，而是“能托管一类可验证的工作”。