Loop Engineering 14 步路线图：从手写 Prompt 到设计循环

原文链接：https://x.com/0xCodez/article/2064374643729773029

大多数开发者还在手动给 coding agent 写 prompt：输入、等待、读 diff、再输入。Codez 这篇文章的核心判断是：AI 编程的杠杆点正在从“写更好的 prompt”上移到“设计会自动提示 agent 的系统”。

这个系统就是 loop。

一个好的 loop 不只是反复调用模型，而是包含工作发现、任务分解、执行、验证、状态记录和停止条件。你不再亲自站在每一步中间推动 agent，而是设计一个小系统，让它知道何时开始、如何检查、何时停止、出错后怎么迭代。

这篇文章把路线图拆成三层：

• 先判断你是否真的需要 loop
• 再理解 loop 的 5 个构建块
• 最后搭一个不会伤到自己的最小可行 loop

第一部分：为什么要先做判断

01. Loop Engineering 是把自己从“提示者”位置替换掉

过去两年，使用 coding agent 的方式很像手动驾驶：你写 prompt、补上下文、看返回结果、指出问题、继续提示。agent 是工具，但方向盘始终在你手上。

Loop engineering 要做的是把这个过程系统化：

• 找到要做的工作
• 把任务交给 agent
• 检查输出
• 记录发生了什么
• 根据结果决定下一步

你只设计一次系统，后面由系统持续提示 agent。

Addy Osmani 把 loop 拆成多个部件。具体说法可以不同，但核心机制一致：杠杆点已经从“我怎么提示 agent”变成“我怎么设计一个会提示 agent 的系统”。

02. 建 loop 前先跑 4 个条件测试

Loop 有成本。它会重复读上下文、尝试方案、运行验证、失败后重试。少了任何一个前提，loop 都可能比手动 prompt 更贵。

建 loop 前先问四个问题：

1. 这个任务会重复吗？ 如果只是一次性的探索，一个好 prompt 通常更快。只有至少每周重复发生的任务，才有机会摊平 loop 的搭建成本。

2. 验证能自动化吗？ Loop 需要一个能在你不在场时拒绝坏结果的机制：测试、类型检查、lint、build。没有自动验证，你还是得回来读每个 diff。

3. Token 预算扛得住浪费吗？ Loop 会探索、回滚、重试。它消耗 token 的速度远高于单次问答。预算不够时，loop 会先变成账单问题。

4. Agent 有没有资深工程师该有的工具？ 它需要日志、复现环境、运行代码的能力，以及看见失败结果的能力。否则它只是盲目迭代。

03. 谁适合，谁暂时不适合

真正受益的通常是三类团队：

• 有大量重复、机器可验证工作的团队，比如 CI 失败分类、依赖升级、lint 修复、issue 到 PR 草稿
• 已经有强测试套件的代码库，坏输出能被测试挡住
• 已经在使用多 agent 或异步工作流的团队，缺的只是编排层

不适合的也很明确：

• 个人开发者在普通消费级套餐上跑重验证 loop
• 没有自动测试或自动检查的代码库
• 真实瓶颈是 review 能力，而不是写代码速度的团队

这也是文章里最清醒的一点：loop engineering 是真的，但大多数开发者今天还不需要它。

04. 30 秒任务检查表

战略上通过 4 个条件后，具体任务还要再过一遍短检查。

一个任务适合变成 loop，至少要满足：

• 每周至少发生一次
• 有测试、类型检查、build 或 linter 能拒绝坏输出
• Agent 能运行它修改的代码
• 有硬停止条件，比如 token 预算、迭代次数或时间限制
• 合并、部署、依赖变更前有人类审批

适合从这些地方开始：

• CI 失败夜间分类和简单修复草稿
• 依赖升级 PR
• PR 打开时自动 lint-and-fix
• 复现 flaky test，直到某个假设能被测试验证
• 强测试代码库里的 issue-to-PR 草稿

不要一开始就把 loop 放到架构重写、auth、支付、生产部署或模糊产品判断里。那些工作需要人坐在驾驶位上。

第二部分：5 个构建块

05. Automations：loop 的心跳

