# 策展 · X (Twitter) 🔥🔥🔥

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

> 作者：Sydney Runkle (@sydneyrunkle) · 平台：X (Twitter) · 日期：2026-06-18

> 原始來源：https://x.com/sydneyrunkle/status/2066928783534289358

## 中文摘要

# 迴圈工程的藝術 (The Art of Loop Engineering)

Agent 之所以實用，是因為它們能透過在現實世界中採取行動，協助我們自動化工作。但要讓 Agent 可靠地完成有價值的工作，僅靠一個優秀的模型是不夠的：它需要一個針對特定任務集精心設計的 harness。

核心的 Agent 演算法很簡單：給予大型語言模型 (LLM) 內容，讓它在迴圈中呼叫工具，直到任務完成。這是最基礎的迴圈，但它絕非驅動 Agent 的唯一迴圈。@swyx 最近寫了一篇關於「loopcraft: the art of stacking loops」的精彩文章，提出了可以堆疊並擴展迴圈來建構更有效率的 Agent 的概念。

以下是我們對這種堆疊方式的思考，以及如何使用 LangChain 的基礎元件 (primitives) 來實作每一層。

## 迴圈 1：Agent

其核心在於，Agent 僅僅是一個在迴圈中呼叫工具直到任務完成的模型。

![這是一張展示 AI 代理（Agent）運作邏輯的流程圖，說明了從請求到模型與工具互動的循環過程。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/e04a2eaa9c25faed.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">圖片標題為「LOOP 1 — AGENT LOOP」。流程圖內容如下：
1. 起始點為「request」。
2. 箭頭指向「model」。
3. 「model」與「tools」之間存在雙向互動：
   - 「model」發送「action」給「tools」。
   - 「tools」回傳「observation」給「model」。
   - 此互動過程標註為「repeat until done」。
4. 「model」最終輸出「result」。</div></details>

這就是 LangChain 的 `create_agent` 所提供的功能。選擇任何模型，插入工具，你就擁有了一個運作中的 Agent 迴圈。工具賦予了 Agent 在現實世界中採取行動的能力。

以我們的內部文件 Agent 為例（我們將在本文後續部分以此作為範例）。在第一層迴圈中，它接收文件改進的請求，模型會進行規劃並草擬變更，接著使用工具來複製程式庫、讀取檔案、編寫文件、發起 Pull Request 等。

![這是一張展示「文件撰寫代理迴圈」（Docs Writer Agent Loop）運作流程的架構圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/2bc87727089c8704.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表描述了一個自動化文件改進流程，包含以下節點與文字：
1. 標題：DOCS WRITER AGENT LOOP
2. 起始節點：docs improvement request（文件改進請求）
3. 核心處理迴圈：
   - model（模型）：負責 plan + draft changes（規劃與草擬變更）。
   - sandbox tools（沙盒工具）：負責 clone · read · write（複製、讀取、寫入）。
   - 兩者之間透過 action（動作）與 observation（觀察）進行互動。
4. 結束節點：pull request（合併請求），包含 diff + description（差異比對與描述）。
5. 流程說明：標註有「repeat until done」（重複直到完成）。</div></details>

## 第 2 層：驗證迴圈 (Verification loop)

Agent 迴圈可以完成工作，但並非每次都能在第一次嘗試時就產出正確或一致的成果。當一致性很重要時，將其包裝在一個驗證迴圈中通常很有用，該迴圈會檢查輸出，並在結果不達標時將回饋傳回給模型。

![這是一張名為「驗證迴圈」（Verification Loop）的流程圖，展示了 AI 代理在執行任務時，透過評分機制進行反饋與修正的運作邏輯。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/d6bc10350d3f2022.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表呈現了「LOOP 2 — VERIFICATION LOOP」的架構，包含以下區塊與流程：
1. 最上方為「request」（請求）輸入點。
2. 中間虛線框內為「agent loop」（代理迴圈），包含「model」（模型）與「tools」（工具）之間的交互作用，模型發出「action」（動作）並接收「observation」（觀察結果）。
3. 模型產出「result」（結果）後，會進入下方的「grader」（評分器），該區塊標註「rubric / eval」（準則／評估）。
4. 若評分未通過，會透過「retry with feedback」（帶有反饋的重試）路徑將結果回傳至「model」進行修正。
5. 若評分通過（pass），則流程結束進入「done」（完成）狀態。</div></details>

驗證迴圈增加了一個評分器 (grader)：它會根據評分標準檢查 Agent 的輸出，如果檢查失敗，則將結果連同回饋傳回。評分器可以是確定性的，也可以是 Agentic 的（此處「以 LLM 作為裁判」就是一個經典例子）。

`RubricMiddleware` 可以處理這種模式，或者你也可以透過 `create_agent` 的 `after_agent` 掛鉤 (hook) 來連接它。

以我們的文件編寫 Agent 為例，評分器會在每次嘗試後執行測試，檢查所有連結是否有效、所有 CI 檢查是否通過，以及差異 (diff) 是否僅限於實際請求的範圍。無需人工審核即可捕捉這些類型的錯誤。

![這是一張展示文件編寫驗證迴圈（Docs Writer Verification Loop）的流程圖，說明了從改進請求到自動化評分與修正的運作機制。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/372ac10a4ce65638.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表描述了「DOCS WRITER VERIFICATION LOOP」的運作流程，包含以下節點與路徑：
1. 起始點：docs improvement request（文件改進請求）。
2. agent loop（代理迴圈）：
   - model：負責 plan + draft changes（規劃與草擬變更）。
   - sandbox tools：負責 clone、read、write（複製、讀取、寫入）。
   - 兩者之間透過 action（動作）與 observation（觀察）進行互動。
   - 產出 pull request（包含 diff 與 description）。
3. grader（評分器）：負責 links resolve（連結解析）與 CI passes（持續整合通過）。
   - 若評分未通過，則執行 retry with feedback（帶有回饋的重試），將流程導回 model。
   - 若評分通過（pass），則進入 done（完成）狀態。</div></details>

一個權衡是：增加驗證會增加延遲和每次執行的成本。當品質比速度更重要時（這適用於大多數生產環境的使用案例），這是值得的。

## 第 3 層：事件驅動迴圈 (Event driven loop)

Agent 開發中最重要的部分之一是整合層：將你的 Agent 連接到你的生態系統，以便它能在背景執行。

事件驅動迴圈將你的 Agent 連接到你的生態系統。當事件觸發時——例如新文件落地、排程觸發、Webhook 到達——Agent 就會執行。Agent 不是你需要手動呼叫的東西；它是運行在更大系統內部的持續性元件。

![這是一張展示「LOOP 3 — EVENT LOOP」架構的流程圖，說明了從事件觸發、代理執行、評估驗證到系統更新的循環機制。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/43b189ea23512c48.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表描述了一個包含多層循環的系統架構：
1. 最外層為「LOOP 3 — EVENT LOOP」，由「event trigger」啟動。
2. 內部包含「verification loop」（驗證循環）與「agent loop」（代理循環）。
3. 「agent loop」包含「model」與「tools」，兩者之間透過「action」與「observation」進行互動。
4. 「model」產出「result」，隨後進入「grader」（包含 rubric / eval）進行評估。
5. 若評估未通過，會透過「retry with feedback」路徑回到「agent loop」重新執行。
6. 評估完成後進入「system update」（service improves），並透過「new events」回饋至「event trigger」形成循環。</div></details>

LangSmith Deployment 支援觸發基礎設施，包括對 cron 排程和 Webhook 的支援。在 openclaw 中，cron 的一個熱門應用是「心跳機制 (heartbeats)」，它能將你的 Agent 變成一個全天候運作、主動式的助理。

我們的文件 Agent 是由 Fleet（我們的無程式碼 Agent 建構器）所驅動。Fleet 的頻道 (channels) 和排程處理了事件驅動和 cron 風格的觸發器。我們使用一個頻道，每當我們的 `#docs-plz` Slack 頻道中有訊息發送時，就會啟動文件 Agent。

![這是一張名為「DOCS WRITER EVENT LOOP」的架構流程圖，展示了從接收訊息到文件更新的自動化處理循環。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/6b5698e733a1d7ec.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表描述了一個名為「DOCS WRITER EVENT LOOP」的自動化工作流程，包含以下節點與邏輯：
1. 起始點：接收來自「Slack message #docs-plz」的請求。
2. 核心處理區（agent loop）：
   - 「model」負責「plan + draft changes」。
   - 「sandbox tools」執行「clone · read · write」操作，並與 model 進行「action」與「observation」的互動。
   - 處理結果產生「pull request」，包含「diff + description」。
3. 驗證區（verification loop）：
   - 「grader」負責檢查「links resolve · CI passes」。
   - 若驗證失敗，會觸發「retry with feedback」回到 model 重新處理。
4. 最終階段：
   - 通過驗證後進入「docs enhancement」，達成「merged · live · discoverable」狀態。
   - 流程最後會回到起始點，準備處理「new request」。</div></details>

## 第 4 層：爬坡迴圈 (Hill climbing loop)

前三個迴圈實現了工作自動化。第四個（也是可以說最重要的）迴圈則是實現了「改進」的自動化！

![這是一張描述「爬山演算法迴圈」（Hill Climbing Loop）的系統架構流程圖，展示了 AI 代理在執行任務時的自我優化與驗證機制。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/2087db6269941216.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表呈現了一個名為「LOOP 4 - HILL CLIMBING LOOP」的系統架構，包含多層次的迴圈結構：

1. **核心流程（由上至下）：**
   - **event trigger**：觸發事件。
   - **agent loop**（代理迴圈）：包含 **model**（模型）與 **tools**（工具），兩者之間有 **action**（動作）與 **observation**（觀察）的雙向互動。模型產生 **result**（結果）。
   - **verification loop**（驗證迴圈）：結果會進入 **grader**（評分器，包含 rubric / eval），若未達標則透過 **retry with feedback** 回饋給模型重新執行。
   - **event loop**（事件迴圈）：通過驗證的結果進入 **system update**（系統更新，service improves），並產生 **traces**（軌跡）。

2. **外部分析與優化：**
   - **engine analysis**（引擎分析，agent over traces）：對系統產生的軌跡進行分析。
   - **harness improvements**：分析結果會回饋至「agent loop」以進行系統改進。
   - **new events**：分析結果亦會回饋至最上層的「event trigger」以觸發新的事件。</div></details>

每次 Agent 的執行都會產生一個追蹤紀錄 (trace)：記錄模型做了什麼、呼叫了哪些工具、評分器的回饋等。這些追蹤紀錄包含了關於哪些有效、哪些無效的高價值訊號。爬坡迴圈會在這些追蹤紀錄上執行一個分析 Agent，並利用分析結果透過改進的配置來重寫 harness。這可能包括提示詞 (prompt)/工具的微調，或是評分器的調整。

在 LangSmith 中，你可以使用 Engine（我們的追蹤分析 Agent）來實作這第四個迴圈。

回到文件 Agent 的類比，我們在文件 Agent 的追蹤紀錄上執行 Engine 以偵測任何問題。當多個追蹤紀錄顯示出潛在問題時，系統會歸檔一個問題，要求對有問題的提示詞或工具進行變更。

![這是一張展示「文件編寫爬坡迴圈」（Docs Writer Hill Climbing Loop）自動化流程的系統架構圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/0fefbe21e9225963.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表描述了一個自動化文件編寫的運作迴圈，包含以下層級與組件：
1. 頂層入口：Slack message (#docs-plz)。
2. 核心迴圈結構：
   - event loop（事件迴圈）
   - verification loop（驗證迴圈）
   - agent loop（代理迴圈）：包含 model（執行 plan + draft changes）與 sandbox tools（執行 clone、read、write，並與 model 進行 action/observation 互動）。
3. 流程步驟：
   - model 產出 pull request (diff + description)。
   - 進入 grader（執行 links resolve 與 CI passes）。
   - 最終產出 docs enhancement（達到 merged、live、discoverable 狀態）。
4. 系統優化機制：
   - 透過 engine analysis（分析 traces，偵測問題並調整 prompt 或 tool）將改進回饋至 agent loop。
   - 失敗時透過「retry with feedback」機制回到 agent loop。
   - 成功後透過「new request」回到起始的 Slack message。</div></details>

這裡的關鍵動作在於，返回箭頭不僅僅是迴圈回到頂部——它會深入內部並直接更新 Agent 迴圈。外層迴圈的每一個週期都會使內層迴圈更有效率。

> 展望未來：提示詞和工具配置是最容易改進的部分，但它們並非唯一的選擇。對於使用開放權重模型的團隊來說，爬坡迴圈可以回饋到 RL 微調 (RL fine-tuning)，利用追蹤紀錄或評估結果作為訓練訊號來改進模型本身。像記憶 (memory) 和已檢索的 skill 等輔助內容也可以透過同樣的方式改進。迴圈是一種模式；至於它優化什麼，則由你決定。

## 人工監督與專業知識

自動化並不意味著將人類從迴圈中移除。在每一個層級，都有人類監督能發揮價值的自然切入點。自動化評分器可以檢查連結是否有效；但需要人類才能察覺到語氣是否不適合目標受眾。那種從內容、經驗和品味中獲得的判斷力，正是人工審核發揮作用的地方。

有些專業知識應該編碼在提示詞/工具本身中，但對於敏感的操作，即時的人工審核是必不可少的（例如金融交易、資料庫操作等）。LangChain 讓在每個迴圈中實作這些接觸點變得簡單直接：

1. 在 Agent 迴圈中，在敏感操作/工具呼叫前要求人工輸入。

2. 在驗證迴圈中，人類可以擔任敏感工作流程的評分器。

3. 在應用程式迴圈中，人類可以在輸出返回給終端使用者前進行核准。

4. 在爬坡迴圈中，harness 的改進可以在部署前經過人工審核。

所有 LangChain 的開源框架都將加入「人在迴圈 (human in the loop)」視為一項核心基礎功能。

## 總結

如果你更喜歡表格形式，以下是這四個迴圈如何堆疊在一起：

| 迴圈 | 功能 | 影響 | LangChain 基礎元件 |
| --- | --- | --- | --- |
| **1: Agent 迴圈** *(模型 + 工具)* | 模型重複呼叫工具直到任務完成 | 工作自動化 | `create_agent`，任何 LangChain 支援的模型 |
| **2: 驗證迴圈** *(Agent + 評分器)* | Agent 執行，輸出根據評分標準評分，若失敗則帶回饋重試 | 確保品質 | `RubricMiddleware` |
| **3: 事件迴圈** *(驗證 + 系統)* | 事件觸發 Agent 執行並更新實際系統 | 大規模運作 | LangSmith Deployment / Fleet 頻道 |
| **4: 爬坡迴圈** *(系統 + Engine)* | 生產環境追蹤紀錄回饋給分析 Agent，進而改進 harness 配置 | 持續改進 | LangSmith Engine |

這就是迴圈工程——或者如 @swyx 所說的 loopcraft——在實踐中真正的樣子。像 Steipete、Boris 和 Andrej 這樣的 AI 領袖都得出了相同的結論：Agent 的潛力在於你圍繞它們所建構的迴圈。

我們思考迴圈 1 和 2 已經有一段時間了。但焦點應該轉向迴圈 3 和 4，透過將 Agent 嵌入你的生態系統，並根據你的標準持續改進，價值將會產生複利效應。

Satya 點出了組織面臨的賭注：那些儘早建立學習迴圈、讓人類判斷與 token 資本共同產生複利的企業，將建立起難以被複製的優勢。

## 致謝

感謝 @Vtrivedy10、@masondrxy、@hwchase17 和 @huntlovell 的深思熟慮的審閱。

## 參考資料

- deepagents 快速入門

- create_agent 文件

- rubric middleware

- cron jobs, webhooks

- langsmith engine

- fleet 頻道

## 標籤

Agent, Loop Engineering, 教學資源, swyx
