从提示词工程到循环工程

原文：https://x.com/omarsar0/status/2068008743153832264

AI 编程圈里最近流传着一个说法：别再给你的编程智能体写提示词了，开始设计能替你给它们写提示词的循环。和所有新东西一样，这类说法经常被重复，却很少被解释清楚。本文是一个实用版本：什么是智能体循环，它为什么重要，以及它在生产环境中是什么样子。

下面是我在一些实验、研究，以及和我们的学生、技术创始人、AI 工程师和创业公司交流后的一些想法（在 Claude 的帮助下写成）。

你也可以把我们最近的直播 “Autonomous Long-Running Coding Agents” 作为理解这一切的良好起点。

这个说法从何而来

“你不应该再给编程智能体写提示词了。你应该设计会提示你的智能体的循环。”Peter Steinberger（@steipete），2026 年 6 月 7 日。220 万次浏览。原推文

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

“我现在不再提示 Claude 了。我有一些循环在运行。是它们在提示 Claude，并弄清楚该做什么。我的工作是编写循环。”Boris Cherny（@bcherny）。原推文

重点并不是说提示词工程已经死了。有了循环工程，工作会上升一个层级：从编写代码，变成编写那个会编写代码的系统。在这条路上走得最远的开发者表示，他们有些月份在没有打开 IDE 的情况下提交了数百个 PR，而且每一行代码都是智能体写的。

循环到底是什么

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

• 替你给编程智能体发送提示词，
• 读取它产出的内容，
• 判断是否已经完成，
• 如果没有完成，就带着错误信息或下一步继续提示它。

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

它的形态始终相同：设定目标、执行、检查、把错误反馈回去，然后不断重复，直到检查通过，或者循环自行停止。

“循环”至少有五种含义

很多分歧来自于人们用同一个词指代五种不同的想法。下面是这个概念从旧到新的演进。

• ReAct（2022）。
   最初的研究模式：推理、行动、观察、重复。
• AutoGPT（2023）。
   一种自我提示的目标循环，因不知道何时停止而臭名昭著。
• ralph loop。
   在迭代之间有意重置上下文，让智能体不会淹没在自己的历史记录里。
• /loop 和 /goal。
   节奏和完成条件内置在智能体中，并能跨轮次携带状态。
• 编排（orchestration）。
   一个作者分发出多个智能体，让它们读取你的 GitHub、Slack 和聊天记录，并决定接下来要构建什么。

你真正需要组装的部分

上面的演进解释了人们说“循环”时指的是什么；而这里讲的是一个循环由什么构成。同样的六个部分每次都会出现，而且现在其中大多数已经内置在编程工具里，而不再需要你维护自定义脚本。

• 一个触发器。
   某个不需要你按下开始按钮就能启动循环的东西：定时任务、webhook、文件变化、PR 上被打了某个标签。这是把真正的循环和你手动重复的一次性运行区分开的东西。
• 隔离环境。
   每个智能体都有一个私有检出副本，通常是一个 git worktree，这样两个同时运行的智能体就不会互相覆盖文件。一旦你同时运行多个智能体，这就不再是可选项。
• 写下来的上下文。
   约定、构建步骤和项目特定规则都放在智能体每次运行都会读取的位置。如果跳过这一步，循环每次都会从头重新推导你的项目，并对空白处进行猜测。
• 接入你的工具。
   连接 issue 跟踪器、CI、数据库和聊天工具，让循环能打开 PR、关联工单、发布结果，而不是只打印一个修复方案，然后等你把它手动推进到后续环节。
• 由第二个智能体检查。
   一个独立的工作者负责给输出打分，它与产出内容的智能体保持分离，因为让模型审查自己的工作几乎什么都能通过。
• 磁盘上的状态。
   一个 markdown 文件、一个看板，或者一个队列：任何存在于对话之外、记录已完成事项和下一步事项的东西。模型会在运行之间遗忘；文件不会。

把这六部分组装起来，你就有了循环工程的良好起点。过去你需要手工构建所有东西；现在大多数都已经作为内置功能提供，这也是这个模式从边缘技巧走向普遍使用的原因。

一个具体循环：PR 看护员

下面是一个你今天就可以构建的具体例子：

• 触发器。
   每 15 分钟一次。
• 范围。
   带有 agent-watch 标签的开放 PR。
• 动作。
   如果 CI 因确定性原因变红，就尝试修复一次。如果主分支发生移动，就 rebase 一次。
• 预算。
   每个 PR 一次修复尝试，五分钟，最多改动十个文件。
