# 循环工程：从提示智能体，到设计提示智能体的循环

> 原文作者：Addy Osmani

## 作者介绍

**Addy Osmani**是 **Google Cloud AI** 的 Director，关注 **Gemini、AI Agents** 以及优秀的用户体验、开发者体验和 AI 体验。

---

## 正文

## 循环工程

循环工程（Loop Engineering）正在取代“由你亲自给智能体写提示词”这件事。你要设计的，是一个会替你提示智能体的系统。这里的“循环”可以理解为一种递归目标：你定义一个目的，然后让 AI 不断迭代，直到完成。它大致由五个构件组成，而 Claude Code 和 Codex 现在都已经具备这五个构件。

我认为，这可能是我们未来使用编程智能体的工作方式。不过，现在仍然处在早期阶段。我对此保持怀疑，而且你绝对需要谨慎对待 token 成本，因为在 token 充裕和 token 紧张的情况下，使用模式可能会天差地别。你也仍然需要某种机制来确保质量不会下降；人们对“AI 垃圾产出”的担忧是合理的。话虽如此，我们还是来看看这到底是怎么回事。

steipete 最近说过：

> “你不应该再去提示编程智能体了。你应该设计那些会提示你的智能体的循环。”

同样，Anthropic 的 Claude Code 负责人 bcherny 也说过：

> “我现在已经不提示 Claude 了。我有一些循环在运行，由它们来提示 Claude，并弄清楚该做什么。我的工作是写循环。”

好吧，这到底是什么意思？

过去大概两年里，你想从一个编程智能体那里得到东西，方式就是写一个好提示词，并提供足够的上下文。你输入一件事，阅读返回结果，再输入下一件事。智能体是一个工具，而你一直握着这个工具，一轮接一轮地操作。这个阶段差不多结束了，或者至少有人认为它正在结束。

现在，你构建的是一个小系统：它会发现工作、分派工作、检查工作、记录已完成事项，然后决定下一步做什么。你让这个系统去“戳”智能体，而不是由你亲自去做。我之前写过一个相近概念：智能体运行框架工程（agent harness engineering），也就是为单个智能体搭建运行环境；还有“工厂模型”（factory model），也就是构建软件的系统。循环工程位于这个运行框架之上。它像是一个运行框架，但会按定时器运行，会生成一些小帮手，还会给自己喂入新的任务。

让我惊讶的是，这现在已经不太是“工具问题”了。一年前，如果你想要一个循环，你得写一堆 Bash 脚本，然后永远维护那一堆东西。它是你的，也只有你能用。现在，这些构件直接内置在产品里了。Steinberger 列出的清单几乎能一一映射到 Codex 应用上，随后也几乎同样映射到 Claude Code 上。一旦你意识到它们的形态是一样的，你就不再争论到底该用哪个工具，而是开始设计一个循环，使它无论你坐在哪个工具前都能运转。

---

## 五个构件，以及一些说明

一个循环需要五样东西，外加一个用于记忆的地方。先列出来，再逐一对应：

1. **自动化任务**：按计划触发，自动做发现和分诊。
2. **工作树（worktrees）**：让两个并行工作的智能体互不踩脚。
3. **技能（skills）**：记录项目知识，避免智能体凭空猜测。
4. **插件和连接器**：把智能体接入你已经在用的工具。
5. **子智能体（sub-agents）**：一个负责提出想法，另一个负责检查。

然后是第六样东西：**记忆**。

它可以是一个 Markdown 文件，也可以是一个 Linear 看板，或者任何存在于单次对话之外、能够记录“已完成什么”和“下一步是什么”的东西。听起来蠢得不像什么重要设计，但这正是每个长期运行智能体都依赖的技巧。我在讨论长期运行智能体时也写过：模型会在两次运行之间忘掉一切，所以记忆必须存在磁盘上，而不是存在上下文里。智能体会忘，代码仓库不会。

它们的名称有时略有不同，但能力是同一种东西。下面我逐个讲，因为说实话，循环能不能撑住，或者会不会悄悄到处漏水，关键都在细节里。

---

## 自动化：这是循环的心跳

自动化让一个循环成为真正的循环，而不是你曾经手动运行过的一次性任务。

在 Codex 应用里，你可以在 Automations 标签页中创建自动化任务，选择项目、要运行的提示词、运行频率，以及它是在你的本地检出目录中运行，还是在后台工作树中运行。那些发现了问题的运行会进入一个分诊收件箱；没有发现任何问题的运行则会自动归档，这点很不错。OpenAI 内部会用它们做一些无聊但有用的事情，比如每日 issue 分诊、总结 CI 失败、编写提交简报、寻找上周有人引入的 bug。

自动化还可以调用一个技能，因此你可以让这种重复任务保持可维护性：触发 `$skill-name`，而不是把一大墙永远没人会更新的说明粘贴进定时任务里。

