原文標題：循環工程。
原文作者：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 engineering（循環工程）正在取代你作為「給智能體寫提示詞的人」的角色。你要設計一個系統，讓這個系統替你去提示智能體。這裡的 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，而不是把一整牆的說明文字貼上進一個以後沒人會更新的計劃任務裡。

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

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

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

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

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

Codex 直接內置了 worktree 支援，所以多個線程可以同時處理同一個程式庫而不會相互衝撞。克劳德代碼 也可以通過 git worktree 實現同樣的隔離：你可以用 --worktree flag 在獨立 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 追蹤器、查詢資料庫、呼叫 staging API，或者在 Slack 裡發消息。Codex 和 Claude Code 都支持 MCP，所以你為其中一個寫的 connector，通常也能在另一個裡使用。Plugins 則會把 connectors 和 skills 打包在一起，讓你的隊友一次安裝完整配置，而不是憑記憶重建整套東西。

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

子代理：讓製作者遠離檢查者

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

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

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

一個循環長什麼樣

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

每天早上，一個自動化在程式碼倉庫上運行。它的提示詞會調用一個 triage skill，讀取昨天的 CI 失敗、開放中的 issues、最近的 commits，並把發現寫入一個 Markdown 檔案或 Linear 看板。對於每一個值得處理的問題，線程會打開一個隔離的 worktree，派一個子代理草擬修復方案，再派第二個子代理根據專案 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 只是為了逃避思考，它就是加速劑。同一個動作，會帶來完全相反的結果。

構建 loop，但仍然做工程師

我認為，這預示著我們未來工作的演化方向。話雖如此，如果我不親自審查代碼，或者完全依賴自動化 loop 去修復代碼，我的產品質量就會受到損害。我很可能會陷入一種向下螺旋：不斷把自己挖進更深的坑裡。

所以，你當然可以去搭建自己的 loop，但別忘了，直接提示你的智能體依然是有效的。關鍵在於找到合適的平衡。

Loop 的結果也會因人而異。兩個人可以構建完全相同的 loop，卻得到截然相反的結果。一個人用它在自己深刻理解的工作上提速；另一個人用它來逃避理解工作本身。Loop 並不知道這兩者之間的區別。你知道。

這就是為什麼 loop design（循環設計）比 prompt engineering（提示詞工程）更難，而不是更簡單。Cherny 的意思並不是工作變輕鬆了，而是杠杆點轉移了。

構建 loop。但要像一個仍然打算做工程師的人那樣去構建它，而不是像一個只負責按下「開始」按鈕的人。

[原文鏈接]

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia