真实的 Loop Engineering 是什么样的？

最近，“循环工程”成了热门话题。Anthropic 和 OpenAI 的一些知名人士透露，他们已经不再为编程任务写 Prompt，而是转向设计循环。在 Anthropic 的开发者大会上，Claude Code 的创建者 Boris Cherny 表示：

“我不再直接向 Claude 发 Prompt 了。我编写了一些循环程序，让这些程序向 Claude 发 Prompt，再由 Claude 决定该做什么。我的工作就是编写循环程序。”

不久之后，OpenClaw 的创始人 Peter Steinberger 也在一篇博文中提倡设计循环：

此外，前谷歌员工艾迪·奥斯曼尼撰写了一篇题为《循环工程》的文章。他写道：“循环工程就是用设计系统代替你向 Agent 发 Prompt。”

这已经是我连续第三次看到有人提起这种新方法。对我来说，它既陌生又相当抽象。为了弄清它究竟是什么，我向一些读过这些文章的人请教。大家在回复中解释了自己如何理解“循环工程”，也分享了工作中的实际案例。

今天，我们将介绍：

• 一切的起源：“拉尔夫·维格姆”循环。 一年前，软件工程师杰弗里·亨特利分享了自己构建“循环”的方法。去年 12 月，这种方法迅速走红，“拉尔夫循环”由此诞生。
• 所有主流的 AI 编码框架都内置了 /goal 命令。 截至今年 5 月，主流 AI 编码框架都已支持通过一条 Prompt 触发 /goal 命令来运行循环。
• 开发者常用的循环：触发器和定时任务。 我询问了开发者们如何使用循环。大多数用例都是响应事件或运行定时任务。它们确实有用，但看起来并不算全新的工作流。
• 对开发者有帮助的循环。 为新出现的应用问题创建 PR，在值班人员加入故障 Slack 频道前准备好调查笔记，监看并修复夜间端到端测试，等等。
• 失望与“Token 最大化”。 一些开发者尝试循环工程后便放弃了。原因包括 Agent 漂移，以及“人机交互”往往能带来更好的结果。此外，对那些按 Token 支付 API 费用的公司来说，持续运行循环的成本会迅速飙升。
• 循环操作是否只是工具完善前的权宜之计？ 杰出工程师 Max Kanat-Alexander 认为，这种“循环”操作可能只是临时的权宜之计，因为工具框架最终会支持通过一条 Prompt 完成同样的工作。
• 对开发者而言，“上下文工程”真的更重要吗？ 除非你在构建 AI 基础设施，否则似乎没必要深入钻研循环工程。相比之下，熟悉 AI 的上下文窗口或许更有用，而这本身也是构建循环的一部分。

1. 起源：“拉尔夫·维格姆”循环

一年前，软件工程师杰弗里·亨特利发表了题为《软件工程师眼中的拉尔夫·维格姆》的文章。拉尔夫·维格姆是《辛普森一家》中当地警察局长的儿子，他天真单纯，总是乐于助人。在工程语境中，“拉尔夫”指的是不断引导 Agent 朝正确方向前进。杰弗里这样描述它：

“Ralph 是一种技术。从本质上说，Ralph 就是一个 Bash 循环：while :; do cat PROMPT.md | claude-code ; done。对大多数公司而言，Ralph 可以取代大部分外包工作，尤其适合全新项目。它确实存在一些缺陷，但可以通过不同的 Prompt 策略发现并解决。这正是 Ralph 的妙处。面对一个非确定性的世界，从确定性的标准来看，这种技术糟透了。”

文章进一步解释了 Ralph 循环：

• 启动 Agent 时，给它一条涵盖任务并定义目标的 Prompt；
• 制定工作计划，每个工作项都包含成功标准；
• 启动循环：
  • 每轮选取一个工作项；
  • Agent 完成任务后，检查目标是否已经达成；
  • 如果尚未达成，重新启动 Agent，并清空上下文窗口；
• 如有必要，启动子循环并生成子 Agent。

杰弗里公开了自己用这种方法开展的实验，其中包括构建一种新的编程语言。他强调，这种做法仍然需要专业能力：“工程师仍然是必需的。如果没有资深专家的指导，Ralph 根本不可能完成这项工作。任何声称不再需要工程师、工具可以完成 100% 工作的说法，都是在胡说八道。”