Claude Code 通过调度和钩子（hooks）达到同样的效果。你可以用 `/loop` 按间隔运行一个提示词或命令，可以调度一个 cron 任务，可以在智能体生命周期的特定节点触发 shell 命令；如果你希望它在你关掉笔记本之后还继续运行，也可以把整个东西推到 GitHub Actions 上。

核心思想完全一样：定义一个自主任务，给它一个节奏，让发现结果来到你面前，而不是由你到处去检查。

还有一个值得了解的会话内原语，它更接近本文讨论的核心。

`/loop` 会按节奏重复运行。`/goal` 则会持续运行，直到你写下的某个条件真的成立；并且在每轮之后，会由一个单独的小模型检查是否已经完成，因此写代码的那个智能体不是给自己打分的人。

你可以给它一个条件，比如：

> `test/auth` 中的所有测试通过，且 lint 干净。

然后离开。

Codex 也有同样的东西，也叫 `/goal`：它会跨多轮持续工作，直到某个可验证的停止条件成立，并支持暂停、恢复和清除。两个工具、同一个原语。这其实就是整篇文章都会反复出现的模式。

所以，这一部分负责把工作浮现出来。循环的其他部分，则负责对这些工作采取行动。

---

## 工作树：避免并行变成混乱

一旦你运行不止一个智能体，文件就会开始互相冲突，这会成为失败点。两个智能体同时写同一个文件，和两个工程师同时提交同一段代码而彼此没沟通过，是同一种头疼。

Git worktree 可以解决这个问题：它是在独立分支上的一个独立工作目录，同时共享同一个仓库历史，所以一个智能体的编辑根本碰不到另一个智能体的检出目录。

Codex 把工作树支持直接内置了进去，因此多个线程可以同时作用于同一个仓库而不互相撞车。

Claude Code 则通过以下方式提供同样的隔离能力：

- `git worktree`
- 用于在独立检出目录中打开会话的 `--worktree` 标志
- 可以放在子智能体上的 `isolation: worktree` 设置

这样每个小帮手都会获得一个新的检出目录，并在结束后自动清理。

我在讨论“编排税”（orchestration tax）时写过这个问题的人类侧面：工作树消除了机械性的冲突，但**你**仍然是上限。你能真正运行多少个智能体，取决于你的审查带宽，而不是工具本身。

---

## 技能：让你不必每次都重新解释项目

技能是你停止在每个会话中像金鱼一样反复解释同一个项目上下文的方法。

两个工具使用的是同一种格式：一个包含 `SKILL.md` 的文件夹，里面有说明和元数据，还可以有可选脚本、参考资料和资源文件。

Codex 会在你用 `$` 或 `/skills` 调用技能时运行它，也可以在任务匹配技能描述时自动运行它。这就是为什么一个紧凑、朴素的描述，比一个聪明花哨的描述更有用。Claude Code 也是同样做法，我之前在“智能体技能”（agent skills）里写过这个模式。

技能也是让“意图”停止反复消耗成本的地方。

我在“意图债务”（intent debt）中说过，智能体每个会话开始时都是冷启动，它会用自信的猜测填补你意图里的任何空洞。技能就是把这种意图写在外部：约定、构建步骤、“我们不这样做是因为那次事故”的背景，全部一次性写下来，让智能体每次运行都能读取。

没有技能，循环每一轮都会从零重新推导你的整个项目；有了技能，它就会有点像在复利增长。

有一点要分清楚：

> 技能是编写格式，插件是分发方式。

当你想跨仓库共享一个技能，或者把几个技能打包在一起时，你会把它们封装成插件。Codex 如此，Claude Code 也是如此。

---

## 插件和连接器：让循环接触你的真实工具

一个只能看到文件系统的循环，是一个很小的循环。

连接器建立在 MCP 之上，让智能体可以读取你的 issue 跟踪器、查询数据库、访问 staging API、往 Slack 里发消息。Codex 和 Claude Code 都支持 MCP，所以你为其中一个写的连接器，通常也能在另一个里工作。

插件则把连接器和技能打包在一起，让你的队友可以一次性安装你的整套设置，而不是凭记忆重建整个系统。

这就是以下两者之间的区别：

- 一个智能体说：“这是修复方案。”
- 一个循环自己打开 PR、关联 Linear 工单，并在 CI 变绿后通知频道。

连接器让循环能够在你的真实环境中采取行动，而不是只告诉你“如果我能做，我会这样做”。

---

## 子智能体：让制造者远离检查者

循环中最有用的结构性设计，远远超过其他东西，就是把写代码的人和检查代码的人分开。

写了代码的模型，在给自己的作业打分时太宽容了。第二个拥有不同指令、有时甚至使用不同模型的智能体，能抓住第一个智能体自我说服后忽略的问题。

