循环工程：Anthropic 设计“提示你的智能体”的系统手册｜中文翻译

一项关于设计自运行循环的实地研究

摘要——过去两年中，一连串“XX Engineering”术语记录了模型发布的节奏。本文考察其中最新的一个：Loop Engineering（循环工程）。该术语由 Peter Steinberger、Boris Cherny 和 Addy Osmani 于 2026 年 6 月各自独立提出，并由 Osmani 以文字形式命名。不同于提示工程、上下文工程或 harness engineering（运行框架工程），循环工程并不是教实践者如何把工作做得更好；它把实践者从“亲自做这项工作”的位置上移开。我们定义这一术语，将其置于 harness 之上的第四层，并把一次循环中的单个回合分解为五个动作——发现、移交、验证、持久化和调度——以及实现这些动作的六个组成部分。我们特别关注生成器/评估器分离：从经验看，一个被要求给自己输出打分的智能体往往会称赞自己的结果；而调校一个独立、持怀疑态度的评估器，远比让生成器对自己的工作保持批判性更容易处理。我们考察了三个实际运行中的循环，从一位工程师的晨间分诊，到 Stripe 每周合并 1,300 多个机器编写的 pull request 的企业级流水线；并归纳了四种悄然累积的成本——验证债务、理解腐化、认知让渡和 token 爆炸。最后，我们给出构建第一个循环的具体配方。本文的核心主张是：循环使生成几乎免费，而让判断成为稀缺资源；同一个循环，由两个人构建，可能产生截然相反的结果。

索引词——Agentic AI、软件工程、自主智能体、编码智能体、生成器–评估器、调度、自动化。

I. 引言：循环工程真正是什么

提示工程课程仍在售卖，上下文工程的墨迹尚未干透，harness engineering 也才刚刚被写成文章。现在，循环工程也来了。在过去一年里，这些“XX Engineering”术语几乎伴随着模型发布同步出现，想要翻白眼是可以理解的。

但这一次不同。它不是关于如何把工作做得更好；而是关于把实践者从做这项工作的岗位上彻底抽离出来。此前那些术语都默认有一个人坐在键盘前，逐行指挥智能体。循环工程删除了这个假设。实践者不再处在循环之内，而是在循环之外，构建循环。

A. 一句话定义

命名并撰写这一术语的人是 Google Chrome 团队的工程师 Addy Osmani。他的定义很短：循环工程就是把自己替换掉，不再由自己来提示智能体，而是设计一个系统来代替自己完成这件事。人不再逐行喂给智能体；人设计喂给智能体的系统。这句话的重心落在“替换你自己”上。这是一种位置的转变——从充当引擎，转为设计引擎的人。你所写的，不再是给智能体看的文字，而是一个会自动把文字发送给智能体的东西。

B. 一周之内，三个人点燃了导火索

这个术语并不是凭空发明出来的。2026 年 6 月的同一周内，几个群体几乎同时撞见了同一件事。引爆它的是 Peter Steinberger（OpenClaw 作者）的一篇浏览量超过八百万的帖子：人们不应再去提示编码智能体，而应设计提示它们的循环。几乎在同一时刻，Boris Cherny（Anthropic 的 Claude Code 负责人）也在说同样的事——他不再提示 Claude，而是让一些循环运行起来，由这些循环去提示 Claude 并弄清楚要做什么；他的工作就是编写循环。6 月 7 日，Osmani 在自己的博客上以《Loop Engineering》为题写下此事，纳入了 Steinberger 和 Cherny 的说法，并在第二天同步到 Substack。一处点火，一声回响，一个名称，全都发生在一周之内。

把这三种说法放在一起，它们指向同一个动作：人所设计的对象，已经从智能体的单个行为，转向驱动智能体的整个系统。就像此前的“vibe coding”一样，这个术语听起来也许粗糙，但它把一种工作方式变成了可以被讨论的东西。

C. 为什么这个术语此时到来

值得追问的是，为什么三位实践者在没有对照笔记的情况下，会在同一周里选择同一个词。答案在于，周边工具已经悄然跨过了一个门槛。编码智能体已经可靠到足以在无人看管时完成非平凡任务；主流 harness 中已经出现了调度原语；单次智能体运行的成本已经降到足够低，以至于按计时器反复运行一个智能体不再显得浪费。当所有部件都已就位，把它们组合起来的动作就会同时对所有人变得显而易见。名称比实践滞后了数月：在人们称之为循环工程之前，大家已经在编写循环；就像在“生成器/评估器分离”有名字之前，团队已经在把写作者智能体与审阅者智能体配对。

这种“实践在先，命名在后”的模式值得记住，因为它告诉读者该到哪里寻找下一个术语。它不会来自某次模型发布。它会来自这样一个时刻：某项新能力变得足够便宜，以至于一种此前不可想象的组合方式变成了日常。

D. Harness 之上的一层

这一转变可以浓缩成两句话。在旧世界里，人坐着逐行提示智能体；智能体完成一件事，停下来，然后等待。人是循环内部的人类时钟，每一次滴答都必须来自人。

©2026 HuaShu。允许个人使用本材料。这是对作者开放的“橙皮书”指南《Loop Engineering: Stop Asking Me What It Is》（v260615）所做的独立会议论文风格重排。原文发布于 2026 年 6 月；可在 huasheng.ai/orange-books 免费获取。

表 I 四层栈

Loop engineering
make it run itself, over and over

Harness engineering
arm a single run: tools, actions, “done”

Context engineering
what goes in the window right now

Prompt engineering
the words you write for the model

scope grows
one
floor
up

图 1. 四层栈。每一层都关注比其下层更大的事物；循环工程自动化了 harness 留下的“等待你”的部分。

在新世界里，人设计某个会自行滴答作响的东西——它按计时器运行，生成 helper 来完成工作，并把自己的结果反馈给自己。正如 Osmani 所说，循环工程位于 harness 之上的一层：下面的 harness 武装一次单独的智能体运行；上面的循环让它一遍又一遍地自行运行。变化发生在身份上：从操作智能体的人，变成调度智能体的人。价值从“知道如何指挥”转移到“知道如何构建循环，以及如何在循环中放入一个能够说不的检查”——最后这一部分是最难的，后文会解释。

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

