文 | 字母 AI

这两天 AI 圈有个词特别火，叫做 loop 工程。

起因是 OpenClaw 创始人斯坦伯格发了条 X，说 " 你不应该再给编程 Agent 写提示词了。你应该设计循环来提示词你的 Agent。"

然而本以为评论区会是一片欣欣向荣，大家积极讨论 loop 工程。

实际情况则是，这条 X 下面变成了一场混战。

有人质疑 loop 会消耗大量 token，除非有无限 token 否则还得人工测试。有人讽刺这又是炒作新概念，"loop 工程会取代 harness 工程 "。

这条 X 如今已经达到了 800 万次浏览。

最早提出 loop 工程这个词的人，其实是 Claude Code 的创始人鲍里斯。

他曾经在一次访谈中提到，" 我现在已经不给 Claude Code 写提示词了，那些 loop 替我写，由它们去判断具体要做什么修改。我的工作只有写 loop。"

很显然，并不是所有人都为 loop 工程买账，毕竟从上一个新概念 "harness"，到现在也只不过才一、两个月。

大家还没来得及消化此前的内容，现在就要去接受新知识。

但争议归争议，loop 工程这个概念本身到底在说什么？它和编程里面的循环又有什么不同呢？

啥是 loop？

先解决第一个问题，loop 工程到底是个啥？

loop 这个词直接翻译过来是循环。

Agent loop，其实和编程里的循环（loop）差不多。

在传统编程里，循环做的事情很明确。

比如你写一个 for 循环遍历数组，那么机器就会从第一个元素走到最后一个元素。编程中，循环的本质是让机器重复执行明确的指令序列。

在 AI Agent 的语境里，loop 也是重复执行。

那么两者的区别在哪呢？

事实上，Agent 里的 loop 并非执行 " 指令 "，它执行的是 " 目标 "。通过如下的一个循环，将输出的结果不断接近目标。当结果符合目标时，循环终止。

目标 Goal → 行动 Action → 观察 Observation → 评估 Evaluation → 修正 Revision →下一轮行动

这个公式里的每一步都不是固定的。

Agent 需要观察当前状态，判断应该采取什么行动，执行行动后再观察结果，评估是否达到了预期，然后决定下一步怎么走。

而传统循环里，每次执行的循环，都是相同的代码逻辑。虽然你可能会处理不同的数据，但处理的方式都是固定的。

所以你就需要把所有可能的情况都考虑清楚，然后写出对应的处理逻辑。

比如碰见 A 情况怎么应对，B 情况怎么应对，而这便是编程循环中的 if 和 else。

但现实世界的复杂任务往往有太多变数，你不可能提前预见所有情况，这就导致出现你没有设定过的情况时，程序就会出 BUG。

Agent loop 的价值就在这里。

你不需要把所有情况都写死，你只需要给 Agent 一个目标，提供必要的工具和上下文，然后让它在 loop 里自己摸索。

它可能会走弯路，可能会犯错，但只要有反馈机制和评估标准，它就能在多次迭代中逐渐逼近正确答案。

这种工作方式在处理开放性任务时尤其有效。写代码、修 bug、做研究、搭建产品，这些任务的共同特点是没有唯一的正确路径，需要在过程中不断调整方向。传统的程序很难应对这种不确定性，但 Agent 在 loop 里可以。

澳洲放羊大叔杰弗里 · 亨特利（Geoffrey Huntley）在 2025 年 7 月发布的 ralph，就是一个典型的 Agent loop。

它本质上是一个 bash 脚本，把同一个提示词文件反复输入给 Agent。但它的真正创新在于纪律性，每次迭代都会重置上下文到一组固定的锚点文件，而不是让对话无限增长。

为了验证 ralph 的能力，杰弗里用这个方法构建了一整个编程语言，总共花了大约 297 美元。

这个案例说明，loop 的核心价值不是让 Agent 变得更聪明，而是给 Agent 创造了一个可以持续改进的环境。

在这个环境里，Agent 不需要一次就做对，它可以试错，可以从失败中学习，可以在多轮迭代中积累进展。

