Loop Engineering

Loop Engineering - by Addy Osmani - Elevate

Loop Engineering

从提示代理到设计提示代理的系统。

Addy Osmani

2026年6月8日

Loop engineering 是将你自己从提示代理的人的角色中取代出来。你设计一个系统来代替你完成这个任务。这里的循环可以被看作是一个递归目标，你定义一个目的，AI 会持续迭代直到完成。它大致由五个构建模块组成，Claude Code 和 Codex 现在都具备这五个模块。

我认为这可能是我们未来与编码代理合作的方式。然而，目前还处于早期阶段，我持怀疑态度，你绝对必须小心令牌成本（如果你的令牌资源丰富或匮乏，使用模式可能会有巨大差异），因此我想解释一下它到底是什么，以及它意味着什么。

Peter Steinberger 最近说：“你不再应该提示编码代理了。你应该设计一些循环来提示你的代理。”同样，Anthropic 的 Claude Code 负责人 Boris Cherny 说：“我不再提示 Claude 了。我运行一些循环来提示 Claude 并决定该做什么。我的工作是编写这些循环。”

那么，以上这些意味着什么呢？

大约两年来，你从编码代理那里获取东西的方式是写一个良好的提示并提供足够的上下文。你输入一些内容，阅读返回的内容，然后输入下一部分内容。代理是一个工具，你一直握着它，一次又一次地进行交互。这一部分已经过去，或者至少有些人认为它将要过去。

现在，你构建一个小型系统，让它找到任务，分配任务，检查任务，记录已完成的内容，然后决定下一步要做什么，并让这个系统去提示代理，而不是你亲自去做。我之前写过关于这个主题的近亲，即代理 harness 工程，它是创建一个环境，让一个代理在其中运行，以及工厂模型——构建软件的系统。Loop engineering 位于 harness 的上一层。harness 是基于定时器运行的，它会生成一些小助手，并且可以自我喂养。

让我感到惊讶的是，这已经不再只是一个工具的问题了。一年前，如果你想创建一个循环，你得写一堆 bash 脚本，然后永远维护这个脚本堆，它只属于你一个人。现在，这些组件已经内置于产品中。Steinberger 的列表几乎完全对应于 Codex 应用，然后几乎同样对应于 Claude Code。一旦你注意到它们的结构是一样的，你就不再争论使用哪个工具，而是设计一个循环，无论你使用的是哪个工具，它都能正常工作。

五个部分，然后是备注

一个循环需要五件事，然后还有一个地方来记住一些东西。让我先列出它们，然后再进行映射。

• 按计划自动运行的自动化，可以自行进行发现和分类。

• Worktrees，这样两个并行工作的代理就不会互相干扰。

• 技能，用于记录代理本应猜测的项目知识。

• 插件和连接器，用于将代理连接到你已经使用的工具。

• 子代理，这样其中一个代理可以产生想法，另一个代理可以检查这个想法。

然后是第六个部分，记忆。一个 markdown 文件，或者一个 Linear 板，任何存在于单次对话之外并记录已完成和下一步内容的东西。听起来似乎太简单而无关紧要。但这是所有长期运行代理所依赖的相同技巧，我在长期运行的代理中详细讨论过，模型在每次运行之间会忘记所有内容，因此记忆必须存储在磁盘上，而不是上下文中。代理会忘记，但仓库不会。

这两个产品现在都具备这五个部分。

名称在不同地方略有不同，但它们的能力是相同的。让我逐一解释，因为说实话，细节决定了一个循环是保持连贯还是悄然泄漏到各处。

自动化，这是循环的心跳

自动化使循环成为一个真正的循环，而不仅仅是一次性运行。在 Codex 应用中，你可以在“自动化”标签页中创建一个自动化，选择项目、要运行的提示、运行频率，以及是在本地签出还是在后台工作树中运行。发现内容的运行会进入一个“分类”收件箱，而没有发现内容的运行则会归档，这很实用。OpenAI 内部使用它们来处理一些无聊的任务，比如日常问题分类、总结 CI 失败、撰写提交简报、查找上周某人添加的错误。自动化还可以调用技能，因此你可以保持重复任务的可维护性，你只需触发 $skill-name，而不是将一大段指令粘贴到一个没人会更新的计划中。

