Loop Engineering
原文作者：Addy Osmani
編譯：Peggy，BlockBeats

編者按：AI 編碼 Agent 的使用方式，正從「人手動撰寫 Prompt、逐輪推進任務」，轉向「人設計循環，讓系統持續調度 Agent」。Addy Osmani 所說的 Loop Engineering（循環工程），核心是搭建一套能自動發現任務、分配任務、檢查結果、記錄進度並決定下一步的工作流。

這個迴圈大致由五個模組組成：Automations（定時發現和分診任務）、Worktrees（隔離多個並行開發環境）、Skills（沉澱項目知識和團隊慣例）、Plugins/Connectors（接入 GitHub、Linear、Slack、資料庫等真實工具）、Sub-agents（讓執行者和審查者分離），再加上一個外部記憶層，如 Markdown 檔案或 Linear 看板，用來保存狀態與進展。

文章提醒，Loop Engineering 的意義不只是「讓 AI 多跑幾輪」，而是把工程師的判斷力前置到系統設計中。循環可以顯著放大開發者的工作槓桿，但不會替代驗證、理解和判斷。真正的風險，也不在於使用循環，而在於把循環當成逃避理解代碼和系統的藉口。未來與 AI 編程協作的關鍵能力，或許不再只是寫出一個好 Prompt，而是設計可靠、可驗證、可持續運行的 Agent 工作流。

以下為原文：

Loop 工程（循環工程）正在取代你作為「給智能體寫提示詞的人」的角色。你要設計一個系統，讓這個系統替你去提示智能體。這裡的 loop（循環）可以理解為一種遞歸目標：你定義一個目的，AI 便不斷迭代，直到任務完成。它大致由五個構件組成，而 Claude Code 和 Codex 現在都已經具備了這五個構件。

我相信，這可能就是我們未來與編碼智能體協作的方式。不過，這一切仍處於早期階段，我也保持懷疑。你絕對需要謹慎對待 token 成本，因為不同使用模式下，成本差異可能非常巨大，尤其取決於你是「token 富裕」還是「token 緊張」。你還需要有某種機制，確保質量不會下降。關於「AI 垃圾產出」（slop）的擔憂也是合理的。話雖如此，我們還是來看看這到底是怎麼回事。

@steipete 最近說過一句話：「你不應該再給編碼智能體寫提示詞了。你應該設計一些迴圈，讓這些迴圈去提示你的智能體。」類似地，Anthropic 的 Claude Code 負責人 @bcherny 也說：「我現在已經不再提示 Claude 了。我有一堆 loop 在運行，它們會提示 Claude，並自己判斷下一步該做什麼。我的工作就是寫 loop。」

那麼，這到底是什麼意思？

在過去大約兩年的時間裡，你想讓編碼智能體做些什麼，基本方式就是寫一個好的提示詞，並提供足夠的上下文。你輸入一句話，閱讀返回結果，再輸入下一句話。智能體是一個工具，而你一直握著這個工具，一輪接一輪地推動它。這個階段某種程度上已經結束了，至少有些人認為它即將結束。

現在，你正在構建一個小型系統：它能自行發現工作、分配任務、檢查結果、記錄完成情況，並決定下一步該做什麼。也就是說，你讓這個系統去驅動智能體，而不是由你親自反覆提示它。我之前寫過它的「近親」——agent harness engineering（智能體運行框架工程），也就是為單個智能體搭建運行環境；以及 factory model（工廠模型），也就是構建軟體的系統。Loop engineering 則位於 harness 的上一層。它像 harness，但會按定時器運行，會生成小助手，並且會自我餵養。

讓我意外的是，這已經不再只是「工具層面」的問題了。一年前，如果你想要一個 loop，你得寫一大堆 bash 腳本，然後永遠維護這堆腳本。那是你自己的東西，也只屬於你自己。現在，這些組件已經直接內建在產品裡了。Steinberger 列出的能力幾乎可以一一對應到 Codex 應用裡，也幾乎同樣可以對應到 Claude Code 裡。一旦你意識到它們的形態是一樣的，你就不会再糾結到底該用哪個工具，而是會去設計一個 loop：無論你坐在哪個工具裡，它都能繼續運轉。

五個構件，以及一些說明

一個 loop 需要五樣東西，外加一個用來記住資訊的地方。我先列出來，再逐一對應。

第一，Automations（自动化任務）：按計劃觸發，自動進行發現和分流。

第二，Worktrees（工作樹）：讓兩個並行工作的智能體不會互相踩到對方的檔案。

第三，Skills（技能）：把項目知識寫下來，避免智能體每次都靠猜。

第四，Plugins and connectors（插件和连接器）：讓智能體接入你已經在使用的工具。

第五，Sub-agents（子智能体）：一個負責提出方案，另一個負責檢查方案。

接著是第六樣東西：memory（記憶）。它可以是一個 Markdown 檔案，也可以是一個 Linear 看板，或者任何獨立於單次對話之外、能夠保存「已完成事項」和「下一步事項」的地方。聽起來簡單到不像重要的事，但這是每一個長期運行的智能體都依賴的同一套技巧。我在 long-running agents 裡也詳細寫過：模型在每次運行之間都會忘記，所以記憶必須放在磁碟上，而不是放在上下文裡。智能體會忘，但程式碼倉庫不會。

