Loop Engineering循环工程

The following article originally appeared on Addy Osmani’s blog and is being reposted here with the author’s permission.以下文章最初发表于Addy Osmani的博客，经作者许可在此转载。

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. A loop here can be thought of as a recursive goal where you define a purpose and the AI iterates until complete. I believe this may be the future of how we work with coding agents. However, it’s still early; I’m skeptical, and you absolutely have to be careful about token costs (usage patterns can vary wildly if you are token rich or poor), so I want to unpack what it is and what it means.循环工程是用你设计系统来代替你作为提示智能体的人。这里的循环可以看作是一个递归目标，你定义一个目的，AI迭代直到完成。我相信这可能是我们使用编码智能体的未来。然而，现在还为时过早；我持怀疑态度，而且你必须非常小心令牌成本（使用模式可能因令牌丰富或贫乏而有很大差异），所以我想剖析它是什么以及它意味着什么。

Peter Steinberger recently said: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Similarly, Boris Cherny, head of Claude Code at Anthropic, said, “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops”.Peter Steinberger最近说：“你不应该再提示编码智能体了。你应该设计循环来提示你的智能体。”同样，Anthropic的Claude Code负责人Boris Cherny说：“我不再提示Claude了。我有循环在运行，提示Claude并决定做什么。我的工作是编写循环。”

Okay, so what does any of that mean?好吧，那到底是什么意思？

For like two years, the way you got something out of a coding agent was you wrote a good prompt and shared enough context. You type a thing, you read what came back, you type the next thing. The agent is a tool and you are holding it the entire time, one turn after the other. That part is kind of over, or at least some think it’s going to be.大约两年来，你从编码智能体那里得到东西的方式是写一个好的提示并分享足够的上下文。你输入一些东西，阅读返回的内容，再输入下一个东西。智能体是一个工具，你一直握着它，一轮接一轮。这部分已经结束了，或者至少有些人认为它将会结束。

Now you build a small system that finds the work, hands it out, checks it, writes down what is done and then decides the next thing, and you let that system poke the agents instead of you. I wrote before about the cousin of this, agent harness engineering, which is making the environment one single agent runs inside and the factory model—the system that builds the software. Loop engineering sits one floor above the harness. The harness but it runs on a timer, it spawns little helpers, and it feeds itself.现在你构建一个小系统，它找到工作，分配出去，检查，记录完成的内容，然后决定下一步，你让那个系统去戳智能体，而不是你。我之前写过它的近亲——智能体驾驭工程，即制造单个智能体运行的环境和工厂模型——构建软件的系统。循环工程位于驾驭层之上。驾驭层但它在定时器上运行，它产生小助手，并且自我供给。

The thing that surprised me is this is not really a tool thing anymore. A year ago if you wanted a loop you wrote a pile of bash and you maintained that pile forever and it was yours and only yours. Now the pieces just ship inside the products. Steinberger’s list maps almost exactly onto the Codex app, and then almost the same onto Claude Code. And once you notice the shape is the same, you stop arguing about which tool. You just design a loop that still works no matter which one you happen to be sitting in.让我惊讶的是，这不再是一个工具问题。一年前，如果你想要一个循环，你写一堆bash脚本，然后永远维护那堆脚本，它只属于你一个人。现在这些部件直接内置在产品中。Steinberger的列表几乎完全映射到Codex应用，然后几乎相同地映射到Claude Code。一旦你注意到形状相同，你就停止争论哪个工具。你只需设计一个循环，无论你碰巧使用哪个工具，它都能工作。

The five pieces, and then notes五个部分，以及备注

A loop needs five things and then one place to remember stuff. Let me list it first and then map it.一个循环需要五样东西，然后一个地方来记住东西。让我先列出它，然后映射它。

1. Automations that go off on a schedule and do discovery and triage by themselves按计划自动运行并自行发现和分类的自动化
2. Worktrees so two agents working in parallel don’t step on each other工作树，这样并行工作的两个智能体不会互相干扰
3. Skills to write down the project knowledge the agent would otherwise just guess技能，用于记录智能体否则只能猜测的项目知识
4. Plugins and connectors to plug the agent into the tools you already use插件和连接器，将智能体连接到你已经使用的工具
5. Subagents so one of them has the idea and a different one checks it子智能体，这样其中一个有想法，另一个检查它

