从提示智能体到循环工程

AI编程圈子里流传着一个说法：别再给你的编程智能体写提示了，开始设计能替你提示它们的循环。和所有新事物一样，这个观点被频繁重复，却很少被解释清楚。下面就是实用版本：什么是智能体循环，它为什么重要，以及它在生产环境中长什么样。

下面你可以读到一些我的想法（在 Claude 的帮助下写成），这些想法来自我与部分学生、技术创始人、AI工程师和初创公司进行的一些实验、研究和交流。

你可能会发现我们最近关于“自主长时间运行编程智能体“的直播课程是所有这一切的一个不错的起点。

这个说法的来源

“你不应该再给编程智能体写提示了。你应该设计循环来替你提示智能体。“Peter Steinberger (@steipete)，2026年6月7日。220万次观看。原始推文

Claude Code 的创建者 Boris Cherny 从另一个角度也表达了同样的观点。

“我不再给 Claude 写提示了。我有正在运行的循环。是它们负责提示 Claude 并找出该做什么。我的工作是写循环。“Boris Cherny (@bcherny)。原始推文

重点不在于提示工程已经死亡。通过循环工程，工作上升了一个层级，从写代码变成了写生成代码的系统。走在这条路最前沿的开发者报告说，他们几个月内提交了数百个 PR，却从未打开过 IDE，每一行代码都由智能体编写。

循环到底是什么

循环是你编写的一个小程序，它做四件事：

• 替你提示编程智能体，

• 读取它生成的内容，

• 判断它是否完成了任务，

• 如果没有，则带上错误信息或下一步指令再次提示它。

你不再坐在循环里手动输入提示；你编写循环，模型就变成了它所调用的一个子程序。

其形态始终如一：设定目标，行动，检查，将错误反馈回去，重复直到检查通过或循环自行停止。

“循环“至少意味着五种东西

很多分歧来自于人们用一个词来表达五种不同的概念。以下是其演进过程，从最古老到最新。

• ReAct (2022)。 原始研究模式：推理，行动，观察，重复。

• AutoGPT (2023)。 一种自我提示的目标循环，因不知道何时停止而臭名昭著。

• ralph 循环。 在迭代之间有目的地重置上下文，以免智能体被自己的历史记录淹没。

• /loop 和 /goal。 节奏和完成条件被内建到智能体中，跨轮次携带状态。

• 编排。 一个作者派生出多个智能体，它们读取你的 GitHub、Slack 和聊天记录，并决定下一步该构建什么。

你实际组装的零件

演进过程解释了人们所说的“循环“是什么；以下则是循环的构建材料。同样的六个部分每次都出现，而且现在大多数都作为内置功能包含在编码工具中，而不是需要你自己维护的自定义脚本。

• 触发器。 在无需你按“开始“的情况下启动循环的东西：一个计划任务、一个 webhook、一个文件变化、一个落在 PR 上的标签。这是区分真正循环和手工重复的单独运行的关键。

• 隔离。 每个智能体拥有一个私有检出目录，通常是一个 git worktree，这样同时运行的两个智能体不会互相覆盖文件。一旦你运行超过一个，这就成了必需品。

• 写下来的上下文。 约定、构建步骤和项目特定规则被保存在智能体每次运行时都能读取的地方。跳过这一步，循环就会每次从头推导你的项目，并猜测其中的空白。

• 对你工具的访问。 与问题追踪器、CI、数据库和聊天的连接器，这样循环可以打开 PR、关联工单、发布结果，而不是打印一个修复方案等你手动完成剩下的工作。

• 另一个智能体进行检查。 一个独立的工作线程来评估输出，与产生该输出的线程分开，因为模型审查自己的工作时几乎会放过所有东西。

• 磁盘上的状态。 一个 markdown 文件、一个看板或一个队列：任何存在于对话之外的东西，记录已完成和下一步要做什么。模型会在两次运行之间遗忘；文件不会。

将这六部分组装起来，你就有了循环工程的一个良好起点。过去你需要手工构建所有东西；现在大多数都作为内置功能提供，这就是为什么这种模式已经从边缘技术转变为常见用法。

一个具体的循环：PR 保姆

一个你今天就能构建的具体例子：

• 触发器。 每 15 分钟一次。

• 范围。 标记了 agent-watch 标签的开放 PR。

• 行动。 如果 CI 因为一个确定性的原因变红，尝试一次修复。如果主分支有移动，rebase 一次。

• 预算。 每个 PR 一次修复尝试，五分钟，十个文件改动。

• 停止条件。 CI 变绿，或预算耗尽，然后停止并通知人类。

你最终得到的是合并的 PR，而不是积压的失败构建。同样的形态覆盖了大多数运维工作：

