你還在手寫 Prompt？聰明的人早就用上了循環工程，AI 的自動駕駛時代來了

一條推文引發的討論

2026 年 6 月初，OpenClaw 創始人 Peter Steinberger 在社交平臺上寫了一句話，大意是：別再手動給 AI 編碼代理寫提示詞了，應該去設計一個能替你寫提示詞的系統。幾天之內，Claude Code 的負責人 Boris Cherny 在公開場合跟上，他現在的日常工作就是寫循環（Loop），讓循環去調度 Claude，自己不再逐條下達指令。Google Cloud 工程總監 Addy Osmani 隨后給這套做法做了系統性的拆解，并賦予它一個正式的名字：Loop Engineering，即循環工程。

三個人，三家公司，同一周，同一個結論。這當然不是巧合，而是標志著 AI 編程工具在2026年新階段的到來。

什么是循環工程

循環工程是一種面向 AI Agent 的工作流設計方法。它的目標搭建一個完整的執行系統，這個系統能夠自動發現任務、分配給 AI 代理去執行、檢查產出質量、記錄進度，并決定下一步是繼續、重試還是停止。整個過程可以在無人值守的狀態下持續運轉，直到滿足預設的退出條件，我愿稱之為 AI 界的永動機。

打個比方，如果提示詞工程（Prompt Engineering）是在棋盤上走好每一步棋，那循環工程就是在設計下棋的規則和裁判機制，讓 AI 按照規則自己完成一整盤棋。

盡管 Loop Engineering 目前主要應用在軟件開發領域，但它的底層邏輯并不局限于寫代碼。任何需要反復執行、反復判斷的流程，從運維巡檢、內容生產、客服分流、到數據清洗，都可以用同樣的思路來構建。只不過編程領域的工具鏈最先成熟，實踐和討論也最密集。

從提示詞工程到循環工程，經歷了什么

回顧 AI 輔助編程的發展路徑，可以看到三個階段，每個階段解決的問題不同，工程師扮演的角色也在變化。

第一階段：提示詞工程（Prompt Engineering）

這是最早被廣泛討論的 AI 協作方式。工程師通過精心設計提示詞，設定角色、給出示例、加入鏈式思考引導，來讓模型產出更準確的結果。但是這個方式的缺點是措辭方式會顯著影響模型輸出。

因為它有一個結構性的問題，提示詞是手工制品，高度依賴特定模型版本和上下文長度。模型一更新，或者輸入稍有變化，之前調好的提示詞就可能悄悄失效。很多團隊甚至為提示詞寫了回歸測試，像測試函數一樣測試措辭，然后看著它們在每次模型升級后批量過期。這種現象被稱為 Prompt Drift（提示詞漂移），這可不是偶發情況，而是把確定性期望綁定在概率系統上的必然結果。

第二階段：上下文工程（Context Engineering）

業界很快意識到，與其在措辭上反復打磨，不如把精力放在模型的輸入數據上。RAG 管線、向量數據庫、嵌入策略陸續出現，上下文窗口也從幾千 Token 擴展到百萬級別。工程師的工作重心也從「怎么說」變成了「讓模型看到什么」。

上下文工程解決了信息供給問題，但也不是完美的，一個被充分喂養了上下文的模型，如果第一次就答錯了，它不會自己發現，也不會主動驗證。整個管線里沒有任何機制推動它做二次檢查。

第三階段：循環工程（Loop Engineering）

循環工程補上的正是這個缺點。它不再試圖優化單次輸入，而是圍繞模型搭建一個閉環系統：模型執行操作 → 確定性工具（編譯器、測試框架、Lint 工具）評估結果 → 評估反饋回傳給模型 → 模型修正后再次執行 → 如此反復，直到通過所有預設的驗證門禁。

工程師的角色也隨之改變。不再是每一輪對話的參與者，而是這個閉環系統的設計者。他們要定義什么算完成、用什么來驗證、失敗后怎么處理、何時需要人工介入。

三個階段之間并非替代關系。好的提示詞和充足的上下文依然有用，但它們已經從主要工程挑戰變成了循環內部的子模塊。真正決定產出質量的，是循環本身的設計。

一個可用的循環需要哪些組件

根據 Addy Osmani 的拆解，一個能投入實際使用的循環需要五個結構性組件，加上一個貫穿始終的記憶層。

1. 自動化觸發（Automations）

