循环工程全读本：从五动作六部件到你的第一个循环

过去两年，提示词工程、上下文工程、框架工程随模型发布的节奏接连登场，最新的一个是循环工程（Loop Engineering）：2026 年 6 月的一周内，Peter Steinberger、Boris Cherny 与 Addy Osmani 先后独立提出同一件事，Osmani 随后正式命名。它与此前三层最大的不同在于：不再教从业者把工作做得更好，而是把从业者从“做工作”的位置上移除。本站此前发过这篇指南的精读拆解（别再给 AI 写提示词了：让系统自己提示自己的循环工程），本文是更完整的全读本，逐节展开论证、案例与附录配方，并以构建第一个循环的具体配方收尾。

I. 引言：循环工程到底是什么

提示词工程的课程还在卖，上下文工程的墨迹未干，框架工程刚被写出来，现在循环工程也来了。过去一年，这些“XX 工程”术语几乎与模型发布同步出现，想翻白眼是可以理解的。

但这一次不同：它不是关于把工作做得更好，而是关于把从业者从做工作的位置上完全移除。之前的术语都假设一个人坐在键盘前，逐行指挥 Agent，循环工程删除了这个假设。从业者不再在循环内部，而是在循环外部，构建循环。

A. 一句话定义

给这个术语命名并写下来的人是 Addy Osmani，Google Chrome 团队的工程师。他的定义很短：循环工程是取代自己成为给 Agent 发提示词的那个人，转而设计做这件事的系统。 人不再逐行喂给 Agent，人设计喂它的系统。这句话的重心落在“取代你自己”上，这是位置的转变：从做发动机的人，变成设计发动机的人。人写的东西不再是给 Agent 的词句，而是一个自动把词句发给 Agent 的东西。

B. 一周之内，三个人点燃了引信

这个术语不是凭空发明的。在 2026 年 6 月的一周内，几组人几乎同时碰到了同样的事。引爆点是 Peter Steinberger（OpenClaw 作者）的一篇帖子，浏览量超过 800 万：人不应再给编码 Agent 写提示词，而应设计给 Agent 写提示词的循环。 几乎同一时刻，Boris Cherny（Anthropic Claude Code 负责人）在说同样的话：他不再给 Claude 写提示词，而是让循环运行着去提示 Claude 并弄清楚该做什么，他的工作是写循环。6 月 7 日，Osmani 在博客上以“Loop Engineering”为题写了下来，引入了 Steinberger 和 Cherny 的说法，第二天同步到 Substack。一次点燃，一次回响，一个名字，全在一周之内。

叠在一起，三段话指向同一个动作：人设计的东西从 Agent 的单个行为，转移到了驱动 Agent 的整个系统。 和之前的“vibe coding”一样，这个词听起来可能粗糙，但它把一种工作方式变成了可以被讨论的东西。

C. 为什么这个词现在出现

值得问为什么三个从业者互不通气，却在同一周用了同一个词。答案是周边的工具已经悄然越过了阈值：编码 Agent 变得足够可靠，能无人值守完成非平凡任务；调度原语在主流框架中出现了；单次 Agent 运行的成本下降到足够低，以至于按定时器重复运行不再显得浪费。当所有部件就位时，组合它们的动作对所有人同时变得显而易见。名字比实践晚了数月：人们已经在写循环了，在有人叫它“循环工程”之前，就像团队在生成器/评估器分离有名字之前，就已经在配对写作 Agent 和审查 Agent 了。

这个模式（实践先行，命名随后）值得记住，因为它告诉读者去哪里找下一个术语：它不会来自模型发布，它会来自某个新能力变得足够便宜，以至于之前不可想象的组合变成日常的那一刻。

D. 框架之上的一层

这个转变可以缩减为两句话。在旧世界里，人坐着逐行提示 Agent，它完成一件事，停下来，等着；人是循环内部的人类时钟，每一次滴答都必须来自人。在新世界里，人设计一个自己滴答的东西：它按定时器运行，生成帮手去做工作，把自己的结果反馈给自己。

如 Osmani 所说，循环工程位于框架之上的一层楼：下面的框架武装单次 Agent 运行，上面的循环让它一遍又一遍地自行运行。变化在于身份，从操作 Agent 的人变成调度 Agent 的人。价值从“知道怎么指挥”转移到“知道怎么构建循环，以及怎么在循环里放一个能说‘不’的检查”，最后这部分是最难的，后面的章节会解释。

II. 从提示词到上下文到循环

“XX 工程”的术语不是互相替代的，它们堆叠在一起，每一层管理更大的东西，见表 I。

