真实的 Loop Engineering 是什么样的？

过去一段时间，“循环工程”成为了热门话题，此前 Anthropic 和 OpenAI 的一些知名人士透露，他们已经停止编写编程 Prompt，转而开始设计循环。在 Anthropic 的开发者大会上，Claude Code 的创建者 Boris Cherny 表示：

“我不再直接提示Claude了。我编写了一些循环程序来提示Claude并让他决定该做什么。我的工作就是编写循环程序。”

不久之后，OpenClaw 的创始人 Peter Steinberger 在一篇博文中宣扬了循环设计：

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

这已经是连续三次提到这种新方法了，对我来说，这是一种全新的方法，因此也相当抽象。为了了解更多信息，我向一些阅读过这些文章的人寻求帮助。在回复中，你们告诉我“循环工程”对你们来说意味着什么，并举了一些你们工作中循环的例子。

今天，我们将介绍：

• 一切的起源：“拉尔夫·维格姆”循环。 一年前，软件工程师杰弗里·亨特利分享了他构建“循环”的方法。去年 12 月，这种方法迅速走红，“拉尔夫循环”由此诞生。
• 所有主流的 AI 编码框架都内置了 /goal 命令。 截至今年 5 月，主流的 AI 编码框架都已添加了对使用 /goal 命令从单个提示符运行循环的支持。
• 开发者常用的循环：触发器和定时任务。 我询问了开发者们如何使用循环。大多数用例都涉及响应事件或运行计划任务。它们很有用，但感觉并不像是全新的工作流程。
• 对开发者有帮助的循环。 为新记录的应用问题打开 PR，在值班人员加入故障 Slack 频道时准备好笔记，“照看”和修复夜间端到端测试等等。
• 失望和“代币最大化”。 一些开发者在尝试循环算法后便放弃了它。Agent 漂移以及“人机交互”能带来更好的结果都是原因。此外，对于那些需要为代币支付 API 费用的公司来说，循环算法的成本会迅速飙升。
• 循环操作是否只是工具完善前的权宜之计？ 杰出工程师 Max Kanat-Alexander 认为，这种“循环”操作可能只是暂时的权宜之计，因为工具框架最终会添加从单个提示符执行相同操作的功能。
• 对开发者而言，“上下文工程”真的更重要吗？ 除了构建 AI 基础设施的工程师之外，深入研究循环工程似乎意义不大。相反，熟悉 AI 上下文窗口（这也是构建循环的一部分）可能更有用。

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

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

“Ralph 是一种技术。从本质上讲，Ralph 就是一个 Bash 循环： while :; do cat PROMPT.md | claude-code ; done 对于大多数公司而言，Ralph 可以替代大部分外包工作，尤其适用于全新项目。它确实存在一些缺陷，但这些缺陷可以通过各种提示方式识别和解决。 这就是拉尔夫的妙处——在一个非决定论的世界里，这种技术在决定论意义上是糟糕的。”

文章进一步阐述了拉尔夫循环的概念：

• 启动 Agent 时，发出一个能捕获任务并定义目标的提示词；
• 制定工作计划，每个项目都包含成功标准；
• 启动循环：
  • 每次循环取一个项目；
  • 当 Agent 完成任务后，检查目标是否达成；
  • 如果未达成：重新启动 Agent，并清除上下文窗口；
• 如有需要，启动子循环：根据需要生成子 Agent。

杰夫公布了他用这种方法所做的实验，例如构建一种新的编程语言，并表示这需要专业技巧：“工程师仍然是必需的。如果没有资深专家的指导，拉尔夫根本不可能完成这项工作。任何声称不再需要工程师，工具可以完成 100% 工作的说法，都是在胡说八道。”

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

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

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

1. 请 Agent 制定一份详细的工作计划，并将各项任务细分；
2. 然后按顺序让 Agent 在单独的运行中完成每个子任务。

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

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

这种工作方式更像是“动态看板”：

“拉尔夫方法”的核心在于绕过上下文窗口的限制。上下文窗口的最大容量有限，这对于复杂的任务来说远远不够，因此需要将 Agent 运行拆分成更小的单元，逐个运行。在这种情况下，拉尔夫方法发挥了作用：

• 为项目设定目标，并持续运行（或重新运行）Agent，直到达成该目标；
• 将以“压缩”方式完成的工作持久化到文件系统中（作为日志或更新后的计划）；
• 为 Agent 提供全新的上下文，以最大程度地减少“上下文腐烂”；
• 允许每个 Agent 根据需要添加或修改“总体规划”。

2. /goal 命令在所有主流框架中均有提供

几个月来，构建 Ralph 循环意味着要自己动手：设置循环、跟踪状态、决定 Agent 如何添加任务以及何时停止。但随着编码工具集开始原生支持，运行这些循环变得轻松多了。

四月：Codex 推出 /Goals

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

“在 Codex 中，目标是持续存在的，它能让一个线程在各个回合中朝着既定结果前进。目标为 Codex 设定了完成条件：什么应该为真，如何检验成功，以及哪些约束条件必须保持不变。”

文档中还提到：

“正常的提示是：接下来要做什么。

