如何用 Claude 构建循环

别再写 prompt 了。 开始设计循环。

一个 prompt 只能换来一次回应。而一个循环，能让你合上电脑后，系统依然在持续运转。Anthropic 公司 Claude Code 的负责人 Boris Cherny 说得直白：他现在不再给 Claude 写 prompt 了，他运行着一些循环，这些循环会自己去调用 Claude 并决定下一步做什么。他的工作是写循环。

Peter Steinberger 从另一个角度说了同样的话：你不再应该给编码 agent 写 prompt，你应该设计循环，让循环去调用你的 agent。杠杆点已经转移了。不再是雕琢完美的消息。而是构建一个系统，让它替你发送消息、审查结果，并决定接下来该做什么。

循环就是一个递归的目标。你定义一个目的，agent 围绕它迭代，循环持续运行，直到真正满足停止条件。agent 每次运行之间会忘记一切。循环不会。仅这一点，就构成了整个架构。

循环究竟是什么

Google 工程师 Addy Osmani 撰文命名了这个实践，他将循环拆解为六个部分：自动化、工作树、技能、连接器、子代理和记忆。任何一个能正常工作的循环，都是这六种元素的组合。

• 自动化：这是让循环成为循环而非一次性运行的关键。可以是一个计划任务、一个 cron 作业、一个 webhook，或 Claude Code 内部无需你输入任何内容即触发的钩子。agent 会在你提问之前就发现工作并对其进行分类。 • 工作树：防止并行 agent 互相干扰。如果两个 agent 同时触碰同一个文件，就会产生冲突。Git 工作树为每个 agent 提供仓库的独立副本，供其独立工作。 • 技能：是 agent 读取的操作手册，而不是每次都要从零开始解释。 • 记忆：是磁盘上的状态文件，通常是 markdown 格式，在每次运行之间持久存在。agent 会忘记，文件不会。

从一个触发器开始

每个循环都始于一个无需你干预就能触发的事件。最简单的版本是一个 cron 作业，按计划运行一个 Claude Code prompt。下一个版本是一个钩子，当特定事件（如提交或文件变更）发生时自动运行的脚本。

选一个你当前手动执行的周期性任务，把触发器作为第一个组件构建起来。“每天早上 8 点，读取昨天的 CI 失败项、打开的问题和最近的提交，并将发现写入一个 markdown 文件。” 仅这一个自动化本身就是一个完整、可运行的循环。

不要试图在第一天就搭建完整的六部分系统。一个能写入状态文件的自动化，已经比一百个精心编写的 prompt 更有杠杆效应——因为它无需你介入即可运行。

给循环一个记忆文件

创建一个 markdown 文件，命名为 STATE.md 或 PROGRESS.md，放在每次迭代都能读写它的位置。这个文件是循环唯一的记忆。agent 需要在此处获取的所有信息以继续先前的工作。

每次运行时，agent 首先读取这个文件。每次运行结束时，它写回发生了什么以及下一步该做什么。这就是 PROGRESS.md 模式，是任何循环中最重要的一份文件。没有它，无论之前运行了多少次，每次运行都从零开始。

用平实的章节组织文件结构：上次运行完成了什么、正在进行什么、什么被阻塞了、下次要尝试什么。保持简短。一个 agent 不得不读取 2000 行的记忆文件，比完全没有记忆文件更糟糕。

把编写者和检查者分开

按照 Osmani 的说法，编写代码的模型在给自己批改作业时通常会过于仁慈。一个既编写又审查自己工作的 agent，标注“完成“的频率会高于应有的标准。

解决方法是评估器-优化器模式，在 Anthropic 自己关于构建高效 agent 的工程文档中命名：一个 agent 生成输出，第二个 agent 根据客观标准进行评判，循环重复直到检查通过。检查必须能在某些真实的东西上失败：测试套件、类型检查器、构建命令、linter。

如果第二个 agent 只是在没有客观信号的情况下被告知“审查一下“，那就只是多了一个乐观主义者。它大概率会同意第一个 agent 的结论。验证者需要一个硬性关卡，而不是一个主观意见。

用工作树隔离并行工作

一旦你针对同一个代码库运行多个 agent，隔离就不再是可选项。执行 git worktree add ../agent-1-branch，为每个 agent 提供指向其自己分支的独立工作目录。这可以防止两个 agent 同时编辑同一个文件而破坏彼此的更改。

