迴圈工程：如何建構能自我優化的 Agent

從手動提示到工程化迴圈

多數人仍在手動操作 AI 代理

他們輸入一個任務

等待一個回應

自己審查結果

自己修正錯誤

然後再發送另一個提示

人類仍然在擔任迴圈的角色

下一個階段看起來截然不同

你不再逐步提示代理

而是為它建立一個迴圈

迴圈會給出指令

檢查輸出

選擇下一步行動

並持續運行，直到結果達到標準

這就是迴圈工程

概念很簡單

停止花時間手動提示代理

開始設計能為你提示代理的系統

「你不再需要親自提示編碼代理了。你應該設計迴圈，讓迴圈來提示你的代理。」

Boris Cherny 在 Anthropic 領導 Claude Code 團隊

他透過自己的工作流程描述了同樣的轉變：

「我不再親自提示 Claude 了。我有迴圈在運行，它們會提示 Claude 並決定下一步該怎麼做。我的工作是編寫這些迴圈。」

為什麼多數人仍然不建立真正的迴圈

迴圈聽起來很棒，直到你看到 Token 帳單

一個普通的代理迴圈可能極快地消耗上下文：

• 一個中等規模的編碼迴圈可能使用 50K-200K Token
• 一個包含編排器和專業代理的艦隊可能使用 500K-2M Token
• 一個排程每天運行的迴圈每週可能消耗數百萬 Token

每次重試都要花費 Token

每次修正都要花費 Token

每次驗證步驟都要花費 Token

每個子代理都會增加一筆帳單

這就是人們很少討論的隱藏限制

迴圈工程之所以困難，並不是因為概念難以理解

而是因為大多數使用者負擔不起無限的代理運行

顯而易見的反應是：

「你說得倒輕鬆，你有無限的 OpenAI 存取權限。」

而這個批評是有道理的

這就是為什麼擁有大型上下文窗口的廉價模型如此重要

要每天運行有用的迴圈，你需要：

• 負擔得起的輸入 Token
• 負擔得起的輸出 Token
• 大型上下文窗口
• 可靠的工具呼叫
• 結構化的 JSON 輸出
• 高並發能力
• 足夠的上下文來記住先前的步驟

沒有這些，迴圈就只是昂貴的實驗

有了這些，迴圈就能成為處理實際工作的實用系統

舊工作流程 vs 新工作流程

在過去兩年裡，多數人使用代理的方式如下：

你提示

代理回應

你審查答案

你發現問題

你再次提示

這種方式可行，但無法擴展

舊工作流程：

• 你編寫提示
• 代理產生輸出
• 你檢查輸出
• 你修復薄弱環節
• 你手動重複流程

新工作流程：

• 你定義結果
• 迴圈發現需要什麼
• 迴圈建立計劃
• 代理執行工作
• 檢查器評估結果
• 迴圈修正失敗
• 系統在目標完成時停止

一個提示給代理一個單一指令

一個迴圈給代理一整個工作

迴圈工程實際上意味著什麼

迴圈工程意謂著圍繞 AI 代理建立可重複的反饋循環

目標很直接：

從初始嘗試到驗證結果

過程中不需要人類控制每一步

基本迴圈包含五個階段：

1. 發現
2. 計劃
3. 執行
4. 驗證
5. 迭代

如果結果通過檢查，就發布

如果結果失敗，就送回迴圈

這就是整個概念

你不是在嘗試編寫一個完美的提示

你是在建立一個系統

一個能不斷改進不完美輸出，直到它們達到要求的系統

單一代理迴圈

迴圈通常有兩種規模

較小的版本使用一個代理來完成整個循環

它發現需要做什麼

計劃工作

執行任務

審查結果

並在失敗時再次嘗試

這類似於一個人編輯自己的草稿，直到準備好為止

單一代理迴圈適用於：

• 聚焦的任務
• 有限的範圍
• 明確的目標
• 內容草稿
• 錯誤修復
• 研究摘要

一個代理

一個反饋循環

持續自我改進

艦隊迴圈

艦隊迴圈以更大的規模運作

一個編排器接收主要目標

它將目標分解為較小的部分

這些部分被分配給專業代理