A. 四层各管什么

提示词工程是最底层，也是最有名的，它管理告诉模型什么：措辞、示例、角色、语气。它的边界是一次交换，问题在于它假设人每次都在场递交提示词。

上下文工程把问题从“我说什么”提升到“这个窗口里应该放什么，模型才能解决问题”。它管理模型的整个视野：检索什么、如何总结、清除什么陈旧信息。满窗噪声会浪费最好的提示词。

框架工程管理一次运行中 Agent 需要携带的东西：哪些工具、哪些动作、何时加载上下文、如何从失败中恢复、什么状态算完成。它武装一次运行，但不会让那次运行重复。

循环工程自动化掉了“等你”的部分。前三层到位后，Agent 干净地跑一次然后停了；循环给它装上定时器，让它按计划醒来，生成子 Agent 并行工作，把自己的输出作为下一轮的输入反馈回去。

B. 上一层楼实际增加了什么

三个动词区分了框架和循环。按定时器运行：循环按计划醒来，无需按键。生成帮手：运行中的循环分裂出子 Agent，一个起草改动，另一个只负责挑刺审查。自我反馈：循环产出的东西成为自己下一轮的输入，昨天的发现写到文件里，今天早上读那个文件继续。这种跨对话的记忆，就是它是循环而不是一次性任务运行多次的原因。

C. 每一层的失败有不同的爆炸半径

考虑同一个底层 bug（Agent 误读了函数返回值）在各层的表现。在提示词层，误读产生一次交流中的一个错误答案，人立即看到并重写提示词。在上下文层，误读来自加载到窗口中的过时文档，人注意到答案自信地错了，清除上下文。在框架层，Agent 基于误读行动一次，也许编辑了文件，但运行结束，diff 可见，人在发布前审查。在循环层，同样的误读被写入状态文件，第二天早上被当作既定事实读回，并在多轮中被在其上构建，等任何人查看时，错误的假设已经成了承重的部分。

这是循环工程中最重要的直觉：错误的代价与它在被发现前存活的轮次成正比，而循环按其构造就是一个最大化轮次的机器。 后面所有的内容（评估器、人类检查点、预算上限），都是为了缩短错误与发现之间的距离。

III. 循环的五个动作

“循环”这个词容易被误读为空转，每一轮做的是具体的事：找到值得做的工作，交给 Agent，验证结果是否正确，保存状态，然后决定下一步。丢掉五个动作中的任何一个（发现、交接、验证、持久化、调度），循环就不会转，或原地转。

A. 一个具体例子

Osmani 给自己建了一个晨间分诊循环。早上，自动化自动启动：一个分诊 Skill 读取昨天失败的 CI 测试、仍然打开的 issue、最近的提交，把结果写进 Markdown 文件或 Linear 面板。对于每个值得行动的发现，它打开一个隔离的 worktree；一个子 Agent 起草修复，第二个对照项目的 Skills 和测试审查；连接器自动打开拉取请求并更新工单。它处理不了的东西进入收件箱等人处理，状态文件保存下来，让第二天从今天停下的地方继续。没有一步需要人动手，但它在应该等人的地方停下来等人。

B. 各个动作

发现弄清楚这一轮该做什么，关键是让 Agent 自己找工作，而不是被递一份清单；自动化触发的应该是一个 Skill（永久化的知识），而不是粘在没人更新的 cron job 里的一堆指令。发现设定了整个循环质量的上限：找出没有价值的工作，其他四个动作就在为无价值的服务中完美执行。

交接把任务从调度系统移到干活的 Agent 手里。每个值得做的发现获得自己的隔离 git worktree，多个 Agent 在独立目录中改代码互不干扰。任务切得越干净，后面的验证和合并越容易。

验证是最容易被偷工减料的动作，也是最不可省的。第一个子 Agent 起草修复后，第二个子 Agent 审查它，不同指令，有时是不同模型。写代码的 Agent 给自己的作业打分太松，专门的挑刺者能抓住第一个 Agent 说服自己放过的东西，这就是**“能说不的东西”**。没有真正检查的循环，只是 Agent 在向自己点头。

持久化把结果落在能超越对话的地方：通过连接器创建 PR 和更新工单，处理不了的进收件箱，状态文件记录进度。循环的记忆不能只活在上下文窗口里，写到 Markdown 或面板上的东西不会遗忘。

调度让一轮变成循环：分诊每天早上自动运行，状态文件让未完成的发现延续到第二天，第二天自行接续。如 Osmani 所说，自动化才是让循环成为真正循环而不是一次性运行的东西。

