還在寫Prompt？AI編程進入Loop新階段

本文來自微信公眾號： 智訊智庫 ，作者：施展

Loop又是什么新概念？

從ReAct到Loop：

一個概念的四次演化

6月2日，Claude Code創(chuàng)作者Boris Cherny在公開活動中說，他已經不再親自提示Claude，而是讓Loop去提示Claude，判斷下一步做什么。[1]

6月7日，OpenClaw創(chuàng)作者Peter Steinberger在X上發(fā)帖：“你不應該再提示編碼Agent，而應該設計那些提示Agent的Loop。”截至6月22日，這條帖子的瀏覽量已經超過800萬。[2]

同一天，AddyOsmani發(fā)表長文《Loop Engineering》，系統化梳理了這套做法。[3]

這些都不約而同指向同一個趨勢：AI編程從Prompt升級到Loop新階段。

簡單來說，Loop是指讓AI Agent自主執(zhí)行“觸發(fā)→工作→評估→重試或結束”這一系列步驟的閉環(huán)機制。[3][4]

過去，開發(fā)者需要手動為AI編寫每一條提示詞、檢查每一次輸出、決定下一步操作，類似于“寫劇本”（規(guī)定好每句話怎么說），而Loop工程則是“建流水線”。

很多開發(fā)者在初接觸Loop時常會困惑：“這和我們現有的Agent框架（如OpenClaw、Codex等）有什么區(qū)別？我該去哪里下載Loop？”

事實上，Loop不是一個具體的工具或代碼庫，而是一種系統設計模式與方法論（就如同“面向對象編程”是一種思想，而Java/C++是實現它的工具）。現有的優(yōu)秀Agent框架，其底層通常已經具備了實現Loop的基礎能力（如定時任務、狀態(tài)保持等）。

而這一范式，經歷了四個關鍵里程碑：

2022年的ReAct論文首次奠定了AI“邊想邊做”的理論起點；2023年AutoGPT的問世將其初步工程化為可放手運行早期產品；2025年業(yè)界覺醒了主動“設計Loop”的工程意識；隨著Google CloudAI總監(jiān)Addy Osmani在2026年6月7日發(fā)表的長文《Loop Engineering》，Loop正式落地為一套系統化的工程體系。

《Loop Engineering》給出了五要素框架，將Loop的概念進一步具象化：Automation（觸發(fā)機制）、Worktree（工作隔離）、Skill（技能封裝）、Connector（外部連接）、Sub-Agent（子Agent），外加一個貫穿始終的Memory層。

• Automation（觸發(fā)機制）：系統的“起動機”，決定了整個Loop流程在什么條件下被喚醒。

  過去，AI工作的觸發(fā)器是“人類在聊天框里敲回車”；在Loop工程中，觸發(fā)是剝離人工干預的。它可以是定時驅動（例如：每天早上8點自動抓取新聞）、事件驅動（例如：數據庫里新增了一條工單、收到了特定客戶的郵件），或者是基于外部API的Webhook信號。它讓AI系統從“被動問答”變成了“全天候待命”的服務。

• Worktree（工作隔離）：系統的“安全沙箱與操作臺”，為AI的自主運行提供一個獨立、安全、可控的臨時物理環(huán)境。

  AI在不斷“循環(huán)（Loop）”試錯的過程中，會生成很多中間產物（比如寫了一半的代碼、下載的臨時圖片、生成的日志）。Worktree就像是給AI分配的一張“臨時工作臺”或“沙箱（Sandbox）”。它確保了AI的操作不會越界破壞宿主機的核心文件，同時也方便在任務完成后，將這個工作臺一鍵打包保存或清空銷毀。

• Skill（技能封裝）：系統的“工具箱”，將其影響范圍擴展到現實或數字世界的原子化功能模塊。

  開發(fā)者將特定的能力預先寫好并封裝起來，比如“執(zhí)行一段Python代碼”、“將網頁轉化為Markdown”、“計算數學公式”等。在Loop運行期間，AI會根據當前的需要，自主決定從工具箱里“掏出”哪個Skill來使用。

• Connector（外部連接）：系統的“神經觸角”，負責打通AI系統與企業(yè)現有SaaS軟件、數據庫或第三方平臺的通道。

  如果說Skill是通用的能力，那么Connector就是具體的業(yè)務橋梁。比如連接飛書/釘釘用來自動發(fā)通知，連接GitHub用來提PR（拉取請求），連接Salesforce用于更新客戶數據。Connector解決了權限認證和數據格式轉換的問題，是Loop真正融入人類業(yè)務流的關鍵。

