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 AgentAddy Osmani 把这件事拆成六块Anthropic 工程师现在每天合入的代码量是 2024 年的 8 倍——这个数字 Anthropic 自己都承认几乎可以肯定夸大了真实生产力提升数字本身可以争议但机制不能杠杆点从敲 prompt挪到了设计 prompt 的 loop1.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 的消费级套餐的单干 buildertoken 账单比生产力提升先到代码里没有自动验证的项目没有真正校验的 loop就是 Agent 反复跟自己点头真正瓶颈在 review 容量而不是打字速度的团队loop 只会让代码产量更多原本就堵在 review 上队列只会更长一次性任务、探索性工作、做完靠人判断的活——一次精准的 prompt 仍然赢。这篇文章诚实的版本是loop 工程是真的但大多数开发者还用不到1.4 30 秒 loop 自检第 2 步那个 4 条件测试是战略决策这一步是战术决策——具体某个任务该不该 loop 化之前过一遍的 checklist漏掉任何一项就把它留作手动 prompt任务至少每周发生一次——低于这个频率搭建成本永远摊不平测试、类型检查、build 或 linter 能否决坏输出——没有自动门Agent 自己给自己作业打分Agent 能跑它改动的代码——没有复现环境迭代是盲的Loop 有硬停——token 预算、迭代次数、时间上限。没有这些loop 会一直跑到有人发现账单合并、部署、改依赖前都有人 review——任何不可逆的事都要过人好的第一个 loopCI 失败分诊——每晚扫失败、分类原因、为容易的那些起草修复 PR依赖升级 PR——每周扫更新、测兼容性、开 PRLint-and-fix pass——每次 PR 打开时自动套用风格修复复现 flaky test——一直 loop 直到某个假设能扛过测试在强测试覆盖代码上的 issue-to-PR 起草——坏输出会被测试套件拒掉不适合做第一个 loop——这些活需要人坐在椅子上架构重写认证 / 支付代码生产部署模糊的产品工作任何做完靠判断的事02 五块积木2.1 Automations心跳Automations 才是让一个 loop 变成真正 loop 的东西而不是只是跑过一次。它按 schedule、按事件、按触发条件触发是心跳——loop 里别的东西都挂在这上面在两个主流工具里的样子CodexAutomations 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:testspasslint 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 拿到一个会自清理的全新 checkoutworktrees 消除了机械上的碰撞但你仍是天花板。你 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 ProtocolMCP让 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 人、早上汇总隔夜 runSentry 或你的错误追踪——让 loop 调查实时告警给高频问题起草修复2.5 Sub-agents让 maker 远离 checkerloop 里结构上最有用的事毫无悬念是把写代码的 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-/goalall tests pass lint cleanachieved 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 用/loopCodex 用 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只是请另一个 Agentreview 一下没有客观信号。两个乐观主义者互相鼓掌软完成条件做完由 Agent 自己判断不是测试、build 或类型检查没有硬停loop 跑到外部某个东西杀掉它为止——限速、你看到了——而不是跑到验证成功为止修法就是第 11 步的那道门——某个客观能判负的东西。一个会过或不过的测试。一个能编译或编译不过的 build。一个会返回 0 或非 0 的 linter。不是个有意见的 verifier其他有量化记录的翻车模式长会话里的目标漂移每次摘要都是有损的不要做 X的约束在第 47 轮就消失了。缓解一份每次 run 都重读的VISION.md或AGENTS.md自我偏好偏差写代码的 Agent 给自己打分太软。缓解一个对 maker 推理过程完全没接触的独立 verifier subagentAgent 偷懒loop 在不完全完成时宣布够好了。缓解用/goal加一个被新模型检查的客观停止条件3.4 理解债与认知投降这是 loop 越好、问题越尖锐的翻车模式。两个有名字的风险都来自 Osmani 的长文理解债Comprehension debtloop 越快交付你没写的代码仓库里的内容和你脑子里理解的内容之间的距离就越大。真正咬人的不是 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 步存在是有原因的大多数开发者至少漏掉一条没有客观的门——请第二个 Agentreview而不是测试、类型检查或 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 goalsLoop Engineering