自動化觸發是讓一個循環區別于一次性腳本的關鍵。它可以是定時任務（比如每 30 分鐘掃描一次依賴漏洞）、事件鉤子（比如PR 被合并后自動啟動檢查）或者持續監聽（每小時檢查一次 Bug 反饋區）。

在 Claude Code 中，可以通過/loop設置定時巡檢，也可以通過 GitHub Actions 實現在關閉終端后繼續運行。Codex 則提供了一個 Automations 面板，可以直接配置項目、提示詞、執行頻率和運行環境，結果自動歸集到分類收件箱中。

沒有觸發機制的循環不是循環，只是一個需要手動啟動的腳本。

2. 工作樹隔離（Worktrees）

當多個 AI 代理同時處理同一個代碼倉庫時，文件沖突是第一個會爆發的問題。Git Worktree 為每個代理提供獨立的工作目錄和獨立的分支，共享同一份倉庫歷史，但彼此的修改互不干擾，原理就和兩個工程師各自在獨立分支上開發完全一致。

Codex 內置了 Worktree 支持，每個線程自動分配隔離環境。Claude Code 則通過--worktree標志或在子代理配置中設置isolation: worktree來實現同樣的效果。

3. 技能文件（Skills）

如果不把項目的約定、構建流程、已知陷阱寫下來，AI 代理每次啟動都會從零開始推導整個項目，然后用自信的猜測填補所有認知空白。這種現象被稱為意圖債務（Intent Debt），比如AI是不知道「這個倉庫不能用 npm」或者「這個測試必須等服務完全啟動后才能跑」，除非有人明確告訴它。

Skills 就是來解決這個問題的。SKILL.md寫著指令和元數據，可選地附帶腳本、示例和參考資料。Claude Code 和 Codex 都支持這個格式，代理在啟動時會自動加載匹配之 Skill，省去了每次重新解釋項目背景的成本。

寫一次，每次循環都能復用。項目經驗不再隨著對話窗口關閉而消失，AI自己就能把踩坑記錄沉淀進系統。

4. 插件與連接器（Plugins & Connectors）

一個只能讀寫本地文件的代理，活動半徑非常有限。通過 MCP（Model Context Protocol）協議，代理可以接入外部系統，讀取工單、查詢數據庫、調用 CI 管線、向 Slack 頻道發送通知。

MCP 已經成為 AI 代理與外部工具通信的行業標準，由 Linux 基金會統一治理，截至 2026 年 3 月，其 SDK 每月被下載超過 9700 萬次，公開的 MCP 服務器數量已突破 1 萬。

在本地開發場景中，MCP 的價值體現得尤為直接。以 ServBay 為例，它內置了 MCP Server，開放了 39 個工具接口，涵蓋服務啟停、建站配域名和 SSL、端口查詢、日志讀取、數據庫創建與查詢、各種開發語言的版本切換等操作。接入之后，Claude Code、Cursor、Codex 這類編碼代理可以直接調用本地開發環境中的服務，而不需要工程師手動配置或者反復解釋環境狀態。AI Agent說出「幫我建一個帶 MySQL 和 HTTPS 的站點」，ServBay 的 MCP Server 就能在幾十秒內把數據庫、域名、證書全部配好。

這就是「AI 告訴你應該怎么配置」和「AI 直接幫你配好」之間的差距。連接器讓循環的執行范圍從本地文件系統擴展到了真實的工程環境。

5. 子代理（Sub-agents）

循環中最有價值的架構決策，是把生成工作的代理和檢查工作的AI分開。

寫代碼的模型在評判自己寫的代碼時，都挺自戀的，它們傾向于給出過于寬容的評價。它會說服自己那個邊界條件處理得沒問題，那個異常捕獲已經夠了。一個獨立的驗證代理，在用不同的指令集，甚至不同的模型之后，能抓住第一個代理在自我合理化后忽略掉的問題。

在 Claude Code 中，/goal命令的底層機制就是這個思路，執行任務的AI Agent和判定是否完成的AI Agent是分開的，后者用一個獨立的小模型來評估停止條件。Codex 則允許在.codex/agents/目錄下用 TOML 文件定義多個代理，每個代理可以指定不同的模型和推理強度。

子代理會消耗額外的 Token，但在無人值守的循環中，一個獨立的驗證者是工程師敢于離開屏幕的前提。

6. 狀態持久化（State）

AI 代理在對話結束后會遺忘一切。但循環不能遺忘。它需要知道上一輪做了什么、哪些任務已完成、哪些還在排隊、哪些嘗試過但失敗了。