現在，這兩款產品都已具備這五個構件。

它們的命名有些地方不同，但能力本質上是同一回事。下面我逐一說明，因為老實說，一個 loop 最終是穩定運轉，還是悄悄到處漏水，關鍵都在細節裡。

Automations：這是 loop 的心跳

Automations 是讓 loop 真正成為 loop 的關鍵，而不是你曾手動執行過的一次性任務。在 Codex 應用中，你可以在 Automations 標籤頁中建立一個自動化任務，選擇項目、要執行的提示詞、執行頻率，以及它是於你的本地 checkout 中執行，還是在後台 worktree 中執行。那些發現問題的執行結果會進入 Triage inbox（分流收件箱），未發現問題的執行則會自動歸檔，這一點非常好。OpenAI 內部也會用它來處理一些枯燥但必要的任務，例如每日 issue 分流、總結 CI 失敗原因、撰寫 commit 簡報、追蹤上周有人引入的 bug。自動化任務還能調用 skill，因此你可以讓反覆執行的任務保持可維護：觸發 $skill-name，而不是將一整牆的說明文字複製到一個以後無人更新的計劃任務中。

Claude Code 也能達到同樣效果，只是路徑不同：它透過排程和 hooks 實現。你可以用 /loop 以固定間隔運行一個提示詞或命令，也可以安排一個 cron 任務，還可以在智能體生命週期的某些節點用 hooks 觸發 shell 命令。如果你希望它在你合上電腦後繼續運行，也可以把整套東西推到 GitHub Actions 上。思路完全一樣：你定義一個自主任務，給它一個節奏，讓發現結果來到你面前，而不是由你到處去檢查。

另一個值得了解的會話內原語，更接近本文真正討論的核心。/loop 會按節奏重複運行；/goal 則會持續執行，直到你寫下的某個條件真正成立。每輪之後，都會由一個單獨的小模型來判斷任務是否完成，因此寫代碼的智能體並不是給自己打分的那個。你可以給它一個條件，例如「test/auth 裏的所有測試都通過，並且 lint 幹淨」，然後離開。Codex 也有同樣的能力，同樣叫 /goal。它會跨輪次持續工作，直到某個可驗證的停止條件成立，並支援暫停、恢復和清除。同一個原語，兩款工具都有。這基本就是本文反覆出現的模式。

因此，Automations 負責把工作浮出水面，loop 的其餘部分則負責處理這些工作。

Worktrees：讓並行不致於變成混亂

一旦你運行不止一個智能體，檔案衝突就會成為失敗點。兩個智能體同時寫同一個檔案，本質上就和兩個工程師在沒有溝通的情況下修改同一行代碼一樣麻煩。git worktree 可以解決這個問題。它是在獨立分支上的一個單獨工作目錄，但共享同一個代碼倉庫歷史，因此一個智能體的修改從物理上就無法碰到另一個智能體的 checkout。

Codex 已內建 worktree 支援，因此多個執行緒可以同時處理同一個倉庫而不會相互衝突。Claude Code 也可透過 git worktree 實現相同的隔離：你可以使用 --worktree 標誌在獨立的 checkout 中開啟一個會話，或在 subagent 上設定 isolation: worktree，讓每個小助手獲得一個全新的 checkout，並在結束後自動清理。我在 the orchestration tax 中寫過這件事的人類面向：worktrees 能消除機械層面的衝突，但你依然是上限。真正決定你能同時運行多少智能體的，不是工具，而是你的 review bandwidth（評審帶寬）。

技能：讓你無需每次都重新解釋項目

Skill 是一種機制，讓你不必每次會話都像金魚一樣重新解釋同一套項目上下文。兩款工具使用的格式相同：一個資料夾，裡面有一個 SKILL.md，保存說明和元數據；此外還可以有可選腳本、參考資料和資源文件。Codex 會在你使用 $ 或 /skills 呼叫時運行一個 skill，也會在你的任務匹配該 skill 描述時自動運行。這也是為什麼一個緊湊、樸素的描述，往往比一個聰明花哨的描述更好。Claude Code 的做法也是一樣的，我在 agent skills 裡寫過這個模式。

Skills 也是讓意圖不再一遍遍消耗你的地方。我在 intent debt 裡說過，智能體每次會話開始時都是冷啟動的，只要你的意圖裡有空白，它就會用自信的猜測把空白填滿。Skill 就是把這種意圖寫在外部：項目約定、構建步驟、「我們不這麼做是因為以前發生過那次事故」等等，都一次性寫在一個智能體每次運行都會讀取的地方。沒有 skills，loop 每一輪都要從零重新推導你的整個項目；有了 skills，它就有點像在複利增長。

有一點需要分清：skill 是編寫格式，plugin 則是分發方式。當你希望在多個程式碼倉庫之間共享一個 skill，或將幾個 skill 打包在一起時，你會將它們封裝成一個 plugin。Codex 如此，Claude Code 也是如此。

