深度 · 进化解读
最近很火的 Loop Engineering 到底是什么
Anthropic 工程师的「循环工程」方法论详解：不再手动一句句提示 AI，而是设计一套能自己跑的循环系统
速览
Loop Engineering 由 Addy Osmani、Boris Cherny、Peter Steinberger 在 2026 年 6 月同一周各自独立撞上并命名：不再手动提示 AI，而是设计一套自动提示 AI 的系统，自己从「操作 AI」变成「设计驱动 AI 的系统」
一个循环由五步构成：发现任务、交接执行、独立验证、持久化状态、自动调度，五步缺任何一步都有对应的具名失败模式（点头循环／失忆循环／手动循环／盲循环／打结循环）
最关键也最容易被跳过的是验证：让 AI 给自己的输出打分会自我夸奖，必须换一个独立 agent 当挑刺专家，默认假设代码是坏的，要动手点页面截图，而不是只读代码
Stripe 的 Minions 流水线每周合并超过 1300 个机器写的 PR，可靠性来自确定性约束（linter 强制跑、agent 绕不过），不是更大的模型
循环会悄悄积累四种代价：验证债、理解腐化、认知投降、Token 账单爆炸，四者互相强化，最后一起爆发，守门人始终是人的判断力
1 缘起 · 命名
一周内，三个人撞上了同一件事
2026 年 6 月同一周内，Google Chrome 工程师 Addy Osmani、Anthropic 的 Claude Code 负责人 Boris Cherny、OpenClaw 作者 Peter Steinberger，各自没对过口风，却撞上了同一件事：他们已经不再手动提示 AI，而是在设计「自动提示 AI 的系统」。
Loop Engineering（循环工程）说的是一次身份转变：你从「坐在键盘前一句句指挥 AI 的人」，变成「设计一套能自己给 AI 派活的系统的人」。这句话的分量全压在「替换掉你自己」上。
⚡
为什么值得看：Steinberger 那条「该设计循环，不是提示 agent」的帖子破 800 万阅读 ；Cherny 的说法是「我现在写的是 loop，我的工作就是写 loop」；Osmani 在 6 月 7 日 把它命名为 Loop Engineering 写成文章。三句话指向同一个动作：你设计的东西，从 agent 的一个行为，变成了驱动 agent 的整个系统。而 Stripe 已经用这套模式，每周合并超过 1300 个机器写的 PR。
8,000,000+
Steinberger「该设计循环，不是提示 agent」那条帖子的阅读量
6 / 7
Osmani 把它命名为 Loop Engineering 并写成文章的日期，次日同步到 Substack
为什么偏偏这一周冒出来
三个人没有商量，却在同一周伸手抓同一个词，不是巧合，是周围的工具悄悄越过了一道门槛。三个条件同时成熟：coding agent 已经可靠到能无人值守干完一个非平凡任务；调度原语刚出现在主流工具里；单次运行的成本掉到了反复跑也不算浪费。零件都齐了，「把它们组合起来」这个动作就对所有人同时变得显然。
名字滞后于实践好几个月：在有人叫它 Loop Engineering 之前，人们早就在写循环了，就像在「generator/evaluator 分离」有名字之前，团队早就在给一个写代码的 agent 配一个审代码的 agent。这条规律值得记住，下一个新词不会来自模型发布，会来自某个能力便宜到让一种过去想都不敢想的组合变成日常的那一刻。
2 定位
它站在这四层的最上面
这些「XX 工程」不是互相取代，是一层摞一层，每层管的东西比下面大一号：从一句话，到一个上下文窗口，到一次运行，最后到一个能自己转的循环。点开每一层看它管什么、出错时炸多大。
Loop · 循环工程 在最上面一层 管什么：在 harness 之上做调度，让它自己一遍遍跑。核心问题：怎么让它无人值守反复转。 比下面一层多了三个动词：定时跑（到点自己醒，不用人按按钮）、拆子 agent（一个起草改动，另一个专门挑刺）、把自己的输出喂回下一轮（昨天的发现写进文件，今早读回来接着干）。出错爆炸半径：错误写进 state file，第二天当成既定事实读回来，沿着它继续建，可能传播很多轮才被发现。
Harness · 单次运行装备 arm one run 管什么：给单次 agent 运行配齐装备：能用哪些工具、允许哪些操作、出错怎么恢复、什么状态算完成。核心问题：这一次跑要带什么。 它武装一次运行，但不让这次运行自动重复。出错爆炸半径：agent 照着误读改了一次文件，但 run 结束、diff 可见，人 review 之后才上线。
Context · 上下文工程 the window now 管什么：此刻窗口里放什么：检索什么、怎么总结、清掉什么过时信息。核心问题：给模型看什么它才解得开。 一个塞满噪音的窗口，会浪费掉再好的提示。出错爆炸半径：一个自信的错误答案，发现不对清掉上下文即可。
Prompt · 提示工程 the words you write 管什么：给模型写的那句话：措辞、例子、角色、语气。核心问题：该告诉模型什么。 边界就是一次对话。麻烦在于它假设每次都有人坐在那里把提示递进去。出错爆炸半径：一次对话当场就看到，重写提示即可。
把同一个 bug（agent 误读了某个函数的返回值）放到四层里看：越往上，发现得越晚，代价越大。到了循环层，这个误读被写进 state file，第二天当成事实读回，沿着它一层层往上盖，等有人去看时，那个错误假设已经成了承重墙。
这是循环工程里最该记住的一条直觉：错误的代价，等于它在被人发现前活过的轮数；而循环按构造就是一台「把轮数最大化」的机器。 后面所有东西，evaluator、人工卡点、预算上限，存在的唯一目的，都是缩短「犯错」到「被发现」之间的距离。
3 五步
一圈五步，缺哪步都会以固定方式坏掉
「循环」别误读成空转。每一轮都干具体的事：找到值得做的活、交给 agent、验证对不对、把状态存下来、再决定下一步。五步缺任何一步，循环要么不转，要么原地打转，而且会以一种有名有姓的方式坏掉。
发现
交接
验证
能说不
持久化
调度
loop
一套自己转的系统
五步顺时针围成一圈，调度把这一轮没干完的活喂进明天那一轮 · 验证是整圈里唯一能说「不」的步骤
下面用 Osmani 给自己搭的「早晨 triage 循环」当例子，逐步看每步干什么，以及跳过它会变成哪种循环。
1
发现Discovery
triage skill 读昨天挂掉的 CI、还开着的 issue、最近合并的 commit，自己找出这一轮该干什么。关键是让 agent 自己找活，不是被递一张清单。这一步定了整个循环质量的天花板：捞上来的活没价值，后面四步做得再漂亮也是白做。
跳过 → 盲循环：还是你每天早上手动派活「修这三个 bug」，自动化了「做」却没自动化「找」，而「找」常常才是最贵的部分 2
交接Handoff
把活从调度系统递到干活的 agent 手里。每个值得做的发现，开一个独立的 git worktree，多个 agent 在各自目录里改代码，互不撞文件。每块活切得越干净，后面验证和合并越省事。
跳过 → 打结循环：几个 agent 并行却都改同一个目录，改动撞在一起，merge 成了没人解得开的乱麻，单 agent 时看不出问题，五个 agent 一起跑的那个早晨才暴露 3
验证Verification
⊘ 整圈里唯一能说「不」的步骤 最容易偷工、也最不能省的一步。第一个子 agent 起草好修复，换第二个子 agent 来审，指令不同，有时连模型都换。写代码那个 agent 给自己批作业批得太松，专门挑刺的那个能逮住前者说服自己放行的东西。没有真检查的循环，只是一个对自己点头的 agent。
跳过 → 点头循环：最常见的失败，每一轮都自我批准，以机器速度堆出一摞看起来没毛病的错误，跑了几百轮一次「不」都没说过，对任何真实工作量都是统计学上的不可能，正好证明根本没有检查 4
持久化Persistence
把结果落到能活过这次对话的地方：通过 connector 开 PR、更新工单，搞不定的进 inbox，还有一个 state file 记进度。循环的记忆不能只活在上下文窗口里，写进 markdown 或看板的东西不会忘。
跳过 → 失忆循环：好活发现了、干了，然后忘了干过，因为结果只在被清空的上下文窗口里，第二天重新发现同一个活，甚至重做一遍跟第一次的成果冲突，每天早上都从同一个地方起步，毫无累积 5
调度Scheduling
把「一轮」变成「一个循环」的就是它。triage 每天早上自动跑，state file 让没干完的发现接到第二天，第二天自己接着干。Osmani 的话：是 automation 让一个循环成为真正的循环，而不只是你跑过一次的某次运行。
跳过 → 手动循环：四步都好，就是没自动化，那不是循环，是一个你手动跑、然后忘了再跑的脚本，搭好那天演示惊艳，注意力一转就悄悄停了，最后一次运行就是被演示的那天