# My Thoughts on Loop Engineering
**作者**: Samuel McDonnell
**日期**: 2026-06-15T14:14:00.000Z
**来源**: [https://x.com/samueljmcd/status/2066524627585634765](https://x.com/samueljmcd/status/2066524627585634765)
---

Loop engineering is the new label. The hard part is the one it has always been. Verification.
Tip: You can copy and paste this article into Claude and ask for the best insights if you don't want to read it all!!
There is a line doing the rounds. Boris Cherny, who created and now heads Claude Code, told the Fortune Brainstorm Tech audience in June that he no longer writes the prompts himself. His phrasing was that it is now another Claude doing the prompting. On a given morning he is managing hundreds of agents, sometimes thousands.
The framing that has grown up around this is "loop engineering." The pitch goes in three phases. 2024 was writing good prompts. 2025 was running agents in parallel. 2026 is building the loop that runs the agents for you. You stop typing prompts and start designing the system that types them.
That framing is fine as far as it goes. It also buries the part that decides whether your loop ships anything. A loop is a generator wired to a verifier. The generator was never the bottleneck. The verifier is.

## What a loop actually is
Strip the language back. A loop replaces the human cycle of prompt, read, prompt again with a self-running cycle: discover, plan, execute, verify, repeat until a condition is met. The agent drives its own iterations. You design the track it runs on.
The simplest version is a single agent looping over its own output. Research, draft, compare against the goal, fix the weak spots, repeat until it clears the bar. It is a person rewriting a draft, except the person does not get bored.
The larger version is a fleet. A goal goes to an orchestrator. The orchestrator splits it and hands pieces to specialists. Specialists hand detailed work to sub-agents. The tree runs discover, plan, execute, verify at every level until the goal is met. One is a single author. The other is a team running a project end to end.

None of this is new in kind. It is the same agent loop you already run, with the human stepped out of the inner cycle and moved up to the design of it.
## Open and closed
There are two shapes, and the difference is the whole game.
An open loop gives the agent a wide exploratory space. Conditions and a goal, but freedom in between. It can find paths you did not specify and produce things you did not plan for. This is where genuinely novel output comes from. It also burns tokens at a rate most budgets cannot absorb, and on loose criteria it turns into a slop machine. The freer the loop, the more it depends on the thing checking its work.
A closed loop pins the passes down in advance. Clear goal, defined steps, evaluation at each step, a stopping condition or a handoff to a human with the run data attached. The agent still loops, but inside a frame you built. It runs on a normal budget because the paths are bounded.

Closed loops are what produce results today. People credit the autonomy for that. The autonomy is not the reason. The evaluation gate is. The gate is what stops a confident wrong answer from propagating into the next iteration, and the next.
This is where most loop content goes quiet. Everyone draws the discover, plan, execute, verify diagram. Almost nobody says anything precise about the verify box. That box is the product. The rest is plumbing.
## Where the loop comes from
Loop engineering did not appear from nothing. Two research patterns sit underneath it.
ReAct, out of Princeton and Google, alternates reasoning and action. Think, act, observe the result, think again, repeat until done. In coding terms: understand the goal, write the code, run it, read the error, infer the cause, fix, rerun, until the tests pass. The loop is the point.
Reflexion is ReAct with a memory. When an attempt fails, the agent writes down in plain language why it failed, stores that note, and reads it on the next attempt. In a modern harness that note lives in a file, not the context window. This is the seed of everything people now call persistent memory.

Both patterns are about the same thing. An agent that checks itself beats an agent that does not.
## Inner loop and outer loop
A useful loop has two layers, and they get confused constantly.
The inner loop runs inside a single task. The agent validates its work before it answers. A weak agent edits the file and says done. A strong agent edits the file, writes a test, runs it, catches the failing edge case, fixes it, reruns, confirms green, then says done. Same tools. The only difference is whether the model chose to call the verifier. That choice is the difference between a demo and a result.
The outer loop runs across sessions. The agent fails at something, records the lesson in a persistent file, and a later session reads that file and gets it right from the start. SKILL.md and AGENTS.md are the obvious homes for this. The agent forgets when the context window resets. The repository does not.

The inner loop is mature. Most agents do it now. The outer loop is still half-built. Persisting the right lesson, in the right place, at the right grain, is harder than it sounds, and it is where a lot of value is currently sitting on the table.
Both layers are verification. The inner loop verifies the task. The outer loop verifies that you do not repeat last week's mistake. And neither is worth much if you cannot see it. You cannot improve a loop you are not measuring. Instrument the gate before you scale the loop, or you are just generating wrong answers faster.
## The Bun port, and the line Anthropic wrote itself
The flagship demonstration is worth reading carefully, because it makes the point better than any diagram.
Jarred Sumner, who built Bun, used Claude Code's dynamic workflows to port the runtime from Zig to Rust. Roughly 750,000 lines of Rust. 99.8% of the existing test suite still passing. Anthropic puts it at eleven days from first commit to merge. Sumner himself said six. Either number is remarkable.
Look at how it was built. One pass mapped the correct Rust lifetime for every struct field. A second wrote each file as a behaviour-identical port, hundreds of agents in parallel, two reviewer agents on every file. A separate layer of agents existed only to refute what the others produced. Then a fix loop drove the build and the test suite until both ran clean. The verification is not a step at the end. It's actually the architecture.

And then the caveat, which Anthropic wrote into its own announcement: the port is not yet in production.
That is the most honest line in the entire launch, and it is the one I would underline. A 99.8% pass on an existing suite is a benchmark result. It tells you the port reproduces the behaviour the old tests already described. Production is the behaviour nobody wrote a test for yet. The gap between those two is the gap this whole industry keeps tripping over. A loop that goes green is not a loop that is correct. It is a loop that satisfied the verifier you gave it. The quality of the output is capped by the quality of that verifier, and not one point higher.
## So what do you actually build
The mechanical parts are not exotic. A scheduled trigger to discover work and start the agent. Isolated git worktrees so parallel agents do not stand on each other's changes. Skills files so you are not re-explaining the project's conventions every run. Connectors to the tools the work already lives in. Separated generator and verifier roles, because an agent grading its own homework grades generously. And memory: the file that outlives the conversation and carries the lesson forward.
The native tooling has caught up to most of this. The documented features as of now are /goal, which holds a completion condition and keeps working across turns until it is met (added in v2.1.139), and dynamic workflows, where Claude writes an orchestration script that fans the work out across many parallel agents, on by default for some plans and gated behind ultracode and /config for others (research preview, v2.1.154+, capped at sixteen concurrent and a thousand agents per run). Both reduce the same thing: the back-and-forth of you instructing, checking, and instructing again.
Reach for them when the task genuinely does not fit one pass. They cost considerably more tokens than a normal session. Not every job is a workflow job, and dressing a small task up as one is its own kind of waste.
## The bottleneck moved
The skill being sold as loop engineering is real. It is just pointed at the wrong half of the system. Designing the orchestration is the easy part now, and the tools do most of it for you. The part that is still hard, still manual, and still where the results actually come from is the evaluation gate. What does the agent check. Against what. How does a failure get caught before it propagates. What gets written down so the next run starts ahead of this one.
Management in the age of agents is not about hiring capable workers. The workers are capable and cheap. It is about designing the constraints they run inside, the same as it always was with people.
Design the verifier, not the prompt.
Sources: Boris Cherny's remarks, Fortune Brainstorm Tech (June 2026). Dynamic workflows and the Bun port, Anthropic's "Introducing dynamic workflows in Claude Code" and the Claude Code docs. ReAct (Yao et al., Princeton and Google). Reflexion (Shinn et al.). The five-components-plus-memory framing follows Addy Osmani's writing on agent loops.
## 相关链接
- [Samuel McDonnell](https://x.com/samueljmcd)
- [@samueljmcd](https://x.com/samueljmcd)
- [38K](https://x.com/samueljmcd/status/2066524627585634765/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:14 PM · Jun 15, 2026](https://x.com/samueljmcd/status/2066524627585634765)
- [38.7K Views](https://x.com/samueljmcd/status/2066524627585634765/analytics)
- [View quotes](https://x.com/samueljmcd/status/2066524627585634765/quotes)
---
*导出时间: 2026/6/16 14:12:54*
---
## 中文翻译
# 关于 Loop 工程的一些思考
**作者**: Samuel McDonnell
**日期**: 2026-06-15T14:14:00.000Z
**来源**: [https://x.com/samueljmcd/status/2066524627585634765](https://x.com/samueljmcd/status/2066524627585634765)
---

Loop 工程是个新标签。难的那部分和以前一样:验证(Verification)。
提示:如果你不想通读全文,可以把这篇文章复制给 Claude,让它提取最精华的见解!
最近有一句话流传甚广。Boris Cherny,Claude Code 的缔造者兼现任负责人,在 6 月的 Fortune Brainstorm Tech 大会上告诉观众,他不再亲自编写提示词(Prompt)。他的说法是,现在是另一个 Claude 在写提示词。在一个给定的早晨,他要管理数百个 agent,有时甚至成千上万。
围绕这一点形成的概念框架叫做“Loop 工程”。这个说法分为三个阶段。2024 年是写好提示词。2025 年是并行运行 agent。2026 年是构建一个为你运行 agent 的 Loop。你不再输入提示词,而是开始设计那个替你输入提示词的系统。
这个说法在目前看来是成立的。但它掩盖了决定你的 Loop 是否能产出东西的关键环节。一个 Loop 就是一个连接了验证器的生成器。生成器从来都不是瓶颈,验证器才是。

## Loop 实际上是什么
把语言剥离开来。Loop 用一个自动运行的循环:发现、规划、执行、验证、重复直到满足条件,替代了人类“提示、阅读、再提示”的循环。Agent 驱动它自己的迭代。你设计它运行的轨道。
最简单的版本是一个单独的 agent 循环处理它自己的输出。研究、起草、与目标对比、修复薄弱环节、重复直到达到标准。这就像一个人在反复修改草稿,只不过这个人不会感到厌倦。
更大的版本是一个舰队。目标进入 orchestrator。Orchestrator 将其拆分并将任务交给专家。专家将详细工作交给子 agent。这棵树在每一层都运行发现、规划、执行、验证,直到目标达成。前者是单个作者。后者是一个端到端运行项目的团队。

这些本质上都不是新东西。它还是你已经运行的那个 agent loop,只是人类从内部循环退一步,上升到了循环的设计层面。
## 开放与封闭
有两种形态,而差别就是一切。
开放式 Loop 给 agent 一个广阔的探索空间。有条件和目标,但中间拥有自由度。它能找到你没有指定的路径,并产生你未曾计划的结果。这就是真正新颖产出的来源。但它也会以大多数预算无法承受的速度消耗 token,而且如果标准宽松,它就会变成一个制造垃圾的机器。Loop 越自由,就越依赖那个检查其工作的东西。
封闭式 Loop 预先锁定了步骤。明确的目标、定义的步骤、每一步的评估、停止条件或附带运行数据后移交给人类。Agent 依然在循环,但是在你构建的框架内。它消耗正常的预算,因为路径是有界限的。

封闭式 Loop 是目前能产生结果的形态。人们把功劳归于自主性。自主性不是原因,评估关卡才是。正是关卡阻止了一个自信的错误答案传播到下一次迭代,以及再下一次。
这是大多数 Loop 内容选择沉默的地方。每个人都在画发现、规划、执行、验证的图表。但几乎没有人对“验证”这个框说出什么精确的话。那个框才是产品。其余的都是管道工程。
## Loop 从何而来
Loop 工程并非凭空出现。它的底层有两个研究模式。
ReAct,源自普林斯顿和谷歌,交替进行推理和行动。思考、行动、观察结果、再思考、重复直到完成。用编程术语来说就是:理解目标、编写代码、运行、阅读报错、推断原因、修复、重新运行,直到测试通过。Loop 才是关键。
Reflexion 则是带记忆的 ReAct。当尝试失败时,agent 用大白话写下失败原因,存下这个笔记,并在下一次尝试时阅读。在现代框架中,这个笔记存在文件里,而不是上下文窗口。这就是现在被称为“持久记忆”的所有事物的种子。

这两种模式都在做同一件事。会自我检查的 agent 胜过不会的。
## 内循环与外循环
一个有用的 Loop 有两层,而人们总是把它们搞混。
内循环运行在单个任务内部。Agent 在回答之前验证自己的工作。一个弱的 agent 修改文件然后说完成了。一个强的 agent 修改文件、编写测试、运行它、捕获失败的边界情况、修复、重新运行、确认变绿,然后说完成。工具是一样的。唯一的区别在于模型是否选择调用验证器。这个选择就是演示和结果之间的区别。
外循环跨越会话运行。Agent 在某事上失败,将教训记录在持久文件中,后续会话读取该文件并从一开始就做对。SKILL.md 和 AGENTS.md 是显而易见的归宿。Agent 在上下文窗口重置时会遗忘。代码库不会。

内循环已经成熟。大多数 agent 现在都在做。外循环还是半成品。在正确的地点、以正确的粒度、持久化正确的教训,比听起来要难得多,而且这里目前还有很多价值待挖掘。
两层都是验证。内循环验证任务。外循环验证你不重复上周的错误。如果你看不见它们,这两者都不值一提。你无法改进一个你不测量的 Loop。在扩展 Loop 之前先给关卡装上仪表,否则你只是在更快地生成错误的答案。
## Bun 的移植,以及 Anthropic 自己写的那句话
这个旗舰演示值得仔细阅读,因为它比任何图表都更能说明问题。
构建了 Bun 的 Jarred Sumner,使用 Claude Code 的动态工作流将该运行时从 Zig 移植到了 Rust。大约 750,000 行 Rust 代码。99.8% 的现有测试套件依然通过。Anthropic 称从首次提交到合并花了十一天。Sumner 自己说是六天。无论哪个数字都令人瞩目。
看看它是怎么构建的。第一遍为每个结构体字段映射了正确的 Rust 生命周期。第二遍将每个文件写成行为一致的移植版,数百个 agent 并行工作,每个文件有两个审查 agent。还有一层 agent 专门存在用来反驳其他 agent 产出的内容。然后一个修复循环驱动构建和测试套件,直到两者都干净运行。验证不是最后的一步。它实际上是架构本身。

然后是那个警告,Anthropic 把它写进了自己的公告里:移植版尚未上线生产。
这是整个发布中最诚实的一行,也是我会划重点的一句话。在现有测试套件上 99.8% 的通过率是一个基准测试结果。它告诉你移植重现了旧测试已经描述的行为。生产环境是还没人写出测试的那种行为。这两者之间的差距,是整个行业不断绊倒的地方。一个变绿的 Loop 不等于一个正确的 Loop。它只是一个满足了你给它的验证器的 Loop。输出的质量被该验证器的质量封顶,一点也不会更高。
## 那你到底该构建什么
机械部件并不稀奇。一个定时触发器来发现工作并启动 agent。隔离的 git worktrees,这样并行 agent 不会互相踩踏修改。技能文件(Skills files),这样你不用每次都重新解释项目约定。连接到工作原本所在的工具。分离的生成器和验证器角色,因为给自己的作业打分的 agent 总会手松。还有记忆:那个比对话生命周期更长并将教训传递下去的文件。
原生工具已经追上了大部分功能。截至目前文档记载的功能包括 /goal,它持有一个完成条件,并持续跨越回合工作直到满足(在 v2.1.139 中添加),以及动态工作流,Claude 编写一个编排脚本将工作分发给许多并行的 agent,对某些计划默认开启,对其他计划则位于 ultracode 和 /config 之后(研究预览版,v2.1.154+,上限为十六个并发和每次运行一千个 agent)。两者都在减少同一件事:你指导、检查、再指导的来回拉锯。
当任务真的无法一遍完成时再使用它们。它们消耗的 token 比普通会话多得多。不是每份工作都是工作流工作,把小任务包装成工作流本身也是一种浪费。
## 瓶颈转移了
作为 Loop 工程被兜售的技能是真实的。只是它对准了系统的错误那一半。设计编排现在成了简单的那部分,而且工具大部分都替你做了。依然困难、依然手动、且依然是结果真正来源的,是评估关卡。Agent 检查什么。对照什么。失败如何在传播前被捕获。什么被写下来以便下一次运行能领先于这一次。
Agent 时代的管理不在于雇佣能干的工人。工人们既能干又便宜。在于设计他们运行的约束条件,就像管理人类向来如此一样。
设计验证器,而不是提示词。
来源:Boris Cherny 的讲话,Fortune Brainstorm Tech(2026 年 6 月)。动态工作流与 Bun 移植,Anthropic 的“在 Claude Code 中引入动态工作流”及 Claude Code 文档。ReAct(Yao 等人,普林斯顿与谷歌)。Reflexion(Shinn 等人)。五个组件加记忆的框架借鉴了 Addy Osmani 关于 agent 循环的写作。
## 相关链接
- [Samuel McDonnell](https://x.com/samueljmcd)
- [@samueljmcd](https://x.com/samueljmcd)
- [38K](https://x.com/samueljmcd/status/2066524627585634765/analytics)
- [升级到 Premium](https://x.com/i/premium_sign_up)
- [10:14 PM · Jun 15, 2026](https://x.com/samueljmcd/status/2066524627585634765)
- [38.7K Views](https://x.com/samueljmcd/status/2066524627585634765/analytics)
- [View quotes](https://x.com/samueljmcd/status/2066524627585634765/quotes)
---
*导出时间: 2026/6/16 14:12:54*