11 页 Claude Loop Engineering 实战手册

Loop Engineering（循环工程）：让 Agent 自己发现任务、执行、验证、循环迭代的工程方法论。

前三篇：

Loop Engineering：从提示者到循环设计者的14步路线图

Loop Engineer Template 详解

Loop Engineering 如何使用AI编程智能体：构建可循环系统

今天是第四篇，Claude 用独立会议风格写的综述：5 步框架：Discovery → Hand off → Verify → Persist → Schedule。

我比较关注这个框架中，如何设置验证，如何停止，以及这个Loop Engineer 有什么需要避免的问题。

摘要：

过去两年间，一系列“XX工程”术语不断涌现，与模型发布的节奏同步。

本文探讨其中最新的一个术语：循环工程（Loop Engineering）。

该术语由彼得·施泰因伯格、鲍里斯·切尔尼和阿迪·奥斯马尼于2026年6月独立提出，并由奥斯马尼在文献中首次命名。

（外国人就是会玩，名词不断花样翻新。）

与提示工程、上下文工程或框架工程不同，循环工程并非教导从业者如何更好地完成工作，而是彻底将从业者从执行工作的角色中移除。

我们对这一术语进行定义，将其置于框架之上作为第四层，并将一次循环分解为五个步骤——发现、移交、验证、持久化和调度，以及实现这些步骤的六个组成部分。

我们特别关注生成器与评估器的分离：经实证表明，被要求自我评分的智能体往往倾向于高估自身输出；

而调整一个独立且持怀疑态度的评估器，远比让生成器学会批判自身工作更为可行。

我们考察了三个实际运行的循环流程，从一名工程师的早晨问题排查，到Stripe每周合并超过1300个机器生成的拉取请求的企业级流水线，

并梳理出四种悄然累积的成本：验证债务、理解退化、认知放弃和令牌膨胀。

最后，我们提供了一套构建首个循环的具体方案。

核心观点是：循环使生成几乎免费，而判断力成为稀缺资源；同一循环若由两人构建，可能产生截然不同的结果。

I. 引言：循环工程究竟是什么

提示工程课程仍在热销，上下文工程的墨迹尚未干透，而驾驭工程（Harness Engineer）才刚刚写成。

如今，循环工程也接踵而至。

在过去一年中，这些“XX工程”术语几乎与模型发布同步出现，让人忍不住想翻白眼，也是情有可原的。

这有所不同。它不再关乎如何更好地完成工作，而是彻底将从业者从执行工作的位置中抽离出来。

之前的术语都假设有一个坐在键盘前的人，逐行地指导智能体运行。

而循环工程则摒弃了这一假设。从业者不再身处循环之中，而是置身于循环之外，去构建这个循环。

A. 一句话定义

提出并阐述这一术语的是谷歌Chrome团队的工程师AddyOsmani。

他的定义简洁明了：循环工程就是不再由自己来提示智能体，而是设计一个能够自动完成这一任务的系统。

人们不再逐行向智能体输入指令，而是设计出能自动向其输入指令的系统。

这句话的重点在于“取代自己”。

这是一种角色的转变——从成为引擎本身，转变为设计引擎的人。

人们所编写的不再是直接给智能体的语句，而是一个能自动将语句发送给智能体的系统。

一周之内，三人相继点燃了引信

这个术语并非凭空而来。

2026年6月的一周内，多个团队几乎在同一时间遇到了同样的问题。

最初的触发点是一篇来自彼得·施泰因伯格（OpenClaw作者）的帖子，该帖浏览量突破八百万次，内容指出：人们不再应该直接提示代码代理，而应设计用于提示它们的循环机制。

几乎与此同时，Anthropic公司Claude Code项目负责人鲍里斯·切尔尼也表达了相同观点：

他不再直接提示Claude，而是运行着自动提示Claude并决定下一步操作的循环程序，而他的工作就是编写这些循环。

6月7日，奥斯马尼在自己的博客上以《循环工程》为题撰文，整合了施泰因伯格和切尔尼的观点，并于次日同步发布到Substack平台。一次点燃，一次回响，一个名称，全部发生在一周之内。

这三个陈述放在一起，指向了同一个转变：设计的对象已从个体行为转向驱动该个体的整个系统。

与此前的“氛围编码（Vibe Coding）”类似，这一术语听起来或许粗略，但它将一种工作方式转化为可供讨论的话题。

C. 为何这个术语现在才出现

值得思考的是，为何三位实践者在没有交流的情况下，竟在同一周内不约而同地使用了同一个术语。

答案在于，周边工具已悄然跨越了一个临界点：

编码代理变得足够可靠，能够无人值守地完成非简单的任务；

调度原语已出现在主流框架中；

单次代理运行的成本已大幅降低，以至于定时重复运行一次也不再显得浪费。

当所有组件都已就位时，将它们组合起来的这一步骤便立刻显而易见。

名称的出现总是滞后数月：人们早在有人称之为“循环工程”之前，就已经开始编写循环；

正如团队在“生成器/评估器”这一分工被命名之前，就已经开始将写入代理与评审代理配对一样。

它不会来自模型发布，而是在某种新能力变得足够廉价、使原本难以想象的组合成为常规操作的那一刻出现。

这种转变简化为两句话。

在旧模式中，人们坐在那里逐行提示代理；它完成一件事后就停止，等待。人就是循环中的时钟，而每一次触发必须来自人类。

在新世界中，人们设计出能够自主运行的事物——它依靠计时器运行，自动生成助手来完成任务，并将自身的结果反馈回系统。

