从提示 Agent 到循环工程

最近，AI 编程圈里流传着一个说法：

不要再只是给 coding agents 写提示词了，而要开始设计那些替你提示 Agent 的循环。

和所有新概念一样，这句话被反复转述，但真正解释清楚的人并不多。

这篇文章想给出一个更实用的版本：什么是 Agent loop，为什么它重要，以及一个真正跑在生产环境里的 loop 大概是什么样。

下面这些内容，来自我近期和一些学生、技术创始人、AI 工程师以及创业公司交流过程中的实验、研究和思考，其中也借助了 Claude 的帮助。

如果你刚开始了解这个方向，也可以把我们最近关于 “Autonomous Long-Running Coding Agents” 的直播作为一个起点。

这个说法从哪里来

你不应该再只是提示 coding agents。你应该设计那些提示 agents 的循环。

Peter Steinberger，2026 年 6 月 7 日，220 万次浏览。

Claude Code 的创造者 Boris Cherny，也从另一个角度表达过类似观点：

我现在已经不再提示 Claude 了。我有一些 loops 在运行。是它们在提示 Claude，并判断下一步该做什么。我的工作是写 loops。

这里的重点，并不是说提示词工程已经死了。

在 loop engineering 中，工作被上移了一个层级：从写代码，变成写一个会写代码的系统。

在这条路上走得比较远的开发者，已经开始报告这样的情况：有些月份他们合并了数百个 PR，但没有打开过 IDE，每一行代码都是 Agent 写的。

loop 到底是什么

loop 是你写的一段小程序，它会做四件事：

替你提示 coding agent

读取 Agent 生成的结果

判断任务是否已经完成

如果没有完成，就把错误或下一步再反馈给 Agent

也就是说，你不再坐在 loop 里面一条一条地输入提示词。

你写的是 loop，而模型变成了这个 loop 调用的一个子程序。

它的结构基本都是一样的：

设定目标

执行动作

检查结果

把错误反馈回去

重复，直到检查通过，或者 loop 自己停止

“loop” 至少有五种含义

很多争论，其实来自大家用同一个词在表达五种不同的东西。

下面是它们从早到新的演进顺序。

ReAct，2022

这是最早的研究模式：

推理

行动

观察

重复

也就是 reason、act、observe、repeat。

AutoGPT，2023

这是一个自我提示的目标循环，曾经非常出名，但也因为“不知道什么时候该停止”而备受争议。

ralph loop

它强调在每次迭代之间主动重置上下文，让 Agent 不至于被自己过去的历史淹没。

/loop 和 /goal

节奏和完成条件被内置到 Agent 里，并且状态会跨多轮对话持续保留。

orchestration

一个作者可以扇出大量 Agent，让它们读取你的 GitHub、Slack 和聊天记录，并决定下一步应该构建什么。

你真正需要组装的部分

上面的演进过程解释了人们说 loop 时到底在说什么。

但真正构建一个 loop 时，你需要的是下面这些组件。

每次都会出现同样六个部分，而且现在大多数部分已经被编码工具内置了，不再需要你自己维护一堆脚本。

触发器

触发器负责在你不用手动点击“开始”的情况下启动 loop。

它可以是一个定时任务、一个 webhook、一次文件变更，或者 PR 上新增的某个标签。

这也是一个真正的 loop 和一次手动重复执行之间的区别。

隔离环境

每个 Agent 都需要一个私有 checkout，通常是 git worktree。

这样，多个 Agent 同时运行时，不会互相覆盖彼此的文件。

只要你开始运行不止一个 Agent，隔离就不再是可选项。

写下来的上下文

项目约定、构建步骤、特定规则，需要放在 Agent 每次运行都能读取到的地方。

如果跳过这一点，loop 每次运行都会从零开始重新推断你的项目，并在空白处乱猜。

接入你的工具

loop 需要能访问 issue tracker、CI、数据库和聊天工具。

这样它才能自动打开 PR、关联工单、发布结果，而不是只打印出一个修复方案，然后等你把它手动搬到下一步。

