循环工程(Loop Engineering)谷歌云AI总监Addy Osmani详解

循环工程正逐步取代那些需要人工提示的编程助手，这一转变颇具深意。如今，系统已能自主完成这些任务。你可以将循环理解为一种递归式的目标定义：设定一个目的，然后让AI不断迭代，直至达成目标。大致而言，它包含五个基本组成部分，而Claude、Code和Codex均已具备这五个部分。

这很可能成为未来处理编码任务的主流方式。不过目前仍处于早期阶段，保持谨慎并不过分。同时，你必须密切关注Token成本——若你手头Token充裕，使用模式会截然不同。此外，还需找到确保质量不滑坡的方法，并解决效率问题。但无论如何，我们先来探讨这背后的真正含义。

@steipete 最近有句话说得十分到位：“你不再需要提示编程助手了。你应该设计那些能引导助手完成任务的循环结构。”而Anthropic的Claude Code负责人 @bcherny 也给出了类似的观点：“我不再主动提示Claude了。我现在让Claude去执行循环任务，然后自行决定下一步该做什么。我的职责，就是编写这些循环结构。”

那么，这一切到底意味着什么？

在过去大约两年时间里，人们获取编程帮助的方式基本只有一条路径：写一条有效的提示，提供足够的上下文。你输入一个指令，等待回复，再输入下一个指令。编程助手只是一个工具，而你始终掌控着它，一步步推进。这种模式已经逐渐过时——至少，有些人觉得它即将被淘汰。

现在，你需要构建一个小型系统：它能寻找工作机会，分配任务，检查任务完成情况，记录已完成的工作，然后决定下一步做什么。让这个系统自己去处理任务，而不是你亲自上手。我之前写过类似的概念，叫“Agent框架工程”——把环境塑造成一个由单个Agent运行的系统，而“工厂模型”则指的是用来构建软件的系统。循环工程，就建立在框架工程之上。框架工程依赖计时器运行，它生成一些小型辅助程序，并自行供给资源。

有趣的是，现在这种工具不再是独立存在的了。一年前，你想创建一个循环，需要编写一堆bash脚本，然后一直维护着，这些东西只属于你一个人。而现在，这些组件直接被集成到了产品里。Steipete的列表几乎与Codex应用完全对应，Claude Code也是如此。一旦你注意到这些组件的结构是相同的，就不会再纠结该用哪种工具了，而是直接设计出一个无论在什么环境下都能正常工作的循环。

五件必备物品，外加一些注释

一个循环需要五样东西，还需要一个地方来记住这些东西。先列出来，再细说。

1. 自动化流程：根据预定时间表运行，能自动发现和分类处理。
2. 并行执行：让两个同时工作的Agent不会互相干扰。
3. 技能：能把Agent可能仅凭猜测来掌握的项目知识记录下来。
4. 插件和连接器：把Agent连接到你已经使用的各种工具中。
5. 副Agent：有一个人提出想法，另一个人负责验证可行性。

还有第六个要素——记忆。无论是Markdown文件还是线性记录，只要能存储多个对话中的信息、记录当前操作和后续步骤，都算记忆。听起来可能没什么了不起，但这是所有长期运行的Agent所依赖的同一机制。在长时间运行的程序中，模型会在运行之间忘记一切，所以记忆必须存储在磁盘上，而不是在上下文里。Agent会忘记，但仓库不会。

这两种产品现在都拥有全部五项功能了。

它们的名称在不同地方略有差异，但功能是一样的。下面逐一说明，因为说实话，细节正是循环结构能紧密结合或悄悄泄露的地方。

自动化系统，这就是生命的节奏

自动化功能的核心，是让循环操作真正变成可重复执行的任务，而不是一次性的花哨表演。在Codex应用中，你可以在“自动化”选项卡里创建自动化任务。你可以指定要执行的项目、提示语、执行频率，以及是在本地环境还是后台工作树中执行。那些用于查找事物的操作会被发送到分类邮箱，而那些没找到任何东西的操作则会被直接归档——这很省心。OpenAI内部也利用自动化来处理一些繁琐的任务，比如日常问题分类、构建集成测试报告、编写提交说明，或者寻找上周有人新增的错误。自动化任务还能调用特定技能，这样重复性操作就能保持可维护性。你只需调用“$skill-name”就行，不用把一大堆指令粘到调度表里——毕竟没人会去更新这些指令。

