一个说法在 AI 编码圈子里流传：别再给你的 coding agent 写提示词了，开始设计循环来替你做这件事。和所有新事物一样，这个观点被反复提及却很少被解释清楚。这篇文章就是实践版：什么是 agent 循环，它为什么重要，以及它在生产环境中长什么样。
下面是我（在 Claude 的帮助下）从一些实验、研究以及与我们的学生、技术创始人、AI 工程师和初创公司的对话中总结出的一些思考。
你可能也会发现我们最近的直播"自主运行的长时间编码 Agent"是一个很好的起点。
这个说法的来源
"你不再应该给 coding agent 写提示词了。你应该设计循环来替你给 agent 写提示词。"Peter Steinberger (
@steipete ), 2026 年 6 月 7 日。220 万次浏览。
Claude Code 的创建者 Boris Cherny 从另一个角度也表达了同样的观点。
"我不再给 Claude 写提示词了。我有正在运行的循环。是它们在给 Claude 写提示词并决定接下来做什么。我的工作是写循环。"Boris Cherny (
@bcherny ).
重点不是说提示工程已死。通过循环工程，工作提升了一个层次：从编写代码转变为编写生成代码的系统。在这条路上走得最远的开发者报告说，他们几个月内提交了数百个 PR 而从未打开过 IDE，每一行代码都由 agent 编写。
循环到底是什么
循环是你写的一个小程序，它做四件事：
- 替你给 coding agent 写提示词，
- 读取它生成的内容，
- 判断它是否完成了任务，
- 如果没有，则带着错误或下一步指令再次给它写提示词。
你不再坐在循环内部手动输入提示词；你编写循环，模型变成它调用一个子程序。
它的形状始终如一：设定目标，执行，检查，把错误反馈回去，重复直到检查通过或循环自行停止。
"循环"至少指代五种不同东西
很多争论来自于人们用一个词指代五个不同的概念。下面是按时间先后顺序的演变过程。
- ReAct (2022 年)。 原始研究模式：推理、行动、观察、重复。
- AutoGPT (2023 年)。 一个自我提示的目标循环，以不知道何时停止而闻名。
- ralph 循环。 在每次迭代之间有意重置上下文，这样 agent 就不会淹没在自己的历史记录里。
- /loop 和 /goal。 节奏和完成条件内置在 agent 中，跨轮次携带状态。
- 编排。 一个作者扩展出多个 agent，读取你的 GitHub、Slack 和聊天记录，然后决定接下来要构建什么。
你需要组装的部件
上面的演变过程解释了人们用“循环”意指什么；而这是循环实际由什么构成的。每次都是同样的六个部件，现在大多数都内置在编码工具中，而不需要你自己维护自定义脚本。
- 触发器。 无需你按“开始”就能启动循环的东西：一个定时器、一个 webhook、一个文件变更、PR 上的一个标签。这是区分真正循环和你手动重复的单个运行的关键。
- 隔离。 每个 agent 有一个私有检出（通常是 git worktree），这样同时运行的两个 agent 不会互相覆盖文件。一旦你运行多个 agent，这就不是可选项了。
- 书面上下文。 约定、构建步骤和项目特定规则保存在 agent 每次运行时都能读取的地方。跳过这一步，循环每次都会从头推导你的项目并猜测缺失的信息。
- 对接你的工具。 连接到问题跟踪器、CI、数据库和聊天工具，这样循环可以打开 PR、关联工单并发布结果，而不是打印一个修复方案然后等着你手动完成剩余工作。
- 另一个 agent 做检查。 一个单独的工作者来评估输出，与生成它的 agent 分开，因为模型审阅自己的工作几乎会通过所有内容。
- 磁盘上的状态。 一个 Markdown 文件、一个项目或一个队列：任何存在于对话之外的东西，记录哪些已经完成、哪些是下一步。模型在运行之间会遗忘；但文件不会。
把以上六点组装起来，你就有了循环工程的一个良好起点。以前你需要手工构建一切；现在大多数都作为内置功能提供，这就是为什么这种模式已经从边缘技术变成了常见做法。
一个具体的循环：PR 保姆
一个你现在就能构建的具体例子：
- 触发器。 每 15 分钟。
- 范围。 标记为
agent-watch的开放 PR。 - 操作。 如果 CI 因一个确定性原因变成红色，尝试一次修复。如果主分支移动了，rebase 一次。
- 预算。 每个 PR 尝试一次修复，五分钟，最多修改十个文件。
- 停止条件。 CI 变绿，或预算耗尽，然后停止并通知人类。
你回来时看到的是已合并的 PR，而不是一堆失败的构建。同样的框架适用于大多数运维工作：
- CI 健康检查。 每 30 分钟拉取失败的运行并按错误签名聚类，这样十个红色 PR 共享一个根因，就变成一件事来处理。
- 部署验证。 推送后，请求你的端点，确认 200 状态码和预期内容，在用户发现之前标记回归问题。
- 反馈聚类。 每 30 分钟从你的渠道拉取评论，按主题分组，然后将每个聚类映射到负责它的文件或文档。
一个具体的带有 /goal 的 Claude Code 循环
“保姆”是你自己搭建的循环；了解一个内置于 agent 中的循环也有帮助。在 Claude Code 中，最小的完整循环是 /goal：你给它一个可验证的最终状态，它不断轮次直到该状态为真。
下面是一个在 Claude Code 中使用 /goal 作为会话内命令的例子。你启动会话，然后在会话内设置目标：
1$ claude # 启动 Claude Code2$ /goal tests in test/auth pass # 在会话内设置目标
这和前面说的“执行、检查、重复”形状是一样的，验证器内置在内。
到了这一步，很明显一个好的 /goal 读起来更像一份合同而不是一个提示词。好的目标会指定四件事：你想要的最终状态、证明你达到该状态的证据、agent 在达到目标时不得违反的约束，以及允许它花费的工作预算。如果其中任何一项含糊不清，模型就会用最容易理解的方式来填补空白：它提前停止、走捷径，或者重新定义成功，使得记录看起来完成了，而实际系统仍然是坏的。
- 设置条件。 输入
/goal加上一个可检查的最终状态，例如/goal tests in test/auth pass。第一个轮次立即开始。 - Agent 执行一个轮次。 它编辑代码、运行测试，并在会话中展示结果。
- 评估器进行检查。 一个快速模型读取对话记录并判断条件是否满足，这样 agent 就不会给自己的工作进行评分。
- 循环或结束。 条件未满足意味着带着指导意见进行下一轮；条件满足则目标自动清除，运行停止。
状态跨轮次传递，所以它不会提前退出或中途放弃某个约束。几个控制措施可以保证其可靠性：
- 让检查可衡量。 一个测试结果、退出码、文件数量或空队列。
npm test exits 0是一个目标；“让它变得更好”则不是。 - 限制运行。 加上“20 轮后停止”之类的内容，这样卡住的循环就会停止，而不是不断消耗轮次。
- 与自动模式配合，使轮次无人值守运行，并使用
/goal clear提前放弃。
评估器这一步隐藏了一个有用的细微之处：检查者不必与编码者是同一个模型。一旦循环有了不同的角色（规划者、执行者、评估者、视觉审查者），每个角色可以在不同的模型上运行，选择哪个模型扮演哪个角色就变成了一个架构决策，而不是把赌注押在一个“最佳” coding agent 上。有些模型规划得更好，有些执行成本更低，有些能更准确地判断截图，一个好的编排器让你可以按角色替换模型，而不是等待一家供应商在所有类别中胜出。
它在以下场景中效果很好：API 迁移（移动每个调用点直到编译通过且测试通过）、重构（拆分文件直到每个模块低于预算）、问题积压（处理标记的队列直到清空）以及评估循环（调整提示词直到分数超过阈值）。/loop 是用于没有单一终点的工作的对应物：它不是设置完成条件，而是按计划重新提示，这正是像 PR 保姆这样的循环持续运行的方式。
无人值守运行多个循环
单个 /goal 循环是一个 agent 朝着一个终点线工作。同时运行多个无人值守进程则会提高风险，因为循环的可靠性取决于它检查自己工作的能力。Cherny 设置 Opus 自主运行数小时的方案归结为五个步骤：
- 自动批准权限，这样 agent 不会在每次工具调用时停下来询问。
- 使用动态工作流（在提示词中加入 Ultracode）扩展到多个 agent，而不是单个串行线程。
- 使用 /goal 或 /loop 保持运行。
/goal设置完成条件，/loop按计划重新提示，两者都携带状态，所以不会提前退出。 - 在云端运行（桌面或移动应用），这样当你合上笔记本电脑时会话仍在继续。
- 给它一种端到端的自我验证方式。 网页用 Chrome 中的 Claude，移动端用模拟器 MCP，后端用实时服务器。这一步让前四步变得安全。
完整序列：
1claude --permission-mode auto # 1 · 无需批准提示2ultracode orchestrate sub-agents to ship the feature # 2 · 扩展到多个 agent3/goal all tests pass and the demo loads clean # 3 · 保持运行4→ cloud / desktop app # 4 · 合上笔记本电脑5→ chrome ext · sim MCP · live server # 5 · 自我验证，然后停止
crabfleet：作为产品的编排
借助具体工具，编排更容易理解。Peter Steinberger 的 crabfleet，一个 OpenClaw 项目，号称“agent 运行的指挥中心”，是一个打包成产品的循环，它的结构映射到了上述所有内容。
- 工作以卡片形式呈现在项目上。 任务由提示词、GitHub 问题或 PR 生成的卡片输入，然后经过待办、运行中、人工审查和完成。这个项目就是循环的队列及其停止与报告步骤，并且是可视化的。
- 持久的运行，发完即忘。 每次运行都是一个带有心跳的追踪尝试，所以当你移开视线时它继续运行，并且合上笔记本电脑后也不会消失。只有当运行时支持交接时，你才接管控制。
- 能产生子 agent 的 agent。 一次运行可以启动子会话、发送消息、读取记录，并在沙箱内更新自己的摘要：磁盘上的内存和扩展功能集中在一处，一个作者和多个 agent。
它在可丢弃的云端沙箱上运行，带有基于浏览器的终端，这使得离开无人值守的运行变得安全。重点不在于具体工具，而在于循环已经硬化成基础设施：一个队列、持久执行、扩展功能以及一个人工审查关卡，现在都是你配置的东西，而不是每次手工编写脚本。
现在成本花在哪里
两年来，AI 编码中的成本问题很简单：用哪个模型，用多少 token。在循环内部，这种直觉指向了错误的层次。花费不再是一次调用，而是循环绕了多少圈，所以一个在收敛前重试六次的循环，在相同模型下花费的是第一次就成功循环的六倍。
这改变了什么值得优化：
- 迭代次数是预算线，而不是 token。 一个更便宜但重试频率高一倍的模型并不更便宜，所以要追踪每个完成任务的花费，而不是每次调用的花费。
- 一个薄弱的验证器是你可能引入的最昂贵的 bug。 如果决定“完成”的检查很松散，循环要么在有问题的代码上提前停止，要么在已经没问题的代码上继续消耗，两者都浪费整轮迭代。优先收紧这一点，再做其他事。
- 快速失败就是成本控制。 一个没有连续失败上限的循环并不会最终成功；它最终会耗尽账户，所以停止条件既保护了代码库，也保护了账单。
以前你调优提示词；现在你调优循环，因为成本在那里累积。
什么时候不要用循环
当任务重复且机器能判断完成时，循环才值得投入。除此之外，循环只会自动化无意义的反复。在以下情况跳过它：
- 一次性编辑。 如果一次就能完成，循环纯粹是开销。
- 无范围或探索性工作。 “找出用户流失的原因”没有通过条件，所以循环永远不会收敛。
- 任何没有廉价自动化检查的事情。 如果唯一的验证者是你自己的眼睛，那你仍然在循环内部。先构建检查，否则就手动完成任务。
可能出什么问题
一个在你睡觉时运行的循环也会在你睡觉时犯错误，并且失败模式是可预测的。
- 验证负担仍由人承担。 循环写代码的速度比你能审查的快，所以如果你停止阅读 diff，你并没有移除工作，只是推迟了它。
- 理解差距扩大。 以超过你吸收速度的速度交付你未编写的代码，会侵蚀你对自身系统的认知，而这种债务将在下一次事故中到期。
- 松散检查下的静默漂移。 一个薄弱的验证器让错误但通过检查的工作每次迭代都通过，所以循环看起来多产，实际上在挖坑。
这些都不是反对循环的论据；这正是为什么设计循环的工程师更重要，而不是更不重要。
如何构建你自己的循环
- 选择一个可重复的任务。 PR 保姆、修复 CI、验证部署：从常规工作开始。
- 严格限定范围。 "修复计费 webhook 验证，只改动
app/api/billing和lib/billing" 优于 "修复 bug"。一个松散的循环会到处游荡。 - 给它设定预算和停止条件。 最大尝试次数、最大运行时间、最大文件数、最大花费、最大连续失败次数。一个无人值守运行的循环也会无人值守地犯错误。
- 添加一个独立的验证器。 一个单独的子 agent 来评估工作，因为编写代码的 agent 是最差的判断是否完成的裁判。
- 按节奏运行。 用
/loop设置间隔，用 cron 设置计划，在生命周期点设置钩子，或者用 GitHub Actions，这样即使合上笔记本电脑也能持续运行。 - 将状态保存在磁盘上。 模型在运行之间会遗忘，所以状态保存在 Markdown 或项目中，而不是在上下文窗口中。
结论：现在昂贵且容易出错的部分是循环，而不是模型。像一位打算始终对输出负责的工程师那样构建它，而不仅仅是启动运行的那个人。
如果你发现任何错误或需要进一步澄清的地方，请随时联系。
