編輯 | 澤南

2026 年，會不會用 AI 不再看 Prompt（提示詞）能力了，而是要看會不會設計循環。

上周，谷歌云 AI 總監 Addy Osmani 的一篇博客文章《Loop Engineering》引發了社區的討論。

Addy Osmani 是一位在前端開發、Web 性能優化以及 AI 開發者工具領域都有影響力的工程師和技術領導者。他最廣為人知的身份是曾任 Chrome 開發者體驗團隊的領導人。

他所討論的「循環工程」概念有關設計代碼智能體實行循環驗證提升的方式。Addy Osmani 表示，就算是使用同樣的大模型，會不會用這種思路，產生的結果將會完全不同

讓我們看看這篇文章是怎么說的：

「循環工程」（Loop engineering）指的是不再由你親自向編程智能體（coding agent）發送指令，而是設計一套系統來自動執行這一過程。這里的「循環」可以理解為一種遞歸式目標：你設定一個意圖，AI 則不斷迭代直至任務完成。這一模式大致包含五個核心組件，而 Claude Code 和 Codex 目前都已具備了這全部五個要素。

我相信，這很可能就是我們未來與編程智能體協作的主流方式。不過，目前尚處于早期階段，我對此持保留態度；此外，你必須格外關注 Token 成本問題（根據 Token 預算的充裕程度，使用模式可能會有天壤之別）。同時，如何確保代碼質量不下滑也是個問題，人們對于產出低質量代碼的擔憂不無道理。話雖如此，讓我們深入探討一下這究竟是怎么一回事。

龍蝦作者 Peter Steinberger 最近指出：「你不應再直接向編程智能體發送指令，而應設計能夠自動向智能體發送指令的『循環』。」

Anthropic 旗下 Claude Code 的負責人 Boris Cherny 也表達了類似的觀點：「我不再直接向 Claude 發送指令了。我運行著一些循環程序，由它們負責向 Claude 發送指令并決定下一步做什么。我的工作變成了編寫這些循環程序。」

那么，這一切具體意味著什么呢？

過去大約兩年里，利用編程智能體完成任務的方式通常是：編寫高質量的提示詞（prompt）并提供充足的上下文信息。你輸入指令，查看反饋，再輸入下一條指令。智能體就像一件工具，你始終握著它，進行著一輪又一輪的交互。那種模式某種程度上已經過時了 —— 至少許多人認為它即將成為過去式。

如今，你需要構建一個小系統來發現任務、分配任務、檢查結果、記錄進度并決定下一步行動；由這個系統去驅動智能體，而不是由你親自動手。我之前寫過關于「智能體支撐框架工程」（agent harness engineering）的內容 —— 即構建單個智能體運行的環境，以及「工廠模型」（即構建軟件的系統）。「循環工程」則處于支撐框架之上：它基于定時器運行，能生成小型輔助程序，并能實現自我驅動。

令我驚訝的是，這已不再僅僅是關于「工具」的問題了。一年前，如果你想要實現這種循環，往往需要編寫一大堆 Bash 腳本，并長期維護這堆代碼 —— 那是完全屬于你個人的東西。如今，這些組件已直接內置于產品之中。

Steinberger 提出的要素清單幾乎完全對應于 Codex 應用，同時也基本適用于 Claude Code。一旦你發現兩者的模式如出一轍，便無需再糾結于選擇哪款工具；你只需設計一套工作閉環，無論身處哪個平臺，這套流程都能順暢運行。

五大要素及相關說明

一個完整的工作閉環需要五個要素，外加一個用于存儲信息的載體：

1. 按預定計劃自動運行，并能自主進行任務發現與分揀的自動化機制。
2. 支持多工作樹（worktrees）機制，能確保并行工作的智能體互不干擾。
3. 用于記錄項目知識的 skill 模塊，避免智能體在缺乏信息時只能靠「猜」來行事。
4. 插件與連接器，用于將智能體接入你現有的工具鏈中。
5. 子智能體機制，實現由一個智能體構思方案，而由另一個進行驗證的協作模式。

