大多数开发者仍然在手动给 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 分离应用到停止条件本身。
> /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，意图会滚起雪球。
约定、构建步骤、「因为当年那次事故所以我们不这么干」——这些东西一次写在外面，每次运行都能读到。
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，能接着上次继续。
# 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。继续当工程师。