Then the sixth thing, the memory. A Markdown file, or a Linear board, anything that lives outside the single conversation and holds what’s done and what is next. Sounds too dumb to matter. But it’s the same trick every long-running agent depends on, and I went into it in “Long-Running Agents”: The model forgets everything between runs so the memory has to be on disk and not in the context. The agent forgets; the repo doesn’t.然后是第六样东西，记忆。一个Markdown文件，或一个Linear看板，任何存在于单个对话之外并记录已完成和下一步的内容。听起来太简单而不重要。但这是每个长期运行的智能体依赖的相同技巧，我在“长期运行的智能体”中深入探讨过：模型在运行之间会忘记一切，所以记忆必须在磁盘上而不是在上下文中。智能体会忘记；仓库不会。

Both products have all five now.两个产品现在都有这五样东西。

The names are a bit different here and there, but the capability is the same thing. Let me go one by one because honestly the details are where a loop either holds together or quietly leaks everywhere.名称可能略有不同，但功能是相同的。让我逐一介绍，因为说实话，细节决定了循环是保持完整还是悄悄泄漏。

Automations, this is the heartbeat自动化，这是心跳

Automations are what make a loop an actual loop and not just one run you did once. In the Codex app you make one in the Automations tab and you pick the project, the prompt it will run, how often, and if it runs on your local checkout or on a background worktree. The runs that find something go to a Triage inbox, and the runs that find nothing just archive themselves which is nice. OpenAI uses them internally for boring stuff like daily issue triage, summarizing CI failures, writing commit briefings, and hunting bugs somebody added last week. And an automation can call a skill, so you keep the recurring thing maintainable; you fire $skill-name instead of pasting a giant wall of instructions into a schedule that nobody will ever update.自动化是使循环成为真正的循环而不是你只运行一次的东西。在Codex应用中，你在自动化选项卡中创建一个，然后选择项目、要运行的提示、频率，以及它是在你的本地检出上运行还是在后台工作树上运行。找到东西的运行会进入分类收件箱，什么都没找到的运行会自动归档，这很好。OpenAI内部使用它们来做无聊的事情，比如每日问题分类、总结CI失败、编写提交简报以及查找上周添加的bug。而且自动化可以调用技能，这样你可以保持重复性任务的可维护性；你调用$skill-name而不是将一堵巨大的指令墙粘贴到永远不会更新的计划中。

Claude Code gets to the same place but through scheduling and hooks. You can run a prompt or a command on a interval with /loop, you can schedule a cron task, you can fire shell commands at certain points in the agent lifecycle with hooks, or you push the whole thing to GitHub Actions if you want it to keep running after you close the laptop. Same idea exactly, you define an autonomous task, you give it a cadence, and the findings come to you so you are not the one going around checking.Claude Code通过调度和钩子达到同样的效果。你可以使用/loop按间隔运行提示或命令，你可以安排cron任务，你可以在智能体生命周期的某些点通过钩子触发shell命令，或者如果你在关闭笔记本电脑后希望它继续运行，你可以将整个事情推送到GitHub Actions。完全相同的想法，你定义一个自主任务，给它一个节奏，结果会来找你，这样你就不需要四处检查了。

There is a second in-session primitive worth knowing, and it’s the one closer to what this whole post is about. /loop re-runs on a cadence. /goal keeps going until a condition you wrote is actually true, and after every turn a separate small model checks whether you are done, so the agent that wrote the code isn’t the one grading it. You give it something like “all tests in test/auth pass and lint is clean” and walk away. Codex has the same thing, also called /goal: It keeps working across turns until a verifiable stopping condition holds, with pause and resume and clear. Same primitive, both tools, which is kind of the pattern for this whole article.还有一个会话内的原语值得了解，它更接近这篇文章的主题。/loop按节奏重新运行。/goal持续运行直到你编写的条件为真，并且在每次轮次之后，一个单独的小模型检查你是否完成，这样编写代码的智能体就不是给它打分的人。你给它类似“test/auth中的所有测试通过且lint干净”这样的条件，然后走开。Codex也有同样的东西，也叫做/goal：它跨轮次持续工作，直到一个可验证的停止条件成立，支持暂停、恢复和清除。相同的原语，两个工具都有，这几乎是整篇文章的模式。

So this is the part that surfaces the work. The rest of the loop is what acts on it.所以这是浮现工作的部分。循环的其余部分是对其采取行动。