这些“XX Engineering”术语并不是相互替代的；它们层层堆叠，每一层都关注更大的东西。表 I 列出了这四层。

每往上一层，关注的单位就扩大一个尺度：从一句话，到一个窗口，到一次运行，最后到一个自行运行的循环。图 1 将这四层展示为一个栈，循环坐落在 harness 之上的一层。

A. 四层

Prompt（提示）是最底层，也是最广为人知的一层。它关注要告诉模型什么：措辞、示例、角色、语气。它的边界是一次交流。问题在于，它假设人每一次都在场，把提示交进去。

Context（上下文）把问题从“我该说什么”提升为“这个窗口里应该放什么，才能让模型破解这个问题”。它关注模型的整个视野——检索什么、如何总结、清除哪些过期信息。一个塞满噪声的窗口会浪费掉即使是最好的提示。

Harness 关注一个智能体在单次运行中需要携带什么：哪些工具、哪些动作、何时加载上下文、如何从失败中恢复、什么状态算作完成。它武装一次运行；它并不会让那次运行重复。

Loop（循环）把“等待你”自动化掉。当前三层就位后，智能体可以干净地运行一次，但随后就会停止。循环给它装上计时器，使它按计划醒来，为并行工作生成子智能体，并把自己的输出反馈为下一轮的输入。

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

有三个动词把 harness 与 loop 区分开来。按计时器运行：循环按计划醒来，无需按下按钮。生成 helper：一个转动中的循环会分拆出子智能体——一个起草变更，另一个只负责在审阅中挑刺。自我喂给：循环产生的内容会成为下一轮自己的输入；昨天的发现被写入文件，今天早晨它读取该文件并继续。这种跨对话的记忆，正是它成为循环而不是多次执行的一次性任务的原因。

这种细粒度拆分很重要，因为每一层的失效方式都不同，而那个能够说“no”的检查必须安装在不同的位置。糟糕的提示会当场被抓住；糟糕的上下文会表现为错误答案。但在循环层，系统会在人睡觉时运行，修改人从未看过的代码，并把自己的错误喂给下一轮——而错误可能数天都不被发现。层级越高，人离现场越远，错误堆积的时间也越长。这正是为什么循环工程真正的难点从来不是构建循环，而是在循环内部放入某种能够让它停下来的东西。

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

考虑同一个底层 bug——一个智能体误读了某个函数返回的内容——在每一层上的表现。在提示层，这种误读会在一次交流中产生一个错误答案；人立即看到它并重写提示。在上下文层，误读来自被加载进窗口的过期文档；人注意到答案自信但错误，于是清空上下文。在 harness 层，智能体基于该误读行动一次——也许它编辑了一个文件——但运行结束，diff 可见，并且人在任何东西发布前审阅它。在循环层，同样的误读会被写入状态文件，第二天早晨又作为既定事实被读回，并在许多回合中被继续构建。等到有人查看时，错误假设已经成了承重结构。

这是循环工程中最重要的直觉：错误的成本随其在被人发现前存活的回合数而扩张；而循环在结构上就是一台最大化回合数的机器。后文中的一切——评估器、人类检查点、预算上限——都是为了缩短错误与其被发现之间的距离。

发现 交接 验证 持久化 调度 一轮 “说不”

图 2. 一轮中的五个动作。调度闭合了循环——它把未完成的一轮送入第二天的运行。验证是那个可以说“不”的动作。

III. 一个循环的五个动作

“循环”（loop）这个词很容易被误读为空转。每一轮都会做一些具体的事：它找到值得做的工作，把工作交给一个 agent，验证结果是否正确，保存状态，然后决定下一步。五个动作——发现、交接、验证、持久化、调度——少掉任何一个，循环就转不起来，或者只会原地打转。图 2 把这五个动作描绘成一轮，并由这一轮馈入下一轮。

A. 一个具体例子

Osmani 为自己搭建了一个早晨分诊循环。早晨，一个自动化流程会自行启动。一个分诊 skill 会读取昨天失败的 CI 测试、仍未关闭的 issue 以及最近的 commit，并把结果写入一个 markdown 文件或 Linear 看板。对于每个值得采取行动的发现，它都会打开一个隔离的 worktree；一个 sub-agent 起草修复，第二个 sub-agent 根据项目的 skills 和测试对其进行审查。一个 connector 会自动打开 pull request 并更新 ticket。任何它无法处理的事项都会进入 inbox 等待人类处理，同时保留一个 state file，以便第二天从当天停下的地方继续。没有哪个步骤需要人插手，但它会在确实应该等待人类的地方停下来等待。

B. 这些动作

发现（Discovery）弄清楚这一轮应该做什么。在这个例子中，分诊 skill 读取 CI 失败、未关闭 issue 和最近 commit。关键在于让 agent 自己找到工作，而不是把一个列表交给它。尤为重要的是，自动化触发的是一个 skill——被永久化的知识——而不是粘贴到一个没人会更新的 cron job 里的大段指令。发现为整个循环的质量设定上限：如果浮现出来的是没有价值的工作，那么其他四个动作即使做得再漂亮，也只是在为虚无服务。

交接（Handoff）把任务从调度系统移交到实际工作的 agent 手中。每个值得做的发现都会得到自己的隔离 git worktree，因此多个 agent 可以在不同目录中修改代码，而不会互相踩踏。每个任务切分得越干净，后续的验证和合并就越容易。

验证（Verification）是最容易偷工减料的动作，也是最不能省略的动作。在第一个 sub-agent 起草修复之后，第二个 sub-agent 会对其进行审查——使用不同的指令，有时甚至使用不同的模型。写代码的 agent 给自己的作业打分会过于宽松；一个专门挑毛病的角色会抓住第一个 agent 自我说服后放过的问题。这就是“那个可以说不的东西”。没有真正检查的循环，只是一个 agent 在对自己点头。