第二个 Agent 来检查

生成结果的 Agent 和检查结果的 Agent 应该分开。

因为让模型审查自己的工作，几乎什么都会通过。

你需要一个独立 worker 来给输出打分。

磁盘上的状态

状态可以是一个 Markdown 文件、一个看板，或者一个队列。

关键是，它必须存在于对话之外，用来记录什么已经完成，下一步是什么。

模型会在不同运行之间遗忘，但文件不会。

把这六个部分组合起来，就有了 loop engineering 的一个良好起点。

过去你需要手工搭建所有东西，现在很多能力已经变成内置功能，这也是为什么这个模式正在从边缘技巧走向普遍使用。

一个具体 loop：PR babysitter

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

我们可以把它叫做 PR babysitter，也就是 PR 看护员。

触发器

每 15 分钟运行一次。

范围

只处理打了 agent-watch 标签的开放 PR。

动作

如果 CI 因为确定性原因变红，就尝试修复一次。

如果主分支发生了移动，就 rebase 一次。

预算

每个 PR 只尝试修复一次。

最多运行 5 分钟。

最多修改 10 个文件。

停止条件

CI 变绿，或者预算耗尽。

然后停止，并提醒人类介入。

结果是，你回来时看到的是已经合并的 PR，而不是一堆构建失败的积压任务。

同样的结构，也覆盖了很多运维工作。

CI 健康检查

每 30 分钟拉取失败的运行记录，并按错误签名聚类。

这样，十个变红的 PR，如果本质上是同一个根因，就会变成一件需要处理的事。

部署验证

每次 push 之后，访问你的接口，确认返回 200 和预期内容，在用户发现问题之前标记回归。

反馈聚类

每 30 分钟拉取各个渠道里的评论，把它们聚成主题，并把每一类反馈映射到对应的文件或文档负责人。

Claude Code 中一个具体的 /goal loop

PR babysitter 是你自己接线搭建的 loop。

但看一个内置在 Agent 里的 loop，也很有帮助。

在 Claude Code 中，最小的完整 loop 是 /goal。

你给它一个可验证的最终状态，它会持续执行，直到这个状态为真。

下面是一个在 Claude Code 会话中使用 /goal 的例子。你先启动会话，然后在会话里设定目标：