IV. 六个部件：循环由什么构成

如果“动作”描述一轮里发生了什么，“部件”描述让它能转必须手上有什么。两者对应：发现运行在 Skills 上，交接运行在 worktree 上，验证运行在子 Agent 上，持久化运行在记忆上，调度运行在自动化上。

自动化让循环自行启动，挂在调度或触发器上。没有调度，人手里的是一次运行，不是循环。自动化应该触发一个命名的 Skill，而不是 cron job 里的一大堆指令。调度有多种形式：本地的（机器必须开着）和云端的（机器关了也跑）。

Worktree 是 git 内置的多工作目录机制。它们的价值随并行度增长：两个 Agent 同时写同一个文件，和两个工程师提交同一行的头疼程度一样。Worktree 把并行从“能跑但脏”变成“能跑且干净”。

Skills 把项目知识永久化在单个文件（SKILL.md）里，Agent 不必每轮重新推导上下文。Osmani 把它们偿还的成本命名为意图债：一遍又一遍解释“这个项目是什么、规则是什么、陷阱在哪”的代价。Skill 可以复用和维护，提示词墙不能。

连接器（基于 MCP）把循环挂到外部世界：issue 跟踪器、数据库、staging API、Slack。只能看到文件系统的循环是个小循环，连接器决定循环的视野半径。为一种工具写的连接器，通常可以直接挪到另一种工具上用。

子 Agent 把写代码的和评判的分开。当一个 Agent 既当运动员又当裁判时，裁判偏袒。反直觉的是，调优一个独立的评判者去挑剔，远比让生成器对自己的工作苛刻要容易，这就是为什么循环要保留一个额外的 Agent，而不是让一个 Agent 审查自己。

记忆是活在对话之外的持久状态：Markdown 文件或面板。上下文窗口一清，Agent 什么都不记得；循环要今天从昨天停下的地方继续，记忆必须落在磁盘上。Agent 会遗忘，仓库不会。 记忆不是上下文：上下文是 Agent 这一轮看到的，刷新时清空；记忆跨轮跨天持久存在。

六个全部到位，循环就有了骨架：自动化让它动，worktree 防止它自相残杀，Skills 防止它重复劳动，连接器让它看到外面，子 Agent 让它自我纠错，记忆让它记住。但搭建只是开始：同一套部件，两个人建，可以完全相反。

V. 生成器与评估器

循环最难的部分不是让 Agent 运行，而是在里面放一个能说“不”的东西，而写代码的 Agent 最不可能说它。

A. 它总是赞美自己

让 Agent 给它刚产出的东西打分，它倾向于自信地赞美，即使人可以清楚地看到质量平庸，正如 Anthropic 工程师 Prithvi Rajasekaran 在构建长时间运行的应用时观察到的。这不是聪明问题，这是给自己的作业打分：代码写入的上下文已经塞满了“为什么这样写”的理由，所以当 Agent 看自己的输出时，它看到的不是结果，而是导致那里的自我说服链条。在循环里这个缺陷被放大：如果每个“这够好了吗”都由刚写完的 Agent 决定，每轮它都在向自己点头，跑得越久，偏离真实质量越远。

B. 调优怀疑者，别修谦虚的作者

让生成器更自我批判，效果很差。Rajasekaran 发现，调优一个独立的评估器去怀疑，远比让生成器对自己的工作苛刻要可行。差异是结构性的，不是措辞问题：人不能要求作者走出自己的视角，但人可以换一个指令完全不同的 Agent，从头看代码，不带任何自我说服。这个想法借自生成对抗网络（GAN，一个网络构建，一个挑错），移植到写代码的生成器和审查的评估器上。

C. 评估器应该行动，而不只是读

换 Agent 不够。如果评估器只读代码，它评判的是“这看起来对吗”，不是“这跑起来对吗”。在前端任务上，Rajasekaran 把评估器接到 Playwright MCP，让它能打开页面、点击按钮、截图、检查 DOM，像 QA 工程师一样。这把判断基础从“这个 JSX 看起来没问题”转移到“我点了按钮，页面导航了，这是截图”。换底层模型也有帮助：同一个模型换新指令，往往保留盲点。社区常见的校准方式是告诉评估器**“假设代码是坏的，除非证明不是”**，默认立场应该是怀疑，不是信任。

D. 在产品中：对停止条件使用 /goal

循环最难的部份不是让 Agent 跑起来，而是在里面放一个能说“不”的东西。Claude Code 把这个结构变成了原语 /goal：给 Agent 一个条件，让它跑到条件满足。

