一層層都是 loop：loop engineering 和 harness engineering 到底替代了什麼

最後更新於 2026-06-10

有個 loop，你已經跑了兩年，卻一直沒給它起名字。Agent 做完一段活，你看一眼它輸出了什麼， 判斷行不行、接下來做什麼，然後敲下一條指令；Agent 再做下一段。這個「看結果、做判斷、再 prompt」的過程， 本身就是一個 loop，而跑這個 loop 的人，是你。

想清楚這一點，2026 年到處都在說的兩個詞就不再像是互相打架的概念了。harness engineering（鷹架工程）和 loop engineering（循環工程）其實各管一攤：一個讓 Agent 自己那個 loop 跑得更久，另一個，要替掉的是你這個 loop。

三層 loop，一個套一個

往上數，一共三層 loop，層層相套，外面那個包著裡面那個。

• 最裡面是 ReAct loop。一次執行之內，Agent 先想、再叫工具、看結果、接著再想。 這是 Agent 自己的循環，一個任務裡它自己一輪一輪地轉。
• 外面包著 harness。它本身不是你來跑的循環， 而是決定「裡面那個 loop 在卡住之前能跑多遠」的那套東西：工具、狀態、上下文管理、hooks、出錯恢復。
• 再外面是你。一次執行結束、或者卡住了，事情就回到人手裡：你看結果、定下一個目標、 再發起一輪。這就是那個一直沒被起名字的 loop。

先記住這張圖，因為關鍵問題就一個：每個詞到底想動哪一層 loop。

harness engineering 動的是裡層

光有模型還不算 Agent。得拿一層鷹架把它裹起來，它才成為 Agent，這層鷹架就是 harness。 Viv Trivedy 有一句話概括了它的形狀：Agent = 模型 + Harness；你要不是那個模型，那你就是 harness。所謂 harness engineering， 就是把這層鷹架當成一件正經的工程產物來打磨：Agent 每犯一次錯，就去改環境，讓這個錯再也犯不出來， 然後接著往下鎖。

說白了，harness 就是「除了模型之外」的所有東西：

• 一份系統 prompt 加規則手冊（比如 AGENTS.md 或 CLAUDE.md）， 每一輪都塞進去。
• 工具、skills 和 connectors，外加那些告訴模型「什麼時候該用哪個」的描述。
• 上下文策略：壓縮、把大段工具輸出轉存出去、用到了才把指令亮出來，都是為了對抗 context rot（上下文越長越糊）。
• 一個沙箱，讓程式碼能安全地跑、讓 Agent 能自己驗證結果。
• hooks，用來確定性地兜底規則：攔掉破壞性命令、改完程式碼自動跑測試、推送前要審批。
• 可觀測性：日誌、呼叫鏈、token 成本和延遲。

有個很根本的現象反覆出現：同一個模型，換個更好的 harness，表現能天差地別。 有團隊光是換 harness，就把一個編碼 Agent 從榜單中游做到了前五。模型從來都不是唯一的變數。

但要看清它到底幫你換來了什麼。harness 做得好，單次執行就能跑得更遠：步子更多、過程更連貫、翻車更少， 然後才需要把控制權交回給你。它拉長的是「一口氣能推多遠、推得多穩」。 Anthropic 工程團隊有句話說得很到位：harness 裡的每個組件，背後都藏著一個「模型自己搞不定什麼」的假設； 所以模型越強，鷹架並不會消失，只是挪到新的天花板那邊去了。

但 harness engineering 有件事做不到：它沒法把你從最外層那個 loop 裡摘出去。 鷹架再好，一輪執行總會結束，總得有個東西來看結果、然後說一句「行，接著幹這個」。 過去兩年，這個東西一直是個人。

loop engineering 衝著外層來