表 II 五个动作，对应到分诊循环

持久化（Persistence）把结果落到能在对话之外存续的地方：通过 connector 创建 PR 并更新 ticket，为无法处理的事项设置 inbox，以及用 state file 记录进度。循环的记忆不能只存在于 context window 中；写入 markdown 或看板的东西不会遗忘。

调度（Scheduling）让一轮变成一个循环。分诊每天早晨自动运行，而 state file 让未完成的发现能够延续到第二天，并自行接续。如 Osmani 所说，automations 才让一个 loop 成为真正的 loop，而不只是你曾经做过的一次运行。表 II 总结了这五个动作。

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

如果说动作描述的是一轮中发生了什么，那么部件描述的是要让它真正转起来，手里必须有什么。两者一一对应：发现依赖 skills，交接依赖 worktrees，验证依赖 sub-agents，持久化依赖 memory，调度依赖 automations。

Automations 让循环自行运转，挂在某个 schedule 或 trigger 上。没有调度，你拥有的只是一次单独运行，而不是一个循环。Automation 应该触发一个命名的 skill，而不是 cron job 中的一堵指令墙。调度不止一种形式——本地调度（机器必须保持开机）和云端调度（机器关机时也会转动）。

Worktrees 是 git 内置的机制，用于在一个 repo 中拥有多个相互独立的工作目录。它们的价值会随并行度扩展：两个 agent 同时写同一个文件，带来的麻烦和两个工程师提交到同一行代码没有区别。Worktrees 把并行性从“能跑但混乱”变成“能跑且干净”。

Skills 把项目知识永久化到单个文件（SKILL.md）中，因此 agent 不必每一轮都重新推导上下文。Osmani 将它们偿还的成本称为 intent debt：反复解释“这个项目是什么、规则是什么、陷阱在哪里”的代价。Skill 可以被复用和维护；一堵 prompt 墙不行。

表 III 六个部件对应五个动作

Connectors（建立在 MCP，即 Model Context Protocol 之上）把循环接到外部世界——issue tracker、数据库、staging API、Slack。一个只能看到文件系统的循环，是一个很小的循环。Connectors 决定了循环的视野半径，而为一个工具编写的 connector 往往可以直接放到另一个工具上照样使用。

Sub-agents 把负责写的那个和负责判断的那个分开。当一个 agent 既是选手又是裁判时，裁判会偏袒选手。反直觉的是，把一个独立的评判者调校得挑剔，要比让生成者对自己的工作严厉得多容易——这就是为什么循环会保留一个额外的 agent，而不是让一个 agent 审计自己。

Memory 是存在于单次对话之外的持久状态——一个 markdown 文件或一个看板。context window 被清空的那一刻，agent 什么都不记得；要让循环今天从昨天停下的地方继续，memory 必须落到磁盘上。Agent 会遗忘，repo 不会。Memory 不是 context：context 是 agent 在这一轮看到的内容，刷新时会被清掉；memory 则跨轮次、跨天持续存在。表 III 将六个部件映射到五个动作。

六个部件全部就位后，循环就有了骨架：automation 让它动起来，worktrees 让它不与自己打架，skills 让它不重复做功，connectors 让它看见外部世界，sub-agents 让它纠正自己，而 memory 让它记得。但把它搭起来只是开始：同一组部件，由两个人搭建，可能得到完全相反的结果。

V. 生成器与评估器

循环最难的部分不是让 agent 跑起来，而是在里面放入某个可以说“不”的东西——而写代码的那个 agent 恰恰是最不可能说“不”的那个。

A. 它总是表扬自己

让一个 agent 给自己刚产出的东西打分，它往往会自信地称赞它，即使人类可以清楚看出质量平平；Anthropic 工程师 Prithvi Rajasekaran 在构建长时间运行的应用时观察到了这一点。这不是聪不聪明的问题；这是在给自己的作业打分。代码被写出来时所在的 context，已经塞满了它之所以被写成那样的理由，因此当 agent 回看自己的输出时，它看到的不是结果——它看到的是通向那个结果的一整条自我说服链。在一个循环内部，这个缺陷会被放大：如果每一次“这是否足够好”都由刚写出它的 agent 来决定，那么每一轮它都会对自己点头，而运行得越久，它就越会偏离真正的质量。

生成器（Generator） 编写代码

评估器（Evaluator） 不同模型； 假定草稿有问题 拒绝 + 理由 通过 MCP 行动：点击、截图、运行测试 制造者–检查者

图 3. 作为独立 agents 的生成器与评估器。评估器不携带生成器的自我说服，默认持怀疑态度，并通过行动而不只是阅读来判断行为。

B. 调校一个怀疑者，而不是修补一个谦逊的作者

让生成器更自我批判的效果很差。Rajasekaran 发现，把一个独立评估器调校得持怀疑态度，远比让生成器批判自己的工作更可行。差异是结构性的，而不是措辞问题：不能要求一个作者跳出自身视角，但可以换入另一个 agent，让它带着完全不同的指令从零开始审视代码，不携带任何自我说服。这个想法借鉴自生成对抗网络（GANs）——一个网络构建，一个网络挑错——并移植到一个负责编写的生成器和一个负责审查的评估器上。图 3 展示了由此形成的循环。

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

更换 agents 还不够。如果评估器只阅读代码，它判断的是“这看起来对吗”，而不是“它运行起来对吗”。在前端任务中，Rajasekaran 把评估器接到 Playwright MCP，使其能够像 QA 工程师一样打开页面、点击按钮、截图并检查 DOM。这把判断依据从“这个 JSX 看起来没问题”转移到“我点击了按钮，页面发生了导航，这是截图”。同时更换底层模型也有帮助：同一个模型即使换了新指令，往往仍会保留自己的盲点。社区中一种常见的校准方式是告诉评估器，在证明相反之前都假定代码是坏的——默认姿态应该是怀疑，而不是信任。

D. 在产品中：用于停止条件的 /goal

