龙虾创始人一条推文引800万人围观，全网都在吵的loop工程到底是个啥？

这两天，AI圈突然刮起了一阵“loop工程”的风。

事情的起因，是OpenClaw的创始人斯坦伯格在X上抛了个观点：“你不应该再给编程Agent写提示词了。你应该设计循环来提示词你的Agent。”

按常理，这种前瞻性的观点底下应该是技术讨论的热闹场景。但现实是，评论区直接变成了一场混战。

有人质疑：loop消耗的token量可不是小数目，除非你有无限的token，否则还是得人工测试。也有人讽刺这是新一轮的概念炒作，“loop工程取代harness工程”的口号听着就耳熟。

这条推文目前的浏览量已经冲到了800万次。

实际上，“loop工程”这个词最早是Claude Code的创始人鲍里斯提出的。他在一次访谈中说过：“我现在已经不给Claude Code写提示词了，那些loop替我写，由它们去判断具体要做什么修改。我的工作只有写loop。”

显然，并不是所有人都愿意为这个新概念买单。毕竟距离上一个热词“harness”出现，也不过一两个月的时间，大家还没来得及消化，就要迎接新知识了。

不过话说回来，争议归争议，loop工程这个概念本身到底在说什么？它和我们熟悉的编程循环又有什么不同？

啥是loop？

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

loop这个词直接翻译过来就是“循环”。Agent loop，其实和编程里的循环（loop）在本质上是一回事。

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

在AI Agent的语境里，loop也是重复执行。那么两者的区别在哪？

关键区别在于：Agent里的loop执行的不是“指令”，而是“目标”。它通过一个循环，将输出的结果不断接近目标。当结果符合目标时，循环终止。这个过程可以概括为：目标→行动→观察→评估→修正→下一轮行动。

在这个公式里，每一步都不是固定的。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。