2026年6月, 有一个新词开始热门起来了。该新词是Loop Engineering（循环工程）。

它的核心主张, 听起来, 近乎挑衅, 你不该再亲自给AI写提示词了。

引发事情的那个引爆点, 是来自 OpenClaw 的作者 Peter Steinberger, 他所发布的一条推文, 这条推文的阅读量达到了八百万人, 内容是: 你不要再去亲自给编程 Agent 撰写提示词了，你得去设计那个驱动 Agent 的循环。

在几乎是同一的那一刻, Claude Code 的负责人那个人Boris Cherny, 于公开的诸多场所, 是这样进行表明的:

这堆循环会自己提示 Claude, 这堆循环会自己判断该怎么做。他不再亲自给 Claude 写提示词以后, 他仅有的一项工作就是写这些会自行提示 Claude、自行判定该做什么的循环的代码。

6月7日, Google的工程师Addy Osmani他在博客当中, 针对这件事情正式赋予了一个称之为Loop Engineering的名字。

之后, Anthropic的工程师将这套实践编撰成了一份完备的手册:

https://drive.google.com/file/d/1qzKI4DKnyHRpXK1J3ATPqwaqLc0iNu-M/view?pli=1

我们把手册里最有价值的部分整理成了这篇文章：

读完之后, 你大概就会清楚, 究竟是为何, 一线的工程师, 正从那个「写提示词的人」, 转变成为「设计循环的人」！

什么是循环工程

过去两年，AI 圈冒出了一堆 XX 工程。

先是提示词工程, 它会教导你如何才能够把一句提示撰写得很好；后来是上下文工程, 它着重于去研究应该往模型的窗口之中放入什么内容、又该删除什么内容；再后来是Harness工程, 它所关心的是一次Agent运行之时应当携带哪些工具、处于什么样的状态才算是完成。

但循环工程切入的角度，不太一样。

工程, 提示词工程、上下文工程、Harness工程背后, 其本质, 都在讲同一件事儿, 到底是件什么事儿着呢: 如何利用工程的途径, 以此方式, 怎样给AI提供最为合适的输入。它们, 这些工程, 全部默认, 内里都相当于有一个人稳稳坐在键盘跟前, 逐行逐行地去指挥Agent。

但循环工程把这个人从位置上删掉了：

你不再身处循环之内，而是站在循环之外，去构建那个循环本身。

也就是说, 原先你所撰写的内容, 并非是给予Agent的提示词了, 原先是给出提示词, 现在变成了一个系统, 啥啥系统, 是一个能够自动朝着Agent发送提示词的系统。而且, 从前你身为那个撰写提示词的人, 目前, 身份已然改变, 变成了去设计让AI自动撰写提示词的人。

将这四个工程放置在一处, 能够采用一个金字塔予以理解, 自下而上, 每一层所关注的事物均比下一层大上一圈。

最底下的是提示词工程, 其所关心的一句话究竟应该怎么去表述。往上的是上下文工程, 它所关心的是一个窗口里面该装入些什么东西。再往上的是Harness工程, 它所关心的是一次运行应该携带什么样的工具, 以及要怎样从失败当中恢复过来。

并且处于最上方位置之处, 则是具备相当关键性质的循环类工程, 其核心在于着重关注如何促使一切情形能够自行反复不断地运转起来。

于循环工程的全新世界当中, 所设计的系统能够自行运转, 它是被定时之任务唤醒的, 在循环之内生成子 Agent 去工作, 随后将这一轮次的结果馈送给下一轮次。

那么，为什么这个词偏偏在这个时候冒出来？

这是由于, 在过去的半年里头, 围绕着Agent的工具, 悄然之间跨越了一个临界点。

1. 模型, 比较可靠, 编程Agent, 同样蛮可靠, 二者结合, 足够可靠到家, 可在无人全程留意监督的状况下, 去把一件完整的任务给完成掉。

2. 单次运行一个 Agent 所产生的成本降低到了足够低的程度, 因而一而再、再而三地依照定时器来运行任务, 便不再给人以浪费之感了。

3. 主流工具具备了定时调度这种能力, 这使得定时让 Agent 按照循环的方式去执行任务成为了可能。

所以, 当零件全部到位之时, 将它们拼接组合起来的这个行为动作, 自然而然地便会一下子在许多人的脑海之中涌现出来。

它的名字总是比实践滞后几个月, 那时候, 早已有前沿的工程师在写循环了。在有人喊它循环工程之前, 情况就是这样。

如何搭建循环工程

