循环工程：五个动作，搭一个会自己跑的循环

2026 年最危险的范式：Loop Engineering（循环工程） 当 AI 已经足够可靠，真正稀缺的不是"会用 AI"，而是"懂判断"。

01 / 一周之内，三个人同时点燃了同一根引线

2026 年 6 月的某个星期。

Peter Steinberger（开源工具 OpenClaw 的作者）在社交媒体上发了一条帖子，浏览量突破 800 万。他的核心观点只有一句：

别再提示 coding agent 了，去设计那些"提示它们的循环"。

几乎同一时刻，Boris Cherny（Anthropic 内部 Claude Code 的负责人）也在说同样的话。他说自己已经不再提示 Claude 了，而是搭了一堆循环，让循环去提示 Claude、让 Claude 自己想清楚该干什么。他的工作，从"提示工程师"变成了"写循环的人"。

三天后，6 月 7 日，Google Chrome 团队的工程师 Addy Osmani 把这两人的话整合起来，在博客上正式写下一篇文章，标题就叫 《Loop Engineering（循环工程）》，第二天同步到 Substack。

一次点燃、一次回响、一个名字。一周之内，一个新的工程范式被命名了。

这不是巧合。Osmani 给出了一个解释，工具已经悄悄越过了某道门槛：

• Coding agent 已经可靠到能无人值守完成非平凡任务；
• 调度原语（scheduling primitives）已经出现在主流的运行框架里；
• 单次 agent 运行的成本，已经降到定时反复跑也不再心疼的程度。

当所有零件都齐了，那个把它们组合起来的动作，对所有人一下子变得显而易见。名字比实践晚了至少几个月，在任何人称之为"循环工程"之前，人们已经在写循环了；就像在"生成器/评估器"这个划分有名字之前，团队早就在把"写作 agent"和"审查 agent"配对使用了。

这个模式值得记住：实践先行，名字后到。 下一个新术语不会来自某个模型发布，而会来自某个能力便宜到"以前不敢想的组合变成日常"的那一刻。

02 / 一句话定义：循环工程，是把你"替换"掉

Addy Osmani 的定义简短得吓人：

循环工程，就是把自己从"提示 agent 的人"这个位置上替换掉，转而设计那个替你做这件事的系统。

请把这句话的重音，落在"替换你自己"上。

过去两年，我们经历了好几波"XX 工程"：提示工程、上下文工程、harness（运行框架）工程。但它们都有一个共同假设：一个人类坐在键盘前，一行一行地指挥 agent。

循环工程删掉了这个假设。

你不再在循环之内，而是在循环之外，去构建这个循环。你的身份从"操作 agent 的人"变成了"调度 agent 的人"。你写下的不再是给 agent 的词，而是一个会自动把词发给 agent 的东西。

这是一次位置的迁移：从"当引擎"，到"设计引擎的人"。

03 / 四层栈：你站在哪一层？

这些"XX 工程"术语不是互相替代，而是层层叠加。每上一层，你照管的"单元"就大一格。一位国内开发者把它精炼地总结为**"四栈"**：

逐层看：

• 提示是地基。它管措辞、示例、角色、语气。边界是"一次对话"。麻烦在于：它假设人每次都在场。

• 上下文把问题从"我说什么"升级为"窗口里该放什么，模型才能破解难题"。它照管模型的整个视野。一个塞满噪声的窗口，会浪费掉再好的提示。

• Harness 照管"一次 agent 运行需要带什么"：哪些工具、何时加载上下文、如何从失败恢复、什么状态算完成。它武装一次运行，但不让运行重复。

• 循环，是这一切之上的一层。前三层就位后，agent 能干净地跑一次，然后停下。循环给它装上定时器，让它按计划醒来、生出子 agent 并行干活、把自己的输出当作下一轮的输入反馈回去。

用 Osmani 的话说：循环工程，位于 harness 之上一层。下面的 harness 武装单次运行；上面的循环，让它一遍又一遍地自己跑。