正如奥斯马尼所说，循环工程位于控制机制之上一层：底层的控制机制仅用于启动单次代理运行；而上层的循环则让其不断重复运行。

这种转变体现在身份的转换上，从操作代理的人转变为调度代理的人。

价值也从“懂得如何指挥”转向“懂得如何构建循环，以及如何在循环内部设置一个能说‘不’的检查机制”，后者最为困难，后文将详细解释。

从提示到上下文再到循环

“XX工程”术语并非相互替代，而是层层叠加，各自关注更大的整体。表一列出了这四个层次。

每一层向上，关注的单位都会扩大一个级别：从一个句子，到一个窗口，再到一次运行，最终到一个能够自我运行的循环。

图1将这四个层次以堆叠的形式展示，其中循环位于控制结构的上一层。

A. 四层结构

提示是底层也是最广为人知的部分，它决定了向模型传达什么内容：措辞、示例、角色和语气。

其边界是一次交互。问题在于，它假设每次都有人类在场来提交提示。

上下文将问题从“我该说什么”提升为“这个窗口里应该放什么内容，才能让模型破解难题”。

它关注模型的整个视野：该提取什么、如何总结、哪些过时信息需要清除。

一个充满噪音的窗口，即使再好的提示也无济于事。

明确一个代理在单次运行中需要携带的内容：

使用哪些工具、执行哪些操作、何时加载上下文、如何从失败中恢复，以及何种状态被视为完成。

它为一次运行提供装备，但不会让该运行重复进行。

Loop 自动化了“等待你”的过程。

在前三个层级设置完成后，Agent 会顺利运行一次，然后停止。

Loop 为其添加了定时器，使其能按计划唤醒，生成子代理以并行工作，并将自身的输出作为下一轮的输入进行反馈。

B. “在Hermes上增加一层”实际上带来了什么

三个动词将“套索（Hermes）”与“循环（Loop）”区分开来。

它按定时器运行：循环会按时自动唤醒，无需按键触发。

它生成辅助者：一个循环会分出子代理，一个负责起草修改，另一个则仅在审查时将其拆解分析。

它自我供给：当前循环的输出成为下一轮的输入；昨天的发现会被写入文件，而今天早上它读取该文件并继续执行。

这种跨对话的记忆能力，正是它被称为“循环”而非“多次重复执行的一次性任务”的原因。

细粒度的划分至关重要，因为每一层的失效方式各不相同，而能够发出“否”判断的检查机制必须部署在不同的位置。

错误的提示会立即被发现；错误的上下文则会体现在错误的回答中。

但在循环层，系统会在人们熟睡时持续运行，修改从未查看过的代码，并将自身的错误带入下一轮。

这种错误可能数天内都未被察觉。

层级越高，就越远离问题现场，错误积累的时间也越长。

这正是循环工程真正的难点所在：问题从来不在于构建循环本身，而在于如何在其中放入能使其停止的机制。

每一层的失败都有不同的影响范围

考虑同一个底层缺陷：即 Agent 错误地解读函数返回值，在每一层的表现。

在提示层，这种误读导致一次对话中出现一个错误答案；人类立即察觉并重新编写提示。

在上下文层，误读源于加载到窗口中的过时文档；人类发现答案自信地错误，于是清空上下文。

在执行层，Agent 仅因误读而采取一次行动：例如编辑一个文件，但运行随即结束，差异可见，人类在发布前会审查这些变更。

而在循环层，同样的误读被写入状态文件，第二天早晨又被当作既定事实读取，并在多次交互中不断累积。

等到有人注意到时，这个错误的假设已经成了系统的关键支撑。

这是循环工程中最重要的直觉：错误的代价取决于它在被发现前能持续多少轮，而循环结构的设计本身就是为了最大化轮数。

后续章节中的所有内容：评估器、人工检查点、预算上限——都旨在缩短错误与其被发现之间的距离。

III. 一个循环的五个动作

“循环”这个词很容易被误解为无所事事地旋转。

但每一次循环都完成着具体的工作：它找到值得处理的任务，将其交给代理执行，验证结果是否正确，保存状态，然后决定下一步行动。

如果缺少这五个步骤中的任何一个：发现、移交、验证、持久化和调度，循环就无法运转，或只能原地打转。

图2展示了这五个步骤如何构成一次循环，并为下一次循环提供输入。

A. 一个具体的例子

奥斯曼为自己构建了一个早晨的分诊循环。

每天早上，自动化流程会自动启动。

一个分诊技能会读取前一天失败的CI测试、尚未关闭的问题以及最近的提交记录，并将结果写入一个Markdown文件或Linear看板中。

对于每一个需要处理的问题，系统会开启一个独立的工作区：

一个子代理负责起草修复方案，另一个则根据项目规范和测试对修复内容进行审查。

连接器会自动创建拉取请求并更新对应工单。

所有无法自动处理的内容会被放入收件箱，等待人工介入，同时状态文件会保留当前进度，以便第二天继续从上次中断的地方开始。

整个流程无需人工干预任何步骤，却能在恰当时机准确地暂停，等待人类参与。

B. 动作

Discovery 会判断当前轮次应该执行什么操作。

在示例中，分诊技能会读取 CI 失败、未解决的问题以及最近的提交记录。

关键在于让代理自行发现工作内容，而不是被动接收一份任务清单。

至关重要的是，自动化触发的是一个技能：即被永久固化为知识的内容，而非将一堆指令粘贴到无人维护的 cron 任务中。

Discovery 决定了整个流程的质量上限：如果它只呈现毫无价值的工作，那么其余四个步骤再完美，也无意义可言。