目标指示：持续工作直至达成此结果。在普通请求中，Codex 会执行当前指令，报告结果并等待。而有了目标，Codex 便拥有了一个持久目标。回合结束后，它可以检查证据并判断目标是否达成。如果未达成且在预算范围内，Codex 可以从最新状态继续执行。”

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

/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 Code 还发布了使用 /loop 命令调度 Agent 的概念。它本质上等同于 JavaScript 的 setTimeout() 函数：按照给定的时间间隔重复执行任务，直到工作完成。

到了五月份，运行 Ralph 循环已经变得像在主流 Agent 框架中输入一条命令一样简单。AI 实验室注意到用户希望简化 Agent 循环的操作，并开发了对应的方法。例如在 OpenCode 等开源框架中有 /goal 插件；对于极简编码 Agent Pi，也可以将 /goal 作为软件包添加。

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

到了五月份，我们已经可以使用 /goal 原语了。那么，Boris Cherny 和 Peter Steinberger 所说的把大部分时间花在设计循环而不是编写提示词上，指的是哪些用例呢？我向其他开发者询问了一些关于“循环工程”的例子。根据收到的回复，触发器和定时任务是两个非常常见的用例：

• 触发器 / 自动化： 当特定事件发生时启动 Agent。该事件可以是记录错误、创建新工单、收到客户支持反馈等。在 AI 出现之前，这些事件通常由 webhook 触发，启动 Slack 机器人发帖或 Zapier/n8n 集成。
• 定时任务： 许多开发者将“循环工程”视为按特定节奏启动涉及 Agent 的任务。这本质上与定时任务相同。工程总监 Oded Messer 表示：

“如果我的战略工作流程可以自动化，那么如果 AI 足够强大，它就能转化为战术流程；否则，它就只是我可以像设置定时任务或触发器一样设置的高级传统自动化流程。这个名称暗示着简单和重复。有时感觉 AI 爱好者们好像忘记了在 LLM 出现之前，自动化就已经存在了。”

4. 对开发者有用的循环

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

开发相关工作

• 针对新记录的应用问题提交 PR（软件工程师 Ivan Pantić）：

  “应用报错并创建 Sentry Issue → 定时任务指示 Agent 检查并提交 PR → 如果没有活跃 PR，Agent 处理该问题并创建一个 → 如果 PR 未被审核，Agent 通过 Slack 提醒开发者。在此流程中，一次只允许开启一个 PR。”

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

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

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

  “频道弹出新警报/异常 → Agent 进行调查 → 若涉及代码更改则直接实施 → 创建 PR → 通知人工审核。客户工单或事件也是同理，当你接到 Call 入场时，Agent 通常已经完成了问题分类并找到了根本原因。”

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

  “我最近经常做的是反复审查设计/实施计划。通常 Agent 在单次运行中只能发现少部分问题，所以我要求它们循环运行，直到单次运行中发现 0 个新的重大问题为止。”

日间/夜间工作

• 每日产品改进（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 的传统方式，而是创建了一项技能，让 Agent 在特定规则下自动识别一小块代码并进行转换，然后将这项技能挂载到定时任务上，每 30 分钟运行一次。这在认知上比管理大型迁移计划要轻松得多。”

生产力相关工作流程

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

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

5. 失望与“代币最大化”

尽管宣传铺天盖地，但并非所有人都买循环工程的账。几位工程师表示，在遭遇了几种可预见的失败模式后，他们放弃了相关实验：

• Agent 漂移（Agent drift）： 在缺乏人工持续监督的情况下，Agent 在多次循环迭代中经常偏离主题。它们会陷入修复不存在的 Bug 或重构可用代码的死循环中。

• 上下文腐烂（Context rot）： 随着文件日志和 PRD 跟踪器的增加，提供给 Agent 的提示词会被稀释，导致幻觉和推理质量下降。

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

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

“循环工程往往变成一场昂贵的代币最大化游戏。你花了 50 美元的 API 成本来节省 10 分钟的手动提示，结果却要多花一个小时去审查杂乱无章的 PR。”

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

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

杰出工程师马克思·卡纳特-亚历山大（Max Kanat-Alexander）指出，标准的基于 Bash 的循环（如 Ralph Wiggum）只是为了绕过早期上下文窗口限制和工具套件缺陷而设计的粗糙桥梁：

“早期的 Agent 无法保持状态或自主执行长运行任务，因此我们构建了外部脚本定期启动它们。既然现在的套件已原生支持 /goal 等原语，管理状态和重试循环的工作正在重新回归 Agent 框架本身。”

随着 Agent 环境的成熟，循环逻辑的手动脚本编写可能会被抽象并融入 Agent 的原生行为中。

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

对于大多数日常软件开发者来说，花数小时设计定制的循环架构带来的收益正在递减。相反，真正的杠杆来自于掌握上下文工程（Context Engineering）。

上下文工程侧重于：

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

除非你正积极构建 AI 开发者工具或 Agent 基础设施，否则痴迷于外层循环是次要的。对于软件工程师来说，掌握如何在现有的 /goal 和 /loop 套件中策划分配高质量的上下文，依然是最有价值的技能。

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

当 Agent 选错 Skill 时：四个修复方法

Skill 路由本质上是一个检索问题。本文从描述文本、负向边界、分层路由和召回重排四个层面，说明不同规模下如何减少漏选与误选。

继续阅读……