Claude Code 用 /goal 将这种结构变成一个原语：给 agent 一个条件，让它一直运行，直到条件被满足。一个具有代表性的评估器设置和停止条件如下。

# Evaluator agent (.claude/agents/reviewer.md)
ROLE: Adversarial code reviewer.
ASSUME: this code is BROKEN until proven otherwise.
DO NOT praise. Find what fails.
CHECK, in order:
1. 它能运行吗？（执行，不要只读）
2. 测试：运行它们，粘贴真实输出。
3. 作者跳过的边界情况。
4. 行为是否与工单一致？
USE Playwright MCP: open the page, click, screenshot, inspect the DOM. Judge behavior, not intent.
VERDICT: PASS only if every check holds. Otherwise REJECT + list each reason.

# Stop condition, judged by a fresh small model
/goal test/auth 中的所有测试通过，且 lint 步骤干净

关键在于，每一轮之后，一个小而快的模型会检查该条件是否成立；如果不成立，就再运行一轮，而不是交还控制权。完成与否由一个新的模型决定，而不是由正在执行工作的模型决定。这就是 maker–checker 原则——在银行业已有数十年历史，其中录入大额转账的人和审核该转账的人必须不同——应用到停止条件上。（Codex 通过自动化加 agent 配置达到同样的能力；不应把 /goal 与 /loop 混淆，后者只是按时间间隔重新运行。）

循环的下限是它的评估器。生成器的水平决定循环能产出什么；评估器的水平决定循环不会产出什么。把生成与判断在结构上分离，把评估器调成怀疑者，让它通过行动来验证，并把最终决定权交给一个新的模型——这四步，正是培养一个循环说“不”的能力所需要的。

VI. 循环出错的五种方式

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

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

这是最常见的失败。循环运行，agent 写代码，然后同一个 agent 宣称它写得很好。没有独立检查，每一轮都会产出自我批准的输出，循环便以机器速度累积看起来合理的错误。症状是：一个循环在数百轮中从未对自己说过一次“不”——这对任何真实工作负载来说在统计上都不可能，因此也证明并不存在真正的检查。修复方法就是上一节的生成器/评估器分离。

B. 健忘循环（跳过持久化）

循环发现了好工作，完成了它，然后忘记它发生过，因为结果只存在于一个已被清空的上下文窗口里。下一轮又重新发现同样的工作，或者更糟，重做它并与第一次尝试发生冲突。症状是：循环没有累积性进展；每天早上都从同一个地方开始。修复方法是在磁盘上放一个状态文件——agent 会忘，仓库不会。

图 4. 每一种反模式都是跳过了一个动作。这五种失败与单轮中的五个动作一一对应。

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

一个有四个好动作但没有自动化的循环，并不是循环；它只是一个由人手动运行、然后又忘记再次运行的脚本。它在建成当天表现惊人，却在注意力转移那天悄无声息地停止。症状是：循环的最后一次运行发生在它被演示的那天。修复方法是一个真正的触发器——定时器或事件——不依赖人类记得去运行。

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

人类每天早上仍然把工作交给循环——“修这三个 bug”——所以循环自动化了执行，却没有自动化发现。这节省的东西比看起来少，因为选择要做什么往往才是昂贵的部分。症状是：人类仍然在早上花时间决定循环应该做什么。修复方法是把发现能力教进一个 skill，让循环自己浮现工作。

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

循环并行运行多个 agent，却让它们都修改同一个工作目录，于是它们的编辑相互碰撞，合并变成一团没人能解开的乱麻。症状只会在并行时出现：单 agent 循环看起来没问题，而问题会在第一个早上五个 agent 同时运行时出现。修复方法是每个任务使用一个隔离的 worktree。图 4 将五种反模式映射到它们违反的动作。

这五种并非彼此独立。缺少验证的循环往往也缺少持久化，因为一个团队若对一项检查粗心，通常也会对其他检查粗心。在实践中它们会聚集出现：有纪律的循环会安装全部五个动作，而仓促的循环只安装发现和交接——这两个会产生可见输出的动作——跳过会产生安全性的另外三个。下一节展示三个安装了全部五个动作的循环。

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

三个公开案例在规模上差异巨大，却共享同一个骨架：一个触发器按下开始，一组约束让它不偏离轨道，末端有一个人类检查点。“在你睡觉时运行”从来不是关于模型有多强——而是关于这个骨架有多牢固。

A. 一位工程师的早晨

Osmani 的分诊循环在第 III 节中已被拆解，它每天早上自动运行。唯一值得重新标出的细节是：自动化调用的是一个 skill，而不是一大块粘在日程里、永远没人会更新的指令。这就是一个人可以运行的循环的样子——一个人、一台机器、每天早上完成苦活。

人类触发器——Slack 中 @bot / emoji reaction

确定性编排器——扫描链接、拉取 Jira，Sourcegraph + MCP 组装上下文（不是 LLM）

LLM agent——在材料在手的情况下编写代码

硬编码关卡——运行 linter；agent 不能跳过

LLM agent——修复 lint

硬编码步骤——git commit

人类 review——每周 1,300 个 PR

图 5. Stripe 的 Minions 流水线。确定性关卡（蓝色）与 LLM 步骤（绿色）相互咬合；任何受规则约束的事情都被放在概率模型之外。可靠性来自约束，而不是模型大小。

B. Stripe 的 Minions：每周 1,300 个 PR

在企业规模上，值得研究的案例是 Stripe 的 Minions：正如 Stripe 工程师 Steve Kaliski 在 How I AI 播客中所描述的，它每周合并超过 1,300 个 pull request，而且没有一行是手写的。触发很轻量——在 Slack 中 @ 机器人，或添加一个 emoji reaction。让它可靠的是模型醒来之前的那一段：一个确定性编排器先组装上下文，扫描链接、拉取 Jira、查找文档，并使用 Sourcegraph 加 MCP 来定位相关代码。让 LLM 自己寻找上下文是最不可控的部分，因此这项工作——其规则可以硬编码——被从模型手中拿走。凡是确定性逻辑能解决的事，就绝不交给概率模型；这条线画在哪里，决定了循环是否可靠。