Worktrees, so parallel doesn’t turn into chaos工作树，这样并行不会变成混乱

The second you run more than one agent, the files start colliding; that becomes the failure. Two agents writing the same file is the exact same headache as two engineers committing to the same lines and nobody talked to each other first. A Git worktree fixes it. It’s a separate working directory on its own branch sharing the same repo history, so one agent’s edits literally cannot touch the other one’s checkout.一旦你运行多个智能体，文件开始冲突；这成为失败点。两个智能体写入同一个文件与两个工程师在没有事先沟通的情况下提交到同一行是完全相同的头痛。Git工作树解决了这个问题。它是一个独立的工作目录，位于自己的分支上，共享相同的仓库历史，因此一个智能体的编辑实际上无法触及另一个智能体的检出。

Codex builds the worktree support right in so several threads hit the same repo at once and don’t bump into each other. Claude Code gives you the same isolation with git worktree, a --worktree flag to open a session in its own checkout, and a isolation: worktree setting you stick on a subagent so each helper gets a fresh checkout that cleans itself up after. (I wrote about the human side of all this in “The Orchestration Tax.”) The worktrees take away the mechanical collision, but YOU are still the ceiling. Your review of bandwidth decides how many you can actually run, not the tool.Codex内置了工作树支持，因此多个线程可以同时访问同一个仓库而不会互相碰撞。Claude Code通过git worktree提供相同的隔离，一个--worktree标志用于在其自己的检出中打开会话，以及一个isolation: worktree设置，你可以将其附加到子智能体上，这样每个助手都会获得一个自动清理的新检出。（我在“编排税”中写过这一切的人性化方面。）工作树消除了机械碰撞，但你仍然是瓶颈。你的审查带宽决定了你实际能运行多少个，而不是工具。

Skills, so you stop explaining your project every single time技能，这样你就不必每次都解释你的项目

A skill is how you stop reexplaining the same project context every session like a goldfish. Both tools use the same format: a folder with a SKILL.md inside holding instructions and metadata, and then optional scripts, references, and assets. Codex runs a skill when you call it with $ or /skills, or by itself when your task matches the skill description, which is the reason a tight, boring description beats a clever one. Claude Code does it the same way and I wrote the pattern up in “Agent Skills.”技能是你如何停止每次会话都像金鱼一样重新解释相同的项目上下文。两个工具使用相同的格式：一个包含SKILL.md的文件夹，里面包含指令和元数据，以及可选的脚本、参考和资产。Codex在你使用$或/skills调用技能时运行它，或者当你的任务匹配技能描述时自动运行，这就是为什么一个紧凑、无聊的描述胜过聪明的描述。Claude Code以相同的方式实现，我在“智能体技能”中写过这个模式。

Skills are also where intent stops costing you over and over. I argued in “The Intent Debt” that an agent starts every session cold and it will fill any hole in your intent with a confident guess. A skill is that intent written down on the outside, the conventions, the build steps, the “we don’t do it like this because of that one incident,” written one time where the agent reads it every run. Without skills the loop rederives your whole project from zero every cycle; with skills it kind of compounds.技能也是意图不再让你反复付出代价的地方。我在“意图债务”中论证过，智能体每次会话都是冷启动，它会用自信的猜测填补你意图中的任何漏洞。技能就是写在外部的那份意图——约定、构建步骤、“我们因为那次事件不这样做”——写一次，智能体每次运行都读取它。没有技能，循环每个周期都从零重新推导你的整个项目；有了技能，它会复合增长。

One thing to keep straight: The skill is the authoring format, and a plugin is how you ship it. When you want to share a skill across repos or bundle a few together, you package them as a plugin. True in Codex, true in Claude Code.有一件事要搞清楚：技能是创作格式，而插件是你如何交付它。当你想要跨仓库共享技能或将几个技能捆绑在一起时，你将它们打包为插件。在Codex中如此，在Claude Code中也如此。

Plugins and connectors, the loop touches your real tools插件和连接器，循环触及你的真实工具