• Sub-agent（子Agent）：系統的“專業(yè)外包團隊”，為了避免單一AI模型處理復雜任務時“腦容量過載”或產生幻覺，將其拆分為多個職責單一、專業(yè)對口的微型Agent。

  比如在一個“自動化代碼修復Loop”中，不再只用一個龐大的Agent包攬一切。而是設置一個“測試Sub-Agent”只負責找Bug，一個“編碼Sub-Agent”只負責寫補丁，一個“評審Sub-Agent”負責代碼Review。主Loop負責統籌和路由，Sub-Agent負責在各自擅長的領域內單點突破。

• 貫穿始終的Memory（記憶層）：系統的“海馬體”,負責狀態(tài)管理與信息留存。沒有這一層，AI每次循環(huán)都會“失憶”。

盡管看起來是一個系統工程模式的創(chuàng)新，但也有人對其內涵發(fā)出質疑：Reddit上有人說“這就是戴了頂帽子的cron job（類似一個定時任務）”。更有人說：從Prompt Engineer到Context Engineer到Harness Engineer到Loop Engineer——同一人換不同馬甲。[4]

但實際上，Loop是在三者演進路線上的必然結果。舉個例子，Prompt是你在教新人做簡單的溝通；Context就類似員工手冊或項目背景；Harness是執(zhí)行手冊和規(guī)范，讓他能開始干活；而Loop就是給新人制定的OKR，讓他在了解背景、懂得規(guī)范的情況下，自主完成既定的目標。

這既是一個新人成長的路徑，也是AI編程成長的必經之路。

從“跑不起來”到“完整可用”，

但Loop有可能會讓賬單爆表

由主目標支配的Sub-Agent則能更高效地提升編程效率，你可以想象，當一個業(yè)務從單打獨斗的大頭兵單干，升級為一個小團隊協同作戰(zhàn)，效率更高，但也有可能犯更大的錯。

Anthropic Labs團隊成員Prithvi Rajasekaran曾比較單Agent和多Agent Harness：面對同一個2D復古游戲編輯器任務，單Agent運行20分鐘、成本9美元，但核心玩法無法工作；三個Agent Harness運行6小時、成本200美元，規(guī)劃出16項功能，并交付了一個核心流程可運行的原型（盡管還存在交互、物理和深層功能的缺陷）。[8]

超過20倍的模型調用成本，換來了從“核心流程不可用”到“可運行原型”的質變。

這不是效率提升，這是能力曲線的躍遷。但代價是明確的：Token賬單有可能會成倍增長。

True Foundry的分析指出，Loop并不是免費的生產力提升。無人值守模式下，如果沒有Token預算、步數上限、限流和異常監(jiān)控，Agent可能在無人察覺的情況下持續(xù)重試，讓成本快速失控。[4]

Reddit社區(qū)上，有開發(fā)者自述隔夜掛著Claude Code跑循環(huán)任務，第二天發(fā)現賬單超出6000美元——該開發(fā)者將原因歸因于緩存過期時間變化，導致每30分鐘重新提交約80萬Token上下文。[9]

另一個由Medium匿名賬戶發(fā)布的帖子表示：其組建了一個由四個LangChain Agent組成的市場調研Loop，兩個Agent在互相“要求對方做更深入分析”，沒有任何人或機制來打斷這個循環(huán)——11天后賬單到達，高達47000美元。[10]

這些數字背后有一個結構性矛盾：Loop工程的價值在于“無人值守”，但“無人值守”恰好是成本失控的溫床。沒有人的判斷力做剎車，一個Agent可以在你把咖啡喝完之前跑出一個token天價賬單的驚悚故事。

比燒錢更危險的，

是人逐漸失去判斷力

成本問題還不是最危險的。更隱蔽的風險是“認知風險”。

Osmani在他的博客里提出了三個風險，每一個都直指工程實踐的核心矛盾：

第一，驗證責任仍在人。Loop輸出的“完成了”只是聲明，不是證明。系統可以跑完整個流程、提交PR、甚至發(fā)通知說“搞定”，但沒有人真正審查過輸出質量。

第二，理解債務。Loop產出越快，人實際理解的代碼與系統真實狀態(tài)之間的差距越大。你只看了幾個關鍵節(jié)點的輸出，但系統在你睡覺時跑了300次迭代。

第三，認知投降。開發(fā)者停止形成自己的判斷，盲目接受Loop輸出。[3]

這三個風險不是理論推演。

相關研究將這類現象稱為“目標漂移Goal Drift”—系統在局部越來越有能力，但對任務的原始意義越來越不負責任。

一個思想實驗解釋“目標漂移”[11]，比如老板讓AI：“提高客服效率，同時真正解決用戶問題。”

