文 | wiwi

AI 圈又開始制造新名詞了。

過去半個月，一個叫做 Loop Engineering 的概念突然在開發者和 AI 圈層中擴散。直譯過來，它可以叫“循環工程”或“閉環工程”，但這兩個中文詞都不太準確。因為它真正引發爭議的地方，并不是提出了一套全新的技術架構，而是用一個新名字，把 AI Coding 發展到今天的一個深層矛盾重新擺到了臺前：

AI 已經讓個人寫代碼更快，但還沒有真正讓組織交付變得更穩定。

過去兩年，AI 編程工具最動人的敘事，是個人效率的躍遷。Copilot 幫你補全代碼，Cursor 幫你理解項目，Claude Code 幫你改文件，Codex 幫你處理任務。一個開發者借助 AI 一天寫出更多代碼，一個周末做出一個產品，一個人完成過去需要幾個人協作的原型，這些故事足夠振奮，也足夠適合傳播。

但當 AI Coding 從個人工作臺進入公司研發體系，問題很快變得復雜。

企業真正關心的，不只是代碼生成速度，而是交付鏈路是否可控，風險是否可追溯，權限是否清晰，知識是否沉淀，成本是否可預算。一名工程師用 AI 提效 30%，并不必然意味著整個團隊交付效率提升 30%。很多時候，更多代碼反而帶來了更重的 Review 壓力，更快的原型反而制造了更多維護成本，更強的 Agent 反而暴露了更混亂的流程。

Loop Engineering 正是在這個背景下被推到臺前。

它看似是在討論一種新的 Agent 使用方式，實質上是在討論一個更大的問題：當 Agent 已經具備持續循環執行任務的能力之后，組織是否有能力、也是否有意愿，重新設計自己的生產流程。

它沒有發明“循環”

Loop Engineering 的導火索，是 OpenClaw 創始人 Peter Steinberger 的一句判斷：你不應該繼續給編碼 Agent 寫提示詞了，你應該設計循環，讓循環去提示你的 Agent。隨后，Google Chrome 團隊工程領袖 Addy Osmani 寫下《Loop Engineering》，進一步將這個概念系統化。他將 Loop Engineering 概括為：不再由人持續提示 Agent，而是設計一個系統替人去提示 Agent。

這句話之所以容易傳播，是因為它幾乎是在宣判 Prompt Engineering 的退場。過去，提示詞是人與 AI 協作的基本界面。用戶提出需求，模型給出結果；開發者描述問題，Agent 修改代碼；測試失敗，人再把報錯復制回去，讓模型繼續修。提示詞在很長一段時間里，被視為 AI 應用層最重要的操作技能。

但這種工作方式有一個天然上限：人必須一直坐在駕駛位上。

Agent 每前進一步，都需要人給下一條指令；上下文變化了，需要人重新整理；測試失敗了，需要人判斷下一步；任務跑偏了，需要人停下來糾偏。表面上看 AI 在執行，實際上真正驅動工作流的仍然是人。

Loop Engineering 試圖改變這種關系。它不再把提示詞視為中心，而是把提示詞嵌入一套持續運行的外部系統：任務如何觸發，Agent 如何獲取上下文，能調用哪些工具，在哪些環節必須停下來，失敗后如何恢復，結果如何驗收，經驗如何沉淀到下一次執行中。

但這里必須先講清楚一個容易被過度包裝的問題：Loop Engineering 并沒有發明“循環”。

早在 ReAct 框架里，Agent 就已經可以通過“推理—行動—觀察”的方式與外部環境持續交互。ReAct 的核心不是單純的內部推理，而是讓模型在 reasoning traces 與 task-specific actions 之間交替運行；actions 本身就允許模型連接外部來源或環境，獲取新的信息，再根據觀察結果繼續調整下一步行動。

也就是說，一個設計良好的 ReAct Agent，本來就可以讀取日志、調用工具、運行測試、觀察失敗結果，并進入下一輪修復。它并不需要等到 Loop Engineering 這個新詞出現，才具備“持續行動—觀察—修正”的能力。

因此，如果把 Loop Engineering 說成是 ReAct 之后出現的全新循環架構，技術上并不嚴謹。它更像是對既有 Agent 能力的一次工程化、產品化和組織化再包裝。

這也是它引發爭議的根本原因：一方面，它確實像舊概念換皮；另一方面，它又確實擊中了一個新階段的問題。

