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 的重點不是工作變簡單了，而是槓桿點搬家了。

把迴圈搭起來。但要像一個「打算繼續當工程師」的人那樣搭，不要像一個「只想當按下啟動鍵的人」那樣搭。