Loop Engineering：当你的工作从「提示 Agent」变成「设计提示 Agent 的系统」

过去两年，"XX Engineering"一个接一个：Prompt → Context → Harness。它们都在教你把活干得更好。直到 Loop Engineering——它干脆把你从"干活"这个位置上挪走了。

引子：一周之内，三个人点燃了同一个词

2026 年 6 月，一周之内，三组人几乎同时撞出了同一个词。

先是 OpenClaw 作者 Peter Steinberger 发了条阅读量八百万的帖子：不该再去 prompt 那些 coding agent，而该去设计提示它们的循环。几乎同一时刻，Anthropic 的 Claude Code 负责人 Boris Cherny 说了同样的意思——他已经不再 prompt Claude，而是跑一些"提示 Claude、并让它自己想清楚要干什么"的循环，他的工作就是写循环。6 月 7 日，Google Chrome 的 Addy Osmani 把它命名并写成博客，标题就叫 Loop Engineering。

三句话叠在一起，指向同一个动作：人们关心的设计对象，从"单个 agent 的行为"上移到了"驱动整个 agent 的系统"。和"vibe coding"刚出现时一样，这词初听有点糙，但它框住了一种正在发生的工作方式。

这篇文章是我读完那份开源指南后的精读笔记。先说结论：它不是一篇同行评审论文，而是一次高质量的行业观点提炼——但里面最硬的几条洞察，工程上站得很稳。

一、四层栈：每往上一层，错误埋得越深

把这些"XX Engineering"排成一摞，它们不是互相替代，而是各自盯着更大的一层：

关注的"单位"逐层变大：一句话 → 一个窗口 → 一次运行 → 一个会自转的循环。前三层都假设"人坐在键盘前，逐行指挥"；Loop Engineering 删掉了这个假设——人不再在循环里面，而在循环外面，造这个循环。

这一层最致命的特性，是错误的 blast radius 随层级放大。同一个 bug——比如 agent 误读了某个函数的返回值——在不同层后果完全不同：

• Prompt 层：当场产出一个错答案，你立刻看到、改提示。
• Context 层：来自窗口里的过期文档，你发现它"自信地错"，清掉 context。
• Harness 层：agent 据错动手改了文件，但运行结束、diff 可见，你在合并前 review。
• Loop 层：误读被写进状态文件，第二天被当作既成事实读取，并在后续多轮里被层层建造。等有人发现时，这个错误假设已经在承重。

一句话记住它：错误的成本 = 它在被发现前存活的轮数。而循环，按定义就是一台"最大化轮数"的机器。后面所有的机制——评估器、人类检查点、预算上限——都是为了缩短"错误发生"到"被发现"的距离。

二、一个循环的五个动作

"loop"这个词容易被误读成"空转"。实际上每一轮都做五件具体的事，缺任意一个，循环就不转、或原地打转：

1. Discovery 发现——自己找出这轮该干什么（读 CI 失败、open issues、最近 commits）。关键是靠一个 skill（固化的知识）来找，而不是塞在 cron 里、没人维护的一大段指令。它设定了整个循环质量的上限。
2. Handoff 交接——把任务丢进隔离的 git worktree，多个 agent 并行改代码而互不踩。
3. Verification 校验——换另一个 agent来说"不"。最容易偷懒、也最不该省的一步。
4. Persistence 持久化——结果落到对话之外：PR、ticket、状态文件。记忆不能只活在 context 窗口里。
5. Scheduling 调度——让"一轮"变成"循环"：定时自动跑，状态文件让没干完的活第二天接着干。

这五个动作背后，是六个必须先备好的零件：Automations（触发器）、Worktrees（并行隔离）、Skills（固化项目知识、省掉反复解释的"intent debt"）、Connectors（基于 MCP 连外部系统）、Sub-agents（写的人和判的人分开）、Memory（磁盘上的持久状态）。

骨架就这么多。但接下来这句要划重点：同一套零件，两个人搭，六个月后结果可以完全相反。

三、全文最硬的一节：生成器不能给自己打分

如果整篇只能记一条，记这条。

它总会夸自己。 让一个 agent 给它刚写的东西打分，它会自信地夸，哪怕质量平庸。这不是智商问题，是"批改自己作业"的结构问题——它看到的不是结果，而是"自己当初为什么这么写"的那条自我说服链。放进循环里，这个缺陷被放大：每一个"够好了吗"，都由刚写完它的 agent 自己拍板，跑得越久，离真实质量越远。

Anthropic 工程师 Prithvi Rajasekaran 发现的解法，反直觉但关键：别去修一个谦虚的作者，去调一个怀疑者。