# 评估器 Agent (.claude/agents/reviewer.md)
ROLE: 对抗性代码审查者。
ASSUME: 这段代码是坏的，除非证明不是。
DO NOT 赞美。找出失败的地方。
CHECK，按顺序：
1. 它能跑吗？（执行，别只读）
2. 测试：运行它们，粘贴真实输出。
3. 作者跳过的边界情况。
4. 行为是否匹配工单？
USE Playwright MCP：打开页面，点击，
截图，检查 DOM。评判行为，不是意图。
VERDICT: 只有所有检查通过才 PASS。
否则 REJECT + 列出每个原因。

# 停止条件，由一个新鲜的小模型判断
/goal test/auth 中的所有测试通过且 lint 步骤干净

关键是，每轮后由一个小而快的模型检查条件是否成立；如果不成立，运行另一轮而不是返回控制。完成由一个全新的模型决定，不是干活的那个。这是制作者与检查者分离的原则（在银行业已有几十年历史：录入大额转账的人和审查的人必须不同）应用到停止条件上。

循环的地板是它的评估器。 生成器的水平决定循环能产出什么，评估器的水平决定它不会产出什么。结构上分离生成和判断，把评估器调教成怀疑者，让它通过行动验证，把最终决定权交给一个全新模型，这四步就是培养循环说“不”的能力所需的全部。

VI. 循环失败的五种方式

在转向成功的循环之前，值得编目它们失败的方式，因为失败比成功更有启发性，也更常见。下面的每个反模式对应五个动作之一被跳过或做差。

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

最常见的失败。循环跑着，Agent 写代码，同一个 Agent 宣布它没问题。没有独立检查，每轮产出自批准的输出，循环以机器速度积累看似合理的错误。症状是一个循环在数百轮中从未对自己说过“不”，对任何真实工作负载来说这在统计上不可能，因此证明没有真正的检查存在。修复是前面章节的生成器/评估器分离。

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

循环发现了好工作，做了，然后忘了它发生过，因为结果只存在于被刷新掉的上下文窗口里。下一轮重新发现同样的工作，或更糟，重做它并和第一次尝试冲突。症状是循环没有累积进展：每天早上从同一个地方开始。 修复是磁盘上的状态文件，Agent 会遗忘，仓库不会。

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

循环有四个好动作但没有自动化；它不是循环，是人手动运行然后就忘了再运行的脚本。它在搭建那天效果惊人，注意力一走开就悄悄停了。症状是循环的最后一次运行是它演示的那天。 修复是一个真正的触发器（定时器或事件），不依赖人记住。

D. 盲目循环（跳过发现）

人仍然每天早上递给循环工作（“修这三个 bug”），所以循环自动化了做，但没自动化找。这省的比看起来少，因为选择做什么往往是昂贵的部分。症状是人仍然花早上时间决定循环该干什么。修复是把发现教进 Skill，让循环自己浮现工作。

E. 纠缠循环（跳过交接）

循环并行运行多个 Agent，但让它们都改同一个工作目录，编辑冲突，合并一团糟没人能理清。症状只在并行下出现：单 Agent 循环看起来没问题，第一个早上五个 Agent 同时运行，问题就出现了。 修复是每个任务一个隔离的 worktree。

这五种不是独立的。缺少验证的循环通常也缺少持久化，一个不在意一种检查的团队通常不在意其他的。实践中它们成簇出现：纪律严明的循环安装全部五个动作，仓促的循环只安装发现和交接（两个产生可见输出的），跳过三个产生安全的。

VII. 睡觉时运行的循环：三个真实案例

三个公开案例在规模上天差地别，但共享一个骨架：触发器按下开始，一组约束让它保持在轨道上，人类检查点坐在终点。“睡觉时运行”从来不是关于模型有多强，而是关于那个骨架有多稳。

A. 一个工程师的早晨

Osmani 的分诊循环（在第三节中拆解过）每天早上自动运行。一个值得重申的细节：自动化触发的是一个 Skill，不是粘在没人更新的调度里的一大堆指令。 这就是一个人能运行的循环长什么样：一个人、一台机器、每天早上干掉粗活。

B. Stripe 的 Minions：每周 1300 个 PR

企业规模上值得研究的案例是 Stripe 的 Minions：每周合并超过 1300 个拉取请求，没有一行手写，Stripe 工程师 Steve Kaliski 在 How I AI 播客中如此描述。触发器很轻：在 Slack 里 @机器人，或加一个表情反应。让它可靠的是模型醒来之前的那段：确定性编排器先组装上下文，扫描链接、拉取 Jira、找文档、通过 Sourcegraph 与 MCP 定位相关代码。让 LLM 自己找上下文是最不可控的部分，所以能被硬编码的那部分工作被从模型手中拿走：任何确定性逻辑能解决的，永远不去碰概率模型。