狀態可以是一個 Markdown 文件、一個 Linear 看板、一條 GitHub Issue 的評論區，任何存在于對話窗口之外的持久化存儲都可以。狀態層是整個循環的骨架，沒有它，每次運行都是一次全新的、毫無上下文的冷啟動。

一個完整循環的實際運作方式

以一個真實場景為例，老王團隊的代碼倉庫每天都有新的 CI 失敗、新的 Issue 和新的提交。如果用循環工程的思路來處理，整個流程大致如下。

一個定時自動化任務在每天早上啟動，調用一個分類 Skill，讀取昨天的 CI 失敗日志、未處理的 Issue 和最近的提交記錄，把需要處理的事項寫入一個狀態文件。

對于每一個需要處理的事項，系統在隔離的 Worktree 中啟動一個子代理來起草修復方案，同時啟動另一個子代理對修復方案進行獨立審查，對照項目 Skill 中記錄的編碼規范和現有測試用例。

審查通過后，連接器自動創建 PR、關聯對應的 Issue，等 CI 跑綠后在 Slack 頻道發送通知。審查未通過的修復方案會被退回重試，超過最大重試次數的任務則升級到人工處理隊列。

狀態文件在每一步都會更新，記錄哪些修復已合并、哪些正在重試、哪些等待人工介入。第二天早上，新一輪循環啟動時，會從狀態文件中讀取上一輪的進度，接著往下走。

這個流程只需要設計一次。之后每天的執行不需要任何人手動輸入提示詞。

循環跑起來了，問題也出現了

大多數關于循環工程的討論，到架構設計這一步就結束了。但在真正落地的時候，Token 消耗才是決定一個循環能不能上生產環境的硬門檻。

每一輪迭代都在消耗 Token，而一個沒有迭代上限的循環，就像一輛沒有油量表的車。根據 FinOps Foundation 2026 年的調查數據（覆蓋 1192 家企業，代表超過 830 億美元的年度技術支出），98% 的企業已經在主動管理 AI 相關成本，兩年前這個比例只有 31%。漲得這么快，說明不少團隊是被賬單教訓過之后才開始重視的。

據傳說，某個團隊配置了一個夜間無人值守的循環，讓 AI 代理自動修復失敗的測試用例。代理遇到了一個 Flaky Test（不穩定測試），這種測試本身就是間歇性失敗的，并不存在真正的代碼缺陷。但 AI 判斷不了這個情況，它連續嘗試了十幾種修復方案，每一輪都把完整的測試輸出和 diff 歷史重新讀了一遍。第二天早上，構建確實綠了，提交看起來也合理，但 Token 也是噌噌地漲，一個工程師花五分鐘掃一眼就能判斷出來的問題，AI 卻判斷不了。

問題其實不出在循環工程上，而在于這個循環上線時就缺了預算上限、最大迭代次數和人工升級通道，就像一條 CI 管線如果沒有超時設置，遲早會出事。

三個被驗證有效的成本控制策略：

提示緩存（Prompt Caching）：把系統提示詞、工具定義、不變的代碼庫上下文設計為可緩存的部分，讓它們在每輪迭代中命中緩存，而不是作為新輸入重新計費。

動態模型路由（Dynamic Model Routing）：確定性高、判斷復雜度低的任務（Lint 檢查、格式校驗、簡單工具調用）交給小型低價模型，只在需要復雜推理的決策節點才調用前沿模型。不同模型之間的價格差距可以達到千倍量級。

狀態壓縮（State Compaction）：對循環的運行歷史做摘要和壓縮，而不是讓模型每一輪都重新消化完整的原始日志。每輪迭代的 Token 消耗應該保持平穩或遞減，而不是隨著迭代次數線性增長。

本地 AI Gateway 在成本控制中的作用

動態模型路由說起來簡單，實際操作的時候就會有不小的麻煩，每個模型提供商都有自己的 API 格式和密鑰體系。手動管理多套密鑰，不僅容易泄露，而且在不同模型之間切換時還需要改代碼或改配置。

這正是 AI Gateway 這一類工具要解決的問題。ServBay 的 AI Gateway 在本地提供了一個統一的代理端點，把 Anthropic、OpenAI、Google、以及本地 Ollama 模型的請求全部收歸到一個入口。所有真實的 API 密鑰加密存儲在本地機器上，不會上傳到任何云端服務器。開發者可以按項目簽發可獨立撤銷的虛擬密鑰，用量和花費在一個儀表盤上一目了然。