让单个生成器学会自我批判，效果很差，因为差异是结构性的：你没法让作者跳出自己的视角；但你可以换一个指令完全不同、甚至模型都不同的 agent，从零看代码、不带任何自我说服。这思路直接借鉴了 GAN——一个网络生成、另一个挑错。

而且这个评估器要会动手，而不是只读。只读代码判断"看起来对不对"是不够的，要判断"能不能跑"。把它接上 Playwright MCP，让它真的打开页面、点按钮、截图、查 DOM，像个 QA 工程师那样。它的默认立场应该是：假设代码是坏的，除非被证明（doubt, not trust）。

Claude Code 把这套固化成了一个原语 /goal：给一个条件，循环跑到条件满足为止，由一个新的、独立的小模型来判断条件是否成立。这正是银行业几十年的老规矩——下大额转账的人，和复核的人，必须是两个人——只不过现在用到了 AI 循环的停止条件上。

循环的下限，是它的评估器。生成器的水平决定循环能产出什么；评估器的水平决定它会放行什么。

四、五种失败，每一种都是跳过了一个动作

在看成功案例之前，先看失败——它们更常见，也更有教益。五种反模式，和五个动作一一对应：

这五种不是独立的：缺校验的循环往往也缺持久化——对一个检查马虎的团队，对所有检查通常都马虎。纪律好的循环装齐五个；草率的循环只装"出可见产出"的发现和交接，跳过那三个"出安全"的。

五、它们已经在跑：从一个人的早晨到每周 1300 个 PR

Osmani 的早晨，是一人一机的样子。每天自动跑一个 triage 循环：读昨天失败的 CI、open issues、最近 commits → 每个值得处理的发现开一个隔离 worktree，一个 sub-agent 起草修复、另一个对照测试审查 → connector 自动开 PR、更新 ticket → 处理不了的进 inbox 等人 → 状态文件存进度，第二天接着干。值得反复强调的细节：自动化调用的是一个 skill，不是塞进 schedule 的一大段指令。

Stripe 的 Minions，是企业规模的样子——每周 1300 多个由人工合并的 PR（Stripe 工程师 Steve Kaliski 在 How I AI 播客披露）。触发很轻：Slack 里 @bot，或者一个 emoji 反应。但它最反直觉的一点是：

可靠性来自约束的质量，不是模型的大小。

Minions 是开源工具 Goose 的一个 fork，架构是确定性闸门和 LLM 步骤交替：

人触发(Slack @bot)
  → 确定性编排器(扫链接 / 拉 Jira / Sourcegraph + MCP 组装上下文，非 LLM)
  → LLM agent 带着材料写代码
  → 硬编码闸门(linter，agent 不能跳过)
  → LLM agent 修 lint
  → 硬编码步骤(git commit)
  → 人类 review(1300 PR / 周)

确定逻辑能解决的，绝不交给概率模型。它跑在 EC2 的 Devbox 沙箱里，"cattle not pets"，环境随用随弃，上千个 agent 同时跑互不干扰。注意：人没有离开，只是从"写代码"转成了"审代码"。

至于调度该放本地还是上云，判据其实很机械——循环的活是不是绑死在本机上：每分钟查本地 dev server，只能本地跑（云调度间隔下不到一小时）；凌晨三点扫仓库 issues、开 PR，就该上云，因为笔记本会被合盖断电。最该避免的混淆，是把"本地重跑"当成"睡觉时也在跑"——前者是"我在的时候多跑几轮"，后者是"我不在也跑"，把这俩搞混，正是很多人合上笔记本、以为循环在自治、其实它早就悄悄停了的原因。

六、四种悄悄累积的成本

循环会自己跑，也会自己犯错；而且跑得越欢，错得越静。四种成本，互相强化成一个环：

• 校验债：合并了、但没人独立验过的 PR。省下的时间，变成"待还的未验证输出"，攒到某个早晨一次爆雷。
• 理解腐烂：循环写得比你读得快，你脑中的代码地图落后于真实代码库——无声无息，直到某个 bug 钻进一个你从没读过的角落。
• 认知投降："没时间看"慢慢变成"懒得有意见"。循环越可靠，你越想把判断外包出去。
• 费用爆炸：唯一直接打到账单上的成本。一个 bug 能空转一整夜烧钱。

想象一个开了 20 个 PR、全绿测试的循环——表面是大捷。但若其中 3 个含测试覆盖不到的隐错：它们被 merge（校验债），你没读这些改动（理解腐烂），整批交给了循环（认知投降），整夜重试（费用爆炸）。三个错误最终只会以"生产事故"的形式被发现。这四种成本，不是四个独立风险，是同一种失败的四张脸。