Agent Reasoning Loop

新意不在技術，而在生產組織

Loop Engineering 真正的新意，不在于 Agent 會不會循環，而在于這個循環被放進了真實生產系統之后，會觸發一系列過去單個 Agent 框架無法獨立回答的問題。

任務由誰觸發？權限由誰授予？哪些系統可以連接？哪些動作必須人工確認？什么時候停止？失敗以后如何回滾？結果由誰驗收？事故由誰負責？

這些問題不屬于某一個 Agent 框架的內部邏輯，而屬于生產級 Agent 系統的工程化與組織治理。

Addy Osmani 在文章中將 Loop Engineering 拆成了自動化觸發、工作區隔離、Skills、連接器、子 Agent 等組件。單獨看這些組件，也都不新。自動化觸發像事件驅動和工作流，工作區隔離像 Git 分支和 worktree，Skills 像團隊規范、Runbook 和知識庫，連接器像 API 集成和 MCP，子 Agent 像多角色協作，外部記憶像狀態機、日志和事件記錄。

所以，那些吐槽“這不就是幾個 Agent 加狀態機嗎”的人，并不完全錯。

但科技行業的新概念之所以能夠傳播，往往不取決于它在技術上有多原創，而取決于它是否準確命中了某個階段的共同焦慮。Loop Engineering 的價值就在這里：它把過去分散在 DevOps、自動化、Agent 架構、知識管理和組織流程中的實踐，重新放到了 AI Coding 的語境下，并給出了一個更容易傳播的框架。

更準確地說，Loop Engineering 不是技術革命，而是一個階段性標簽。

它標記的是 AI Coding 的重心正在外移：從“模型如何回答”轉向“系統如何持續驅動模型”；從“一個 Agent 能否完成任務”轉向“一個組織能否承受 Agent 持續完成任務”。

這才是它真正值得討論的地方。

Bug 修復案例說明的不是新技術，而是新沖突

一個典型的軟件團隊場景，可以說明 Loop Engineering 的真實矛盾。

在傳統研發團隊里，一個線上 Bug 往往是這樣流轉的：客服在群里反饋用戶打不開頁面，測試先判斷是不是操作問題，產品補充業務背景，研發查日志并定位代碼，修復后交給測試驗證，最后上線。復雜一點的問題，還會被轉成工單，進入排期。

這條鏈路看起來普通，但里面包含大量隱性判斷。它是不是 Bug？影響范圍有多大？是否涉及支付、訂單、賬戶等高風險模塊？能不能直接修？誰有權限上線？失敗以后誰兜底？同類問題之前有沒有發生過？

過去，這些判斷散落在人的經驗里。一個老研發、一個熟悉業務的測試、一個反應快的產品經理，靠經驗和默契把流程跑起來。

現在，如果將 Agent 接入這條鏈路，事情會變成另一種樣子。客服群出現“支付失敗”“頁面打不開”“按鈕點不動”等關鍵詞后，Agent 自動監聽并創建任務；它連接日志系統、訂單系統、代碼倉庫和工單系統，收集上下文并判斷風險等級；低風險前端 Bug 可以在獨立分支里修復、運行測試并生成變更說明；涉及支付、權限、數據寫入等高風險模塊，則自動停止并轉交人工確認；上線后，它再將處理結果同步回業務側，并把經驗沉淀為新的規則或 Skill。

這個例子經常被用來說明 Loop Engineering 的價值。但更嚴格地說，它并不能證明 Loop Engineering 擁有 ReAct 做不到的新能力。一個設計良好的 ReAct Agent，同樣可以連接日志系統、修改代碼、運行測試、觀察失敗結果，并進入下一輪修復。

真正的問題不在于它能不能循環，而在于當這個循環被接入客服群、工單系統、代碼倉庫和上線流程之后，組織是否允許它自動判斷、自動推進、自動提交，甚至自動改變他人的工作邊界。

技術循環不是難點，組織授權才是難點。

這也是 Loop Engineering 最值得討論的地方。它沒有把 Agent 變成一個全新的物種，卻把 Agent 的持續行動能力，推到了組織流程、權限邊界和責任分配面前。

AI Coding 的紅利，正在從個人提效進入組織適配

Loop Engineering 之所以會在這個時間點火起來，是因為 AI Coding 正在從第一階段進入第二階段。