最后是第六個要素：記憶存儲。這可以是一個 Markdown 文件、一塊 Linear 看板，或是任何獨立于單次對話之外、用于記錄已完成工作及后續計劃的載體。這聽起來似乎微不足道，但這正是所有長期運行的智能體所依賴的關鍵機制 —— 正如我在探討「長期運行智能體」時所分析的，模型在兩次運行之間會遺忘所有信息，因此記憶必須存儲在磁盤上，而不能僅依賴上下文（context）。智能體會遺忘，但代碼倉庫（repo）會保留記錄。

如今，Claude Code 與 Codex 已具備了上述全部五個要素

雖然各處的命名略有差異，但核心功能是一樣的。讓我們逐一探討，因為說實話，細節往往決定了一個循環（loop）是能穩健運行，還是會悄無聲息地出現各種問題。

自動化（Automations）

核心驅動力

正是自動化讓「循環」名副其實，使其不僅僅是一次性的單次運行。在 Codex 應用中，你可以在「自動化」標簽頁創建一個任務，指定項目、要運行的提示詞、執行頻率，以及是在本地檢出（local checkout）的代碼上運行，還是在后臺工作樹（background worktree）上運行。發現問題的運行結果會進入「分類收件箱」（Triage inbox），而未發現問題的運行則會自動歸檔 —— 這非常方便。OpenAI 內部利用它來處理一些枯燥瑣碎的任務，比如每日問題分類、總結 CI 失敗情況、撰寫提交摘要，或是查找上周有人引入的 Bug。

此外，自動化任務還可以調用 skill，從而保證重復性任務的可維護性：你只需觸發 $skill-name，而無需將一大段冗長的指令硬塞進一個沒人會去更新的調度配置里。

Claude Code 實現了同樣的目標，但采用的是調度（scheduling）和 hooks 機制。你可以使用 /loop 按固定間隔運行提示詞或命令，可以設置 cron 任務，可以通過鉤子在智能體生命周期的特定節點觸發 Shell 命令，或者將其推送到 GitHub Actions，以便在你合上筆記本電腦后任務仍能繼續運行。理念完全一致：定義一個自主任務，設定執行節奏，讓結果自動反饋給你，而無需你親自四處檢查。

還有一個值得了解的會話內原語（primitive），它更貼近本文的主題。/loop 是按節奏重復運行的；而 /goal 則會持續運行，直到滿足你設定的條件為止。在每一輪運行結束后，會有一個獨立的小型模型來檢查任務是否完成，這意味著編寫代碼的智能體并不負責評估結果。你只需設定類似「test/auth 目錄下的所有測試通過且代碼檢查（lint）無誤」這樣的目標，然后就可以去做別的事了。

Codex 也有同樣的功能，同樣稱為 /goal：它跨輪次持續工作，直到滿足可驗證的停止條件，并支持暫停、恢復和清除操作。同樣的機制，同樣的工具 —— 這正是貫穿整篇文章的模式。

這就是將工作成果呈現出來的環節。循環的其余部分負責對它進行操作。

Worktree（工作樹）

避免并行操作引發混亂

一旦運行多個智能體，文件沖突就會導致失敗。兩個智能體寫入同一個文件，就像兩個工程師在未溝通的情況下修改同一行代碼一樣令人頭疼。Git Worktree 解決了這個問題：它是在同一倉庫歷史基礎上、位于獨立分支上的獨立工作目錄，因此一個智能體的修改絕對不會影響另一個智能體的檢出（checkout）內容。

Codex 內置了對 Worktree 的支持，允許多個線程同時訪問同一個倉庫而互不干擾。Claude Code 也通過 Git Worktree 提供了同樣的隔離機制：使用 --worktree 標志可以在獨立檢出環境中開啟會話，或者在子智能體上設置 isolation: worktree，讓每個輔助智能體獲得一個全新的檢出環境，并在任務結束后自動清理。我在「編排成本」（orchestration tax）一文中探討了其中的人為因素：Worktree 解決了機械性的沖突問題，但人依然是瓶頸所在 —— 決定你能實際運行多少個智能體的是你的代碼審查能力，而不是工具本身。

