# 策展 · X (Twitter) 🔥🔥🔥🔥
> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)
> 作者：Samuel McDonnell (@samueljmcd) · 平台：X (Twitter) · 日期：2026-06-16
> 原始來源：https://x.com/samueljmcd/status/2066524627585634765
## 中文摘要
# 我對 Loop Engineering 的看法
Loop engineering（迴圈工程）是現在的新名詞。但困難的部分一直沒變，那就是：驗證（Verification）。
小撇步：如果你不想讀完這篇文章，可以直接複製貼上到 Claude，請它幫你整理出最精華的觀點！！
現在業界流傳著一句話。Claude Code 的創作者兼負責人 Boris Cherny 在六月的 Fortune Brainstorm Tech 會議上提到，他現在已經不再親自撰寫 Prompt 了。他的說法是，現在是另一個 Claude 在負責下 Prompt。在某個早晨，他同時管理著數百甚至數千個 Agent。
圍繞著這個現象發展出來的框架就是「Loop engineering」。這個概念的推銷方式分為三個階段：2024 年是寫出好的 Prompt；2025 年是並行執行 Agent；2026 年則是打造出能為你執行 Agent 的迴圈。你不再需要親自輸入 Prompt，而是開始設計一套能自動輸入 Prompt 的系統。
這個框架在一定程度上是沒問題的，但它也掩蓋了決定你的迴圈能否真正產出成果的關鍵。一個迴圈本質上就是一個連接到驗證器的生成器。生成器從來都不是瓶頸，驗證器才是。
展開畫面重點
圖片標題為「FIG. 1 A loop is a generator wired to a verifier」（圖 1：一個由生成器連接至驗證器的循環）。
圖中包含兩個主要組件：
1. 左側為「GENERATOR」（生成器），下方註記「writes the work」（負責撰寫工作）。
2. 右側為「VERIFIER」（驗證器），下方註記「the gate」（作為閘門），並標有勾選符號。
流程說明如下：
- 生成器輸出內容至驗證器。
- 若通過驗證（pass），則進入「PASS -> SHIP」（通過並發布）階段。
- 若未通過驗證（fail），則產生「feedback」（回饋）並進行「next iteration」（下一次迭代），虛線箭頭將回饋導回生成器以進行修正。
展開畫面重點
圖片標題為「FIG. 2 Same loop, two scales」，分為左右兩個部分：
左側為「SINGLE AGENT」（單一代理）：
- 流程包含三個步驟：draft（草稿）、check（檢查，標註有勾號）、fix（修正）。
- 箭頭指示從 draft 到 check，再到 fix，並有一條虛線箭頭從 fix 指回 draft，標註為「repeat」（重複）。
- 下方文字說明：「rewrites its own draft」（重寫其自身的草稿）。
右側為「FLEET」（代理群體）：
- 頂層為「ORCHESTRATOR」（協調者）。
- 中間層為「specialist A」與「specialist B」。
- 底層為四個「sub」（子任務，均標註有勾號），分別對應 specialist A 與 specialist B。
- 虛線箭頭從底層的「verified results」（驗證結果）指向 ORCHESTRATOR。
- 下方文字說明：「a team running the project end to end」（一個從頭到尾執行專案的團隊）。
展開畫面重點
圖片標題為「FIG. 3 Open vs closed」。
左側為「OPEN · EXPLORE」流程：
- 起點為「goal」。
- 透過發散的虛線指向四個不同的圓形節點，其中最上方標註為「novel」，下方兩個標註為「slop」。
- 下方文字說明：「no gate · expensive · drifts」。
右側為「CLOSED · EXECUTE」流程：
- 起點為「goal」。
- 依序向下連結至「step 1」與「step 2」，每個步驟旁皆有對應的「eval ✓」評估框。
- 最後連結至「stop · ship」節點。
- 下方文字說明：「bounded · gated · ships」。
此圖表對比了兩種模式：開放式探索流程缺乏門檻、成本較高且容易偏離目標；封閉式執行流程則有明確邊界、設有評估關卡，且能確保產出。
展開畫面重點
圖表標題為「FIG. 5 ReAct → Reflexion」。
左側為「ReAct · reason + act」流程：
- thought
- action · call tool
- observation (✓ read the result)
- 設有虛線箭頭標示「loop」，從 observation 回到 thought。
右側為「Reflexion · ReAct + memory」流程：
- attempt
- fail
- reflect (write why it failed)
- memory (以文件圖示表示)
- 設有虛線箭頭標示「reuse next attempt」，從 memory 回到 attempt。
展開畫面重點
圖表標題為「FIG. 4 Inner loop and outer loop」。
1. **INNER · WITHIN ONE TASK（內部 · 單一任務內）**：
- 流程包含三個節點：edit（編輯）、run tests（執行測試，下方註記「✓ before answering」）、respond（回應）。
- 當「run tests」通過（pass）時，流程進入「respond」。
- 若測試失敗，則透過「fail · fix · rerun」的路徑回到「edit」重新編輯。
2. **OUTER · ACROSS SESSIONS（外部 · 跨工作階段）**：
- 流程包含兩個節點：session 1（工作階段 1，下方註記「hits the wall」）、session 2（工作階段 2，下方註記「starts ahead」）。
- 當「session 1」遇到瓶頸（hits the wall）時，會執行「writes lesson」（寫入經驗教訓）至「SKILL.md」與「AGENTS.md」檔案中。
- 隨後「session 2」透過「reads next run」（讀取下一次執行）讀取這些檔案，從而以更進階的狀態開始。
展開畫面重點
圖表標題：FIG. 6 The Bun port put verification in the architecture
流程說明：
1. 起始點：Zig codebase。
2. 轉換階段：透過數百個「port .zig -> .rs agent」進行程式碼轉換。
3. 審核階段：進入「adversarial review」（對抗性審核），每個檔案由 2 個審核代理（reviewer agents）進行反駁與驗證。
4. 修復階段：進入「fix loop」（修復迴圈），驅動建置與測試套件直到通過（drive build + test suite to green），若未通過則循環回審核階段（until green）。
5. 最終結果：合併（merged），共約 750k 行 Rust 程式碼。
6. 狀態標註：右下角標註「≈99.8% suite pass - not yet in production」（約 99.8% 的測試套件通過，尚未投入生產環境）。