loop engineering 這個說法是 Addy Osmani 帶火的，Peter Steinberger 和 Claude Code 的 Boris Cherny 也是這個意思。 它要自動化的，正是你一直手動在跑的那個 loop。不再是每做完一段就去看、去 prompt， 而是把目標一次性定下來，再搭一套系統，讓它推著 Agent 一直幹到目標真正達成。

而且它不只是「幫你自動敲下一句 prompt」這麼簡單。你那個 loop 從來就不只是「定下一步」， 它還默默幹著另一件事：發現「有活要幹」。所以一個真正的外層 loop，連發現和分流也得接過去： 一個定時的、或者由事件觸發的開關，把該做的事撈出來，loop 自己派下去，只有它搞不定的才回到你面前。 調度、派活、一輪一輪盯著，這三件事你一下子都不用做了。

把一個能用的 loop 拆開，裡頭是五個零件加一塊記憶：

• 自動化：一個定時的、或由事件觸發的開關，負責把活撈出來。這是心跳。
• 隔離：worktree 或各自獨立的上下文，讓並行跑的 Agent 不會互相踩到。
• skills：把專案知識寫下來一次，省得 loop 每個循環都從頭重推一遍你的規矩。
• connectors：接上活兒真正要碰的那些工具和資料。
• 子 Agent：也就是「幹活的」和「檢查的」分開，這點重要到下面專門有一節講。
• 落盤的記憶：一個檔案或一塊看板，能跨多次執行留下來，因為模型兩次之間什麼都不記得。

這些已經不是紙上談兵了。Claude Code 提供了 /loop 和 /goal， OpenAI Codex 提供了 Automations 和它自己的 /goal 命令。這些原語如今就長在你天天用的工具裡， 這也是這個詞能火起來的一部分原因。

真正變的是這裡。重心從「這一條 prompt 寫得好不好」， 挪到了「那套替你寫 prompt、又替你判斷結果的系統，搭得好不好」。 外層 loop 設計得好，能把一個好工程師放大；設計得糟，也會用同樣的速度把一個糟糕的決定放大， 而且盯著它的人還更少。

陷阱：人這個 loop 同時也在做檢查

幼稚版本的 loop engineering 就栽在這兒。要是你只是把人撤掉，讓系統自己朝著目標反覆 prompt， 你撤掉的就不只是那個說「接著做這個」的人，連那個會喊「等等，上一步錯了」的人也一起沒了。 最外層這個 loop，一直是一頂帽子下面塞著兩份活：定下一步，和驗上一步。

所以真能用的 loop，必須把驗證收進自己肚子裡。常見做法是把「幹活的」和「檢查的」拆開（maker-checker）： 另起一個驗證 Agent，專門給中間結果打分、判斷目標到沒到。注意，它絕不能是那個幹活的 Agent， 因為模型給自己的活打分，每次都往高了打。有了這個驗證者，「loop 說它幹完了」這句話才算數。 這跟把 Agent 評估做扎實是同一個道理： 生成和判斷必須分開，不然你信的不過是一個理直氣壯的猜測。

就算有了驗證者，人也沒法徹底離開檢查這攤事。你只是從「一輪一輪地盯」裡退出來，挪到了兩個位置：

• 動手之前，先把 loop 設計好。目標是什麼、驗證者拿什麼標準判定「算幹完了」、 多久跑一次、哪些不可逆的操作要卡一道審批。把「怎樣算完成」白紙黑字寫下來，最能擋住跑偏。
• 跑完之後，只看要緊的。不是每一輪都看，而是那些影響大、不好回頭的結果。 「幹完了」只是 loop 單方面的說法，要不要真的合進去，還是你說了算。

所以那句實在話不是「人只看最後狀態就行」，而更接近這樣： loop engineering 把你從「每輪都得開車」裡拽出來，挪去設計 loop、把關重要產出； 而你過去一筆一筆手動做的檢查，交給驗證 Agent 接著做。

放到手機上長什麼樣：Memex