Claude Code实现了同样的功能，不过是通过调度和钩子机制。你可以用/loop定期执行提示或命令；也可以安排定时任务；还可以在Agent生命周期中的特定时刻执行shell命令。如果你希望程序在关闭笔记本电脑后仍能持续运行，还可以把整个系统部署到GitHub Actions中。原理完全相同：定义一个自主任务，设定周期，然后通知会定期送达，你不需要亲自去检查。

有一个在会话期间使用的特殊指令值得了解，它正是本文讨论的核心。/loop按照特定的节奏重复执行。/goal会持续运行，直到你设定的条件成立；每次循环结束后，都会有一个独立的小型模型来检查任务是否完成，这样编写代码的Agent就不会成为最终评判者。你可以提供类似“所有测试都通过，代码也没有错误”这样的信息，然后就可以离开了。Codex也有类似的机制，同样叫/goal，它会持续运行，直到有可验证的停止条件成立，同时支持暂停、恢复或清除状态。两种工具都用了同样的机制，这正是本文的核心模式。

这就是工作的核心。循环的其他部分都围绕它运转。

并行执行，不会导致混乱

一旦用多个Agent来操作文件，文件就会开始相互冲突，这就是所谓的“故障”。两个Agent同时修改同一个文件，简直就是一场灾难——就像两个工程师同时修改同一行代码，而他们之间没有任何沟通。Git的工作树可以解决这个问题：它提供了一个独立的工作目录，位于同一个分支上，但共享相同的仓库历史。这样一来，一个Agent的修改就不会影响到另一个Agent的版本。

Codex在多个线程同时访问同一仓库时，能很好地处理工作树的构建，避免相互干扰。Claude Code提供了与Git工作树相同的隔离功能：通过--worktree参数可以开启一个独立工作环境；而“隔离：工作树”设置则让每个辅助工具都拥有自己的独立环境，每个工具都能独立运行，并自行清理工作区域。我在《协调成本》一文中详细讨论过这些复杂性——工作树确实避免了机械性的冲突，但你能同时运行多少个工具，最终还是由你来决定，而不是由工具本身决定。

技能，下次不用每次都解释你的项目

“技能”是一种方式，让你不用在每次会话中重复解释同一个项目，就像一条金鱼。这两种工具都使用相同的格式：一个包含“SKILL.md”文件的文件夹，里面存放着说明和元数据；还可以添加可选的脚本、引用文件以及资源文件。当你用“$”或“/skills”命令调用某个技能时，或者当你的任务符合该技能的描述时，代码就会执行这个技能。这就是为什么冗长而枯燥的描述不如巧妙的描述有效。Claude Code也是以同样的方式实现，而我也把这一模式编写在了Agent技能中。

技能也是让意图不再因错误而付出代价的关键。我在关于“意图债务”的讨论中提到，每次会话开始时，Agent都会从零开始，用自信的猜测来填补你意图中的空白。而技能则是将这种意图外在化，体现在各种惯例和操作步骤中——比如“因为那次事件，我们不会再按原来的方式做”。这些技能在每次会话中都会被重复阅读。没有技能的话，每次循环都会从头开始重新构建整个项目；有了技能，这种重复过程就会逐渐累积起来。

需要注意一点：所谓“技能”，本质上是一种创作格式；而插件则是用来实现这种格式传输的工具。当你想要在多个仓库之间共享某个技能，或者将多个技能组合在一起使用时，就会把它们打包成插件。在Codex和Claude Code中，这个概念都是如此应用的。

插件和连接器，与你的实际工具相连

只能访问文件系统的循环，说实话相当有限。基于MCP构建的连接器，可以让Agent读取你的问题跟踪数据、查询数据库、调用staging接口，甚至可以在Slack中发送消息。无论是Codex还是Claude Code，都支持MCP连接，所以你为其中一个系统编写的连接器通常也适用于另一个。此外，插件还可以把连接器和技能整合在一起，这样你的团队成员就可以一次性安装你的配置，而不用重新从内存中重建整个系统。

