Google 工程师教你什么是 Loop Engineering？

Loop Engineering让 AI 代理自己跑起来的工作流设计Loop Engineering 是一套让 AI 代理自行运转的系统由五个核心模块构成自动化任务、工作树、技能库、插件与连接器、子代理再加上一个外部记忆。本文来自 Google 软件工程师 Addy Osmani 的思考。本文目录五个核心模块外加几点说明自动化任务循环的心脏工作树别让并行变成一团乱麻技能库终于不用每次都从头交代项目背景插件与连接器让循环真正触达你的工具子代理把执行和审查拆开一个完整的循环长什么样循环仍然搞不定的事把循环搭起来但别丢掉工程师的脑子所谓 Loop Engineering就是用你自己设计的系统去替代那个需要你亲手向 AI 代理发号施令的过程。这里的循环可以理解成一个递归的目标你定好方向AI 反复迭代直到完成。我觉得这很可能就是未来我们和编码代理协作的主流方式。不过先把丑话说在前头这还非常早期我自己也存疑而且你必须特别当心 Token 成本。我想把这件事掰开揉碎聊聊它到底是什么又意味着什么。Peter Steinberger 最近说过一句话你不该再亲自给编码代理下指令了。你应该设计一个循环让这个循环去给代理下指令。Anthropic 那边负责 Claude Code 的 Boris Cherny 也表达了类似的观点“我已经不直接给 Claude 下指令了。我让循环跑起来让循环自己去决定怎么指挥 Claude。”过去两年要从编码代理身上拿到像样的结果全靠你写一条好提示、给足上下文。你打一段话读回复再打下一段。代理是工具而你全程握着方向盘一轮接一轮。这个阶段差不多到头了——至少有些人这么认为。现在你要做的是搭建一个小型系统它自己发现任务、分配任务、检查结果、记录完成了什么然后决定下一步做什么。由这个系统去驱动代理而不是你亲自上阵。我之前写过类似的概念叫代理工具链工程那是围绕单个代理搭建运行环境相当于软件开发的工厂模式。Loop Engineering 比工具链工程高一个层级工具链还在那里但它会按计划自动跑、会生成帮手、会自我投喂。让我意外的是这已经不是工具层面的问题了。一年前你要写一个循环得堆一堆 Bash 脚本自己维护那是你自己折腾的东西。现在这些零件直接内建在产品里。Steinberger 列的那张清单几乎完全对得上 Codex 应用也几乎完全对得上 Claude Code。一旦你发现它们的结构其实一模一样你就不会再纠结用哪个工具了——你只需要去设计一个无论套在哪个工具里都能跑的循环。五个核心模块外加几点说明一个完整的循环需要五样东西再加一个记忆存储。我先列出来再一一对应到具体产品。自动化任务按计划触发自动做发现和分流。工作树让两个并行跑的代理不会互相踩脚。技能库把代理本来只能靠猜的项目知识写成文档。插件与连接器把代理接到你已经在用的各种工具上。子代理一个负责出方案另一个负责检查。然后是第六样状态记忆。可以是一份 Markdown 文件也可以是 Linear 看板——任何能存活在单次对话之外、用来记录做了什么、下一步是什么的东西都算。听起来简单到让人觉得不靠谱。但这就是每一个长时间运行的代理都在用的把戏我在写长期运行代理那篇文章时也提过模型每次运行之间会忘光所有东西所以状态必须存在磁盘上而不是在上下文里。代理会失忆但仓库不会。现在两个产品这五样东西全都有。模块在循环中的角色Codex 应用Claude Code自动化任务定时发现和分流Automation 分页选项目、写提示词、设频率、配环境结果进 Triage 收件箱/goal 用于跑到完成为止定时任务与 cron、/loop、/goal、hooks、GitHub Actions工作树隔离并行的功能开发每个会话线程自带工作树git worktree、–worktree 参数、子代理的 isolation: worktree 设定技能库把项目知识固化下来Agent SkillsSKILL.md用 $name 或隐式调用Agent SkillsSKILL.md插件/连接器对接你的工具Connectors基于 MCP加上分发用的插件MCP 服务器加插件子代理构思和验证在 .codex/agents/ 用 TOML 定义.claude/agents/ 里的 Task 子代理、代理团队状态记忆追踪完成进度Markdown 或通过连接器对接 LinearMarkdownAGENTS.md、进度文件或通过 MCP 对接 Linear名字上有些细微差别但能力本质是一样的。我一个个展开来讲因为老实说魔鬼都藏在细节里——循环是稳得住还是会偷偷漏气全看这些细节怎么处理。自动化任务循环的心脏自动化任务才是让循环真正成为循环的东西而不是你只跑过一次就忘掉的东西。在 Codex 应用里你在 Automation 分页建一个任务选好项目、要跑的提示词、执行频率、跑在本地检出版本还是后台工作树里。有发现的运行结果会进 Triage 收件箱没发现的就自己归档——这个设计挺舒服的。OpenAI 内部就用它跑那些无聊但必须做的事每日 Issue 分流、CI 失败摘要、提交记录简报、找出上周是谁塞进来的 Bug。自动化任务可以调用技能库所以你的周期性任务就好维护了你只要触发$技能名而不是把一大坨命令贴进一个之后没人会去更新的定时脚本里。Claude Code 走到同样的地方但路径不太一样是通过定时任务和钩子来实现的。你可以用/loop让提示词或指令按间隔重复跑可以设 cron可以用钩子在代理生命周期的特定节点触发 Shell 命令也可以把整件事推到 GitHub Actions 上让它在你合上笔记本电脑之后继续跑。概念完全一样你定义一个自动任务、给它节奏、发现结果自动送到你面前你不用亲自去翻。还有一个会话内的原语值得了解而且这个更接近整篇文章在讲的核心。/loop是按节奏重复跑。/goal则是跑到你写下的条件真正成立为止——每一轮结束会由另一个小模型来判断是不是完成了所以写代码的那个模型不是打分数那个模型。你给它一个像test/auth 目录下所有测试通过、lint 检查干净这样的条件就可以走人了。Codex 也有同样的东西也叫/goal跨多轮一路跑到一个可验证的停止条件成立可以暂停、恢复、清除。同样的原语两个工具都有这也基本上就是整篇文章的套路。所以这部分是让任务浮现出来。循环剩下的部分是对这些任务动手做事。工作树别让并行变成一团乱麻你只要同时跑超过一个代理文件就会开始打架这就是它崩掉的方式。两个代理写同一个文件跟两个工程师往同一段代码提交而且事前没打过招呼一样痛苦。git worktree 解决了这个问题它是一个独立的工作目录、自己一条分支、共用同一个仓库的历史记录所以一个代理的编辑在物理上就不可能碰到另一个代理的检出版本。Codex 把工作树支持内建了所以好几个会话线程可以同时打在同一个仓库上也不会撞车。Claude Code 用 git worktree、--worktree参数让一个会话开在自己的检出版本里、以及你在子代理上贴的isolation: worktree设定每个子代理拿到一个全新的检出版本跑完自己清理来给你同样的隔离效果。我在写工具链的代价那篇时从人的角度讲过这件事工作树解决了机器层面的碰撞但你才是真正的瓶颈——你的审查带宽才决定你实际上能并行跑多少而不是工具本身。技能库终于不用每次都从头交代项目背景技能库就是让你不用每个会话都像金鱼一样重新交代一遍项目背景。两个工具用同样的格式一个文件夹里有 SKILL.md放着指令和元数据再加上可选的脚本、参考资料、附件。Codex 在你用$或/skills调用时跑技能库或者当你的任务符合技能描述时自动跑——这就是为什么一个精准而平淡的描述会打败一个漂亮但模糊的描述。Claude Code 做法一样我在写代理技能那篇时详细讲过这个模式。技能库也是意图不用反复支付的地方。我在写意图债务那篇时主张过代理每次会话都是冷启动它会用自信的猜测来填补你意图里所有的坑。技能库是把那个意图写在外部——项目惯例、构建步骤、“我们不那样做因为上次出了事故”——写一次代理每次运行都读。没有技能库的循环每一轮都从零推导你的整个项目有技能库的循环会慢慢积累复利。有一点要分清技能库是写作格式插件是发布方式。当你要跨仓库分享一个技能库、或者把几个技能库打包成一组你打包成插件。Codex 是这样Claude Code 也是。插件与连接器让循环真正触达你的工具只能看到文件系统的循环是一个很小的循环。连接器基于 MCP 构建让代理可以读 Issue 追踪器、查数据库、打预发布环境的 API、往 Slack 发消息。Codex 和 Claude Code 都支持 MCP所以你为其中一个写的连接器通常另一个也能直接用。插件把连接器和技能库打包成一组让你的队友一次装完你的整套配置而不是凭记忆重建一遍。这就是代理告诉你怎么修和循环自己开 Pull Request、连 Linear 工单、CI 过了之后往频道里吼一声之间的差距。连接器是循环得以在你真实环境里动手做事的原因不只是告诉你如果它能做到的话它会做什么。子代理把执行和审查拆开循环里最有用的结构设计绝对是把执行的和审查的拆开。写代码的模型自己给自己写的作业打分时太仁慈了。换一个指令不同、有时候连模型都不同的第二个代理会抓到第一个模型自我说服过去的东西。Codex 只在你要求的时候才生成子代理并行跑再把结果汇总成一个答案。你在.codex/agents/把自己的代理定义成 TOML 文件每个都有名字、描述、指令、可选的模型与推理算力——你的安全审查员可以是一颗强模型开高思考预算你的探索员可以是某个快、只读的东西。Claude Code 也用.claude/agents/的子代理和代理团队做同样的事在代理之间传递任务。两边常见的拆法都一样一个探索、一个实现、一个对照规格做验证。我之前已经主张过两次了一次叫代码代理乐团一次叫对抗性代码审查。在循环里为什么特别重要是因为循环会在你没看的时候跑——一个你真的信得过的审查员是你能放心走人的唯一理由。子代理确实会多烧 Token因为每个都要自己跑模型和工具。所以把它花在值得拿到第二意见的地方。Claude Code 的/goal底层大致就是这个逻辑由一个全新的模型来判断循环是不是完成了而不是那个写完代码的模型——做的人 vs 检查的人应用在停止条件本身。一个完整的循环长什么样把这些零件拼起来单一个会话线程就会变成一个小型控制面板。我常用的形态是这样一个自动化任务每天早上在仓库上跑。它的提示词调用一个分流技能库去读昨天的 CI 失败记录、未处理的 Issue、最近的提交把发现写进一份 Markdown 文件或 Linear 看板里。对于每个值得做的发现这个会话线程开一个隔离的工作树派一个子代理草拟修法方案再派第二个子代理对照项目技能库和现有测试来审查那份草稿。连接器让循环开 Pull Request、更新工单。任何循环处理不了的东西进 Triage 收件箱等我来处理。状态文件是整个系统的脊梁骨记录试过什么、过了什么、还开着什么——所以明天早上的那一轮能从今天结束的地方接起来。回头看你在做什么你只设计过一次。没有任何一步是你亲自下达提示词的。这就是 Steinberger 那句话的具体实现。而且同样的循环在 Codex 和 Claude Code 都跑得起来因为零件就是同样那些零件。循环仍然搞不定的事循环改变了工作的形态但没有把你这个人删掉。而且有三个问题随着循环变好会变得更尖锐而不是更轻松。审查仍然是你的事。一个没人盯着跑的循环也是一个没人盯着犯错的循环。把审查性子代理和执行者子代理拆开的全部理由就是让循环说的完成了具有意义即便如此完成是一个主张不是证明。我一直在重复AI 时代的代码审查那篇文章里的同一句话你的工作是把你亲自确认过能跑的代码交出去。你对代码的理解仍然会生锈如果你放任不管的话。循环输出不是你写的代码越快存在的东西和你真的弄懂了的东西之间的鸿沟就越大。那是理解债务一个太顺畅的循环只会让它长得更快——除非你去读循环做的东西。舒服的姿势就是危险的姿势。当循环自己在跑你会很想停止有任何看法直接收下它丢回来的东西。我把那叫认知投降。设计循环在你带着判断力的时候是解药在你想避免思考的时候是加速剂——同样的动作相反的结果。把循环搭起来但别丢掉工程师的脑子我觉得这是我们工作未来走向的一个预告。话说回来如果我没有亲自审查代码或者完全靠自动循环来修东西产品品质会掉。我大概会卡在下降螺旋里越挖越深。也就是说去把你的循环搭起来——但别忘了直接给代理下指令也仍然是有效的方法。一切都关于找到平衡。循环也会因为人而给出非常不同的结果。两个人搭一模一样的循环可以拿到完全相反的结果。一个人用它在他理解得很深的工作上加速另一个人用它来回避去理解任何工作。循环分不出差异你才知道。这就是为什么循环设计比提示词工程更难而不是更简单。Cherny 的重点不是工作变简单了而是发力点搬家了。把循环搭起来。但要像一个打算继续当工程师的人那样搭不要像一个只想当按下启动键的人那样搭。