最反直觉的一点是：Minions 并不是建立在更强的模型之上。它是开源工具 Goose 的一个 fork，其核心主张是：可靠性来自约束的质量，而不是模型的大小。它的架构交错安排确定性关卡与创造性的 LLM 步骤，如图 5 所示——agent 写代码，硬编码流水线运行 linter 且 agent 不能跳过，agent 修复 lint，然后硬编码步骤运行 commit。沙箱是在 EC2 上的 Devbox，并以“cattle not pets”的方式运行：每个环境都可以随时替换，因此一千多个 agent 可以同时运行而互不踩踏。值得注意的是，那 1,300 个 PR 仍然由人类 review——人类并没有离开，只是换了工位，从编写转向审查。

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

本地 /loop 和桌面计划任务需要机器开着；关机后循环就会停止。要在机器关闭时运行，正确答案是 Cloud Routines 或 GitHub Actions 的 schedule 触发器。表 IV 对比了这些选项。想要频繁运行，并且能看到本地文件？使用本地 /loop，代价是保持机器开启。

表 IV 调度选项对比

想要它脱离本地状态运行？去云端，代价是一小时的最小间隔，以及每次都是一个干净的 clone。没有哪一种调度器能包办一切。

关于广泛流传的数字，需要提醒一句：诸如“Claude Code 大约 90% 是由它自己编写的”或大规模迁移提速之类的说法，大多是二手总结，应当作为粗略参考对待。这里的三个案例都能追溯到一手来源，比一个听起来令人印象深刻的数字更站得住脚。

D. 实践中如何选择调度器

本地调度和云端调度之间的选择不是品味问题；它机械地来自一个问题：循环的工作是否粘在本地机器上，还是可以离开？两个具体场景把规则说清楚。假设一个循环必须每分钟检查一次本地开发服务器——这项工作只能在本地运行，因为云端看不到某个人笔记本上的进程，而且云端间隔不能低于一小时。现在反过来：假设一个循环应该在凌晨三点扫描仓库的 open issue，并在有必要时打开 pull request——这项工作根本不该绑定到笔记本上，因为笔记本会合盖、断电、被带出门。对于第二种，云端计划或 CI schedule 触发器才是正确答案，运行在一台在人类睡觉时仍保持唤醒的机器上。

需要避免的扭曲，是把本地重跑当成“在你睡觉时运行”的全部。本地重跑意味着“在我还在这里时多跑几轮”；云端调度意味着“即使我不在也运行”。这是不同的能力，把它们混为一谈，正是人们合上盖子后发现他们以为自主的循环悄悄停止时感到失望的原因。诚实的表述是：本地调度以要求机器保持开启为代价，换来频率和访问本地文件的能力；云端调度以更粗的间隔和每次新 clone 为代价，换来真正的自主性。没有单一调度器能包办一切，成熟的循环往往两者都用——本地用于紧密的内部检查，云端用于夜间扫荡。

E. 同一种能力，两套工具链

本文中的命令是 Claude Code 的，但这些能力并不专属于它。Codex 以不同名称提供同样的五个器官，为一侧编写的 connector 往往可以原样迁移到另一侧并使用。表 V 将它们并排列出，避免读者把一个命令名钉在错误的门上。教训是：循环工程是一组能力，而不是一个产品：调度、运行直到条件满足、并行隔离，

表 V

两个工具链中的同一能力

子智能体、外部连接，以及显式技能调用。无论团队使用哪一种工具链，应该问的问题是这六项是否齐备，而不是由哪个品牌的命令来提供它们。

VIII. 代价：四个不会自行清空的标签页

一个自行运行的循环，同时也是一个自行犯错的循环。它运行得越欢快，出错就越悄无声息。四种代价会不断累积，而在循环运行时，没有一种会拉响警报。

验证债务。 每一个被打开并合并的 PR 都节省了时间，但省下的时间会变成等待偿还的未验证输出。问题隐藏在测试覆盖不到的地方，隐藏在“能运行”和“正确”之间的缝隙里，不断累积，直到某个发布的早晨一次性爆发。防护措施是一个独立评估器——一个不同于执行工作的智能体。

理解腐化。 循环越快地交付并非自己写的代码，已存在的东西与自己实际理解的东西之间的差距就越大。读代码比写代码更无聊，而循环已经接管了写作；代码库在增长，脑中的地图却停滞不前。它不会拉响警报，直到一个 bug 钻进从未读过的角落。防护措施是定期阅读循环的输出，并强迫自己解释若干变更；无法解释，就说明地图需要更新。

认知投降。 当循环自行运行时，人很容易停止持有意见，只接受它交回来的任何东西。这是前两者在态度上的版本：不是“没有时间”，而是“不再想费心”。循环越可靠，就越容易把判断外包出去。防护措施只有一行——循环可以执行，但它不能决定。人至少必须仍然有能力说出“这是错的”。

Token 爆炸。 这是唯一直接打到账单上的成本，而且很难提前估算：循环孵化帮手、重试，一轮又一轮地运行，于是一个 bug 可能空转整夜，产生一张陌生的账单，而不是修好的代码。防护措施是在交付前设置硬上限——单次运行预算、每日预算、最大重试次数——这样一个空转的 bug 就不能烧掉一整晚的配额。

这四者共有一个特征：循环运行时保持沉默。循环工程最迷人的地方，是它让一个人完成一个团队的工作；最危险的地方也在同一点，因为一个团队会与自身争论，而一个人加上一堆循环，很容易变成无人争论的回音室。

验证
债务
理解
腐化
认知
投降
Token
爆炸
每一个都滋养
下一个

图 6. 四种代价彼此强化。未经验证的输出侵蚀理解，理解被侵蚀会诱发投降，投降让循环运行更久、花费更多，而这又产生更多未经验证的输出。

A. 复合债务的一个实例