最反直觉的点：Minions 不是建立在更强的模型上。它是开源工具 Goose 的 fork，其核心主张是可靠性来自约束的质量，而非模型的大小。 它的架构交错确定性门和创造性 LLM 步骤：Agent 写代码，硬编码管线运行 linter 且 Agent 不能跳过它，Agent 修 lint，硬编码步骤运行提交。沙箱是 EC2 上的 Devbox，按“牲畜不是宠物”的方式运行：每个环境随意替换，千余个 Agent 同时运行互不干扰。值得注意的是，那 1300 个 PR 仍然由人类审查：人没离开，只是换了桌子，从写代码换成了审查代码。

C. “睡觉时运行”实际依赖什么

本地 /loop 和桌面定时任务需要机器开着，关机了循环就停了。要机器关了也跑，正确的答案是 Cloud Routines 或 GitHub Actions 定时触发器。

要避免的扭曲，是把本地重运行当成“睡觉时运行”的全部。 本地重运行意味着“我在的时候多跑几轮”，云端调度意味着“我不在的时候也跑”，这些是不同的能力。诚实的表述是：本地调度买的是频率和本地文件访问，代价是机器必须开着；云端调度买的是真正的自主，代价是更粗的间隔和每次运行的全新克隆。没有单一调度器什么都能做，成熟的循环通常两者都用：本地做紧密的内循环检查，云端做过夜扫描。

D. 在实践中选择调度器

本地和云端之间的选择不是品味问题，它机械地遵循一个问题：循环的工作粘在本地机器上，还是可以离开？

如果循环必须每分钟检查本地开发服务器，那只能本地跑，因为云端看不到笔记本上的进程。如果循环应该在凌晨三点扫描仓库的开放 issue 并在适当时打开 PR，那不该绑在笔记本上，因为笔记本会合盖、断电、被带走。

E. 同样的能力，两种工具链

本文的命令是 Claude Code 的，但能力不是特定于它的。Codex 用不同名称提供同样的五个器官，为一边写的连接器通常可以挪到另一边直接用。教训是循环工程是一组能力，不是产品。 无论团队用哪种工具链，要问的是六个部件是否都存在，而不是哪个品牌的命令提供了它们。

VIII. 成本：四个不会自行清零的账单

自己运行的循环，同时也是自己犯错的循环。跑得越欢，错得越静。 四种成本悄然累积，循环运行时一个都不响警报。

验证债。 每个打开并合并的 PR 省了时间，但省下的时间变成了等待偿还的未验证输出。问题藏在测试没覆盖的地方，在“能跑”和“正确”之间的缝隙里，积累到某个发布早晨突然爆发。护栏是独立的评估器，与干活的不同的 Agent。

理解腐烂。 循环越快发布人没写的代码，存在的与人实际理解的之间的差距越大。读代码比写代码更无聊，而循环把写代码拿走了；代码库在增长，人脑里的地图停滞了。直到 bug 钻进一个从不阅读的角落才会响警报。护栏是定期读循环的输出，强迫自己解释几个改动，无法解释就是地图需要更新了。

认知投降。 当循环自行运行时，诱惑是停止持有观点，直接接受它给的东西。这是前两个的态度版本：不是“没时间”，而是“不再想操心”。循环越可靠，越容易外包判断。护栏是一句话：循环可以执行，但不能决定，人必须至少保持能说“这错了”的能力。

Token 失控。 唯一直接打在账单上的成本，且难以预先估算：循环孵化帮手、重试、一轮又一轮地跑，所以一个 bug 能整夜空转，产出一张不熟悉的账单而不是修复好的代码。护栏是在无人值守运行前设硬上限：每次运行预算、每日预算、最大重试次数，让一个空转的 bug 不能烧掉整夜的配额。

A. 复合债务的实例

考虑一个循环一夜打开 20 个 PR，全部测试通过，表面上是胜利。但假设 20 个中有 3 个包含测试未覆盖的微妙错误：没有独立评估器，那 3 个合并了，这是验证债。因为人合并了 20 个 PR 没读，他们对代码库的心理模型现在落后了 20 个改动，这是理解腐烂。因为循环跑得如此顺畅，人完全停止读第二天早上的批次，这是认知投降。因为循环整夜自由孵化帮手和重试，账单是预估的三倍，这是 Token 失控。

