# 策展 · X (Twitter) 🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Addy Osmani (@addyosmani) · 平台：X (Twitter) · 日期：2026-06-09

> 原始來源：https://x.com/addyosmani/status/2064127981161959567

## 中文摘要

# Loop Engineering 迴圈工程

Loop engineering 的核心在於，你不再是那個親自對 Agent 下達 Prompt 的人，而是轉而設計一套能自動執行這些任務的系統。這裡的「Loop」（迴圈）可以被視為一種遞迴式的目標：你定義一個目的，AI 則不斷迭代直到任務完成。這套機制大致由五個建構模組組成，而 Claude Code 與 Codex 目前都已具備這五項功能。

我相信這可能是我們未來與程式開發 Agent 協作的方式。不過，這一切還在早期階段，我對此仍持保留態度，且你絕對必須留意 token 的消耗（如果你的 token 額度充裕或匱乏，使用模式會有極大差異）。此外，你仍然需要某種方式來確保程式碼品質不會下降，對於「產出垃圾程式碼」（slop）的擔憂也是合理的。話雖如此，讓我們來深入探討這究竟是怎麼一回事。

@steipete 最近提到：「你不應該再對程式開發 Agent 下達 Prompt 了。你應該設計能對 Agent 下達 Prompt 的 Loop。」同樣地，Anthropic 旗下 Claude Code 的負責人 @bcherny 也說：「我不再對 Claude 下達 Prompt 了。我運行著一些 Loop，由它們來對 Claude 下達 Prompt 並決定要做什麼。我的工作是撰寫這些 Loop。」

好吧，這到底是什麼意思？

過去兩年左右，你從程式開發 Agent 獲取成果的方式，通常是撰寫一個好的 Prompt 並提供足夠的 context。你輸入指令，閱讀回傳的內容，然後輸入下一個指令。Agent 是一個工具，而你全程都在操作它，一輪接著一輪。那種模式某種程度上已經結束了，或者至少有些人認為它即將結束。

現在，你建立的是一個小型系統，它負責尋找工作、分配任務、檢查成果、記錄已完成事項，然後決定下一步，你只需要讓這個系統去驅動 Agent，而不是自己動手。我之前寫過關於這類系統的「親戚」——Agent harness engineering，也就是打造單一 Agent 運作的環境，以及「工廠模型」（factory model）——即建構軟體的系統。Loop engineering 的層級比 harness 更高。它就像是一個在計時器上運作的 harness，會產生小型輔助 Agent，並自我供給。

讓我驚訝的是，這已經不再單純是「工具」的問題了。一年前，如果你想要一個 Loop，你得寫一堆 bash 腳本，然後永遠維護那堆程式碼，那是專屬於你個人的東西。現在，這些功能直接內建在產品裡。Steinberger 的清單幾乎完全對應到 Codex 應用程式，也幾乎完全對應到 Claude Code。一旦你發現它們的架構是一樣的，你就不會再爭論哪個工具比較好，你只需要設計一個無論在哪個工具上都能運作的 Loop。

## 五個組成部分與注意事項

一個 Loop 需要五個要素，再加上一個用來記憶資訊的地方。讓我先列出來，再一一對應。

1. **自動化（Automations）**：按排程執行，並自動進行探索與分類（triage）。

2. **工作樹（Worktrees）**：讓兩個並行工作的 Agent 不會互相干擾。

3. **Skill**：記錄專案知識，否則 Agent 就只能靠猜測。

4. **Plugin 與連接器（Connectors）**：將 Agent 連接到你現有的工具。

5. **子 Agent（Sub-agents）**：讓一個 Agent 負責構思，另一個負責檢查。

接著是第六個要素：**記憶**。這可以是一個 Markdown 檔案、一個 Linear 看板，或是任何存在於單一對話之外，用來記錄「已完成」與「下一步」的東西。聽起來很簡單，甚至顯得有點笨，但這是每個長效執行 Agent 賴以生存的關鍵技巧。我在關於長效執行 Agent 的文章中提過，模型在每次執行之間會忘記所有事情，因此記憶必須存在磁碟上，而不是在 context 裡。Agent 會忘記，但儲存庫（repo）不會。

這兩款產品現在都具備了這五項功能。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780993170158-diaHKU9kOakAEj0WPpng.png)

名稱在不同地方略有差異，但能力是一樣的。讓我逐一說明，因為老實說，細節才是決定一個 Loop 是能穩固運作，還是會悄悄崩潰的關鍵。

## 自動化，這是心跳

自動化是讓 Loop 成為真正的「迴圈」，而不僅僅是一次性執行的關鍵。在 Codex 應用程式中，你可以在「自動化」分頁中建立一個任務，選擇專案、要執行的 Prompt、執行頻率，以及是在你的本地 checkout 還是背景工作樹中執行。找到問題的執行結果會進入「分類收件匣」（Triage inbox），而沒找到問題的執行則會自動封存，這很方便。OpenAI 在內部使用它們來處理瑣事，例如每日 Issue 分類、總結 CI 失敗原因、撰寫 commit 簡報、追蹤上週有人新增的 Bug。而且自動化可以呼叫一個 Skill，這樣你就能維持重複性任務的可維護性，你只需要觸發 `$skill-name`，而不是將一大堆指令貼進一個沒人會去更新的排程裡。