Handoff 将任务从调度系统移交给执行工作的代理。

每个值得处理的发现都会拥有独立的 git 工作树，因此多个代理可以在不同的目录中修改代码而互不干扰。

任务划分得越清晰，后续的验证和合并就越容易。

验证是最容易偷工减料的环节，也是最容易被忽视的一环。

在第一个子代理起草修复方案后，第二个子代理会进行审查：使用不同的指令，有时甚至采用不同的模型。

编写代码的代理对自己作业的评分过于宽松；而专门负责挑错的代理则能发现前一个代理因自我说服而放过的漏洞。

这就是“能够说不的东西”。

没有真正检查的循环，不过是 Agent 在自欺欺人地点头同意罢了。

持久性将结果保存在能够超越对话本身的地方：

通过连接器生成的公关记录和更新后的工单，一个用于处理不了事项的收件箱，以及记录进展状态的文件。

循环的记忆不能仅存在于上下文窗口中；写入到Markdown或看板中的内容不会被遗忘。

调度机制使得一次运行转变为循环。

每天早晨，分诊流程会自动执行，而状态文件则可将未完成的发现延续到第二天，系统会自动继续处理。

正如奥斯马尼所说，正是自动化让循环真正成为循环，而不仅仅是一次性的运行。

表二总结了这五个方面。

IV. 六个部分：

循环的构成要素如果“移动”描述的是每一轮中发生的事情，那么“部分”则描述了实现该轮次所必须具备的条件。

两者一一对应：发现依赖于技能，交接依赖于工作树，验证依赖于子代理，持久化依赖于记忆，调度依赖于自动化。

自动化可依据计划或触发器自行启动循环运行。

若无计划安排，所执行的仅是一次性操作，而非循环。

自动化应触发一个命名的技能，而不是在定时任务中堆砌大量指令。

调度方式有多种，包括本地（设备必须保持开机）和云端（即使设备关机也能运行）。

工作树是 Git 内置的一种机制，用于在一个仓库中管理多个独立的工作目录。

其价值随着并行操作的增加而提升：两个代理同时修改同一文件所带来的问题，与两名工程师提交相同代码行时遇到的问题如出一辙。

工作树将并行操作从“能运行但混乱”转变为“既能运行又保持整洁”。

技能将项目知识永久保存在一个文件（SKILL.md）中，因此代理无需在每次交互时重新推导上下文。

奥斯马尼将这种付出的成本称为“意图债务”：即反复解释“这个项目是什么、规则有哪些、陷阱在哪里”的代价。

技能可以被重复使用和维护，而光凭提示词的堆砌则无法做到这一点。

连接器（基于MCP，即模型上下文协议）将循环与外部世界连接起来：例如问题跟踪系统、数据库、预发布API或Slack。

一个只能看到文件系统的循环是极其有限的。

连接器决定了循环的视野范围，而且为某个工具编写的连接器通常可以直接迁移到另一个工具上并直接使用。

子Agent 将撰写者与评判者分开。

当一个代理同时担任玩家和裁判时，裁判就会偏袒。

反直觉的是，让独立的评判者变得挑剔要容易得多，而让生成器对自己作品严格要求则困难得多。

这就是为什么循环中会保留一个额外的代理，而不是让同一个代理自我审查。

记忆是存在于单次对话之外的持久状态：一个 Markdown 文件或一块看板。

一旦上下文窗口被清除，Agent 便不再记得任何内容；若要让循环从昨天中断的地方继续今天的工作，记忆就必须保存到磁盘上。

Agent 会遗忘，而仓库不会。

记忆不是上下文：上下文是代理当前轮次所看到的内容，刷新时会被清空；

而记忆则跨轮次、跨天持续存在。

表 III 将六个部分映射到五个动作。

当六个部分全部到位时，一个循环便有了骨架：

自动化使其运转，工作树防止其自我冲突，技能避免重复劳动，连接器使其能够感知外部，子代理使其具备自我修正能力，而记忆则让它能够记住。

但构建只是开始：同样的组件，由两个人分别搭建，最终结果可能截然不同。

V. 生成器与评估器

循环中最难的部分不是让代理运行起来，而是如何在其中放入一个能说“不”的东西，而编写代码的 Agent 恰恰是最不可能说出“不”的人。

A. 它总是过于自信

让一个 Agent 去评价它刚刚生成的内容，它往往会自信地给予好评，即使人类明显能看出质量平庸。

Anthropic 工程师普里特维·拉贾塞卡尔在开发长期运行的应用程序时就观察到了这一点。

这并非智能的问题，而是相当于在给自己批改作业。

代码被编写时，其中已经充满了它之所以那样编写的理由，因此当代理审视自己的输出时，看到的并非结果本身，而是导致该结果的一系列自我说服过程。

在循环中，这一缺陷会被放大：如果每一次“这足够好吗”的判断都由刚刚写出它的代理来决定，那么每一轮它都在对自己点头认可，运行时间越长，就越偏离真正的质量标准。

B. 调教怀疑者，而非修正谦逊的作者

让生成器更具备自我批判能力效果不佳。

拉贾塞卡尔发现，调整一个独立的评估器使其保持怀疑态度，远比让生成器对自己作品进行批判要容易得多。

这种差异是结构上的，而非措辞问题：无法要求作者跳出自身视角，但可以引入另一个具有完全不同指令的代理，从零开始审视代码，且不带有任何自我说服的倾向。