三个埋藏的错误现在坐在人不再完全理解的代码库里，被一个已经停止查看的人守护着，最终只在一个浮现为生产事故时才被发现。

四种成本不是独立风险的清单，它们是穿着四张面孔的同一个失败。 它们互相强化：循环产出的未验证输出越多，人理解的越少；理解的越少，越投降；越投降，循环无人看管的时间越长，账单越大。对四种的护栏是同一个：保持一个人能说“不”，安装一个不需要人醒着就能运行的检查。

IX. 保持工程师身份，不只是按“开始”的人

同样的循环，由两个不同的人构建，可以到达截然不同的地方，差异不在循环。如 Osmani 所写，两个人可以构建同样的循环，得到相反的结果：一个用循环在已经掌握的事情上加速，他们读代码，持有坚定的方向感，循环放大他们已有的判断力；另一个用同样的循环，只是为了再也不用理解。六个月后，一个变强了，另一个变成了一台他读不懂的机器的守门人。

A. 它是一个忠实的乘号

循环不是质量由工具固定的工具。它如此强大，以至于不变地放大人带来的任何东西：带来理解，它放大理解；带来懒惰，它放大懒惰。它是一个忠实的乘号，它乘的是人。

循环让生成变得极其便宜：代码、计划、PR、修复，几乎免费。保持稀缺的是判断力：知道哪个计划是对的，哪行应该停，哪个输出跑起来没问题但根本上是错的。循环可以生成一百个选项但不能真正选择；或者更准确地说，它选择“看起来合理”，不是“真的对”，而那两者之间的差距就是工程师存在的理由。循环工程因此不贬低判断力，它剥离一切不需要判断力的东西，留下判断力作为剩下的全部。

B. 放大是双向的

因为循环是判断力的放大器，判断力的失误也被放大。在旧世界，一个错误决定代价一段手写的错误代码，爆炸半径有限，速度慢到能抓到。在新世界，一个错误决定被忠实地、批量地、一百次地执行，被一台不会停下来问“这对吗”的机器。 循环移除了曾经拯救工程师的慢速齿轮，人不能再指望过程慢到能在中途发现错误。这提高了循环做不到的那一件事的赌注。

X. 判断力的经济学

上一节提出了一个值得按自身条件审视的主张：循环让生成便宜，让判断力稀缺。 这不是口号，这是一个关于团队应如何组织的经济学观察。

A. 什么变得充裕

当资源变得充裕，其价格下降，围绕它组织的活动重新排列。循环让代码、计划、修复、PR 变得充裕：一个构建了良好循环的工程师可以产出一个小团队的量。曾经消耗工程师一天的活动（打字、样板代码、机械重构）坍塌向零成本。合理的第一个反应是这让工程师更不值钱。恰恰相反，但只对持有稀缺东西的工程师成立。

B. 什么保持稀缺

稀缺的是决定保留哪些充裕产出的判断力。循环可以生成一百个候选实现，它不能告诉你哪个是对的，只能告诉你哪个看起来合理，而“看起来合理”和“是对的”之间的差距，正是工程存在的地方。随着生成趋向免费，工程师的全部价值集中到了这个差距里。 剩下的工作是纯粹的判断力，被曾经包围它的机械劳动蒸馏和稀释。

这有一个不舒服的含义。一个价值主要在机械劳动（快速打字、广博的 API 记忆、愿意啃样板代码）的工程师，发现那价值在蒸发，因为循环免费做了所有这些；一个价值在判断力的工程师，发现它被放大了，因为循环把他们的好决策执行了一百倍。同一个工具扩大了两种工程师之间的差距：它不会平等地抬升每个人，它乘上每个人带来的东西。

XI. 操作纪律

如果判断力是稀缺资源，实际问题是如何花好它。三条纪律值得作为常设实践来执行。

A. 总是读一个样本

对理解腐烂的防御不是读循环产出的所有东西（那会违背目的），而是每天读一个有代表性的样本，强迫自己解释每个采样的改动：它做了什么，为什么那样做。无法解释一个改动是一个精确信号：你的心理地图落后于代码库了。 从一个安静的早上的采样 PR 发现这一点，比从一个糟糕日子的生产事故发现便宜得多。样本不需要大，需要定期和真正检查。

B. 先设上限再发布

对 Token 失控的防御是在循环第一次无人值守运行前设硬天花板，而不是在第一张意外账单后。每次运行预算、每日预算、最大重试次数一起确保一个空转的 bug 不能整夜消耗全部配额。这些数字主要不是省钱，它们是断路器，把无界风险转换成有界风险。没有上限的循环，是把消费权委托给自己 bug 的循环。

