迴圈工程

以下文章最初出現在 Addy Osmani 的部落格上，經作者許可在此轉載。

迴圈工程是指將你自己從提示代理的角色中替換出來，轉而設計系統來執行提示。這裡的“迴圈”可以理解為一個遞迴目標：你定義一個目的，然後 AI 迭代直到完成。我相信這可能是我們未來與編碼代理協作的方式。不過，這仍處於早期階段；我持懷疑態度，而且你必須小心令牌成本（如果你令牌充足或匱乏，使用模式可能大相徑庭）。因此，我想剖析它到底是什麼以及意味著什麼。

Peter Steinberger 最近說：“你不應該再提示編碼代理了。你應該設計迴圈來提示你的代理。” 同樣，Anthropic 的 Claude Code 負責人 Boris Cherny 說：“我不再提示 Claude 了。我有迴圈在執行，提示 Claude 並決定做什麼。我的工作是編寫迴圈。”

好吧，這到底意味著什麼？

大約兩年以來，從編碼代理獲取結果的方式是編寫一個良好的提示並分享足夠的上下文。你輸入內容，閱讀回覆，然後繼續輸入下一個指令。代理是一個工具，你全程掌控，一個回合接一個回合。這部分已經結束了，或者至少有些人認為它將成為過去。

現在，你構建一個小型系統，它負責發現任務、分配任務、檢查結果、記錄完成情況，然後決定下一步。你讓這個系統去操控代理，而不是你自己。我之前寫過它的表親——代理框架工程，即打造單個代理執行的環境，以及工廠模式——構建軟體的系統。迴圈工程位於框架之上：框架加上定時器、生成子幫手，並自我反饋。

讓我驚訝的是，這已經不再是工具層面的問題。一年前，如果你想實現一個迴圈，你需要編寫一堆 bash 指令碼，並永久維護它，而且它只屬於你。現在，這些元件直接內建於產品中。Steinberger 的列表幾乎完全對映到 Codex 應用，然後同樣對映到 Claude Code。一旦你注意到形狀相同，你就不會再爭論哪個工具更好。你只需設計一個迴圈，無論你使用哪個工具，它都能正常工作。

五個元件及說明

一個迴圈需要五個東西，加上一個記錄狀態的地方。我先列出，然後對映到具體工具。

按計劃自動執行並自行發現和分類的自動化 工作樹（Worktrees），使並行執行的兩個代理不會相互干擾 技能（Skills），記錄專案知識，代理否則只能猜測 外掛和聯結器（Plugins and Connectors），將代理連線到你已經使用的工具 子代理（Subagents），讓一個代理產生想法，另一個代理進行檢查

然後是第六個東西：記憶。一個 Markdown 檔案，或一個 Linear 看板，任何存在於單個對話之外並能記錄已完成和下一步的內容。聽起來太簡單以至於無關緊要，但這是每個長期執行的代理所依賴的相同技巧，我在“長期執行代理”中詳細討論過：模型在執行之間會忘記一切，因此記憶必須儲存在磁碟上，而不是在上下文中。代理會忘記，但倉庫不會。

現在兩種產品都具備這五個元件。

PrimitiveJob in the loop Codex app Claude Code Automations 按計劃發現和分類 自動化標籤：選擇專案、提示、節奏、環境；結果進入分類收件箱；/goal 用於執行直到完成 定時任務和 cron，/loop，/goal，鉤子，GitHub Actions Worktrees 隔離並行功能 內建每個執行緒的工作樹 git worktree，--worktree，隔離：子代理上的 worktree Skills 編碼專案知識 代理技能（SKILL.md），透過 $name 或隱式呼叫 代理技能（SKILL.md） Plugins and connectors 連線你的工具 聯結器（MCP）加外掛用於分發 MCP 伺服器加外掛 Subagents 構思與驗證 在 .codex/agents/ 中定義為 TOML 的子代理 在 .claude/agents/ 中的任務子代理，代理團隊 State 跟蹤完成情況 透過聯結器實現的 Markdown 或 Linear Markdown（AGENTS.md，進度檔案）或透過 MCP 的 Linear

名稱略有不同，但功能相同。讓我們逐一介紹，因為細節決定了迴圈是穩固執行還是四處洩漏。

自動化是心跳

自動化是使迴圈成為真正迴圈的關鍵，而不僅僅是一次性執行。在 Codex 應用中，你在自動化標籤頁建立一個自動化，選擇專案、提示、執行頻率以及是在本地檢出還是後臺工作樹上執行。發現問題的執行結果進入分類收件箱，沒有發現問題的執行則自行歸檔，這很不錯。OpenAI 內部將其用於無聊的任務，如每日問題分類、總結 CI 失敗、編寫提交簡報以及追蹤上週新增的 bug。而且自動化可以呼叫技能，因此你可以保持重複性任務的可維護性；你呼叫 $skill-name，而不是將一長串指令貼上到永遠無人更新的計劃中。

Claude Code 透過排程和鉤子達到同樣的目的。你可以使用 /loop 按間隔執行提示或命令，可以排程 cron 任務，可以在代理生命週期中的特定點透過鉤子觸發 shell 命令，或者如果你希望關閉筆記型電腦後繼續執行，可以將整個任務推送到 GitHub Actions。完全相同的想法：你定義一個自主任務，指定節奏，然後結果會自動呈現給你，這樣你就不必親自四處檢查了。