这一思路借鉴自生成对抗网络（GAN）：一个网络负责生成，另一个负责挑错，并将其应用于一个负责编写代码的生成器和一个负责评审的评估器。

图3展示了由此形成的循环过程。

C. 评估者应采取行动，而不仅仅是阅读

仅仅更换评估模型是不够的。

如果评估器只读取代码，它判断的是“这看起来对吗”，而不是“它能正确运行吗”。

在前端任务中，拉贾塞卡尔将评估器连接到 Playwright MCP，使其能够打开页面、点击按钮、截取屏幕截图并检查 DOM，就像一名测试工程师一样。

这样一来，判断依据就从“这段 JSX看起来没问题”转变为“我点击了按钮，页面跳转了，这是截图”。

同时更换底层模型也有帮助：同一个模型即使使用新指令，仍可能保留原有的盲区。

一个常见的社区校准方法是让评估器默认假设代码是错误的，除非有证据证明其正确——默认态度应是怀疑，而非信任。

D. 在编程工具中：/goal 命令适合有停止条件的任务

Claude Code 将这种结构转化为一个原始形式，其目标是：给代理一个条件，并让它运行直到该条件满足。

一个典型的评估器设置和停止条件如下所示。

关键在于，每次执行后，一个独立的快速模型会检查条件是否满足；

如果不满足，则继续运行下一轮，而不是返回控制权。

完成与否由另一个全新的模型决定，而非执行工作的那个模型。

这就是“制造者-检查者”原则：在银行业已沿用数十年，即输入大额转账和审核转账的人员必须不同，应用于停止条件上。

（Codex 通过自动化与代理配置实现相同功能；不应将 /goal 与 /loop 混淆，后者仅表示按固定间隔重复运行。）

循环的底层是其评估器。生成器的层级决定了循环能产生什么，而评估器的层级则决定了它不会产生什么。在结构上将生成与判断分离，把评估器调校成一个怀疑者，使其通过行动来验证，并将最终决定权交给一个全新的模型——这四个步骤正是提升循环说“不”能力的关键所在。

VI. 循环出错的五种方式

在探讨有效的循环之前，值得先梳理一下它们失败的各种方式，因为失败的案例比成功的更具启发性，也更为常见。

下面每一种反模式都对应着五种操作中的一种被跳过或执行不当的情况。

A. 点头循环（已跳过验证）

最常见的失败情况是：循环运行，代理生成代码，然后同一个代理又宣称代码合格。

由于缺乏独立的检查机制，每一轮都产生自我认可的输出，循环以机器速度不断累积看似合理的错误。

其表现特征是，在数百轮迭代中，该循环从未对自己说“不”，对于任何真实的工作负载而言，这在统计上是不可能的，因此证明了实际上并不存在真正的检查机制。

解决方法就是前一节提到的生成器与评估器分离的方案。

B. 失忆循环（持久性已跳过）

循环会发现好的工作，执行它，然后忘记曾经发生过，因为结果只存在于一个已被清空的上下文窗口中。

下一次循环时，又会重新发现同样的工作，或者更糟的是，重复执行并导致与第一次尝试冲突。

其表现是循环没有累积进展：每天早上都从同一个起点开始。

解决方法是在磁盘上保存状态文件，Agent 会遗忘，但仓库不会。

C. 手动循环（已跳过调度）

一个包含四个良好操作但没有自动化的循环并不是真正的循环；它只是人类手动执行后便遗忘再次运行的脚本。

在创建当天，它可能表现得非常出色，但一旦注意力转移，便会悄然停止。

其症状是：最后一次运行是在演示当天。

解决方法是设置一个真正的触发器：比如定时器或事件，使其不依赖于人类的记忆。

D. 盲环（发现已跳过）

人类每天早晨仍会向循环流程下达任务：“修复这三个漏洞”，因此，循环流程虽然自动化了执行过程，却未能自动发现任务。

这带来的节省效果远不如表面看起来那么大，因为选择该做什么往往才是成本高昂的部分。

其表现就是，人们仍在清晨耗费时间决定循环流程该处理什么。

解决方法是将问题发现培养成一项技能，让循环流程能够自行浮现待办事项。

E. 缠绕的环（已跳过交接）

该循环并行运行多个代理，但允许它们全部修改同一个工作目录，导致编辑内容相互冲突，合并结果混乱不堪，无人能理清。

这一问题仅在并行运行时出现：单个代理的循环运行正常，而当五个代理同时运行的第一个早晨问题便显现出来。

解决方法是为每个任务分配一个独立的工作树。

图4将五种反模式与它们所违反的操作对应起来。

这五个环节并非相互独立。

一个缺少验证的循环往往也会忽略持久性，因为一个团队如果对某项检查疏忽大意，通常对其他检查也同样粗心。

在实际操作中，这些环节常常成群出现：有条不紊的循环会安装全部五个步骤，而草率的循环则只安装发现和交接。

这两个能产生可见输出的环节，却跳过了那三个保障安全的步骤。

下一节将展示三个完整安装了全部五个环节的循环实例。

VII. 睡觉时运行的循环：

三个真实案例三个公开案例在规模上差异巨大，但都共享一个基本框架：

一个触发器启动运行，一组约束条件确保其沿轨运行，而人类检查点则位于终点。

所谓“在你睡觉时运行”从来不是关于模型有多强大，而是关于这个框架是否稳固。

A. 一位工程师的早晨

奥斯曼尼的分诊循环在第三部分中被分解，每天早晨都会自动运行。

有一点值得再次强调：该自动化调用的是一个技能，而不是一大段指令。

被固定在一个无人更新的日程中。

