这两天，AI领域悄然掀起了一股“Loop工程”的热潮。

这场讨论的导火索，源于OpenClaw创始人斯坦伯格在X平台上发表的一个观点：“你应当停止为编程Agent撰写提示词。相反，你应该设计一套循环机制（Loop）来驱动你的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中自主探索。它可能会走弯路，也可能会犯错，但只要具备反馈机制和评估标准，它就能在多次迭代中逐步逼近正确答案。

这种工作方式在处理开放性任务时尤为高效。编写代码、修复漏洞、开展研究、搭建产品——这些任务的共同特点是没有唯一的正确路径，需要在过程中不断调整方向。传统程序很难应对这种不确定性，但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。