我現在不再手動提示 Claude 了。我有一些正在運行的循環，它們會提示 Claude 並決定下一步要做什麼。我的工作是編寫這些循環。
—— Boris Cherny，Anthropic 公司 Claude Code 的創始人兼負責人。
大約兩年來，大家追逐的技能都是提示工程。寫一個好的提示、提供足夠的上下文、閱讀輸出、再寫下一個提示。你把 Agent 當作一個工具，一次只進行一輪互動。
那個時代正在悄然結束。
在 2026 年中，三位意見領袖在幾天內不約而同地提出了相同的想法。Boris Cherny（Claude Code）說他現在的工作是編寫循環。Peter Steinberger（OpenClaw 的創始人）告訴數百萬開發者：「你不應該再手動提示編碼 Agent 了。你應該設計循環來提示你的 Agent。」 而 Addy Osmani（Google）在一篇廣為流傳的文章中為這個模式命名：循環工程 (Loop Engineering)。這篇文章將深入解析循環工程到底是什麼、它解決了哪些問題、如何解決、一個你現在就能運行的實際程式碼範例，以及那些在 hype 討論中從未被提及的誠實取捨。
什麼是循環工程？
循環工程就是取代你自己成為提示 Agent 的那個人。你設計一個系統來代替你進行提示。
一個循環是一個遞迴目標：你定義一個目的和一個可驗證的停止條件，然後 AI 會迭代，發現工作、執行工作、驗證工作、記錄進度，直到條件成立為止。你不再身處循環之中。你凌駕於循環之上。
你可以這樣理解這個層級結構：
- 提示工程：你撰寫一個好的指令。
- 上下文工程：你圍繞指令組裝正確的資訊。
- Agent 框架工程：你構建一個 Agent 運行的環境。
- 循環工程：你構建一個系統，該系統定時運行框架、產生輔助 Agent、檢查其狀態。
舊的工作流程：撰寫提示 → 閱讀輸出 → 撰寫下一個提示（你就是那個循環）。
新的工作流程：設計一次循環 → 循環發現工作 → 循環指派 Agent → 循環驗證 → 循環記錄狀態 → 重複（你負責審查和引導）。
循環工程解決的問題
問題 1：你就是瓶頸
在手動提示中，除非你打字，否則什麼都不會發生。每一輪互動都在等待人類。2026 年的 Agent 可以自主運行數小時，Claude Opus 級別的模型在困難任務上已經可以無人值守運行近五個小時——但人類驅動的對話將其限制在你的打字速度和注意力範圍內。Agent 有 95% 的時間處於空閒狀態，等待你。
問題 2：Agent 在每次會話之間會忘記一切
每次會話都是從頭開始。模型會從零開始重新推導你專案的慣例、建置步驟和來之不易的經驗教訓——或者更糟，用自信的猜測來填補空白。這就是 Osmani 所說的意圖債務 (intent debt)：未說明的意圖在每次運行時都必須被償還（或重新猜測）。
問題 3：Agent 給自己的作業打分
寫了程式碼的 Agent 在審查時會過於寬容。「完成了」只是一個聲明，而不是一個證明。沒有獨立的驗證，自主運行會累積錯誤，而不是修復它們。
問題 4：並行 Agent 會互相衝突
當你在一個儲存庫上運行多個 Agent 時，它們會開始互相覆蓋對方的檔案——就像兩個工程師不溝通就直接提交到同一行程式碼一樣的災難。
問題 5：重複性工作從未被自動化
CI 失敗排查、依賴項更新、處理不穩定測試、問題標籤分類、每日錯誤清理——這些工作無聊、無窮無盡，並且非常適合 Agent 處理。但是沒有人會每天早上手動提示一個 Agent 去做這些事，因為你必須每天早上出現來進行提示。
循環工程如何解決這些問題：六個基本構建模組
一個能真正無人值守運行的循環不是一個長長的提示。它是一個包含五種能力加一個記憶體的小型系統。值得注意的是，Claude Code 和 OpenAI 的 Codex 現在都原生提供了這六個要素——循環的形狀已經變得與工具無關。
- 自動化 (Automations)：心跳
排程運作，能自行發現問題並進行分類。這解決了問題 5。
- Claude Code: /loop 按節奏重新運行一個提示（從一分鐘間隔到多天窗口）、cron 排程任務、用於雲端排程自動化的 Routines、生命週期鉤子，或使用 GitHub Actions 來確保在你關閉筆記型電腦後仍能持續運行。
- Codex: Automations 標籤頁——選擇一個專案、一個提示、一個節奏；結果會進入 Triage 收件匣，空的運行會自動歸檔。
會話中最強大的原語是 /goal：在你撰寫的條件（例如「test/auth 中的所有測試通過且 lint 檢查乾淨」）被可驗證地滿足之前，持續工作，然後你就可以離開了。
- 工作樹 (Worktrees)：並行的隔離機制
Git 工作樹為每個 Agent 提供其自己的、位於獨立分支上的工作目錄，共享儲存庫歷史。編輯操作在物理上就不可能衝突。這解決了問題 4。
- Claude Code: git worktree、--worktree 標誌，或在子 Agent 上使用
isolation: worktree，讓每個輔助 Agent 獲得一個全新的、自動清理的檢出副本。 - Codex: 每個執行緒內建的工作樹。
據報導，高階用戶可以透過這種方式運行 10–15 個並行 Agent。
- 技能 (Skills)：編碼化的專案知識
一個技能是一個包含 SKILL.md 檔案的資料夾——你的慣例、建置步驟，以及「我們不這樣做是因為那次事件」的經驗教訓，一次寫好，Agent 每次運行都會讀取。這解決了問題 2。沒有技能，循環每次都會從零開始重新推導你的專案。有了它們，知識會不斷累積。
- 插件與連接器 (MCP)：操作真實工具的能力
一個只能看到檔案系統的循環是一個很小的循環。MCP 連接器讓它可以讀取你的問題追蹤器、查詢資料庫、開啟 PR、更新 Linear 工單，並在 CI 變綠時在 Slack 上發送通知。這就是一個說「這是修復方案」的 Agent 和一個實際部署修復方案的循環之間的區別。
- 子 Agent (Sub-agents)：將製造者與檢查者分離
這是整個模式中最重要的結構性概念。一個 Agent（或模型）負責撰寫；一個不同的、帶有不同指令的 Agent 負責驗證。這解決了問題 3。Claude Code 的 /goal 內建了這個功能：由一個獨立的模型來評判停止條件是否滿足，這樣工作 Agent 永遠不會給自己的作業打分。
- Claude Code: 在 .claude/agents/ 中的子 Agent、Agent 團隊。
- Codex: 在 .codex/agents/ 中以 TOML 格式定義的子 Agent——例如，一個高推理能力的高效能模型作為你的安全審查員，一個快速的唯讀模型作為你的探索者。
- 狀態 (State)：記憶主幹
一個 Markdown 檔案、一個進度日誌，或一個 Linear 專案——任何存在於對話之外並記錄已完成和待辦事項的東西。聽起來簡單到不值一提。但這是每個長時間運行的 Agent 都依賴的唯一技巧：模型在運行之間會忘記；但儲存庫不會。 這也在任務層面解決了問題 2，並讓明天的運行可以從今天停止的地方精確地繼續。結合自動化，它消除了問題 1——當你睡覺時，循環仍在工作。
一個真實的循環看起來像什麼
這是一個參考範例（改編自 Osmani 自己的日常循環）：
- 一個自動化任務在儲存庫上觸發。它的提示調用了一個分類技能，該技能讀取昨天的 CI 失敗、未解決的問題和最近的提交，並將發現寫入 STATE.md。
- 對於每個值得處理的發現，循環會開啟一個隔離的工作樹，並派遣一個製造者子 Agent 來起草修復方案。
- 一個檢查者子 Agent 根據專案技能和現有測試來審查草稿。
- 連接器會開啟 PR、連結工單，並在 Slack 上發布訊息。
- 任何循環無法處理的事情都會進入一個待處理收件匣——留給你。
- STATE.md 記錄了嘗試了什麼、通過了什麼、還有什麼未解決。明天的運行將從這裡繼續。
來源與延伸閱讀：Addy Osmani, "Loop Engineering" (addyosmani.com); The New Stack 關於循環工程的報導; Boris Cherny 在 Meta 的 Scale 會議上的爐邊談話及 CNBC 採訪; Claude Code 關於 Routines 的文檔 (code.claude.com/docs/en/routines); OpenAI Codex Automations 文檔。
如果你根據這篇文章構建了一個循環，我很想看看！請回覆告訴我你首先自動化了什麼。
