Loop engineering：从 prompt 操作者到 loop 设计者的 14 步路线图
Codez (@0xCodez)
2026-06-09
D
原文
---
title: "Loop engineering：从 prompt 操作者到 loop 设计者的 14 步路线图"
author: "Codez (@0xCodez)"
source_url: "https://x.com/0xCodez/status/2064374643729773029"
published_at: "2026-06-09T15:50:43.000Z"
fetched_at: "2026-06-11T02:01:21Z"
updated_at: "2026-06-11T02:08:58Z"
language: "zh"
review_status: "draft"
---
# Loop engineering：从 prompt 操作者到 loop 设计者的 14 步路线图
大多数开发者仍然在手动给 coding agent 写 prompt。他们输入，等待，读 diff，然后再输入。10 个 builder 里有 **9** 个，从来没有写过一个替他们 prompt agent 的 loop。
没有 **automation**，没有 **state file**，没有 **verifier**，没有 **schedule**。杠杆点已经变了——从*输入 prompt*，变成*设计会发 prompt 的系统*。这是一份 14 步路线图，带你从 prompt 操作者变成 loop 设计者。
> 关注我的 Linkedin，获取最新 AI alpha：linkedin.com/in/lev-deviatkin
这份 14 步路线图会帮你完成这个转变——内容来自 Anthropic 的工程文档、Addy Osmani 关于 loop engineering 的长文，以及近期的测量研究。
三个层级：先判断你是不是真的需要 loop，再学会 5 个构件，最后搭出一个最小可用、且不会反噬你的 loop。
**14 步。3 个层级。停止 prompt。开始设计。**
---
PART 1 **· 为什么，以及怎么测试**
### 01. Loop engineering 是把自己从 *prompt 操作者* 这个角色里替换出来。
过去两年，你想让 coding agent 产出东西，方式是：写一个 prompt，给足上下文，读它返回的内容，再写下一个 prompt。agent 是工具，而你一直握着它。**这部分正在结束。**
Loop engineering 是构建一个小系统，让它自己*找到*任务、*交给* agent、*检查*结果、*记录*发生了什么，并且*决定*下一步。你只设计一次这个系统。从那以后，由系统去 prompt agent。
Addy Osmani 把它拆成了六个部分：
Anthropic 的工程师现在每天合并的代码量，是 2024 年的 8 倍——Anthropic 自己也说，这个数字「几乎肯定夸大了真实生产力提升」。
数字可以争论。机制没什么可争的：**杠杆点已经从输入 prompt，转移到了设计那个会发 prompt 的 loop**。
---
### 02. 在构建任何东西之前，先跑 4 条件测试。
Loop 只有在四个条件下才配得上它的成本。漏掉一个，loop 花出去的就比赚回来的多。AlphaSignal 的分析里最诚实、也是大多数 X 长帖会跳过的部分是：
用大白话说，这四个条件是：
- **任务会重复发生。** loop 会把搭建成本摊到很多次运行里。一次性任务，用一个好 prompt 更快也更便宜。如果这件事不是每周都会发生，那你没有一个 loop——你只是跑过一次脚本。
- **验证是自动化的。** loop 需要某种东西，能在你不在场时判定这次工作失败。测试套件、类型检查器、linter、构建流程都可以。没有自动检查，就等于你又回到椅子上逐个读 diff——这正是 loop 本来要替你拿掉的工作。
- **你的 token 预算能承受浪费。** loop 会反复读取上下文、重试、探索。不管这次运行最终有没有产出可交付结果，都会烧 token。这种技术会随预算一起扩展，所以对 token 几乎免费的人来说它显得显而易见，对按量计费的人来说则显得莽撞。
- **agent 拥有资深工程师该有的工具。** 日志、可复现环境、能运行自己写的代码并看到哪里坏了的能力。没有这些，loop 就是在盲目迭代。
---
### 03. 谁会赢，谁会输。*Loop 偏向能花得起钱的人。*
这里的经济账并不普适。那些说 loop engineering 显而易见的人，往往有不计量的 token。
觉得它很莽撞的人，通常是在用 20 美元消费者套餐跑重型验证 loop，一边担心撞上额度限制，一边担心突然收到天价账单。
实践中真正受益的是：
- **拥有重复、可机器检查的工作，并且有预算去跑它的团队**——持续测试分诊、依赖升级、lint-and-fix 扫描、有强测试覆盖代码库上的 issue-to-PR 草稿。
- **已经有强测试套件的代码库。** 如果一个初级工程师能按 checklist 完成任务，而测试套件能抓住他的错误，那么 loop 就合适。
- **已经在用 multi-agent 模式的 async-first 团队。** 对这些团队来说，routines 正是缺失的编排层。
今天应该先跳过的人：
- **使用消费者套餐的独立 builder**——token 账单会比生产力收益更早到来。
- **任何在没有自动化验证的代码上工作的人。** 没有真实检查的 loop，就是 agent 在一遍遍赞同自己。
- **真正瓶颈是 review 能力，而不是打字速度的团队。** loop 会生成更多代码；如果 review 已经是瓶颈，它只会把队列变得更长。
对于一次性任务、探索性工作，或者任何「完成」本身需要判断的事情，**一个瞄准得很准的 prompt 仍然赢**。这篇文章的诚实版本是：loop engineering 是真的，但大多数开发者还不需要它。
---
### 04. 30 秒 loop 检查。
第 2 步的 4 条件测试是战略判断。这里是战术判断——在你把某个具体任务变成 loop 之前，先跑一遍这个 checklist。
**漏掉任何一项，就继续把它当成手动 prompt。**
- **1. 这个任务至少每周发生一次。** 低于每周一次 → 搭建成本永远摊不回来。
- **2. 测试、类型检查、构建或 linter 能拒绝坏输出。** 没有自动闸门 → agent 在批改自己的作业。
- **3. agent 能运行自己改过的代码。** 没有复现环境 → 迭代就是盲飞。
- **4. loop 有硬停止条件。** token 预算、迭代次数或时间限制。没有这一条，loop 会一直跑到有人注意到账单为止。
- **5. merge、deploy 或依赖变更前有人类 review。** 任何不可逆动作，在执行前都需要人类批准闸门。
适合作为第一个 loop 的任务：
- **CI failure triage**——每晚扫描失败、分类原因，并为简单问题起草修复 PR。
- **Dependency bump PRs**——每周扫描更新、测试兼容性、打开 PR。
- **Lint-and-fix passes**——每次 PR 打开事件触发，自动应用样式修复。
- **Flaky test reproduction**——持续循环，直到某个解释能经受住测试。
- **Issue-to-PR drafts**——适用于测试很强的代码库，坏输出会被测试套件拒绝。
不适合作为第一个 loop 的任务——这些需要人坐在椅子上：
- 架构重写
- 认证或支付代码
- 生产部署
- 模糊的产品工作
- 任何「完成」需要判断的事情
---
**PART 2 · 5 个构件**
### 05. Automations：心跳。
Automations 让 loop 成为真正的 loop，而不是你只跑过一次的单次运行。它们按 schedule、event 或 trigger condition 触发。它们是心跳——loop 里的其他东西都挂在它们上面。
在两个重要工具里，它大概长这样：
- **Codex。** Automations 标签页——选择项目，设置 prompt，设置 cadence，选择本地 checkout 或后台 worktree。发现东西的运行会进入 Triage inbox；什么都没发现的运行会自动归档。
- **Claude Code。** 三个 primitive 组合出同样的形状：
/loop 用于 session-scoped cadence，Desktop scheduled tasks 用于重启后继续存在，Routines 用于笔记本关机后的云端运行。再配合 hooks 处理生命周期事件。
automation 里有两个 primitive，能把能工作的 loop 和烧钱 loop 区分开：
- **/loop** 按 cadence 重跑。适用于你想不管状态如何都定期检查的场景。
- **/goal** 会一直跑，直到你写下的条件真的成立。一个独立的小模型会检查完成情况，所以写代码的 agent 不是给它打分的那个。
*这是把 maker-vs-checker 分离应用到停止条件本身。*
```python
> /loop 30m /goal All tests in test/auth pass and lint is clean.
Scan src/auth for new failures, propose fixes in claude/auth-fixes,
open draft PR when goal condition holds.
▲ Claude
CronCreate(*/30 * * * * : auth quality loop)
Stop condition: tests pass + lint clean (verified by checker)
✓ Scheduled. Will continue past intermediate completions
until /goal condition is met by independent checker.
```
---
---
### 06. Worktrees：并行但不混乱。
只要你运行超过一个 agent，文件就会开始互相撞车。两个 agent 写同一个文件，麻烦程度就像两个工程师在没沟通过的情况下改同几行代码。
***git worktree 可以解决*这个问题**——它是在自己分支上的独立工作目录，但共享同一个 repo 历史，所以一个 agent 的改动从物理上就碰不到另一个 agent 的 checkout。
它在两个工具里的表现方式：
- **Codex** 内置 worktree 支持——几个 thread 可以同时打到同一个 repo 上，不会互相撞。
- **Claude Code** 直接暴露 git worktree，一个 --worktree flag 可以在自己的 checkout 里打开 session，subagent 上还有 isolation: worktree 设置，让每个 helper 都拿到一个全新的 checkout，用完自己清理。
**Worktrees 拿掉了机械性的冲突，但你仍然是天花板。** 你的 review 带宽决定你实际上能跑多少个并行 agent——不是工具决定的。
---
### 07. Skills：项目知识只写一次。每次运行都读。
Skill 是让你不用像金鱼一样每个 session 都重新解释同一份项目上下文的办法。两个工具使用同一种格式：一个文件夹，里面有 SKILL.md，保存 instructions 和 metadata，另可附带 scripts、references 和 assets。
为什么这对 loop 尤其重要：没有 skills 的 loop，每一轮都会从零重新推导你的整个项目上下文。**有了 skills，意图会滚起雪球。**
约定、构建步骤、「因为当年那次事故所以我们不这么干」——这些东西一次写在外面，每次运行都能读到。
```python
name: ci-triage
description: Classify CI failures by root cause (env, flake, real bug,
dependency, infra), draft fixes for the easy ones, escalate the rest.
Trigger whenever a workflow run fails or on the morning triage loop.
---
# CI triage skill
## Classification rules
- env: missing secret, wrong env var, infra not provisioned. # human
- flake: passes on retry without code change. # retry once, then file
- bug: deterministic failure tied to recent commit. # draft fix
- dependency: failure tied to a version bump. # draft rollback
- infra: timeout, OOM, runner issue. # escalate
## Fix patterns
- Auth tests → check src/auth/middleware first
- Database tests → verify migration applied in CI env
- E2E tests → check selectors against the latest UI snapshot
## Never do
- Disable failing tests — always file as escalation instead
- Modify CI config without human approval
- Touch src/payments/ or src/billing/ (in claude/permissions.md)
## State
Update STATE.md after each run: file paths checked, classifications,
PRs opened, items escalated.
```
---
### 08. Connectors：loop 触达你的真实工具。*通过 MCP。*
一个只能看文件系统的 loop，是很小的 loop。基于 Model Context Protocol（MCP）构建的 **Connectors**，可以让 agent 读取你的 issue tracker、查询数据库、调用 staging API，或者往 Slack 里发消息。
Codex 和 Claude Code 都支持 MCP，所以你为其中一个写的 connector，通常在另一个里也能直接用。
这就是「agent 说：这里是修复方案」和「loop 打开 PR、关联 Linear ticket，并在 CI 绿了以后 ping 频道」之间的区别。
connectors 之所以重要，是因为它们让 loop 能在你的真实环境里行动，而不是只告诉你「如果我能做，我会怎么做」。
对 loop 工作回报最快的 connectors，按顺序是：
- **GitHub**——读取 repo、创建分支、打开 PR、评论 issue、响应 webhook events。任何代码 loop 第一天最值的一项收益。
- **Linear or Jira**——随着 loop 推进更新 ticket，把 PR 链回 issue，在验证通过后自动关闭条目。
- **Slack**——发布分诊结果，在需要升级时 ping 人，早上汇总夜间运行结果。
- **Sentry / your error tracker**——让 loop 调查线上告警，并为高频问题起草修复。
---
### 09. Sub-agents：让 maker 远离 checker。
loop 里最有用的结构性设计，远远超过其他东西：把写东西的 agent 和检查东西的 agent 分开。
Osmani 的说法非常准确：写代码的模型在给自己批改作业时「实在太好说话了」。第二个 agent，配上不同指令，有时再换一个模型，能抓住第一个 agent 自己说服自己的那些问题。
这就是 Anthropic 2024 年 12 月工程文章里的 **evaluator-optimizer pattern**，只是换了个新名字。一个模型生成，另一个模型批评，如此反复。2026 年走红的这套词汇，十八个月前就已经写在文档里了。
sub-agents 在两个工具里是这样落地的：
- **Codex** 只有在你要求时才会启动 subagents，让它们同时运行，然后把结果合并回一个答案。你可以在 .codex/agents/ 里用 TOML 文件定义自己的 agents——name、description、instructions、可选 model 和 reasoning effort。
你的 security reviewer 可以用一个 high effort 的强模型，而 explorer 可以用某个快速的只读模型。
- **Claude Code** 也用 .claude/agents/ 里的 subagents 和 agent teams 做同样的事，让它们彼此传递工作。
常见拆法是：一个 agent 探索，一个实现，一个按 spec 验证。
**它在 loop 里尤其重要的原因是：**loop 会在你没盯着的时候运行，所以一个你真的信得过的 verifier，是你能走开的唯一理由。
Sub-agents 会烧更多 token，因为每个 subagent 都要跑自己的模型和工具工作——只在第二意见值得付钱的地方花。
---
PART 3 **· 要么正确构建，要么别构建**
### 10. State file。*agent 会忘。文件不会。*
这部分听起来蠢到不像有用，但它其实是每个能工作的 loop 的主心骨。一个 markdown 文件、一个 Linear 看板、一个 JSON state——*任何活在单次 conversation 之外*、并保存已完成事项和下一步事项的东西。
为什么它重要：agent 默认记忆很短。这个 session 里学到的东西，明天就没了，除非你把它写下来。
**Osmani 的规则是：agent 会忘，repo 不会。** 没有持久 state 的 loop，每次运行都会从头开始；有 state 的 loop，能接着上次继续。
```json
# Loop state · ci-triage
## Last run
2026-06-09 03:30 UTC · 7 failures classified, 3 fixes drafted, 4 escalated
## In progress
- claude/fix-auth-token-refresh — tests passing locally, awaiting CI
- claude/fix-flaky-payment-webhook — retry pattern applied, monitoring
## Completed today
- claude/bump-axios-1.7.4 → merged (CI green, deps loop verified)
- claude/lint-fix-pass-june-9 → merged
## Escalated to humans
- src/billing/refund.ts — tests failing in 3 ways, root cause unclear
- ci/staging-runner — infra timeouts, not a code issue
## Lessons learned (write here, not in chat)
- 2026-06-08: PowerShell hits TLS 1.2 issue on this Windows runner. Use bash.
- 2026-06-07: tests/e2e/checkout requires Stripe webhook secret in env. Skip if missing.
## Stop conditions met since last review
- /goal “all tests pass + lint clean” achieved on commit 3a7b8c1 at 02:14 UTC
```
state file 可以放在两个地方：
- **repo 里的 Markdown**——根目录下的 STATE.md，或者 .claude/ 里的文件。进版本控制。简单。diff 可读。最适合个人或小团队。
- **外部系统（Linear、GitHub Issues、数据库）**——跨 repo 存活，可查询，支持团队级可见性。最适合需要多人看到 loop 正在做什么的生产 loop。
对有可能偏离目标的长时间运行 loop，要把 state file 和**长期高层 spec** 搭配起来——比如 VISION.md 或 AGENTS.md，让 agent 每次运行都重新读。State 告诉 agent *它在哪里*。spec 告诉它*要去哪里*。
---
### 11. 最小可用 loop。
如果你通过了第 2 步的 4 条件测试，那就先构建一个最小可用的 loop，*在*任何花哨东西之前。**四个部分，不要 swarm。**
用大白话说，这四个部分是：
- **一个 automation。** 一个按 cadence 触发、并在明确条件下停止的 scheduled run。在 Claude Code 里用 /loop，或者在 Codex 里用 automation。如果你希望它一直跑到某个声明条件成立，就配上 /goal。
- **一个 skill。** 一个 SKILL.md，保存 agent 否则每次都要从零重新推导的项目上下文。
- **一个 state file。** 一个 markdown 文件或 Linear 看板，记录已经完成什么、下一步是什么。明天的运行会继续，而不是重启。
- **一个 gate。** 测试、类型检查或构建，用来自动拒绝坏工作。**这一部分决定了 loop 是在帮忙，还是只是在烧钱。**
**顺序很重要：**先让一次手动运行可靠。把它变成 skill。再包进 loop。最后 schedule。跳步骤，是 loop 在生产里失败的常见方式。
真正重要的指标是 **cost per accepted change**——不是花了多少 token，不是尝试了多少任务，也不是 schedule 了多少 loop。如果你的 accepted-change rate 低于 50%，你就在做 loop 本来应该替你省下来的 review 工作，这个 loop 就是在亏。
---
### 12. Ralph Wiggum loop。*静悄悄失败的 loop。*
工程师 Geoffrey Huntley 记录并命名了这种失败模式。一个 agent 本应只在完成时发出 completion token，却提前发了，于是 loop 在一个半成品任务上退出。没有硬 gate，loop 就会静悄悄地失败，并继续烧钱。
Ralph Wiggum loop 会在这些情况下出现：
- **没有真正的 verifier。** 只是让第二个 agent「review」一下，没有客观信号。两个乐观派互相点头。
- **软性的完成条件。** 「完成」由 agent 判断，而不是由测试、构建或类型检查定义。
- **没有硬停止。** loop 一直运行，直到某个外部东西把它杀掉（rate limit，或者你注意到），而不是直到成功被验证。
修复办法就是第 11 步里的 gate——**某个能客观判定工作失败的东西**。测试通过或失败。构建能编译或不能编译。linter 返回 0 或非 0。不是一个发表意见的 verifier。
其他值得知道的实测失败模式：
- **长 session 里的 goal drift。** 每次总结都会丢信息；「不要做 X」这种约束会在第 47 轮消失。缓解方法：每次运行都重新读 standing VISION.md 或 AGENTS.md。
- **Self-preferential bias。** 写代码的 agent 对自己的作业太宽容。缓解方法：用一个没看过 maker 推理过程的独立 verifier subagent。
- **Agentic laziness。** loop 在部分完成时就宣称「够好了」。缓解方法：用 /goal，并让一个新模型检查客观停止条件。
---
### 13. Comprehension debt 和 cognitive surrender。
这是一个会随着 loop 变得*更好*而更尖锐的失败模式，不是随着它变差才出现。两个命名风险，都来自 Osmani 的文章：
- **Comprehension debt。** loop 越快地交付你没写过的代码，repo 里实际存在的东西和你理解的东西之间距离就越大。真正让你疼的账单不是 token 账单，*而是有一天你不得不调试一个团队里没人读过的系统。*
- **Cognitive surrender。** 那种停止形成自己的判断、直接接受 loop 返回内容的冲动。带着判断力设计 loop，是解药；为了逃避思考而设计 loop，是加速剂。**同一个动作，结果完全相反。**
缓解方式不是技术性的：
- **读 diffs。** 如果你不读 loop 发出来的东西，你就是在让 comprehension debt 滚雪球。
- **抽查 gate。** 挑几个 loop 打开的 PR，确认批准它们的测试真的能抓住你关心的失败模式。gate 会腐烂。
- **禁止 loop 做架构工作。** 让它只处理小的、可机器检查的变更。一旦你让它碰需要判断的事情，comprehension debt 就会加速。
- **和队友一起设计 loop。** 在设计 loop 时，多一双眼睛能发现盲点，否则 loop 会永远利用这些盲点。
---
### 14. 安全税。*无人值守的 loop，就是无人值守的攻击面。*
一个无人值守运行的 loop，也是一个无人值守运行的攻击面。
你的 loop 必须防住的 threat model：
- **生成代码未经 review 就发出。** loop 打开 PR 的速度超过人类阅读速度。如果 gate 不包含安全检查（SAST、dependency audit、secret scanning），不安全的代码就会自动合并。
- **Skills 成为注入向量。** 自动安装 skills 的 loop，会继承隐藏在它们 description 里的每一个 prompt injection。安装前先审计 skill 来源。
- **凭据散落在日志里。** 长时间运行 loop 里的 debug logging，会把 secrets 撒进你没有监控的日志。生产 loop 里关闭 verbose logging；对确实记录的内容做脱敏。
- **权限范围蠕变。** 一个用 read-only 权限测试过的 loop，为了方便被加了「就一个」写权限，然后再也没人重新审计。*每 30 天重新审计权限。*
---
### § 把 loop 变成烧钱坑的错误
- **没有跑 4 条件测试就构建 loop。** 第 2 步存在是有原因的。大多数开发者至少会漏掉一个条件。
- **没有客观 gate。** 让第二个 agent 在没有测试、类型检查或构建的情况下「review」，只是多了一个乐观派。
- **一个 agent 同时写和验。** Self-preferential bias。maker 批改自己的作业，而且永远是「A+」。
- **没有 state file。** 明天的运行从零开始，而不是继续。
- **停止条件模糊。** 「看起来不错就算完成」永远不会成立。用测试、类型通过或构建通过。
- **没有 token budget cap。** loop 会重读上下文并重试。没有 cap，野心大的 loop 会烧掉你预期的 5–10 倍 token。
- **在消费者套餐上跑重型验证 loop。** token 账单和 rate limit，总有一个会抓到你。
- **自动安装社区 skills。** 被审计的 17,022 个 skills 里，有 520 个会泄露凭据。安装前读源码。
- **把 loop 用在需要判断的工作上。** 架构、认证、支付、模糊产品决策。让 loop 做 lint-and-fix，不要让它做战略。
- **不读 diffs。** comprehension debt 会滚雪球。有一天你要调试一个没人读过的系统，那一天的成本会比 token 贵得多。
---
### 结论：
### 杠杆点变了。*你的工作也变了。*
过去两年，和 coding agent 协作的杠杆在 prompt 上。更好的 prompt，更好的上下文，更好的一次性输出。
**那个阶段正在结束。** agent 已经足够强，所以下一个杠杆点上移了一层：那个决定它们做什么、什么时候做、用什么 gate，以及哪些 state 能在运行之间保留下来的系统。
但这个故事的诚实版本，并不是每个人都应该冲去构建 loop。**大多数开发者还不需要 loop**——除非任务会重复，验证已经自动化，预算能吸收浪费，并且 agent 拥有资深工程师的工具。
漏掉一个条件，loop 花出去的就比赚回来的多。
如果你通过了测试，就从小处开始。**一个 automation。一个 skill。一个 state file。一个 gate。** 先让一次手动运行可靠。把它变成 skill。包进 loop。然后 schedule。顺序很重要。跳步骤，你就是在为一个没人理解的系统付钱。
Cherny 的意思不是工作变简单了。*而是杠杆点变了。* **构建 loop。继续当工程师。**