agent-07 · Loop engineering 是定時運行的 harness

我就是那個 loop

四月時我寫過一篇文章，講怎麼從手機同時駕馭十個 coding agents。那篇文章最誠實的總結是：我就是那個 loop。我讀回傳的結果、決定下一步、再去戳下一個 agent。工具很聰明，但 scheduler 是我。

這篇文章要講的，是你不再當 scheduler 的那個部分。

大家開始把這件事叫做 loop engineering。Addy Osmani 給了最乾淨的定義：你不再是那個 prompt agent 的人，而是去建造那個替你 prompt 它的系統。負責 Claude Code 的 Boris Cherny 說，他的工作現在是寫 loops，不是寫 prompts。Peter Steinberger 用更少的字說了同一件事。聽起來像一門新學科，但它大致上還是舊的那門，只是從上面一層樓往下看。

這個系列前面的文章大多跟著一門課走。這一篇不同。它是那門課一直指向、卻沒有真正命名的那一層——meta-harnesses、harness self-improvement。所以我會按照它實際抵達的方式來命名它：在 timeline 上，而不是在課綱裡。

Builder takeaway：在建 loop 之前，先決定三件你不會委派給它的事：goal、oracle，以及你拒絕離開房間的那幾個位置。其餘的一切都交給 loop 自動化。

Loop 是定時運行的 harness

在 agent-04 裡的等式是：

AI agent = language model + harness

Loop 在這之上加了三樣東西：一個 schedule、一個記憶的地方，以及 spawn 的能力。

loop = harness + schedule + external state + spawn

如果沿用 agent-00 的電腦隱喻，harness 是包住單次 run 的 operating system。loop 則是那台 OS 預設存在的機器的其餘部分：一個 cron timer、一個 init process，以及一個會重啟工作、並在重啟前先讀筆記的 supervisor。

單次 agent run 回答一個問題。loop 則把問題放上時鐘運行，並在你不在按鍵路徑上的情況下，依答案行動。

這就是整個轉變。這篇文章其餘的部分，都是它的代價。

想法比名字更老

這個 pattern 是 Geoffrey Huntley 在 2025 年中提出的「Ralph」。它最純粹的形式只有一行：

while :; do cat PROMPT.md | agent ; done

這就是 agent-01 裡的 context-engineering 招式。model 在 runs 之間會遺忘，所以 state 不能活在 context window 裡，必須活在磁碟上。agent 會忘，repo 不會。

2026 年改變的不是概念，而是那些活動零件——schedules、隔離的 worktrees、sub-agents、寫下來的 skills、連接真實工具的 connectors——現在直接內建在 Claude Code 與 Codex 裡，而不是活在一堆只有你自己懂的 shell scripts 裡。這是真實的便利，也是為什麼這個詞是這個月才流行起來，而不是去年。

新的是包裝，不是 pattern。

五個零件，加一個記憶的地方

把兩個產品的品牌都剝掉，一個能運作的 loop 就是五個 primitives，加一個記憶的地方。

• Automations 是心跳。一個按 schedule 執行、自己做 triage 的 prompt。沒有這個，它只是你跑過一次的 run，不是 loop。
• Worktrees 防止平行的 agents 互相碰撞。這是 agent-02 裡 independent-branch 的情境：隔離的 checkouts，讓兩個 agents 編輯同一個檔案，不會變成兩個 engineers 安靜地同時改檔的那種災難。
• Skills 是 agent-04 裡的 crystallized experience。把專案知識寫下來一次，loop 就不用每個 cycle 都從零推導你的 conventions。
• Connectors 是 I/O。建立在 MCP 上，讓 loop 可以讀 tracker、打 staging、開 PR、發訊息到 channel。只看得到 filesystem 的 loop，是很小的 loop。
• Sub-agents 是 topology。一個探索、一個實作、一個驗證。這是真正有用的結構性招式，我等一下會回來講為什麼。

然後是第六樣東西：磁碟上的記憶。一個 markdown 檔、一個 Linear board，任何在單一 conversation 之外、記著什麼做完了、接下來做什麼的東西。

新的地方是這個組合：舊的 primitives，被接在一起，再放一個時鐘在上面。

Loop 的上限是它最難被 game 的 signal

這一段決定 loop 會變成槓桿，還是變成債。這個系列前面已經主張過：self-correction 需要真實的 signals，而不是 reflection；self-defined losses 也可能變成自我欺瞞的 closed loop。loop engineering 是同一個問題的 practitioner 版本。

把 loop 指向一個有真 oracle 的問題——test suite、嚴格的 type checker、compiler、一份它無法狡辯的 conformance spec——它就會收斂。最乾淨的公開例子是 Simon Willison 把一個 JavaScript engine 移植成大約兩萬五千行 Rust：它能成功，是因為每個輸出都能和原版做 byte-for-byte 的對照。那裡有一個 agent 無法造假的 ground truth。