Claude Code 透過排程與 Hook 達到同樣的效果。你可以透過 `/loop` 以特定間隔執行 Prompt 或指令，可以排程 cron 任務，可以在 Agent 生命週期的特定時間點透過 Hook 觸發 shell 指令，或者如果你希望在關上筆電後它能繼續執行，也可以將整件事推送到 GitHub Actions。概念完全相同：你定義一個自主任務，給它一個節奏，然後結果會自動送到你面前，不需要你親自去檢查。

還有一個值得了解的「會話內」（in-session）原語，它更接近這篇文章的主題。`/loop` 會按節奏重新執行。`/goal` 則會持續執行直到你寫下的條件真正達成，且在每一輪之後，會有另一個小型模型檢查你是否完成，因此撰寫程式碼的 Agent 並不是負責評分的那一個。你給它一個目標，例如「確保 `test/auth` 中的所有測試都通過且 lint 檢查乾淨」，然後就可以走開了。Codex 也有同樣的功能，也叫 `/goal`，它會跨輪次持續工作，直到可驗證的停止條件達成，並支援暫停、恢復與清除。同樣的原語，同樣的工具，這幾乎是整篇文章的模式。

所以，這是呈現工作成果的部分。而 Loop 的其餘部分則是負責處理這些成果。

## 工作樹，讓並行執行不再混亂

一旦你同時執行多個 Agent，檔案衝突就會開始發生，這就是失敗的開始。兩個 Agent 修改同一個檔案，就像兩個工程師在沒有溝通的情況下修改同一行程式碼一樣，會造成同樣的頭痛。Git worktree 解決了這個問題，它是在同一個儲存庫歷史記錄下，於不同分支建立獨立的工作目錄，因此一個 Agent 的編輯動作絕對不會影響到另一個 Agent 的 checkout。

Codex 直接內建了對 worktree 的支援，因此多個執行緒可以同時存取同一個儲存庫而不會互相碰撞。Claude Code 透過 `git worktree` 提供同樣的隔離性，你可以使用 `--worktree` 旗標在獨立的 checkout 中開啟會話，並在子 Agent 上設定 `isolation: worktree`，讓每個輔助 Agent 都能擁有一個在結束後會自動清理的全新 checkout。我曾在「編排稅」（orchestration tax）一文中談過這一切的人性面，worktree 解決了機械式的碰撞，但「你」依然是效能的天花板，你的審核頻寬決定了你能同時執行多少任務，而不是工具本身。

## Skill，讓你不用每次都解釋專案

Skill 是讓你不再像金魚一樣，每次會話都要重新解釋專案 context 的方式。這兩款工具使用相同的格式：一個包含 `SKILL.md` 的資料夾，裡面存放指令與 metadata，以及選用的腳本、參考資料與 asset。當你使用 `$` 或 `/skills` 呼叫它，或者當你的任務與 Skill 描述相符時，Codex 就會執行該 Skill，這也是為什麼精簡且無聊的描述比花俏的描述更有用的原因。Claude Code 的運作方式相同，我已在「Agent skills」一文中寫過這種模式。

Skill 也是讓「意圖」（intent）不再重複消耗成本的地方。我在「意圖債」（intent debt）中爭論過，Agent 每次會話都是從零開始，它會用自信的猜測來填補你意圖中的任何漏洞。而 Skill 就是將那些意圖寫下來，包含慣例、建置步驟、「因為某次事故所以我們不這樣做」的規則，寫一次，Agent 每次執行時都會讀取。沒有 Skill，Loop 每個週期都會從零開始重新推導你的整個專案；有了 Skill，它就會產生累積效應。

有一點要釐清：Skill 是撰寫格式，而 Plugin 是你發布它的方式。當你想在多個儲存庫之間共享 Skill 或將幾個 Skill 打包在一起時，你會將它們封裝為 Plugin。這在 Codex 和 Claude Code 中都適用。

## Plugin 與連接器，讓 Loop 觸及你的真實工具

一個只能看到檔案系統的 Loop 是一個微小的 Loop。連接器（Connectors）建立在 MCP 之上，讓 Agent 可以讀取你的 Issue 追蹤系統、查詢資料庫、呼叫 Staging API 或在 Slack 發送訊息。Codex 和 Claude Code 都支援 MCP，所以你為其中一個寫的連接器通常在另一個也能直接使用。而 Plugin 將連接器與 Skill 打包在一起，讓你的隊友可以一次安裝好你的設定，而不需要憑記憶重新建構。

這就是「告訴你修復方案」的 Agent，與「自動開啟 PR、連結 Linear ticket 並在 CI 通過後自動在頻道發送通知」的 Loop 之間的區別。連接器是 Loop 能夠在你的實際環境中採取行動，而不僅僅是告訴你它「如果可以的話會做什麼」的原因。

## 子 Agent，讓創作者與檢查者分開

