Loop Engineering（循环工程）。

循环工程就是取代你自己作为提示智能体的那个人，你设计一个系统来代替你完成提示。 **这里的循环可以看作是一个递归目标，你定义了一个目的，然后AI不断迭代直到完成。**它大致由五个构建块组成，而Claude Code和Codex现在都具备了这五个。

我相信这可能是未来我们与编码智能体协作的方式。不过，现在还为时过早，我持怀疑态度，而且你绝对要小心 token 成本（使用模式在 token 丰富或匮乏时可能会有天壤之别）。你仍然需要某种方法来确保质量不下降，对“垃圾输出”的担忧也是合理的。话虽如此，让我们来探索一下这究竟是怎么回事。

@steipete 最近说：“你不应该再手动提示编码智能体了。你应该设计循环来提示你的智能体。”同样，Anthropic 的 Claude Code 负责人 @bcherny 说：“我不再手动提示 Claude 了。我有循环在运行，它们提示 Claude 并决定该做什么。我的工作是编写循环。”

好吧，这到底是什么意思？

大约两年来，从编码智能体获得结果的方式一直是：写一个好的提示，提供足够的上下文。你输入一些内容，阅读返回的结果，然后再输入下一个。智能体是一个工具，你一直握着它，一个回合接一个回合。这个阶段已经结束了，或者至少有人认为它即将结束。

现在，你构建一个小型系统，它负责查找任务、分配任务、检查任务、记录已完成的内容，然后决定下一步做什么，并且让这个系统代替你去“戳”智能体。我之前写过与此相关的概念：智能体工具链工程（agent harness engineering）——即构建单个智能体运行的环境；以及工厂模式（factory model）——即构建软件的体系。循环工程（loop engineering）位于工具链工程之上一个层级。工具链工程基于定时器运行，它会生成小助手，并能自我维持。

让我惊讶的是，这已经不再仅仅是工具层面的问题了。一年前，如果你想要一个循环，你得写一大堆 bash 脚本，并且永远维护它们，那是你独有的。而现在，这些组件直接内置在产品中。Steinberger 列出的清单几乎完全对应 Codex 应用，然后又几乎与 Claude Code 相同。一旦你发现它们的结构是一样的，你就不会再争论用哪个工具了，你只需设计一个无论你身处哪个工具都能正常运行的循环。

五个组成部分，以及附注

一个循环需要五样东西，以及一个用来记录状态的地方。我先列出它们，然后进行映射。

• 自动化任务：按计划自动执行，进行发现和分类。
• 工作树：让两个并行工作的智能体不会互相干扰。
• 技能：记录项目知识，否则智能体只能猜测。
• 插件与连接器：将智能体与你已有的工具连接起来。
• 子智能体：一个智能体提出想法，另一个智能体负责检查它。

然后是第六样东西：记忆。一个 Markdown 文件，或者一个 Linear 看板，任何存在于单个对话之外的东西，用来记录已完成和下一步要做的事。听起来太简单了，不值一提。但这是每个长期运行的智能体都依赖的相同技巧，我在《长期运行的智能体》中深入讨论过：模型在每次运行之间会忘记所有内容，所以记忆必须存储在磁盘上，而不是上下文中。智能体会忘记，但仓库不会。

现在，这两个产品都具备了全部五个组件。

名字上有些许不同，但能力是一样的。让我逐一说明，因为说实话，细节决定了循环是能稳固运行，还是会悄无声息地到处出问题。

自动化任务，这是心跳

自动化任务才是让循环真正成为循环的关键，而不仅仅是一次性的运行。在 Codex 应用中，你在“自动任务”标签页创建一个自动化任务，选择项目、要运行的提示、运行频率，以及它是在你的本地 checkout 上运行还是在后台工作树中运行。找到东西的运行结果会进入分类收件箱，什么都没找到的运行结果会自动存档，这很不错。OpenAI 内部使用它来处理无聊的事情，比如每日问题分类、总结 CI 失败、编写提交简报、追踪上周某人引入的 bug。并且，自动化任务可以调用一个技能，这样你就可以保持重复性任务的可维护性，使用 $skill-name 来调用，而不是把一大段指令粘贴到一个永远不会更新的计划中。

