AI 应用风向标（公众号：ZhidxcomAI）

作者｜毕伟豪

编辑｜漠影

智东西 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 的构成：五块积木，外加一层记忆

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，不要去做只会点开始键的人。