Skills

無需每次都重新解釋項目

「技能」機制能讓你擺脫那種像金魚一樣、在每次會話中都要反復解釋項目背景的困境。這兩種工具采用相同的格式：一個包含 SKILL.md 文件的文件夾（其中存有指令和元數據），以及可選的腳本、參考資料和資源文件。Codex 會在用戶通過 $ 或 /skills 調用時，或者當任務與技能描述匹配時自動運行該技能 —— 這正是精準、平實的描述要優于花哨描述的原因。Claude Code 的運作方式也如出一轍，我在「智能體技能」一文中詳細闡述了這一模式。

「技能」也是解決「意圖成本」反復消耗問題的關鍵。智能體每次會話都是從零開始的，它會自信地填補你意圖中的任何空白。而「skill」就是將這些意圖（如約定俗成的規范、構建步驟、諸如「因為某次事故所以我們不這么做」之類的經驗教訓）顯式地記錄下來；只需編寫一次，智能體每次運行時都會讀取。如果沒有技能，循環會在每個周期從零開始重新推導整個項目；有了技能，知識積累就能產生疊加效應。首先要明確一點：Skill 指的是創作格式，而 Plugin 則是交付它的方式。當你需要在不同代碼倉庫間共享 Skill，或者將多個 Skill 組合在一起時，就可以把它們打包成 Plugin。這一邏輯在 Codex 和 Claude Code 中均適用。

Plugins 與 Connector

讓「循環」能夠與你的實際工具交互

如果一個「循環」只能訪問文件系統，那它的能力將非常有限。基于 MCP 構建的連接器（Connectors）則打破了這一局限，讓智能體能夠讀取 Issue 追蹤系統、查詢數據庫、調用預發布環境（staging）的 API，甚至在 Slack 上發送消息。由于 Codex 和 Claude Code 都支持 MCP 標準，因此你為其中一個編寫的連接器，通常也能直接在另一個中運行。此外，插件將連接器和 Skill 整合在一起，方便你的團隊成員一鍵安裝并使用整套配置。

而不是完全憑記憶從頭重建。

這就是「只會說『修復方案如下』的智能體」與「能自動提交 PR、關聯 Linear 工單并在 CI 通過后在頻道通知的循環」之間的區別。正是因為有了連接器，循環才能在你的實際環境中采取行動，而不只是空談它「如果能操作的話」會做什么。

子智能體

將「執行者」與「檢查者」分離

在循環機制中，最有用的結構性設計莫過于將編寫代碼的角色與檢查代碼的角色分離開來。負責寫代碼的模型在評估自己的「作業」時往往過于寬容；而另一個擁有不同指令（有時甚至使用不同模型）的智能體，則能發現第一個智能體因自我合理化而忽略的問題。

Codex 僅在你明確要求時才會啟動子智能體，讓它們并行運行，最后將結果匯總為一個答案。你可以通過 .codex/agents/ 目錄下的 TOML 文件定義自己的智能體，每個智能體包含名稱、描述、指令以及可選的模型和推理強度設置；這樣，你的安全審查員可以是高推理強度的強大模型，而負責探索任務的智能體則可以是快速、只讀的輕量級模型。Claude Code 也有類似機制，利用 .claude/agents/ 中的子智能體和智能體團隊在彼此間傳遞任務。在這兩種工具中，常見的角色分工通常是：一個負責探索，一個負責實現，另一個根據規范進行驗證。

我之前曾兩次闡述過這一理念：一次是將其稱為「代碼智能體編排（orchestra）」，另一次則稱之為「對抗式代碼審查」。之所以在循環機制中這一點尤為重要，是因為循環是在你無人值守的情況下運行的；只有擁有一個你真正信任的驗證者，你才能放心地離開。子智能體確實會消耗更多 Token（因為每個智能體都要獨立進行模型調用和工具操作），因此應將資源投入到那些值得獲取「第二意見」的環節中。這其實也是 Claude Code 的 /goal 命令在底層運作的原理：由一個全新的模型（而非執行任務的那個模型）來判斷循環是否結束 —— 即將「執行者」與「檢查者」分離的原則應用到了終止條件的判定上。