還有一個會話內的原語值得了解，它與本文的主題更接近。/loop 按節奏重複執行。/goal 繼續執行直到你編寫的條件為真，並且每個回合後有一個單獨的小模型檢查是否完成，這樣編寫程式碼的代理就不是評估者。你給出類似“test/auth 中的所有測試透過且 lint 乾淨”的條件，然後走開。Codex 也有同樣的功能，也稱為 /goal：它跨回合繼續工作，直到可驗證的停止條件成立，並支援暫停、恢復和清除。相同的原語，兩種工具，這幾乎是本文的整個模式。

所以，這部分是浮現任務的部分。迴圈的其餘部分是對任務採取行動。

工作樹，讓並行不變成混亂

一旦你執行多個代理，檔案開始衝突；這就成了失敗。兩個代理寫入同一個檔案就像兩個工程師在沒有事先溝通的情況下提交到同一行程式碼一樣令人頭疼。Git 工作樹解決了這個問題。它是一個獨立的工作目錄，擁有自己的分支，共享相同的倉庫歷史，因此一個代理的編輯完全不會影響另一個的檢出。

Codex 內建了工作樹支援，因此多個執行緒可以同時訪問同一個倉庫而不互相碰撞。Claude Code 透過 git worktree、--worktree 標誌（在獨立檢出中開啟會話）以及 isolation: worktree 設定（應用於子代理，使每個助手獲得一個自動清理的新檢出）提供了相同的隔離功能。（我在“編排稅”中寫過這一切的人類層面。）工作樹消除了機械衝突，但你仍然是瓶頸。你審查的頻寬決定了你能實際執行多少個代理，而不是工具。

技能，讓你不再每次都解釋專案

技能讓你不再像金魚一樣每次會話都重新解釋相同的專案上下文。兩種工具使用相同的格式：一個包含 SKILL.md 的資料夾，裡面存放指令和後設資料，以及可選的指令碼、參考檔案和資源。Codex 在你透過 $ 或 /skills 呼叫技能，或者當任務與技能描述匹配時自動執行技能。因此，一個緊湊、無聊的描述勝過聰明的描述。Claude Code 以相同的方式處理，我在“代理技能”中寫過這個模式。

技能也是意圖不再重複花費的地方。我在“意圖債務”中指出，代理每次會話從零開始，它會用自信的猜測填補你意圖中的任何漏洞。技能是將意圖寫在外部，包括約定、構建步驟、“我們因為那次事故不這樣做”等，只寫一次，而代理每次執行都會讀取。沒有技能，迴圈每個週期都會從零重新推導整個專案；有了技能，它會不斷積累。

有一點要分清：技能是創作格式，外掛是釋出方式。當你想跨倉庫共享技能或將多個技能打包時，你將它們打包為外掛。Codex 和 Claude Code 都是如此。

外掛和聯結器，迴圈接觸你的真實工具

只能看到檔案系統的迴圈是個微小的迴圈。聯結器基於 MCP，允許代理讀取你的問題跟蹤器、查詢資料庫、訪問暫存 API 或在 Slack 上傳送訊息。Codex 和 Claude Code 都支援 MCP，因此你為其中一個編寫的聯結器通常也可以用於另一個。而外掛將聯結器和技能打包在一起，使你的隊友可以一次性安裝你的設定，而不用憑記憶重建整個環境。

這就是代理說“這是修復方法”與迴圈自動建立 PR、關聯 Linear 工單、並在 CI 透過後自動通知頻道的區別。聯結器使得迴圈能夠在你實際環境中行動，而不僅僅是告訴你如果它能做到會做什麼。

子代理，讓編寫者與檢查者分離

迴圈中最有用的結構無疑是分離編寫者和檢查者。編寫程式碼的模型在評估自己的作業時過於寬容。另一個具有不同指令（有時是不同模型）的代理會捕捉到第一個代理自己說服自己相信的錯誤。

Codex 只在請求時生成子代理，同時執行它們，然後將結果合併為一個答案。你在 .codex/agents/ 中定義自己的代理為 TOML 檔案，每個代理包含名稱、描述、指令以及可選的模型和推理努力度，這樣你的安全審查者可以使用高努力度的強模型，而你的探索者可以使用快速只讀的模型。Claude Code 透過 .claude/agents/ 中的子代理和在它們之間傳遞工作的代理團隊實現同樣的功能。兩者的常見分工是一個代理探索，一個代理實現，一個代理根據規格驗證。

我已經兩次提出這個觀點，一次是“程式碼代理管絃樂隊”，一次是“對抗性程式碼審查”。它在迴圈中特別重要的原因是迴圈在你不在場時執行，因此一個你真正信任的驗證者是你能夠走開的唯一理由。子代理確實會消耗更多令牌，因為每個代理都執行自己的模型和工具工作，因此將令牌用在值得付出第二次意見的地方。這基本上也是 Claude Code 的 /goal 在底層所做的：一個全新的模型決定迴圈是否完成，而不是執行工作的那個——編寫者與檢查者的分離應用於停止條件本身。

一個迴圈的樣子

將所有元件組合在一起，一個單執行緒就變成了一個小控制面板。這是我經常使用的一個形狀。

一個自動化每天早上在倉庫上執行。它的提示呼叫一個分類技能，讀取昨天的 CI 失敗、未解決的問題和最近的提交，並將結果寫入 Markdown 檔案或 Linear 看板。對於每個值得做的發現，執行緒開啟一個隔離的工作樹，併傳送一個子代理來起草修復，第二個子代理根據專案技能和現有測試審查該草案。

聯結器允許迴圈建立 PR 並更新工單。迴圈無法處理的任何問題都會進入我的分類收件箱。狀態檔案是整個迴圈的脊柱；它記住嘗試了什麼、透過了什麼以及還有什麼待辦。