循环工程：从提示者到循环设计者的 14 步路线图

大多数开发者仍然手动向编码代理输入提示。他们打字、等待、阅读 diff、再次打字。90% 的构建者从未编写过一个能自动为代理生成提示的循环。

没有自动化，没有状态文件，没有验证器，没有调度。杠杆点已经转移——从输入提示转向设计能生成提示的系统。这是从提示者到循环设计者的 14 步路线图。

关注我的 LinkedIn 获取最新 AI 阿尔法信息：linkedin.com/in/lev-deviatkin

以下是实现这一转变的 14 步路线图——内容来自 Anthropic 的工程文档、Addy Osmani 关于循环工程的长文，以及最近的测量研究。

三个层级：判断你是否真的需要循环，学习五个构建模块，然后构建一个最小可行的、不会反噬你的循环。

14 步。3 个层级。停止提示。开始设计。

第一部分 · 为什么与测试

01. 循环工程就是用你自己替代提示者的角色。

两年来，你从编码代理那里获得成果的方式一直是：写一个提示，分享上下文，读取返回内容，再写下一个提示。代理是工具，而你全程掌握着它。这种情况正在结束。

循环工程是构建一个小型系统，它能找到任务、交给代理、检查结果、记录发生的事，并自主决定下一步行动。你只需设计这个系统一次。之后，系统会自动生成提示。

Addy Osmani 将其分解为六个部分：

Anthropic 的工程师现在每天合并的代码量是 2024 年的八倍——Anthropic 自己称这个数字“几乎肯定夸大了真实的效率提升”。

这个数字有争议。但机制是清晰的：杠杆点已经从输入提示转移到了设计能够生成提示的循环。

02. 在构建任何东西之前，先运行 4 条件测试。

循环在满足四个条件时才有价值。缺少一个，循环的成本就会超过其回报。这是 AlphaSignal 分析的诚实结论，也是大多数 X 帖子跳过的地方：

用简单的语言描述这四个条件：

• 任务可重复。 循环通过多次运行分摊其设置成本。对于一次性任务，一个好的提示更快、更便宜。如果工作不是每周重复，那就不是循环——你只是写了一个运行一次的脚本。

• 验证可自动化。 循环需要一个能在你不在场时判定工作失败的东西。测试套件、类型检查器、linter、构建。没有自动化检查，你就又回到了阅读每个 diff 的椅子上——这正是循环本应消除的工作。

• 你的 token 预算能承受浪费。 循环会重新读取上下文、重试、探索。无论运行是否产出结果，这些都会消耗 token。这项技术随着预算增加而扩展，这也是为什么拥有几乎无限 token 的人觉得它显而易见，而使用按量计费计划的人觉得它鲁莽。

• 代理拥有高级工程师的工具。 日志、可复现环境、运行自己编写的代码并查看哪里出错的能力。没有这些，循环就会在盲目中迭代。

03. 谁赢谁输。循环偏向那些能花费的人。

这种经济性并非普遍适用。称循环工程显而易见的人通常拥有无限制的 token。

而认为它鲁莽的人通常使用的是 20 美元的消费级计划，试图运行重验证循环却没有遇到限制或意外的账单。

实际受益的是谁：

• 拥有重复性、可机器检查的工作以及足够预算来运行它的团队——例如持续测试分类、依赖更新、lint 并修复、在测试覆盖率高的代码库中从问题到 PR 草稿。

• 拥有强大现有测试套件的代码库。 如果一个初级工程师能根据清单完成任务，并且测试套件能发现他们的错误，那么循环就适用。

• 已经采用多代理模式的异步优先团队。 对于这些团队，例程是缺失的编排层。

谁应该跳过（目前）：

• 使用消费级计划的独立构建者——在效率提升到来之前，token 账单已经到了。

• 任何在无自动化验证的代码上工作的人。 没有真正检查的循环就是代理在重复地自我认可。

• 真正的瓶颈是审查能力而非打字速度的团队。 循环会生成更多代码；如果审查已经是瓶颈，那它只会让队列更长。

对于一次性任务、探索性工作，或任何“完成”是判断性决策的情况，一个精心设计的提示仍然更胜一筹。这篇文章的诚实版本是：循环工程是真实的，但大多数开发者目前还不需要它。

04. 30 秒循环检查。

第 2 步的 4 条件测试是战略决策。这里是战术决策——在将特定任务转化为循环之前，你要运行一个清单。

漏掉任何一项，就保持手动提示。

• 1. 任务至少每周发生一次。 少于每周 → 设置成本永远无法分摊。

• 2. 测试、类型检查、构建或 linter 可以拒绝错误输出。 没有自动化门控 → 代理给自己的作业评分。

• 3. 代理可以运行它修改的代码。 没有可复现环境 → 迭代是盲目的。

• 4. 循环有一个硬性停止条件。 Token 预算、迭代次数或时间限制。否则，循环会一直运行直到有人注意到账单。