设想一个循环在一夜之间打开了二十个拉取请求，而且测试全都通过。从表面上看，这是一场胜利。但假设二十个里有三个包含测试没有覆盖到的微妙错误。没有独立评估器，这三个就会被合并——这就是验证债务。因为人类在没有阅读的情况下合并了二十个 PR，他们对代码库的心智模型现在落后了二十个变更——这就是理解腐化。因为循环运行得如此顺滑，人类在第二天早上完全停止阅读下一批输出——这就是认知投降。而因为循环整夜自由地生成帮手并重试，账单是估算值的三倍——这就是 token 爆炸。那三个被埋下的错误如今坐落在一个人类已不再完全理解的代码库中，由一个已经停止查看的人类守着，最终只有当其中某个错误以生产事故的形式浮出水面时才被发现。

这个实例的要点在于，四种代价并不是一组彼此独立的风险；它们是同一个失败戴上的四副面孔。它们彼此强化：循环产生的未验证输出越多，人类理解得越少；理解得越少，就越会投降；投降得越多，循环就越会在无人看管下运行得更久，账单也越大。图 6 展示了这个强化循环。抵御四者的防护措施是同一个：保留一个有能力说“不”的人，并安装一个不需要人醒着也能运行的检查。

IX. 继续做工程师，而不只是那个按下“开始”的人

同一个循环，由两个不同的人构建，可能走向相反的结局——而差别并不在循环本身。正如 Osmani 所写，两个人可以构建同一个循环，却得到相反的结果。一个人用循环在已经掌握的事情上推进得更快：他们阅读代码，牢牢把握方向感，而循环放大了他们本就拥有的判断力。另一个人使用同一个循环，是为了再也不必理解。六个月后，一个人变得更强，另一个人则成了一台自己读不懂的机器的看门人。

循环不是一种其质量由工具本身固定下来的工具。它强大到会原封不动地放大人带来的任何东西：带来理解，它就放大理解；带来懒惰，它就放大懒惰。它是一个忠实的乘号，而它所乘的是人本身。

循环让生成变得极其廉价——代码、计划、

PR、修复，几乎免费。仍然稀缺的是判断：知道哪个计划是正确的，哪一行应该被叫停，哪个输出运行良好但根上是错的。循环可以生成一百个选项，但不能真正选择；或者更准确地说，它是基于“看起来合理”来选择，而不是基于“实际上正确”来选择，而这两者之间的差距正是工程师存在的理由。因此，循环工程并不会贬低判断；它剥离掉所有不需要判断的东西，让判断成为剩下的一切。

循环执行交给它的逻辑，但并不理解人为什么想构建它，人实际上想要什么，或者哪些地方人宁愿亲自盯着。这些边界——手动检查点放在哪里、哪里让它自行运行——无法从循环中读出来；它们只存在于构建者的脑中，必须一个一个写进去。一个人带着什么心态设计，循环就会长成什么形状。两个循环，一个带着“迅速解放我自己”的心态构建，另一个带着“我仍然打算做工程师”的心态构建，在代码上可能有百分之九十相同；差别只在一两个检查点，而这些检查点决定了六个月后，一个人是站在循环之上，还是被它掏空。Osmani 的结语值得记住：构建循环，但要像一个打算继续做工程师的人那样去构建，而不只是像那个按下“开始”的人。

X. 判断的经济学

上一节提出了一个值得按其自身逻辑审视的主张：循环让生成变得廉价，而让判断保持稀缺。这不是一句口号；这是一个关于团队应如何组织的经济学观察。

A. 什么变得充裕

当一种资源变得充裕时，它的价格会下降，围绕它组织起来的活动也会重组。循环让代码、计划、修复和拉取请求变得充裕——一个拥有良好构建循环的工程师，可以产出一个小团队的成果。过去消耗工程师一天的那些活动，打字、样板代码、机械式重构，成本趋近于零。一个合理的第一反应是，这会让工程师变得不那么有价值。事实恰恰相反，但只对那些抓住稀缺之物的工程师成立。

B. 什么仍然稀缺

稀缺资源是那种决定在充裕输出中保留哪些的判断力。循环可以生成一百个候选实现；它不能告诉你哪一个是正确的，只能告诉你哪一个看起来合理，而“看起来合理”和“是正确的”之间的差距，恰恰就是工程所在之处。随着生成趋近免费，工程师的全部价值都集中到这个差距之中。剩下的工作是纯粹的判断，被蒸馏出来，不再被过去围绕它的机械劳动所稀释。

这有一个令人不适的含义。一个其价值主要在机械劳动中的工程师——快速打字、广泛记忆 API、愿意熬过样板代码——会发现这种价值正在蒸发，因为循环免费完成了所有这些事情。一个其价值在判断中的工程师会发现自己的价值被放大，因为循环会把他们的好决策执行一百倍。同一个工具扩大了两类工程师之间的差距。它并不会平等地托举每个人；它会倍增每个人带来的东西。

C. 放大器的刀刃双向切割

因为循环是判断的放大器，判断中的失误也会被放大。在旧世界里，一个糟糕决策的代价是一段手写的错误代码，爆炸半径有限，而且慢到足以被捕捉。在新世界里，一个糟糕决策会被一台不会停下来询问它是否正确的机器忠实地、大批量地执行一百次。循环移除了过去能把工程师救回来的慢档。人不能再指望流程慢到足以在半途注意到错误，因为流程已经没有慢档了。这提高了循环唯一无法完成之事的赌注，也正是为什么“继续做工程师”的纪律不是可有可无的情怀，而是运营上的必要。

XI. 运营纪律

如果判断是稀缺资源，那么实际问题就是如何把它花好。根据上述案例和代价，有三条纪律值得作为常规实践明确下来。

A. 永远阅读样本

抵御理解腐化的办法不是阅读循环产生的一切——那会违背目的——而是每天阅读一个有代表性的样本，并强迫自己解释每一个被抽样的变更：它做了什么，为什么那样做。无法解释某个变更，是一个精确的信号，说明自己的心智地图已经落后于代码库；在一个安静的早晨从抽样 PR 中发现这一点，远比在一个糟糕的生产事故中发现它便宜得多。样本不需要很大；它需要定期存在，并且被真正检查。

