循环工程 (Loop Engineering)【译】

原文链接： https://addyosmani.com/blog/loop-engineering/

所谓“循环工程”（Loop engineering），就是不再由你亲自去向 agent 发送 prompt，而是设计一个能够自动执行此操作的系统。

这里的“循环”可以理解为一个递归式的目标：由你设定一个终点，AI 负责反复迭代，直到达成目标。它大致由五个模块构成。现在的 Claude Code 和 Codex 都已经具备了这五大要素。

我相信这是我们未来与 coding agent 协作的方式。不过，现在还处于早期阶段。你需要关注 token 的成本（根据你手头 token 的预算，使用模式可能会有巨大差异），还需要依赖其它外部方式来保证代码质量。

但是，话虽如此，“循环工程“究竟是怎么回事，仍然值得我们一起去探究一下。

---

有用户最近提到：“你不应该再亲自给 coding agent 写 prompt 了。你应该设计能替你向 agent 发送 prompt 的循环。”

同样，Anthropic 的 Claude Code 负责人 @bcherny 也表示：“我不再直接给 Claude 写 prompt 了。我运行着一些循环，由它们去调配 Claude 并决定接下来该做什么。我的工作就是编写这些循环。”

这到底意味着什么？

在过去两年里，从 coding agent 获取产出的方法是：写好 prompt 并分享充足的上下文。

你输入内容，检查返回结果，然后再输入下一步。

Agent 是一个工具，而你从头到尾都需要密切掌控这个工具。这一阶段即将成为过去。

现在，你需要构建一个轻量系统，由它来发现任务、分派工作、检查结果、记录进度并决定下一步，让这个系统代替你跟 agent 交互。

我之前写过一个类似的例子，叫 agent harness engineering（即单个 agent 运行构建的环境）以及工厂模式（即构建软件的系统）。循环工程则位于 harness 的上一层。它本质上是一个装了定时器、能派生出小助手，并能自我演进的 harness。

让我感到惊讶的是，这不再单纯是工具层面的竞争。

一年前，如果你想要一个循环，你必须自己写一堆 bash 脚本，并为了维护它们而耗费心力，而且那完全是你个人的定制产物。

而现在，这些核心组件已经直接内置在产品中了。它们在 Codex 和 Claude Code 中的表现形式如出一辙。

一旦你意识到它们的底层形态是一致的，你就不会再纠结于使用哪款工具，而是专注于设计一个无论身处哪个工具环境都能运行的循环。

五个组成部分 + 笔记记录

一个循环需要五大要素，外加一个记录信息的空间。我先将它们列出来，然后再逐一讲解。

1. 自动化 (Automations)：按照预设日程自动运行，自主进行任务发现和分类整理。
2. 工作区 (Worktrees)：确保两个并行工作的 agent 互不干扰，避免文件冲突。
3. 技能 (Skills)：固化项目知识，避免 agent 凭空猜测。
4. 插件与连接器 (Plugins & Connectors)：将 agent 接入你现有的工具链中。
5. 子 agent (Sub-agents)：让一个 agent 负责产出思路，另一个负责审核校验。

除此之外，你还需要第 6 个部分，那就是记忆（memory）。

它可以是一个 markdown 文件，或者一个 Linear 看板，或者任何存在于单次会话之外、能记录“已完成”和“下一步”的载体。

这听起来简单得微不足道，但却是每个长期运行的 agent 所依赖的秘诀。

我在关于长期运行 agent 的文章中深入讨论过这一点：模型在不同批次的运行之间会丢失所有记忆，因此记忆必须持久化在磁盘上，而不是留在 context 中。

Agent 会遗忘，但 repo 不会。

目前，上述两款产品都已具备了这五大要素。

虽然两者的命名有些许不同，但实现的功能是相同的，让我们逐一来看。

自动化：系统的脉搏

自动化是让循环成为真正的“循环”，而不是一次性运行的关键。

在 Codex 中，你可以在 “Automations” 标签页中创建一个自动化任务，选择对应的项目、要运行的 prompt、执行频率，并决定是在你本地的 checkout 上运行，还是在后台的 worktree 中运行。

有新发现的运行结果会被发送到分流（Triage）收件箱，而一无所获的运行记录则会自动归档，这非常方便。

OpenAI 内部也在使用它们来处理一些琐碎的工作，比如每日 issue 分类、总结 CI 失败原因、撰写 commit 简报、排查上周引入的 bug 等。

而且，自动化任务可以调用 skill，这使得日常的循环任务更具可维护性。你只需触发 $skill-name，而不用将一大堆冗长的指令贴进一个以后再没人去更新的日程表里。