价值随之迁移：从"懂得如何指挥"，转移到"懂得如何构建循环，以及，如何在循环里放进一个能说'不'的东西"。最后这一句，是全文最难的，我们后面会反复回到它。

04 / 一个最重要的直觉：错误的成本，与它存活的轮数成正比

这是整篇论文最关键的一句话，请慢慢读：

一个错误的成本，与它在被发现前存活的轮数成正比。而循环，本质上就是一台把轮数最大化的机器。

拿同一个 bug 看看它在各层怎么表现。假设 agent 误读了一个函数的返回值：

• 提示层：产生一个错误答案，你立刻看到，改写提示。一拍解决。
• 上下文层：误读来自加载进窗口的陈旧文档，你注意到答案自信地错了，清掉上下文。当天解决。
• Harness 层：agent 按误读行动了一次（比如改了个文件），但运行结束、diff 可见、你在上线前审查。一周内解决。
• 循环层：同一个误读被写进了状态文件，第二天早上被当作"既定事实"读回来，并在接下来的很多轮里被层层叠加。

等你发现时，那个错误的假设，已经成了承重墙。

后面所有的东西（评估器、人类检查点、预算上限），本质上都是为了做一件事：缩短错误与发现之间的距离。

05 / 五个动作：少一个，循环就转不起来

"循环"这个词，太容易被误读成"空转"。

那位国内开发者把它概括为**"五行"**。每一轮循环都做五件实事：发现 → 移交 → 验证 → 持久化 → 调度。砍掉任何一个，循环要么转不起来，要么原地打转。

让我们跟着 Osmani 自己搭的"早晨分诊循环"看一遍：

动作一：发现（Discovery）

早上一个自动化自己启动。一个分诊 skill 读取三样东西：昨天失败的 CI 测试、还开着的问题、最近的提交。

关键不是"给它清单"，而是让它自己找活干。更关键的是：自动化触发的，是一个 skill（被永久化的知识），而不是糊在 cron job 里、没人会再去更新的"一墙指令"。

发现决定整个循环质量的天花板。给它一堆没价值的活，后面四个动作做得再漂亮，也是在为垃圾服务。

动作二：移交（Handoff）

对每个值得处理的发现，循环开一个隔离的 git worktree。一个子 agent 起草修复，第二个子 agent 对照项目的 skill 和测试做审查。

为什么要隔离？因为两个 agent 同时写同一个文件，和两个工程师提交到同一行一样头疼。worktree 把"能跑但乱"变成"能跑且干净"。

动作三：验证（Verification），全文最重要

这是最容易被偷工减料、也最不能省的动作。

写完代码的那个 agent，会去审自己刚写的代码。结果你猜得到：它总在自我表扬。

这不是"聪明度"问题，是"给自己作业打分"。写代码时的上下文，已经塞满了"为什么这么写"的理由。所以 agent 看自己产出时，看到的不是结果，而是那条把自己说服到这里的论证链。

所以必须有第二个、独立的、持怀疑态度的 agent。Anthropic 工程师 Prithvi Rajasekaran 的发现是：

调校一个独立的"怀疑型"评估器，远比让生成器"对自己手硬"可行得多。

这个差异是结构性的：你没法让一个作者走出自己的视角，但你可以换进另一个指令完全不同、从零看代码、不带任何自我说服的 agent。

这个思路借鉴自 GAN（生成对抗网络）：一个网络造，一个挑刺，再移植到"生成器写、评估器审"上。

更进一步：评估器不能只读代码（那只判"看着对不对"），它必须行动。Rajasekaran 把评估器接上 Playwright MCP，让它像 QA 工程师一样开页面、点按钮、截图、查 DOM，把判断基础从"这段 JSX 看着没问题"变成"我点了按钮、页面跳转了、这是截图"。

社区里流行一个校准口诀：