• 停止条件。
   CI 变绿，或者预算耗尽，然后停止并通知人类。

你回来时看到的是已经合并的 PR，而不是一堆构建失败的积压任务。同样的形态覆盖了大多数运维工作：

• CI 健康检查。
   每 30 分钟拉取失败的运行，并按特征签名聚类，这样十个变红的 PR 如果只有一个根因，就会变成一个需要查看的问题。
• 部署验证。
   推送之后，访问你的端点，确认返回 200 和预期内容，并在用户发现之前标记回归。
• 反馈聚类。
   每 30 分钟从你的渠道拉取评论，将它们按主题分组，并把每个聚类映射到对应的文件或文档。

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

PR 看护员是一个你自己接线的循环；看看一个内置在智能体中的循环也很有帮助。在 Claude Code 中，最小的完整循环是 /goal：你给它一个可验证的最终状态，它会持续进行多轮操作，直到该状态为真。

下面是在 Claude Code 中把 /goal 作为会话内命令使用的例子。你启动会话，然后在其中设定目标：

bash

它与前面讲过的执行、检查、重复形态相同，只是验证器内置其中。

到这里已经很清楚了：一个强有力的 /goal 读起来不像提示词，更像一份合约。好的 /goal 会明确四件事：你想要的最终状态、证明你已经达到该状态的证据、智能体在实现过程中不得破坏的约束，以及允许它消耗的工作预算。其中任何一项含糊，模型都会用最省事的方式填补空白：它会过早停止、走捷径，或者重新定义成功，让转录记录看起来已经完成，而真实系统仍然是坏的。

• 设定条件。
   输入 /goal 加上一个可检查的最终状态，例如，/goal tests in test/auth pass。第一轮会立即开始。
• 智能体执行一轮。
   它会编辑、运行测试，并在会话中展示结果。
• 评估器检查。
   一个快速模型读取转录记录，并判断是否达到目标，所以不是由智能体给自己的工作打分。
• 循环或结束。
   未达到意味着带着指导进入下一轮；达到意味着目标自动清除，运行停止。

状态会跨轮次携带，所以它不会过早退出，也不会中途丢掉某个约束。一些控制手段能让它更可靠：

• 让检查可度量。
   测试结果、退出码、文件数量，或者空队列。npm test exits 0 是一个目标；“把它变得更好”不是。
• 限制运行边界。
   追加类似 “or stop after 20 turns” 的内容，让卡住的循环停止，而不是不断消耗轮次。
• 将它与自动模式配合使用
  ，让各轮次无人值守地运行，并用 /goal clear 提前放弃。

评估器这一步隐藏了一个有用的细节：检查器不必和编码器是同一个模型。一旦循环有了不同角色（规划者、执行者、评估者、视觉审查者），每个角色都可以运行在不同模型上，而选择哪个模型承担哪个角色，会变成一个架构决策，而不是把赌注押在某个“最佳”编程智能体上。有些模型更擅长规划，有些模型执行成本更低，有些模型能更准确地判断截图，一个好的编排器允许你按角色替换它们，而不是等待某个厂商赢下所有类别。

它很适合 API 迁移（移动每个调用点，直到编译和测试通过）、重构（拆分文件，直到每个模块都低于预算）、issue 积压处理（处理带标签的队列，直到队列为空），以及评估循环（调整提示词，直到分数超过阈值）。/loop 是针对没有单一终点的工作的对应物：它不是设置完成条件，而是按计划重新提示，这正是 PR 看护员这类循环能持续运行的方式。

无人值守地运行多个循环

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

• 自动批准权限
  ，这样智能体不会在每次工具调用时都停下来询问。
• 使用动态工作流
  （把 Ultracode 放进提示词中），从而分发到多个智能体，而不是一个串行线程。
• 使用 /goal 或 /loop
   来让它持续运行。/goal 设置完成条件，/loop 按计划重新提示，二者都会携带状态，所以它不会过早退出。
• 在云端运行
  （桌面端或移动端应用），这样即使你合上笔记本，会话也能继续。
• 给它一种端到端自我验证的方式
  。Web 使用 Chrome 中的 Claude，移动端使用模拟器 MCP，后端使用实时服务器。这一步让其他四步变得安全。

完整序列：

bash

crabfleet：作为产品的编排

用一个具体工具来理解编排会更容易。Peter Steinberger 的 crabfleet 是 OpenClaw 的一个项目，被称为“智能体运行的任务控制中心”。它是一个被包装成产品的循环，其形态与上文所有内容都能对应起来。