Claude Code 则是通过调度（scheduling）和钩子（hooks）来达到同样的目的。

你可以使用 /loop 在特定的时间间隔内运行某个 prompt 或命令，也可以调度一个 cron 任务，或者利用 hooks 在 agent 生命周期的特定节点触发 shell 命令。如果你希望在合上电脑后它依然能运行，还可以将整个流程推送到 GitHub Actions 上。

两者的理念完全一致：定义一个自主任务，为其设定一个运行频率，之后呈现产出结果。省去了你亲自检查的麻烦。

还有一个功能非常值得了解，它更接近本文的核心主题。

/loop 专注于按周期重复运行，而 /goal 则会一直执行，直到你设定的条件真正达成。

在每一轮运行后，会由另一个较小的模型来检查任务是否完成。编写代码和给代码评分的 agent 是不同的。

你可以输入类似于 “test/auth 中的所有测试都通过且 lint 无报错” 这样的指令，然后直接离开。/goal 会跨轮次持续工作，直到满足可验证的终止条件，并支持暂停、恢复和清除。

同样的指令，在两款工具中都有实现，这也是贯穿本文的一个共性。

工作区 (Worktrees)：避免并行任务陷入混乱

一旦你同时运行多个 agent，文件冲突就会随之而来。

两个 agent 往同一个文件写内容，就像两个工程师在没有事先沟通的情况下往同一行代码提交修改一样令人头疼。

而 git worktree 解决了这个问题。

它可以在独立的文件夹中为不同的分支提供独立的运行目录，但共享同一个仓库的本地历史记录。

因此，一个 agent 的修改绝对不会触碰到另一个 agent 的工作区。

Codex 内置了对 worktree 的支持，多个线程可以同时访问同一个仓库而不会发生冲突。

Claude Code 也通过 git worktree 提供了相同的隔离能力：使用 --worktree 标记可以在独立的 checkout 目录中开启会话，还可以在子 agent 上设置 isolation: worktree，这样每个辅助 agent 都会获得一个干净的、用完即被自动清理 of checkouts 目录。

我之前在另一篇文章中讨论过这件事在人机协同层面的表现：worktree 确实消除了机械层面的冲突，但「人类」仍然是瓶颈所在。你的 review “带宽“决定了你实际上能并行运行多少个任务。

技能 (Skills)：不再在每次交互中都重复解释项目背景

使用 Skill 可以让你不用像金鱼一样，在每个会话中都反复解释相同的项目上下文。

Codex 和 Claude Code 都采用了相同的格式：一个包含 SKILL.md 的文件夹，其中存放着指令和元数据，还可以包含可选的辅助脚本、参考文档和资源文件。

在 Codex 中，当你使用 $ 或 /skills 调用时会运行相应的 skill，或者当你的任务与 skill 的描述相匹配时也会自动运行。Claude Code 也是如此。

因此，一段严谨、朴实的描述往往比花哨的文案更有效。

Skill 让你不用再为「表达意图」反复浪费时间。

我在另一篇文章中提到过，agent 每次开启新会话时都是“冷启动”的，它会用极其自信的猜测来填补你意图中的任何空白。

而 skill 就是将你的意图在外部记录下来。比如代码规范、构建步骤、或者“因为之前发生过事故，我们不能用这种方式处理”等经验。这些内容只需编写一次，agent 在每次运行时都会自动读取。

如果没有 skill，循环在每次运行周期中都需要从零开始重新推导你的整个项目；而有了 skill，经验就会不断累积。

有一点需要厘清：skill 是编写格式，而插件（plugin）是它的分发方式。

当你需要在不同的仓库之间共享某个 skill，或者想把几个 skill 打包在一起时，你可以把它们打包成一个插件。这在 Codex 和 Claude Code 中都是相通的。

插件与连接器 (Connectors)：让循环接入你真实的工具链

如果一个循环只能看到本地文件系统，那它的局限性就会非常大。

而基于 MCP 构建的连接器（connectors），可以让 agent 读取你的 issue 追踪工具、查询数据库、调用测试环境的 API、或者在 Slack 里发消息。

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

此外，插件会将连接器和 skill 打包在一起，这样你的队友只需一步就能安装好你的整套配置，而不需要凭记忆去重新构建。

正是因为有了连接器，循环才能在你的实际开发环境中执行具体操作，而不仅仅是给出建议。

子 agent (Sub-agents)：让执行者与检查者分离

在循环的设计中，目前最有效的架构设计就是将负责编写代码的 agent与负责检查的 agent分离开来。