這套說法對我們來說不只是幾個詞。早在這兩個詞火起來之前，Memex 就已經在手機上跑著外層 loop 的一個版本了： 一個本地優先、沒有後端的應用，一套多 Agent 系統，把你的記錄整理成結構化卡片、抽取知識、找出洞察， 全程都在手機上完成。這裡的 harness 就是 dart_agent_core， 我們開源的 Dart 框架，實現了完整的 ReAct loop，外加工具呼叫、用 FileStateStorage 落盤的會話、 上下文壓縮和出錯恢復。有意思的是那層約束：沒有伺服器、沒有 shell、沒有 CI。 外層 loop 得扛得住應用被砍掉、手機重啟，這正是為什麼「狀態落盤」和「事件觸發」在這裡是頂梁柱， 而不是可有可無的點綴。（這些在 Memex 背後的工程那篇裡講得更細。）

這個外層 loop 是靠事件轉的，不是靠聊天。你不會看完一張卡片再去告訴系統下一步幹嘛， 而是一條記錄事件經過全域事件匯流排，直接交給訂閱了它的那個 Agent， 觸發條件、工作目錄、技能集都寫在磁碟上的 CustomAgentConfig 裡。 Super Agent 在上面調度一組專門的 worker（Card、PKM、Insight、Comment、Memory）， 通過 delegate_task 把活派下去，每個都在各自隔離的狀態裡跑。沒有人去敲下一句 prompt。

而「算幹完了」的判定也是寫進程式碼裡的，不是聽它一面之詞。Card Agent 跑完時，Memex 會跑一遍 CardRunCompletionEvidence：磁碟上卡片在不在、fact_id 對不對、 狀態是不是 completed、有沒有標題和 UI 設定，執行記錄裡有沒有一次成功的 save_timeline_card 呼叫。全滿足才算完成；缺一樣，就把具體缺的東西塞回去讓它再跑， 直到跑滿重試上限。再加上碰到破壞性操作能先停下來的 AgentController hooks， 和專抓重複呼叫的循環偵測器，這就是前面說的驗證者和完成判定，實打實地跑在一支手機上。

真正有意思的是那層約束。講 loop engineering 的文章，大多預設你有伺服器、有 shell、有 CI。 Memex 一樣都沒有。它的外層 loop 得扛得住應用被系統砍掉、手機重啟、網路斷掉。 這恰恰說明，為什麼「狀態落盤」和「事件觸發」在這裡不是可有可無的點綴， 而是外層 loop 在手機上能跑起來的唯一辦法。

風險不會消失，只是往上挪了一層

那些本來藏在「人這個 loop」裡的麻煩，並不會因為你把它自動化就憑空消失。它們只是換了地方，其中幾個還更扎手了。

• 驗證還是最難的那塊。你只是把它從自己的眼睛，挪給了一個驗證 Agent， 再加上你對重要結果的複核。驗證者一旦不靠譜， 這個 loop 會比當年那個人肉 loop 更快、更理直氣壯地把錯活交出去。
• 「看不懂」的債越欠越多。loop 越快地產出你沒親手寫的改動， 「實際存在的東西」和「你真正搞懂的東西」之間，差距就拉得越大。
• 成本是跟著 loop 走的，不是跟著任務走。一個定時跑、每輪還帶驗證者、 底下掛著好幾個子 Agent 的 loop，不管有沒有撈到活都在燒 token。先慢慢跑，盯著帳單， 等它產出的東西你真的願意留下，再把頻率往上加。

所以結論不是「把人肉 loop 自動化，然後甩手走人」，而是這活兒換了個形狀。 harness engineering 讓一次執行靠得住；loop engineering 讓一次靠得住的執行， 在沒有你開車的情況下不停地重複。這兩件事划不划算，就看兩點： 你過去一筆一筆手動做的驗證，有沒有原樣搬進 loop 裡； 以及你還是不是那個設計這套系統的工程師，而不是只負責按下「開始」的人。

FAQ：loop、harness，以及到底什麼被替代了