Loop 工程：从 prompter 到 loop 设计师 [翻译]

由 Claude Code 翻译自 Codez (@0xCodez) 的 X 长文

大多数开发者还在手动给编码 Agent 写提示词，敲一段、等一段、读一段 diff，再敲下一段。10 个 builder 里有 9 个从没写过一个能自动替自己 prompt 的 loop——没有自动化、没有状态文件、没有 verifier、没有调度

杠杆点已经从"敲提示词"挪到了"设计 prompt 系统"。这就是从 prompter 转向 loop 设计师的 14 步路线图，素材来自 Anthropic 的工程文档、Addy Osmani 关于 loop 工程的长文，以及最近的若干量化研究

三个层次：先判断你是不是真的需要一个 loop，再学会五块积木，最后搭出最小的那个不至于反噬你的版本

14 步，3 个层次，停止 prompt，开始设计

01 为什么要做以及测试是否值得做

1.1 Loop 工程，就是替换掉作为 prompter 的你自己

过去两年，让编码 Agent 干活的姿势是：写一段 prompt，给上下文，看返回，写下一段 prompt。Agent 是工具，你全程攥着它。这阶段正在结束

Loop 工程是搭一个小系统，由它来找活、把活交给 Agent、检查结果、记录过程、决定下一步——全自动。你只设计一次，从此之后，是系统在 prompt Agent

Addy Osmani 把这件事拆成六块：

Anthropic 工程师现在每天合入的代码量是 2024 年的 8 倍——这个数字 Anthropic 自己都承认"几乎可以肯定夸大了真实生产力提升"

数字本身可以争议，但机制不能：杠杆点从"敲 prompt"挪到了"设计 prompt 的 loop"

1.2 在动手之前先跑 4 个条件测试

Loop 要赚回它的成本，必须同时满足 4 个条件。漏掉一个，loop 的成本就会高过它能带来的回报。AlphaSignal 分析里最实在的一段，也是大多数 X 上的 thread 都跳过的部分：

四个条件，大白话版：

• 任务会重复发生：loop 的搭建成本要靠很多次运行摊销。一次性任务，写个好 prompt 又快又便宜。如果这活每周都不发生一次，那你不是有个 loop，你只是有个跑过一次的脚本
• 验证可以自动化：loop 需要某个东西能在你不在场时判负——测试套件、类型检查、linter、build。没有自动检查，你就被拉回椅子上挨个看 diff，那正是 loop 想消除的工作
• Token 预算扛得住浪费：loop 会反复读上下文、重试、探索，无论本次有没有产出代码都在烧 token。这个手艺随预算放大——对 token 几乎免费的人来说显而易见，对走计量套餐的人来说是不负责任
• Agent 有资深工程师那套工具：日志、复现环境、把自己写的代码跑起来看哪里挂掉的能力。没这些，loop 是在闭眼迭代

1.3 谁赢谁输——loop 偏爱那些花得起的人

经济账不是普适的。觉得 loop 工程"显而易见"的人，通常用的是不限量的 token

觉得它"不负责任"的人，通常是 20 刀消费级套餐想跑重验证 loop 的人——撞限额或者被账单吓到

实践中的赢家：

• 任务可重复 + 机器可验证 + 预算充足的团队：持续测试分诊、依赖升级、lint-and-fix、在测试覆盖率好的代码库上的 issue-to-PR 起草
• 已有强测试套件的代码库：如果一个初级工程师能照着 checklist 把活干完、测试套件能兜住他的错，那 loop 就合适
• 已经在用 multi-agent 模式的 async-first 团队：对他们来说，routines 是缺失的那层编排

应该跳过 loop 的：

• 消费级套餐的单干 builder：token 账单比生产力提升先到
• 代码里没有自动验证的项目：没有真正校验的 loop，就是 Agent 反复跟自己点头
• 真正瓶颈在 review 容量而不是打字速度的团队：loop 只会让代码产量更多，原本就堵在 review 上，队列只会更长