假设代码是坏的，直到被证明不是。默认姿态应是怀疑，不是信任。

一个没有真检查的循环，只是一个 agent 在冲自己点头。

动作四：持久化（Persistence）

结果落到能活过对话的地方：通过连接器开 PR 和更新工单、一个收件箱装处理不了的东西、一个状态文件记录进度。

为什么重要？因为 agent 会忘，repo 不会。 上下文窗口一清，agent 啥也不记得。循环要"今天接着昨天干"，记忆必须落盘。

动作五：调度（Scheduling）

让"一轮"变成"循环"的东西。分诊每天早上自动跑，状态文件让未完成的发现延续到第二天，第二天自己接着干。

Osmani 的一句话很关键：

自动化，是让循环成为"真正的循环"、而不是"你做过一次的一次性运行"的东西。

06 / 循环跑在什么上面？六个部件

动作描述"一轮里发生什么"，部件描述"要让循环转起来必须手头有什么"。两者一一对应：

其中两个值得展开：

Skill 偿还的债，叫"意图债务"（intent debt）。 它是反复解释"这个项目是什么、规则是什么、坑在哪"的代价。一个 skill 可以被复用、被维护；一墙糊在 cron 里的 prompt 不行。

连接器基于 MCP（Model Context Protocol）。 它把循环钩到工单系统、数据库、staging API、Slack。只能看文件系统的循环，是个很小的循环。 好消息是：为一个工具写的连接器，往往能直接套到另一个上。

六个部件齐了，循环就有了骨架。但骨架只是开始：同一套部件，两个人搭出来，可以南辕北辙。

07 / 五种"病循环"：每一种，都是砍掉了一个动作

论文把"失败的循环"归纳成五种反模式，每一种对应一个动作被跳过。这部分比成功案例更有教益。

点头循环（跳过验证）

最常见的失败。 循环跑、agent 写代码、同一个 agent 宣布"没问题"。每一轮都产出"自我批准"的输出，循环以机器速度累积"看着合理"的错误。

症状：一个循环在几百轮里，从没对自己说过一次"不"。这对任何真实工作量都是统计上的不可能，因此它恰恰证明：根本没有真正的检查存在。

失忆循环（跳过持久化）

循环发现了好活、干了、然后忘了，因为结果只活在被冲掉的上下文窗口里。第二天又发现同样的活，甚至重新干一遍，和第一次撞车。

症状：循环没有任何累积进展，每天早上从原点开始。

手动循环（跳过调度）

四个动作都好，但没有自动化。这其实不是循环，是一个你手动跑、然后忘了再跑的脚本。

症状：循环最后一次运行，是它被 demo 的那天。

盲循环（跳过发现）

人仍然每天早上把活儿递给循环，"修这三个 bug"。循环自动化了"做"，却没自动化"找"。

这省得比看起来少。因为"决定干什么"，往往是整个流程里最贵的部分。

症状：一个还在花早上时间决定"循环该干什么"的人。

缠绕循环（跳过移交）

循环并行跑多个 agent，却让它们都改同一个工作目录。编辑撞车，合并成一团没人能解开的乱麻。

症状只在并行时出现：单 agent 循环看着好好的，某个早上五个 agent 同时跑，问题才爆发。

这五种会聚集出现。 自律的循环装上全部五个动作；潦草的循环只装"发现"和"移交"，这两个产出可见输出，而跳过那三个产出"安全"的。那位国内开发者的一句话说得很好：

Loop 是最忠实的放大器。你带理解，它放大理解；你带懒惰，它放大懒惰。

08 / 三个真实在跑的循环

光讲理论不够，看看真实在跑的三个案例。它们的规模天差地别，但骨架惊人地一致：一个触发器按下"开始"，一组约束把它留在轨道上，一个人类检查点坐在终点。

案例一：一个工程师的早晨（Osmani 的分诊循环）