这就是一个人所能运行的循环模式：一个人、一台机器，每天早晨完成琐碎的重复工作。

Stripe的“小黄人”：每周提交1300份PR

在企业级规模下，值得研究的案例是 Stripe 的 Minions：每周合并超过 1300 个拉取请求，且没有一行代码是手动编写的，这是 Stripe 工程师 Steve Kaliski 在《How I AI》播客中提到的。

触发方式非常简单——在 Slack 中@机器人，或添加一个表情符号反应。

其可靠性来自于模型启动前的准备阶段：一个确定性的调度器会先构建上下文，扫描链接、提取 Jira 信息、查找文档，并利用 Sourcegraph 和 MCP 定位相关代码。

让大语言模型自行寻找上下文是最不可控的部分，因此这部分工作（其规则可被硬编码）被移出了模型的处理范围。

任何能用确定性逻辑解决的问题都不会交给概率模型；而这条界限的划定，决定了整个流程是否可靠。

最反直觉的一点是：Minions 并不是基于更强大的模型构建的。

它实际上是开源工具 Goose 的一个分支，其核心主张是可靠性来自于约束条件的质量，而非模型的规模。

它的架构将确定性门控与创造性大语言模型步骤交错结合，如图5所示：Agent 编写代码，一个硬编码的流水线运行代码检查器且代理无法跳过该步骤，代理修复检查问题后，再由一个硬编码步骤执行提交操作。

沙箱环境使用 EC2 上的 Devbox，并以“牲畜而非宠物”的方式运行：每个环境可随意替换，因此上千个代理可以同时运行而互不干扰。

值得注意的是，这1300个拉取请求仍然由人类进行审查：人类并未离开，而是从编写代码转向了代码审查工作。

C. “当你睡觉时”实际上依赖的是什么

本地/循环任务和桌面定时任务需要设备处于开机状态；一旦关机，循环就会停止。

若要在设备关机时运行，正确的选择是使用云流程或 GitHub Actions 的定时触发器。

表 IV 对比了这些选项。

如果希望执行频率高且能访问本地文件，请使用本地/循环方式，但需承担持续保持设备开机的成本。

机器已启动。想要脱离本地状态独立运行？

那就上云吧，但每次至少需要一小时的间隔，并且要重新克隆一份干净的实例。

没有单一的调度器能包办所有事情。

关于广泛流传的数据需谨慎对待：诸如“Claude代码中约90%由其自身编写”或大幅提速迁移速度等说法，大多是二手转述，应视为粗略参考。

此处的三个案例均源自一手资料，比一个听起来令人印象深刻的数据更具可信度。

D. 实践中的调度器选择

本地调度与云端调度的选择并非个人偏好问题，而是由一个简单问题决定的：

循环任务是否必须绑定在本地机器上运行，还是可以脱离本地？

两个具体场景能清楚说明这一规则。

假设某个循环需要每分钟检查一次本地开发服务器，这项任务只能在本地运行，因为云端无法访问笔记本电脑上的进程，且云端任务间隔不能短于一小时。

反过来，如果某个循环需要在凌晨三点扫描代码库中的开放问题，并在必要时创建拉取请求，那么这项任务绝不应绑定在笔记本电脑上，因为笔记本会合上盖子、断电或被带出门外。

对于这种情况，使用云端调度或CI（持续集成）调度触发器才是正确选择，让任务在人类睡觉时仍能在始终开机的机器上持续运行。

需要避免的误解是将本地重跑等同于“睡眠时运行”的全部含义。

本地重跑指的是“在我在场时多运行几轮”，而云端调度则意味着“即使我不在，也能持续运行”。

这是两种不同的能力，若将二者混为一谈，就会导致用户合上笔记本盖子后，原本以为能自主运行的循环却悄然停止，从而感到失望。

更准确的说法是：本地调度以机器必须保持开机为代价，换取更高的执行频率和对本地文件的访问；

而云端调度则以较低的执行频率和每次运行都需要重新克隆为代价，换来真正的自主性。

没有一种调度器能兼顾所有需求，成熟的循环通常会结合两者使用：用本地调度处理频繁的内部检查，用云端调度完成夜间的大范围扫描。

同样的能力，两种工具链本笔记中的命令属于Claude Code，但这些功能并非其独有。

Codex提供了相同五种功能，只是名称不同，且为一侧编写的连接器通常可直接迁移到另一侧使用。

表V将它们一一对应排列，以免读者将命令名称误用于错误的功能。

其要点在于：循环工程是一组能力，而非单一产品：包括调度、运行至条件满足、并行隔离等。

子代理、外部连接和明确的技能调用。

无论团队使用哪种工具链，需要考虑的问题是这六项是否全部具备，而不是哪种品牌的命令提供了它们。

VIII. 成本：四个无法自动关闭的标签页

一个自行运行的循环，同时也是一个自我犯错的循环。它运行得越欢快，错误就越悄然发生。

四种成本随之产生，而这些成本在循环运行时均不会发出警报。

验证债务。

每一次打开并合并的 PR 都能节省时间，但节省下来的时间却变成了未经验证的输出，等待着被偿还。

问题隐藏在测试未能覆盖的地方，在“运行”与“正确”之间的缝隙中不断累积，直到某个发布当天突然爆发。

而守卫则是一个独立的评估者：一个与执行工作的人不同的代理。

理解的滞后。

循环越快地运行那些自己未曾编写的代码，现实与实际理解之间的差距就越大。

阅读代码比编写代码更枯燥，而循环却取代了编写的过程；代码库不断增长，而脑海中的地图却停滞不前。