一次性任务、探索性工作、"做完"靠人判断的活——一次精准的 prompt 仍然赢。这篇文章诚实的版本是：loop 工程是真的，但大多数开发者还用不到

1.4 30 秒 loop 自检

第 2 步那个 4 条件测试是战略决策，这一步是战术决策——具体某个任务该不该 loop 化之前过一遍的 checklist

漏掉任何一项，就把它留作手动 prompt

• 1. 任务至少每周发生一次——低于这个频率，搭建成本永远摊不平
• 2. 测试、类型检查、build 或 linter 能否决坏输出——没有自动门，Agent 自己给自己作业打分
• 3. Agent 能跑它改动的代码——没有复现环境，迭代是盲的
• 4. Loop 有硬停——token 预算、迭代次数、时间上限。没有这些，loop 会一直跑到有人发现账单
• 5. 合并、部署、改依赖前都有人 review——任何不可逆的事都要过人

好的第一个 loop：

• CI 失败分诊——每晚扫失败、分类原因、为容易的那些起草修复 PR
• 依赖升级 PR——每周扫更新、测兼容性、开 PR
• Lint-and-fix pass——每次 PR 打开时自动套用风格修复
• 复现 flaky test——一直 loop 直到某个假设能扛过测试
• 在强测试覆盖代码上的 issue-to-PR 起草——坏输出会被测试套件拒掉

不适合做第一个 loop——这些活需要人坐在椅子上：

• 架构重写
• 认证 / 支付代码
• 生产部署
• 模糊的产品工作
• 任何"做完"靠判断的事

02 五块积木

2.1 Automations：心跳

Automations 才是让一个 loop 变成真正 loop 的东西，而不是"只是跑过一次"。它按 schedule、按事件、按触发条件触发，是心跳——loop 里别的东西都挂在这上面

在两个主流工具里的样子：

• Codex：Automations tab——挑项目、设 prompt、设 cadence、选本地 checkout 或后台 worktree。发现东西的 run 会落到 Triage 收件箱；什么都没发现的自动归档
• Claude Code：三种原语组合成同一形态——/loop用于会话内的周期触发、Desktop scheduled tasks 用于跨重启存活、Routines 用于关机后云端运行。配合 hooks 处理生命周期事件

automation 内部有两个原语，决定了 loop 是好用还是烧钱：

• /loop按 cadence 重跑——不管状态如何，定期检查
• /goal跑到你写的条件真的成立为止——单独一个小模型来检查是否完成，写代码的 Agent 不当评委

在这里插入图片描述

这是 maker-vs-checker 分工被应用到"停止条件"本身

>/loop 30m/goal All testsintest/authpassandlintisclean.Scan src/authfornew failures,propose fixesinclaude/auth-fixes,opendraft PR when goal condition holds.▲ Claude CronCreate(*/30****:auth quality loop)Stop condition:testspass+lint clean(verified by checker)✓ Scheduled.Willcontinuepast intermediate completions until/goal conditionismet by independent checker.

2.2 Worktrees：并行而不混乱

一旦你跑一个以上的 Agent，文件就会开始打架。两个 Agent 写同一个文件，跟两个工程师不打招呼就往同一行 commit 一样头疼

git worktree 解决这事——同一个 repo 历史下的一个独立工作目录，在自己的分支上，一个 Agent 的改动物理上碰不到另一个的 checkout

两个工具里的呈现：

• Codex内建 worktree 支持——多个线程同时打到同一个 repo，互不撞车
• Claude Code直接暴露 git worktree、有--worktreeflag 让会话在自己的 checkout 里打开、subagent 上有isolation: worktree设置让每个 helper 拿到一个会自清理的全新 checkout

worktrees 消除了机械上的碰撞，但你仍是天花板。你 review 的带宽决定了能真正跑多少并行 Agent，不是工具决定

2.3 Skills：项目知识写一次，每次 run 读

Skill 是让你不必每次会话像金鱼一样从头解释项目上下文的方式。两个工具用同一种格式：一个文件夹，里面装一个SKILL.md，包含指令和元数据，外加可选的脚本、参考资料、资产文件