讲到循环这个词汇, 极易使人误解为呈空转状态, 可是实际上它每转动一回都在施行具体的事宜。

具体的，Anthropic 的手册把循环拆成了五个动作：

1、发现：自己找出这一轮值得做的活；

2、交接：把任务移交出去，并且互相隔离；

3、验证：引入另一个 Agent 来说不；

4、持久化：把状态写到对话之外的地方；

5、调度：让它一轮接一轮地转下去。

这五个动作里少了任何一个，循环要么转不动，要么在原地打转。

在这儿存在着, 这样的一个, 非常不错的, 示例情形, Osmani借助这款模式, 为自身架构起, 如同早晨时间段开展的, 那种分诊循环流程:

每日清晨时分, 他会触发一项自动化定时任务, 从而去读取前一日遭遇失败的CI测试, 以及仍然呈开启状态的issue, 还有近期的提交内容, 而后AI会将具备处理必要性的事物撰写至一个Markdown文件之中。

为每一项, 针对循环工程开启一个单独性成立地git工作树: 有一个子Agent去着手开展进行起草式的修复行为动作, 致使第二个子Agent用于对照测试作出审查的相关工作, 之后进而进行自动开启PR以及更新工单的相关事宜。针对于循环工程没有办法能够处理的内容, 会将其投递发送至收件箱等待人员去完成处理工作事项, 与此同时, 状态文件会予以保留留存, 以等待到第二天等人确认好了之后随后接着去开展下一件工作。

全都的循环进程, 全部过程都用不着人去插手处理, 然而它会在恰恰到达该等待人的那个地方之时停下来。

手册也给出了这个例子和循环工程五个动作的对应关系：

搭建循环工程的关键

要是打算从这本手册当中挑选出最为具价值的那一个段落, 那么便是有关「验证」的这一部分内容。

Anthropic的工程师Rajasekaran, 在进行长时间运行的应用时, 发现了这样一个现象, 即每当让一个Agent为自己刚写出的内容打分, 这个Agent几乎总是满心自信地自我夸赞, 可是对于人而言, 一眼就能看出其质量呈现出平庸的状态。

为什么会这样呢？

当代码被创作出来之际, Agent里边的上下文已然充斥着「为何得这般写」的诸多缘由, 故而当它回头审视自身输出之时, 所见到的并非结果, 而是那串说服自身的链条。

而这个问题, 在循环工程这个范畴当中, 是会被无限放大的: 要是每一次「这够好了吗」这个判断环节, 都是由刚刚写完的那个Agent去决定的话, 那么它在每一轮都会对自身所做出的判断表示认同, 如此一来, 随着运行的时间越久, 最终就会致使整体输出的质量变得相当差。

尝试让生成器对待自己更加严厉的 Rajasekaran, 所收获的效果糟糕透顶。其随后转变了思维, 进行调教以使一个独立的评估器对所有事物持怀疑态度, 然而这反倒变得轻松许多。

这里的核心思路是, 你没办法去要求一个 Agent 跳出它自身的视角, 可你能够换一个 Agent 进来, 因它会带着全然不一样的指令, 从零点开始审视这段代码。这个原则在银行业也有一个称谓, 叫做制衡原则, 几十年前银行就做出规定, 录入一笔大额转账的人与审核这笔转账的人必须是两个不同的人。

针对评估而言, 在社区当中, 存在着这样一种常常会被运用的校准方式, 那便是, 直接向评估器传达相关信息, 设定默认的假设情况为本段代码是存在问题的, 一直持续到它被证实不存在问题为止。

在这同一时段, 单单启用一个单独的评估器是不足够的, 还得促使它运用恰当的工具去开展评估:

倘若评估器仅仅读取代码, 那它所判断的乃是「这看上去是否正确」, 而非「它运行起来是否正确」。故而在此处还得引入真正的代码: 于前端任务当中, Rajasekaran将评估器连接到了Playwright, 使得它能够切实地打开页面、点击按钮、进行截图、检查DOM，如同一名QA工程师那样开展工作。

Claude代码, 将这一套生成以及评估的结构, 转变成为了一个名为/goal的命令, 给予Agent一个停止条件, 使其持续运行直至满足该条件为止, 并且由一个全新的小型模型判断条件是否成立, 并非是负责工作的那个模型进行判定。

如果用一句话总结这部分，那就是：

让生成器决定循环能产出什么，让评估器决定它不会产出什么。

这也正是为何可以讲评估是达成循环工程的重要所在, 评估器, 它定夺了循环工程的最低限定。

循环工程的最佳实践和建议