一个典型的并行设置：一个子 agent 进行探索并编写计划，第二个子 agent 在自己的工作树中针对该计划实现代码，第三个子 agent 在另一个工作树中通过测试验证实现。每个 agent 只看到自己的副本。

这也是循环从“在后台运行一个任务“扩展到“同时运行一整套任务管道“的关键点：每个任务相互隔离，完成后都向共享记忆文件报告。

设定硬性的停止条件

没有真正退出条件的循环会悄无声息地失败。工程师 Geoffrey Huntley 将此记录为“Ralph Wiggum 循环“：一个本应在完成任务时才发出完成信号的 agent，却过早地发出信号，导致循环以为一项完成了一半的工作已经完成。

你的停止条件必须可以由 agent 自身声称之外的其他事物来检查。“测试套件通过”、“构建成功”、“关联的工单移动到 Done 状态且 CI 运行通过”——这些是真实的停止条件。“agent 说它完成了“不是真实的停止条件。

无论你的主要停止条件是什么，都要设置最大迭代次数作为后备保障。对大多数循环来说，十次或二十次迭代是合理的上限。如果循环达到上限而仍未满足真实停止条件，它应该停止并标记为需要审查，而不是继续运行。

接入人工审查检查点

并非每个循环一开始就要完全无人值守运行。Boris Cherny 的框架使用了一个四层级的自主阶梯：第一层只提供建议，第二层生成更改草稿供人类应用，第三层应用低风险更改但需要人类批准后才能发布或合并，第四层自动应用并完成，同时保留审计日志。

从第一层或第二层开始每个新循环。运行一周，阅读其输出，纠正其错误。一旦循环能持续产出你无需修改即可批准的工作，再将其提升到第三层。第四层是赢得的，而非预设的。

那些发现某些内容的运行结果应放入分类收件箱或标记列表。什么都没发现的运行应自动归档，保持安静。你永远不应该为了确认“什么都没发生“而去打开循环的输出。

关注 Token 成本

一次糟糕的迭代只是一个被浪费的 prompt。而一个糟糕的循环在无人值守时运行一整晚，就是一笔账单。Agent 式循环可以运行数十次甚至数百次迭代，每次迭代都是一次完整的模型调用，并附加累积的对话历史。

在让任何循环无人监督运行之前，手动运行三到五次迭代，检查每次迭代的 token 消耗。将其乘以你的最大迭代次数，得出每次运行的最坏情况成本。再将其乘以自动触发的频率，得出最坏情况的日成本。

为任何能够执行 shell 命令的循环构建一个命令白名单。将命令限制为任务实际需要的特定命令，如 npm、git、ls、cat。在无人看管的循环中，一个拥有不受限制 shell 访问权限的 agent，是将 token 成本问题转化为安全问题的最快途径。

构建第二个循环时，要不同于第一个

你的第一个循环应该规模小、目的单一、且受到高度监督。你的第二个循环应该连接到第一个。这时，自动化、技能和记忆开始产生复合效应，而不仅仅是并行运行。

一个每日分类循环将发现写入共享状态文件。第二个循环，也按计划运行，读取该状态文件并选出最高优先级的项目来执行。两个循环不需要彼此就能运行，但合在一起形成了一个管道，将工作从“已发现“推向“进行中“，而无需你触碰任何一个。

这也是技能开始产生回报的时候。一旦你编写了一个技能文件，说明循环应如何对 CI 失败进行分类，那么未来每一个处理 CI 失败的循环都会读取相同的技能，而无需你重新解释。循环不仅仅是独立运行，它们会分享所学到的东西。

你的工作角色将如何转变

一旦有几个循环在运行，你的日常工作形态就会改变。你不再打开聊天窗口提问，而是打开一个分类收件箱，查看循环在夜间发现了什么。待办事项列表不再是一堆静态任务，而变成了一组 agent、例程和循环，持续将想法转化为草稿、修复和审查。

这并不意味着你不再决定什么重要。而是意味着决策发生在循环设计的层面，而不是每个任务的层面。你写更少的 prompt，不是因为你做得少了。而是因为循环在替你写 prompt，而你的注意力转移到了那些真正需要人类参与的部分：审查检查点、停止条件，以及下一个值得构建的循环。