每個專業代理也可以將更狹窄的任務委派給較小的子代理

範例：

1目標：建立一個生產力應用程式
2
3編排器擁有任務
4        ↓              ↓              ↓
5    研究             工程             品質保證
6    專業代理         專業代理         專業代理
7        ↓              ↓              ↓
8 網路研究員        程式碼編寫員      測試編寫員
9                   + 除錯員          + 錯誤追蹤員

這不再是一個代理單獨工作

它更像是一個小型自主團隊從頭到尾執行一個專案

開放式迴圈 vs 封閉式迴圈

這是最重要的實務差異

並非每個迴圈都以相同方式運作

開放式迴圈

開放式迴圈是探索性的

你提供一個廣泛的目標，並允許代理自行發現路徑

代理可能會發現你未曾指定但有用的東西

但它也可能變得昂貴且混亂

開放式迴圈可能：

• 探索太多方向
• 浪費大量 Token
• 快速產生低品質的工作
• 偏離實際目標
• 變得難以控制

開放式迴圈令人興奮

但它們通常不是最佳的起點

封閉式迴圈

封閉式迴圈有明確的界限

人類先定義路徑

迴圈仍然獨立運作，但保持在明確的規則之內

封閉式迴圈包含：

• 一個明確的目標
• 定義好的階段
• 每個階段後的評估
• 一個停止條件
• 當系統卡住時交給人類處理

這是在今天能創造價值的版本

它成本更低

更容易被信任

產生更乾淨的結果

從封閉式迴圈開始

只有在你的檢查機制足夠強大之後，才讓它們變得更開放

有效迴圈的 6 個建構模塊

每個迴圈在概念上都遵循相同的五階段循環

在實務上，六個建構模塊讓這個循環變得有用

1 自動化

自動化是迴圈的心跳

它啟動流程，無需你記住手動啟動

範例：

• 每天早上運行
• 每當有 PR 開啟時運行
• 檔案變更後運行
• 新 Ticket 出現時運行
• 持續直到所有測試通過

如果你仍然自己啟動每個動作，那麼迴圈做得還不夠

2 工作樹

當多個代理同時編輯程式碼時，工作樹變得重要

沒有隔離，代理就會衝突

兩個代理可能修改同一個檔案

一個代理可能覆蓋另一個代理的工作

工作樹讓每個代理擁有獨立的工作區和分支

這讓多個代理能夠並行工作

而不會把儲存庫搞得一團糟

3 技能

技能儲存關於專案的可重複使用知識

停止在每次運行中解釋相同的上下文

一次寫下重要資訊

讓每次未來的迴圈都能重複使用它

有用的技能檔案可以包含：

• 產品願景
• 架構
• 專案規則
• 建置說明
• 測試說明
• 代理絕對不能採取的動作

沒有技能，每個迴圈都從冷啟動開始

有了技能，每次運行都從先前工作累積的知識開始

4 插件與連接器

一個只能讀取本地檔案的迴圈價值有限

連接器讓它能夠與你實際工作使用的工具互動

範例：

• GitHub
• Slack
• Linear
• Jira
• Gmail
• Google Drive
• 資料庫
• 測試環境的 API

這就是以下兩者的區別：

「這裡有一個可能的修復方案」

以及：

「我已經開啟了 PR，並將其連接到 Ticket」

「然後我監控了 CI，並發布了最終更新」

5 子代理

製作方和檢查方不應該總是同一個代理

編寫程式碼的代理在審查時可能過於寬容

起草文章的代理可能會兩次忽略相同的薄弱環節

為以下任務使用不同的代理：

• 探索
• 實施
• 審查
• 測試
• 事實查核
• 最終摘要

當審查者獨立時，品質會提升

創作者不應該是唯一檢查工作的人

6 記憶

記憶讓迴圈能夠跨多次運行持續進行

模型會忘記

但儲存庫不會

筆記不會

專案日誌不會

記憶可以儲存在：

• Markdown 檔案
• 專案日誌
• Linear Ticket
• GitHub Issue
• Obsidian 筆記庫
• 資料庫
• Claude 專案

一個長期運行的迴圈必須記住已經嘗試過什麼

什麼有效

