从提示词智能体到循环工程

从提示词智能体到循环工程 从提示词智能体到循环工程 Modified June 21 • 触发条件：每15分钟执行一次。 • 作用范围：带有agent watch标签的待合并拉取请求。 • 执行操作：若持续集成流程因确定原因报错，尝试修复一次；若主分支有更新，执行一次变基操作。 • 资源限制：每个拉取请求仅允许一次修复尝试，耗时上限5分钟，最多修改10个文件。 • 终止条件：持续集成流程校验通过，或资源耗尽，随即停止执行并通知人工处理。 你回来时看到的是已合并的 PR，而不是一堆坏掉的构建积压。同样的形状可以覆盖大多数运维工作： • CI 健康度。 每 30 分钟拉取失败运行，并按特征聚类，让 10 个红色 PR 背后的同一个根因变成一件需要查看的事。 • 部署验证。 推送后访问你的端点，确认 200 响应和预期内容，并在用户发现前标出回归。 • 反馈聚类。 每 30 分钟从你的频道拉取评论，把它们分组为主题，并把每个聚类映射到负责它的文件或文档。 一个具体的 Claude Code /goal 循环 PR 看护器是你自己接线的循环；再看一个内置在智能体里的循环也很有帮助。在 Claude Code 里，最小完整循环是 /goal：你给它一个可验证的最终状态，它会持续轮转，直到该状态成立。 Claude Code /goal 循环 下面是把 /goal 作为 Claude Code 会话内命令使用的例子。你先启动会话，然后在会话里设定目标： Code block Bash Copy $ claude 启动 Claude Code $ /goal tests in test/auth pass 在会话中设定目标 它和前面说的“行动、检查、重复”是同一种形状，只是验证器已经内置。 到这里可以看出，一个强 /goal 读起来不像提示词，更像一份合约。好的目标会明确四件事：你想要的最终状态、证明已经到达该状态的证据、智能体达成目标时不能破坏的约束，以及允许它消耗的工作预算。任何一项含糊，模型都会用最容易的理解补上空白：提前停止、走捷径，或者重新定义成功，让会话记录看起来完成了，而真实系统仍然坏着。 • 设定条件。 输入 /goal 加一个可检查的最终状态，比如 /goal tests in test/auth pass。第一轮会立即开始。 • 智能体工作一轮。 它编辑、运行测试，并在会话里展示结果。 • 评估器检查。 一个快速模型读取会话记录，判断目标是否达成，避免智能体给自己的工作打分。 • 继续循环或结束。 未达成意味着带着指导进入下一轮；达成意味着目标自动清除，运行停止。 状态会跨轮次保留，所以它不会中途提前退出，也不会半路丢掉约束。几个控制项能让它更可靠： • 让检查可度量。 测试结果、退出码、文件数量、空队列都可以。npm test 退出码为 0 是目标；“让它更好”不是。 • 限制运行范围。 加上类似“或 20 轮后停止”的内容，让卡住的循环停止，而不是继续烧轮次。 • 搭配自动模式，让多轮可以无人值守运行；需要提前放弃时，用 /goal clear 清除。 评估器这一步隐藏了一个有用细节：检查者不必和编码者是同一个模型。一旦循环里有了不同角色，比如规划者、执行者、评估者、视觉审查者，每个角色就可以运行在不同模型上。选择哪个模型承担哪个角色，会变成架构决策，而不是押注某一个“最好”的编码智能体。有些模型更会规划，有些执行更便宜，有些判断截图更准确；好的编排器允许你按角色替换模型，而不是等待某个供应商赢下所有类别。 它很适合 API 迁移（移动每个调用点，直到能编译并通过测试）、重构（拆分文件，直到每个模块低于预算）、issue 积压（处理带标签队列，直到清空）和评测循环（调提示词，直到分数超过阈值）。/loop 是没有单一终点的对应物：它不是根据完成条件停止，而是按计划重新提示，这就是 PR 看护器这类循环持续运行的方式。 无人值守地运行多个循环 单个 /goal 循环，是一个智能体朝一个终点工作。运行多个无人值守进程会提高风险，因为循环的可信度取决于它检查自己工作的能力。Cherny 用 Opus 自主运行数小时的配置，可以归结为五步： 1. 自动批准权限，让智能体不会每次工具调用都停下来询问。 2. 使用动态工作流，也就是把 Ultracode 放进提示词，让它扇出到多个智能体，而不是一个串行线程。 3. 使用 /goal 或 /loop 保持运行。/goal 设定完成条件，/loop 按计划重新提示；二者都会携带状态，所以不会提前退出。 4. 在云端运行，也就是桌面或移动应用里运行，这样你合上笔记本后会话仍然存活。 5. 给它一种端到端自我验证方式。 Web 用 Chrome 里的 Claude，移动端用模拟器 MCP，后端用实时服务器。这一步让前面四步变得安全。 完整序列： Code block Bash Copy claude permission mode auto 1 · 不再弹批准提示 ultracode orchestrate sub agents to ship the feature 2 · 扇出 /goal all tests pass and the demo loads clean 3 · 持续运行 → cloud / desktop app 4 · 合上笔记本 → chrome ext · sim MCP · live server 5 · 自我验证，然后停止 crabfleet：把编排做成产品 用一个具体工具来理解编排会更容易。Peter Steinberger 的 crabfleet 是 OpenClaw 项目，号称“智能体运行的任务控制中心”。它是被包装成产品的循环，形状和上面的内容都能对应起来。 crabfleet 编排 • 把工作变成看板卡片。 任务以卡片形式输入，可以来自提示词、GitHub issue 或 PR，然后在待办、运行中、人工审查和完成之间移动。这个看板就是循环的队列，也是它可见的停止与报告步骤。 • 持久运行，而非一次性触发后不管。 每次运行都是一次被追踪的尝试，并带有心跳，所以你看向别处时它也会继续，合上笔记本也能存活。只有当运行时声明支持 handoff 时，你才接手。 • 会生成智能体的智能体。 一次运行可以启动子会话、发送消息、读取会话记录，并在沙箱内更新自己的摘要：磁盘记忆和扇出在同一个地方完成，一个作者，多个智能体。 它依托带有浏览器终端的一次性云沙箱运行，这也是无人值守运行时离开操作界面仍能保障安全的原因。关键不在于某款特定工具，而是这套循环流程已固化为标准化基础设施：队列、持久化执行、多分支分发以及人工审核关卡，如今均可通过配置实现，无需每次手动编写脚本。 现在成本花在哪里 过去两年里，AI 编码的成本问题很简单：哪个模型，用多少 token。但在循环内部，这种直觉会指向错误层级。花费不再是一次调用，而是循环转了多少圈；所以同一个模型上，一个收敛前重试 6 次的循环，成本是一次命中的循环的 6 倍。 这改变了值得优化的东西： • 迭代次数才是预算项，不是 token。 如果一个更便宜的模型循环次数翻倍，它并不更便宜。所以要追踪每个完成任务的成本，而不是每次调用的成本。 • 弱验证器是你能交付的最昂贵 bug。 如果决定“完成”的检查太松，循环要么在坏结果上提前停止，要么在已经没问题的工作上继续打转。两者都会浪费整个迭代。先收紧这里，再优化别的。 • 快速失败是一种成本控制。 没有连续失败上限的循环，不会最终成功，只会最终耗干账户。所以停止条件保护的不只是代码库，也保护账单。 过去你调提示词；现在你调循环，因为成本在循环里累积。 什么时候不要使用循环 当任务会重复，而且机器能判断它是否完成时，循环才划算。除此之外，循环只会自动化无效忙碌。下面这些情况要跳过： • 一次性编辑。 如果单次就能完成，循环就是纯开销。 • 无范围或探索性工作。 “弄清楚用户为什么流失”没有通过条件，所以循环永远不会收敛。 • 任何没有低成本自动检查的工作。 如果唯一验证器是你的眼睛，那你仍然在循环里。先构建检查，或者手工完成任务。 会出什么问题 一个在你睡觉时运行的循环，也会在你睡觉时犯错，而且失败模式是可预测的。 • 验证负担仍然在人类身上。 循环写得比你审得更快，所以如果你停止阅读 diff，你并没有消除工作，只是把它推迟了。 • 理解差距扩大。交付你没有编写的代码，速度比你吸收的速度还快，会侵蚀你对自己系统的认知模型，而这笔债务会在下一次事件中到期。 • 宽松检查下的悄然偏离。一个薄弱的验证器会让错误但能通过的工作在每次迭代中都得以通过，所以这个循环看起来很有成效，实则在挖一个坑。 这些都不是反对循环的理由；它们说明设计循环的工程师更重要，而不是更不重要。 如何构建你自己的循环 如何构建自己的循环 1. 选择一个可重复任务。 看护 PR、修 CI、验证部署：从常规工作开始。 2. 把范围收紧。 “修复 billing webhook 校验，只能改 app/api/billing 和 lib/billing”，比“修这个 bug”好。松散循环会乱跑。 3. 给它限制和停止条件。 最大尝试次数、最大运行时间、最大文件数、最大花费、最大连续失败次数。无人值守运行的循环，也是在无人值守地犯错。 4. 加入独立验证器。 用单独的子智能体给工作打分，因为写代码的智能体最不适合判断它是否完成。 5. 按节奏运行。 /loop 用于间隔运行，cron 用于计划任务，hooks 用于生命周期节点，GitHub Actions 则能让它在合上笔记本后继续。 6. 把记忆保存在磁盘上。 模型会在运行之间遗忘，所以状态应该存在 Markdown 或看板里，而不是上下文窗口里。 关键点：现在昂贵且容易失败的部分，是循环，而不是模型。构建它时，要像那个仍然要对输出负责的工程师，而不只是启动运行的人。 如果你发现任何错误，或者有需要进一步澄清的地方，欢迎联系我。 其他有用参考 • Addy Osmani（@addyosmani），关于 AI 辅助编码循环 • Matt Van Horn（@mvanhorn），《WTF Is a Loop?》 • Peter Steinberger（@steipete），关于设计循环 • Boris Cherny（@bcherny），关于自主运行智能体 crabfleet Addy Osmani（@addyosmani），关于 AI 辅助编码循环 Matt Van Horn（@mvanhorn），《WTF Is a Loop?》 Peter Steinberger（@steipete），关于设计循环 Boris Cherny（@bcherny），关于自主运行智能体 • 触发条件：每15分钟执行一次。 • 作用范围：带有agent watch标签的待合并拉取请求。 • 执行操作：若持续集成流程因确定原因报错，尝试修复一次；若主分支有更新，执行一次变基操作。 • 资源限制：每个拉取请求仅允许一次修复尝试，耗时上限5分钟，最多修改10个文件。 • 终止条件：持续集成流程校验通过，或资源耗尽，随即停止执行并通知人工处理。 你回来时看到的是已合并的 PR，而不是一堆坏掉的构建积压。同样的形状可以覆盖大多数运维工作： • CI 健康度。 每 30 分钟拉取失败运行，并按特征聚类，让 10 个红色 PR 背后的同一个根因变成一件需要查看的事。 • 部署验证。 推送后访问你的端点，确认 200 响应和预期内容，并在用户发现前标出回归。 • 反馈聚类。 每 30 分钟从你的频道拉取评论，把它们分组为主题，并把每个聚类映射到负责它的文件或文档。 一个具体的 Claude Code /goal 循环 PR 看护器是你自己接线的循环；再看一个内置在智能体里的循环也很有帮助。在 Claude Code 里，最小完整循环是 /goal：你给它一个可验证的最终状态，它会持续轮转，直到该状态成立。 下面是把 /goal 作为 Claude Code 会话内命令使用的例子。你先启动会话，然后在会话里设定目标： 它和前面说的“行动、检查、重复”是同一种形状，只是验证器已经内置。 到这里可以看出，一个强 /goal 读起来不像提示词，更像一份合约。好的目标会明确四件事：你想要的最终状态、证明已经到达该状态的证据、智能体达成目标时不能破坏的约束，以及允许它消耗的工作预算。任何一项含糊，模型都会用最容易的理解补上空白：提前停止、走捷径，或者重新定义成功，让会话记录看起来完成了，而真实系统仍然坏着。 • 设定条件。 输入 /goal 加一个可检查的最终状态，比如 /goal tests in test/auth pass。第一轮会立即开始。 • 智能体工作一轮。 它编辑、运行测试，并在会话里展示结果。 • 评估器检查。 一个快速模型读取会话记录，判断目标是否达成，避免智能体给自己的工作打分。 • 继续循环或结束。 未达成意味着带着指导进入下一轮；达成意味着目标自动清除，运行停止。 状态会跨轮次保留，所以它不会中途提前退出，也不会半路丢掉约束。几个控制项能让它更可靠： • 让检查可度量。 测试结果、退出码、文件数量、空队列都可以。npm test 退出码为 0 是目标；“让它更好”不是。 • 限制运行范围。 加上类似“或 20 轮后停止”的内容，让卡住的循环停止，而不是继续烧轮次。 • 搭配自动模式，让多轮可以无人值守运行；需要提前放弃时，用 /goal clear 清除。 评估器这一步隐藏了一个有用细节：检查者不必和编码者是同一个模型。一旦循环里有了不同角色，比如规划者、执行者、评估者、视觉审查者，每个角色就可以运行在不同模型上。选择哪个模型承担哪个角色，会变成架构决策，而不是押注某一个“最好”的编码智能体。有些模型更会规划，有些执行更便宜，有些判断截图更准确；好的编排器允许你按角色替换模型，而不是等待某个供应商赢下所有类别。 它很适合 API 迁移（移动每个调用点，直到能编译并通过测试）、重构（拆分文件，直到每个模块低于预算）、issue 积压（处理带标签队列，直到清空）和评测循环（调提示词，直到分数超过阈值）。/loop 是没有单一终点的对应物：它不是根据完成条件停止，而是按计划重新提示，这就是 PR 看护器这类循环持续运行的方式。 无人值守地运行多个循环 单个 /goal 循环，是一个智能体朝一个终点工作。运行多个无人值守进程会提高风险，因为循环的可信度取决于它检查自己工作的能力。Cherny 用 Opus 自主运行数小时的配置，可以归结为五步： 1. 自动批准权限，让智能体不会每次工具调用都停下来询问。 2. 使用动态工作流，也就是把 Ultracode 放进提示词，让它扇出到多个智能体，而不是一个串行线程。 3. 使用 /goal 或 /loop 保持运行。/goal 设定完成条件，/loop 按计划重新提示；二者都会携带状态，所以不会提前退出。 4. 在云端运行，也就是桌面或移动应用里运行，这样你合上笔记本后会话仍然存活。 5. 给它一种端到端自我验证方式。 Web 用 Chrome 里的 Claude，移动端用模拟器 MCP，后端用实时服务器。这一步让前面四步变得安全。 完整序列： crabfleet：把编排做成产品 用一个具体工具来理解编排会更容易。Peter Steinberger 的 crabfleet 是 OpenClaw 项目，号称“智能体运行的任务控制中心”。它是被包装成产品的循环，形状和上面的内容都能对应起来。 crabfleet • 把工作变成看板卡片。 任务以卡片形式输入，可以来自提示词、GitHub issue 或 PR，然后在待办、运行中、人工审查和完成之间移动。这个看板就是循环的队列，也是它可见的停止与报告步骤。 • 持久运行，而非一次性触发后不管。 每次运行都是一次被追踪的尝试，并带有心跳，所以你看向别处时它也会继续，合上笔记本也能存活。只有当运行时声明支持 handoff 时，你才接手。 • 会生成智能体的智能体。 一次运行可以启动子会话、发送消息、读取会话记录，并在沙箱内更新自己的摘要：磁盘记忆和扇出在同一个地方完成，一个作者，多个智能体。 它依托带有浏览器终端的一次性云沙箱运行，这也是无人值守运行时离开操作界面仍能保障安全的原因。关键不在于某款特定工具，而是这套循环流程已固化为标准化基础设施：队列、持久化执行、多分支分发以及人工审核关卡，如今均可通过配置实现，无需每次手动编写脚本。 现在成本花在哪里 过去两年里，AI 编码的成本问题很简单：哪个模型，用多少 token。但在循环内部，这种直觉会指向错误层级。花费不再是一次调用，而是循环转了多少圈；所以同一个模型上，一个收敛前重试 6 次的循环，成本是一次命中的循环的 6 倍。 这改变了值得优化的东西： • 迭代次数才是预算项，不是 token。 如果一个更便宜的模型循环次数翻倍，它并不更便宜。所以要追踪每个完成任务的成本，而不是每次调用的成本。 • 弱验证器是你能交付的最昂贵 bug。 如果决定“完成”的检查太松，循环要么在坏结果上提前停止，要么在已经没问题的工作上继续打转。两者都会浪费整个迭代。先收紧这里，再优化别的。 • 快速失败是一种成本控制。 没有连续失败上限的循环，不会最终成功，只会最终耗干账户。所以停止条件保护的不只是代码库，也保护账单。 过去你调提示词；现在你调循环，因为成本在循环里累积。 什么时候不要使用循环 当任务会重复，而且机器能判断它是否完成时，循环才划算。除此之外，循环只会自动化无效忙碌。下面这些情况要跳过： • 一次性编辑。 如果单次就能完成，循环就是纯开销。 • 无范围或探索性工作。 “弄清楚用户为什么流失”没有通过条件，所以循环永远不会收敛。 • 任何没有低成本自动检查的工作。 如果唯一验证器是你的眼睛，那你仍然在循环里。先构建检查，或者手工完成任务。 会出什么问题 一个在你睡觉时运行的循环，也会在你睡觉时犯错，而且失败模式是可预测的。 • 验证负担仍然在人类身上。 循环写得比你审得更快，所以如果你停止阅读 diff，你并没有消除工作，只是把它推迟了。 • 理解差距扩大。交付你没有编写的代码，速度比你吸收的速度还快，会侵蚀你对自己系统的认知模型，而这笔债务会在下一次事件中到期。 • 宽松检查下的悄然偏离。一个薄弱的验证器会让错误但能通过的工作在每次迭代中都得以通过，所以这个循环看起来很有成效，实则在挖一个坑。 这些都不是反对循环的理由；它们说明设计循环的工程师更重要，而不是更不重要。 如何构建你自己的循环 1. 选择一个可重复任务。 看护 PR、修 CI、验证部署：从常规工作开始。 2. 把范围收紧。 “修复 billing webhook 校验，只能改 app/api/billing 和 lib/billing”，比“修这个 bug”好。松散循环会乱跑。 3. 给它限制和停止条件。 最大尝试次数、最大运行时间、最大文件数、最大花费、最大连续失败次数。无人值守运行的循环，也是在无人值守地犯错。 4. 加入独立验证器。 用单独的子智能体给工作打分，因为写代码的智能体最不适合判断它是否完成。 5. 按节奏运行。 /loop 用于间隔运行，cron 用于计划任务，hooks 用于生命周期节点，GitHub Actions 则能让它在合上笔记本后继续。 6. 把记忆保存在磁盘上。 模型会在运行之间遗忘，所以状态应该存在 Markdown 或看板里，而不是上下文窗口里。 关键点：现在昂贵且容易失败的部分，是循环，而不是模型。构建它时，要像那个仍然要对输出负责的工程师，而不只是启动运行的人。 如果你发现任何错误，或者有需要进一步澄清的地方，欢迎联系我。 其他有用参考 • Addy Osmani（@addyosmani），关于 AI 辅助编码循环 Addy Osmani（@addyosmani），关于 AI 辅助编码循环 • Matt Van Horn（@mvanhorn），《WTF Is a Loop?》 Matt Van Horn（@mvanhorn），《WTF Is a Loop?》 • Peter Steinberger（@steipete），关于设计循环 Peter Steinberger（@steipete），关于设计循环 • Boris Cherny（@bcherny），关于自主运行智能体 Boris Cherny（@bcherny），关于自主运行智能体 原帖链接：https://x.com/omarsar0/status/2068008743153832264 原帖链接：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）。原帖 原帖 这并不是说提示词工程已经死了。循环工程把工作上移了一个层级：从写代码，变成写那个会写代码的系统。走在这条路最前面的一些开发者表示，他们有些月份交付了数百个 PR，却没有打开 IDE；每一行代码都由智能体写出。 循环到底是什么 循环是你写的一小段程序，它做四件事： • 替你提示编码智能体； • 读取它产出的结果； • 判断任务是否完成； • 如果没有完成，就带着错误或下一步继续提示它。 你不再坐在循环里不断输入提示词；你写下循环，模型变成它调用的一个子程序。 形状始终相同：设定目标，执行动作，检查结果，把错误反馈回去，然后重复，直到检查通过，或者循环自己停止。 “循环”至少有五种含义 很多争论的根源，是大家用同一个词指代五种不同想法。下面是从旧到新的演进顺序。 • ReAct（2022）。 最早的研究模式：推理、行动、观察、重复。 • AutoGPT（2023）。 自我提示的目标循环，出名的问题是不知道什么时候该停。 • ralph loop。 每次迭代之间刻意重置上下文，让智能体不会淹没在自己的历史里。 • /loop 和 /goal。 节奏与完成条件内置进智能体，并能跨轮次携带状态。 • 编排。 一个作者扇出多个智能体，让它们读取你的 GitHub、Slack 和聊天内容，并决定下一步该构建什么。 你真正要组装的部件 上面的演进解释的是人们说“循环”时到底在说什么；下面这些才是循环真正由什么构成。同样六个部件每次都会出现，而且现在大多已经内置在编码工具里，不再需要你维护自定义脚本。 • 触发器。 某个不需要你按下开始按钮就能启动循环的东西：定时任务、webhook、文件变更、PR 上出现某个标签。这是区分真实循环和你手动重复单次运行的关键。 • 隔离。 每个智能体都有自己的私有检出副本，通常是 git worktree，这样两个智能体同时运行时不会覆盖彼此的文件。一旦你运行不止一个智能体，这就不再是可选项。 • 写下来的上下文。 约定、构建步骤和项目特定规则，都放在智能体每次运行都会读取的位置。跳过这一步，循环每一轮都会从头推导你的项目，并在空白处乱猜。 • 接入你的工具。 连接问题跟踪器、CI、数据库和聊天工具，让循环可以打开 PR、关联工单、发布结果，而不是打印一个修复方案后等你把它搬到终点。 • 第二个智能体负责检查。 一个独立工作进程给输出打分，并和产出结果的智能体隔离开，因为让模型审查自己的工作，几乎什么都会通过。 • 磁盘上的状态。 Markdown 文件、看板或队列都可以：任何位于对话之外、能记录什么已完成和接下来做什么的东西。模型会在运行之间遗忘，文件不会。 把这六件事组装起来，你就有了循环工程的一个良好起点。过去你需要手工搭建所有东西；现在大多数已经变成内置能力，这也是这个模式从边缘技巧变成常见用法的原因。 一个具体循环：PR 看护器 一个今天就能构建的具体例子：