# From Prompting Agents to Loop Engineering
**作者**: elvis
**日期**: 2026-06-19T16:31:20.000Z
**来源**: [https://x.com/omarsar0/status/2068008743153832264](https://x.com/omarsar0/status/2068008743153832264)
---
A claim has been circulating in AI coding circles: stop prompting your coding agents and start designing loops that prompt them for you. As with everything new, this stuff gets repeated often and explained rarely. This is the practical version: what an agent loop is, why it matters, and what one looks like in production.
Below you can read some of my thoughts (written with the help of Claude) from some of the experiments, research, and conversations I’ve been having with some of our students, technical founders, AI engineers, and startups.
You might also find our recent live session on "Autonomous Long-Running Coding Agents" as a good starting point for all of this.
## Where the claim comes from
> "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."Peter Steinberger (@steipete), Jun 7 2026. 2.2M views. Original tweet
Boris Cherny, the creator of Claude Code, makes the same point from the other side.
> "I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops."Boris Cherny (@bcherny). Original tweet
The point is not that prompt engineering is dead. With loop engineering, the work moves up a level, from writing the code to writing the system that writes the code. Developers furthest along this path report months where they shipped hundreds of PRs without opening an IDE, with every line written by the agent.
## What a loop actually is
A loop is a small program you write that does four things:
- prompts the coding agent for you,
- reads what it produced,
- decides whether it is done,
- and if not, prompts it again with the error or the next step.
You stop sitting inside the loop typing prompts; you write the loop, and the model becomes a subroutine it calls.
The shape is always the same: set a goal, act, check, feed the error back, and repeat until the check passes or the loop stops itself.
## "Loop" means at least five things
Much of the disagreement is people using one word for five different ideas. Here is the progression, oldest to newest.
- ReAct (2022). The original research pattern: reason, act, observe, repeat.
- AutoGPT (2023). A self-prompting goal loop, notorious for not knowing when to stop.
- ralph loop. A deliberate context reset between iterations so the agent does not drown in its own history.
- /loop and /goal. Cadence and completion conditions are built into the agent, carrying the state across turns.
- orchestration. One author fans out many agents that read your GitHub, Slack, and chat, and decide what to build next.
## The parts you actually assemble
The progression explains what people mean by loop; this is what a loop is built from. The same six parts show up every time, and most now ship inside the coding tools instead of custom scripting you maintain yourself.
- A trigger. Something that starts the loop without you pressing go: a schedule, a webhook, a file change, a label landing on a PR. This is what separates a real loop from a single run you repeat by hand.
- Isolation. A private checkout per agent, usually a git worktree, so two agents running at once cannot overwrite each other's files. Once you run more than one, this stops being optional.
- Written-down context. The conventions, build steps, and project-specific rules are kept where the agent reads them on every run. Skip it, and the loop re-derives your project from scratch each pass and guesses at the gaps.
- Reach into your tools. Connectors to the issue tracker, CI, database, and chat, so the loop can open the PR, link the ticket, and post the result instead of printing a fix and waiting for you to carry it the rest of the way.
- A second agent checks. A separate worker who grades the output is held apart from the one who produced it, because a model reviewing its own work passes almost everything.
- State on disk. A markdown file, a board, or a queue: anything outside the conversation that records what is finished and what is next. The model forgets between runs; the file does not.
Assemble those six, and you have a good starting point for loop engineering. You used to hand-build everything; now most ship as built-in features, which is why the pattern has moved from a fringe technique into common use.
## A concrete loop, the PR babysitter
A concrete example you can build today:
- Trigger. Every 15 minutes.
- Scope. Open PRs labeled agent-watch.
- Action. If CI is red for a deterministic reason, attempt one fix. If the main moved, rebase once.
- Budget. One fix attempt per PR, five minutes, ten files changed.
- Stop condition. CI green, or budget exhausted, then stop and ping a human.
You return to merged PRs instead of a backlog of broken builds. The same shape covers most ops work:
- CI health. Every 30 minutes, pull failing runs and cluster them by signature, so ten red PRs with one root cause become one thing to look at.
- Deploy verification. After a push, hit your endpoints, confirm 200s and the expected content, and flag regressions before users do.
- Feedback clustering. Every 30 minutes, pull comments from your channels, group them into themes, and map each cluster to the file or doc that owns it.
## A concrete Claude Code loop with /goal
The babysitter is a loop you wire up yourself; it also helps to see one that ships inside the agent. In Claude Code, the smallest complete loop is /goal: you hand it a verifiable end state, and it keeps taking turns until that state is true.
Here is an example of /goal used as an in-session command in Claude Code. You launch the session, then set the goal inside it:
```
$ claude # launch Claude Code
$ /goal tests in test/auth pass # set the goal inside the session
```
It is the same act, check, repeat shape from earlier, with the verifier built in.
At this point, it’s clear that a strong /goal reads less like a prompt and more like a contract. The good ones specify four things: the end state you want, the evidence that proves you reached it, the constraints the agent must not break getting there, and the budget of work it is allowed to spend. Leave any one of them vague, and the model fills the gap with the easiest reading: it stops early, takes a shortcut, or redefines success so the transcript looks done while the real system is broken.
- Set the condition. Type /goal plus a checkable end state, for example,/goal tests in test/auth pass. The first turn starts immediately.
- The agent works a turn. It edits, runs the tests, and surfaces the results in the session.
- An evaluator checks. A fast model reads the transcript and decides whether it is met or not met, so the agent is not grading its own work.
- Loop or finish. Not met means another turn with guidance; met means the goal clears itself and the run stops.
State carries across turns, so it does not quit early or drop a constraint partway through. A few controls keep it reliable:
- Make the check measurable. A test result, an exit code, a file count, or an empty queue. npm test exits 0 is a goal; "make it better" is not.
- Bound the run. Append something like "or stop after 20 turns" so a stuck loop halts instead of burning turns.
- Pair it with auto mode so that turns run unattended, and use /goal clear to abandon it early.
The evaluator step hides a useful subtlety: the checker does not have to be the same model as the coder. Once the loop has distinct roles (planner, executor, evaluator, vision reviewer), each can run on a different model, and choosing which model fills which role becomes an architecture decision rather than a single bet on one "best" coding agent. Some models plan better, some execute more cheaply, some judge a screenshot more accurately, and a good orchestrator lets you swap them per role instead of waiting for one vendor to win every category.
It works well for API migrations (move every call site until it compiles and tests pass), refactors (split a file until each module is under budget), issue backlogs (work a labeled queue until it is empty), and eval loops (tune a prompt until the score clears a threshold). /loop is the counterpart for work with no single finish line: instead of a completion condition it re-prompts on a schedule, which is how a loop like the PR babysitter keeps running.
## Running many loops unattended
A single /goal loop is one agent working toward one finish line. Running many unattended processes raises the stakes, because a loop is only as trustworthy as its ability to check its own work. Cherny's setup for running Opus autonomously for hours comes down to five steps:
1. Auto-approve permissions so the agent does not stop to ask on every tool call.
2. Use dynamic workflows (drop Ultracode into the prompt) to fan out across many agents instead of one serial thread.
3. Use /goal or /loop to keep it going. /goal sets a completion condition, /loop re-prompts on a schedule, and both carry state, so it does not quit early.
4. Run it in the cloud (desktop or mobile app) so the session survives when you close the laptop.
5. Give it a way to self-verify end-to-end. Claude in Chrome for web, a simulator MCP for mobile, and a live server for backend. This is the step that makes the other four safe.
The full sequence:
```
claude --permission-mode auto # 1 · no approval prompts
ultracode orchestrate sub-agents to ship the feature # 2 · fan out
/goal all tests pass and the demo loads clean # 3 · keep going
→ cloud / desktop app # 4 · close the laptop
→ chrome ext · sim MCP · live server # 5 · self-verify, then halt
```
## crabfleet: orchestration as a product
Orchestration is easier to picture with a concrete tool. Peter Steinberger's crabfleet, an OpenClaw project billed as "mission control for agent runs," is a loop packaged as a product, and its shape maps onto everything above.
- Work as cards on a board. Tasks are entered as cards built from a prompt, a GitHub issue, or a PR, then move through todo, running, human review, and done. That board is the loop's queue and its stop-and-report step, made visible.
- Durable runs, not fire-and-forget. Each run is a tracked attempt with heartbeats, so it keeps going when you look away and survives a closed laptop. You take over only when the runtime advertises that it supports handoff.
- Agents that spawn agents. A run can start child sessions, send messages, read transcripts, and update its own summary from inside a sandbox: on-disk memory and fan-out in one place, one author and many agents.
It runs on disposable cloud sandboxes with browser-based terminals, which is what makes walking away from an unattended run safe. The point is not the specific tool but that the loop has hardened into infrastructure: a queue, durable execution, fan-out, and a human-review gate are now things you configure rather than hand-script every time.
## Where the cost goes now
For two years, the cost question in AI coding was simple: which model, and how many tokens. Inside a loop, that instinct points at the wrong layer. The spend is no longer a single call but how many times the loop goes around, so a loop that retries six times before it converges costs six times as much as one that lands on the first pass, on the same model.
That changes what is worth optimizing:
- Iterations are the budget line, not tokens. A cheaper model that loops twice as often is not cheaper, so track cost per finished task, not cost per call.
- A weak verifier is the most expensive bug you can ship. If the check that decides "done" is loose, the loop either stops early on broken work or grinds on work that was already fine, and both waste whole iterations. Tighten this before anything else.
- Failing fast is a cost control. A loop with no cap on consecutive failures does not eventually succeed; it eventually drains the account, so the stop condition protects the bill as much as the codebase.
You used to tune the prompt; now you tune the loop, because that is where the cost accumulates.
## When not to loop
Loops pay off when a task repeats, and a machine can tell when it is done. Outside that, a loop only automates churn. Skip it in these cases:
- One-shot edits. If you can finish it in a single pass, a loop is pure overhead.
- Unscoped or exploratory work. "Figure out why users are churning" has no pass condition, so the loop never converges.
- Anything without a cheap automated check. If the only verifier is your own eyes, you are still inside the loop. Build the check first, or do the task by hand.
## What can go wrong
A loop that runs while you sleep also makes mistakes while you sleep, and the failure modes are predictable.
- The verification burden stays human. The loop writes faster than you can review, so if you stop reading the diffs, you have not removed the work, only deferred it.
- Comprehension gaps widen. Shipping code you did not write, faster than you can absorb it, erodes the model of your own system, and that debt comes due during the next incident.
- Silent drift on a loose check. A weak verifier lets wrong-but-passing work through on every iteration, so the loop looks productive while it digs a hole.
None of this is an argument against loops; it is why the engineer who designs the loop matters more, not less.
## How to build your own
1. Pick one repeatable task. Babysitting PRs, fixing CI, verifying deploys: start with routine work.
2. Scope it tight. "Fix the billing webhook validation, only touch app/api/billing and lib/billing," beats "fix the bug." A loose loop wanders.
3. Give it a budget and a stop condition. Max attempts, max runtime, max files, max spend, max consecutive failures. A loop running unattended is also a loop making mistakes unattended.
4. Add an independent verifier. A separate sub-agent grades the work, because the agent who wrote the code is the worst judge of whether it is done.
5. Run it on a cadence. /loop for an interval, cron for a schedule, hooks at lifecycle points, or GitHub Actions so it survives a closed laptop.
6. Keep memory on disk. The model forgets between runs, so state lives in markdown or a board, not in the context window.
The takeaway: the loop, not the model, is now the expensive and failure-prone part. Build it like someone who intends to stay the engineer responsible for the output, not just the person who starts the run.
If you see any errors or things that need further clarification, don’t be afraid to reach out.
## Other Useful References
- Addy Osmani (@addyosmani), on AI-assisted coding loops
- Matt Van Horn (@mvanhorn), "WTF Is a Loop?"
- Peter Steinberger (@steipete), on designing loops
- Boris Cherny (@bcherny), on running agents autonomously
## 相关链接
- [elvis](https://x.com/omarsar0)
- [@omarsar0](https://x.com/omarsar0)
- [56K](https://x.com/omarsar0/status/2068008743153832264/analytics)
- [students](https://academy.dair.ai/)
- [Autonomous Long-Running Coding Agents](https://academy.dair.ai/events/cmplo7v3b000e04l1pxprat4d)
- [@steipete](https://x.com/@steipete)
- [Original tweet](https://x.com/steipete/status/2063697162748260627)
- [@bcherny](https://x.com/@bcherny)
- [Original tweet](https://x.com/bcherny/status/2063792263067754658)
- [crabfleet](https://github.com/openclaw/crabfleet)
- [Addy Osmani (@addyosmani), on AI-assisted coding loops](https://x.com/addyosmani/status/2064127981161959567)
- [Matt Van Horn (@mvanhorn), "WTF Is a Loop?"](https://x.com/mvanhorn/status/2063865685558903149)
- [Peter Steinberger (@steipete), on designing loops](https://x.com/steipete/status/2063697162748260627)
- [Boris Cherny (@bcherny), on running agents autonomously](https://x.com/bcherny/status/2063792263067754658)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:31 AM · Jun 20, 2026](https://x.com/omarsar0/status/2068008743153832264)
- [56.4K Views](https://x.com/omarsar0/status/2068008743153832264/analytics)
- [View quotes](https://x.com/omarsar0/status/2068008743153832264/quotes)
---
*导出时间: 2026/6/20 10:18:09*
---
## 中文翻译
# 从提示词代理到循环工程
**作者**: elvis
**日期**: 2026-06-19T16:31:20.000Z
**来源**: [https://x.com/omarsar0/status/2068008743153832264](https://x.com/omarsar0/status/2068008743153832264)
---
AI 编程圈里流传着一个说法：别再给你的编程代理写提示词了，开始设计能帮你提示它们的循环吧。就像所有新事物一样，这话被人反复传颂，却鲜少有人解释。这是它的实践版本：什么是代理循环，为什么它很重要，以及它在生产环境中长什么样。
下方你可以读到一些我的想法（在 Claude 的帮助下写成的），源于我最近与一些学生、技术创始人、AI 工程师和初创公司进行的实验、研究和交流。
你也可以把我们最近关于“自主长期运行的编程代理”的直播作为了解这一切的一个很好的起点。
## 说法的由来
> “你不应该再为编程代理写提示词了。你应该设计能替你提示代理的循环。”—— Peter Steinberger (@steipete)，2026 年 6 月 7 日。220 万浏览量。[原始推文](https://x.com/steipete/status/2068008743153832264)
Claude Code 的创造者 Boris Cherny 从另一面表达了同样的观点。
> “我不再给 Claude 写提示词了。我有正在运行的循环。是它们在提示 Claude 并弄清楚该做什么。我的工作就是写这些循环。”—— Boris Cherny (@bcherny)。[原始推文](https://x.com/bcherny/status/2068008743153832264)
重点不在于提示词工程已死。有了循环工程，工作层级向上移动了一步：从编写代码转变为编写能编写代码的系统。在这条道路上走得最远的开发者报告说，他们曾连续几个月在不打开 IDE 的情况下合并了数百个 PR，每一行代码都由代理编写。
## 循环到底是什么
循环是你编写的一个小程序，它做四件事：
- 代替你向编程代理发出提示，
- 读取它生成的结果，
- 判断任务是否完成，
- 如果未完成，带着错误或下一步骤再次提示它。
你不再坐在循环里手动输入提示词；你编写循环，模型变成它调用的子程序。
形式总是相同的：设定目标，执行，检查，反馈错误，并重复直到检查通过或循环自行停止。
## “循环”至少意味着五件事
许多分歧源于人们用同一个词指代五种不同的概念。以下是这一演进过程，从旧到新。
- ReAct (2022)。最初的研究模式：推理，行动，观察，重复。
- AutoGPT (2023)。一个自我提示的目标循环，因不知道何时停止而臭名昭著。
- ralph 循环。在迭代之间刻意重置上下文，以免代理淹没在它自己的历史记录中。
- /loop 和 /goal。节奏和完成条件内置在代理中，状态在轮次间传递。
- 编排。一个作者分发许多代理，它们读取你的 GitHub、Slack 和聊天记录，并决定接下来要构建什么。
## 你实际组装的部件
上述演进解释了人们所说的循环的含义；而以下是循环的构建组件。同样的六个部分每次都会出现，而且现在大多数已作为内置功能集成在编码工具中，不再需要你自己维护自定义脚本。
- 触发器。某些能在你按下“开始”之外启动循环的东西：一个定时计划、一个 Webhook、一个文件变更、或一个打在 PR 上的标签。这正是区分真正的循环与你手动重复单次运行的关键。
- 隔离。每个代理一个私有检出，通常是 git worktree，这样两个同时运行的代理不会覆盖彼此的文件。一旦你运行超过一个代理，这就不再是可选项。
- 书面化的上下文。约定俗成的规范、构建步骤和项目特定规则被保存在代理每次运行时能读取的地方。如果跳过这一步，循环每一轮都要从头重新推导你的项目，并猜测缺失的部分。
- 触达你的工具。连接到问题追踪器、CI、数据库和聊天工具的连接器，这样循环可以打开 PR、链接工单并发布结果，而不是打印出一个修复方案然后等着你自己把剩下的工作做完。
- 第二个代理检查。一个独立的工作者负责给输出打分，它与生成输出的一方分开，因为一个模型审查它自己的工作时，几乎会放行所有东西。
- 磁盘上的状态。一个 markdown 文件、看板或队列：只要是对话记录之外的任何东西，用来记录什么是已完成的、什么是下一步。模型会在运行之间遗忘；文件不会。
组装好这六个部分，你就拥有了循环工程的一个良好起点。过去你需要手工构建一切；现在大多数都作为内置功能提供，这也是为什么这一模式从边缘技术转变为普遍用法。
## 一个具体的循环：PR 看护者
一个你现在就可以构建的具体例子：
- 触发器。每 15 分钟。
- 范围。标记为 agent-watch 的已开放 PR。
- 动作。如果 CI 因确定性的原因失败，尝试修复一次。如果主干分支有移动，变基一次。
- 预算。每个 PR 一次修复尝试，五分钟时限，十个文件变更上限。
- 停止条件。CI 变绿，或预算耗尽，然后停止并人工通知。
你回来时面对的是已合并的 PR，而不是一堆损坏的构建。同样的模式覆盖了大部分运维工作：
- CI 健康度。每 30 分钟，拉取失败的运行按错误签名聚类，这样十个由同一根本原因导致的红 PR 就变成了只需关注的一件事。
- 部署验证。推送之后，访问你的端点，确认返回 200 状态码和预期内容，在用户之前标记回归问题。
- 反馈聚类。每 30 分钟，从你的频道中拉取评论，将它们按主题分组，并将每个集群映射到负责的文件或文档。
## 一个使用 /goal 的具体 Claude Code 循环
看护者是一个你自己搭建的循环；看一看一个内置在代理中的循环也很有帮助。在 Claude Code 中，最小且完整的循环是 /goal：你交给它一个可验证的最终状态，它就会不断采取行动直到该状态为真。
这是一个在 Claude Code 中作为会话内命令使用 /goal 的例子。你启动会话，然后在其中设定目标：
```
$ claude # 启动 Claude Code
$ /goal tests in test/auth pass # 在会话中设定目标
```
这与前文提到的行动、检查、重复的形式相同，只是内置了验证器。
此时，很明显一个强有力的 /goal 读起来不像提示词，更像是一份合约。好的目标会指定四件事：你想要的最终状态，证明你已到达该状态的证据，代理在到达过程中绝不能打破的约束，以及它被允许花费的工作预算。如果其中任何一点模糊不清，模型就会用最简单的理解来填补：它会早早停下、走捷径，或者重新定义成功，让对话记录看起来完成了，但实际系统却是坏的。
- 设定条件。输入 /goal 加上一个可检查的最终状态，例如，/goal tests in test/auth pass。第一轮会立即开始。
- 代理工作一轮。它编辑代码，运行测试，并在会话中展示结果。
- 评估者检查。一个快速模型阅读对话记录并决定是否满足条件，这样代理就不是在给自己的工作打分。
- 循环或结束。不满足意味着在指导下再进行一轮；满足意味着目标自行清除并停止运行。
状态会在轮次间传递，所以它不会提前退出或在中途放弃约束。一些控制手段能保持其可靠性：
- 让检查可度量。一个测试结果、一个退出码、一个文件计数或一个空队列。npm test exits 0 是一个目标；“让它更好”则不是。
- 限制运行。追加诸如“或在 20 轮后停止”之类的指令，这样卡住的循环会停止，而不是空耗轮次。
- 将其与自动模式配对，使轮次无人值守运行，并使用 /goal clear 提前放弃它。
评估者这一步隐藏了一个有用的微妙之处：检查者不必与编写者使用同一个模型。一旦循环有了不同的角色（规划者、执行者、评估者、视觉审查者），每个角色都可以运行在不同的模型上，而选择哪个模型填充哪个角色就变成了一个架构决策，而不是在单一“最佳”编码代理上的一次性押注。有些模型更擅长规划，有些执行起来更便宜，有些判断截图更准确，而一个好的编排器能让你按角色交换它们，而不是等待某一家供应商在所有类别都胜出。
它非常适用于 API 迁移（移动每个调用点直到编译通过且测试通过）、重构（拆分文件直到每个模块都在预算之下）、积压问题（处理一个标记队列直到为空）以及评估循环（调整提示词直到分数超过阈值）。/loop 则是针对没有单一终点线的工作的对应方案：它没有完成条件，而是按计划重新提示，这就是像 PR 看护者这样的循环能持续运行的原因。
## 无人值守地运行多个循环
单个 /goal 循环是一个代理朝着一个终点线工作。运行多个无人值守过程提高了风险，因为循环的可信度取决于其检查自身工作的能力。Cherny 让 Opus 自主运行数小时的设置归结为五个步骤：
1. 自动批准权限，这样代理不会在每次工具调用时停下来询问。
2. 使用动态工作流（将 Ultracode 放入提示词中）分发到许多代理，而不是一个单线程序列。
3. 使用 /goal 或 /loop 让它持续运行。/goal 设定完成条件，/loop 按计划重新提示，且两者都携带状态，所以它不会提前退出。
4. 在云端运行（桌面或移动应用），这样当你合上笔记本时会话依然存活。
5. 给它一种端到端自验证的方法。用 Chrome 里的 Claude 处理网页，移动端用模拟器 MCP，后端用实时服务器。正是这一步让其他四步变得安全。
完整的序列：
```
claude --permission-mode auto # 1 · 无需批准提示
ultracode 编排子代理以交付该功能 # 2 · 分发
/goal all tests pass and the demo loads clean # 3 · 持续进行
→ cloud / desktop app # 4 · 合上笔记本
→ chrome ext · sim MCP · live server # 5 · 自验证，然后停止
```
## crabfleet：作为产品的编排
通过一个具体的工具更容易想象编排是什么样子的。Peter Steinberger 的 crabfleet，一个被称为“代理运行的任务控制中心”的 OpenClaw 项目，就是一个被封装成产品的循环，它的形态与上述一切相吻合。
- 工作以看板上的卡片形式存在。任务作为卡片输入，这些卡片构建自提示词、GitHub Issue 或 PR，然后穿过待办、运行中、人工审查和完成等状态。这个看板就是循环的队列及其停止并汇报的步骤，且是可见的。
- 持久化的运行，而非“发射后不管”。每次运行都是一个有心跳记录的受控尝试，所以当你转移注意力时它会继续，并在你合上笔记本后依然存活。只有当运行时环境明确支持交接时，你才会接手。
- 能生成代理的代理。一个运行可以启动子会话、发送消息、阅读对话记录，并在沙箱内部更新它自己的摘要：磁盘上的记忆和分发机制集中在一处，一个作者对应多个代理。
它在一次性的云端沙箱中运行，并配有基于浏览器的终端，这正是让无人值守运行变得安全的原因。重点不在于具体的工具，而在于循环已经固化为基础设施：队列、持久化执行、分发机制和人工审查闸门，现在都变成了你可以配置的东西，而不是每次都要手工编写的脚本。
## 现在成本在哪里
两年来，AI 编程的成本问题很简单：选哪个模型，以及多少 token。在循环内部，这种直觉指向了错误的层级。支出不再是单次调用，而是循环转了多少圈，所以一个在收敛前重试六次的循环，即使在同一个模型上，其成本也是一次就成功的循环的六倍。
这改变了值得优化的方向：
- 迭代次数是预算项，而不是 token 数。一个循环频率高两倍的更便宜的模型并不便宜，所以要追踪每个已完成任务的单位成本，而不是每次调用的成本。
- 软弱的验证器是你能引入的最昂贵的 bug。如果决定“完成”的检查很宽松，循环要么会在坏掉的工作上提前停止，要么会在已经没问题的工作上空转，这两种都会浪费整次迭代。在优化其他任何东西之前，先收紧这一步。
- 快速失败是一种成本控制。一个没有连续失败上限的循环不会最终成功；它最终会耗尽账户，所以停止条件不仅保护代码库，也保护账单。
过去你调优提示词；现在你调优循环，因为那才是成本累积的地方。
## 何时不应使用循环
当任务重复进行，且机器能判断何时完成时，循环才有回报。除此之外，循环只是自动化了空转。在这些情况下跳过它：
- 一次性编辑。如果你一次性就能完成，循环纯属额外开销。
- 范围不清或探索性工作。“弄清楚用户为什么流失”没有通过条件，所以循环永远无法收敛。
- 任何没有廉价自动检查手段的任务。如果唯一的验证器是你自己的眼睛，那么你依然身处循环之中。先构建检查机制，或者手工完成任务。
## 可能会出什么错
一个在你睡觉时运行的循环也会在你睡觉时犯错，而且这些失败模式是可预测的。
- 验证的负担依然由人承担。循环写代码的速度快过你审查的速度，所以如果你停止阅读 diff，你并没有消除工作，只是推迟了它。
- 理解鸿沟扩大。以快于你能吸收的速度交付你没有写的代码，会侵蚀你对自己系统的认知模型，而这笔债在下一次事故时就会到期。
- 宽松检查下的无声漂移。软弱的验证器会让每轮迭代中错误但通过的工作混进来，所以循环看起来很高产，实际上是在挖坑。
这些都不是反对循环的理由；它们恰恰说明了为什么设计循环的工程师更重要，而不是更不重要。
## 如何构建你自己的循环
1. 选择一个可重复的任务。看护 PR、修复 CI、验证部署：从日常工作开始。
2. 紧缩范围。“修复计费 webhook 验证，只触碰 app/api/billing 和 lib/billing，”胜过“修复 bug。”宽松的循环会跑偏。
3. 给它一个预算和停止条件。最大尝试次数、最大运行时间、最大文件数、最大花费、最大连续失败次数。无人值守运行的循环也是无人值守地犯错。
4. 添加一个独立的验证器。一个独立的子代理来评估工作，因为编写代码的代理是判断其是否完成的最糟糕的裁判。
5. 按节奏运行它。/loop 用于间隔，cron 用于定时计划，生命周期点的钩子，或 GitHub Actions，这样即使你合上笔记本它也能继续存活。
6. 将记忆保存在磁盘上。模型会在运行之间遗忘，所以状态存在于 markdown 或看板中，而非上下文窗口里。
要点在于：循环，而不是模型，现在才是昂贵且容易出问题的部分。要像一个打算继续对输出负责的工程师那样去构建它，而不仅仅是那个按下启动按钮的人。
如果你发现任何错误或需要进一步澄清的地方，请随时联系。
## 其他有用的参考资料
- Addy Osmani (@addyosmani)，关于 AI 辅助编码循环
- Matt Van Horn (@mvanhorn)，“WTF Is a Loop?”
- Peter Steinberger (@steipete)，关于设计循环
- Boris Cherny (@bcherny)，关于自主运行代理