什么是 Loop Engineering？解析 Codex goal 模式的工作原理与场景

最近，你可能刚接触到这样一个新词：Loop Engineering，也就是“循环工程”。
简单来说，就是给 AI 定义一个目标，然后让模型自己反复迭代，直到目标达成。

Agent 本身就具备多轮执行能力，那么 Loop Engineering 和它到底有什么不同？
下面我们就结合 Codex 中的 goal 模式来把这事讲清楚。

基本概念

追根溯源，Loop Engineering 并不是某家公司官宣的正式术语，它的流行更多来自几位技术大牛的公开观点。
Claude Code 的负责人 Boris Cherny 就曾说过：

我不再提示 Claude 了。我运行循环来提示 Claude 并让它自己决定该做什么。我的工作就是编写循环。

OpenClaw 的作者 Peter Steinberger 也说：

你不应该再提示编码智能体，而应该设计循环来提示它们。

Google Cloud 工程负责人 Addy Osmani 专门写了一篇题为《Loop Engineering》的文章，把这一概念阐述得更加系统。
在他看来，一套理想的 Loop Engineering 机制应该包含以下几点：

• 能够按计划自动运行，自行发现并分类故障。
• 具备工作树，防止两个并行的代理互相干扰。
• 拥有技能库，把原本靠模型猜测的项目知识固化下来。
• 提供插件和连接器，让 Agent 接入你已经在用的工具。
• 支持子代理，一个提想法，另一个做验证。

不过这些描述还偏概念，我们再看看到底是怎么实现出来的。

机理分析

要想从技术机理上理解 Loop Engineering，最直接的方法就是用 AI 去读 Codex 的开源代码。
Codex 内置了一个目标（Goal）模式，你可以在 App 中手动开启。

开启 goal 模式后，整个执行流程如下：

和普通模式比起来，goal 模式的提示词不会直接透传给模型，而是在外层先被解析成一系列 goal 控制命令，具体包括：

• /goal：设定目标
• /goal edit：编辑目标
• /goal pause：暂停目标
• /goal resume：恢复目标
• /goal clear：清空目标

底层靠一个额外的状态机来判断目标有没有完成。如果当前处于正在执行的 active 状态，就会自动进入下一轮循环。

状态	含义	自动续跑
active	正在执行	是
paused	用户主动暂停	否
blocked	模型或系统认为无法继续	否
usageLimited	账户/使用额度限制	否
budgetLimited	Goal token 预算达到	否
complete	目标完成	否

goal 模式本质上是对普通模式的增强——普通模式只包含一个会话轮次（turn），而 goal 模式下可以自动拉起多个连续 turn。

普通模式里，随着上下文不断增长，模型很容易忘记最初的要求，从而提前停掉任务。而 goal 模式增加了一层外层调度，把目标状态独立出来，不再完全依赖对话历史，因此能够扛住跨 turn、上下文压缩带来的干扰。

实际体验

当你发现一个任务单次对话根本做不完时，就可以考虑开启 goal 模式。
举个我最近的真实例子：我写了一个网站，需要让 AI 帮我查询大量数据。在普通模式下，它还没跑完就主动停止了，然后告诉我“尚未查完”。

切到 goal 模式后，它一口气连续跑了 1 小时 37 分钟，直到把任务彻底搞定才罢休。

适用场景

当然，goal 模式的代价也很明显：要比普通模式消耗更多 token 和运行时间。如果一直开着 goal 模式，它可能会去干一些边际收益很低的事——比如反复运行测试、为了证明完成而添加额外的验证步骤。

而且 goal 模式也不是万能的，它对提示词的要求反而更高。如果你只是写一句：

优化这个项目

模型根本不知道你期望的方向在哪，一旦中间某一步的理解出现偏差，这个偏差就会在循环中被不断放大。

它更适合那些有清晰终点的任务，比如：

完成 TypeScript 迁移；strict 编译通过；不存在 explicit any；测试全部通过。

所以，当你需要执行一个耗时较长、中间不需要人工确认干预的操作时，开启 goal 模式会是一个很趁手的选择。

如果你想深入探讨这类自动化循环工程的实践，欢迎到 云栈社区 与更多开发者交流。