2026 年 6 月，Anthropic Claude Code 負責人 Boris Cherny 說了句讓人愣住的話：
"I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops."
有意思的是，大多數開發者仍在打造完美的提示詞，而製作工具的人完全放棄了提示詞。
同一周，OpenClaw 的創始人 Peter Steinberger 用另一種方式表達了同一件事：
"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
兩個人在不同場合、不同產品上，得出了同一個結論。這不像是巧合，更像是某種工程實踐自然走到了一個拐點。
本文討論的問題是：Loop 它從那裡來？解決的到底是什麼問題？以及對大多數人來說，現在該不該動手建一個？
一、Prompt → Context → Harness → Loop
要理解 Loop Engineering，得先理解它之前發生了什麼，弄清楚整條鏈路發生了什麼。
故事從 2024 年講起。那時候跟 AI 協作的方式很簡單：你寫一條 prompt，模型回你一段結果。Prompt Engineering 這個詞就是在這個階段被發明的——用措辭+例子+格式，能讓模型輸出你想要的東西。
這套方法有一個根本性的侷限：你必須在一條消息裡事先預見模型需要的一切。你得把背景、規則、示例、約束全塞進去。模型看到什麼就知道什麼，看不到的只能猜。
到了 2025 年初，人們意識到問題不出在 prompt 的措辭上，而在於模型拿到的資訊太少。Context Engineering（上下文工程）應運而生——不再糾結於怎麼“問”，而是精心構造模型“看到”的東西：system prompt 提供角色和規則，few-shot 示例校準輸出格式，RAG 檢索注入即時知識，結構化輸入讓模型精確理解需求邊界。
上下文做好了，模型不再猜了。但一個新問題浮出來：即使資訊完美，複雜任務一次做不完。重構一個模組需要先讀程式碼、再改介面、再更新呼叫方、再跑測試驗證——這不是一個 prompt 能搞定的事。模型需要多步執行，需要工具，需要在中間觀察結果再決定下一步。
於是 Harness Engineering出現了。這個名字有點奇怪，但它描述的事情很具體：給 Agent 裝上工具——shell 命令、檔案系統讀寫、MCP 連接器、沙箱環境——然後給它一套重試機制和權限控制，讓它能在一次 session 內完成多步操作。Claude Code、Cursor、Codex 這些產品本質上都是 harness。你給它一個任務，它自己規劃步驟、呼叫工具、觀察結果、在失敗後重試。
Harness 解決了“單次 session 內的執行能力”問題。但它沒解決一個更大的瓶頸——人。
你有一個裝備精良的 Agent。它能讀程式碼、寫程式碼、跑測試、開 PR。但每天早上，是你打開電腦、檢查 CI 狀態、複製錯誤日誌、把日誌貼給 Agent、等它修完、review 結果、批准合併。第二天重複。第三天你可能就煩了。
此時Agent 的能力不是瓶頸，人才是。
Loop Engineering 的出發點正基於此，把“人觸發 Agent → 人判斷結果 → 人決定下一步”這個循環中的人替換成一個自動化系統。這個系統能定時觸發、能驗證結果、能記住上次做到那了、能決定繼續還是停止還是上報。
你不再是那個寫 prompt 的人。而是設計 prompt 系統的人。
二、讓 Loop 跑起來需要什麼
業界通用的Loop是六個元件，我們用一個具體場景來看。
假設你的團隊每天都會遇到 CI 紅了的情況——某個測試掛了，某個類型檢查報錯。沒有 Loop 時，流程是這樣的：早上打開電腦，看到 CI 紅了，把錯誤日誌複製出來，貼給 Agent，等它修完，跑測試，提 PR。明天重複。
有 Loop 時，流程變成：每天早上 8 點，系統自動醒來。接下來發生的事情，是一次完整的運行循環——
1、找到要做的事（Automations）。系統檢查 CI 狀態。全綠就什麼也不做。有失敗，就讀取錯誤日誌，確定今天的工作目標。這是觸發層——Loop 需要某種東西把它叫醒，可以是定時器（cron）、可以是事件（CI 失敗觸發 webhook）、也可以是 Agent 自己的心跳檢測。沒有這個，Loop 不會自己開始。
2、隔離：開一個乾淨的工作區（Worktrees）。系統在一個獨立的 git worktree 裡啟動修復。為什麼不直接在主分支上改？因為如果你同時跑三個修復任務，它們不能在同一個程式碼目錄裡互相覆蓋。每個子任務需要自己的副本，互不干擾。
3、讀規則：不從零開始（Skills）。Agent 啟動時先讀項目知識檔案——Codex 叫它 AGENTS.md，Claude Code 叫 CLAUDE.md，更細粒度的技能檔案叫 SKILL.md。不管叫什麼名字，做的是同一件事：把編碼規範、架構約定、常見坑點寫下來，Agent 每次啟動時自動讀取。否則每個 session 都在重新“學習”你的項目，浪費 token，浪費時間。
4、動手：連接真實世界（Connectors）。Agent 修完程式碼後，需要開 PR、關 ticket、通知你。這要求它能觸達外部系統——通過 MCP 連接 GitHub、Linear、Slack、資料庫，與外界互動或通知。
5、驗證：找另一個人打分（Sub-agents）。修完後自動跑測試。但這裡有個關鍵設計：寫程式碼的 Agent 不能自己驗證自己的程式碼——就像學生自己給自己批卷，它犯的錯誤恰恰是它發現不了的錯誤，需要用另一個 Agent 來檢查。
6、記住：寫下今天發生了什麼（Memory/State）。測試通過了就開 PR 並更新狀態檔案；沒通過就把“今天嘗試了什麼、卡在那裡”寫進狀態檔案。下次 Loop 醒來時讀取這個檔案，就知道上次做到那了、什麼試過失敗了。Agent 的上下文窗口每次都會清空，但磁碟可以用來儲存記憶知識庫。
這就是一次完整的 Loop 運行。你早上打開電腦看到的不再是“CI 紅了”，而是“這裡有個 PR 等你 review”或者“這個問題跑了兩天沒搞定，需要你看看”。
那這裡可能會問：這和 cron job 有什麼區別？看著就像一個定時執行的任務。
區別在於 cron 的邏輯是寫入時就確定的——if CI red then run fix script then commit，硬編碼的 if-else。Loop 內部的決策者是 LLM。同樣是“CI 紅了”，它可能判斷“這是個 flaky test，跳過”，也可能判斷“這涉及三個檔案的依賴變更，需要分步處理”。它的行為在執行階段才確定，因為決策者有判斷力。
三、Loop 的本質：控制論
到目前為止，大多數關於 Loop Engineering 的討論把它當成一個編排問題來講——要用 Worktrees 做隔離，用 Connectors 做連接，用 Memory 做記憶。這些回答的都是怎麼組裝，而不是為什麼要這樣組裝。
回到剛才的 CI triage 例子。仔細看那個流程在做什麼：有一個目標（測試全通過），有一個執行動作（Agent 修復程式碼），有一個檢查（測試套件跑完報告偏差），有一個反饋（把失敗資訊送回去讓 Agent 再來一輪）。
這個結構似曾相識，家裡空調設定 25 度，壓縮機開始製冷，溫度感測器測量室溫，如果還沒到 25 度就繼續製冷，到了就停。汽車巡航定速設定 120 km/h，發動機調節輸出，車速感測器測量實際車速，如果偏低就加油，偏高就減。
這本質都是同一個結構：目標 → 執行 → 測量偏差 → 反饋修正 → 再測量。
這個結構有一個共同名字。控制論（Cybernetics / Control Theory）——研究「系統如何通過反饋維持目標狀態」的學科，1940 年代誕生，核心問題只有一個：怎樣讓一個系統在受到干擾時自動修正回目標。它把這類系統拆成三個角色：控製器決定做什麼，執行器去做，感測器檢查做得怎麼樣並把偏差送回控製器，三者構成閉環。
先看控製器。
閉環需要一個決策中心——讀取偏差訊號，決定下一步怎麼修正。這就是控製器（Controller）。在 Agent 場景下，控製器是整個編排邏輯：讀取驗證結果，判斷是否達標，如果沒達標就構造下一個 prompt 再跑一輪。
控製器要做出好的決策，面臨兩個困難。第一，它不知道你的項目怎麼做事——編碼規範、架構約定、工具用法，每次從零推導就慢且不穩定。於是就需要把這些規則寫下來，讓控製器每次啟動時直接拿到。這就是 Skills 存在的原因。第二，它不記得上次做到那了——上下文窗口每次清空，今天不知道昨天已經試過什麼。於是就需要一個活在 session 之外的持久狀態。這就是 Memory/State 存在的原因。
再看執行器。
閉環需要一個角色把決策變成對真實世界的動作。這就是執行器（Actuator）。在 Agent 場景下，執行器是工具呼叫層——檔案編輯、shell 命令、API 呼叫。
執行器要精確操作，也面臨兩個困難。第一，它觸達不了外部世界——控製器說「開個 PR」，得真能連上 GitHub 才行。於是就需要讓執行器的手伸得夠遠。這就是 Connectors（通過 MCP 協議連接的外部服務）存在的原因。第二，多個 Agent 平行時會互相覆蓋——於是就需要隔離的操作空間。這就是 Worktrees 存在的原因。
最後看感測器。
閉環需要一個角色在執行完成後測量結果、報告偏差。這就是感測器（Sensor）。在 Agent 場景下，感測器就是驗證，產出的是誤差訊號，看離目標還差什麼。
感測器面臨一個結構性困難：獨立性。如果做事的 Agent 同時充當驗證者，錯誤是相關的——導致 bug 的那個盲點，恰好也是讓它看不到 bug 的盲點。就像做題後用同一個思路檢查，大機率發現不了錯誤。於是就需要另一個 Agent、甚至另一個模型來做檢查。這就是 Sub-agents 存在的原因。
還有一個不屬於三者中任何一個的東西：Automations（定時器、事件觸發、心跳檢測）。它是閉環的啟動條件——誰來按開始鍵讓回路轉起來。沒有它，三個角色再完善也不會自己主動運行。
至此，Loop Engineering的六個元件有了歸屬。它們不是拼湊的零件，而是控制自然需要的基礎設施。因為控製器需要知識和記憶，所以有了 Skills 和 Memory；因為執行器需要觸達和隔離，所以有了 Connectors 和 Worktrees；因為感測器需要獨立性，所以有了 Sub-agents；因為閉環不會自己啟動，所以有了 Automations。
現在問一個控制工程早就在問的問題：這個閉環跑起來之後，會怎樣？
空調控制的被控對像是穩定的——加熱功率和溫度的關係不會突然變。而你控制的是一個語言模型——同樣的輸入給兩次，輸出可能完全不同。隨機性越強，反饋修正就越不可缺少。
在這個系統上跑Loop，有三種結局。
收斂到正確狀態——Agent 達到目標，驗證通過，且驗證沒有撒謊，沒有幻覺，這是唯一好的結局。
收斂到錯誤狀態——Loop 停下來了，因為感測器報告“通過”，但感測器錯了：測試通過是因為測試本身寫得不對，建構通過是因為出問題的路徑沒被執行，審閱 Agent 通過是因為它太容易同意。這比永遠不停還糟糕，因為它帶著自信地停下了。
發散——Loop 達不到感測器接受的狀態，它越改越偏，最後到達上限退出。
當你想讓AI做些更複雜的事情，但是又對質量有要求時，你不能用「固定計畫」去掌控這個系統。而控制論給出的框架是：提高「收斂正確」結局的機率，或者限制後兩種結局的損失。
那在這三個角色裡，誰決定了收斂速度？是感測器。
同樣是做驗證，一個感測器只返回 pass/fail，控製器收到後只知道“還沒好”，不知道那裡沒好，下一步修正近乎盲猜。但如果感測器返回的是“那個用例掛了、那個斷言失敗了、是那個 diff 引入的”，控製器就不是在猜，而是在針對一個具體缺陷做修復。搜尋空間會被進一步壓縮。
大多數人的直覺是反的，花大錢買最強的模型來寫程式碼，然後用簡單的chat來做驗證，最後反覆幻覺，離目標越來越偏。而高槓桿的方式是去設計好的感測器，從而返回更豐富的訊號，而不僅僅關注模型更聰明。
這個邏輯就是："Great prompt + weak verification" will fail; "mediocre prompt + strong verification" will converge. 感測器就是設計本身。
四、怎麼判斷你需不需要 Loop
既然感測器是關鍵，那麼判斷“你該不該建 Loop”的問題就轉化成了一個更具體的問題：
你能不能寫出一個不需要你盯著就能拒絕壞輸出的自動化檢查？
能——你就有閉環的前提。不能——“完成”就是主觀判斷。
即使能閉環，還有幾個現實約束。任務得重複——至少每周出現一次才值得自動化，否則你建的是一個很貴的一次性指令碼。Token 預算得能承受浪費——Loop 會重讀上下文、重試失敗路徑，無論是否產出成果，每一步探索都會消耗token。Agent 得擁有足夠的工具觀察結果，否則是在盲修。
有一類我們常常犯的錯誤，面對目標不可測量的任務的設計。比如“幫我重構這段程式碼讓它更優雅”、“寫一篇好的技術部落格”、“設計一個好的 API”，這些都沒有制定客觀的 pass/fail 標準。“優雅”、“好”是主觀判斷。即使你可以讓另一個 LLM 來打分，但 LLM 打分本身不可靠——它傾向於給高分，且標準會漂移。這種情況下你建了一個 Loop，感測器說“通過了”，但這個“通過”在沒有任何客觀標準時，就是假的閉環。
如果你判斷自己滿足條件，起步的順序就是：先寫 Skills（明確意圖，讓 Agent 不用每次從頭推導你的標準），再寫感測器（確保你能精確定義“什麼叫做完”），最後才套上 cron 觸發器。先建 Inspector，再建 Loop。
Loop 不關心操作它的人是誰。它只管跑“讀感測器 → 判斷 → 再來一輪”。但感測器是你寫的——你對系統理解多深，感測器就能寫多精確。Loop 放大的是你的判斷力。 (Datawhale)