Automation 让 loop 不只是“我手动跑了一次”，而是能按计划、事件或触发条件启动。

在 Codex 里，这对应 Automations：选择项目、写 prompt、设置 cadence、选择本地 checkout 或后台 worktree。发现问题的运行进入 Triage inbox，没有发现问题的运行自动归档。

在 Claude Code 里，文章提到的是三类原语：

• /loop：会按 cadence 重跑
• Desktop scheduled tasks：重启后仍能继续
• Routines：即使笔记本离线也能在云端跑

另外还有一个关键区分：/loop 是定时重跑，/goal 是持续运行直到某个条件被满足。后者更像“让一个独立 checker 判断完成条件是否成立”，避免写代码的 agent 自己给自己打分。

示例形态可以是：

/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.

06. Worktrees：并行但不互相踩文件

当多个 agent 同时修改同一个仓库，文件冲突会很快出现。Git worktree 的价值在这里很直接：每个 agent 在独立工作目录和分支里运行，共享同一份历史，但不会互相覆盖 checkout。

Codex 内建 worktree 支持，多个线程可以同时操作同一个 repo。Claude Code 也可以通过 git worktree、--worktree 或 subagent 的 isolation 设置来实现隔离。

不过 worktree 只解决机械冲突。真正的上限仍然是你的 review 带宽。你能并行开多少 agent，不取决于工具有多能跑，而取决于你能认真读多少 diff。

07. Skills：项目知识写一次，每次运行都读取

Skill 的意义是让 loop 不必每次从零重新理解项目。它通常是一个带 SKILL.md 的文件夹，里面保存项目约定、操作流程、边界、脚本、参考材料和禁区。

Loop 没有 skill，就会在每次运行里重新推导上下文。Loop 有 skill，意图和经验才会复利。

一个 CI triage skill 可以写清楚：

• 如何区分 env、flake、真实 bug、dependency、infra
• 哪些失败可以自动修，哪些必须升级给人
• 哪些目录禁止触碰
• 每次运行后要更新什么状态文件

这类知识如果只停留在聊天记录里，下一次运行就丢了。写进 repo 或 skill，agent 才能每次重新读到。

08. Connectors：让 loop 接触真实工具

只看文件系统的 loop 很小。通过 MCP connector，loop 可以读 issue tracker、查数据库、访问 staging API、给 Slack 发总结、更新 Linear 或 Jira。

文章给出的优先级很实际：

• GitHub：读仓库、建分支、开 PR、评论 issue、响应 webhook
• Linear 或 Jira：同步任务状态、关联 PR、验证后自动关闭事项
• Slack：发 triage 结果、升级提醒、早晨总结夜间运行
• Sentry 或错误追踪系统：调查线上高频错误并草拟修复

这一步让 agent 不再只是“告诉你它会怎么修”，而是进入真实工作流里推进任务。

09. Sub-agents：把 maker 和 checker 分开

Loop 里最有价值的结构之一，是把“写的人”和“检查的人”拆开。写代码的模型很容易相信自己的输出，第二个带不同指令的 agent 更容易发现它自我说服的地方。

这其实就是 evaluator-optimizer 模式：一个模型生成，另一个模型批评，反复迭代。Anthropic 早在 2024 年底就系统写过这个模式，只是 2026 年它被放进了 loop engineering 的语境里。

在 Codex 中，你可以显式要求 subagent 并行探索，再把结果合并回来；也可以用 .codex/agents/ 定义不同 agent 的名称、描述、指令、模型和 reasoning effort。

在 Claude Code 中，对应的是 .claude/agents/ 和 agent teams。

常见拆分是：

• explorer 负责读代码和找方向
• implementer 负责改动
• verifier 负责按 spec 和测试检查

Sub-agent 会烧更多 token，所以应该用在第二意见真的值钱的地方。

第三部分：小心地把它建出来

10. State file：agent 会忘，文件不会

State file 是 loop 的脊柱。它可以是 repo 里的 Markdown、Linear board，或者一份 JSON。关键是它活在单次对话之外，记录已经完成什么、还剩什么、遇到过什么坑。

没有状态文件，明天的运行会从零开始。状态文件存在，明天的运行才能接着昨天继续。