• 5. 合并、部署或依赖变更前由人工审查。 任何不可逆的操作都需要在行动前设置人工批准门。

好的初次循环示例：

• CI 失败分类——每晚扫描失败，分类原因，为简单问题起草修复 PR。

• 依赖更新 PR——每周扫描更新，测试兼容性，打开 PR。

• Lint 并修复——每次 PR 打开事件时，自动应用风格修复。

• 不稳定测试复现——循环直到某个理论通过测试为止。

• 问题到 PR 草案 在测试强大的代码上，错误输出会被套件拒绝。

糟糕的初次循环示例——这些需要人工在场：

• 架构重写

• 认证或支付代码

• 生产部署

• 模糊的产品工作

• 任何“完成”是判断性决策的事务

第二部分 · 5 个构建模块

05. 自动化：心跳。

自动化使循环成为真正的循环，而不仅仅是一次性的运行。它们按计划、事件或触发条件触发。它们是心跳——循环中的所有其他部分都依赖于它。

这在两个重要工具中的表现：

• Codex。 自动化选项卡——选择一个项目，设置提示，设置节奏，选择本地检出或后台工作树。找到问题的运行进入分诊收件箱；什么也没找到的运行自动存档。

• Claude Code。 三个原语，可以组合成相同的形式：

/loop 用于会话级节奏，Desktop 计划任务用于重启生存，Routines 用于无笔记本的云端运行。与 hooks 配对用于生命周期事件。

自动化内部的两个原语，区分了有效的循环和昂贵的循环：

• /loop 按节奏重新运行。当你希望定期检查（无论状态如何）时使用。

• /goal 持续运行，直到你编写的条件真正成立。一个独立的小模型检查完成情况，这样编写代码的代理就不是在为自己评分。

这是将制造者与检查者分离应用于停止条件本身。

06. 工作树：无混乱的并行。

一旦你运行多个代理，文件就开始冲突。两个代理同时写入同一个文件，就像两个工程师在未沟通的情况下提交到同一行代码一样。

git worktree 解决了这个问题——一个独立的工作目录，位于自己的分支上，共享同一个仓库历史，因此一个代理的编辑实际上不可能影响另一个代理的检出。

这两个工具中的实现方式：

• Codex 内置工作树支持——多个线程可以同时访问同一个仓库而不会互相干扰。

• Claude Code 直接暴露 git worktree，使用 –worktree 标志在单独的检出中打开会话，并对子代理使用 isolation: worktree 设置，以便每个助手获得一个全新的检出，完成后自动清理。

工作树消除了机械冲突，但你仍然是天花板。 你的审查带宽决定了你能实际运行多少个并行代理——而不是工具本身。

07. 技能：一次写入项目知识。每次运行都读取。

技能是一种让你无需在每个会话中像金鱼一样重新解释相同项目上下文的方法。两个工具都使用相同的格式：一个包含 SKILL.md 的文件夹，里面包含指令和元数据，以及可选的脚本、参考和资产。

这对于循环特别重要：没有技能的循环每次都会从零重新推导整个项目上下文。有了技能，意图就会累积。

约定、构建步骤、“我们不这样做因为那件事”——一次在外部写好，每次运行都读取。

08. 连接器：循环通过 MCP 接触你的真实工具。

只能看到文件系统的循环是一个很小的循环。连接器，基于模型上下文协议（MCP），让代理读取你的问题跟踪器、查询数据库、访问暂存 API、在 Slack 中发送消息。

Codex 和 Claude Code 都支持 MCP，因此你为一个工具编写的连接器通常也能在另一个工具中使用。

这就是“这是修复方案”的代理与打开 PR、链接 Linear 工单并在 CI 通过后通知频道的循环之间的区别。

连接器是循环能够在你实际环境中行动的原因，而不是仅仅告诉你如果它能行动会做什么。

对循环工作回报最快的连接器，按顺序：

• GitHub——读取仓库、创建分支、打开 PR、评论问题、响应 webhook 事件。对于任何代码循环来说，这是最重要的第一天收益。

• Linear 或 Jira——随着循环进展更新工单，将 PR 链接回问题，验证通过时自动关闭项目。

• Slack——发布分诊结果，在升级时通知人工，早上总结夜间运行情况。

• Sentry / 你的错误跟踪器——让循环调查实时警报并为高频问题起草修复。

09. 子代理：让制造者远离检查者。

到目前为止，循环中最有用的结构性设计是分离编写代理和检查代理。

Osmani 的表述非常准确：编写代码的模型“在给自己作业评分时过于宽容”。第二个具有不同指令（有时是不同模型）的代理能抓住第一个代理说服自己忽略的问题。

这就是 Anthropic 2024 年 12 月工程博客中提到的评估器-优化器模式，只是换了个新名字。一个模型生成，另一个批评，重复。2026 年流行起来的词汇早在十八个月前就已经被记录下来。

子代理在两个工具中的表现：