A loop that can only see the filesystem is a tiny loop. Connectors, which are built on MCP, let the agent read your issue tracker, query a database, hit a staging API, or drop a message in Slack. Codex and Claude Code both speak MCP so the connector you wrote for one usually just works in the other. And plugins bundle connectors and skills together so your teammate installs your setup in one go instead of rebuilding the whole thing from memory.一个只能看到文件系统的循环是一个微小的循环。连接器，基于MCP，让智能体读取你的问题跟踪器、查询数据库、访问暂存API或在Slack中发送消息。Codex和Claude Code都支持MCP，因此你为一个编写的连接器通常可以在另一个中工作。而插件将连接器和技能捆绑在一起，这样你的队友可以一次性安装你的设置，而不是从头重建整个东西。

This is the difference between an agent that says “here is the fix” and a loop that opens the PR, links the Linear ticket, and pings the channel once CI is green by itself. The connectors are the reason the loop can act inside your actual environment instead of just telling you what it would do if it could.这就是说“这是修复”的智能体与打开PR、链接Linear工单并在CI变绿时自动ping频道的循环之间的区别。连接器是循环能够在你实际环境中行动的原因，而不是仅仅告诉你如果它能做到它会做什么。

Subagents, keep the maker away from the checker子智能体，让制造者远离检查者

The most useful structural thing in a loop, by far, is splitting the one who writes from the one who checks. The model that wrote the code is way too nice grading its own homework. A second agent with different instructions and sometimes a different model catches the stuff the first one talked itself into.循环中最有用的结构部分，远胜其他，是将编写者与检查者分开。编写代码的模型在给自己的作业打分时太宽容了。第二个具有不同指令、有时使用不同模型的智能体会捕捉第一个智能体说服自己相信的东西。

Codex only spawns subagents when you ask, runs them at the same time, and then folds the results back into one answer. You define your own agents as TOML files in .codex/agents/, each with a name, a description, instructions, and optional model and reasoning effort, so your security reviewer can be a strong model on high effort while your explorer is some fast read-only thing. Claude Code does the same with subagents in .claude/agents/ and agent teams that pass work between them. The usual split in both is one agent explores, one implements, and one verifies against the spec.Codex只在你要求时生成子智能体，同时运行它们，然后将结果合并回一个答案。你在.codex/agents/中将你自己的智能体定义为TOML文件，每个都有名称、描述、指令以及可选的模型和推理努力，这样你的安全审查员可以是一个高努力度的强模型，而你的探索者是一个快速的只读东西。Claude Code在.claude/agents/中使用子智能体和在它们之间传递工作的智能体团队做同样的事情。两者中常见的分工是一个智能体探索，一个实现，一个根据规范验证。

I made this case twice already, once as “The Code Agent Orchestra” and once as “Adversarial Code Review.” The reason it matters specifically inside a loop is the loop runs while you are not watching, so a verifier you actually trust is the only reason you can walk away. Subagents do burn more tokens since each one does its own model and tool work, so spend them where a second opinion is worth paying for. This is also basically what Claude Code’s /goal does under the hood: A fresh model decides if the loop is done instead of the one that did the work, the maker and checker split applied to the stop condition itself.我已经两次提出这个观点，一次是“代码智能体管弦乐队”，一次是“对抗性代码审查”。它在循环内部特别重要的原因是循环在你不在看的时候运行，因此一个你真正信任的验证者是你能够走开的唯一原因。子智能体确实会消耗更多令牌，因为每个都做自己的模型和工具工作，所以在你认为第二意见值得付出代价的地方使用它们。这基本上也是Claude Code的/goal在底层所做的：一个全新的模型决定循环是否完成，而不是做工作的那个，制造者和检查者的分离应用于停止条件本身。

What one loop looks like一个循环的样子

Stick it together and a single thread turns into a little control panel. Here is one shape I keep using.把它们组合在一起，一个单独的线程就变成了一个小控制面板。这是我一直在使用的一个形状。

An automation runs every morning on the repo. Its prompt calls a triage skill that reads yesterday’s CI failures, the open issues, and the recent commits and writes the findings into a Markdown file or a Linear board. For each finding that is worth doing, the thread opens an isolated worktree and sends a subagent to draft the fix, and a second subagent reviews that draft against the project skills and the existing tests.一个自动化每天早上在仓库上运行。它的提示调用一个分类技能，读取昨天的CI失败、开放的问题和最近的提交，并将结果写入一个Markdown文件或Linear看板。对于每个值得做的发现，线程打开一个隔离的工作树并发送一个子智能体来起草修复，第二个子智能体根据项目技能和现有测试审查该草稿。