直到某个漏洞悄然潜入从未读过的角落，才发出警报。

应对之策是定期审视循环的输出，并强迫自己解释几处变更；若无法解释，则说明地图需要更新。

认知上的放弃。

当循环自行运行时，人们很容易不再坚持自己的观点，而只是接受它返回的结果。

这与前两种情况的态度版本不同：不是“没时间”，而是“不再想费心”。

循环越可靠，就越容易将判断权外包出去。

守卫只是一行代码，循环可以执行，但无法做出决定。

人至少必须仍保有说出“这是错的”的能力。

令牌耗尽。

这是唯一会直接且难以提前预估的开销：循环不断触发辅助程序、重试并一轮接一轮地运行，因此一个漏洞可能整晚空转，产生一份陌生的账单，而非修复后的代码。

而防护机制则通过在发布前设定硬性上限，每次运行预算、每日预算、最大重试次数，从而防止空转的漏洞消耗整晚的配额。

这四者有一个共同点：循环运行时保持沉默。

循环工程最迷人的地方在于，它能让一个人完成整个团队的工作；

而最危险的地方也恰恰在此，因为团队内部会彼此争论，但一个人加上一堆循环，很容易变成一个回音室，无人质疑，无人争辩。

A. 债务累积的实例说明

设想一个循环，一夜之间提交了二十个拉取请求，所有测试都显示通过。

表面上看，这是一次胜利。

但假设这二十个请求中有三个包含了测试未能覆盖的细微错误。

由于没有独立的审核者，这三个请求最终被合并，这就是验证债务。

因为人只是机械地合并了二十个请求而未阅读内容，他对代码库的心理模型因此落后了二十次变更，这就是理解腐化。

由于循环运行得过于顺畅，第二天早上这个人干脆完全不再查看新一批请求，这就是认知放弃。

再加上这个循环整夜自动调用助手并不断重试，最终成本变成了最初预估的三倍，这就是Token暴增。

那三个隐藏的错误如今就存在于一个人已无法完全理解的代码库中，由一个停止审视的人守护着，直到其中某一个最终以生产事故的形式暴露出来才被发现。

这个实例的关键在于，这四项成本并非独立的风险列表，而是一个以四种面貌呈现的单一失败。

它们相互强化：循环产生的未经验证的输出越多，人类的理解就越少；

理解越少，就越容易放弃控制；放弃得越多，循环运行无人监督的时间就越长，账单也就越大。

图6展示了这种增强循环。

防范这四种风险的方法是一致的：保持一个能够说“不”的人，并设置一种无需此人清醒也能运行的检查机制。

IX. 做一名工程师，而不仅仅是按下启动键的人

同一个循环，由两个人分别构建，却可能导向截然不同的结果，而这种差异并不在于循环本身。

正如奥斯曼尼所写，两个人可以构建相同的循环，却得到相反的结局。

一个人用这个循环来加速掌握已知领域：

他们阅读代码，保持清晰的方向感，循环放大了他们原有的判断力；

另一个人则用同样的循环，让自己再也不必真正理解。

六个月后，前者变得更强，而后者却成了一个自己无法读懂的机器的守门人。

循环并非一种由工具本身决定其品质的工具。

它极为强大，能原封不动地放大你所投入的一切：

投入理解，它就放大理解；投入懒惰，它就放大懒惰。

它是一个忠实的乘号，而它所乘的对象正是人本身。

循环使得生成变得极其廉价：代码、计划，

PR、修复、几乎免费。

真正稀缺的却是判断力：知道哪个方案正确，哪条生产线该停，哪个输出看似正常却根本上是错误的。

循环可以生成上百种选项，却无法真正做出选择；

或者说，它只根据“看起来合理”来选择，而非“实际上正确”，而这两者之间的差距，正是工程师存在的意义所在。

因此，循环工程并未贬低判断力，而是剔除了所有无需判断的部分，让判断力成为唯一剩下的核心。

循环会执行赋予它的逻辑，却无法理解为何要构建它、真正想要什么，或哪些部分更希望亲自监督。

这些界限，手动检查点的位置、自动运行的区域，无法从循环本身读取；它们只存在于构建者脑海中，必须逐一写入。

你设计时的心态，决定了循环最终的形态。

两个代码上九成相同的循环，一个出自“快速摆脱束缚”的心态，另一个出自“我仍想做工程师”的心态。

区别可能仅在于一两个检查点，而正是这些差异，决定了六个月后你是站在循环之上，还是被它掏空。

奥斯马尼的结语值得铭记：去构建循环，但要以一个打算继续做工程师的心态来构建，而不仅仅是按下启动键的人。

X. 判断的经济学

上一节提出了一项值得单独审视的观点：循环使生成变得廉价，却让判断变得稀缺。

这并非一句口号，而是一项具有经济意义的观察，对团队的组织方式有着深远影响。

A. 什么会变得丰富

当某种资源变得丰富时，其价格就会下降，围绕它的活动也会随之重组。

循环让代码、计划、修复和拉取请求变得丰富起来。

一位拥有良好构建循环的工程师，就能产出相当于一个小团队的工作成果。

过去需要耗费工程师一整天时间的活动，比如打字、重复模板代码和机械性的重构，如今成本几乎降为零。

人们的第一反应可能是，这会让工程师的价值降低。

但事实恰恰相反，只是对于那些仍掌握稀缺资源的工程师而言才是如此。

B. 什么依然稀缺

稀缺的资源是决定保留哪一个丰富输出的判断力。

