别写提示词了，开始设计循环吧。
一个提示词只能换来一次回复。一个循环带来的是一套在你合上笔记本后仍在运行的系统。Anthropic 旗下 Claude Code 的负责人 Boris Cherny 点得很透：他早就不给 Claude 发提示词了，他手上跑着的是替 Claude 发提示词、并判断下一步该怎么做的循环。他的工作就是写循环。
Peter Steinberger 从另一个角度说了同样的话：你不应该再去给编码智能体写提示词了，你应该去设计那些替你发提示词的循环。发力点已经变了。关键不再是雕琢一条完美的消息，而是构建那套替你发送消息、审查结果、并决定下一步行动的系统。
一个循环就是一个递归目标。你定义一个目的，智能体朝这个目的迭代，循环一直运行直到满足一个真正的停止条件为止。智能体在每次运行之间会忘记一切，但循环不会。这一条事实就是整个架构的全部。
循环到底是什么
写出那篇为这种实践命名的文章的作者、Google 工程师 Addy Osmani，把一个循环拆成了六个部分：自动化（automations）、工作树（worktrees）、技能（skills）、连接器（connectors）、子智能体（sub-agents）和记忆（memory）。每个能正常工作的循环都是这六种元素的某种组合。
自动化让一个循环成为循环，而不是一次性运行。它可以是一个定时任务、一个 cron 作业、一个 webhook，或是 Claude Code 内部一个无需你输入就能触发的钩子。智能体在你开口之前就开始发现工作并对其进行分诊。
工作树让并行的智能体互不干扰。如果两个智能体同时触碰同一些文件，就会发生冲突。git worktrees 为每个智能体提供一份独立的代码仓库副本，供其独立工作。
技能是操作手册，智能体直接读取，而不是每次都要从头被告知。记忆是磁盘上的一个状态文件，通常是 markdown 格式，能在运行之间持久保留。智能体会忘记，但文件不会。
从一个触发器开始
每个循环都始于一个无需你操作就能触发的东西。最简单的版本是一个按计划运行 Claude Code prompt 的 cron 任务。下一个版本是一个钩子，即当特定事件（如一次提交或文件变化）发生时自动运行的脚本。
挑一个你当前手动完成的重复性任务，把触发器做成第一个积木。"每天早上 8 点，读取昨天的 CI 失败、已打开的 issue 和最近的提交，然后把发现写到一个 markdown 文件里。"这一个自动化本身就是一个完整且能运转的循环。
不要第一天就试图搭建完整的六部分系统。一个能写一个状态文件的自动化，已经比一百个精心编写的提示词更有杠杆效应，因为它在没有你的时候也能运行。
给循环一个记忆文件
创建一个 markdown 文件，命名为 STATE.md 或 PROGRESS.md，放在循环每次迭代都能读取和写入的地方。这个文件就是循环唯一的记忆。智能体从中断处继续所需的一切都在这里。
每次运行开始时，智能体先读取这个文件。每次运行结束时，它把完成的事情和接下来的步骤写回去。这就是 PROGRESS.md 模式，也是任何循环里最重要的一个文件。没有它，每次运行都从零开始，不管之前跑了多少轮。
用简单的章节来组织文件结构：上次运行做了什么、正在做什么、什么被阻塞了、下一步尝试什么。保持简短。一个需要智能体读 2000 行的记忆文件比没有记忆文件还要糟糕。
把写作者和检查者分开
用 Osmani 的话来说，写出代码的那个模型太温和了，舍不得给自己的作业打低分。一个既写又审查自身工作的智能体，会比自己应该承认的时候更频繁地把自己的活儿标记为完成。
解决办法是评估器-优化器模式（evaluator-optimizer pattern），这是 Anthropic 自己在关于构建有效智能体的工程文档里命名的：一个智能体生成，第二个智能体根据客观标准进行评判，循环反复直到检查通过。检查必须落在一个真实的东西上：测试套件、类型检查器、构建命令、代码检查工具。
如果第二个智能体只是被要求"检查一下"，没有客观的信号，那就只是多了一个乐观主义者。它往往更倾向于同意第一个智能体的结论。验证者需要一道硬性的门槛，而不是凭感觉。
用工作树隔离并行工作
一旦你有多个智能体对同一个代码库运行，隔离就不再是可选项了。执行 git worktree add ../agent-1-branch 给每个智能体一个自己的工作目录，指向它自己的分支。这样可以防止两个智能体同时编辑同一个文件并破坏彼此的更改。
一个典型的并行设置：一个子智能体探索并写计划，第二个子智能体在自己的工作树里按计划实施，第三个子智能体在另一个工作树中验证实施结果是否通过了测试。每个智能体永远只看到自己的副本。
这也是循环从"在后台跑一个任务"扩展到"同时运行一整条任务流水线"的方式——每个任务相互隔离，完成后都汇报给共享的记忆文件。
设定一个硬停止条件
没有真正退出条件的循环会悄悄地失败。工程师 Geoffrey Huntley 将此称为"拉尔夫·威格姆循环"：本应在完成时才发出完成信号的智能体提前发出了信号，循环以为自己完成了任务，实际上只做了一半。
你的停止条件必须能够被智能体自身声明之外的东西检查。"测试套件通过"、"构建成功"、"关联的工单移动到 Done 状态且 CI 通过"是真实的停止条件。"智能体说它完成了"则不是。
无论你的主停止条件是什么，都设置一个最大迭代次数作为后备。十到二十次迭代对大多数循环来说是合理的上限。如果循环达到了上限却仍未满足真实停止条件，它应该停止运行并标记为待审，而不是继续跑下去。
接入人工审查检查点
不是每个循环从一开始就要完全无人值守地运行。Boris Cherny 的框架使用了一个四级自主阶梯：第一级仅提供建议，第二级起草更改供人工应用，第三级应用低风险更改但在发布或合并前需人工批准，第四级全自动应用和完成并带有审计日志。
每个新循环都从第一或第二级开始。运行一周，阅读它的输出，纠正它犯的错误。一旦循环持续产生你无需修改就能批准的产出，就把它升到第三级。第四级是挣来的，不是默认的。
那些发现了什么的运行结果应当进入一个分诊收件箱或标记列表。那些什么都没发现的运行结果应当静默归档。你永远不应该只是为了确认无事发生而打开一个循环的输出。
关注 Token 成本
一次糟糕的迭代浪费一次提示词。一次糟糕的循环在无人看管下跑一晚就是一笔账单。智能体循环可能运行几十次甚至上百次迭代，而每次迭代都是一次完整的模型调用，附带着累积的对话历史。
在让任何循环无监督运行之前，手动跑三到五次迭代，检查每次迭代的 token 使用量。用这个数字乘以你的最大迭代次数，得到每次运行的最坏成本。再乘以自动化的触发频率，得到每日最坏成本。
为任何能够执行 shell 命令的循环构建一个命令白名单。只允许任务实际需要的具体命令，比如 npm、git、ls、cat。一个在无人循环内拥有不受限制 shell 访问权限的智能体，是把 token 成本问题变成安全问题的最快途径。
构建第二个循环时与第一个不同
你的第一个循环应该小而专一，并且高度受监督。你的第二个循环应该连接到第一个。这时自动化、技能和记忆开始发挥复合作用，而不仅仅是并行运行。
一个每日分诊循环把发现写到一个共享状态文件中。第二个循环也按计划运行，读取那个状态文件，挑选最高优先级的事项来执行。两个循环各自都不依赖对方才能工作，但合在一起就形成了一条流水线，把工作从"已发现"推向"进行中"，而你无需触碰任何一个。
这也是技能开始体现价值的时候。一旦你写好了一份关于循环应如何分诊 CI 失败文件的技能文件，未来所有涉及 CI 失败的循环都会读取这份技能，而不需要你重新解释一遍。这些循环并不仅仅是各自独立地运行，它们还在共享所学到的东西。
你的工作将如何转变
一旦几个循环开始运行，你的日常工作形态就会改变。你不再打开聊天窗口来提问，而是打开分诊收件箱来审查循环在一夜之间发现了什么。待办清单不再是静态的一堆任务，而变成了一组智能体、例程和循环，它们不断将想法转化为草稿、修复和Review。
这并不意味着你不用再决定什么是重要的。它意味着做决定这件事从每个任务的层面转移到了循环设计的层面。你写的提示词变少了，不是因为你在少做事，而是因为循环替你写了那些提示词，而你的注意力转到了那些真正需要人的部分：审查检查点、停止条件，以及下一个值得构建的循环。