此外，手册里提到了关于循环工程的一些最佳实践：

第一个经验：该让模型自动触发什么。

返回到先前那个名为Osmani的晨间进行分诊的案例, 于此存在着一个需要予以留意的细节, 且此细节值得去留意：

导致自动化触发的应当是一项技能, 并非是那一堆无人在意的指令, 这是由于技能具备可复用性, 还具备可维护性。

第二个经验，是什么可以信任模型，什么不可以。

不得不说起 Stripe 的 Minions: 他每一周合并的 PR 数量都超过 1300 个, 然而却看不到半行是人工手写而成。并且他的循环工程其触发的方式十分轻缓: 仅仅是在 Slack 里面通过 @ 一下该机器人 , 或者添加个 emoji 符号反应便可以达成。

这里, 他使模型稳定运行的关键在于, 对于能够通过硬编码解决之事, 绝对不会交给模型来处理。

所以他向来都不会让LLM自行去寻觅上下文, 缘由在于模型无法被控制。Stripe的举措是, 于模型被定时任务激发之前, 先凭借一段具有确定性的编排逻辑将上下文装配起来，其步骤依次为: 扫描链接、拉取Jira、查阅文档、确定相关代码。

另外, 他存在这样一个核心习惯, 那 1300 个 PR 依旧是人来进行审阅, 因为极为重要的判断工作, 绝对不允许交由模型, 不能交！

第三个经验：如何让循环真正在你睡觉时还在跑。

不少人觉得在本地持续地反复运行 /loop 就等同于令循环为自身去值夜班。然而, 本地的循环是需要机器始终保持开启状态的, 一旦你合上了笔记本的盖子, 那么它就会停止运行。

所以, 倘若你想要那种在你进入睡眠状态时能够真正运行起来的循环工程, 那你就必须借助云端的定时调度, 或者使用GitHub Actions。

这是第四个经验, 要留意循环工程所带来的隐形成本, 循环愈是好用, 便愈发危险。

为何会这样呢, 是由于循环进行得越是畅快, 所犯的错误就越发难以被察觉，存在着四笔隐形账单, 在其运行之际绝对不会给予你提醒。

第一种是验证债务；每个由AI生成的、被合并的PR都节省了你的时间；然而节省下来的这些时间；常常变成了一堆无人验证的代码；这些代码有可能在某一天就成为线上的超级Bug ；要怎样避免呢；建议定期复盘AI生成的内容。

排在第二类位置的是用进废退这种情况。你要是越发习惯于借助AI去编写代码, 那你便更不善于依靠自身独立编写代码了。怎样去防止出现这种状况呢? 每天阅读一段具备代表性的代码, 迫使自己进行相关方面的练习。

第三种情形是认知方面的投降行为。这种循环工程越是具备可靠性, 那么你往往就越发容易去放弃自身原本所拥有的判断, 也就是它生成什么样的内容, 你便使用什么样的内容。针对这样的一个问题而言, 所给出的建议便是要给自己预留出一条底线, 即这种循环能够协助你去执行相应的任务, 然而却不能够替代你去做出决策。

第四种情形为Token爆炸, 循环一次次地运行的确会造成诸多消耗，特别是某些意外状况, 像一个bug便能够空转一整晚, 如此一来, 到了第二天, 你所获取的并非修好的代码, 而是一张意外的发票。针对此情况, 建议在循环启动前设定硬上限, 其所涵盖的有每次运行的预算、每日的预算以及最大重试次数。

手册里最后提到：

就同一个循环而言, 由两个人去搭配完成, 结果有可能走向全然相反的结局, 与之无关是这个循环自身, 存在这种情形~

其以循环之手段, 旨在于自身已然领会之事上愈发迅速前行, 此人阅读代码之际, 具备方向感, 明晰何处应予以置信, 何处应予以停驻, 循环所扩充的, 乃其原本便存在的判断力。

再有一个人运用同样的那种循环, 目的在于自此往后无需再去理解, 代码能够被生成, 计划能够被生成, PR能够被生成, 修复同样能够被生成。六个月过去了, 前面那个人变强大了, 后面那个人成为了一台连自己都看不懂的机器的看守人员。

把生成这件事情变得极为简单的是循环, 几乎将门槛给抹平了。稀缺的剩下的是判断力, 清楚哪个方案是正确的、哪一条线应当停止、要知道哪个输出能运行但从根本上就是错误的。

所以这份手册最重要的一句话是：

去搭你的循环，但要像一个打算继续做工程师的人那样去搭它

——而不是一个只会按启动键的人。

- 完 -