插件與連接器：讓 loop 與你的真實工具接觸

一個只能看到檔案系統的 loop，是一個很小的 loop。Connectors 基於 MCP 構建，可以讓智能體讀取你的 issue tracker、查詢資料庫、調用 staging API，或在 Slack 裡發訊息。Codex 和 Claude Code 都支援 MCP，因此你為其中一個撰寫的 connector，通常也能在另一個中使用。Plugins 則會將 connectors 和 skills 打包在一起，讓你的隊友一次安裝完整配置，而不是憑記憶重建整套東西。

這就是「一個智能體告訴你『這是修復方案』」和「一個 loop 自行開啟 PR、關聯 Linear ticket，並在 CI 通過後通知頻道」之間的區別。Connectors 之所以重要，是因為它們讓 loop 能在你的真實環境中行動，而不僅僅是告訴你「如果我能做，我會這麼做」。

Sub-agents：Keep manufacturers away from inspectors

在一個 loop 裡，最有用的結構性設計，遠遠是把「寫的人」和「檢查的人」拆開。寫代碼的模型太容易在給自己的作業打分時表現得過於寬容。另一個帶著不同指令、有時甚至使用不同模型的智能體，能夠抓住第一個智能體自我说服後忽略的問題。

Codex 只會在你要求時生成 subagents，它們會並行運行，然後將結果合併為一個答案。你可以在 .codex/agents/ 中使用 TOML 檔案定義自己的 agents：每個 agent 都有名稱、描述、指令，以及可選的模型和推理強度。因此，你的安全審查員可以是一個高強度推理的強模型，而你的探索者則可以是一個快速、只讀的輕量模型。Claude Code 也透過 .claude/agents/ 中的 subagents 和 agent teams 實現類似能力，讓多個 agent 在彼此之間傳遞工作。兩邊最常見的分工都是：一個 agent 探索，一個 agent 實現，一個 agent 根據規範驗證。

我已經兩次闡述過這個觀點：一次是在 code agent orchestra，另一次是在 adversarial code review。它在 loop 裡尤其重要，是因為 loop 會在你沒有盯著的時候運行，所以一個你真正信任的 verifier（驗證者），是你敢於離開的唯一理由。Subagents 確實會消耗更多 token，因為每個 agent 都要進行自己的模型調用和工具調用，所以你應該把它們用在「第二意見值得付費」的地方。這基本上也是 Claude Code 的 /goal 在底層做的事：由一個新的模型判斷 loop 是否完成，而不是讓完成工作的那個模型來判斷。也就是說，它把「製造者」和「檢查者」的分離應用到了停止條件本身。

一個 loop 長什麼樣

把這些東西拼在一起，一條單獨的線程就會變成一個小控制面板。下面是我經常使用的一種結構。

每天早上，一個 automation 會在程式碼倉庫上運行。它的提示詞會調用一個 triage skill，讀取昨天的 CI 失敗、開放中的 issues 和最近的 commits，並將發現寫入一個 Markdown 檔案或 Linear 看板。對於每一個值得處理的問題，線程會開啟一個隔離的 worktree，派發一個 sub-agent 草擬修復方案，再派發第二個 sub-agent 根據專案 skills 和現有測試來審查該方案。

Connectors 讓這個 loop 可以自行開啟 PR 並更新 ticket。任何 loop 處理不了的東西，都會進入 triage inbox，交由我處理。狀態文件是整套系統的脊樑：它記住嘗試過什麼、什麼通過了、什麼仍然未完成。因此，第二天早上的運行會從今天停下的地方繼續。

注意你真正做了什麼。你只是設計了一次。那些步驟並不是你親自逐條提示出來的。這就是 Steinberger 那句話的現實版本。而且，同一個 loop 可以運行在 Codex，也可以運行在 Claude Code，因為構件本身是同一套構件。

Loop 仍然不會替你做什麼

Loop 改變了工作方式，但並不會把你從工作中刪除。事實上，隨著 loop 變得更強，有三個問題會變得更尖銳，而不是更容易。

驗證仍然取決於你。一個無人值守運行的 loop，也可能是在無人值守地犯錯。你之所以要把 verifier sub-agent 和 maker 拆開，就是為了讓 loop 說「完成了」這句話多少有點意義。即便如此，「完成」仍然是一个主張，而不是證明。我在 code review in the age of AI 裡一直重複同一句話：你的職責是交付你確認有效的代碼。

如果你放任不管，你自己的理解仍然會腐爛。Loop 越快交付你沒有親自寫的代碼，你實際理解的東西和系統裡真實存在的東西之間的差距就越大。這就是 comprehension debt（理解債）。如果你不閱讀 loop 產出的東西，一個順滑的 loop 只會讓這種債務增長得更快。

而且，是的，最舒服的姿態很可能也是最危險的姿態。當 loop 能自己運行時，你很容易停止形成自己的判斷，只是接受它返回的任何東西。我把這叫作 cognitive surrender（認知投降）。如果你帶著判斷力去設計 loop，它就是解藥；如果你設計 loop 只是為了逃避思考，它就是加速劑。同一個動作，會帶來完全相反的結果。