B. 交付前设上限

抵御 token 爆炸的办法，是在循环第一次无人值守运行之前设置硬性上限，而不是在第一张令人惊讶的账单之后。单次运行预算、每日预算和最大重试次数三者结合，可以确保一个通宵空转的 bug 不会消耗掉整个配额。这些数字主要并不是为了省钱；它们是断路器，把开放式风险转化为有边界的风险。没有上限的循环，就是把支出权限委托给了它自身 bug 的循环。

C. 留一扇门开着

抵御认知投降的办法是结构性的，而不只是态度上的。至少在循环中构建一个检查点，让它为人类暂停——不是因为人类总会介入，而是因为这个暂停的存在让人类保持在能够介入的位置。那个把每一扇门都焊死、押注自己永远不需要进去的工程师，会在必须进去的那一天发现自己已不再持有钥匙。那个留一扇门开着的工程师，可以随时走进去看看循环在做什么。这两个循环只在一个检查点上不同，但六个月后，控制权在谁手中会完全不同。

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

Stripe 的流水线是终点，而不是起点。第一个循环应该小到几乎不像一个系统——只是一个按定时器检查某件事的小东西。

第一步：运行一个 /loop。Claude Code v2.1.72 之后可用；它会按间隔重新运行同一个任务。它以会话为作用域，周期性任务七天后过期，并且在本地机器上运行；关掉机器，它就停止。

/loop 5m check the deploy
# 固定：每 5 分钟一次
/loop check the deploy
# 由代理自行调整节奏
/loop
# 运行 .claude/loop.md

第二步：读取 CI 和 issue；先做分诊。重复运行一行命令并不是循环。给它一个提示，让它每天早晨查看三类东西，并列出哪些值得处理。“定时 + 自动发现”是循环的入门层级。发现逻辑应该放在 skill 中，而不是放在调度里。

# .claude/skills/morning-triage/SKILL.md
NAME: morning-triage
WHEN: invoked each morning by automation.
READ:
- CI runs that failed since yesterday
- issues opened in the last 24h
- commits merged since the last run
JUDGE: for each item, is it worth acting on?
Skip noise. Keep only actionable findings.
OUTPUT: write findings + status to
./state/triage.md (one row per finding).

第三步：添加一个状态文件。不要把结果留在聊天窗口里。把每个发现项以及它已被处理到什么程度，都写入一个 Markdown 文件（或 Linear 看板）。代理会遗忘；仓库不会。

# ./state/triage.md
（循环的记忆）

| finding        | source   | status  |
|----------------|----------|---------|
| auth test flaky| CI #4821 | fixing  |
| null deref     | issue 92 | PR open |
| stale dep      | commit a3| inbox   |

第四步：添加一个评估器。这是最关键的一步，也是最容易跳过的一步。Claude Code 的 /goal（v2.1.139 之后）会一直运行，直到某个条件被满足，并由另一个模型判断该条件是否成立。

/goal all tests in test/auth pass and the lint
step is clean

第五步：添加 worktree 以实现并行。使用 --worktree（或 -w）为每个后台代理打开一个独立的 worktree，这样它们就不会互相踩踏。

# 每个发现项一个隔离的 worktree
claude --worktree fix/auth-test
"draft the fix"
claude --worktree fix/null-deref "draft the fix"

在表 VI 的六个元素中，前两个决定循环能否运行；后四个决定它一旦运行起来是否会惹麻烦。初学者最常见的做法是只把前两个构建出来，结果就是一个没人看管、没人能停下、只会对自己点头的循环。最后的建议很简单：第一个循环最好小，但必须完整安装那个会说“不”的检查，以及人工审查点。

表 VI 第一个循环检查清单

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

为了让检查清单具体化，下面是一个最小但完整的循环，它安装了全部六个元素。它小到可以一口气读完，但包含真实循环所需的每个器官，只是缩小了规模。

# 1. SCHEDULING -- a real trigger
#
(.github/workflows/triage.yml)
on:
schedule:
- cron: ’0 6 * * *’
# 06:00 daily, cloud

# 2. DISCOVERY -- a skill, not a wall of text
#
invoked by the workflow:
run: claude --skill morning-triage

# 3. PERSISTENCE -- state on disk
#
the skill writes ./state/triage.md
#
and commits it back to the repo

# 4. HANDOFF -- one worktree per finding
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. VERIFICATION -- a fresh model judges
#
/goal’s stop check runs after each turn;
#
a second reviewer agent picks holes

# 6. HUMAN REVIEW -- the open door
#
PRs are opened, never auto-merged;
#
anything uncertain lands in ./inbox/

从上到下读，六条编号注释就是检查清单中的六个元素，每个都用两三行实现。cron 行是调度；skill 调用是发现；提交到仓库的状态文件是持久化；每个发现项对应一个 worktree 是交接；/goal 停止检查加上审查代理是验证；“绝不自动合并”规则和 inbox 则是人工审查点。一个具备全部六项的循环，哪怕很小，也是真正的循环。缺少其中任何一项的循环，都是第 VI 节中五种失败之一披上了伪装。

B. 安全地扩大循环

一旦最小循环跑起来，诱惑就是扩张它——更多发现项、更多并行代理、更短间隔。安全的增长顺序是最后再增加并行度，在检查机制被证明可靠之后再这样做。先扩大循环发现的内容，再增加它并行处理的数量；先证明评估器能抓住真实错误，再信任它同时为许多代理把关。Stripe 案例是这条路径的终点，而不是入口：它的可靠性来自多年强化确定性关卡，而不是一开始就做得很大。一个循环必须先证明自己能停下单个坏代理，才有资格运行更多代理。

其余内容不在这篇笔记里；它在终端里。

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

发现这个动作依赖的是 skill，而不是一堵说明文字墙，因为 skill 可以被复用和维护，而粘贴进去的提示会在没人更新的调度里腐烂。下面是本文多处引用的 morning-triage skill 的更完整版本，并加上注释说明每一节如何服务于一个动作。