这就是那种声称“这里有解决方案”的Agent，与那些会打开PR、链接Linear工单、并在CI自己变绿后通知渠道的循环之间的区别。这些连接器正是让循环程序能在实际环境中发挥作用的关键，而不是仅仅描述一下如果它能执行哪些操作的话。

副Agent，让制造者远离检查员

在循环中，最实用的结构就是让写代码的人和验证代码的人分开。让写代码的人来负责自我评估，这个模型相当不错。另一个有不同指令的Agent——有时甚至用不同的模型——来检测第一个人写的代码，从而发现漏洞。

Codex仅在请求时才会生成子Agent。它会同时运行这些子Agent，然后把结果合并成一个答案。你可以把自己的Agent定义为TOML文件，存放在“.codex/agents/”目录下。每个文件都包含名称、描述、指令，以及可选的模型和推理工作量。这样，你的安全审查者就可以用高效的模型进行推理，而执行器可以是某种速度快且只读的工具。Claude Code也类似地处理“.claude/agents/”目录中的子Agent，以及负责分配任务的Agent团队。通常情况下，系统会分配一个Agent负责探索，另一个负责实施，还有一个负责根据规范进行验证。

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

坚持住，一条线就能变成一个小控制面板。这是我一直使用的一种形状。

每天早晨，仓库都会运行一次自动化流程。这个流程会调用一个分类技能，分析上周的CI测试缺陷、未解决的问题以及最近的提交内容，然后把分析结果记录到一个Markdown文件里，或写入Linear板。对于那些值得处理的缺陷，流程会打开一个独立的工作树，并派遣一个子Agent来起草修复方案；另一个子Agent则会根据项目需求和现有测试情况来审核这个方案。

这些连接器让循环能够打开待办事项并更新工单状态。任何循环无法处理的事情，都会被放进我的分类邮箱里。状态文件是整个系统的核心，它记录了哪些任务已经尝试过、哪些任务已经成功解决、哪些任务仍然在等待处理。所以，第二天早上，这些任务会继续从今天开始的处理流程。

看看你实际上做了什么吧。你只设计了一遍，并没有实际执行那些步骤。这正是Steipete的观点得到了验证——在Codex或Claude Code中，这些步骤都是相同的。因为各个部分都是一样的。

而这个循环仍然没有为你做些什么……

这个循环会改变工作内容，但它并不会把你从其中移除。实际上，随着循环变得越来越好，这三个问题反而会变得更严重，而不是更轻松。

没错，那种随遇而安的舒适态度，可能是一种冒险的选择。当循环机制自行运转时，人们很容易放弃自己的意见，接受系统给出的任何结果。这可以叫做“认知上的屈服”。如果你以评判的态度来使用这个循环，那它就是“治疗”；而如果你为了避免思考而使用它，那它就变成了“毁灭”。同样的行动，却产生相反的结果。

构建这个循环，保持工程师的专注

这很可能是我们的工作将如何发展的预兆。不过，如果我不亲自审查代码，或者完全依赖自动化流程来修复问题，那么我的产品质量就会受到影响。我可能会陷入一个恶性循环，不断把自己推入更深的困境。

去设置你的循环吧。但记住，直接提示你的Agent仍然是有效的手段。关键在于找到合适的平衡点。

这些循环的结果也可能因不同方式而有差异。两个人可以构建完全相同的循环，但最终得到的结果却截然不同。一个人利用这个循环来更快地完成自己熟悉的工作；另一个人则完全避免去理解那些工作内容。这个循环并不知道这两者之间的区别——只有你才能明白其中的差异。

这正是使得循环设计比提示工程更困难的原因，而不是更简单。Cherny的观点并非认为这项工作变得简单了。而是说，其中的控制点已经发生了改变。

去构建这个循环吧。但请用一种真正想成为工程师的方式去构建它，而不是一个只会按下启动按钮的人。