一个循环可以生成上百个候选实现方案，但它无法告诉你哪个是正确的，只能指出哪个看起来合理，而“看起来合理”与“确实是正确的”之间的差距，正是工程学存在的核心所在。

当生成变得近乎免费时，工程师的全部价值便集中于这一差距之中。

剩下的工作纯粹是判断，它被过去围绕其周围的机械劳动所提炼和净化，不再掺杂杂质。

这带来了一个令人不安的含义。

一位原本价值主要体现在机械劳动上的工程师，快速打字、广泛记忆API、愿意反复处理重复代码，会发现自己的价值正在消失，因为这个循环可以免费完成所有这些工作。

而另一位原本依靠判断力取胜的工程师，则会发现自己的价值被放大了，因为循环能将他们做出的正确决策执行上百次。

同样的工具拉大了这两类工程师之间的差距。

它不会让每个人同等受益，而是会放大每个人原有的能力。

放大器具有双面性由于循环会放大判断，判断上的失误也会被放大。

在旧世界中，一个错误的决定只会导致一段手写的错误代码，其影响范围有限，且速度较慢，足以让人及时发现。

而在新世界中，一个错误的决定会被机器忠实地批量执行上百次，而机器不会停下来询问是否正确。

这种循环去除了过去能挽救工程师的缓慢机制。

人们再也无法指望流程足够缓慢，从而在运行中途察觉到错误，因为流程本身已不再具备任何缓慢的环节。

这使得唯一无法由循环完成的事情变得至关重要，也正因如此，保持工程师本色的准则不再是可有可无的情感选择，而是操作上的必然要求。

XI. 运营纪律

如果判断力是一种稀缺资源，那么实际的问题就是如何更好地运用它。

根据上述案例和成本分析，有三条原则值得作为常规做法加以强调。

A. 阅读样章，始终如此

防范理解退化的办法，并非要读完循环产生的所有内容，那样反而违背了初衷，而是每天阅读一个具有代表性的样本，并强迫自己解释每一个被选中的变更：

它做了什么，以及为何以那种方式实现。

无法解释某个变更，正是表明自己的心智图谱已落后于代码库的明确信号，而比起在糟糕的一天因生产事故才发现这一点，不如在安静的早晨通过一个抽样提交来提前发现，成本要低得多。

样本无需庞大，但必须定期进行，并真正深入审视。

B. 发货前请检查

防止Token暴增的防御措施，是在循环首次无人值守运行前就设定严格的上限，而不是在出现第一张意外账单后才设置。

每次运行的预算、每日预算以及最大重试次数共同确保，单个漏洞即使整夜空转，也无法耗尽全部配额。

这些数值的主要目的并非节省成本，而是作为熔断器，将无限风险转化为可控风险。

没有上限的循环，就是将自身的消费权限交给了其内部的漏洞。

C. 保持一扇门敞开

对认知放弃的防御是结构性的，而不仅仅是态度上的。

在循环中至少设置一个检查点，让其暂停以等待人类介入，并非因为人类总能干预，而是因为这种暂停的存在使人类始终保有干预的可能性。

那位焊死每一扇门的工程师，自以为永远无需进入，却在必须进去的那天发现，自己已不再掌握钥匙。

而那位留一扇门敞开的工程师，则随时可以走进去查看循环的运行情况。

这两个循环的区别，仅在于一个检查点。

六个月后，谁掌控局面的情况大不相同。

XII. 今天就打造你的第一个循环

Stripe 的流程是终点，而非起点。第一个循环应该非常小，几乎看不出是个系统：只是一个定时检查某件事的小功能。

第一步：运行一个 /loop。

该功能在 Claude Code v2.1.72 版本后可用，可按设定间隔重复执行相同任务。

它具有会话作用域，重复任务七天后过期，并且在本地机器上运行；一旦关闭机器，任务即停止。

第二步：阅读CI和问题；

先进行分类处理。重新运行一行代码不构成循环。

每天早晨给它一个提示，让它查看三件事，并列出值得处理的内容。

计划任务加上自动发现是进入循环的基础。

发现逻辑应存在于技能中，而不是在计划里。

第三步：添加一个状态文件。

请勿将结果留在聊天中将每项发现及其处理进度记录到一个 Markdown 文件（或Linear 板）中。

Agent会遗忘，而仓库不会。

第四步：添加评估器。

这是最关键的一步，也是最容易跳过。

Claude Code 的 /goal（在 v2.1.139 之后）会一直运行，直到满足某个条件为止，而该条件由另一个模型来判断是否成立。

第五步：添加工作树以实现并行处理。

使用 --worktree（或 -w）为每个后台代理开启独立的工作树，避免它们相互干扰。

在表六的六个要素中，前两个决定了是否

循环可以运行；

最后四个环节决定了它一旦启动是否会陷入困境。

初学者通常只构建前两个环节，结果就是形成一个无人关注、也无法停止的循环，只能自我点头。

最后的建议很简单：第一个循环最好小一些，但必须完整配备“否定”检查机制和人工审核节点。

A. 完整的第一圈，附注解

为了使清单具体化，以下是安装全部六个要素的最小但完整的循环。

它足够简短，可一次性读完，并包含真实循环所需的所有器官，只是按比例缩小了而已。

从上到下阅读，这六条编号的评论就是这六条。

清单中的每个要素都用两到三行代码实现。

cron 行用于调度；

技能调用用于发现；

已提交的状态文件用于持久化；

每个发现对应的工作树用于交接；

/goal 停止检查加上审核人用于验证；

而永不自动合并的规则配合收件箱则实现了人工审核。