到了 2026 年春天，Codex 和 Claude Code 都推出了 /goal 命令，把 ralph 给产品化了。这个命令会一直运行循环，直到一个验证完成。

但斯坦伯格说的 loop，已经不单单是 " 让一个 Agent 反复做某个任务 " 那么简单了，而是把 loop 当成一种可以长期运行、互相协作、自动调度的 AI 工作系统。

具体来讲，斯坦伯格认为 loop 是工作的基本单位。

以前我们给 AI 下达的指令是帮我修一个 bug、帮我写一篇文章。所有任务是一次性的，做完就结束。

但斯坦伯格说的 loop，虽然也是任务的一种，不过它是一个持续运转的工作单元。比如每天检查 GitHub issue，判断哪些需要修，自动分配给 Agent，修完后跑测试，失败就继续改，成功就提交 PR。

这里的重点不再是 " 修某一个 bug"，而是有一个长期存在的流程在处理一类工作。

当你有了多个这样的 loop 在同时运行时，新的问题就出现了。谁来协调它们？谁来决定优先级？谁来检查它们的工作质量？

因此，斯坦伯格在设计 loop 时，已经开始用 loop 去监督其他 loop 了。

通过一个总 loop 负责观察全局→它发现有几个任务→分发给多个子 loop →每个子 loop 自己跑→总 loop 检查它们的进度和结果

提示词是输入，loop 是过程

斯坦伯格的那条推文之所以引发争议，是因为它触及了一个话题。

提示词工程是不是已经过时了？

截止至今，提示词仍然是你和 Agent 交流意图的主要方式，它仍然需要清晰、具体、包含必要的上下文。

这么说吧，一个写得很烂的提示词，绝对不会因为你把它放进 loop 里，它就能突然变好了。

但单次的提示词，已经不再是 Agent 的核心。

原因很简单，假如你能在一开始就把所有要求说清楚，Agent 只需要一次输出，就满足你的所有要求，那就再也不需要上下文了。

现实就是，你可能在看到初步结果后才发现自己遗漏了某个重要条件，或者 Agent 的输出虽然符合你的字面要求，但在实际使用中暴露出问题。

更关键的是，很多反馈信息在任务开始时根本不存在。

比如 BUG，你只有在测试的时候才能知道。

以前你需要盯着 Agent 的每一次输出，判断对不对，想下一步怎么引导它。

现在你只需要设计好 loop，定义清楚目标和评估标准，然后让它自己跑。

归根结底，loop 工程就是给 Agent 加一个框架，让它知道每一轮应该看什么、做什么、怎么判断、什么时候停。

我举个例子你就懂了：

你要让 Agent 生成一个登录页面。

提示词工程的做法是写一个详细的提示词。" 请帮我写一个登录页面。需要有用户名和密码输入框，一个登录按钮，一个忘记密码链接。样式要简洁现代，使用蓝色作为主色调。要有表单验证，用户名不能为空，密码至少 8 位。登录失败要显示错误提示。"

如果你的提示词写得足够好，Agent 可能会生成一个看起来不错的页面。

但这个页面真的能用吗？表单验证的逻辑是否正确？在不同浏览器上显示是否正常？是否有安全漏洞？

loop 工程的做法是你需要设计一整个流程。

第一步，根据需求生成页面代码。第二步，运行自动化测试，检查基本功能是否正常。第三步，启动浏览器，截图检查视觉效果。第四步，如果测试失败或者截图显示问题，分析具体是什么问题。第五步，修改代码解决问题。第六步，再次测试，重复这个过程，直到满足所有验收标准。

在这个流程里，初始的提示词可能很简单，因为你知道后面还有多轮迭代的机会。Agent 不需要第一次就做对所有事情，它可以在每一轮看到具体的反馈，然后针对性地改进。

loop 工程在设计什么

那到底该如何写一个 loop 工程呢？

我们需要设计 5 个组件。

第一个组件是目标。

这听起来是废话，但实际上很多 loop 失败的原因，就是目标定义得不够清晰。

" 帮我优化一下 " 这不是一个好目标。什么叫优化？优化到什么程度算完成？有哪些约束条件？这些都不清楚。