什麼失敗了

以及還有什麼需要完成

沒有持久記憶，迴圈每次都會從零開始

迴圈的實際範例

這些工作流程讓概念具體化

編碼迴圈

1讀取 VISIONmd + ARCHITECTUREmd
2↓
3計劃下一個變更
4↓
5編輯程式碼
6↓
7運行測試
8↓
9如果測試失敗 → 檢查錯誤 → 修復 → 再次測試
10↓
11如果測試通過 → 總結變更
12↓
13停止

人類不需要驅動每個階段

代理自行編寫、測試、修正和驗證自己的工作

研究迴圈

1定義研究問題
2↓
3尋找相關來源
4↓
5總結證據
6↓
7根據來源驗證每個主張
8↓
9比較衝突資訊
10↓
11建立最終綜合報告
12↓
13達到信心閾值時停止

這比要求一個快速摘要能產生更強大的結果

內容迴圈

1定義主題 + 受眾 + 目標
2↓
3建立初稿
4↓
5將其發送給評論代理
6↓
7根據評論改寫
8↓
9根據成功標準評分
10↓
11如果通過 → 發布
12↓
13如果失敗 → 再次改寫

這個迴圈將一個想法轉變為一個可重複的內容系統

銷售外展迴圈

1定義理想客戶檔案
2↓
3尋找符合檔案的潛在客戶
4↓
5用公司資料豐富每個潛在客戶資訊
6↓
7根據標準進行資格審查
8↓
9個性化訊息
10↓
11進行品質審查
12↓
13發送或升級給人類處理

每個範例都使用相同的骨架：

目標

行動

檢查

修正

重複直到工作完成

提示工程師 vs 迴圈工程師

這是 2026 年正在出現的新技能差距

提示工程師

提示工程師專注於更好的指令

他們改進措辭

他們產生更強大的單一回應

但在代理完成後，人類仍然必須審查所有內容

人類仍然是反饋迴圈

迴圈工程師

迴圈工程師則建立反饋系統本身

他們決定：

• 什麼啟動迴圈
• 代理接收什麼上下文
• 它可以存取哪些工具
• 什麼算是成功
• 誰來驗證結果
• 流程何時必須停止
• 最終輸出儲存在哪裡

提示工程師說：

「幫我寫一個函數」

迴圈工程師說：

「寫這個函數」

「測試它，並修復它，直到所有測試通過」

「然後總結這個變更」

工具可能完全相同

但心態完全不同

最具影響力的 AI 建構者正在超越更好的指令

他們正在建立能夠發現和計劃

執行和驗證

然後在正確時機停止的系統

重點摘要

迴圈工程是從手動提示到自動化反饋循環的轉變

轉變：

• 舊方式：一次給代理一個任務
• 新方式：建立一個管理完整循環的迴圈

你要建立的 6 個東西：

• 自動化：自動啟動迴圈
• 工作樹：讓代理並行工作而不產生檔案衝突
• 技能：在每次運行中重複使用專案知識
• 插件與連接器：讓迴圈存取實際工具
• 子代理：將製作者與審查者分開
• 記憶：在運行之間保留知識

2 種規模：

• 單一代理迴圈：一個代理反覆改進自己的工作
• 艦隊迴圈：一個編排器協調專業代理和子代理

2 種類型：

• 開放式迴圈：靈活、探索性強且昂貴
• 封閉式迴圈：範圍明確、可靠且負擔得起

5 個階段：

1. 發現
2. 計劃
3. 執行
4. 驗證
5. 迭代

真正的成本問題：

• 迴圈會快速消耗 Token
• 廉價的長上下文模型讓它們變得實用
• 沒有負擔得起的 Token，大多數使用者永遠無法超越實驗階段

心態轉變：

• 提示工程師向 AI 請求輸出
• 迴圈工程師建立能夠交付驗證結果的系統

這才是真正的關鍵

停止尋找一個完美的提示

建立一個能讓不完美輸出變得更好的迴圈

一個可靠的迴圈將勝過一個完美的提示

如果你讀到了這裡

追蹤 @elune0x 並將這篇文章加入書籤

當你準備好建立自己的迴圈時，再回來參考它