Google 工程师教你什么是 Loop Engineering？五个积木＋外部记忆，2026 年的 AI 必修课

Loop Engineering 是一套会自己執行 prompt 代理的系统，它由五个積木：Automations、Worktrees、Skills、Plugins/Connectors、Sub-agents，加上一个外部記憶構成。本文源自 Google 软體工程師 Addy Osmani。
（前情提要：Anthropic 在 Claude Fable 5 加入蒸餾偵測功能，能擋住中国开源模型？ ）
（背景補充：Anthropic：美国 AI 模型领先中国才能守護民主、提议將蒸餾攻擊定为刑事犯罪）

本文目錄

Toggle

• 五个積木，加上一些備註
• Automations：迴圈的心跳
• Worktrees：別让平行變成混亂
• Skills：你終於不用每次都重講你的專案
• Plugins 与 connectors：迴圈伸手碰你真正的工具
• Sub-agents：让做的人跟檢查的人分开
• 一个迴圈长什麼樣子
• 迴圈仍然沒有幫你做的事
• 把迴圈搭起来，但继续当工程師

Loop engineering 是把「親手 prompt 代理」的那个你換掉，由你设计的系统来做这件事。这裡所謂的「迴圈」可以理解成一个递迴目標：你定義目的，AI 反覆迭代直到完成。我相信这可能就是我們未来与編碼代理協作的方式。

但話说在前头，这还很早期，我自己也存疑，而且你絕对必須小心 token 成本。我想把这件事拆开談談：它是什麼，又意味著什麼。

Peter Steinberger 最近说：「你不該再 prompt 你的編碼代理了。你应該设计会 prompt 你的代理的迴圈。」Anthropic 的 Claude Code 负责人 Boris Cherny 也说了類似的話：「我已经不再 prompt Claude 了。我让迴圈跑著去 prompt Claude，由迴圈自己決定要做什麼。」

过去差不多两年，要从一个編碼代理身上拿到結果，靠的是你寫一个好 prompt 並提供足夠脈絡。你打一段、读回应、再打下一段。代理是工具，而你从头到尾都握著它，一輪接一輪。那个階段差不多結束了，至少有些人这樣认为。

现在你做的是搭一个小系统：它找工作、派工作、檢查工作、寫下哪些完成了，然后決定下一件事，由这个系统来戳代理而不是你親自戳。我之前寫过它的近親「agent harness engineering」，那是在打造單一代理运行的環境，也就是建構软體的「工廠模型」。

Loop engineering 比 harness 高一層：harness 还在原地，但它会按表跑、会生小幫手、会自己餵自己。

让我意外的是，这已经不是工具層級的事了。一年前你要寫一个迴圈，你得堆一堆 bash，自己維護，那是你个人的东西。现在，这些零件直接內建在产品裡。Steinberger 的清單幾乎完全对应到 Codex app，再幾乎完全对应到 Claude Code。一旦你发现形狀其实一樣，你就不会再为「用哪个工具」吵架，你只是去设计一个无論坐在哪个工具裡都能跑的迴圈。

五个積木，加上一些備註

一个迴圈需要五樣东西，再加一个記憶位置。我先列再对映。

2. Automations：照排程觸发，自动做 discovery 与 triage。
3. Worktrees：让两个並行跑的代理不会踩到对方。
4. Skills：把代理本来只能用猜的專案知识寫下来。
5. Plugins 与 connectors：把代理接到你已经在用的工具。
6. Sub-agents：一个想点子，另一个檢查。

然后是第六樣：記憶。一份 markdown 檔，或是 Linear 看板，任何活在單次对話之外、用来記錄「做了什麼、下一步是什麼」的东西都算。聽起来蠢到沒人要用。但这就是每一个长时间运行代理都仰賴的把戲，我在 long-running agents 那篇也談过：模型在每次跑之间会忘光一切，所以記憶必須存在磁碟上，不在 context 裡。代理会忘，repo 不会忘。

两个产品现在五樣都有。

| 原语 | | --- | 在迴圈中的角色 | Codex app | Claude Code | | --- | --- | --- | --- | | Automations | 排程上的发现与分流 | Automations 分頁：选 project、prompt、cadence、environment；結果进 Triage 收件匣；/goal 用於 run-until-done | 排程任務与 cron、/loop、/goal、hooks、GitHub Actions | | Worktrees | 隔离並行的功能开发 | 每个 thread 內建 worktree | git worktree、--worktree、subagent 上的 isolation: worktree | | Skills | 把專案知识編碼下来 | Agent Skills（SKILL.md），用 $name 或隐式呼叫 | Agent Skills（SKILL.md） | | Plugins / connectors | 接你的工具 | Connectors（MCP）加上散发用的 plugins | MCP servers 加 plugins | | Sub-agents | 構思与验证 | 在 .codex/agents/ 用 TOML 定義 | .claude/agents/ 裡的 Task subagents、agent teams | | State | 追蹤完成狀態 | Markdown 或透过 connector 连 Linear | Markdown（AGENTS.md、进度檔）或透过 MCP 连 Linear |