一个好的目标应该是这样的。把这个接口的响应时间从 800 毫秒降到 300 毫秒以下。保留现有行为，所有测试必须通过。输出改动说明，列出具体做了哪些优化。

这个目标的每一部分都是可验证的。

清晰的目标实际上是给 Agent 提供了一个稳定的锚点，每一轮迭代都可以用这个锚点来校准。

第二个组件是上下文管理。

上下文其实包括很多东西，不只是你跟模型的对话那么简单。

代码库的当前状态、相关文档、需求说明、错误日志、测试结果、用户偏好、历史决策，以及之前几轮的尝试和结果，这些都是上下文。

很多 Agent 表现差，根本原因不是模型不够聪明，而是 loop 每一轮喂给它的上下文太脏、太少，或者太随机。

太脏是指上下文里混杂了太多无关信息，Agent 需要花费大量 token 来处理这些噪音，反而忽略了真正重要的部分。

太少是指关键信息缺失，Agent 没有足够的材料来做出正确判断。

太随机是指每一轮的上下文组织方式不一致，Agent 无法建立稳定的理解模式。

前文提到的 Ralph loop，它有一个很重要的创新，就是它的上下文管理系统。

它每次迭代都会重置上下文到一组固定的锚点文件，而不是让对话历史无限增长。

虽然简单，但它的确解决了上下文污染的问题。

你需要决定哪些信息应该保留，哪些应该丢弃，哪些应该总结后保留。

2026 年的 loop 系统开始使用基于 git 的状态管理。每一轮的改动都会提交到 git，Agent 可以查看历史提交，理解之前做了什么，为什么要这么做。

第三个组件是工具。

说白了就是 Agent 能调用哪些工具。

巧妇难为无米之炊，工具的选择需要和任务匹配。

如果你让 Agent 写代码但不给它运行测试的工具，那它就无法验证代码是否正确。

但工具也不是越多越好。每增加一个工具，Agent 的决策空间就变大了，它需要在更多选项中做选择。如果工具太多，Agent 可能会迷失在工具的使用上，忘记了真正的目标。

好的 loop 设计会精心选择工具集。只提供完成任务必需的工具，每个工具都有清晰的用途和使用时机。这样 Agent 可以把注意力集中在任务本身，而不是工具的选择上。

第四个组件是评估。

这是 loop 的灵魂。没有评估，循环就会变成瞎转。

评估的关键是要自动化。

如果每一轮都需要人来判断对不对，loop 就失去了自主运行的能力。所以你需要设计出可以自动执行的评估标准，让 Agent 能够自己判断当前状态是否满足要求。

但自动化评估也有局限。有些质量标准很难用量化的标准来判断，比如代码的可读性，设计的美感，文字的流畅度。

对于这些方面，你可能需要引入人工检查点，让人在关键节点介入评估。

AI 里面有一个概念叫 human-in-the-loop 的。

好的 loop 不是把人踢出去，而是把人放在最关键的检查点上。自动化处理大部分常规判断，人负责那些需要主观判断或者风险较高的决策。

第五个组件是停止条件。

从最古老的编程开始，任何一个循环它都得具备一个退出的条件。

比如循环计数器 i，每一次循环 i 的数值都会加 1，当 i 的值大于规定的值时，循环就会停止。

对于 Agent 而言，最理想的停止条件是任务完成，但现实往往不会这么顺利。

有时候 Agent 会陷入死循环，反复尝试同样的方案，每次都失败，但它不知道应该放弃。有时候 Agent 也会持续做微小的改动，每次都有一点点改进，但永远达不到完美，不知道应该停在哪里。

所以你需要设计多种停止条件。

最直接的是成功条件，所有评估都通过，任务达标，可以停了。然后是失败条件，连续多轮没有改进，或者错误次数超过阈值，说明当前方案可能走不通，应该停下来重新思考。

还有资源限制，运行时间超过上限，成本超过预算，也应该停止。

更重要的是风险检查点。当 Agent 要做一些高风险操作时，比如删除数据，应该停下来等待人工确认。这些操作一旦出错代价很大，不应该完全自动化。

把这五个组件放在一起，你就得到了一个完整的 loop。