每天早上自动跑。最值得重申的一个细节：自动化触发的是一个 skill，而不是一坨糊进计划、永远不会有人更新的指令。 这是一个人、一台机器、每天早上把脏活干完的样子。

案例二：Stripe 的 Minions，每周 1300 个 PR

企业级的标杆案例。Stripe 工程师 Steve Kaliski 在 How I AI 播客里描述：每周合并超过 1300 个 PR，没有一行代码是人写的。

触发很轻：在 Slack 里提及机器人，或者加一个表情回应。

真正让它可靠的，是模型醒来之前的那段拉扯：一个确定性编排器先组装上下文，扫链接、拉 Jira、用 Sourcegraph 加 MCP 定位相关代码。

核心设计原则：任何确定性逻辑能解决的事，绝不交给概率模型。

让它干活的那段，能被硬编码的就硬编码：它跑 linter，agent 跳不过；agent 修 lint；硬编码步骤跑 git commit。沙箱用 EC2 上的 Devbox，按"牲口不是宠物"（cattle not pets）的原则，每个环境随手替换，上千个 agent 同时跑互不踩踏。

最反直觉的一点：Minions 不是建立在更强的模型上。它是开源工具 Goose 的一个 fork。它的可靠性，来自约束的质量，而非模型的大小。

那 1300 个 PR，仍然由人类审查。人没有离开，只是换了张桌子：从"写"，换到了"审"。

"你睡觉时跑"到底靠什么？

• 本地 /loop / 桌面任务：需要机器开着。关机就停。
• Cloud Routines / GitHub Actions 定时触发：机器关了也跑，代价是间隔更粗（最小 1 小时），且每次全新 clone。

一个常被误解的点：本地重跑 ≠ "你睡觉时跑"。 本地重跑的意思是"我在的时候多跑几轮"；云端调度的意思是"我不在的时候也能跑"。这是两种不同的能力。把它们混为一谈，就是人们合上笔记本盖子、发现"本以为自动的循环悄悄停了"的原因。

成熟的循环往往两者都用：本地跑紧密的内部检查，云端跑夜间大扫除。

09 / 四笔"不会自己清"的账

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

验证债务（Verification Debt）

每个开并合并的 PR 都省了时间。但省下的时间，变成了待还的未验证输出。问题藏在测试覆盖不到的地方，在"能跑"和"对的"之间的缝隙里，一直累积，直到某个上线的早晨一起爆炸。

守卫： 独立评估器。

理解力腐蚀（Comprehension Rot）

循环越快地交付你没写的代码，你脑中地图与实际代码的差距就越大。读代码本来就比写代码无聊，循环又把"写"这件事拿走了：代码库在长大，你脑中的地图却在原地踏步。

守卫： 定期读循环的输出，逼自己解释几个改动。解释不出来，就是地图该更新的信号。

认知投降（Cognitive Surrender）

循环自己跑时，太容易就停止持有意见、照单全收。这不是"没时间"，而是"不想再费这个神了"。循环越可靠，外包判断就越容易。

守卫：一句话，循环可以执行，但不能决策。 你至少要始终保持"能说出'这是错的'"的能力。

Token 失控（Token Blowout）

循环生出帮手、重试、一轮轮跑。一个 bug 能让循环空转一整晚，产出一张你不认识的账单，而不是修好的代码。

守卫： 上线前设硬上限：单次预算、每日预算、最大重试次数。

这四个不是独立的风险清单，而是同一场失败的四张脸。 它们互相强化：循环产出的未验证东西越多 → 人理解得越少 → 越投降 → 循环越久无人看 → 账单越大 → 又产出更多未验证东西……

守住这四个的，是同一个动作：保留一个能说"不"的人，并装上一个不依赖人醒着就能跑的检查。

10 / 经济学：循环让"生成"近乎免费，却让"判断"成为稀缺品

这一节值得单独拎出来。

当一种资源变得充裕，它的价格就会下降，围绕它的活动会重组。循环让代码、计划、修复、PR 变得充裕：一个带着好循环的工程师，能产出一个小团队的量。