名字这边那边有点不同，但能力本质一樣。我一个一个展开講，因为老实说，魔鬼藏在細節：迴圈会穩住还是会偷偷漏光，全看这些細節。

Automations：迴圈的心跳

Automations 才是让「迴圈」真的成为迴圈，而不是「你跑过一次的东西」。在 Codex app 裡，你在 Automations 分頁建一个，选 project、要跑的 prompt、频率、跑在本机 checkout 还是背景 worktree。有发现的 run 会进 Triage 收件匣，沒发现的 run 自己歸檔，这点蠻舒服的。

OpenAI 內部就用它跑无聊但必要的事：每日 issue 分流、CI 失敗摘要、commit briefing、找上禮拜被誰塞进来的 bug。Automation 可以呼叫 skill，所以你的週期任務可以維護：你只要觸发 $skill-name，而不是把一大坨指令貼进一个之后沒人会更新的排程。

Claude Code 走到同一个地方但路徑不太一樣，是透过排程与 hooks。你可以用 /loop 让 prompt 或指令照间隔重跑、可以排 cron、可以用 hooks 在代理生命週期的特定点觸发 shell 指令、也可以把整件事推上 GitHub Actions 让它在你合上筆电后继续跑。概念完全相同：你定義一个自动任務、給它節奏、发现自动送到你面前，你不用親自去翻。

还有一个 session 內的原语值得知道，而且这个更接近这整篇文章在講的事。/loop 是按節奏重跑。/goal 則是跑到你寫下的條件真的成立为止，每一輪結束会由另一个小模型判斷是不是完成了，所以「寫代碼那个」不是「打分數那个」。

你給它一个像「test/auth 下所有測試通过、lint 乾淨」这樣的條件，就走人。Codex 也有同樣的东西，也叫 /goal，跨多輪一路跑直到一个可验证的停止條件成立，可以 pause、resume、clear。同一个原语，两个工具都有，这也基本上就是整篇文章的 pattern。

所以这部份是「把工作浮现出来」。迴圈剩下的部份是「对这些工作做点事」。

Worktrees：別让平行變成混亂

你只要同时跑超过一个代理，檔案就会开始相撞，这就是它崩壞的方式。两个代理寫同一个檔案，跟两个工程師往同樣的程式碼行 commit 而且事前沒講过話一樣痛。git worktree 解掉这件事：它是一个分开的工作目錄、自己一條 branch、共用同樣的 repo 歷史，所以一个代理的編辑在物理上不可能碰到另一个代理的 checkout。

Codex 把 worktree 支援內建，所以好幾个 thread 可以同时打同一个 repo 也不会撞到。Claude Code 用 git worktree、--worktree flag（让一个 session 在自己的 checkout 裡开）、以及你貼在 subagent 上的 isolation: worktree 设定（每个小幫手拿到一个全新的 checkout，跑完自己清掉）来給你同樣的隔离。我在 the orchestration tax 那篇有从人類角度寫这件事：worktree 解掉了机械上的碰撞，但你才是天花板，你的 review bandwidth 才決定你实际上能跑幾个，不是工具。

Skills：你終於不用每次都重講你的專案

Skill 就是让你不用每个 session 像金鱼一樣重講同樣的專案脈絡。两个工具都用同樣的格式：一个资料夾裡有 SKILL.md，放著指令与 metadata，再加上可选的 scripts、references、assets。Codex 在你用 $ 或 /skills 呼叫时跑 skill，或者当你的任務符合 skill 描述时自动跑——这就是为什麼一个精準无聊的描述会打敗一个漂亮聰明的描述。Claude Code 做法一樣，我在 agent skills 那篇有寫过这个 pattern。

Skill 也是「意圖不必一付再付」的地方。我在 the intent debt 那篇主張过：代理每次 session 都是冷啟动，它会用自信的猜測填上你意圖裡所有的洞。Skill 是把那个意圖寫在外部——慣例、build 步骤、「我們不那樣做，因为上次那个事件」——寫一次，代理每次跑都读。沒有 skill 的迴圈每一輪都从零重推你的整个專案，有 skill 的迴圈会慢慢累積複利。

有一件事要分清楚：skill 是寫作格式，plugin 是发行的方式。当你要跨 repo 分享一个 skill、或把幾个 skill 包成一組，你打包成 plugin。Codex 是这樣，Claude Code 也是。

Plugins 与 connectors：迴圈伸手碰你真正的工具

只能看到 filesystem 的迴圈是一个很小的迴圈。Connectors，建構在 MCP 之上，让代理可以读 issue tracker、查资料庫、打 staging API、丟 Slack 訊息。Codex 跟 Claude Code 都講 MCP，所以你为其中一个寫的 connector 通常另一个也直接能用。Plugins 把 connectors 跟 skills 包成一組，让你的队友一次裝完你的整套设定，而不是憑記憶重建一遍。