去年年底，性能更强、能够出色完成大型项目的模型陆续出现，“Ralph 方法”也突然爆红。软件工程师马特·波科克（Matt Pocock）使用这种方法，发布了一篇名为《睡觉时也能发布工作代码》的教程。他说道：

“大家对编程 Agent 的一个梦想，就是早上醒来时看到已经可以运行的代码。Agent 处理完了你积压的任务，生成了一大堆代码供你审查，而且这些代码还能正常运行。”

在使用 Ralph 循环之前，Matt 会分两步完成这项工作：

1. 请 Agent 制定一份详细的工作计划，并拆分各项任务；
2. 再让 Agent 按顺序在彼此独立的会话中完成每个子任务。

这种方法的问题在于，很难向“总体规划”中添加新任务。软件工程师都知道，大多数规划都需要在实施过程中调整。相比之下，在 Matt 改进的 Ralph 方法中，“总体规划”会在“主 PRD”里持续更新。以下是他给 Agent 的 Prompt：

• 选择下一个功能： 找到优先级最高的功能，只开发这一个功能；
• 测试通过： 运行 pnpm test，检查测试是否通过；
• 更新主跟踪器： 根据已完成的工作更新 PRD；
• 记录工作： 将进度追加到 progress.txt 文件中；
• 提交： 将该功能的代码改动提交到 Git。

这种工作方式更像一块会随进展不断更新的“动态看板”。

“Ralph 方法”的核心，是绕过上下文窗口的容量限制。上下文窗口容量有限，远远不足以承载复杂任务，因此需要把 Agent 的运行拆成更小的单元，逐个执行。Ralph 方法正是在这种情况下发挥作用：

• 为项目设定目标，持续运行或重新运行 Agent，直到目标达成；
• 把已完成工作的精简摘要持久化到文件系统中，作为日志或更新后的计划；
• 为 Agent 提供全新的上下文，尽可能减少“上下文腐烂”；
• 允许每个 Agent 根据需要添加或修改“总体规划”。

2. 所有主流框架都提供了 /goal 命令

过去几个月里，构建 Ralph 循环一直意味着凡事都要自己动手：设置循环、跟踪状态、决定 Agent 如何添加任务，以及何时停止。但随着编码工具开始原生支持这类循环，运行循环变得容易多了。

四月：Codex 推出 Goals

在“Ralph 技术”获得关注约六个月后，Codex 发布了 Goals 功能。文档中写道：

“在 Codex 中，目标会一直存在，让一个线程能够跨越多个回合，持续朝既定结果前进。目标为 Codex 设定完成条件：应达到什么状态、如何验证成功，以及哪些约束条件必须始终保持不变。”

文档中还提到：

“普通 Prompt 告诉 Codex：下一步做什么。

Goal 则要求 Codex：持续工作，直至达成这个结果。处理普通请求时，Codex 会执行当前指令、报告结果，然后等待。有了 Goal，Codex 就拥有了一个持久目标。每个回合结束后，它都可以检查证据，判断目标是否已经达成。如果目标尚未达成，并且仍在预算范围内，Codex 可以从最新状态继续工作。”

以下是在 Codex 中使用 Goal 的示例：

/goal Reduce p95 checkout latency below 120 ms on the checkout benchmark while keeping the correctness suite green

（目标：在保持正确性测试套件绿灯的前提下，将结账基准测试中的 p95 结账延迟降低到 120 毫秒以下。）

这是一个足够清晰的完成标准，可以直接交给 Agent。随后，Agent 会拆解任务、生成子 Agent，并持续运行直至完成。OpenAI 使用文件、日志、测试运行和生命周期控制构建了 Goals：

Goals 功能与 Ralph 循环非常相似，只不过被封装成了一条命令。Codex 团队借鉴 Ralph 循环的理念，围绕它构建了基础设施，负责 Agent 之间的协调、状态管理、测试运行和启停控制，还加入了预算设置等功能。

五月：Hermes 和 Claude Code 跟进支持 /goal

三天后的 5 月 2 日，热门 Agent 框架 Hermes Agent 发布了自己的 /goal 实现：

“[/goal] 这是我们基于 Ralph 循环的实现，直接受到 OpenAI 为 Codex CLI 编写的 /goal 指令启发。核心思路是让目标在不同回合中一直存在，直到达成目标才停止，这个思路正是他们提出的。我们的实现是独立完成的，并针对 Hermes 的架构做了调整。”

