最近两天，AI行业里“loop工程”突然成为热议焦点。
事情的起因是OpenClaw创始人斯坦伯格在X上发布了一句话：“你不应该再为编程Agent写提示词了。你应该设计循环来提示你的Agent。”
按理说这条推文发出后，评论区应该充满深度技术讨论。然而实际情况却演变成了一场激烈争论。
有人质疑，循环会消耗大量token，除非你拥有无限token，否则依然需要人工测试。也有人讽刺说，这不过是在炒作新概念，“loop工程会取代harness工程”的声音再次浮现。
目前这条推文的浏览量已突破800万。
事实上，最早提出“loop工程”这个概念的，是Claude Code的创始人鲍里斯。他在一次访谈中提到：“我现在已经不给Claude Code写提示词了。那些循环替我完成提示工作，让它们自己去判断具体要做什么修改。我的任务只剩下编写循环。”
显然，并非所有人都认同这个观点。毕竟距离上一个新概念“harness”被抛出，才过去一两个月。很多人还没来得及消化之前的内容，现在又要接受新事物，情绪反应激烈也在情理之中。
但抛开争议不谈，loop工程这个概念本身究竟在说什么？它和我们编程中的循环又有什么区别？
01
什么是loop？
先解决第一个问题：loop工程到底是什么？
loop这个词直译就是“循环”。Agent loop，说白了和编程里的循环是一个道理。
传统编程中，循环做的事情非常明确。比如你写一个for循环遍历数组，机器就会从第一个元素执行到最后一个元素。本质上，循环就是让机器重复执行一组明确的指令序列。
在AI Agent的语境下，loop也是重复执行。那差别在哪里？
区别在于，Agent中的loop执行的不是“指令”，而是“目标”。通过下面这样一个循环，把输出的结果不断向目标逼近。当结果符合目标时，循环终止：
目标 → 行动 → 观察 → 评估 → 修正 → 下一轮行动
这个公式里的每一步都不是固定的。Agent需要观察当前状态，判断该采取什么行动，执行后再看结果，评估是否达到预期，然后决定下一步怎么走。
而传统循环中，每次执行的代码逻辑都是固定的。虽然你可能会处理不同的数据，但处理方式完全一样。这就要求你提前把所有可能的情况都考虑周全，再写出对应的逻辑——比如遇到A情况怎么处理，B情况怎么处理，这就是编程中的if和else。
但现实世界的复杂任务往往充满变数，你不可能预判所有情况。一旦出现你没想到的情形，程序就会出BUG。
Agent loop的价值就在这里。你不需要把所有情况都写死，只需给Agent一个目标，提供必要的工具和上下文，然后让它自己在循环中探索。它可能会走弯路，可能会犯错，但只要反馈机制和评估标准到位，它就能在多次迭代中逐步逼近正确答案。
这种方法在处理开放性任务时尤其有效。写代码、修复bug、做研究、搭建产品——这些任务的共同点是，没有唯一正确的路径，需要在过程中不断调整方向。传统程序很难应对这种不确定性，但Agent在循环中可以。
澳大利亚有位叫杰弗里·亨特利的“放羊大叔”，他在2025年7月发布的Ralph，就是一个典型的Agent loop。它本质上是一个bash脚本，将同一个提示词文件反复输入给Agent。但真正的创新在于它的纪律性：每次迭代都会重置上下文到一组固定的锚点文件，而不是让对话无限增长。为了验证Ralph的能力，杰弗里用这个方法构建了一整门编程语言，总共花费约297美元。
这个案例说明，loop的核心价值不是让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。