一个状态文件至少应该记录：

• 上次运行时间和结果
• 正在处理的分支或任务
• 今天完成的事项
• 已升级给人的问题
• 学到的项目经验
• 哪些 stop condition 已经被满足

对于长期 loop，再配一个高层 spec，比如 VISION.md 或 AGENTS.md。State 告诉 agent 现在在哪里，spec 告诉它要往哪里去。

11. 最小可行 loop

如果你真的通过了前面的条件测试，不要一上来搭 swarm。先建最小可行版本。

最小 loop 只有四件东西：

• 一个 automation：按 cadence 启动，并有明确停止条件
• 一个 skill：保存每次运行都需要读取的项目知识
• 一个 state file：记录完成事项和下一步
• 一个 gate：测试、类型检查或 build，负责自动拒绝坏工作

顺序很重要：

1. 先把一次手动运行做可靠
2. 再把经验沉淀成 skill
3. 然后包进 loop
4. 最后才 schedule

衡量指标不是花了多少 token，也不是跑了多少任务，而是“每个被接受变更的成本”。如果接受率低于 50%，你很可能只是把节省下来的工作转移成了 review 工作。

12. 静默失败的 loop

文章引用了 Geoffrey Huntley 描述的一类失败：agent 过早发出“完成”信号，loop 因此退出，但任务其实没做完。没有硬 gate 时，这种失败很安静，也很贵。

典型原因包括：

• 没有真正 verifier，只是第二个 agent 被要求“review”
• 完成条件太软，比如“看起来可以了”
• 没有硬停止条件，直到额度耗尽或人发现才停

修复方式不是再找一个 agent 聊聊，而是放一个客观 gate：测试通过或失败、build 编译或不编译、linter 返回 0 或非 0。

13. Comprehension debt：越快越危险

Loop 越有效，另一个风险越尖锐：代码增长速度超过团队理解速度。

文章把这叫 comprehension debt。你没有亲手写的代码越多，repo 里“存在但没人真正理解”的部分就越多。真正昂贵的账单不是 token，而是未来某天你要 debug 一套没人读过的系统。

对应的防线很朴素：

• 读 diff
• 抽查 gate 是否真的捕捉到了你关心的失败
• 禁止 loop 做架构判断
• 设计 loop 时找队友一起看

Loop 不是让人停止判断，而是把判断前移到系统设计阶段。

14. 安全税：无人值守 loop 也是无人值守攻击面

长期运行的 loop 也是长期运行的攻击面。

需要提前考虑的威胁包括：

• 生成代码未经 review 合并
• 社区 skill 作为 prompt injection 或供应链入口
• debug 日志里散落 credentials
• 权限为了方便一点点扩大，最后没人重新审计

所以生产级 loop 至少要有：

• 安全检查 gate，比如 SAST、依赖审计、secret scanning
• skill 来源审计
• 日志脱敏
• 定期权限复查
• 人类审批节点

最容易把 loop 变成钱坑的错误

这篇文章最后的清单很值得贴在桌面上：

• 没跑 4 条件测试就开建
• 没有客观 gate
• 同一个 agent 既写又验
• 没有 state file
• 停止条件模糊
• 没有 token 预算上限
• 在消费级计划上跑重验证 loop
• 自动安装社区 skill
• 让 loop 处理架构、auth、支付、模糊产品判断
• 不读 diff

结论：杠杆点移动了，但工程师没有下班

过去两年，和 coding agent 协作的关键是 prompt：更清楚的指令、更好的上下文、更强的一次性输出。

这个阶段正在结束。Agent 已经强到一定程度，新的杠杆点变成了更上一层的系统：谁决定它何时工作、处理什么、用什么 gate 检查、哪些状态能跨运行保留下来。

但这不等于所有人都该马上建 loop。只有当任务重复、验证自动化、预算能承受浪费、agent 有足够工具时，loop 才可能产生正回报。

最稳的路径仍然很小：

先让一次手动运行可靠。再写成 skill。再包成 loop。最后 schedule。

顺序错了，你买到的不是自动化，而是一套你自己也说不清的系统。