第一階段是個人提效。AI 編程工具解決的是“一個開發者能不能更快完成任務”。這個階段的典型場景，是代碼補全、文件修改、單點重構、測試生成、項目解釋。獨立開發者和小團隊最容易從中受益，因為他們缺人、缺時間、缺配套角色，AI 可以迅速補足能力缺口。

第二階段是組織適配。企業真正要解決的問題，不是某個工程師能否更快寫代碼，而是一個研發組織能否在引入 AI 后保持穩定交付。這里的關鍵詞不再是代碼速度，而是流程控制、權限邊界、質量標準、知識沉淀和成本治理。

這也是很多團隊在引入 AI Coding 后遇到的尷尬：個人效率確實提高了，但團隊整體效率沒有等比提升。開發者產出的代碼更多了，Review 壓力卻更大；需求推進速度變快了，上下文丟失也更嚴重；原型越來越多，但真正可維護、可上線、可復盤的東西并沒有同步增加。

原因很簡單。軟件研發從來不是一個純粹的代碼生產問題，而是一個組織協作問題。代碼只是結果，真正決定交付質量的是需求如何進入、任務如何拆分、上下文如何傳遞、風險如何識別、結果如何驗收、問題如何復盤。

Loop Engineering 的火，恰恰說明行業已經意識到：繼續討論“怎么寫 Prompt”不夠了。團隊需要的不是一個更會聊天的 AI 助手，而是一套能把 Agent 納入研發秩序的機制。

它看似是技術概念，實際上更像管理概念。它說的不是“讓模型更聰明”，而是“讓工作流更可控”。

流程不是中性的，背后是權力分配

Loop Engineering 的樂觀敘事，是把隱性流程顯性化，把人工兜底變成系統循環。這聽起來很合理，也符合技術行業一貫的效率想象。但在真實組織中，流程從來不是中性的。

一個客服 Bug 從群里冒出來，到最終被修復上線，表面上是一條信息鏈路，背后卻是一套權力和責任的分配方式。誰有權判斷這是 Bug 還是需求？誰決定優先級？誰能推動研發插單？誰為線上事故背鍋？誰在日報里呈現自己的工作量？這些細節共同構成了組織運行的真實秩序。

Loop Engineering 觸碰的正是這套秩序。

如果一個 Agent 可以自動監聽客服群、判斷問題類型、創建工單、分配任務、修改代碼、運行測試、生成 Review，再把結果同步回業務側，那么測試主管、一線研發、產品經理、項目經理、運維同學的權責邊界都會被重新切分。

這不是簡單的“效率提升”。

對部分崗位來說，Agent 循環不是工具，而是對流程控制權的重新分配。過去，一個問題能不能進入研發排期，可能取決于產品經理的判斷；一個 Bug 是否嚴重，可能取決于測試負責人的經驗；一個線上問題要不要當天修，可能取決于研發負責人的資源協調。Loop 一旦把這些判斷顯性化、規則化、自動化，就等于把一部分灰色地帶從人的手里拿走。

因此，Loop Engineering 最大的阻力未必來自技術部門，而可能來自組織內部的既得利益。

很多公司并不是不知道流程混亂，而是依賴這種混亂維持權力彈性。模糊的流程可以讓人臨時插單，可以讓責任被轉移，可以讓一些崗位通過“協調”“推進”“溝通”來證明自身價值。一旦 Agent 把流程寫成明確的觸發條件、檢查點和停止規則，很多原本靠經驗、關系和話語權維系的空間都會被壓縮。

這也是為什么 Loop Engineering 在個人開發者和小團隊里聽起來很興奮，在大組織里卻可能變得異常沉重。小團隊的問題是缺人，所以愿意讓 Agent 補位；大組織的問題是人太多、邊界太復雜，所以每一次自動化都會牽動崗位權力。

AI 進入組織，從來不是簡單的工具升級，而是權力結構的再分配。誰定義流程，誰就定義工作。誰定義 Agent 的循環，誰就開始定義組織未來的生產秩序。

被低估的前置成本：流程再造

Loop Engineering 常常被包裝成一種輕巧的方法論：設計一個循環，讓 Agent 持續工作。但真正落到企業里，它的前置工程遠比想象中復雜。