# .claude/skills/morning-triage/SKILL.md
---
name: morning-triage
trigger: invoked by daily automation
---

## Read (the DISCOVERY inputs)
- CI runs failed since the last run
- issues opened in the last 24 hours
- commits merged since yesterday
- the previous ./state/triage.md

## Judge (the part that sets the ceiling)
For each candidate, decide:
- is it actionable now, or noise?
- does it block a release? →priority
- is it already tracked? →skip
Keep only what is worth a worktree today.

## Write (the PERSISTENCE output)
Append to ./state/triage.md:
| finding | source | priority | status |
Commit the file so tomorrow can read it.

## Hand off (prepare the HANDOFF)
For each kept finding, emit a task line:
worktree=fix/<slug>
goal=<stop-condition>

## Stop (the boundary you keep for yourself)
Never merge. Never delete. Anything you are
less than confident about goes to ./inbox/
for a human, not into a PR.

这个 skill 的六个标题中，有五个对应五个动作；第六个“Stop”是构建者写下循环无法自行推断的边界之处。循环会忠实地执行 skill 所说的一切，也会忠实地不做 skill 遗漏的一切；因此，“Stop”部分不是样板文字——它是工程师关于控制权应保留在哪里的意图被永久化的唯一位置。把它漏掉，循环就会带着并未赢得的信心去合并。

XIV. 附录 B：术语表

表 VII 本文使用的术语

XV. 综合：这套剧本归根结底是什么

贯穿九个章节，这个论证只有一条主线。循环工程是一个技术栈的第四层：这个栈始于提示词，经过上下文和执行架逐级上升；而它区别于下方三层之处在于，它把人类从“亲自做工作”的位置上移开。循环的一轮包含五个动作——发现、交接、验证、持久化、调度——由六个部件实现；循环的失败，归根结底就是这些动作被跳过。最难的动作是验证，因为让代理给自己的工作打分，它会夸奖自己；可靠的补救办法是结构性的：一个独立评估器，默认怀疑、行动而非阅读，并由新模型根据明确的停止条件来判断。循环已经在实践中运行起来，从某个工程师的早晨，到每周合并一千多个机器撰写 pull request 的企业；让它们可靠的，是约束的质量，而不是模型的大小。它们会悄悄积累四种债务——验证债、理解腐烂、认知让渡和 token 爆炸——这些债务会相互强化，并在同一时刻到期。而由于循环会放大构建者带进去的一切，同一个循环由两个人构建，会产生相反的结果；差别只在一两个检查点，这些检查点决定了后来谁掌握控制权。

真正应该带走的一句话，是这个领域在一周内汇聚成的共识：不要再提示代理，而要设计那个提示代理的系统——但要像一个打算继续做工程师的人那样设计它，而不仅仅像那个按下“开始”的人那样设计它。本文中所有技术内容都服务于这一种姿态。评估器、状态文件、预算上限、敞开的门：每一样都是让人类仍然能够对一台被构造成高速说“是”的机器说“不”的方式。循环是这一代软件实践中最强大的工具，正因为它最忠实地放大其构建者；而一个忠实的放大器，其价值或危险，恰好等于输入其中的判断力。

A. 第一个月的现场笔记

对于正在采用循环的团队，有一些实践观察反复出现，值得直白地写下来。第一，能存活下来的循环，是那个小而赢得信任的循环，而不是那个野心勃勃、要求被信任的循环；从一个发现项端到端处理开始，只有在检查机制抓住过真实错误之后，才扩大范围。第二，工程投入应该放在评估器上——强大的生成器配上弱判断者，会产出自信的垃圾；普通的生成器配上敏锐的判断者，会带来缓慢而可靠的进展，而后者才会复利增长。第三，人工审查点不是在循环被信任后就可拆除的临时脚手架；它是让循环保持可信的永久特性，而它被移除的那一天，就是理解腐烂真正开始的那一天。第四，预算上限应该基于这样的假设来设置：总会有某个东西在夜里空转，因为最终确实会发生；上限就是日志里的一件趣事和发票上的一个项目之间的区别。

这些单独看都不令人意外。让团队意外的是，一个“就是能用”的循环所带来的愉悦体验，会多么迅速地侵蚀那些原本让它能用的纪律；而这种侵蚀又是多么隐形，直到某个早晨它不再隐形。归根结底，这套剧本与其说是关于构建循环——这部分现在确实很容易——不如说是关于如何继续做那种工程师：在任何一个早晨，都仍然能回答循环刚刚做的那件事到底是否真的正确。

参考文献

[1] A. Osmani, “Loop Engineering,” personal blog and Substack, Jun. 2026. [2] P. Steinberger, post on designing loops that prompt coding agents, social media, Jun. 2026. [3] B. Cherny, public remarks on writing loops that prompt Claude, Anthropic, Jun. 2026. [4] P. Rajasekaran, “Building long-running agentic applications: the generator/evaluator pattern,” Anthropic engineering blog, 2026. [5] S. Kaliski, “Stripe’s Minions: 1,300 PRs a week,” How I AI podcast, 2026. [6] “Model Context Protocol (MCP) specification,” open standard, 2025–2026. [7] “Goose: an open-source agent framework,” project documentation, 2025–2026. [8] “Claude Code documentation: /loop, /goal, worktrees, skills, automations,” Anthropic, 2026. [9] HuaShu, Loop Engineering: Stop Asking Me What It Is, Orange Books, v260615, Jun. 2026.

致谢。 本文是一篇独立的会议风格综述，建立在 HuaShu 开放指南 Loop Engineering: Stop Asking Me What It Is（Orange Books，v260615，2026 年 6 月）的框架之上。框架和引用表述归功于 Addy Osmani；生成器/评估器相关发现归功于 Prithvi Rajasekaran（Anthropic）；企业案例归功于 Steve Kaliski（Stripe）。所有产品细节都可能变化；请以各工具的官方文档为准。