Claude Code 通过调度和钩子实现了同样的功能。你可以使用 /loop 按间隔运行一个提示或命令，可以调度一个 cron 任务，可以在智能体生命周期的特定点触发 shell 命令（通过钩子），或者将整个过程推送到 GitHub Actions，这样即使你合上笔记本电脑，它也能继续运行。完全相同的理念：你定义一个自主任务，给它一个节奏，结果会呈现给你，这样你就不需要自己去四处检查了。

还有一个值得了解的会话内原语，它更接近本文的核心——/loop 按节奏重新运行；/goal 则持续运行，直到你编写的某个条件成立。每次轮次后，一个独立的小模型会检查你是否完成，这样编写代码的智能体就不是评判者。你给出类似“test/auth 中的所有测试通过且 lint 干净”的条件，然后离开。Codex 也有同样的功能，也叫做 /goal，它会跨轮次持续工作，直到一个可验证的停止条件成立，并支持暂停、恢复和清除。相同的原语，两个工具都有，这几乎是本文的典型模式。

所以，这部分是发现任务。循环的其余部分则是对这些任务采取行动。

工作树，让并行不会变成混乱

一旦你运行多个智能体，文件就会开始冲突，这就会变成故障。两个智能体写入同一个文件，就像两个工程师在没人事先沟通的情况下提交到同一行代码一样令人头疼。Git 工作树解决了这个问题：它是一个独立的工作目录，位于自己的分支上，共享相同的仓库历史，这样，一个智能体的编辑物理上无法触及另一个智能体的 checkout。

Codex 内置了工作树支持，使得多个线程可以同时处理同一个仓库而不会相互碰撞。Claude Code 通过 git worktree 提供了相同的隔离：一个 --worktree 标志可以在它自己的 checkout 中打开一个会话；还有一个 isolation: worktree 设置，可以附加到子智能体上，这样每个助手都能获得一个全新的、用完即自动清理的 checkout。我在《编排税》中写过关于人机协作方面的问题：工作树消除了机械碰撞，但你仍然是瓶颈——你的审查带宽决定了你实际能运行多少个，而不是工具本身。

技能，这样你就不用每次都解释你的项目

技能让你不再需要像金鱼一样，每次会话都重新解释相同的项目上下文。这两个工具使用相同的格式：一个文件夹，里面有一个 SKILL.md 文件，包含指令和元数据，以及可选的脚本、参考文件和资源。当你使用 $ 或 /skills 调用技能时，或者当你的任务与技能描述匹配时，Codex 就会运行该技能（系统会自动匹配，这就是为什么一个紧凑、枯燥的描述比一个巧妙的描述更有效）。Claude Code 以相同的方式实现，我在《智能体技能》中写过这个模式。

技能也是让你的意图不再需要反复支付成本的地方。我在《意图债务》中论证过，智能体每次会话开始时都是“冷启动”，它会用自信的猜测来填补你意图中的任何空白。技能就是将那些意图写在外部：约定、构建步骤、“我们因为那次事故不这样做”——写一次，智能体每次运行都会读取。没有技能，循环每一轮都会从零开始重新推导你的整个项目；有了技能，它会累积知识。

有一点需要理清：技能是创作格式，插件是分发方式。当你想跨仓库共享一个技能，或者将几个技能捆绑在一起时，你可以将它们打包成一个插件。这在 Codex 和 Claude Code 中都是如此。

插件与连接器，循环触及你的真实工具

一个只能看到文件系统的循环是一个微小的循环。连接器（基于 MCP）让智能体能够读取你的问题追踪器、查询数据库、访问暂存 API、在 Slack 中发送消息。Codex 和 Claude Code 都支持 MCP，所以为你一个工具编写的连接器通常可以直接用在另一个工具中。插件将连接器和技能捆绑在一起，这样你的队友可以一键安装你的设置，而不必从记忆中重新构建整个环境。

这就是“智能体说‘这是修复方法’”和“循环自动打开 PR、关联 Linear 工单、并在 CI 变绿后自动 ping 频道”之间的区别。连接器是循环能够在你实际环境中行动的关键，而不是仅仅告诉你它如果能够的话会做什么。

子智能体，让制造者远离检查者

在一个循环中，最有用的结构性组件，毫无疑问，就是将编写者与检查者分离。写出代码的那个模型在批改自己作业时太宽容了。第二个智能体（带有不同的指令，有时使用不同的模型）能抓住第一个智能体自己说服自己所犯的错误。