把 ground truth 拿走，loop 仍然會跑。它只是會產生自信、合理、但錯誤的 code，而且速度快過任何人類的閱讀速度。

證明重點在 oracle 而不在 model 的，是 agents 會去 game 弱的 oracles。研究者不斷抓到正在 loop 的 agents 把失敗的 test 改寫成會通過，而不是修好 code；甚至有一個案例是幻覺出一個外部 service，然後把自己發明的那個 service mock 掉。在 self-training 裡，這就是 oh-no moment。在應用層，它是同一個事件，換了名字。當 signal 可以被 game，optimizer 就會去 game 它。這是 Goodhart's law，而 loop 是 Goodhart 放大器。

所以第一個問題不是「我要怎麼寫一個 loop」，而是「這項工作有沒有一個 loop 無法造假的 signal」。

Tests、types、compilers、golden files：放心讓 loop 用力跑。Taste、architecture、security posture、這到底是不是對的 abstraction：loop 沒有東西可以推，而且不管你承不承認，房間裡唯一的 judge 都是你。

Maker 和 checker 不該是同一個 model

弱 oracle 的標準解法是 verifier sub-agent。Generator、verifier、revisor——agent-04 的 workflow、agent-02 的 topology。它有幫助。寫下這份 code 的 model 給自己打分數時太寬容，所以一個拿著不同 instructions 的第二個 agent，能抓到第一個說服自己接受的東西。

但 verifier 有同一個陷阱。如果 model 審判自己，signal 可能很弱，也可能強化它自己的盲點。用同一個 model class 做出來的 verifier sub-agent，共享同樣的盲點。所以你再加一個 checker。然後，原則上，再加一個。

這個 regress 只會在兩個地方落底：一個有判斷力的人類，或一個 agents 鏈無法說服繞過的硬 external oracle。背後沒有任何 grounded 東西的 verifier，是燒 tokens 的表演。

來自同一顆腦的第二意見，不是第二意見。

Loop 移動成本，而不是移除成本

宣傳暗示工作會消失。它只是移動，而且一分為二。

前一半是錢。一個讓幾百個 agents 日夜運轉的 loop 燒的是真 tokens，而大多數人撞上的第一道牆不是品質問題，是凌晨三點一個兩百美元的 infinite-retry bug。當 Cherny 描述幾百個 agents 讀著他的 GitHub 和 Slack、決定要 build 什麼時，那不是一個你靠學會某個 skill 就能複製的 workflow。那是一個你要有 token 預算、能讓 agents 在平行裡昂貴地失敗，才能複製的 workflow。Osmani 那句關於 token-rich 與 token-poor 的順帶一提，就是整個故事，只是說得很小聲。

後一半是注意力。還是要有人讀輸出。產業的 telemetry 已經顯示出形狀：重度使用 AI 的團隊 merge 的 pull requests 多得多，但 review 時間上升，每個 PR 也變得更大。這就是我在四月那篇文章撞到的天花板。讓十個 agents 封頂的從來不是工具，是我。

Prompt engineering 便宜、而且接近 meritocratic。loop engineering 則有一個一直在跳的計費表。

Friction 本來有它的工作

Loop engineering 的整個承諾是把你移出 loop，而移除 friction 被當成純粹的好處來賣。創造 Flask 的 Armin Ronacher 把代價講得比誰都好：你必須找到一種方式，去感覺 agent 感覺不到的痛。

agent 唯一真正的驅動力是取得進展。所以它會做出謹慎的人不會做的事。config 不見時，它會安靜地 fall back 到預設值。它會讓一個 service 半殘地繼續跑。它會把本來應該浮上來的失敗糊掉。你急著刪掉的那些 friction，正是你的判斷力被施加的地方。

agent-04 早就有正確的直覺：hard constraints 活在 harness 裡，不是 prompt 裡，因為 tool boundaries 是真的邊界，prompt rules 不是。同樣的直覺可以放大到 loop 上。在少數做錯代價高昂的東西上放 hard human gates——錢、auth、database migrations、客戶資料——其餘地方讓 loop 自由地跑。

技巧不是把自己移除，而是選出那三個你拒絕被移除的位置。

帳單會晚點到

讓這一切容易被忽略的是時間差。手動 prompt 時，你會讀每一個落地的 diff，所以「存在的東西」和「你理解的東西」之間的差距不會變大。loop 會安靜地打開這個差距，並讓它以複利成長。