写代码的模型在批改自己的作业时往往会过于宽容。而拥有不同指令（有时甚至是不同模型）的第二个 agent，能够发现前一个 agent 因自我合理化而漏掉的问题。

Codex 仅在你提出要求时才会生成子 agent，让它们同时运行，并将结果合并为最终答案。

你可以在 .codex/agents/ 下用 TOML 文件定义你自己的 agent：指定名称、描述、指令，以及可选的模型与推理模式。建议 reviewer 可以使用高推理强度的模型，而 explorer 可以使用低成本的快速只读模型。

Claude Code 在 .claude/agents/ 下提供了类似的支持，并通过 agent 团队在彼此之间传递工作。两者的常见划分方式是：一个负责探索、一个负责实现，还有一个负责对照规格说明书进行校验。

之所以在循环中这一点尤为重要，是因为循环是在你不在场时自动运行的，只有拥有一个你真正信任的校验器，你才能放心走开。

由于每个子 agent 都会消耗各自的模型和工具配额，因此子 agent 会带来更高的 token 消耗，所以请把预算花在确实需要独立客观审查的关键环节。

这也正是 Claude Code 的 /goal 底层的运行逻辑：由一个全新的模型来判定循环是否应当结束，而不是由写代码的模型自己决定。

一个典型的循环示例

将这些元素整合在一起，一个会话流就会变成一个轻量控制台。

以下是我一直在使用的一种运作模式：

每天早晨，仓库都会自主运行一个自动化任务。

它的 prompt 会调用一个分类（triage）技能，去读取昨天的 CI 失败记录、打开的 issue 以及最近的 commit，并将发现的问题写入一个 markdown 文件或 Linear 看板。针对其中有必要处理的每个问题，该线程会开启一个独立的 worktree，并指派一个子 agent 去起草修复方案，接着由第二个子 agent 对照项目技能和现有测试来评审该草稿。

连接器（connectors）让这个循环能够自动提交 PR 并更新任务状态。任何循环无法处理的问题都会被发送到我的分类收件箱中，由我亲自处理。而状态文件会记录了已经尝试过的方案、跑通的测试以及仍然挂起的问题，这样明天的运行就能直接承接今天的进度，而不是重头再来。

回头看看你在这个过程中做了什么：你只设计了一次系统，此后便无需手动输入任何 prompt。

无论是使用 Codex 还是 Claude Code，其底层的设计思路都是相通的，因为核心组件是一致的。

循环无法解决的问题

循环改变了你的工作方式，但并没有把你从开发流程中抹去。

实际上，随着循环变得越来越高效，以下三个问题反而会变得更加棘手：

1. 校验依然是你的职责。一个在无人值守下运行的循环，同样会悄无声息地犯错。我们之所以要将校验子 agent 从编写者中分离出来，就是为了让循环做出的“已完成”声明具备一定的可信度；即便如此，这个“已完成”也只是一个声明，而不是最终证明。我一直在强调 AI 时代代码评审中的那句话：你的工作是交付你亲自确认过，能正常运行的代码。
2. 如果你听之任之，你对代码的理解就会退化。循环提交你未曾写过的代码的速度越快，实际存在的代码与你大脑理解的代码之间的鸿沟就会越大。这就是理解负债。一个顺畅运行的循环只会加速债务的累积，除非你认真去阅读它所生成的代码。
3. 越是舒服的过程，往往越危险。当循环自动运转时，你很容易放弃独立思考，对它返回的任何结果都全盘接受。我称之为“认知放弃”。如果你在设计循环时保持审慎的判断，它就是解决问题的良药；但如果你是为了逃避思考，它就会变成认知退化的加速器。同样的行为，会导致截然相反的结局。

构建你的循环，但保持你工程师的角色

我认为这是我们未来工作方式演进的预告。

如果我不亲自去评审代码，或者完全依赖自动化循环来修复问题，我的产品质量势必会下滑。我可能会陷入恶性循环，一步步让自己陷入更深的泥潭。

即便如此，你依然可以着手构建你的循环，但也别忘了，直接与 agent 交互依然是行之有效的。这其中的关键在于找到合适的平衡点。

相同的循环对于不同的人会产生截然不同的结果。

有的人用它来加速自己深谙的开发工作；有的人则用它来彻底逃避去理解代码。

循环本身并不知道这两者的差别，但你心里很清楚。

这正是为什么设计循环比编写 prompt 更难，核心观点并不是说工作变得简单了，而是提效的杠杆已经发生了转移。

以工程师的姿态开启你的 Loop Engineering，而不是做一个只会按下启动按钮的旁观者。