# 迴圈工程到底在教你委派什麼

> loop engineering 最近很紅，但 loop、harness、loop engineering 其實是同一件事的三個名字，一個是社群叫法、一個是 Anthropic 官方用語。這篇拆開它的真正結構：從『你還在盯著』的回合式，到『連題目都交出去』的主動式，四級委派階梯；再往下挖它到底在解決什麼問題，Anthropic 自己的實測數據（20 分鐘的半成品 vs 6 小時的完整應用）說得很清楚。

- Author: Paul Kuo（郭曜郎）
- Date: 2026-07-08
- Pillar: 創造與建構 / Creation & Enterprise
- Tags: Loop Engineering, Harness Engineering, AI Agent, Claude Code, 委派階梯, Evaluator-Optimizer, 翻譯品質工程
- Canonical: https://paulkuo.tw/articles/loop-engineering-the-layer-you-own/
- Site index for LLMs: https://paulkuo.tw/llms.txt

---

> **TL;DR：** loop engineering 最近很紅，但它其實只是三個名字指同一件事：社群叫 loop，Anthropic 官方叫 harness。真正的結構是一套四級委派階梯，從「你還在盯」的回合式，爬到「連題目都交出去」的主動式。它存在的理由是三個真問題，其中最關鍵的一個是模型判斷不了自己輸出的品質。Anthropic 自己的實測數據對照很清楚：單一 agent 20 分鐘做出的是勉強能跑的半成品，拆開生成與評估的完整框架跑 6 小時，做出的才是真正堪用的成品。