• CI 健康检查。 每 30 分钟，拉取失败的运行并按特征聚类，这样十个红色 PR 如果只有一个根本原因，就变成一个需要关注的事情。

• 部署验证。 推送后，访问你的端点，确认 200 状态码和预期内容，并在用户之前标记回归。

• 反馈聚类。 每 30 分钟，从你的渠道拉取评论，按主题分组，并将每个聚类映射到拥有该问题的文件或文档。

一个具体的 Claude Code 循环，使用 /goal

PR 保姆是你自己搭建的循环；我们也可以看看一个内建在智能体内部的循环。在 Claude Code 中，最小的完整循环是 /goal：你给它一个可验证的最终状态，它会不断轮次执行，直到该状态为真。

以下是一个在 Claude Code 中作为会话内命令使用 /goal 的例子。你启动会话，然后在会话内设置目标：

它与前面提到的“行动，检查，重复“形状相同，并内建了验证器。

到这一点上，很明显，一个好的 /goal 读起来更像一份契约，而不是一段提示。好的目标指定了四件事：你想要的最终状态，证明你已达成目标的证据，智能体在达成目标过程中不能违反的约束，以及它允许花费的工作预算。任何一个模糊不清，模型就会用最简单的解读来填补空白：它可能提前停止、走捷径，或者重新定义成功，使得对话记录看起来完成了，而实际系统已经崩溃。

• 设置条件。 输入 /goal 加上一个可检查的最终状态，例如 /goal tests in test/auth pass。第一轮立即开始。

• 智能体执行一轮。 它编辑代码、运行测试，并将结果呈现在会话中。

• 一个评估器进行检查。 一个快速的模型读取对话记录，并判断目标是“已达成“还是“未达成“，这样智能体就不再是给自己的作业打分。

• 循环或完成。 未达成意味着进入下一轮并附带指导；已达成意味着目标自行清除，运行停止。

状态跨轮次携带，所以它不会中途退出或在半路上丢弃某个约束。一些控制措施能保证其可靠性：

• 让检查可衡量。 一个测试结果、一个退出码、一个文件计数或一个空队列。npm test exits 0 是一个目标；“让它变得更好“不是。

• 限定运行范围。 附加一些内容，比如“或在 20 轮后停止“，这样卡住的循环就会停止，而不是一直消耗轮次。

• 与自动模式配合使用，这样轮次可以无人值守地运行，并使用 /goal clear 来提前放弃它。

评估器步骤隐藏了一个有用的微妙之处：检查者不必是与编码者相同的模型。一旦循环有了不同的角色（规划者、执行者、评估者、视觉审查者），每个角色都可以在不同的模型上运行，而选择哪个模型扮演哪个角色就变成了一个架构决策，而不是对单个“最佳“编程智能体的单一押注。有些模型更善于规划，有些执行成本更低，有些判断截图更准确，一个好的编排器让你可以为每个角色更换模型，而不是等待一个厂商赢得所有类别。

它非常适合 API 迁移（移动所有调用点直到编译通过且测试通过）、重构（拆分文件直到每个模块低于预算）、问题积压（处理一个标记的队列直到为空）以及评估循环（调整提示直到分数超过阈值）。/loop 则是针对那些没有单一终点线的工作的对应命令：它不设定完成条件，而是按计划重新提示，这正是像 PR 保姆这样的循环能够持续运行的方式。

无人值守地运行多个循环

单个 /goal 循环是一个智能体朝着一个终点线工作。无人值守地运行多个进程会提高风险，因为一个循环的可信度完全取决于它检查自己工作的能力。Cherny 为让 Opus 自主运行数小时而搭建的配置归结为五个步骤：

• 自动批准权限，这样智能体就不会在每个工具调用时都停下来询问。

• 使用动态工作流（将 Ultracode 放入提示中），以派生出多个智能体，而不是一个串行线程。

• 使用 /goal 或 /loop 来让它持续运行。/goal 设置一个完成条件，/loop 按计划重新提示，两者都携带状态，所以它不会提前退出。

• 在云端运行它（桌面或移动应用），这样即使你合上笔记本电脑，会话也能继续存活。

• 给它一种端到端的自我验证方式。 Claude 在 Chrome 中用于 Web，一个模拟器 MCP 用于移动端，一个实时服务器用于后端。这是让其他四个步骤变得安全的步骤。

完整顺序：

crabfleet：作为产品的编排

用一个具体工具来理解编排会更直观。Peter Steinberger 的 crabfleet，一个被描述为“智能体运行的任务控制中心“的 OpenClaw 项目，是一个被包装成产品的循环，其形态映射到上述所有内容。

• 工作表现为看板上的卡片。 任务以卡片形式输入，由一段提示、一个 GitHub 问题或一个 PR 构建而成，然后依次经过待办、运行中、人工审核和已完成。这个看板就是循环的队列及其停止和报告步骤，并且是可视化的。