Codex 只在你要求时才会生成子智能体，它们同时运行，然后将结果合并成一个答案。你可以在 .codex/agents/ 中以 TOML 文件的形式定义你自己的智能体，每个智能体都有名称、描述、指令，以及可选的模型和推理努力程度。这样，你的安全审查员可以是一个使用高推理努力程度的强模型，而你的探索者可以是一个快速的只读智能体。Claude Code 同样支持在 .claude/agents/ 中定义子智能体，以及在工作之间传递任务的智能体团队。在这两者中，常见的分工是：一个智能体探索，一个实现，一个对照规格进行验证。

我已经两次论证过这一点：一次是《代码智能体管弦乐团》，一次是《对抗性代码审查》。它之所以在循环中特别重要，是因为循环在你没有监视时运行，所以一个你真正信任的验证器是你能够放心离开的唯一理由。子智能体确实会消耗更多 token（因为每个智能体都有自己的模型和工具工作），所以要把它们花在值得为第二意见付费的地方。这基本上也是 Claude Code 的 /goal 在底层所做的：一个全新的模型决定循环是否完成，而不是那个执行工作的模型——这是制造者与检查者分离原则，应用到停止条件本身。

一个循环看起来是什么样的

把这些组合在一起，一个单一的线程就变成了一个小控制面板。下面是我一直在使用的一个形态。

一个自动化任务每天早上在仓库上运行。它的提示调用一个分类技能，该技能读取昨天的 CI 失败、未解决的问题、最近的提交，并将发现结果写入一个 Markdown 文件或 Linear 看板。对于每个值得处理的问题，线程会打开一个隔离的工作树，并派送一个子智能体来起草修复方案，然后第二个子智能体根据项目技能和现有测试来审查该草案。

连接器让循环可以打开 PR 并更新工单。任何循环无法处理的问题都会落入我的分类收件箱。状态文件是整个循环的脊柱，它记住了尝试了哪些、哪些通过了、哪些仍然待处理，这样第二天早上的运行就可以从今天停止的地方继续。

看看你实际做了什么。你只设计了一次。你没有手动提示任何一个步骤。这就是 Steinberger 观点的实际体现。在 Codex 或 Claude Code 中，循环是一样的，因为组件是相同的。

循环仍然不能为你做什么

循环改变了工作方式，但并没有把你从工作中删除。 而且随着循环变得更好，三个问题实际上会变得更尖锐，而不是更容易。

验证仍然是你的责任。 一个无人值守运行的循环，也是一个在无人值守时犯错的循环。你将验证子智能体与制造者分离的全部原因，就是为了让循环的“完成”具有意义。即便如此，“完成”也只是一个声明，而不是一个证明。我一直在重复《AI 时代的代码审查》中的那句话：你的工作是交付你已经确认有效的代码。

如果放任不管，你对项目的理解仍然会退化。 循环交付你没写过的代码越快，已存在的内容与你实际理解的内容之间的差距就越大。这就是理解债务，一个流畅的循环只会让它增长得更快，除非你阅读循环所产生的内容。

是的，舒适的姿势很可能是危险的姿势。当循环自行运行时，很容易失去自己的判断力，只接受它返回的任何东西。我把这称为认知投降。用判断力来设计循环是解药；用它来避免思考则是催化剂。同样的动作，相反的结果。

构建循环。保持工程师的身份。

我认为这是我们未来工作演变的预演。话虽如此，如果我自己不审查代码，或者完全依赖自动化循环来修复问题，我产品的质量就会下降。我很可能会陷入一个恶性循环，不断挖坑把自己陷得更深。

也就是说，尽管去设置你的循环，但不要忘记直接提示你的智能体仍然有效。关键在于找到正确的平衡。

循环也可能因你而异。两个人可以构建完全相同的循环，却得到完全相反的结果。一个人用它来在自己深刻理解的工作上加速前进。另一个人则用它来避免理解工作。循环不知道其中的区别。你知道。

这就是为什么循环设计比提示工程更难，而不是更容易。Cherny 的观点并不是工作变容易了。而是杠杆点移动了。

构建循环。但要像一个打算保持工程师身份的人那样去构建它，而不仅仅是那个按下“运行”按钮的人。