Codex 只会在你要求时生成子智能体，让它们同时运行，然后把结果折叠回一个答案中。你可以在 `.codex/agents/` 中用 TOML 文件定义自己的智能体，每个智能体都有名称、描述、指令，以及可选的模型和推理强度。因此，你的安全审查员可以是一个高推理强度的强模型，而探索者则可以是某个快速、只读的模型。

Claude Code 通过 `.claude/agents/` 中的子智能体和能互相传递工作的智能体团队，实现同样的事情。在两个工具里，常见拆分都是：

1. 一个智能体探索
2. 一个智能体实现
3. 一个智能体根据规范验证

我之前已经两次提出过这个观点，一次是在“代码智能体交响乐队”（code agent orchestra），一次是在“对抗式代码审查”（adversarial code review）。

它在循环里尤其重要的原因是：循环会在你不盯着的时候运行，所以一个你真正信任的验证者，是你能够离开的唯一理由。

子智能体确实会消耗更多 token，因为每个子智能体都会进行自己的模型调用和工具操作，所以要把它们花在值得支付第二意见的地方。

这基本上也是 Claude Code 的 `/goal` 在底层所做的事情：由一个新的模型判断循环是否完成，而不是由完成工作的那个模型来判断。也就是说，把“制造者”和“检查者”的分离应用到了停止条件本身。

---

## 一个循环长什么样

把这些东西组合起来，一个单独的线程就会变成一个小型控制面板。下面是我一直在使用的一种形态。

每天早上，一个自动化任务在代码仓库上运行。它的提示词会调用一个分诊技能，读取昨天的 CI 失败、打开的 issue、最近的提交，然后把发现写入一个 Markdown 文件或 Linear 看板。

对于每个值得处理的发现，这个线程会打开一个隔离的工作树，派一个子智能体起草修复方案，再派第二个子智能体根据项目技能和现有测试来审查这个草稿。

连接器让这个循环可以打开 PR 并更新工单。任何循环处理不了的东西，都会落进我的分诊收件箱。

状态文件是整个系统的脊梁：它记住已经尝试过什么、什么通过了、什么仍然待处理。因此，明天早上的运行会从今天停下的地方继续。

看看你实际上做了什么：你只设计了一次。你并没有亲自提示其中任何一步。

这就是 Steinberger 的观点变成现实的样子。而且，无论是在 Codex 还是 Claude Code 中，它都是同一个循环，因为构件本身是同一套构件。

---

## 循环仍然不能替你做什么

循环改变了工作，但它没有把你从工作中删除。

而且，随着循环变得更好，有三个问题实际上会变得更尖锐，而不是更容易。

### 1. 验证仍然要靠你

一个无人值守运行的循环，也可能是在无人值守地犯错。

你把验证子智能体和制造子智能体分开的全部原因，就是为了让循环说“完成了”时有点意义。即便如此，“完成”仍然是一个主张，而不是证明。

我在“AI 时代的代码审查”中一直重复同一句话：

> 你的职责是交付你已经确认有效的代码。

### 2. 如果你放任不管，你的理解仍然会腐烂

循环越快地交付那些不是你亲手写的代码，现实中存在的东西和你真正理解的东西之间的差距就越大。

这就是“理解债务”（comprehension debt）。

一个顺滑的循环只会让这种债务增长得更快，除非你去阅读循环产出的东西。

### 3. 最舒服的姿态，很可能也是最危险的姿态

当循环自己运行时，你很容易停止表达自己的判断，只是接受它交回来的东西。

我把这叫作“认知投降”（cognitive surrender）。

当你带着判断力设计循环时，它是解药；当你用它来逃避思考时，它就是加速剂。

同一个动作，会产生相反的结果。

---

## 建立循环，但继续做工程师

我认为，这是我们工作方式将如何演进的一个预告。

话虽如此，如果我不亲自审查代码，或者如果我完全依赖自动化循环去修复代码，我的产品质量会受损。我很可能会陷入一种向下螺旋，持续把自己挖进更深的坑里。

所以，可以去搭建你的循环，但不要忘了：直接提示你的智能体仍然有效。关键在于找到正确的平衡。

循环也会因为使用者不同而产生不同结果。

两个人可以构建完全相同的循环，却得到完全相反的结果：

- 一个人用它在自己深刻理解的工作上走得更快。
- 另一个人用它来避免理解工作本身。

循环并不知道这两者的区别。你知道。

这就是为什么循环设计比提示词工程更难，而不是更容易。Cherny 的意思并不是工作变简单了，而是杠杆点移动了。

最后：

> 建立循环。
> 但要像一个打算继续做工程师的人那样去建立它，
> 而不是像一个只负责按下“开始”按钮的人。

#AI创造营#