不到两周后的 5 月 12 日，Claude Code 也发布了 /goal 命令。它的功能与 Codex 完全相同：

“/goal 命令会设置一个完成条件，Claude 将持续朝这个条件努力，无需你手动为每一步发 Prompt。每个回合结束后，一个小型快速模型都会检查这个条件是否已经满足。如果尚未满足，Claude 会开始下一个回合，而不是将控制权交还给你。一旦条件满足，目标就会自动清除。”

此前，Claude Code 已在 3 月发布了通过 /loop 命令调度 Agent 的功能。它本质上相当于 JavaScript 的 setTimeout() 函数：按给定的时间间隔重复执行任务，直到工作完成。

到了 5 月，在主流 Agent 框架中运行 Ralph 循环已经变得像输入一条命令一样简单。AI 实验室发现用户希望简化 Agent 循环的操作，于是开发了相应功能。例如，OpenCode 等开源框架提供 /goal 插件；对于极简编码 Agent Pi，也可以将 /goal 作为软件包添加进去。

3. 开发者使用的循环：触发器和定时任务

到了 5 月，我们已经有了 /goal 这个基础能力。那么，Boris Cherny 和 Peter Steinberger 所说的“把大部分时间花在设计循环上，而不是编写 Prompt”，具体是在做什么？我向其他开发者征集了一些“循环工程”的案例。根据收到的回复，触发器和定时任务是两个非常常见的用例：

• 触发器 / 自动化： 特定事件发生时启动 Agent，例如记录错误、创建新工单或收到客户支持反馈。AI 出现之前，这些事件发生后，通常会通过 webhook 触发后续操作，让 Slack 机器人发帖，或启动 Zapier/n8n 集成。
• 定时任务： 许多开发者把“循环工程”理解为按固定节奏启动包含 Agent 的任务。这本质上与定时任务相同。工程总监 Oded Messer 表示：

“只要战略工作流可以自动化，足够强的 AI 就能把它转化为具体的战术流程；如果 AI 能力还不够，那它也不过是一套更高级的传统自动化，可以像定时任务或触发器一样设置。‘循环’这个名字本身就意味着简单和重复。有时我觉得，AI 爱好者似乎忘了，自动化早在 LLM 出现之前就已经存在。”

4. 对开发者有用的循环

以下是一些使用 AI Agent 的工作流。它们会定期通过 /loop 命令运行，或在特定事件发生时触发：

开发相关工作

• 为新出现的应用问题提交 PR（软件工程师 Ivan Pantić）：

  “应用报错并创建 Sentry Issue → 定时任务让 Agent 检查是否已有活跃 PR → 如果没有，Agent 就处理该问题并创建一个 PR → 如果 PR 尚未审核，Agent 通过 Slack 提醒开发者。在这套流程中，同一时间只允许有一个 PR 处于开启状态。”

• 修复不稳定的测试（PostHog 软件工程师 Paul D’Ambra）：

  “/loop 从主干 API 拉取下一个不稳定的测试用例，并在本地运行验证；如果确认测试不稳定，就提交一个包含修复方案的 PR。这个流程帮我成功提交了 13 个用于修复不稳定测试的 PR。”

• 问题与故障分类（软件工程师 Ivan Abad）：

  “频道里出现新的警报或异常 → Agent 展开调查 → 如果需要修改代码，就直接实施修改 → 创建 PR → 通知人工审核。客户工单或事件也是如此。等你加入故障处理时，Agent 通常已经完成问题分类，并找到了根本原因。”

• 审阅设计方案（Elastic 软件工程师 Artem Nikitin）：

  “我最近经常做的一件事，是反复审查设计方案或实施计划。Agent 单次运行通常只能发现少量问题，所以我会要求它循环运行，直到某一轮没有发现任何新的重大问题。”

日间/夜间工作

• 每日产品改进（Schematic 创始工程师 Jack D）：

  “我们有一个循环，会读取过去 24 小时的日志和用户反馈，并生成包含修复代码的 PR。不过，我们仍然会人工审核它生成的 PR！”