第一反应可能是：这让工程师贬值了。

恰恰相反，但只对"留住稀缺品"的工程师成立。

稀缺的是什么？判断。

• 知道哪个计划是对的；
• 知道哪一行该叫停；
• 知道哪个产出"能跑但根上是错的"。

循环可以生成一百个候选方案，但它没法告诉你哪个是对的：它只能告诉你哪个"看着合理"。而"看着合理"和"真的是对的"之间的缝隙，正是工程师之所以存在的地方。

循环工程因此没有让判断贬值；它剥掉了一切不需要判断的东西，只留下判断，让判断成为工程师所剩的全部。

这有一个不舒服的推论：

• 价值主要在机械劳动（打字快、API 记得多、肯磨样板代码）的工程师，这部分价值正在蒸发。
• 价值在判断上的工程师，这部分价值正在被放大。

同一个工具，拉大了两类工程师的差距。它不是平均地抬升每个人，而是成倍放大每个人本来就有的东西。

11 / 最重要的那句话：当工程师，而不只是按"开始"的那个人

同一个循环，两个人搭，结局可能完全相反。

• 一个人用循环，在已经精通的事上提速：他读代码、保持坚定的方向感，循环放大了他本来就有的判断。
• 另一个人用同一个循环，好让自己再也不必理解：六个月后，他成了自己看不懂的机器的看门人。

这两个循环，在代码上可能有九成相同。差别就在那一两个检查点上，而正是这一两个，决定了半年后谁站在循环之上、谁被循环掏空。

Osmani 那句结语，请记住：

构建循环，但要像"打算继续当工程师"那样去构建，而不只是"按开始的那个人"。

因为循环是最忠实的乘号，它乘的，是你这个人。 它会忠实地放大你带来的理解，也会忠实地放大你带来的懒惰。

放大的好处你已经懂了。坏处是：在旧世界，一个坏决定只付出一段手写错误代码的代价，爆炸半径有限、慢得来得及抓。在新世界，一个坏决定会被一台不会停下来问自己对不对的机器，忠实地、批量地、执行一百遍。

循环拿掉了过去那个**"慢齿轮"，那个曾经能在飞行途中把工程师救下的慢齿轮。当流程已经没有慢齿轮了，"保持工程师身份"就不再是抒情，而是操作上的必需**。

12 / 三条操作纪律

如果判断是稀缺资源，那实际问题就是：怎么花好它。

一、永远读样本

抵抗"理解力腐蚀"的方法，不是读循环产出的所有东西（那会毁了循环的意义），而是每天读一个有代表性的样本，并逼自己解释每个抽样的改动：它做了什么、为什么这么做。

解释不出来的那一刻，就是精确的信号：你的脑中地图已经落后于代码库了。从一个安静早晨的抽样 PR 里发现这一点，比从一个糟糕日子的生产事故里发现，便宜得多。

样本不必大，但必须定期、且真正被审视。

二、上线前设上限

抵抗"token 失控"的方法，是在循环第一次无人值守运行之前就设好硬天花板，而不是在收到第一张意外账单之后。单次预算 + 每日预算 + 最大重试次数，三者一起保证"一个空转的 bug 烧不掉一整晚的配额"。

这些数字主要不是为了省钱，它们是断路器，把一个"开放式风险"转换成"有界风险"。一个没有上限的循环，是一个把自己的花钱权委托给了自己 bug 的循环。

三、留一扇门

抵抗"认知投降"的方法是结构性的，不只是态度。在循环里至少建一个会为人暂停的检查点，不是因为人总会干预，而是因为这个暂停的存在，让人始终"有能力"干预。

焊死每扇门、赌自己永远不用进去的工程师，真到那天会发现钥匙不在手里。留一扇门的工程师，随时能走进去看循环在干什么。

两个循环，代码上只差一个检查点；半年后，谁在掌控，天差地别。