對于循環工程的落地來說，這類 Gateway 能讓「把 Lint 檢查路由給低價模型、把架構決策路由給前沿模型」這件事變得可操作，在一個入口上切換模型，不用動工具側的任何配置。配合 ServBay 內置的 MCP Server，代理可以一邊通過 Gateway 按需調用不同的模型，一邊通過 MCP 操作本地開發環境中的數據庫、Web 服務器和域名配置。兩個能力疊加之后，一個循環就具備了從「讀取任務 → 調用合適模型 → 操作真實環境 → 驗證結果」的完整閉環能力。

四種循環模式，自動化程度逐級遞增

ClaudeDevs 官方歸納了四種 循環模式，適用于不同的場景和信任程度。

• 回合制循環（Turn-based）：最基礎的形式。每次給代理一條指令，代理執行后按照 Skill 中預定義的驗收清單自查，啟動本地服務、在瀏覽器中實際操作、檢查控制臺是否有報錯、運行性能測試。所有檢查項通過后才提交結果。
• 目標制循環（Goal-based）：適用于多輪迭代才能完成的復雜任務。通過/goal命令設定一個可量化的目標（比如 Lighthouse 評分達到 90 分），加上最大重試次數。代理在后臺反復嘗試、測試、修改，直到達標或觸及上限。模糊的審美判斷被轉換成了確定性的數字指標。
• 定時制循環（Time-based）：適用于重復性日常事務。通過/loop設定巡檢間隔，比如每 5 分鐘檢查一次 PR 狀態、回復代碼審查意見、修復 CI 失敗。那些高頻但低創造性的工作被轉化為后臺守護進程。
• 主動循環（Proactive）：自動化程度最高的形態，結合事件驅動和多代理協作。系統監聽到新事件后自動啟動處理流程，可以同時在多個隔離工作區中生成多套方案，再由獨立的審查代理擇優合并。

雖然循環工程目前的工具鏈主要監控開發領域，但它的設計思路可以遷移到任何包含重復性判斷的工作流中。

內容團隊可以搭建一個每天定時掃描行業信息源、篩選選題線索、生成初稿摘要的循環。運維團隊可以讓循環持續監控告警、自動執行預案、在無法自動處理時升級到人工。客服團隊可以用循環做工單分類和初步回復，把需要深度溝通的對話路由給真人。

這些場景的共同特征是：有明確的輸入源、可定義的處理規則、可驗證的完成標準。滿足這三個條件的流程，都適合用循環工程的方式來組織。

循環跑得越快，人的角色越不能缺席

循環工程改變了工作方式，但并沒有把人從流程中移除。恰恰相反，隨著循環的自動化程度提高，有三件事反而變得更加突出。

• 驗證責任沒有轉移。無人值守的循環同時也是無人值守的犯錯。即便拆分了生成代理和驗證代理，完成仍然是一個斷言而不是一個證明。最終為代碼質量負責的還是工程師本人。
• 認知差距會加速拉大。循環產出代碼的速度越快，工程師對代碼庫的理解就越容易脫節。不主動閱讀循環生成的代碼，工程師和自己維護的系統之間會形成越來越大的認知債務（Comprehension Debt）。
• 舒適狀態是危險狀態。當循環自己就能跑出結果時，人很容易滑入一種不再形成自己判斷的模式——全盤接受循環的產出。同樣是使用循環，理解業務的人用它來加速已經想清楚的工作，不理解業務的人用它來回避思考。循環本身不區分這兩種用法，但產出質量會如實反映。

Boris Cherny 的表達并不是說工作變輕松了，而是說關注點不一樣了。設計循環比寫提示詞更難，因為它要求工程師對「完成」這件事有精確的定義能力，對失敗模式有預判，對成本有約束意識，對何時拉人介入有清醒的判斷。

循環工程仍然處于早期階段，工具在快速迭代，最佳實踐還在成形的過程中。但它指向的方向已經比較明確：AI 輔助編程正在從人驅動每一輪對話走向人設計系統、系統驅動對話。

想要嘗試循環工程的同學，可以可以從一個小的回合制循環開始，給現有的 Claude Code 或 Codex 工作流加上一個 Skill 文件和一份驗收清單，體驗一下循環帶來的效率變化。等對機制有了信心，再逐步引入目標制循環和子代理驗證。

搭好循環，但別忘了自己為什么要坐在這里。工具在變，工程師的判斷力不會過期。