「我不再 prompt Claude 了，我寫的是會自己 prompt Claude 的迴圈。」寫出 Claude Code 的 Boris Cherny [在 Sequoia AI Ascent 2026 的訪談](https://www.youtube.com/watch?v=SlGRN8jh2RI)裡這句話，後來被剪成片段大量轉發了近七十萬次。可是往下細問，麻煩就來了：同一件事，社群叫它 loop，Anthropic 官方文件叫它 harness，Google 的 [Addy Osmani 又正式取名](https://addyosmani.com/blog/loop-engineering/)叫 loop engineering。三個名字指同一個東西，難怪讀起來像三種不同的新技術。這篇把名詞對齊，再把這套東西的真正結構、它解決的問題、跟我自己做的一套系統之間的關係，一次講清楚。

## loop engineering 到底是什麼？

先把名詞對齊。loop（Peter Steinberger、Addy Osmani、swyx 這條社群脈絡在推）跟 harness（Anthropic 官方用語）是同一件事的兩個名字。harness 指模型外面那整套裝置：prompt、工具、記憶或交接檔、編排方式，模型負責想，harness 負責讓它一直對準目標。

一句話講完它在做什麼：你不再一步步手動指揮 AI，而是寫一個「會自己一直指揮 AI、朝目標反覆跑到完成」的系統。這是一條光譜，兩端是 Anthropic 在〈[Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents)〉裡分的兩家：workflow（工作流），路徑是你事先寫死的，可預測、穩；agent（代理），路徑是模型當場自己決定的，有彈性，但貴、慢、出錯會滾雪球。從簡單到複雜有五種積木：串接、分流、並行、指揮工人，最後才是生成評估。官方鐵律是能簡單就簡單，只有真的需要才往上爬。

![迴圈是什麼：一個目標進入系統，Claude 一輪一輪做事，直到滿足停止條件才輸出完成](/images/articles/loop-engineering-diagram-1-concept.svg)

真正決定你委派了多少的，是「迴圈怎麼跑」這個層次。Claude Code 官方文件〈[Getting started with loops](https://claude.com/blog/getting-started-with-loops)〉把它拆成一套委派階梯，四級，差別在「你交出什麼」：

**回合式（turn-based）**：你給一個提示，agent 自己蒐集脈絡、採取行動、驗證成果，沒做完就再跑一輪，判斷做完或力氣預算用完才回應。你還在旁邊盯著每一步。

![回合式迴圈：你給一個提示，Claude 蒐集脈絡、行動、驗證，判斷做完才回應](/images/articles/loop-engineering-diagram-2-turn-based.svg)

**目標式（`/goal`）**：你交出去的不再是每一步的指令，是「停止條件」。agent 在任務上工作，換一個獨立的評估模型檢查你設下的條件，沒過就退回繼續做，達標或到回合上限才結束。評審是另一個模型，不是 agent 自己說了算。

![目標式迴圈：你交出停止條件，評審換一個獨立模型檢查，沒過就退回繼續做](/images/articles/loop-engineering-diagram-3-goal.svg)

**時間式與主動式（`/schedule`）**：你交出去的是「觸發」，連 prompt 都不用每次給。系統在雲端常駐，盯著某個事件來源，主 agent 跑到驗證通過、開一個 PR，第二個 agent 審完通知你，你只需要決定要不要合併。最自主的「主動式」併在這一型裡：它連題目都自己找，你唯一保留的動作是最後那個決定。

![時間式與主動式迴圈：你交出觸發，系統在雲端跑到驗證通過、開 PR，你只決定要不要合併](/images/articles/loop-engineering-diagram-4-schedule.svg)

這套東西為什麼現在才紅：模型和框架兩個齒輪在協同進化。[METR 的時間跨度測試](https://metr.org/time-horizons/)顯示，Claude 3.7 Sonnet 完成一半任務的最長時長約 59 分鐘，到 Opus 4.5 已經拉到約 4 小時 49 分（METR 官方數字，信賴區間 1 小時 49 分到 20 小時 25 分，樣本仍偏少）。模型變強的同時，框架跟著簡化：原本要靠反覆重置上下文才撐得住的做法，新模型訓練後常常自己就解掉，框架的複雜度隨之下降。這條協同進化，是後面所有內容的背景。

## 它解決什麼問題？

推動 loop engineering 出現的，是三個具體的真問題。[Anthropic 工程團隊在 2026 年 5 月的一場工作坊](https://www.youtube.com/watch?v=mR-WAvEPRwE)（Ash Prabaker 與 Andrew Wilson 主講）把長時間運作的 agent 會遇到的麻煩分成三類：第一，脈絡限制，窗口有限，會遺忘，會腐壞；第二，規劃能力差，大模型天生不太會規劃，常做到一半停下來，留一個半成品；第三、也是最關鍵的一類：模型無法可靠判斷自己輸出的品質，會誤以為一個還沒做完的功能已經做完了。

早期的解法不夠。單一模型、單一會話，一直跑 build、check、fix 循環，靠壓縮歷史來修自己，這種做法的致命傷正是第三類問題：它自己蓋章通過，最後陷入無限修補一個爛地基。Anthropic 那句常被引用的原則講的就是這個：可預測地失敗，勝過不可預測地成功。

新解法怎麼對症下藥：脈絡問題用結構化的檔案交接，不靠模型記憶；規劃問題讓一個 planner agent 先把模糊需求拆成規格加多個 sprint；最關鍵的第三類問題，解法是把生成和評估拆成兩個獨立 agent，各自獨立的上下文、獨立的 system prompt，借鏡的正是 GAN 的對抗式生成。Ash 在那場工作坊講得直白：批評一幅畫遠比自己畫一幅容易，所以與其要求生成者自我批評，不如訓練一個嚴苛的獨立評審。

真正讓這套做法落地的，是開工前的一道手續：生成和評估兩個 agent 在動工前先協商清楚「這一段做完了要滿足哪些條件」，[Anthropic 實測案例](https://www.anthropic.com/engineering/harness-design-long-running-apps)裡光是其中一個關卡（level-editor sprint）就談出 27 項可測條件，每一項都有明確門檻，只要有一項沒過，這個階段就算失敗，生成方拿到具體回饋重做。

> **📊 一手實測數據**
> - 單一 agent 做同一個題目（打造一套復古遊戲製作工具）：20 分鐘、成本 9 美元，做出一個勉強能跑的雛型
> - 拆開規劃、生成、評估三個角色的完整框架：6 小時、成本 200 美元，做出的 RetroForge 是真正堪用、能玩的應用
> - 多花的近六倍時間，幾乎全用在「談清楚怎樣算做完」跟「嚴格檢查有沒有做到」，這正是產出能不能用的關鍵

Anthropic 自己還留了一句提醒：模型變強、框架跟著簡化，是協同進化，但這不代表框架這一層會消失。他們的說法是「有意思的 harness 組合不會隨模型變強而變少，它只是換了位置」，舊的被模型吃掉，新的能力又開出新的組合空間。這句話該怎麼用，得看你自己的任務落在哪個階段：模型還接不住的地方，框架還是得補上去。

## 這跟我自己的翻譯系統有什麼關係？

Anthropic 在〈Building Effective Agents〉裡舉生成評估這個積木的例子，用的正是文學翻譯：翻譯有很多細節，第一輪模型不一定抓得到，但一個獨立的評估模型可以給出有用的批評，一輪一輪修。這剛好是我今年稍早開始做的一套會議翻譯品質工程系統，我叫它 TQEF：多路語音辨識接不同引擎、進模型翻譯、後處理、出逐段譯文，這是生成端；一個評分器拿五個維度的 rubric 給每段譯文打分，術語、流暢度、語境、格式、致命錯誤，不過關就重來，這是評估端；五個來源匯流、排程常駐累積語料，是把整套東西撐住的背景設施。

我沒有讀過這套官方框架才開始做，是自己一輪一輪撞出同樣的結構。我比官方示範多想了一步：不只調評分器的 prompt，還該有一個階段（我叫它 Stage B）去驗評分器本身準不準，拿另一套指標交叉比對它的判斷、拿真人專家的評分校準它、看同一批重跑穩不穩。這個階段我還沒真正跑完，先卡在其他優先順序後面，是誠實留著的一個坑。這件事回應的正是前面那條原則：迴圈可以幫你把生成和評估拆開，但「怎樣算一句翻譯過關」這件事，永遠得是你自己先講清楚，連「這把尺準不準」都得自己驗，沒人能替你做。

從這條路走過一輪，我歸納出幾條日常工作原則：每個手工零件都寫一句「為什麼存在」，模型升級時先做減法再做加法；力氣要投在評審跟 criteria 上，換模型也不會丟，別投在疊更多迴圈，那些會被模型吃掉；一個結果不合格，別只修那一個，把它編碼進系統讓之後每一輪都受益；控 token 也要選對層次，`/goal` 的評審用便宜模型就夠，停止條件寫清楚，確定性的步驟交給腳本，不用每次重新想一遍。

loop engineering 讓你把「怎麼跑」交出去：怎麼蒐集脈絡、怎麼行動、怎麼驗證，都可以自動化。它永遠不能自動化的，是誰來定義「跑對了」這件事本身。那個標準，還是得有人先講清楚。

這篇先把框架本身講清楚。我自己這幾個月怎麼一輪一輪撞出同樣的結構、踩過哪些坑，留到下一篇細談。

## 參考資料

**Anthropic／Claude Code 官方一手**
- Anthropic，[Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents)：workflow 與 agent 的分類、五種積木
- Anthropic，[Harness design for long-running application development](https://www.anthropic.com/engineering/harness-design-long-running-apps)：RetroForge 實測、27 項契約條件
- Claude Code 官方部落格，[Getting started with loops](https://claude.com/blog/getting-started-with-loops)：四級委派階梯的官方定義
- METR，[Task-Completion Time Horizons of Frontier AI Models](https://metr.org/time-horizons/)：Claude 3.7 Sonnet／Opus 4.5 時間跨度數據
- Ash Prabaker、Andrew Wilson（Anthropic 工程團隊），[Build Agents That Run for Hours 工作坊](https://www.youtube.com/watch?v=mR-WAvEPRwE)，2026 年 5 月

**其他一手來源**
- Boris Cherny（Claude Code 負責人），[Sequoia AI Ascent 2026 訪談](https://www.youtube.com/watch?v=SlGRN8jh2RI)：本文開場那句話的原始出處。這段話後來被大量剪輯轉發，本文引用回訪談本身，不採二手轉述版本
- Addy Osmani，[Loop Engineering](https://addyosmani.com/blog/loop-engineering/)：正式為這個概念命名的原始文章