13 / 今天就搭你的第一个循环

Stripe 的流水线是终点，不是起点。你的第一个循环应该小到几乎不像个系统，一个小东西，定时检查点什么。

五步走：

第一步：跑一个 /loop。（Claude Code v2.1.72 之后可用）它按固定间隔重跑同一任务。它是会话级的、跑在本地机器上。关机就停。

第二步：读 CI 和 issues，先分诊。 重跑一行不是循环。给它一个提示，让它每天早上看三样东西，列出值得处理的。"定时调度 + 自动发现"，是循环的入门门槛。发现逻辑应活在 skill 里，不在计划里。

第三步：加状态文件。 别把结果留在聊天窗口。把每个发现、以及它处理到哪了，写进一个 markdown 文件（或 Linear 看板）。agent 会忘，repo 不会。

第四步：加评估器，最关键、最易跳过的一步。 用 /goal（v2.1.139 之后）让 agent 跑到条件满足为止，由一个不同的模型判定条件是否成立。

第五步：为并行加 worktree。 用 --worktree 给每个后台 agent 开独立工作目录，让它们互不踩踏。

一个六个部件齐全、哪怕很小的循环，是个真循环。缺任何一个的循环，都是上面五种失败之一在伪装。

一个完整（但极简）的循环骨架，六个部件各两三行：

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

# 2. 发现：一个 skill，不是一墙文字
run: claude --skill morning-triage

# 3. 持久化：磁盘上的状态
#    skill 写 ./state/triage.md 并提交回 repo

# 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 的停止检查每轮后跑；第二个 reviewer agent 挑刺

# 6. 人类审查：那扇开着的门
#    PR 只开不合；不确定的进 ./inbox/

安全的生长顺序： 先证明检查能抓住真实错误，再加并行。先增大"它发现什么"，再增大"它并行干多少"。Stripe 的案例是这条路走出来的终点，不是入口，它的可靠性来自多年硬化确定性闸门，不是从大开始。一个循环赢得"跑更多 agent"的权利，靠的是先证明它能拦住一个坏的。

14 / 写在最后：这场范式跃迁，留给谁？

让我们退一步，看看这场范式跃迁的真正含义。

从提示，到上下文，到 harness，到循环。 每一层，人类离"现场"都更远一步。循环工程是这条阶梯的顶端：它不再假设"人在场"，而是假设"人在场外，构建那个会自己跑的东西"。

这件事之所以现在发生，不是因为某个模型突然变强了。而是因为三个条件同时成熟了：

1. Agent 可靠到能独立完成非平凡任务；
2. 调度原语出现在主流框架里；
3. 单次运行成本便宜到可以反复跑。

当所有零件都齐了，那个把它们组合起来的动作，对所有人一下子变得显而易见。

于是，在一周之内，三个互不通气的人，抓住了同一个词。

但范式跃迁从不平均分配它的红利。

• 它会奖励那些在循环里认真放进"能说不的东西"、并且自己每天读样本、留一扇门的人。
• 它会惩罚那些只想"再也不用理解"、把判断外包给一个对着自己点头的循环的人。

同一个循环，两个人搭，半年后一个变强了，一个成了自己机器的看门人。差别不在循环，而在那个搭循环的人：他带来的是理解，还是懒惰。

最后，把这句话带走：

别再提示 agent 了，去设计那个提示它的系统；但要像"打算继续当工程师"那样去设计，而不只是"按开始的那个人"。

剩下的，不在任何文章里。它在你的终端里。

本文基于 IEEE 风格论文《Loop Engineering: The Anthropic Playbook》及 Addy Osmani、Peter Steinberger、Boris Cherny、Prithvi Rajasekaran（Anthropic）、Steve Kaliski（Stripe）等人的公开论述综合而成，原论文由社区整理，2026 年 6 月发布。

所有产品细节（命令、参数、版本号）可能随官方文档更新而变化，请以各工具官方文档为准。