为什么对 loop 尤其重要：没有 skill 的 loop，每个周期都从零重推一遍项目上下文；有了 skill，意图能累积

约定、构建步骤、“我们因为某次事故再也不那样干了”——在外面写一次，每次 run 都读

name:ci-triage description:Classify CI failures by root cause(env,flake,real bug,dependency,infra),draft fixesforthe easy ones,escalate the rest.Trigger whenever a workflow run failsoron the morning triage loop.---# CI triage skill## Classification rules-env:missing secret,wrong env var,infranotprovisioned.# 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 appliedinCI env-E2E tests → check selectors against the latest UI snapshot## Never do-Disable failing tests — alwaysfileasescalation instead-Modify CI config without human approval-Touch src/payments/orsrc/billing/(inclaude/permissions.md)## StateUpdate STATE.md after each run:filepaths checked,classifications,PRs opened,items escalated.

2.4 Connectors：让 loop 触达你真实的工具，走 MCP

只能看文件系统的 loop 是个小 loop。Connectors 基于 Model Context Protocol（MCP），让 Agent 读你的 issue tracker、查数据库、打 staging API、往 Slack 丢消息

Codex 和 Claude Code 都说 MCP，所以你给一个写的 connector，往往另一个也能直接用

这就是"Agent 告诉你修复在这里"和"loop 直接开 PR、链上 Linear ticket、CI 一绿就在频道里 ping 一下"的区别

Connectors 是 loop 能在你真实环境里动手的原因，不是只能告诉你它"如果可以"会怎么动

回报最快的 loop connector，按顺序：

• GitHub——读 repo、建分支、开 PR、评论 issue、响应 webhook 事件。任何代码 loop 第一天最大的赢点
• Linear 或 Jira——loop 进展时更新 ticket、把 PR 链回 issue、验证通过时自动关闭
• Slack——发分诊结果、升级时 ping 人、早上汇总隔夜 run
• Sentry 或你的错误追踪——让 loop 调查实时告警，给高频问题起草修复

2.5 Sub-agents：让 maker 远离 checker

loop 里结构上最有用的事，毫无悬念，是把写代码的 Agent 跟检查的 Agent 分开。Osmani 的措辞很精准：写代码的模型"给自己作业打分时心太软"。第二个 Agent，不同的指令，有时是不同的模型，能抓到第一个把自己说服的东西

这就是 Anthropic 2024 年 12 月那篇工程帖里 evaluator-optimizer 模式换了个名字。一个模型生成，另一个挑刺，循环。2026 年爆火的这套词汇，18 个月前就有文档了

两个工具里的落地：

• Codex只在你要时 spawn subagent，同时跑，再把结果折回一个回答。你自己以 TOML 文件形式在.codex/agents/里定义——名字、描述、指令、可选的模型和推理强度。你的 security reviewer 可以是强模型 + 高强度，explorer 可以是某个快的只读小模型
• Claude Code也一样，subagent 放.claude/agents/，agent team 之间互相传活。常见拆法：一个 Agent 探索，一个实现，一个对着规范验证

为什么这件事对 loop 尤其重要：loop 在你不看的时候跑，所以你能放心走开的唯一原因是有个你真的信得过的 verifier。Sub-agent 烧更多 token，因为每个都跑自己的模型和工具——把这钱花在"第二意见值得付费"的地方

03 把它搭对，或者干脆不要搭

3.1 状态文件——Agent 会忘，文件不会

这块听起来蠢得不像回事，实际上是每个好用 loop 的脊梁。一个 markdown 文件、一个 Linear 看板、一个 JSON 状态——任何活在单次对话之外、记录"什么做完了什么是下一步"的东西

为什么重要：Agent 默认是短记忆。它这次会话学到的东西，明天就没了，除非你写下来

Osmani 的规矩：Agent 会忘，repo 不会。没有持久状态的 loop 每次从头跑；有状态的 loop 是续跑