• 持久化运行，而非即抛即忘。 每次运行都是一个带有心跳的可追踪尝试，所以当你移开视线时它会继续运行，并且在合上笔记本电脑后依然存活。只有当运行时支持切换时，你才接管控制。

• 能生成智能体的智能体。 一次运行可以从沙箱内部启动子会话、发送消息、读取对话记录并更新自己的摘要：磁盘上的记忆和派生子节点合二为一，一个作者，多个智能体。

它运行在可随时丢弃的云端沙箱上，并带有基于浏览器的终端，这正是让你可以安心离开一个无人值守运行的关键。重点不在于特定的工具，而在于循环已经固化为基础设施：一个队列、持久化执行、派生子节点和一个人工审核门控，现在都是你可以配置的东西，而不是每次都需要手工编写脚本。

成本现在花在了哪里

两年来，AI编程中的成本问题很简单：哪个模型，以及多少个 token。在一个循环内部，这种直觉指向了错误的层级。花费不再是一次单一的调用，而是循环要绕多少圈，所以一个循环在收敛之前重试了六次，其成本是首次就成功的循环的六倍，即便使用的是同一个模型。

这改变了值得优化的方向：

• 迭代是预算线，而不是 token。 一个更便宜的模型如果循环次数加倍，实际上并不便宜，所以要追踪每个已完成任务的总成本，而不是每次调用的成本。

• 一个弱的验证器是你可能引入的最昂贵的 bug。 如果判断“完成“的检查很宽松，循环要么在有缺陷的工作上提前停止，要么在已经没问题的工作上继续消耗资源，两者都浪费了完整的迭代。在优化其他任何东西之前，先收紧这个检查。

• 快速失败是一种成本控制。 一个对连续失败次数没有限制的循环，最终不会成功；它最终会耗尽你的账户资金，所以停止条件保护你的账单，就像保护你的代码库一样。

过去你调整提示；现在你调整循环，因为那是成本累积的地方。

何时不应使用循环

当一个任务重复出现，并且机器能判断它是否完成时，循环才有意义。除此之外，循环只会自动化一种空转。在以下情况下跳过它：

• 一次性编辑。 如果你能一次完成它，循环纯粹是额外开销。

• 无范围或探索性工作。 “找出用户流失的原因“没有通过条件，所以循环永远不会收敛。

• 任何没有廉价自动化检查的工作。 如果唯一的验证者是你自己的眼睛，那你仍然处于循环之中。先构建检查，或者手工作业。

可能出现的问题

一个在你睡觉时运行的循环，也会在你睡觉时犯错误，其失败模式是可以预测的。

• 验证负担仍然落在人类身上。 循环写代码的速度比你审查的速度快，所以如果你停止阅读 diff，你并没有消除工作，只是推迟了它。

• 理解差距在扩大。 以你无法吸收的速度，发布了不是你编写的代码，会侵蚀你对自身系统的理解模型，而这笔债务会在下一次事故中到期。

• 宽松检查下的静默漂移。 一个弱的验证器让错误但通过检查的工作在每个迭代中溜过去，所以循环看起来高产，实际上却在挖坑。

这些都不是反对循环的理由；这正是为什么设计循环的工程师变得更加重要，而不是更不重要。

如何构建你自己的循环

• 选择一个可重复的任务。 照看 PR、修复 CI、验证部署：从例行工作开始。

• 严格限定范围。 “修复计费 webhook 验证，只改动 app/api/billing 和 lib/billing” 优于 “修复这个 bug”。一个松散循环会四处游荡。

• 给它一个预算和一个停止条件。 最大尝试次数、最大运行时间、最大文件数、最大花费、最大连续失败次数。一个无人值守运行的循环，也是一个无人值守犯错的循环。

• 添加一个独立的验证器。 一个独立的子智能体来评估工作，因为编写代码的智能体是判断它是否完成的最差评判者。

• 按节奏运行它。 /loop 用于时间间隔，cron 用于计划任务，生命周期点的钩子，或 GitHub Actions，这样即使合上笔记本电脑它也能存活。

• 在磁盘上保留记忆。 模型在两次运行之间会遗忘，所以状态存在于 markdown 或看板中，而不是在上下文窗口里。

总结：循环，而不是模型，现在是昂贵且易出错的部分。把它当作一个你打算继续对输出负责的工程师来构建，而不仅仅是启动运行的那个人。

如果你发现任何错误或需要进一步澄清的地方，请随时联系我。

其他有用参考

• Addy Osmani (@addyosmani)，关于 AI 辅助的编码循环
• Matt Van Horn (@mvanhorn)，“WTF Is a Loop？”
• Peter Steinberger (@steipete)，关于设计循环
• Boris Cherny (@bcherny)，关于自主运行智能体