• 以看板卡片形式组织工作。
   任务以卡片形式录入，可以来自提示词、GitHub issue 或 PR，然后在 todo、running、human review 和 done 之间流转。这个看板就是循环的队列，也是它的停止与报告步骤，只不过被可视化了。
• 持久运行，而不是发射后不管。
   每次运行都是一次被跟踪的尝试，并带有心跳，所以当你把视线移开时它会继续进行，也能在笔记本合上后存活。只有当运行时声明自己支持接管时，你才会介入。
• 会生成智能体的智能体。
   一次运行可以启动子会话、发送消息、读取转录记录，并在沙箱内更新自己的摘要：磁盘记忆和扇出能力汇集在同一个地方，一个作者，多个智能体。

它运行在一次性云沙箱上，并带有基于浏览器的终端，这让你放心离开无人值守运行成为可能。重点不是具体工具，而是循环已经硬化成了基础设施：队列、持久执行、扇出和人工审查门禁，现在都是你配置的东西，而不是每次都要手写脚本。

现在成本花在哪里

过去两年里，AI 编程中的成本问题很简单：用哪个模型，以及多少 token。在循环内部，这种直觉会指向错误的层级。支出不再是一次调用，而是循环转了多少圈，所以一个在收敛前重试六次的循环，和一个一次就成功的循环相比，即使使用同一个模型，成本也是六倍。

这会改变值得优化的东西：

• 迭代次数才是预算项，不是 token。
   一个更便宜但循环次数翻倍的模型并不更便宜，所以要追踪每个已完成任务的成本，而不是每次调用的成本。
• 薄弱的验证器是你能交付的最昂贵 bug。
   如果负责判断“完成”的检查很松，循环要么会在坏掉的工作上过早停止，要么会在本来已经没问题的工作上继续打转，而两者都会浪费整轮迭代。先把这个收紧，再考虑别的。
• 快速失败是一种成本控制。
   没有连续失败上限的循环不会“最终成功”；它最终会耗尽账户。所以停止条件保护的不只是代码库，也保护账单。

过去你调提示词；现在你调循环，因为成本是在这里累积的。

什么时候不该使用循环

当任务会重复，并且机器能够判断何时完成时，循环才有回报。除此之外，循环只是在自动化制造忙乱。以下情况请跳过：

• 一次性编辑。
   如果你可以一次完成，循环就是纯粹的额外开销。
• 无范围或探索性工作。
   “弄清楚用户为什么流失”没有通过条件，所以循环永远不会收敛。
• 任何缺少廉价自动化检查的事情。
   如果唯一的验证器是你自己的眼睛，那么你仍然在循环里。先构建检查，或者手动完成任务。

可能出什么问题

一个在你睡觉时运行的循环，也会在你睡觉时犯错，而且失败模式是可预见的。

• 验证负担仍然落在人类身上。
   循环写得比你审得快，所以如果你停止阅读 diff，你并没有消除工作，只是推迟了它。
• 理解缺口会扩大。
   以快于你吸收的速度交付你没有写过的代码，会侵蚀你对自己系统的心智模型，而这笔债会在下一次事故中到期。
• 宽松检查下的静默漂移。
   薄弱的验证器会让错误但通过的工作在每次迭代中流入系统，所以循环看起来很高产，实际上是在挖坑。

这些都不是反对循环的理由；它们说明了为什么设计循环的工程师更加重要，而不是更不重要。

如何构建你自己的循环

• 选择一个可重复任务。
   看护 PR、修复 CI、验证部署：从日常工作开始。
• 把范围收紧。
   “修复账单 webhook 验证，只能触碰 app/api/billing 和 lib/billing”，比“修复这个 bug”更好。松散的循环会到处游荡。
• 给它预算和停止条件。
   最大尝试次数、最大运行时间、最大文件数、最大支出、最大连续失败次数。无人值守运行的循环，也是在无人值守地犯错。
• 加入独立验证器。
   由一个单独的子智能体给工作打分，因为写代码的智能体最不适合判断它是否完成。
• 按节奏运行它。
   用 /loop 设置间隔，用 cron 设置计划任务，在生命周期节点使用 hook，或者用 GitHub Actions 让它在笔记本合上后仍能存活。
• 把记忆保存在磁盘上。
   模型会在运行之间遗忘，所以状态应该存在 markdown 或看板里，而不是上下文窗口里。

要点是：现在昂贵且容易出故障的部分是循环，而不是模型。构建它时，要像一个仍打算对输出负责的工程师，而不只是那个启动运行的人。

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

其他有用参考

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