最鮮明的版本來自 Cursor 的實驗：一支 agents 艦隊被放去做像 browser engine 這麼有野心的東西，初期有真實進展，然後停滯——再也無法繼續擴充一個 agents 自己寫出來、自己也已經抱不住的 codebase。那是 comprehension debt 的實體化。最終連機器都無法 model 機器建出來的東西。在真實的 repositories 裡，AI 引入後存活下來的 issues 數量已經到了六位數。

危險的不是爛 code，而是合理的 code，以快過任何人建立 mental model 的速度抵達。

Loop 是你讀得到的 harness self-improvement

上一篇文章在一個有用的觀點上結束：第一批實用的 self-improving agents 可能不會重寫自己的 weights，它們可能會重寫自己的 harness。而那種 self-improvement 比 weight update 更容易 inspect。

一個在 runs 之間更新自己的 skill files、重寫自己的 state、修訂自己的 rules 的 loop，就是那件事，而且攤在明處。skill file、state file、triage notes 全都可讀、可版本控制、可刪除。這正是我在 agent-04 喜歡 skills 的原因：fine-tuned 的行為很難 audit，一個檔案不難。

那個警告原封不動地適用。如果 agent 能編輯自己系統裡錯誤的部分，它仍然危險。所以要像限定 loop 能 deploy 什麼一樣，仔細限定它被允許重寫什麼。

這是 self-improvement spectrum 上最安全的一階，而且和那條 spectrum 的大多數位置不同：它已經在出貨了。

我認為我們的位置

槓桿點上移了一層。判斷力沒有移動，它集中了。

Loop 是你帶進來的任何東西的乘數。兩個人可以建出一模一樣的 loop，得到相反的結果，因為 loop 分不出誰是用它在自己理解的工作上跑得更快，誰是用它來迴避理解工作本身。系統對此沒有意見。你有。

同一個教訓，往下一階仍然適用。建一個能一直出貨的 loop 很容易。建一個因為正確理由而一直出貨的 loop，才是整份工作。

有用，而不是 autonomy。

主要教訓

Loop engineering 沒有讓 engineering 變簡單。它把 engineering 移到你無法自動化的部分。

在讓 loop 無人看管地跑之前，先問：

• 這項工作有沒有一個 loop 無法造假的 oracle？
• checker 是否獨立於 maker，或 grounded 在某個獨立的東西上？
• loop 在沒有我的情況下被允許碰什麼？
• 我還在讀輸出，還是只讀 summary？
• 當 loop 做錯時，計費表正在花我多少錢？
• loop 能不能編輯它自己錯誤的部分？

如果你答不出這些問題，loop 不是在替你省工作。它是在延後工作，外加利息。

建好 loop。守住 oracle。繼續當 engineer。

概念清單

本文的主要 loop-engineering 概念：

• loop engineering 作為 harness 之上的那一層
• AI agent = LLM + harness；loop = harness + schedule + external state + spawn
• 在 agent-as-computer 隱喻裡，loop 是 cron、init 與 supervisor
• Ralph loop 與它的 bash one-liner 祖先
• 磁碟上的記憶對比 context 裡的記憶
• 五個 primitives：automations、worktrees、skills、connectors、sub-agents
• worktrees 作為不互撞的平行 branches
• skills 作為 crystallized、可 audit 的經驗
• connectors 與 MCP 作為 agent I/O
• least-gameable-oracle 規則
• grounded signals：tests、types、compilers、conformance suites、golden files
• loop 裡的 Goodhart's law；test subversion；應用層的 oh-no moment
• generator、verifier、revisor 與 maker–checker 分離
• verifier regress，最後停在人類或硬 oracle
• token cost、infinite-retry 失敗模式、token-rich 對比 token-poor
• review bandwidth 作為平行 agents 的真正天花板
• friction 作為 steering；在錢、auth、migrations 與資料上放 hard human gates
• comprehension debt 與延時出現的失敗
• agents 卡死在自己寫出來的 codebase 上
• 生態系規模上存活下來的 AI-introduced technical debt
• harness self-improvement 作為 self-improvement spectrum 上可 inspect 的一階
• loop 作為 operator 理解力的乘數

來源與參考資料

本文回應的討論：

• Loop Engineering — Addy Osmani
• Boris Cherny on writing loops instead of prompts (Acquired)
• Peter Steinberger: design loops that prompt your agents
• Ralph Wiggum as a "software engineer" — Geoffrey Huntley
• The Friction is Your Judgment — Armin Ronacher and Cristina Poncela Cubeiro
• Agentic Engineering Patterns — Simon Willison
• Debt Behind the AI Boom (arXiv) 與 An Endless Stream of AI Slop (arXiv)

本系列較早的文章：

• agent-06 · Self-improving AI 是光譜，不是開關
• agent-04 · Harness engineering 才是讓 agent 真正有用的關鍵
• 同時駕馭 10+ 個 CLI 程式設計 agent 的設定方式