• Codex 仅在你要求时生成子代理，它们同时运行，然后将结果合并回一个答案。你可以在 .codex/agents/ 目录中将自己的代理定义为 TOML 文件——名称、描述、指令、可选的模型和推理努力。

你的安全审查员可以使用高努力度的强模型，而你的探索者可以使用快速只读的东西。

• Claude Code 使用 .claude/agents/ 中的子代理和将工作传递的代理团队实现相同功能。

常见的分工：一个代理探索，一个代理实现，一个代理根据规范验证。

这在循环中尤为重要： 循环在你没有监视的情况下运行，因此一个你真正信任的验证器是你能够离开的唯一理由。

子代理会消耗更多 token，因为每个子代理都要执行自己的模型和工具工作——在值得为第二意见付费的地方使用它们。

第三部分 · 正确构建，否则不构建

10. 状态文件。代理会忘记。文件不会。

这听起来太简单以至于无足轻重，但实际上它是每个有效循环的支柱。一个 Markdown 文件、一个 Linear 看板、一个 JSON 状态——任何存在于单个对话之外并记录已完成和下一步的内容。

为什么这很重要：默认情况下，代理的记忆很短。它们在这回合学习到的内容，如果不记录下来，明天就会消失。

Osmani 的规则：代理会忘记，仓库不会。 没有持久状态的循环每次运行都要重新开始；有状态的循环可以恢复。

状态文件存放位置的两种模式：

• 仓库中的 Markdown 文件——根目录或 .claude/ 下的 STATE.md。版本控制。简单。可 diff 读取。最适合个人或小团队工作。

• 外部系统（Linear、GitHub Issues、数据库）——跨仓库存活，可查询，支持团队级可见性。最适合生产级循环，多个人员需要查看循环在做什么。

对于可能偏离目标的长周期循环，将状态文件与一个持续的高级规范配对——VISION.md 或 AGENTS.md——代理每次运行时重新阅读。状态告诉代理它在哪里。规范告诉它要去哪里。

11. 最小可行循环。

如果你通过了第 2 步的 4 条件测试，在开始任何花哨功能之前，先构建最小的有效循环。四个部分，没有 swarm。

这四个部分，用简单的语言描述：

• 一个自动化。 一个按节奏触发并在明确条件下停止的计划运行。在 Claude Code 中使用 /loop，在 Codex 中使用自动化。当你想让它运行直到声明的条件成立时，与 /goal 配对。

• 一个技能。 一个单一的 SKILL.md，存储代理否则每次运行都会从零重新推导的项目上下文。

• 一个状态文件。 一个 Markdown 文件或一个 Linear 看板，记录已完成和下一步。明天的运行可以恢复而不是重新开始。

• 一个门控。 自动失败错误工作的测试、类型检查或构建。这是决定循环是提供帮助还是仅仅消耗资源的部分。

顺序很重要： 先确保一次手动运行可靠。然后将其转化为技能。放入循环中。最后安排计划。跳过步骤是循环在生产中失败的原因。

关键指标是每次接受的变更的成本——而不是消耗的 token、尝试的任务或计划的循环次数。如果你的接受变更率低于 50%，你正在做循环本应为你省去的审查工作，那样循环就输了。

12. Ralph Wiggum 循环。静默失败的循环。

工程师 Geoffrey Huntley 记录了这种失败模式并为其命名。一个本应在完成时发出完成 token 的代理过早地发出了它，循环在任务未完成时退出。没有硬性门控，循环会静默失败并持续消耗资源。

Ralph Wiggum 循环发生在以下情况：

• 没有真正的验证器。 只让第二个代理进行“审查”，没有客观信号。两个乐观主义者相互同意。

• 软性完成条件。 “完成”由代理的判断定义，而不是由测试、构建或类型检查定义。

• 没有硬性停止。 循环持续运行直到外部因素终止它（速率限制、你注意到），而不是直到成功得到验证。

修复方法是第 11 步的门控——一个可以客观失败工作的东西。通过或不通过的测试。编译或不编译的构建。返回零或非零的 linter。而不是一个有观点的验证器。

其他值得了解的经过测量的失败模式：

• 长时间会话中的目标漂移。 每次总结步骤都会丢失信息；“不要做 X”的约束在第 47 轮消失。缓解措施：每次运行时重新阅读一个持续的 VISION.md 或 AGENTS.md。

• 自我偏好偏差。 编写代码的代理在给自己作业评分时过于宽容。缓解措施：使用一个与制造者推理过程完全隔离的单独验证子代理。

• 代理懒惰。 循环在部分完成时宣布“足够好了”。缓解措施：使用 /goal，其客观停止条件由一个新的模型检查。

13. 理解债务和认知放弃。

这是随着循环变得更好而不是更差而变得更为突出的失败模式。两个命名的风险，均来自 Osmani 的文章：

• 理解债务。 循环越快交付你没有编写的代码，仓库包含的内容与你理解的内容之间的差距就越大。