循環工程

以下文章最初出現在 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 並更新工單。循環無法處理的任何問題都會進入我的分類收件箱。狀態文件是整個循環的脊柱；它記住嘗試了什麼、通過了什麼以及還有什麼待辦。