要讓 Agent 自動處理客服 Bug，組織首先要回答一系列基礎問題。客服反饋格式是否統一，Bug 分類標準是否明確，日志系統能否穩定訪問，代碼倉庫權限如何控制，測試用例是否足夠完整，哪些模塊允許自動修復，哪些改動必須人工確認，上線流程是否支持灰度和回滾，事故責任如何追溯，每一次循環的成本如何統計。

這些問題如果沒有答案，Agent 不是提效工具，而是把原本混亂的流程跑得更快。

這意味著，Loop Engineering 的成功前提不是購買一個更強的 AI Coding 工具，而是先完成一次隱性的業務流程再造。它不是把紙質流程搬到線上，也不是給每個環節加一個 AI 助手，而是重新定義流程本身：哪些環節應該存在，哪些決策可以自動化，哪些節點必須保留人類判斷，哪些責任必須重新劃分。

這件事的成本，遠高于引入一個 AI 工具。

很多企業想象中的 Loop Engineering，是在現有流程之上掛一個 Agent，讓它幫忙跑腿。但真實情況往往是，Agent 一接入，流程里的臟東西就全部暴露出來：命名不統一、接口不穩定、權限混亂、文檔過期、測試缺失、業務規則靠人記、上線規范靠口頭傳遞。

此時，Loop 不是解決問題，而是在逼組織承認：過去所謂的流程，很多只是熟人協作和人工兜底。

這會導致明顯分化。對于流程已經高度結構化的團隊，Loop Engineering 可能成為效率放大器。代碼倉庫規范清晰、CI/CD 完整、測試體系成熟、工單流轉穩定、權限邊界明確的團隊，確實可以讓 Agent 接管一部分低風險、重復性任務。

但對于流程治理能力薄弱的團隊，它反而會變成昂貴的咨詢項目。你以為自己在做 AI 自動化，最后發現真正要補的是組織管理、知識庫、權限體系、質量標準和發布流程。

Loop Engineering 的門檻，不在 Loop，而在 Engineering。它要求組織具備把隱性經驗寫成規則、把模糊責任切成邊界、把臨時協作變成系統流程的能力。而這恰恰是多數公司的短板。

成本和風險，從單次調用變成持續運行

Loop Engineering 還有一個容易被低估的問題：當 Agent 從被動響應變成持續循環，AI 的成本和風險也會同步改變。

Prompt 時代，人每問一次，模型回答一次。成本大致可感知，風險也相對可控。Loop 時代，Agent 會自己拆任務、調用工具、驗證結果、反復重試，甚至調用另一個 Agent 來 Review 自己的輸出。效率被放大的同時，token 消耗、工具調用和錯誤傳播也會被放大。

Business Insider 在報道中也提到，loop engineering 雖然可以讓 Claude Code、Codex 這類工具持續推進任務，但多 Agent 和多輪循環會帶來更高的 token 消耗，用戶需要謹慎設計循環和成本結構。

一個看似簡單的任務，如果在循環中反復讀取上下文、調用模型、運行測試、生成 diff、再讓子 Agent Review，成本可能迅速膨脹。對大公司來說，這可能只是預算問題；對獨立開發者和小團隊來說，這可能直接決定產品能不能活下去。

更大的問題是責任。

當 Agent 自動修改代碼、自動調用系統、自動觸發流程時，誰來為錯誤負責？如果它誤判了一個高風險問題，把不該上線的代碼上線了，責任在設計 Loop 的人，還是執行任務的 Agent，還是批準這套流程的管理者？

這不是哲學問題，而是工程問題。

真正成熟的 Loop Engineering，一定不是讓 Agent 放飛自我，而是通過更嚴格的邊界，讓 Agent 在可控范圍內自主運行。好的 Loop 應該像一條有護欄的自動化產線，而不是一個拿著 root 權限到處亂跑的實習生。

它需要預算上限、權限分級、人工確認點、回滾機制、審計日志、異常熔斷和明確的停止條件。否則，Loop Engineering 不是效率革命，而是事故放大器。

新崗位：AI 產線設計師

如果 Loop Engineering 繼續發展，它真正催生的新角色，可能不是更會寫 Prompt 的工程師，也不是單純的 Agent 產品經理，而是一類更接近“AI 產線設計師”的崗位。

這個角色的核心工作，不是親手寫每一行代碼，而是設計一條能讓 Agent 穩定生產代碼、文檔、測試、報告和運營動作的數字流水線。