一個循環的典型形態

將這些組件組合起來，單一的執行流就變成了一個小型控制面板。以下是我經常采用的一種模式。

針對代碼倉庫，每天早上運行一次自動化任務。它的提示詞（prompt）會調用一個「分診」技能（triage skill），該技能讀取昨天的 CI 失敗記錄、未解決的問題（open issues）和最近的代碼提交，并將分析結果寫入 Markdown 文件或 Linear 看板中。對于每一項值得處理的問題，流程會創建一個獨立的工作樹（worktree），并派遣一個子智能體（sub-agent）起草修復方案，隨后由第二個子智能體根據項目的既有技能和現有測試用例對該草案進行審查。

通過連接器（connectors），該循環能夠自動創建 PR 并更新工單狀態。凡是循環無法處理的事項，都會進入「分診收件箱」等待我親自處理。狀態文件是整個系統的核心，它記錄了已嘗試的操作、已通過的任務以及未完成的工作，確保明早的運行能從今天中斷的地方繼續進行。

回想一下你實際做了什么：你只進行了一次設計，而無需針對后續的每一步驟單獨下達指令。這正是 Steinberger 觀點的具體實現；無論是在 Codex 還是 Claude Code 中，其循環邏輯都是一樣的，因為底層的組件是相同的。

循環仍然無法代勞的事項

循環改變了工作方式，但并未將你從工作中剔除。事實上，隨著循環能力的提升，有三個問題反而會變得更加棘手，而非變得簡單。

驗證工作依然由你負責。一個無人值守運行的循環，也可能在無人監督的情況下犯錯。將驗證子智能體與執行子智能體分離開來，其目的正是為了賦予循環所宣稱的「已完成」狀態以實質意義 —— 即便如此，「已完成」也只是一種聲明，而非確鑿的證明。有句適用于 AI 時代代碼審查的話：你的職責是交付那些經你確認可正常運行的代碼。

如果你疏于維護，你對代碼的理解就會逐漸退化。循環交付非你親手編寫代碼的速度越快，現有代碼與你實際掌握情況之間的鴻溝就越大。這就是「理解債務」（comprehension debt）；除非你親自閱讀循環生成的代碼，否則高效的循環只會讓這種債務積累得更快。

沒錯，那種看似舒適的狀態往往伴隨著風險。當循環自動運行時，人很容易放棄獨立思考，轉而全盤接受它給出的結果。我稱之為「認知投降」（cognitive surrender）。設計循環時，若能保持判斷力，它便是良方；若僅僅為了逃避思考而設計，它便成了加速惡化的催化劑 —— 同樣的動作，結果卻截然不同。

構建循環，堅守工程師本色。我認為這預示了我們工作方式的演變方向。話雖如此，如果我不親自審查代碼，或者完全依賴自動化循環來修復問題，產品的質量就會受損。我恐怕會陷入惡性循環，越陷越深。

當然，你可以著手構建這些循環，但別忘了，直接向智能體下達指令依然行之有效。關鍵在于找到合適的平衡點。

同樣的循環機制，因使用者不同，結果也可能截然不同。兩個人構建完全相同的循環，可能會得出完全相反的結論：一個人利用它來加速處理自己深刻理解的工作，而另一個人則利用它來徹底回避對工作的理解。循環本身無法區分這兩者，但你能。

正因如此，設計循環比編寫提示詞更具挑戰性。

這是工程工作，并未變得更輕松。并非工作本身變簡單了，而是關鍵的杠桿點發生了轉移。

去構建這個循環吧。但構建時，要懷著一種「立志深耕工程領域」的心態，而不僅僅是做一個只會按下啟動鍵的人。

參考內容：

https://x.com/addyosmani/status/2064127981161959567