OpenClaw创始人斯坦伯格关于'loop工程'的推文引爆AI圈争议，这场关于'提示词已死'的论战背后，隐藏着AI Agent工作范式的根本变革。本文深度解析loop工程如何通过目标→行动→观察→评估→修正的闭环机制，让Agent在动态环境中实现自主迭代，并拆解构成有效loop的五大核心组件。

这两天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工程这个概念本身到底在说什么？它和编程里面的循环又有什么不同呢？

01 啥是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检查它们的进度和结果

02 提示词是输入，loop是过程

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

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

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

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

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

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

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

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

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

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

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

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

我举个例子你就懂了：

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

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

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

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

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

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

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

03 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。