Claude Code 通过调度和钩子达到相同的效果。你可以使用 /loop 在一定间隔内运行一个提示或命令，你可以安排一个 cron 任务，你可以在代理生命周期的某些点使用钩子触发 shell 命令，或者如果你想让其在你关闭笔记本电脑后继续运行，可以将其推送到 GitHub Actions。完全相同的理念，你定义一个自主任务，你为其设定节奏，发现的内容会发送给你，这样你就不用四处检查。

还有一个在会话中值得了解的原始功能，它更接近本文的主题。/loop 按照节奏重新运行。/goal 会一直运行，直到你编写的条件真正成立，每次回合后，一个独立的小模型会检查你是否完成，因此编写代码的代理不是评分的人。你可以给它一个条件，例如“test/auth 中的所有测试通过且 lint 清洁”，然后离开。Codex 也有相同的功能，也称为 /goal，它会在回合之间持续运行，直到满足可验证的停止条件，支持暂停、恢复和清除。相同的原始功能，两种工具，这基本上是整篇文章的模式。

所以，这就是展现工作的地方。循环的其余部分则是对它的处理。

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

一旦你运行了多个代理，文件开始发生冲突，这就会成为失败。两个代理同时编辑同一个文件，这与两个工程师在未沟通的情况下提交到同一行代码完全一样。git 工作树解决了这个问题，它是一个独立的分支上的工作目录，共享相同的仓库历史，因此一个代理的编辑实际上无法影响另一个代理的签出。

Codex 在内部构建了工作树支持，因此多个线程可以同时访问同一个仓库而不会相互干扰。Claude Code 通过 git 工作树提供相同的隔离，使用 --worktree 标志在自己的签出中打开一个会话，并在子代理上设置 isolation: worktree，使每个助手都能获得一个干净的签出，并在使用后自动清理。我在“编排税”中讨论了所有这些的人类方面，工作树消除了机械冲突，但你仍然是瓶颈，你的审查带宽决定了你实际上可以运行多少个，而不是工具。

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

技能是你如何避免像金鱼一样在每次会话中反复解释相同的项目背景。这两种工具使用相同的格式，一个包含 SKILL.md 的文件夹，其中保存了指令和元数据，然后是可选的脚本、参考资料和资源。当使用 $ 或 /skills 调用技能时，或当你的任务与技能描述匹配时，Codex 会运行该技能，这也是为什么一个简洁无聊的描述胜过一个聪明的描述的原因。Claude Code 也采用同样的方式，我在 agent skills 中详细描述了这种模式。

技能也是你停止反复支付意图成本的地方。我在意图债务中提到过，代理在每次会话开始时都是冷启动，它会用自信的猜测填补你意图中的任何漏洞。技能就是将这些意图写在外部，包括惯例、构建步骤、以及“我们不这样做的原因是因为那次事件”，只写一次，而代理在每次运行时都会读取它。没有技能的话，每次循环都会从零重新推导你的整个项目，而有了技能，这种推导就会积累起来。

有一点需要明确，技能是创作的格式，而插件是你是如何发布它的。当你想要在多个仓库之间共享一个技能或捆绑几个技能时，你可以将它们打包成一个插件。在 Codex 中如此，在 Claude Code 中也是如此。

插件和连接器，循环可以触及你的实际工具

一个只能看到文件系统的循环是一个非常有限的循环。连接器是基于 MCP 构建的，它们可以让代理读取你的问题跟踪器、查询数据库、调用一个预发布 API、在 Slack 中发送消息。Codex 和 Claude Code 都使用 MCP，因此你为其中一个编写的连接器通常在另一个中也能直接使用。插件将连接器和技能捆绑在一起，这样你的队友可以一次性安装你的设置，而不是从记忆中重新构建整个东西。

这是代理说“这里是修复方法”和循环自动打开 PR、链接 Linear 任务并在 CI 变绿后向频道发送通知之间的区别。连接器是循环能够在你的实际环境中采取行动，而不仅仅是告诉你它能做什么的原因。

子代理，将创作者与检查者分开

在循环中，最有用的结构之一，无疑是将编写者和检查者分开。编写代码的模型在给自己打分时过于仁慈。一个具有不同指令、有时甚至使用不同模型的第二个代理可以发现第一个代理自己说服自己忽略的问题。

