Loop Engineering 迴圈工程
Loop engineering 的核心在於，你不再是那個親自對 Agent 下達 Prompt 的人，而是轉而設計一套能自動執行這些任務的系統。這裡的「Loop」（迴圈）可以被視為一種遞迴式的目標：你定義一個目的，AI 則不斷迭代直到任務完成。這套機制大致由五個建構模組組成，而 Claude Code 與 Codex 目前都已具備這五項功能。
我相信這可能是我們未來與程式開發 Agent 協作的方式。不過，這一切還在早期階段，我對此仍持保留態度，且你絕對必須留意 token 的消耗（如果你的 token 額度充裕或匱乏，使用模式會有極大差異）。此外，你仍然需要某種方式來確保程式碼品質不會下降，對於「產出垃圾程式碼」（slop）的擔憂也是合理的。話雖如此，讓我們來深入探討這究竟是怎麼一回事。
@steipete 最近提到：「你不應該再對程式開發 Agent 下達 Prompt 了。你應該設計能對 Agent 下達 Prompt 的 Loop。」同樣地，Anthropic 旗下 Claude Code 的負責人 @bcherny 也說：「我不再對 Claude 下達 Prompt 了。我運行著一些 Loop，由它們來對 Claude 下達 Prompt 並決定要做什麼。我的工作是撰寫這些 Loop。」
好吧，這到底是什麼意思？
過去兩年左右，你從程式開發 Agent 獲取成果的方式，通常是撰寫一個好的 Prompt 並提供足夠的 context。你輸入指令，閱讀回傳的內容，然後輸入下一個指令。Agent 是一個工具，而你全程都在操作它，一輪接著一輪。那種模式某種程度上已經結束了，或者至少有些人認為它即將結束。
現在，你建立的是一個小型系統，它負責尋找工作、分配任務、檢查成果、記錄已完成事項，然後決定下一步，你只需要讓這個系統去驅動 Agent，而不是自己動手。我之前寫過關於這類系統的「親戚」——Agent harness engineering，也就是打造單一 Agent 運作的環境，以及「工廠模型」（factory model）——即建構軟體的系統。Loop engineering 的層級比 harness 更高。它就像是一個在計時器上運作的 harness，會產生小型輔助 Agent，並自我供給。
讓我驚訝的是，這已經不再單純是「工具」的問題了。一年前，如果你想要一個 Loop，你得寫一堆 bash 腳本，然後永遠維護那堆程式碼，那是專屬於你個人的東西。現在，這些功能直接內建在產品裡。Steinberger 的清單幾乎完全對應到 Codex 應用程式，也幾乎完全對應到 Claude Code。一旦你發現它們的架構是一樣的，你就不會再爭論哪個工具比較好，你只需要設計一個無論在哪個工具上都能運作的 Loop。
五個組成部分與注意事項
一個 Loop 需要五個要素，再加上一個用來記憶資訊的地方。讓我先列出來，再一一對應。
自動化（Automations）：按排程執行，並自動進行探索與分類（triage）。
工作樹（Worktrees）：讓兩個並行工作的 Agent 不會互相干擾。
Skill：記錄專案知識，否則 Agent 就只能靠猜測。
Plugin 與連接器（Connectors）：將 Agent 連接到你現有的工具。
子 Agent（Sub-agents）：讓一個 Agent 負責構思，另一個負責檢查。
接著是第六個要素：記憶。這可以是一個 Markdown 檔案、一個 Linear 看板，或是任何存在於單一對話之外，用來記錄「已完成」與「下一步」的東西。聽起來很簡單，甚至顯得有點笨，但這是每個長效執行 Agent 賴以生存的關鍵技巧。我在關於長效執行 Agent 的文章中提過，模型在每次執行之間會忘記所有事情，因此記憶必須存在磁碟上，而不是在 context 裡。Agent 會忘記，但儲存庫（repo）不會。
這兩款產品現在都具備了這五項功能。
名稱在不同地方略有差異，但能力是一樣的。讓我逐一說明，因為老實說，細節才是決定一個 Loop 是能穩固運作，還是會悄悄崩潰的關鍵。
自動化，這是心跳
自動化是讓 Loop 成為真正的「迴圈」，而不僅僅是一次性執行的關鍵。在 Codex 應用程式中，你可以在「自動化」分頁中建立一個任務，選擇專案、要執行的 Prompt、執行頻率，以及是在你的本地 checkout 還是背景工作樹中執行。找到問題的執行結果會進入「分類收件匣」（Triage inbox），而沒找到問題的執行則會自動封存，這很方便。OpenAI 在內部使用它們來處理瑣事，例如每日 Issue 分類、總結 CI 失敗原因、撰寫 commit 簡報、追蹤上週有人新增的 Bug。而且自動化可以呼叫一個 Skill，這樣你就能維持重複性任務的可維護性，你只需要觸發 $skill-name，而不是將一大堆指令貼進一個沒人會去更新的排程裡。
Claude Code 透過排程與 Hook 達到同樣的效果。你可以透過 /loop 以特定間隔執行 Prompt 或指令，可以排程 cron 任務，可以在 Agent 生命週期的特定時間點透過 Hook 觸發 shell 指令，或者如果你希望在關上筆電後它能繼續執行，也可以將整件事推送到 GitHub Actions。概念完全相同：你定義一個自主任務，給它一個節奏，然後結果會自動送到你面前，不需要你親自去檢查。
還有一個值得了解的「會話內」（in-session）原語，它更接近這篇文章的主題。/loop 會按節奏重新執行。/goal 則會持續執行直到你寫下的條件真正達成，且在每一輪之後，會有另一個小型模型檢查你是否完成，因此撰寫程式碼的 Agent 並不是負責評分的那一個。你給它一個目標，例如「確保 test/auth 中的所有測試都通過且 lint 檢查乾淨」，然後就可以走開了。Codex 也有同樣的功能，也叫 /goal，它會跨輪次持續工作，直到可驗證的停止條件達成，並支援暫停、恢復與清除。同樣的原語，同樣的工具，這幾乎是整篇文章的模式。
所以，這是呈現工作成果的部分。而 Loop 的其餘部分則是負責處理這些成果。
工作樹，讓並行執行不再混亂
一旦你同時執行多個 Agent，檔案衝突就會開始發生，這就是失敗的開始。兩個 Agent 修改同一個檔案，就像兩個工程師在沒有溝通的情況下修改同一行程式碼一樣，會造成同樣的頭痛。Git worktree 解決了這個問題，它是在同一個儲存庫歷史記錄下，於不同分支建立獨立的工作目錄，因此一個 Agent 的編輯動作絕對不會影響到另一個 Agent 的 checkout。
Codex 直接內建了對 worktree 的支援，因此多個執行緒可以同時存取同一個儲存庫而不會互相碰撞。Claude Code 透過 git worktree 提供同樣的隔離性，你可以使用 --worktree 旗標在獨立的 checkout 中開啟會話，並在子 Agent 上設定 isolation: worktree，讓每個輔助 Agent 都能擁有一個在結束後會自動清理的全新 checkout。我曾在「編排稅」（orchestration tax）一文中談過這一切的人性面，worktree 解決了機械式的碰撞，但「你」依然是效能的天花板，你的審核頻寬決定了你能同時執行多少任務，而不是工具本身。
Skill，讓你不用每次都解釋專案
Skill 是讓你不再像金魚一樣，每次會話都要重新解釋專案 context 的方式。這兩款工具使用相同的格式：一個包含 SKILL.md 的資料夾，裡面存放指令與 metadata，以及選用的腳本、參考資料與 asset。當你使用 $ 或 /skills 呼叫它，或者當你的任務與 Skill 描述相符時，Codex 就會執行該 Skill，這也是為什麼精簡且無聊的描述比花俏的描述更有用的原因。Claude Code 的運作方式相同，我已在「Agent skills」一文中寫過這種模式。
Skill 也是讓「意圖」（intent）不再重複消耗成本的地方。我在「意圖債」（intent debt）中爭論過，Agent 每次會話都是從零開始，它會用自信的猜測來填補你意圖中的任何漏洞。而 Skill 就是將那些意圖寫下來，包含慣例、建置步驟、「因為某次事故所以我們不這樣做」的規則，寫一次，Agent 每次執行時都會讀取。沒有 Skill，Loop 每個週期都會從零開始重新推導你的整個專案；有了 Skill，它就會產生累積效應。
有一點要釐清：Skill 是撰寫格式，而 Plugin 是你發布它的方式。當你想在多個儲存庫之間共享 Skill 或將幾個 Skill 打包在一起時，你會將它們封裝為 Plugin。這在 Codex 和 Claude Code 中都適用。…