• Agent 监督每晚运行的端到端测试（工程经理 Utku K）：

  “我们每晚都会在前端应用上运行端到端测试。测试失败时，Agent 会先调查这是真正的回归问题，还是误报。如果确实是 Bug，Agent 会尝试修复、重新运行测试并不断迭代，直到测试通过，或达到重试上限后将问题上报。第二天早上，修复结果会以待审核 PR 的形式提交。”

更复杂的开发工作

• 构建并验证新的遥测集成（Incident.io 软件工程师 Lawrence Jones）：

  “我们用来构建新遥测集成的许多 AI 运行手册都会使用循环。例如，执行查询、验证查询是否正确运行，并不断调整查询计划和输出格式，直到对结果满意。”

• 自主完成耗时较长的代码迁移（创业公司创始人 Rafel Mendiola）：

  “最近，我使用 Expo 将代码库从 React 应用转换为 React Native 应用。我没有按照传统方式创建 50 到 100 个 Ticket，而是创建了一个 Skill，让 Agent 按照特定规则自动找出一小块代码并完成转换，然后把这个 Skill 配置为每 30 分钟运行一次的定时任务。与管理大型迁移计划相比，这种方式的认知负担小得多。”

生产力相关工作流程

• 每日任务执行（Akka.NET 创作者 Aaron Stannard）：

“我设置了一个每日循环，它会解析我收到的 GitHub 通知，根据上下文对 Issue 分类，更新项目看板，并在每天早上 7 点为我起草一份每日简报。这让我每天可以少花 45 分钟处理行政杂务。”

5. 失望与“Token 最大化”

尽管相关讨论很多，但并非所有人都认同循环工程。几位工程师表示，在遇到几类并不意外的问题后，他们放弃了相关实验：

• Agent 漂移（Agent drift）： 如果没有人持续监督，Agent 在多轮循环中经常会偏离目标。它可能陷入死循环，不断修复并不存在的 Bug，或重构原本可用的代码。

• 上下文腐烂（Context rot）： 随着日志文件和 PRD 跟踪内容不断增长，上下文中的关键信号会被稀释，导致幻觉增多、推理质量下降。

• “Token 最大化”的代价（Tokenmaxxing）： 持续运行循环会很快消耗数百万 Token。对使用第三方 API 的开发者来说，一个在夜间失控的循环很容易带来数千美元的意外账单。

软件架构师丹·阿布拉莫夫（Dan Abramov）总结道：

“循环工程往往会变成一场昂贵的 Token 最大化游戏。你花 50 美元的 API 费用，只为省下 10 分钟手动发 Prompt 的时间，结果却要多花一个小时审查一团糟的 PR。”

6. 循环操作是否只是工具完善前的权宜之计？

循环工程是一种永久性的范式转变，还是一种临时的变通方案？

杰出工程师 Max Kanat-Alexander 指出，Ralph Wiggum 这类标准 Bash 循环，只是为了绕过早期上下文窗口限制和工具套件缺陷而设计的粗糙过渡方案：

“早期的 Agent 无法保持状态，也不能自主执行需要长时间运行的任务，所以我们构建了外部脚本，定期启动它们。如今的工具和框架已经原生支持 /goal 等基础能力，状态管理和重试循环正重新交由 Agent 框架本身负责。”

随着 Agent 环境日趋成熟，手动编写的循环逻辑可能会被进一步抽象，融入 Agent 的原生行为中。

7. 对开发者而言，“上下文工程”真的更重要吗？

对大多数从事日常开发的软件工程师而言，花几个小时设计定制循环架构，收益越来越有限。相比之下，更值得掌握的是上下文工程（Context Engineering）。

上下文工程侧重于：

• 优化上下文窗口： 动态移除上下文中无关的文件、历史记录和系统指令，让 Agent 保持专注；
• 配置确定性环境： 为 Agent 提供准确的工具、文档和终端访问权限，使其能够高效执行任务而不偏离方向。

除非你正在构建 AI 开发者工具或 Agent 基础设施，否则就没必要把大量精力投入外层循环。对软件工程师来说，学会在现有的 /goal 和 /loop 工具中组织并提供高质量上下文，依然是最值得掌握的技能。

下面是一篇与本文标签相关的文章。

8 分钟讲清楚 Agents、Loops 和 Graphs

理解 Agent、Loop 和 Graph 这三种结构如何让 Claude 从等待指令的聊天工具，变成能够自主完成工作的系统。

继续阅读……