C. 保持一扇门开着

对认知投降的防御是结构性的，不仅仅是态度。在循环里建至少一个检查点让人暂停，不是因为人总是干预，而是因为暂停的存在让人保持在能干预的位置。焊死每扇门、赌永远不需要进去的工程师，在必须进去的那天发现不再持有钥匙；留一扇门开着的工程师随时可以走进去看看循环在干什么。两个循环在代码上差一个检查点，六个月后谁掌控差得远了。

XII. 今天构建你的第一个循环

Stripe 的管线是终点，不是起点。第一个循环应该小到几乎看不出是个系统：一个按定时器检查点东西的小东西。

第一步：运行 /loop。 Claude Code v2.1.72 后可用，按间隔重运行同一任务。它是会话级的，循环任务 7 天后过期，在本地机器上运行。

第二步：读 CI 和 issue，先分诊。 重运行一行不是循环。给它一个 prompt 每天早上看三件事并列举值得处理的。发现逻辑应该在 Skill 里，不在调度里。

第三步：加状态文件。 不要把结果留在聊天窗口。把每个发现和它被处理到什么程度写进 Markdown 文件。Agent 会遗忘，仓库不会。

第四步：加评估器。 最关键且最容易被跳过的步骤。Claude Code 的 /goal（v2.1.139 后）跑到条件满足，由不同模型判断条件是否成立。

第五步：加 worktree 做并行。 用 --worktree 为每个后台 Agent 打开独立 worktree，互不干扰。

A. 一个完整的第一循环（带注释）

以下是一个最小但完整的循环，安装了全部六个元素：

# 1. 调度：真正的触发器
# .github/workflows/triage.yml
on:
  schedule:
    - cron: '0 6 * * *'   # 每天早上6点，云端

# 2. 发现：Skill，不是文本墙
# 由工作流调用：
run: claude --skill morning-triage

# 3. 持久化：磁盘上的状态
# Skill 写 ./state/triage.md，并提交回仓库

# ./state/triage.md（循环的记忆）
# | finding         | source    | status  |
# | auth test flaky | CI #4821  | fixing  |
# | null deref      | issue 92  | PR open |
# | stale dep       | commit a3 | inbox   |

# 4. 交接：每个发现一个 worktree
for finding in $(parse ./state/triage.md); do
  claude --worktree "fix/$finding" \
    --goal "tests pass and lint is clean" \
    "draft a fix for $finding"
done

# 5. 验证：全新模型审查
# /goal 的停止检查在每轮后运行；
# 第二个审查 Agent 挑刺
/goal all tests in test/auth pass and the lint step is clean

# 6. 人工审查：敞开的门
# PR 被打开，从不自动合并；
# 任何不确定的进 ./inbox/ 等人处理

从上往下读，六个编号注释对应六个部件：cron 行是调度，Skill 调用是发现，提交的状态文件是持久化，每个发现的 worktree 是交接，/goal 停止检查加审查者是验证，从不自动合并加收件箱是人工审查。

B. 安全地扩大循环

一旦最小循环跑起来，诱惑是扩展：更多发现、更多并行 Agent、更短间隔。安全的增长顺序是最后加并行，在检查被证明之后。 先增加循环发现的东西，再增加它并行做的量；先证明评估器能抓住真正的错误，再信任它同时门控多个 Agent。Stripe 案例是这条路的终点，不是入口：它的可靠性来自多年硬化确定性门，不是从大规模开始。一个循环赢得运行更多 Agent 的权利的方式，是先证明它能停住一个坏的。

XIII. 附录 A：带注释的分诊 Skill

# .claude/skills/morning-triage/SKILL.md
--name: morning-triage
trigger: 由每日自动化调用
---

## 读取（发现的输入）
- 上次运行以来失败的 CI
- 最近 24 小时打开的 issue
- 昨天以来合并的提交
- 上一个 ./state/triage.md

## 判断（设定天花板的部分）
对每个候选项，决定：
- 是现在可操作的，还是噪声？
- 是否阻塞发布？→ 优先级
- 是否已在追踪？→ 跳过
只保留今天值得开 worktree 的。

## 写入（持久化的输出）
追加到 ./state/triage.md：
| finding | source | priority | status |
提交文件让明天能读。

## 交接（准备交接）
为每个保留的发现，输出任务行：
worktree=fix/某某 goal=某停止条件