七、真正稀缺的，是判断力

这是全篇的论点核心。

当生成变得几乎免费——代码、计划、修复、PR 都廉价——真正稀缺的，就剩判断力：知道哪个计划对、哪一行该停、哪个看似没问题的输出其实错在根上。循环能生成一百个"看起来合理"的方案，但它没法告诉你哪个"实际正确"，而这道 gap，恰恰是工程师存在的理由。

于是价值被重新分配：价值主要来自"机械劳动"（快速打字、广背 API、磨样板代码）的工程师，会发现价值在蒸发；价值来自"判断"的工程师，会发现价值被放大了一百倍。

循环是一个忠实的乘法器。 它放大你带进去的东西——带懂行，放大懂行；带懒，放大懒。同一个循环，一个人用它在已掌握的事情上加速（他读代码、有方向感），另一个人用它来"再也不必理解"，六个月后，一个变得更强，另一个成了"一台自己看不懂的机器的守门人"。差别不在循环，在人。

放大器是双向的刀。旧世界里一段手写的错代码，blast radius 有限、慢到能被抓住；新世界里一个坏决策，被机器忠实地批量执行一百次，中途不会停下来问一句"这对吗"。循环移除了过去那个"慢到能让你中途发现错误"的减速齿轮——这正是"保持自己是个工程师"不是情怀、而是运营必需的原因。

八、三条纪律，和你的第一个循环

如果判断力是稀缺资源，那实际问题就是：怎么把它花在刀刃上。三条可以当成长期实践的纪律：

1. 永远读一个样本（防理解腐烂）——不是读全部，而是每天读一个有代表性的样本，强迫自己解释每处改动"做了什么、为什么"。解释不出来，就是你的心智地图已经落后了。
2. 上线前设硬上限（防费用爆炸）——单次预算 + 每日预算 + 最大重试。这不是为了省钱，是把"开放式风险"变成"有界风险"的断路器。无上限的循环，等于把花钱的权力委托给了自己的 bug。
3. 永远留一扇门（防认知投降）——至少保留一个人类检查点。不是因为人总会介入，而是**"暂停的存在"本身，让你始终处在能介入的位置**。把每扇门都焊死、赌自己永不需要进去的人，会在需要的那天发现进不去。

而你的第一个循环，应该小到不像一个系统——一个在定时器上检查点小东西就够了。安全的生长顺序是这样（并行永远最后加）：

1. /loop 定时重跑（Claude Code，session 级、本机）；
2. 把发现逻辑写进一个 skill，不是写进 schedule；
3. 加一个状态文件——agent 会忘，repo 不会；
4. 加评估器（最关键、也最容易省）：/goal 跑到条件满足，由另一个模型判断；
5. 最后才加 worktree 做并行（--worktree），等检查被证明能抓到真错之后再上。

搭之前，对着这张清单自问一遍：发现源读什么？状态文件存哪？有没有能说"不"的评估器？每个并行 agent 有自己的 worktree 吗？设了 token 上限、跑飞了谁来停？哪一步会停下来让你看？——前两个决定循环能不能跑，后四个决定它出事时能不能被拦住。新手最常只装前两个，结果就是那个"没人看、没人能停"的点头循环。

收束

这份 playbook 真正想说的，最后浓缩成一句：

停止提示，去设计那个提示你的系统——但要像一个打算继续当工程师的人那样去设计它，而不是像一个只想按下启动键的人。

循环让"生成"变得极度廉价，于是唯一剩下的稀缺品，是判断力。循环是这一代软件实践里最强的工具，恰恰因为它是其建造者最忠实的乘法器——而一个忠实的乘法器，跟你喂给它的判断力一样有价值，也一样危险。

真正会让团队吃惊的，从来不是"搭循环变难了"（那部分确实变容易了），而是**"它就是能用"的那种愉悦感，会多快侵蚀掉当初让它能用的纪律——以及这种侵蚀，在某个早晨爆雷之前有多隐形**。

到头来，这本 playbook 关心的，是保持那种"在任何一个早晨，都还答得出'循环刚才那一下到底对不对'"的工程师。

本文是我读 Addy Osmani 等人开源指南 Loop Engineering: Stop Asking Me What It Is（Orange Books, 2026-06）后的精读笔记。术语与表述源自 Addy Osmani；generator/evaluator 部分源自 Prithvi Rajasekaran（Anthropic）；企业案例源自 Steve Kaliski（Stripe）。文中 /loop、/goal、--worktree、SKILL.md 等为 Claude Code 特定命令，Codex 等工具有同样能力但命名不同。