Connectors let the loop open the PR and update the ticket. Anything the loop cannot handle lands in the triage inbox for me. The state file is the spine of the whole thing; it remembers what got tried, what passed, and what is still open, so tomorrow morning the run picks up where today stopped.连接器让循环打开PR并更新工单。循环无法处理的任何东西都会进入我的分类收件箱。状态文件是整个事情的主干；它记住尝试了什么、通过了什么以及还有什么未完成，这样明天早上运行会从今天停止的地方继续。

And look at what you actually did there. You designed it one time. You did not prompt any of those steps. That’s Steinberger’s whole point made real, and it’s the same loop in Codex or in Claude Code because the pieces are the same pieces.看看你实际做了什么。你设计了一次。你没有提示任何这些步骤。这就是Steinberger的整个观点变为现实，而且在Codex或Claude Code中是相同的循环，因为部件是相同的部件。

What the loop still does not do for you循环仍然不能为你做什么

The loop changes the work; it does not delete you from it. And three problems actually get sharper as the loop gets better, not easier.循环改变了工作；它并没有把你从工作中删除。而且随着循环变得更好，三个问题实际上变得更尖锐，而不是更容易。

Verification is still on you. A loop running unattended is also a loop making mistakes unattended. The whole reason you split the verifier subagent from the maker is to make the loop’s “it’s done” mean something, and even then “done” is a claim and not a proof. I keep saying the same line from “Code Review in the Age of AI”: Your job is to ship code you confirmed works.验证仍然在你身上。一个无人值守运行的循环也是一个无人值守犯错的循环。你将验证子智能体与制造者分开的全部原因是为了让循环的“完成”有意义，即使如此，“完成”也是一个声明而不是一个证明。我一直在重复“AI时代的代码审查”中的同一句话：你的工作是交付你确认有效的代码。

Your understanding still rots if you allow it. The faster the loop ships code you did not write, the bigger the gap between what exists and what you actually get. That’s comprehension debt and a smooth loop just makes it grow faster unless you read what the loop made.如果你允许，你的理解仍然会腐烂。循环交付你没有编写的代码越快，存在的东西和你实际理解的东西之间的差距就越大。这就是理解债务，一个顺畅的循环只会让它增长得更快，除非你阅读循环制造的东西。

And the comfortable posture is the dangerous one. When the loop runs itself, it’s very tempting to stop having an opinion and just take whatever it gives back. I called that “cognitive surrender.” Designing the loop is the cure when you do it with judgment and the accelerant when you do it to avoid thinking: same action, opposite result.而舒适的姿势是危险的姿势。当循环自我运行时，很容易停止拥有意见，只是接受它返回的任何东西。我称之为“认知投降”。当你用判断力设计循环时，它是解药；当你用它来避免思考时，它是催化剂：相同的行动，相反的结果。

Build the loop. Stay the engineer.构建循环。保持工程师的身份。

I think this is a preview of how our work is going to evolve. That said, if I weren’t reviewing the code myself or if I relied entirely on automated loops to fix it, my product’s quality would suffer. I’d likely end up stuck in a downward spiral, continuously digging myself into a deeper hole.我认为这是我们工作如何演变的一个预览。话虽如此，如果我不自己审查代码，或者我完全依赖自动化循环来修复它，我的产品质量会受到影响。我可能会陷入一个恶性循环，不断把自己挖得更深。

Go ahead and set up your loops, but don’t forget that prompting your agents directly is also effective. It’s all about finding the right balance.去设置你的循环吧，但不要忘记直接提示你的智能体也是有效的。关键在于找到正确的平衡。

Loops can also result in different outcomes depending on you. Two people can build the exact same loop and get completely opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop doesn’t know the difference. You do.循环也可能根据你产生不同的结果。两个人可以构建完全相同的循环，得到完全相反的结果。一个人用它来更快地推进他们深刻理解的工作。另一个人用它来避免理解工作。循环不知道区别。你知道。

That’s what makes loop design harder than prompt engineering. Cherny’s point isn’t that the work got easier. It’s that the leverage point moved.这就是为什么循环设计比提示工程更难。Cherny的观点不是工作变得更容易了。而是杠杆点移动了。

Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.构建循环。但要像打算保持工程师身份的人那样构建它，而不仅仅是按下开始按钮的人。