Codex 只有在你请求时才会生成子代理，它们同时运行，然后将结果合并成一个答案。你可以通过在 .codex/agents/ 中定义自己的 TOML 文件来定义自己的代理，每个代理都有名称、描述、指令，以及可选的模型和推理努力程度，因此你的安全审查员可以是一个高努力程度的强模型，而你的探索者则可能是一个快速的只读工具。Claude Code 同样通过 .claude/agents/ 中的子代理和在它们之间传递工作的代理团队来实现这一点。在两者中，通常的分工是一个代理负责探索，一个负责实现，还有一个负责根据规范进行验证。

我已经两次构建了这个案例，一次是作为代码代理编排，另一次是作为对抗性代码审查。之所以在循环中特别重要，是因为循环在你没有关注的时候运行，所以唯一能让你放心离开的理由，是你真正信任的验证者。子代理确实会消耗更多令牌，因为每个子代理都要进行自己的模型和工具工作，所以只在需要第二个意见的地方使用它们。这也是 Claude Code 的 /goal 实际上所做的事情，一个全新的模型决定循环是否结束，而不是执行工作的那个模型，制造者和检查者被应用于停止条件本身。

一个循环的外观

将它们组合在一起，单线程就变成一个小小的控制面板。这是我经常使用的一种结构。

每天早上，自动化会在仓库中运行一次。它的提示会调用一个分诊技能，读取昨天的 CI 失败情况、开放的问题、最近的提交，并将发现的结果写入一个 markdown 文件或 Linear 板。对于每一个值得处理的发现，线程会打开一个隔离的工作树，并发送一个子代理来起草修复方案，同时另一个子代理会根据项目技能和现有测试来审查该草案。

连接器让循环可以打开 PR 并更新工单。循环无法处理的任何内容都会进入我的分诊收件箱。状态文件是整个结构的脊柱，它会记住尝试过什么、哪些通过了、哪些仍然开放，因此明天早上运行会从今天停止的地方继续。

看看你实际上在那里做了什么。你只设计了一次。你并没有提示任何这些步骤。这就是 Steinberger 的观点真正实现的地方，而且无论是 Codex 还是 Claude Code，都是同样的循环，因为它们使用的组件是一样的。

循环仍然无法为你做的事情

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

验证仍然由你负责。一个无人值守运行的循环，也是一个无人值守犯错的循环。你将验证子代理从制造者中分离出来的全部原因，就是为了让循环的“已完成”具有实际意义，即使如此，“已完成”只是一个主张，而不是证明。我一直在重申人工智能时代代码审查中的同一句话：你的工作是发布你确认能正常工作的代码。

如果你允许它，你的理解仍然会退化。循环越快地发布你没有编写的代码，现实存在与你真正理解之间的差距就越大。这是理解债务，一个流畅的循环只会让这种债务增长得更快，除非你阅读了循环所生成的内容。

而舒适的姿态反而是危险的。当循环自行运行时，很容易停止表达自己的观点，只是接受它返回的任何结果。我称之为认知投降。当你带着判断力设计循环时，它是一种治愈方式；而当你为了逃避思考而设计循环时，它则是一种加速剂。同样的行为，却产生了相反的结果。

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

我认为这预示了我们工作方式的演变。话虽如此，如果我自己不审查代码，或者如果我完全依赖自动化循环来修复它，我的产品质量将会下降。我可能会陷入一个向下螺旋，不断让自己陷入更深的困境。

话虽如此，去设置你的循环吧，但不要忘记直接提示你的代理同样有效。关键在于找到合适的平衡点。

循环的结果也可能因人而异。两个人可以构建完全相同的循环，却得到截然不同的结果。一个人用它来在自己深刻理解的工作上加快进度。另一个人则用它来完全回避对工作的理解。循环本身并不知道其中的区别，但你清楚。

这正是为什么循环设计比提示工程更难，而不是更容易。切尔尼的观点并不是说工作变得更简单了，而是说杠杆点发生了变化。

构建循环。但要像一个打算继续做工程师的人那样去构建，而不仅仅是一个按下“开始”按钮的人。