# Loop state · ci-triage ## Last run2026-06-0903:30UTC·7failures classified,3fixes drafted,4escalated ## In progress-claude/fix-auth-token-refresh — tests passing locally,awaitingCI-claude/fix-flaky-payment-webhook — retry pattern applied,monitoring ## Completed today-claude/bump-axios-1.7.4→merged(CIgreen,deps loop verified)-claude/lint-fix-pass-june-9→ merged ## Escalated to humans-src/billing/refund.ts — tests failingin3ways,root cause unclear-ci/staging-runner — infra timeouts,not a code issue ## Lessonslearned(write here,notinchat)-2026-06-08:PowerShell hitsTLS1.2issue onthisWindows runner.Use bash.-2026-06-07:tests/e2e/checkout requires Stripe webhook secretinenv.Skipifmissing.## Stop conditions met since last review-/goal"all tests pass + lint clean"achieved on commit 3a7b8c1 at02:14UTC

状态文件放哪里，两种模式：

• Repo 里的 markdown——STATE.md在根目录或.claude/下。版本控制、简单、diff 友好。适合 solo 或小团队
• 外部系统（Linear、GitHub Issues、数据库）——跨 repo 存活、可查询、整团队可见。适合多人协作的生产 loop

对于跑久了容易跑偏的 loop，把状态文件和一份高层稳定规范（VISION.md或AGENTS.md）配对，每次 run 都让 Agent 重读一遍。状态告诉 Agent 现在在哪，规范告诉它要去哪

3.2 最小可用 loop

如果你过了第 2 步那个 4 条件测试，先搭最小那个能跑的 loop，再说花活。四块，不上 swarm

四块，大白话版：

• 一个 automation：按 cadence 触发、按明确条件停止的一次定时 run。Claude Code 用/loop，Codex 用 automation。需要它跑到某条件成立时配/goal
• 一个 skill：一个SKILL.md，装那些不写下来 Agent 每次都会重推一遍的项目上下文
• 一个状态文件：markdown 或 Linear 看板，记录什么做完了什么待办，明天的 run 是续跑而不是重启
• 一道门：自动判决坏工作的测试、类型检查或 build——这是决定 loop 是帮你还是烧钱的那一块

顺序重要：先让一次手动 run 稳定跑通，把它变成 skill，再用 loop 包起来，最后调度。跳步是 loop 在生产里翻车的方式

真正重要的指标是每个被接受变更的成本——不是花的 token、不是尝试的任务数、不是调度的 loop 数。如果你的"被接受率"低于 50%，你做的是 loop 本来要替你省下的 review 工作，loop 在亏钱

3.3 Ralph Wiggum loop——悄悄翻车的 loop

工程师 Geoffrey Huntley 记录并命名了这种翻车模式：一个本该只在完成时发出完成 token 的 Agent，提前发了，loop 在半拉子状态退出。没有硬门的 loop 会悄悄翻车，且持续烧钱

Ralph Wiggum loop 出现在：

• 没有真正的 verifier：只是请另一个 Agent"review 一下"，没有客观信号。两个乐观主义者互相鼓掌
• 软完成条件："做完"由 Agent 自己判断，不是测试、build 或类型检查
• 没有硬停：loop 跑到外部某个东西杀掉它为止——限速、你看到了——而不是跑到验证成功为止

修法就是第 11 步的那道门——某个客观能判负的东西。一个会过或不过的测试。一个能编译或编译不过的 build。一个会返回 0 或非 0 的 linter。不是个"有意见"的 verifier

其他有量化记录的翻车模式：

• 长会话里的目标漂移：每次摘要都是有损的，"不要做 X"的约束在第 47 轮就消失了。缓解：一份每次 run 都重读的VISION.md或AGENTS.md
• 自我偏好偏差：写代码的 Agent 给自己打分太软。缓解：一个对 maker 推理过程完全没接触的独立 verifier subagent
• Agent 偷懒：loop 在不完全完成时宣布"够好了"。缓解：用/goal加一个被新模型检查的客观停止条件

3.4 理解债与认知投降

这是 loop 越好、问题越尖锐的翻车模式。两个有名字的风险，都来自 Osmani 的长文：

