# How to Create Loops with Claude
**作者**: MIKE
**日期**: 2026-06-15T06:03:00.000Z
**来源**: [https://x.com/mikenevermiss/status/2066401066518802637](https://x.com/mikenevermiss/status/2066401066518802637)
---
stop making prompts.
start designing loops.
a prompt gets you one response. a loop gets you a system that keeps working after you close the laptop. Boris Cherny, who runs Claude Code at Anthropic, put it plainly: he does not prompt Claude anymore, he has loops running that prompt Claude and figure out what to do. his job is to write loops.
Peter Steinberger said the same thing from a different angle: you should not be prompting coding agents anymore, you should be designing loops that prompt your agents. the leverage point has moved. it is no longer about crafting the perfect message. it is about building the system that sends messages for you, reviews the results, and decides what happens next.
a loop is a recursive goal. you define a purpose, the agent iterates against it, and the loop keeps running until a real stopping condition is met. the agent forgets everything between runs. the loop does not. that single fact is the entire architecture.
What a Loop Actually Is
--------------------------
Addy Osmani, a Google engineer who wrote the essay that named this practice, breaks a loop into six parts: automations, worktrees, skills, connectors, sub-agents, and memory. every working loop is some combination of these six.
automations are what make a loop a loop instead of a one-time run. this is a schedule, a cron job, a webhook, or a hook inside Claude Code that fires without you typing anything. the agent finds work and triages it before you ask.
worktrees keep parallel agents from stepping on each other. if two agents touch the same files at the same time, you get collisions. git worktrees give each agent its own isolated copy of the repo to work in.
skills are procedure manuals the agent reads instead of being told from scratch every time. memory is a state file on disk, usually markdown, that survives between runs. the agent forgets, the file does not.
Start With One Trigger
-------------------------
every loop starts with something that fires without you. the simplest version is a cron job that runs a Claude Code prompt on a schedule. the next version is a hook, a script that runs automatically when a specific event happens, like a commit or a file change.
pick one recurring task you currently do manually and turn the trigger into the first piece. "every morning at 8am, read yesterday's CI failures, open issues, and recent commits, and write findings to a markdown file." that single automation is a complete, working loop on its own.
do not try to build the full six-part system on day one. one automation that writes one state file is already more leverage than a hundred well-crafted prompts, because it runs without you.
Give the Loop a Memory File
------------------------------
create one markdown file, call it `STATE.md` or `PROGRESS.md`, and place it where every iteration of the loop can read and write it. this file is the loop's only memory. everything the agent needs to pick up where it left off goes here.
at the start of each run, the agent reads this file first. at the end of each run, it writes back what happened and what comes next. this is the PROGRESS.md pattern, and it is the single most important file in any loop. without it, every run starts from zero regardless of how many runs came before.
structure the file in plain sections: what was done last run, what is in progress, what is blocked, what to try next. keep it short. a memory file the agent has to read 2000 lines of is worse than no memory file at all.
Split the Writer From the Checker
------------------------------------
the model that wrote the code is, in Osmani's words, too nice grading its own homework. a single agent that writes and then reviews its own work will mark its own work as done more often than it should.
the fix is the evaluator-optimizer pattern, named in Anthropic's own engineering writeup on building effective agents: one agent generates, a second agent critiques against an objective standard, and the loop repeats until the check passes. the check has to fail on something real: a test suite, a type checker, a build command, a linter.
a second agent told to "review this" with no objective signal just adds a second optimist. it will agree with the first agent more often than not. the verifier needs a hard gate, not an opinion.
Isolate Parallel Work With Worktrees
---------------------------------------
once you are running more than one agent against the same codebase, isolation stops being optional. run `git worktree add ../agent-1-branch` to give each agent its own working directory pointed at its own branch. this prevents two agents from editing the same file at the same time and corrupting each other's changes.
a typical parallel setup: one sub-agent explores and writes a plan, a second sub-agent implements against that plan in its own worktree, a third sub-agent verifies the implementation against tests in a separate worktree. each agent only ever sees its own copy.
this is also where loops scale from "one task running in the background" to "an entire pipeline of tasks running at once," each isolated, each reporting back to the shared memory file when done.
Set a Hard Stop Condition
-----------------------------
a loop without a real exit condition fails quietly. engineer Geoffrey Huntley documented this as the "Ralph Wiggum loop": an agent meant to emit a completion signal only when finished emits it early, and the loop exits believing a half-done job is complete.
your stop condition needs to be checkable by something other than the agent's own claim. "the test suite passes," "the build succeeds," "the linked ticket moves to Done with a passing CI run" are real stop conditions. "the agent says it's finished" is not.
set a maximum iteration count as a backstop regardless of what your primary stop condition is. ten or twenty iterations is a reasonable ceiling for most loops. if the loop hits the ceiling without meeting the real stop condition, it should halt and flag for review, not keep running.
Wire In a Human Review Checkpoint
------------------------------------
not every loop should run fully unattended from day one. Boris Cherny's framing uses an autonomy ladder with four levels: level one suggests only, level two drafts changes for a human to apply, level three applies low-risk changes but requires human approval before publish or merge, level four applies and completes automatically with audit logs.
start every new loop at level one or two. run it for a week, read its output, and correct what it gets wrong. once the loop is consistently producing work you would approve without changes, move it to level three. level four is earned, not assumed.
the runs that find something should go to a triage inbox or a flagged list. the runs that find nothing should archive themselves silently. you should never have to open a loop's output to confirm that nothing happened.
Watch the Token Cost
------------------------
a single bad iteration is a wasted prompt. a single bad loop running unattended overnight is a bill. agentic loops can run for dozens or hundreds of iterations, and each iteration is a full model call with the accumulated conversation history attached.
before you let any loop run unsupervised, run it manually for three to five iterations and check the token usage per iteration. multiply that by your maximum iteration count to get a worst-case cost per run. multiply that by how often the automation fires to get a worst-case daily cost.
build a command allowlist for any loop that can execute shell commands. restrict it to the specific commands the task actually needs, things like `npm`, `git`, `ls`, `cat`. an agent with unrestricted shell access inside an unattended loop is the fastest way to turn a token-cost problem into a security problem.
Build the Second Loop Differently Than the First
----------------------------------------------------
your first loop should be small, single-purpose, and heavily supervised. your second loop should connect to the first. this is where automations, skills, and memory start compounding instead of just running in parallel.
a daily triage loop writes findings to a shared state file. a second loop, also on a schedule, reads that state file and picks the highest-priority item to act on. neither loop needs the other to function, but together they form a pipeline that moves work from "discovered" to "in progress" without you touching either one.
this is also when skills start paying off. once you have written a skill file for how your loop should triage CI failures, every future loop that touches CI failures reads that same skill instead of you re-explaining it. the loops do not just run independently, they share what they have learned.
The Shift in What Your Job Becomes
--------------------------------------
once a few loops are running, your daily work changes shape. you stop opening a chat window to ask a question and start opening a triage inbox to review what the loops found overnight. the to-do list stops being a static pile of tasks and becomes a set of agents, routines, and loops that keep converting ideas into drafts, fixes, and reviews.
this does not mean you stop deciding what matters. it means the deciding happens at the loop-design level instead of the per-task level. you are not writing fewer prompts because you are doing less. you are writing fewer prompts because the loops are writing them for you, and your attention moves to the parts that actually need a human: the review checkpoint, the stop condition, and the next loop worth building.
## 相关链接
- [MIKE](https://x.com/mikenevermiss)
- [@mikenevermiss](https://x.com/mikenevermiss)
- [256K](https://x.com/mikenevermiss/status/2066401066518802637/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [2:03 PM · Jun 15, 2026](https://x.com/mikenevermiss/status/2066401066518802637)
- [256.6K Views](https://x.com/mikenevermiss/status/2066401066518802637/analytics)
- [View quotes](https://x.com/mikenevermiss/status/2066401066518802637/quotes)
---
*导出时间: 2026/6/16 19:57:34*
---
## 中文翻译
# 如何使用 Claude 创建循环
**作者**: MIKE
**日期**: 2026-06-15T06:03:00.000Z
**来源**: [https://x.com/mikenevermiss/status/2066401066518802637](https://x.com/mikenevermiss/status/2066401066518802637)
---
别再写提示词了。
开始设计循环。
一次提示词只能换来一个回复。而一个循环能为你建立一个即使合上笔记本也能持续运行的系统。Anthropic 负责 Claude Code 项目的 Boris Cherny 说得很直白：他不再自己写提示词给 Claude，而是通过运行循环来向 Claude 发送提示词并弄清楚该做什么。他的工作就是编写这些循环。
Peter Steinberger 从另一个角度表达了同样的观点：你不应该再向代码代理发送提示词，你应该去设计那些能替你向代理发送提示词的循环。杠杆的支点已经转移。关键不再在于精心编写完美的信息，而在于构建一个能替你发送信息、审查结果并决定下一步做什么的系统。
循环是一个递归的目标。你定义一个目的，代理根据它进行迭代，循环会持续运行直到满足真正的停止条件。代理在两次运行之间会遗忘一切，但循环不会。这一单一事实构成了整个架构的基础。
循环究竟是什么
--------------------------
Addy Osmani 是一名谷歌工程师，他撰写了定义这一实践的文章。他将循环分为六个部分：自动化、工作树、技能、连接器、子代理和记忆。每一个能正常工作的循环都是这六部分的某种组合。
自动化是让循环之所以成为循环、而不是一次性运行的关键。它是一个日程表、一个 cron 定时任务、一个 webhook，或者是 Claude Code 内部的一个钩子，无需你输入任何内容即可触发。代理在你发出指令之前就能找到工作并对其进行分诊。
工作树能让并行的代理互不干扰。如果两个代理同时触碰同一个文件，就会发生冲突。git worktrees（工作树）能让每个代理获得代码仓库各自的独立副本来进行工作。
技能是代理阅读的操作手册，这样它就不需要每次都从头开始接受指令。记忆是磁盘上的一个状态文件，通常是 Markdown 格式，它在运行之间持久保存。代理会遗忘，文件不会。
从一个触发器开始
-------------------------
每个循环都始于某种无需你操作就能触发的东西。最简单的版本是一个按计划运行 Claude Code 提示词的 cron 定时任务。再进阶一点的版本是一个钩子，即当特定事件（如提交或文件变更）发生时自动运行的脚本。
挑一个你现在手动执行的重复性任务，把触发器作为第一个环节做出来。“每天早上 8 点，阅读昨天的 CI 失败记录、未解决的 Issue 和最近的提交，并将发现写入一个 Markdown 文件。”仅此一个自动化，本身就是一个完整且可独立运行的循环。
不要试图在第一天就建立全套的六部分系统。一个只需写入一个状态文件的自动化，就已经比一百个精心编写的提示词拥有更高的杠杆率，因为它无需你的介入即可运行。
给循环一个记忆文件
------------------------------
创建一个 Markdown 文件，命名为 `STATE.md` 或 `PROGRESS.md`，将其放在循环的每次迭代都能读写的地方。这个文件是循环唯一的记忆。代理为了能从上次中断的地方继续工作所需的一切信息都存放在这里。
在每次运行开始时，代理首先读取这个文件。在每次运行结束时，它写回发生了什么以及下一步要做什么。这就是 PROGRESS.md 模式，也是任何循环中最重要的单一文件。如果没有它，无论之前运行了多少次，每次运行都还是从零开始。
用清晰的版块来组织文件：上次做了什么、正在进行什么、有什么阻碍、下一步尝试什么。保持简短。如果一个记忆文件需要代理阅读 2000 行，那还不如没有记忆文件。
将编写者与检查者分离
------------------------------------
用 Osmani 的话来说，编写代码的模型在给自己的作业打分时总是太“宽容”。一个负责编写又负责审查自己工作的代理，往往会过早地将工作标记为完成。
解决之道是“评估者-优化者”模式，这在 Anthropic 关于构建高效代理的工程文档中也有提及：一个代理生成内容，第二个代理根据客观标准进行批判，然后循环重复直到检查通过。检查必须基于某种真实的失败：测试套件、类型检查器、构建命令或代码检查工具。
如果只让第二个代理去“审查这个”，而不提供客观数据，那只是增加了一个乐天派。它大概率会附和第一个代理。验证者需要一个硬性门槛，而不是一种观点。
使用工作树隔离并行工作
---------------------------------------
一旦你针对同一个代码库运行不止一个代理，隔离就不再是可选项。运行 `git worktree add ../agent-1-branch`，给每个代理分配一个指向其独立分支的工作目录。这能防止两个代理同时编辑同一个文件，从而破坏对方的更改。
典型的并行设置：一个子代理负责探索并制定计划，第二个子代理在自己的工作树中根据该计划实施，第三个子代理在单独的工作树中通过测试验证实施结果。每个代理只能看到它自己的那份副本。
这也是循环从“后台运行一个任务”扩展到“同时运行整个任务管道”的阶段，每个任务相互隔离，并在完成后向共享的记忆文件汇报。
设定硬性停止条件
-----------------------------
一个没有真正退出条件的循环会悄无声息地失败。工程师 Geoffrey Huntley 将此记录为“Ralph Wiggum 循环”：一个本应仅在完成时才发出完成信号的代理提前发出了信号，导致循环误以为一项只完成了一半的工作已做毕而退出。
你的停止条件必须能被代理自身声明之外的手段所验证。“测试套件通过”、“构建成功”、“关联的工单移动到完成状态且 CI 运行通过”才是真正的停止条件。“代理说它完成了”则不是。
无论你的主要停止条件是什么，都要设置一个最大迭代次数作为底线。对于大多数循环来说，10 到 20 次是一个合理的上限。如果循环触达上限仍未满足真正的停止条件，它应该暂停并标记等待审查，而不是继续运行。
接入人工审查检查点
------------------------------------
并非每个循环从第一天起就应该完全无人值守运行。Boris Cherny 的框架使用了一个包含四个等级的“自主阶梯”：第一级仅提出建议，第二级起草变更由人来应用，第三级应用低风险变更但在发布或合并前需人工批准，第四级自动应用并完成所有操作，附带审计日志。
每个新循环都从第一级或第二级开始。让它运行一周，阅读其输出，并修正它出错的地方。一旦循环能稳定产出你无需修改即可批准的工作，再将它提升至第三级。第四级是赢来的，不是假设的。
发现了问题的运行应该进入分诊收件箱或标记列表。什么都没发现的运行应该自动归档。你绝不应该为了确认“无事发生”而去打开循环的输出。
关注 Token 成本
------------------------
一次糟糕的迭代只是浪费了一个提示词。一个整晚无人值守运行的糟糕循环则是一笔账单。代理式循环可以运行几十甚至上百次迭代，而每次迭代都是一次完整的模型调用，附带着累积的对话历史。
在让任何循环无人监督运行之前，先手动运行 3 到 5 次迭代，并检查每次迭代的 Token 用量。乘以你的最大迭代次数，得出每次运行的最坏情况成本。再乘以自动化触发的频率，得出每天的最坏情况成本。
为任何能执行 Shell 命令的循环构建一个命令白名单。将其限制为任务真正需要的特定命令，比如 `npm`、`git`、`ls`、`cat`。在一个无人值守的循环中，让代理拥有不受限的 Shell 访问权限，是让 Token 成本问题瞬间变成安全问题的最快途径。
以不同的方式构建第二个循环
----------------------------------------------------
你的第一个循环应该是小型的、单目标的、且受到严密监督的。你的第二个循环应该与第一个连接起来。这时候，自动化、技能和记忆开始产生复利效应，而不仅仅是并行运行。
一个每日分诊循环将发现写入共享状态文件。第二个循环，同样按计划运行，读取该状态文件并挑选优先级最高的项目进行处理。两个循环都不需要对方才能运行，但合在一起，它们构成了一条管道，将工作从“发现”转移到“进行中”，全程无需你触碰任何一个。
这也是技能开始显现价值的时候。一旦你为循环如何分诊 CI 失败编写了一个技能文件，未来所有涉及 CI 失败的循环都会读取同一个技能文件，而无需你重新解释。这些循环不仅仅是独立运行，它们共享所学到的知识。
你的工作性质将发生转变
--------------------------------------
一旦几个循环开始运行，你的日常工作就会改变形态。你不再是打开聊天窗口去提问，而是打开分诊收件箱去审查循环一夜之间发现了什么。待办事项不再是一个静态的任务堆，而变成了一组代理、例程和循环，它们不断将想法转化为草稿、修复方案和审查意见。
这并不意味着你不再决定什么才是重要的。这意味着决策发生在循环设计层面，而不是单项任务层面。你写的提示词变少，并不是因为你做得少了。你写的提示词变少，是因为循环正在替你写，而你的注意力转移到了真正需要人类介入的环节：审查检查点、停止条件，以及下一个值得构建的循环。
## 相关链接
- [MIKE](https://x.com/mikenevermiss)
- [@mikenevermiss](https://x.com/mikenevermiss)
- [256K](https://x.com/mikenevermiss/status/2066401066518802637/analytics)
- [升级至高级版](https://x.com/i/premium_sign_up)
- [2026年6月15日 下午 2:03](https://x.com/mikenevermiss/status/2066401066518802637)
- [25.66万 次查看](https://x.com/mikenevermiss/status/2066401066518802637/analytics)
- [查看引用](https://x.com/mikenevermiss/status/2066401066518802637/quotes)
---
*导出时间: 2026/6/16 19:57:34*