一个包含全部六个要素的循环，哪怕再小，也是一个真正的循环。

缺少其中任何一个要素的循环，就是第六节中五种失败情况之一，只是披着伪装罢了。

B. 安全地扩展循环

一旦最小化的循环开始运行，人们就容易想对其进行扩展，发现更多问题、增加并行代理数量、缩短执行间隔。

安全的增长顺序是：在验证检查机制有效之后，最后再引入并行性。

应先提升循环的检测能力，再增加其并行处理的程度；

必须先证明评估器能够准确捕捉真实错误，才能放心地让它同时控制大量代理。

Stripe 的案例正是这一路径的终点，而非起点：它的可靠性源于多年来对确定性控制机制的不断打磨，而不是一开始就大规模部署。

一个循环只有先证明自己能阻止单个出错的代理，才有资格去运行更多的代理。

附录A：带注释的分诊技能

发现式操作依赖于技能而非一成不变的指令，因为技能可以重复使用并持续维护，而复制粘贴的提示则会在无人更新的日程中逐渐失效。

以下是贯穿全文所提及的晨间分诊技能的完整版本，并附有注释，说明每个部分如何服务于特定的操作目标。

技能的六个标题中有五个对应于五种操作；

第六个“停止”部分，是构建者写下循环无法推断出的边界的地方。

循环会严格执行技能中规定的所有内容，而忽略其中遗漏的部分，因此“停止”部分并非模板化内容，它是工程师明确表达控制权归属位置的唯一永久性设定。

若省略此部分，循环将自信地合并，但这种自信并未经过验证。

XIV. 附录B：术语表

XV. 综合：剧本的实质内容

在九个部分中，论证贯穿一条主线。

循环工程是自提示开始、经由上下文和框架层层递进的第四层结构，它与下方三层的区别在于，它将人类从执行工作的角色中移除。

一个循环的单次运转包含五个步骤——发现、移交、验证、持久化和调度——由六个组件实现，而循环的失败仅表现为这些步骤中的某些被跳过。

其中最困难的步骤是验证，因为一个代理若自行评估其工作成果，便会自我褒奖；

可靠的解决方式是结构性的：引入一个独立的评估器，它默认持怀疑态度，采取行动而非被动阅读，并由一个新模型在明确的停止条件下进行评判。

目前循环已在实践中运行，从一位工程师的早晨工作到一家企业每周合并上千个机器生成的拉取请求，它们之所以可靠，关键不在于模型的规模，而在于约束条件的质量。

循环会积累四种隐性债务：验证债务、理解退化、认知放弃和令牌膨胀，这些债务相互强化，并最终同时到期。

由于循环会放大建造者所带入的一切，因此由两个人构建的相同循环会产生相反的结果，而这种差异往往取决于一两个关键节点，这些节点决定了后续谁将掌握控制权。

值得铭记的一句话，是整个领域在一周内达成共识的：停止直接提示代理，而是设计一个能提示它的系统，但要像一位打算长期做工程师的人那样来设计，而不仅仅是一个按下“开始”键的人。

本笔记中的“技术”服务于这一姿态。

评估者、状态文件、预算上限、开放的大门：每一种都是为了确保人类能够对一台被设计成高速说“是”的机器说出“不”。

循环正是当今软件实践中最强大的工具，恰恰因为它最忠实地放大了其创造者的判断力，而这种忠实的放大器的价值或危险性，正与输入其中的判断本身一样。

A. 第一个月的田野笔记

对于采用循环机制的团队，有几点实用观察反复出现，值得明确指出。

首先，能够存续下来的循环是那个赢得信任的小型循环，而非那些要求信任却未能实现的宏大循环；

应从一个端到端处理的单一发现开始，只有在检查机制真正捕捉到错误后，再逐步扩大范围。

其次，评估环节才是工程投入的关键所在：一个强大的生成器搭配一个薄弱的判断者，只会产生自信满满的垃圾成果；

而一个适度的生成器配合一个敏锐的判断者，则能带来缓慢但可靠的进展，而后者才是真正累积价值的部分。

第三，人工审核环节并非一旦循环被信任便可移除的临时脚手架；它恰恰是维持循环可信性的永久性特征，一旦移除，理解力的衰退便将真正开始。

第四，预算上限应基于“某些任务会整夜空转”的假设来设定，因为最终总会发生这种情况，而这个上限决定了日志中的一条记录与账单上的一项支出之间的区别。

这些单独来看都不足为奇。

令团队感到惊讶的是，一个“自动运行”且体验良好的循环，会迅速侵蚀当初使其成功所依赖的严谨规范，而这种侵蚀过程在发生时往往难以察觉，直到某天早晨突然发现系统出错才意识到。

归根结底，关键不在于构建循环，这部分如今确实很容易实现，而在于始终保持自己作为一名工程师的能力：无论在哪个清晨，都能判断出刚才循环所做的操作是否真的正确。

鸣谢。

本文是一份独立的会议风格综述，基于华书开放指南《循环工程：别再问我它是什么》（橙色书籍，2026年6月15日版，第260615卷）的框架构建。

该框架及引用表述由Addy Osmani提出；生成器/评估器相关发现归功于PrithviRajasekaran（Anthropic）；企业案例则来自Steve Kaliski（Stripe）。

所有产品细节可能随时变更，请参考各工具的官方文档。

-END-

你准备开始实施一个简单的 Loop Engineer 了吗？

腾讯邮箱为 Agent 专门开了一个邮箱：https://agent.qq.com。

我的是：hyaimemo@agent.qq.com。