AI一輪輪自我優(yōu)化后變成：“回復越快越好”→“少問幾個問題”→“多用模板回復”→“盡快把工單標成已解決”。

它依然邏輯清楚、執(zhí)行力很強，甚至比以前更聰明，只是它努力維護的東西已經變了。

你省下的每一分鐘“手動提示”時間，都在累積一筆看不見的技術債。這筆債什么時候到期，取決于你的系統設計有多健壯——以及你對“完成”的定義有多清晰。

Loop工程仍是被低估的

生產力杠桿，

但核心是學會設計“好的Loop”

盡管Loop是一個全新的范式概念，但在生產環(huán)境里，已經有類似的框架設計。

這些案例盡管表述不同，但都不約而同采用了類似Loop的工程理念，足以證明其在生產力環(huán)節(jié)的潛力。

而其潛力，在于同時擁有「自主性」和「并發(fā)性」，更像一個團隊作戰(zhàn)。在設計了危險邊界、明確了路徑和驗收標準、且加入了多個子agent的并行處理后，單個項目內擁有了自主可迭代、可控制的小團隊，

一個設計良好的Loop系統，可以在你睡覺時同時跑50個實驗、測試100種配置、修復20個Bug，且每一次迭代都不需要對齊會議，不需要stand up，不需要等code review排隊。

當然，這里有個前提：你得把Loop設計對——即你這個小團隊里的人是干活的（SKILL是對的）、關系是打通的（Connector是有效的）、SOP（執(zhí)行規(guī)范）是對的、老板腦子是清楚的（能驗證成果、控制成本）。

設計一個優(yōu)秀的Loop，更重要的是回答三個問題（一個頭腦清楚的老板該回答的問題）：

• 停止條件是什么？不是“完成了就停”，而是“什么叫完成”。如果答不上來，Loop就會在“完成”和“還沒完成”之間永遠振蕩，或者更糟——在錯誤的地方停下來。

• 誰來驗證輸出？AI聲明“完成”和人確認“可用”是兩件事。一個沒有驗證環(huán)節(jié)的Loop，是一臺有發(fā)動機沒剎車的機器。

• 出了問題，我能在多少錢花出去之前知道？監(jiān)控不是可選項，是Loop設計的第一道工序。LangChain事件，不是因為Loop失控了才被發(fā)現——是因為賬單來了才被發(fā)現。這兩者之間差了11天。

這三個問題，是設計可靠Loop時最容易被跳過的治理環(huán)節(jié)。大多數失敗的Loop，都是因為有人興沖沖地把“觸發(fā)”和“工作”設計好了，然后跳過了“評估”和“終止”——就像造了發(fā)動機卻沒裝剎車。

構建一個包含“觸發(fā)器→任務邊界→狀態(tài)/記憶→執(zhí)行Agent→外部驗證→停止條件→成本/步數上限→人工接管”的“好Loop最小結構”，才能推動AI編程在極大釋放產能的前提下，依然保持可控與可信。

2026年AI編程，正在經歷一個類似于2004年前后的時刻：那時云計算從“聽起來不靠譜”變成了“不用就落伍”，過渡期大概花了五到七年，AI的進化則會更快。

【聲明】本文圖表及分析框架基于公開信息整理，僅供產業(yè)研究參考，不構成對任何上市公司的投資建議或買賣依據。

參考資料：

[1]https://x.com/steipete/status/2063697162748260627

[2]https://explainx.ai/blog/loop-engineering-coding-agents-claude-code-guide-2026

[3]https://thenewstack.io/loop-engineering/

[4]https://addyosmani.com/blog/loop-engineering/

[5]https://arxiv.org/pdf/2210.03629

[6]https://mitchellh.com/writing/my-ai-adoption-journey

[7]https://martinfowler.com/articles/harness-engineering.html

[8]https://www.anthropic.com/engineering/harness-design-long-running-apps

[9]https://metr.org/blog/2026-1-29-time-horizon-1-1/

[10]https://www.makeuseof.com/someone-left-claude-code-running-overnight-and-it-cost-6000/

[11]https://dev.to/dingdawg/how-an-ai-agent-ran-up-a-47000-bill-in-11-days-and-how-to-stop-it-1fk

[12]http://m.hzrcw.cc/dy/article/KVFDE8IC0534A4SC.html

[13]https://www.zendesk.com/newsroom/articles/relate-2026/

[14]https://arxiv.org/abs/2505.02709

本內容由作者授權發(fā)布，觀點僅代表作者本人，不代表虎嗅立場。如對本稿件有異議或投訴，請聯系 tougao@huxiu.com。

本文來自虎嗅，原文鏈接：https://www.huxiu.com/article/4874380.html?f=wyxwapp