• 理解债（Comprehension debt）：loop 越快交付你没写的代码，仓库里的内容和你脑子里理解的内容之间的距离就越大。真正咬人的不是 token 账单，是有一天你要 debug 一个团队里没人读过的系统
• 认知投降（Cognitive surrender）：停止形成自己的判断、接受 loop 返回的一切的那种引力。"设计 loop"在你带着判断力做时是解药，在你为了不思考做时是助推剂。同一个动作，相反的结果

缓解方法不是技术：

• 读 diff：你不读 loop 交付的东西，就是在用复利租理解债
• 抽查那道门：挑几个 loop 开的 PR，验证那个让它过去的测试确实能抓住你在意的失败模式。门会腐烂
• 不让 loop 碰架构活：把它锁在"小的、机器可校验的改动"上。一旦放它碰判断题，理解债加速增长
• 结对设计 loop：一个队友一起设计 loop，能发现盲点；不然 loop 会永远利用这些盲点

3.5 安全税——无人值守的 loop 也是无人值守的攻击面

无人值守跑的 loop 也是无人值守跑的攻击面

你的 loop 要防的威胁模型：

• 生成代码未经 review 就上线：loop 开 PR 比人能读的快。没有包含安全检查（SAST、依赖审计、密钥扫描）的门，不安全的代码会自动合入
• Skills 作为注入向量：自动安装 skill 的 loop 会继承它们描述里所有的 prompt 注入。安装前审计 skill 来源
• 凭据出现在日志里：长跑 loop 的 debug 日志会把密钥撒到你不监控的日志里。生产 loop 关闭 verbose logging，做日志脱敏
• 权限范围蔓延：用只读权限测过的 loop，为了方便加了"就一个"写权限，然后再也没复审。每 30 天复审一次权限

04 那些把 loop 变成无底洞的错误

• 没跑 4 条件测试就搭 loop——第 2 步存在是有原因的，大多数开发者至少漏掉一条
• 没有客观的门——请第二个 Agent"review"而不是测试、类型检查或 build，只是又一个乐观主义者
• 一个 Agent 既写又验——自我偏好偏差，自己给自己作业打分，永远是 A+
• 没有状态文件——明天的 run 从零重启而不是续跑
• 模糊的停止条件——"看起来不错就算做完"永远站不住，用测试、类型 pass 或 passing build
• 没有 token 预算上限——loop 反复读上下文、重试。没有上限，野心大的 loop 会烧掉你预期的 5-10 倍
• 消费级套餐上跑重验证 loop——token 账单或限速，总有一个先咬到你
• 自动安装社区 skill——审计的 17022 个 skill 里有 520 个泄漏凭据。安装前读源
• 判断题上的 loop——架构、auth、payments、模糊的产品决策。把 loop 锁在 lint-and-fix 上，不要锁在战略上
• 不读 diff——理解债复利。有一天你要 debug 一个没人读过的系统，那个代价比所有 token 加起来都高

05 结论：杠杆移动了，你的工作也变了

过去两年，跟编码 Agent 干活的杠杆在 prompt 上——更好的 prompt、更好的上下文、更好的一次性输出

那个阶段在结束。Agent 已经好到下一个杠杆点上移了一层：决定它们做什么、什么时候做、过哪道门、什么状态在两次 run 之间存活的那个系统

但这个故事诚实的版本不是"所有人都该赶紧搭 loop"。大多数开发者还用不到——除非任务会重复、验证可自动化、预算扛得住浪费、Agent 有资深工程师的工具

漏掉一条，loop 就比它带来的回报更贵

如果你过了测试，搭小的。一个 automation、一个 skill、一个状态文件、一道门。先让手动 run 稳定，再变成 skill，再用 loop 包，最后调度。顺序重要。跳步，你就是在为一个没人理解的系统付钱

Cherny 的点不是工作变容易了，是杠杆点移动了。搭 loop，做工程师

参考链接

Loop engineering: the 14-step roadmap from prompter to loop designer.

claude code goals

Loop Engineering