ounter(lineounter(line$ claude  # 启动 Claude Code$ /goal tests in test/auth pass   # 在会话中设定目标

这仍然是前面讲过的 act、check、repeat 结构，只不过验证器已经被内置进去了。

到这里应该很清楚了：一个强大的 /goal，看起来不像一个提示词，更像一份合同。

好的 /goal 会明确四件事：

你想要的最终状态

证明已经达到目标的证据

Agent 在实现过程中不能破坏的约束

允许消耗的工作预算

只要其中任何一个部分含糊，模型就会用最省事的方式填补空白：

提前停止

走捷径

或者重新定义成功，让对话记录看起来完成了，但真实系统仍然是坏的

如何设定 /goal

第一步，设定条件。

输入 /goal 加上一个可以检查的最终状态。

例如：

ounter(line/goal tests in test/auth pass

第一轮会立即开始。

第二步，Agent 执行一轮工作。

它会编辑文件、运行测试，并在会话中展示结果。

第三步，评估器检查。

一个快速模型会读取执行记录，并判断目标是 met 还是 not met。

这样，Agent 就不是在给自己的工作打分。

第四步，继续或结束。

如果没有达成目标，就带着指导进入下一轮。

如果达成目标，goal 会自动清除，运行停止。

状态会跨多轮保留，所以它不会过早退出，也不会中途丢掉某个约束。

为了让它可靠，有几个控制点很重要。

让检查可度量

测试结果、退出码、文件数量、空队列，都可以作为检查条件。

npm test exits 0 是一个目标。

“让它变得更好”不是目标。

给运行加边界

可以追加类似 “or stop after 20 turns” 的限制。

这样，当 loop 卡住时，它会停止，而不是不断消耗轮次。

配合 auto mode 使用

让多轮执行可以无人值守运行。

如果你想提前放弃，可以用 /goal clear 清除目标。

评估器不一定要和编码器是同一个模型

这里有个很有用但容易被忽略的细节：

检查者不一定要和写代码的是同一个模型。

一旦 loop 有了不同角色，比如 planner、executor、evaluator、vision reviewer，每个角色都可以运行在不同模型上。

选择哪个模型承担哪个角色，就变成了一个架构决策，而不是押注某一个“最强 coding agent”。

有些模型更擅长规划。

有些模型执行成本更低。

有些模型更擅长判断截图。

一个好的 orchestrator，应该允许你按角色替换模型，而不是等待某个供应商在所有类别上都赢。

/goal 适合什么

它适合 API 迁移。

比如把所有调用点迁移完，直到能编译并通过测试。

它适合重构。

比如拆分一个文件，直到每个模块都低于预算。

它适合 issue backlog。

比如处理一个打了标签的队列，直到队列清空。

它也适合 eval loop。

比如持续调整一个提示词，直到评分超过阈值。

/loop 是另一个对应能力。

它适合没有单一终点的任务。

/goal 关注完成条件。

/loop 关注按计划重复提示。

像 PR babysitter 这样的 loop，就是靠 /loop 持续运行的。

让多个 loop 无人值守地运行

一个 /goal loop，是一个 Agent 朝着一个终点工作。

但当你开始运行多个无人值守流程时，风险会显著提高。

因为一个 loop 是否可信，本质上取决于它能不能检查自己的工作。

Boris Cherny 用 Opus 自主运行数小时的配置，可以概括成五步：

第一步：自动批准权限

让 Agent 不会在每一次工具调用时停下来询问你。

第二步：使用 dynamic workflows

把 Ultracode 放进提示词中，让它扇出多个 Agent，而不是用一个串行线程做所有事。

第三步：使用 /goal 或 /loop 保持运行

/goal 设置完成条件。

/loop 按计划重复提示。

两者都会保留状态，所以不会过早停止。

第四步：在云端运行

使用桌面端或移动端 App 的云端能力。

这样，就算你合上笔记本，会话也能继续存活。

第五步：给它端到端自验证能力

Web 端可以用 Claude in Chrome。

移动端可以用 simulator MCP。

后端可以用 live server。

这一步，才是让前面四步变得安全的关键。

完整流程大致如下：

ounter(lineounter(lineounter(lineounter(lineounter(lineclaude --permission-mode auto                          # 1 · 不再弹出审批提示ultracode  orchestrate sub-agents to ship the feature  # 2 · 扇出多个 Agent/goal all tests pass and the demo loads clean          # 3 · 持续运行→ cloud / desktop app                                  # 4 · 合上笔记本也继续跑→ chrome ext · sim MCP · live server                   # 5 · 自我验证，然后停止

crabfleet：把 orchestration 做成产品

用一个具体工具来看 orchestration，会更容易理解。

Peter Steinberger 的 crabfleet 是 OpenClaw 项目的一部分，被称为“agent runs 的任务控制中心”。

它本质上就是一个被产品化的 loop，它的结构几乎映射了前面讲到的一切。

工作以看板卡片形式存在

任务被输入为卡片，可以来自一个 prompt、一个 GitHub issue，或者一个 PR。

随后这些卡片会在 todo、running、human review、done 等状态之间流转。

这个看板，就是 loop 的队列，也是它的停止和报告步骤，只不过被可视化了。

持久运行，而不是发出去就不管

每次运行都是一次被跟踪的 attempt，并带有 heartbeat。

所以它可以在你不盯着的时候继续运行，也能在你合上笔记本之后存活。

只有当运行时声明支持 handoff 时，你才会接管。

Agent 可以生成 Agent

一次运行可以启动子会话，发送消息，读取转录记录，并在沙箱中更新自己的摘要。

也就是说，它把磁盘记忆和 fan-out 放在了同一个地方：

一个作者，多个 Agent。

它运行在一次性云端沙箱中，并提供基于浏览器的终端。

正是这一点，让无人值守运行变得相对安全。

重点不是这个具体工具，而是说明 loop 已经开始硬化成基础设施：

队列

持久执行

fan-out

人工审核门

这些能力正在从每次手写脚本，变成可以配置的东西。

现在成本花在哪里

过去两年，AI 编程的成本问题很简单：

用哪个模型？

消耗多少 token？

但在 loop 里，这种直觉会指向错误的层级。

花费不再是一次模型调用，而是 loop 转了多少圈。

同一个模型下，一个需要重试六次才收敛的 loop，成本就是一次通过的六倍。

这会改变你真正应该优化的东西。

迭代次数才是预算项，不是 token

一个更便宜的模型，如果循环次数增加一倍，就不一定更便宜。

所以不要只看每次调用成本，而要看每个完成任务的成本。

弱验证器是最昂贵的 bug

如果负责判断 “done” 的检查太松，loop 要么会在坏工作上提前停止，要么会对已经没问题的工作继续消耗迭代。

两种情况都会浪费完整的迭代成本。

在优化其他东西之前，先收紧验证器。

快速失败是一种成本控制

没有连续失败上限的 loop，并不会“最终成功”。

它更可能最终把账户余额耗光。

所以停止条件既是在保护代码库，也是在保护账单。

过去你调的是提示词。

现在你调的是 loop。

因为成本正是在 loop 上累积的。

什么时候不要用 loop

loop 适合重复发生，并且机器能够判断何时完成的任务。

除此之外，loop 只是把无效忙碌自动化。

以下几类情况应该跳过。

一次性修改

如果一轮就能完成，loop 只是额外开销。

没有边界的探索性工作

“弄清楚为什么用户在流失”没有通过条件。

所以 loop 永远不会真正收敛。

没有廉价自动检查的事情

如果唯一的验证器还是你的眼睛，那你其实仍然在 loop 里。

要么先构建检查机制，要么手动完成这项工作。

可能出什么问题

一个能在你睡觉时运行的 loop，也会在你睡觉时犯错。

而且这些失败模式是可以预见的。

验证负担仍然落在人身上

loop 写得比你 review 得更快。

如果你停止阅读 diff，你并没有消除这项工作，只是把它推迟了。

理解缺口会扩大

你没有亲手写代码，却以比自己吸收速度更快的节奏交付代码。

这会侵蚀你对自身系统的理解。

这笔债务，往往会在下一次事故中到期。

松散检查导致静默漂移

弱验证器会让“错误但能通过”的工作在每次迭代中进入系统。

于是 loop 看起来很高产，但其实是在挖坑。

这些并不是反对 loop 的理由。

恰恰相反，它说明设计 loop 的工程师变得更重要，而不是更不重要。

如何构建你自己的 loop

选择一个可重复任务

从日常工作开始：

看护 PR

修复 CI

验证部署

这些都是很好的起点。

把范围收紧

“修复 billing webhook validation，只允许修改 app/api/billing 和 lib/billing”，比“修复这个 bug”好得多。

松散的 loop 会四处游走。

给它预算和停止条件

最多尝试次数

最长运行时间

最多修改文件数

最大花费

最多连续失败次数

无人值守运行的 loop，也是在无人值守地犯错。

增加独立验证器

用一个单独的 sub-agent 给结果打分。

因为写代码的 Agent，是最不适合判断自己是否完成的人。

让它按节奏运行

可以用 /loop 设置间隔。

可以用 cron 设置计划任务。

可以用 hooks 绑定生命周期节点。

也可以用 GitHub Actions，让它在笔记本合上之后仍然存活。

把记忆放在磁盘上

模型会在多次运行之间遗忘。

所以状态应该放在 Markdown 文件或看板里，而不是放在上下文窗口里。

最后的 takeaway

现在，真正昂贵、真正容易出错的部分，已经不是模型，而是 loop。

你应该像一个仍然要为输出负责的工程师那样构建它。

而不是像一个只负责启动运行的人那样对待它。

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