## 停止（你为自己保留的边界）
从不合并。从不删除。
任何你不够确信的进 ./inbox/ 等人，不进 PR。

Skill 的六个标题中五个映射到五个动作，第六个“停止”是构建者写入循环无法自行推断的边界。循环会忠实地做 Skill 说的一切，不做它省略的一切。所以“停止”部分不是样板，它是工程师关于在哪里保持控制的意图被永久化的唯一地方。 省掉它，循环会带着它没挣来的自信去合并。

XIV. 附录 B：术语表

XV. 综合：手册的核心

横跨全篇，论点有一条脊柱。循环工程是一个栈的第四层，始于提示词，攀升经过上下文和框架；区别于下面三层的是，它把人从做工作的位置上移除了。 循环的单轮是五个动作（发现、交接、验证、持久化、调度），由六个部件实现，而循环的失败就是那些动作被跳过。最难的动作是验证，因为给自己的工作打分的 Agent 会赞美它；可靠的补救是结构性的：一个默认怀疑、行动而非阅读、由一个全新模型按明确停止条件评判的独立评估器。

循环已经在实践中运行，从一个工程师的早晨到每周合并千余个机器生成 PR 的企业。让它们可靠的是约束的质量，而非模型的大小。它们积累四种隐性债务：验证债、理解腐烂、认知投降、Token 失控，互相强化，同时到期。

因为循环是其构建者带来的东西的放大器，同样的循环由两个人构建产生相反的结果，差别在一两个检查点上，它们决定了后来谁掌控。

要带走的一句话，是这个领域在一周内收敛出的那句：停止提示 Agent，设计提示它的系统；但像一个打算继续当工程师的人那样设计，而不只是按“开始”的人。

本文中所有的技术都服务于这一个姿态。评估器、状态文件、预算上限、敞开的门，每一个都是让人保持能对一台被设计成高速说“是”的机器说“不”的方式。循环是这一代软件实践中最强大的工具，恰恰因为它是构建者最忠实的乘号，而一个忠实的乘号，和喂进去的判断力一样有价值，或一样危险。

首月的田野笔记

对于采用循环的团队，几条实践观察反复出现得足够多，值得直说：

1. 存活下来的是赢得信任的小循环，不是要求信任的大循环。先从端到端处理一个发现开始，在检查抓到真正的错误后再扩大。
2. 工程精力应该花在评估器上：强生成器配弱审查者产出自信的垃圾，而中等生成器配尖锐的审查者产出缓慢但可靠的进展，第二个才会复利。
3. 人工审查点不是临时脚手架，一旦循环被信任就拆除；它是保持循环可信的永久特征，拆除的那天就是理解腐烂认真开始的那天。
4. 预算上限应该假设会有东西整夜空转来设，因为最终会有；上限是日志里的好奇和发票上的一行之间的差别。

这些孤立看都不令人惊讶。让团队惊讶的是，循环“就是能用”的愉快体验多快侵蚀了让它能用的纪律，而那种侵蚀在某个它不再能用的早晨之前是不可见的。 手册最终不是关于构建循环（那部分现在确实容易了），而是关于保持那种在任何给定早上仍然能回答“循环刚做的事到底对不对”的工程师。

本文基于 HuaShu 的开源指南《Loop Engineering: Stop Asking Me What It Is》（橙皮书，v260615，2026 年 6 月）独立改写。框架和引用表述归功于 Addy Osmani；生成器/评估器发现归功于 Prithvi Rajasekaran（Anthropic）；企业案例归功于 Steve Kaliski（Stripe）。所有产品细节可能变化，请参考各工具的官方文档。

参考文献：

1. A. Osmani, "Loop Engineering," 个人博客和 Substack, 2026 年 6 月。
2. P. Steinberger, 关于设计给编码 Agent 写提示词的循环的帖子, 社交媒体, 2026 年 6 月。
3. B. Cherny, 关于写循环提示 Claude 的公开言论, Anthropic, 2026 年 6 月。
4. P. Rajasekaran, "Building long-running agentic applications: the generator/evaluator pattern," Anthropic 工程博客, 2026。
5. S. Kaliski, "Stripe's Minions: 1,300 PRs a week," How I AI 播客, 2026。
6. "Model Context Protocol (MCP) specification," 开放标准, 2025-2026。
7. "Goose: an open-source agent framework," 项目文档, 2025-2026。
8. "Claude Code documentation: /loop, /goal, worktrees, skills, automations," Anthropic, 2026。
9. HuaShu, Loop Engineering: Stop Asking Me What It Is, 橙皮书, v260615, 2026 年 6 月。