智东西6月15日报道，Google Cloud AI总监、前Chrome工程负责人Addy Osmani前段时间发表长文，系统阐述了最近火爆AI圈的Loop Engineering（循环工程）。
过去两年，很多开发者跟编程Agent打交道的方式是：写好提示词、塞够上下文、敲回车、读返回结果，然后再敲下一句，Agent是手上的工具，很多人全程握着它。
而现在，有人觉得这套流程已经快走到头了。
OpenClaw创始人Peter Steinberger最近说了一句话：“你不该再亲自给编程Agent写提示词了。你应该设计Loop，让Loop替你去写。”
Claude Code之父Boris Cherny说得更直白：“我已经不给Claude写提示词了，我有Loop在跑，它们自己决定该干什么，我的工作是写Loop。”
一时间，Loop Engineering风靡AI圈，Addy Osmani随即撰写文章，来解读这个继提示词工程和Harness工程之后又一个爆火的“新词”。
但对于这个看起来能让日常工作全自动运行的提效模式，Addy Osmani在解读的同时，非常认真地提出了其可能会带来的负面影响，如果用一个很形象的词来总结，就是Loop虽然很好，但是不要被其诱惑，变成不会思考、只会点“开始键”的人。
下面是文章的编译，智东西做了不影响原意的改编：
Loop Engineering由5个部分组成，核心是让Agent自己去发现、分发和检查工作，随后定义完成状态，最终决定下一步干什么。五个部分分别是：自动化、工作树、skill、插件和连接器、子Agent，外加一个跨会话的记忆层。
这些东西听起来复杂，实际上在现有的Agent产品中都已经很成熟了，诸如在Codex和Claude Code中，开发者需要做的，只是把它们拼接起来。
而且在大多数情况下，这些“积木”的底层逻辑是相同的，这意味着开发者完全不需要为“使用哪个“AI工具”而纠结，也不用担心换工具的问题，只需要设计Loop，跑通后，在哪个工具里都可以运行。
详细说说这五块积木吧：
1、自动化。或者可以叫心跳、定时任务。它在固定的时间点或者特定事件发生时自动触发，让Loop真正成为一个自行运转的“Loop”。
在Claude Code里有很多种用法，用/loop跑定时任务，用cron做调度，用hook在Agent生命周期关键节点触发，或者推到GitHub Actions，电脑合上了也可以继续跑。
还有一个很重要的模式：/goal。它不按时间触发，而是一直运行到最开始所制定的标准真正完成为止。每跑完一轮，会有一个独立的Agent判断是否完成，Claude Code和Codex都有这个玩法。
如果说自动化负责开启Loop，那么剩下的四块积木就负责执行工作完成Loop。
2、工作树。当开发者同时跑两个以上Agent的时候，时常会出现两个Agent写同一个文件的撞车问题。
Git worktree的思路是在同一个仓库历史上切出一个独立的工作目录，一个Agent的修改完全碰不到另一个的工作内容，等于给每个Agent配了自己独立的工位，互不干扰。
3、skill。skill是把开发者对于整个项目的要求，诸如代码风格、规范、架构、踩过的坑等等这些打包展示给Agent看的关键功能。Agent每跑一遍都读一次，无需每次都重新输入。
如果没有skill，Loop每一轮都要从零推导项目该怎么做，有了skill，它每一轮都会吸取上一次的经验。
4、插件和连接器。这决定了Loop能不能碰到真实的工具，一个只能看文件系统的Loop是个小Loop，能操作工具干活才是真正的Loop，连接器基于MCP协议，让Agent能读取Issue Tracker、查数据库等等。
5、子Agent。Loop中非常关键的的一步：把写代码的和检查代码的拆成两个Agent。让写代码的Agent给自己打分太容易放水了，第二个独立的Agent配不同的指令，甚至有时用不同的模型，专门负责检查其他Agent的工作成果。
Loop运行过程中，让开发者敢放开监管的最大底气就是子Agent，一个真正信得过的验证者。这也是/goal命令中会去做的事——让一个独立Agent判断目标是否完成。
6、最后一块：记忆。听起来最简单，实际上是整条流水线的脊椎。一个Markdown文件，或一个Linear看板，或任何活在单个会话之外、记录什么做了、什么没做的东西。记忆文件必须存在磁盘上，不能在上下文窗口里，Agent会忘，文件不会。
这些“积木”拼接好以后，整个工作流会从一条线变成一个控制面板，作者展示了自己最常使用的一个Loop：
每天早上，一个定时任务在代码仓库上自动启动。它调用一个分诊技能，可以把分诊理解成一个急诊护士，只不过它翻的不是病历，是昨天的CI失败记录、Open Issue、最近谁提交了什么代码，翻完之后，它会把发现的问题写进一个Markdown文件或Linear看板。
对每个值得修改的的问题，这个Loop会自动开一个独立工作区（worktree），派一个子Agent去起草修复方案，再派第二个子Agent拿着项目的技能文档和现有测试去审查那个方案。
如果修复方案过了审查，连接器会自动开PR、更新工单，Loop搞不定的东西，会放到一个Triage收件箱里等人处理。
把整个流程串起来的，是state file，它记录了什么试过、什么通过了、什么还开着，第二天早上会从今天停下的地方继续。
设计出这个Loop后的每一步，发现、分配、修复、审查、开PR，一个字都不用敲。
二、搭建Loop不是当甩手掌柜，三个问题不注意会被废掉
Loop改变的是工作量，不是让人从流程里消失，它只是让一些工作可以自动运转，但就像经营一家公司，即便公司可以自行运转，老板也不能当甩手掌柜，有这样三个问题，随着Loop的建立和持续运转，会更加需要重视。
1、验证还是你的活。作者在文章中说：开发者的工作是发布你确认能运行的代码。把验证子Agent和生产的子Agent拆开，是为了让Loop的完成状态更加可靠，但“完成了”这三个字依然只是一个声明，不是证明。
2、你的理解还是会烂掉，只要你允许它烂。Loop产出速度越快，实际的代码和人能真正理解的代码之间的差距就越大，因为代码不是自己写的。这叫理解债务，一个丝滑的Loop只会让这个债务膨胀更快，除非开发者去认真阅读并思考Loop产出的东西。
3、最舒服的姿势可能是最危险的。当Loop自己撒欢运行时，意志不坚定的开发者极其容易被诱惑，然后不再自己进行判断，会选择直接收下它给的一切结果。
作者管这个叫认知投降，设计Loop是解药还是毒药，取决于开发者是在用判断力设计它然后辅助提效，还是在用它来逃避思考，同一种行为，往往会得到相反的结果。
结语：Loop虽好，但依然要保持思考
作者在文末写了这样一句话：“搭好你的Loop，但别忘了直接给你的Agent写提示词仍然有效。关键是找到正确的平衡。”
两个不同的人可以搭完全一样的Loop，然后得到完全相反的结果：个人用它加速自己透彻理解的工作，另一个人用它避开理解工作本身。Loop分不清，使用者自己要分清。
Loop替人类省掉的除了繁琐的工作，还有参与感，不再需要亲手敲提示词的那一刻，使用者也就失去了亲手验证的机会。这就是为什么作者在讲完五块积木之后，用了同样的篇幅讲三件事：验证还是你的活、理解债务会滚雪球、舒服的姿势是最危险的。事实上，他在说：Loop越强，你得越清醒。
Boris Cherny的原话是“我的工作是写Loop”，这句话并没有说工作减少，背后蕴含的，是工作难点的变化。
搭建Loop是大势所趋，要学也要去做，但要保持思考，像一个还要继续做工程师的人一样搭建Loop，不要去做只会点开始键的人。