Loop 中最有用的結構，絕對是將「撰寫者」與「檢查者」分開。撰寫程式碼的模型在評分自己的作業時太過寬容了。第二個擁有不同指令、有時甚至使用不同模型的 Agent，可以抓出第一個 Agent 自圓其說的錯誤。

Codex 只有在你要求時才會產生子 Agent，它們會同時執行，然後將結果合併為一個答案。你可以在 `.codex/agents/` 中將自己的 Agent 定義為 TOML 檔案，每個檔案包含名稱、描述、指令以及選用的模型與推理強度，這樣你的安全性審核員可以使用高強度的強大模型，而你的探索者可以使用快速的唯讀模型。Claude Code 在 `.claude/agents/` 中也有類似的子 Agent 設定，以及可以在它們之間傳遞工作的 Agent 團隊。兩者常見的分工都是：一個 Agent 負責探索，一個負責實作，一個負責根據規格進行驗證。

我已經兩次提出這個觀點，一次是作為「程式開發 Agent 樂團」，一次是作為「對抗式程式碼審核」。它在 Loop 中特別重要的原因是，Loop 會在你沒在看的時候執行，因此一個你真正信任的驗證者，是你敢於放手讓它執行的唯一理由。子 Agent 確實會消耗更多 token，因為每個 Agent 都有自己的模型與工具運作成本，所以請將 token 花在值得尋求第二意見的地方。這基本上也是 Claude Code 的 `/goal` 在底層所做的事：由一個全新的模型來決定 Loop 是否完成，而不是由執行工作的那個模型來決定。這就是將「創作者與檢查者分離」應用在停止條件本身。

## 一個 Loop 的樣貌

將這些拼湊起來，單一執行緒就會變成一個小小的控制面板。這是我一直使用的一種架構：

一個自動化任務每天早上在儲存庫上執行。它的 Prompt 會呼叫一個分類 Skill，讀取昨天的 CI 失敗記錄、開啟的 Issue、最近的 commit，並將發現的內容寫入 Markdown 檔案或 Linear 看板。對於每一項值得處理的發現，執行緒會開啟一個獨立的 worktree，並派遣一個子 Agent 來草擬修復方案，再由第二個子 Agent 根據專案 Skill 與現有測試來審核該草案。

連接器讓 Loop 可以開啟 PR 並更新 Ticket。任何 Loop 無法處理的事情，都會進入我的分類收件匣。狀態檔案（state file）是整個系統的脊椎，它記住了嘗試過什麼、什麼通過了、什麼還沒處理，所以明天早上執行時，會從今天結束的地方繼續。

看看你實際上做了什麼。你設計了它一次。你沒有對那些步驟下達任何 Prompt。這就是 Steinberger 的觀點成真，而且無論是在 Codex 還是 Claude Code 中，Loop 都是一樣的，因為它們的零件都是一樣的。

## Loop 依然無法為你做的事

Loop 改變了工作方式，但並沒有將你從工作中剔除。而且隨著 Loop 變得越來越強大，有三個問題反而變得更尖銳，而不是更容易。

**驗證依然是你的責任。** 無人看管的 Loop 也是會犯錯的 Loop。你將驗證子 Agent 與創作者分開的全部原因，是為了讓 Loop 的「已完成」具有意義，即便如此，「已完成」也只是一個聲明，而非證明。我一直在重複 AI 時代程式碼審核的那句話：你的工作是交付你確認過能運作的程式碼。

**如果你放任不管，你的理解力依然會退化。** Loop 交付你未親手撰寫的程式碼速度越快，現有程式碼與你實際理解之間的差距就越大。這就是「理解債」（comprehension debt），除非你閱讀 Loop 所產生的內容，否則順暢的 Loop 只會讓這筆債務增長得更快。

是的，舒適的姿勢往往是最危險的。當 Loop 自動執行時，很容易停止思考並直接接受它給出的任何結果。我稱之為「認知投降」（cognitive surrender）。當你帶著判斷力去設計 Loop 時，它是解藥；當你為了逃避思考而設計它時，它就是加速器。同樣的動作，結果卻截然不同。

## 建立 Loop。保持工程師的本色。

我認為這是我們工作將如何演變的預覽。話雖如此，如果我不親自審核程式碼，或者完全依賴自動化 Loop 來修復它，我產品的品質就會受損。我可能會陷入惡性循環，不斷地讓自己陷入更深的坑裡。

話說回來，儘管去設定你的 Loop 吧，但別忘了直接對 Agent 下達 Prompt 依然有效。重點在於找到正確的平衡。

Loop 的結果也可能因你而異。兩個人可以建立完全相同的 Loop，卻得到截然不同的結果。一個人用它來加速自己深入理解的工作；另一個人則用它來完全逃避理解工作。Loop 本身無法分辨其中的差異，但你可以。

這就是為什麼 Loop 設計比 Prompt Engineering 更難，而不是更容易。Cherny 的觀點並不是說工作變簡單了，而是槓桿點轉移了。

去建立 Loop 吧。但要像一個打算保持工程師本色的人那樣去建立它，而不僅僅是一個按下「開始」按鈕的人。

## 標籤

Agent, Claude Code, Codex, 產業趨勢, 自動化, Anthropic, Claude, Codex