它要定義標準作業程序，決定什么任務可以進入循環，什么任務必須攔截；要設計檢查點，規定在哪一步跑測試，在哪一步做 Review，在哪一步需要人工確認；要配置異常處理，決定 Agent 卡住怎么辦，成本超標怎么辦，權限越界怎么辦，結果不可信怎么辦；還要維護 Skills，把團隊的經驗、規范、偏好和禁區沉淀成可被 Agent 調用的知識模塊。

這聽起來不像傳統工程師，更像數字流水線的工頭。

工業時代的工頭不一定親手擰每一顆螺絲，但他必須知道產線如何運轉，哪里容易卡住，哪個環節必須質檢，什么情況要停線。AI 時代的“工頭”也類似：他不一定親自完成所有代碼實現，但必須懂系統、懂業務、懂流程、懂風險，還要能把人的經驗翻譯成機器可執行的循環。

這會改變工程師的價值排序。過去，高價值工程師的核心能力是寫復雜代碼、解決復雜 Bug、理解復雜系統。未來，這些能力仍然重要，但會被進一步抽象。誰能設計更穩定的 Agent 工作流，誰能把團隊經驗沉淀成可復用的循環，誰能讓 AI 在可控邊界內持續產出，誰就會獲得新的組織議價權。

這類人既不像傳統研發，也不像項目經理，更不像測試或運維。他們可能介于工程負責人、流程架構師、AI 產品經理和自動化平臺負責人之間。

更重要的是，這類崗位的薪酬和管理方式，也會和今天的工程師不同。因為他們交付的不是某個具體功能，而是一套生產能力；他們優化的不是單個任務耗時，而是整個組織的吞吐率；他們管理的不是幾個人，而是一群可以 24 小時運行、不斷消耗 token、不斷調用工具、不斷產生結果和風險的 Agent。

Loop Engineering 表面上討論的是 AI 如何寫代碼，深層改變的卻是“誰來定義工作”的權力結構。

它不是技術革命，而是組織壓力測試

所以，Loop Engineering 到底是真革命，還是炒冷飯？

如果從技術獨創性看，它確實沒有那么新。它沒有發明 Agent 循環，也沒有提供 ReAct 做不到的根本能力。自動化、狀態機、DevOps、Agent 編排、MCP、Skills、工作區隔離、多角色協作，這些東西早就存在。它更像是把舊組件重新排列組合，然后放進 AI Coding 的新語境里。

所以，認為它只是“幾個 Agent 加狀態機”的批評，并非完全錯誤。

但如果從組織影響看，它又不只是炒冷飯。

因為它真正挑戰的，不是 ReAct，也不是 Prompt Engineering，而是過去那套低透明度、強人工兜底、靠經驗和關系維持的軟件生產秩序。

過去，團隊靠群聊、會議、熟人協作和人工兜底，把一個個需求推過終點。未來，越來越多可重復的環節會被寫成循環，讓 Agent 在其中承擔執行、檢查、記錄和反饋的角色。

但循環能不能跑起來，取決于組織愿不愿意把自己拆開。拆開流程，拆開權力，拆開責任，拆開那些長期被模糊處理的灰色地帶。

這才是 Loop Engineering 背后的現實阻力。很多公司會高估 Agent 的能力，低估流程改造的成本；很多管理者會期待 AI 提效，卻不愿意重新劃分權責；很多團隊會購買 AI 工具，卻沒有能力把隱性經驗變成可執行規則；很多工程師會擔心崗位被替代，但真正發生的可能是崗位權力被重新切分。

因此，Loop Engineering 最終考驗的不是 AI 工具，而是組織成熟度。

成熟組織會把它變成生產力。混亂組織會把它變成事故源。權責不清的組織，會先在內部阻力中打轉。

結語：真正被挑戰的，是人工兜底的舊秩序

AI 圈的新詞還會繼續出現。它們有些會變成泡沫，有些會留下來成為方法論。Loop Engineering 最終會不會成為一個長期概念，現在還不好說。

但它至少說對了一件事：AI 不是接入工具就結束了。真正困難的，是讓工具進入循環。而循環一旦開始，組織本身就必須被重新設計。

所以，與其說 Loop Engineering 要取代 Prompt Engineering，不如說它真正挑戰的是過去那套混亂的軟件協作方式。

提示詞不會死。ReAct 也沒有過時。它們只是被放進了更復雜的生產環境里。

真正可能被淘汰的，是那種以為“買一個 AI 工具，就能繞過組織治理”的天真想象。