这就是「代理告訴你『这是修法』」跟「迴圈自己开 PR、连 Linear ticket、CI 綠了之后丟频道一聲」之间的差距。Connectors 是迴圈得以在你真实環境裡动手做事的原因，不只是告訴你「如果它能，它会做什麼」。

Sub-agents：让做的人跟檢查的人分开

迴圈裡最有用的結構性手段，絕对是把「寫的人」和「檢查的人」拆开。寫程式的模型自己給自己打作业分數时太仁慈了。換一个指令不同、有时候连模型都不同的第二个代理，会抓到第一个自我说服过去的东西。

Codex 只在你叫它的时候才生 subagent，並行跑，再把結果摺回一个答案。你在 .codex/agents/ 把自己的代理定義成 TOML，每个都有 name、description、instructions、可选的 model 与 reasoning effort——你的安全審查者可以是一顆強模型开高思考预算，你的探索者可以是某个快、唯读的东西。Claude Code 也用 .claude/agents/ 的 subagent 和 agent teams 做同樣的事：在代理之间傳递工作。两边常见的拆法都是：一个探索、一个实作、一个对著 spec 验证。

我之前已经主張过两次，一次叫 code agent orchestra，一次叫 adversarial code review。在迴圈裡为什麼特別重要，是因为迴圈会在你沒看的时候跑——一个你真的信得过的 verifier，是你能放心走人的唯一原因。Subagent 確实会多燒 token，因为每个都要自己跑模型跟工具。所以把它花在「值得拿到第二意见」的地方。Claude Code 的 /goal 底層大致就是这樣：由一个全新的模型決定迴圈是不是完成，而不是那个寫完代碼的模型——「做的人 vs 檢查的人」应用在停止條件本身。

一个迴圈长什麼樣子

把这些拼起来，單一个 thread 就会變成一个小型控制面板。我常用的形狀如下。

一个 automation 每天早上在 repo 上跑。它的 prompt 呼叫一个 triage skill，去读昨天的 CI 失敗、open issues、最近的 commits，把发现寫进一份 markdown 檔或 Linear 看板。对於每个值得做的发现，这个 thread 开一个隔离的 worktree，派一个 sub-agent 草擬修法，再派第二个 sub-agent 对著專案 skills 和现有測試審查那份草稿。

Connectors 让迴圈开 PR、更新 ticket。任何迴圈處理不了的东西进 triage 收件匣等我。狀態檔是整件事的脊椎，記得試过什麼、过了什麼、还开著什麼——所以明天早上的那一輪，能从今天結束的地方接起来。

回头看你做了什麼：你只设计过一次。沒有任何一步是你 prompt 的。这就是 Steinberger 那句話的具體实现。而且同樣的迴圈在 Codex 跟 Claude Code 都跑得起来，因为零件就是同樣那些零件。

迴圈仍然沒有幫你做的事

迴圈改變了工作的形狀，但沒有把你刪掉。而且有三个问題随著迴圈變好会變得更尖锐，而不是更轻鬆。

验证仍然是你的事。 一个沒人盯著跑的迴圈，也是一个沒人盯著犯错的迴圈。把 verifier sub-agent 跟 maker 拆开的整个理由，就是让迴圈说的「完成了」具有意義；即便如此，「完成」是一个主張，不是证明。我一直在重複 code review in the age of AI 那篇的同一句話：你的工作是出货「你親自確认过能跑」的程式碼。

你的理解仍然会腐爛，只要你允許。 迴圈出货「不是你寫的程式碼」越快，「存在的东西」跟「你真的有的东西」之间的鴻溝就越大。那是 comprehension debt（理解负債），一个順暢的迴圈只会让它长得更快——除非你去读迴圈做的东西。

舒服的姿勢就是危险的姿勢。 当迴圈自己在跑，你会很想停止有任何看法，直接收下它丟回来的东西。我把那叫 cognitive surrender（认知投降）。设计迴圈，在你帶著判斷力的时候是解藥，在你想避免思考的时候是加速劑——同樣一个动作，相反的結果。

把迴圈搭起来，但继续当工程師

我认为这是我們工作未来会走向的预告。話说回来：如果我沒有親自審查程式碼，或者完全靠自动迴圈来修，产品品质会掉。我大概会卡在下沉螺旋，越挖越深。

也就是说，去把你的迴圈搭起来——但別忘了直接 prompt 你的代理也仍然是有效的方法。一切都关於找到平衡。

迴圈也会因为「人」而給出非常不同的結果。两个人搭一模一樣的迴圈，可以拿到完全相反的結果。一个人用它在他理解得很深的工作上加速，另一个人用它来迴避去理解任何工作。迴圈分不出差異，你才知道。

这就是为什麼 loop design 比 prompt engineering 更难而不是更簡單。Cherny 的重点不是工作變簡單了，而是槓桿点搬家了。

把迴圈搭起来。但要像一个「打算继续当工程師」的人那樣搭，不要像一个「只想当按下啟动鍵的人」那樣搭。