黃仁勛：Prompt正在過時(shí)，Loop才是新范式

Prompt已死，loop當(dāng)立

這就是最近網(wǎng)上熱傳熱議，然后老黃黃仁勛給AI新趨勢畫的新重點(diǎn)：

• Nobody writes prompts anymore. The new job is to write and handle loops.（現(xiàn)在根本沒有人寫Prompt了，新時(shí)代的核心工作是編寫和管理loop。）

啥是loop？這個(gè)詞直譯過來是“循環(huán)”，換成AI圈的說法就是：

你不再親手給AI下指令，而是設(shè)計(jì)一個(gè)系統(tǒng)，讓系統(tǒng)替你下指令、替你驗(yàn)收、不合格自己重來，直到活干完

嗯？這不就是如今Agent那一套嗎？為啥又搞個(gè)新概念出來？

暫且按下此疑惑不表，待我環(huán)顧一圈后發(fā)現(xiàn)，這個(gè)“l(fā)oop”還真挺火——

除了老黃，“龍蝦之父”Peter、“Claude Code之父”Boris Cherny、吳恩達(dá)等一眾大佬全都在談、在大力推loop。

• （Peter）別再給編程Agent寫提示詞了，去設(shè)計(jì)循環(huán)，讓循環(huán)替你提示Agent。

• （Boris）我已經(jīng)不給Claude寫提示詞了。我有一堆循環(huán)在跑，是它們在給Claude下指令、決定下一步做什么。我的工作，就是寫循環(huán)。

而當(dāng)“寫loop”取代“寫prompt”成為大佬們新的日常，loop顯然已經(jīng)越過了“又一個(gè)新概念”的階段。

剩下的問題就只有：

loop具體是指什么？它怎么就突然火起來了？

loop到底是什么

要理解loop這個(gè)新東西，我們得先回顧一下之前的那套舊范式。

過去兩年AI編程的標(biāo)準(zhǔn)動(dòng)作是這樣的：

你寫一條prompt，AI吐一段代碼，你看了不滿意，再寫一條，AI再改，你再看……

反正就是來回拉鋸，人全程盯著。

卡帕西之前還側(cè)面吐槽了“人就是瓶頸”這件事，而且勸告大家：

• 你不能坐在那里等著給每一步寫prompt，你得把自己從流程中抽離出來

把人從流程中抽離出來，這正是loop要解決的事。

其核心邏輯只有一句話：

你定義一個(gè)目標(biāo)，AI自己跑，跑完自己驗(yàn)收，不合格帶著報(bào)錯(cuò)再來一輪，直到通過或者撞上預(yù)算上限才停。

此時(shí)人的角色就從“傳話人”變成了“規(guī)則設(shè)計(jì)者”。

所以回到開頭的疑問：這跟Agent有什么區(qū)別？

顯而易見，Agent是干活的那個(gè)人，而loop是讓這個(gè)人不用你盯著也能持續(xù)干活的那套管理機(jī)制。

沒有l(wèi)oop的Agent，你提一句它動(dòng)一下，本質(zhì)上還是個(gè)聽話的工具。

套上loop的Agent，才真正變成了一個(gè)能自轉(zhuǎn)的系統(tǒng)。

原理聽起來確實(shí)不復(fù)雜，但貌似仍有點(diǎn)抽象。

別急，我又去翻了下當(dāng)前l(fā)oop的實(shí)際落地情況，結(jié)果發(fā)現(xiàn)它其實(shí)已經(jīng)藏在了我們熟悉的系統(tǒng)里。

圍繞loop，產(chǎn)品落地層目前已經(jīng)形成了“雙雄對峙”格局

一個(gè)就是大家天天都在用的Claude Code，它圍繞loop做了三件套：

/loop負(fù)責(zé)定時(shí)循環(huán)，/goal負(fù)責(zé)目標(biāo)驅(qū)動(dòng)（跑到驗(yàn)收條件滿足為止），/schedule負(fù)責(zé)云端定時(shí)任務(wù)（合上電腦也能跑）

其中最精妙的設(shè)計(jì)是/goal，它背后藏著loop最關(guān)鍵的一條原則——自己不能判自己的卷子。

Claude Code把這條原則直接寫進(jìn)了產(chǎn)品架構(gòu)：

寫代碼的是大模型，驗(yàn)收的是另一個(gè)獨(dú)立的小模型Haiku，兩個(gè)模型各司其職。

這樣一來，Agent不會自己給自己打高分，驗(yàn)收才有真實(shí)的約束力。

另一個(gè)就是OpenAI Codex。

Codex的玩法更接近“自動(dòng)化流水線+目標(biāo)驅(qū)動(dòng)+多個(gè)子Agent”的組合，在一些開發(fā)者的實(shí)際體驗(yàn)中，能看到最多8個(gè)Agent同時(shí)跑在各自的云端沙箱里，各干各的活，最后把結(jié)果匯總回來。

有意思的是，雖然兩家的實(shí)現(xiàn)路徑不太一樣，但最終長出來的形態(tài)高度相似——

都是把復(fù)雜任務(wù)拆碎，分給多個(gè)Agent并行去跑，再統(tǒng)一匯總。

在公開評測和社區(qū)口碑里，兩者的表現(xiàn)也已經(jīng)非常接近。

這也說明一個(gè)問題，模型本身已經(jīng)卷不出太大差別了，真正的差距在上層的loop編排

說到這兒，咱們直接看看“Claude Code之父”Boris Cherny每天怎么工作的就全明白了。

他自述去年11月卸載了IDE，一個(gè)月沒打開過，索性刪了。

現(xiàn)在他手下幾百個(gè)小Agent同時(shí)跑，有的掃GitHub issue，有的讀Slack上的用戶反饋，有的監(jiān)控CI失敗。每個(gè)Agent在自己隔離的代碼分支里干活，一個(gè)寫代碼，另一個(gè)跑測試驗(yàn)收。

搞不定的才進(jìn)他的收件箱，等他來做判斷。

據(jù)他透露，自O(shè)pus 4.5以來，其所有代碼都是Claude Code寫的，如今大部分代碼都是直接在他的手機(jī)上完成。

• 接下來是循環(huán)，Agent之間互相提示，中間無需人工審核。

看到?jīng)]，loop的終極形態(tài)已經(jīng)很清晰了：

人不寫代碼，也不寫prompt，只寫規(guī)則和判斷，剩下的全交給loop

怎么loop起來

那么，我們該怎么loop起來呢？

X上有個(gè)叫Codez的博主已經(jīng)都替大家總結(jié)好了，他發(fā)了一份14步實(shí)操roadmap，這里我挑了一些干貨。

step 1：先別急著建，先做“4條件測試”

loop不是什么活兒都能往里面塞，瞎建只會虧錢。

在動(dòng)手之前，先回答四個(gè)問題：

• 任務(wù)重復(fù)發(fā)生嗎？
• 有自動(dòng)化驗(yàn)收手段嗎？
• Token預(yù)算扛得住嗎？
• Agent有“高級工程師”的工具嗎？

圖片由AI生成

四個(gè)全過，才值得建loop。

step 2：從最小可行l(wèi)oop開始

第一次別搞花活，就建一個(gè)四件套：

• 一個(gè)觸發(fā)器（Automation）：定時(shí)跑、事件觸發(fā)跑都行。Claude Code里用/loop，Codex里用Automations面板。
• 一個(gè)技能（Skill）：把項(xiàng)目上下文寫進(jìn)STATE.md，讓每次運(yùn)行不用重新解釋一遍。
• 一個(gè)狀態(tài)文件（State File）：用Markdown記下“做到哪了、什么成了、什么掛了”，下次接著跑。
• 一個(gè)門禁（Gate）：測試、類型檢查、構(gòu)建——能自動(dòng)攔住壞結(jié)果的東西。

而且順序很關(guān)鍵：先手動(dòng)跑通一次→寫成Skill→包進(jìn)loop→最后才上定時(shí)。

• 跳步是loop死在生產(chǎn)環(huán)境的主要原因。

step 3：做“拆卷子”的人，別做“判卷子”的

整個(gè)loop設(shè)計(jì)里最重要的一條原則前面已經(jīng)提過了——寫代碼的和驗(yàn)代碼的，必須分開。

落地到具體操作就是：

用一個(gè)模型（或者子Agent）負(fù)責(zé)寫，用另一個(gè)獨(dú)立的模型（或者子Agent）負(fù)責(zé)驗(yàn)收，驗(yàn)收的那個(gè)不能看到寫代碼的那個(gè)的推理過程。

為什么這很重要？因?yàn)槟Ｐ徒o自己寫的代碼打分時(shí)，往往“手太松了”。

所有“看起來不錯(cuò)”的代碼，在獨(dú)立驗(yàn)收器面前大概率能挑出一堆毛病。

step 4：別人踩過的坑就別再踩了

附幾個(gè)避坑指南。

1、沒有硬停止條件。loop跑到你發(fā)現(xiàn)賬單或者被限流才停，所以需要設(shè)Token上限、迭代次數(shù)上限、時(shí)間限制。

2、狀態(tài)不落地。Agent的記憶是短時(shí)的，今天學(xué)到的東西明天就忘了，所以需要寫進(jìn)狀態(tài)文件（STATE.md），每次運(yùn)行接著讀。

3、讓loop碰“需要判斷”的活。架構(gòu)重寫、鑒權(quán)代碼、支付邏輯、產(chǎn)品方向決策，這些別讓loop碰。loop適合干“對錯(cuò)清晰、機(jī)器可驗(yàn)證、不依賴人的判斷”的活，比如Lint自動(dòng)修復(fù)、依賴更新PR、CI失敗分類、Flaky測試復(fù)現(xiàn)。

4、不讀Diff。loop合入代碼越來越快，你對代碼庫的理解越來越淺。這叫“理解力債務(wù)”——真正的代價(jià)不是Token賬單，而是某天你要調(diào)試一個(gè)團(tuán)隊(duì)里沒人讀過的系統(tǒng)。所以建議你讀Diff，哪怕只是掃一眼。

step 5：衡量指標(biāo)就一個(gè)

別管燒了多少Token、開了多少PR、跑了多少次任務(wù)。

唯一有用的指標(biāo)是：每個(gè)被接受的改動(dòng)，平均成本是多少

如果你的“被接受率”低于50%，說明你在做loop本該替你省掉的評審工作，即loop在虧錢。

從提示詞到loop，四次范式躍遷

原理和方法搞懂了，最后的問題只有一個(gè)：

loop為什么現(xiàn)在火了？

雖然嚴(yán)格來說，loop Engineering這個(gè)概念只有不到三周的歷史。

但它不是憑空蹦出來的，往回拉一下時(shí)間線就能看到一條很清晰的演化路徑。

這條路徑大佬們也已經(jīng)替大家總結(jié)好了，咱直接抄作業(yè)：

從Prompt→Context→Harness→loop，一共四次

簡單來說，從2023~2024年，這是Prompt Engineering的天下。

當(dāng)時(shí)大家都在琢磨一件事：提示詞怎么寫才能讓AI好好干活。

寫得好和寫得不好，出來的東西天差地別，所以那會兒“會不會寫prompt”基本就等于“會不會用AI”。

這一階段，人和AI的關(guān)系還停在最表面那層——你說一句，它回一句，細(xì)到每一個(gè)指令都要人親自敲。

但隨著模型能力增強(qiáng)、上下文窗口變長，以及RAG和代碼庫接入逐漸普及，問題開始發(fā)生第一次遷移。

大約在2024到2025年前后，行業(yè)開始強(qiáng)調(diào)“Context Engineering”的重要性，關(guān)注點(diǎn)從“怎么問”變成了“給AI看什么”。

也就是說，AI不再只依賴一句提示詞，而依賴你提供的整個(gè)背景。

這一階段，信息組織能力開始比寫prompt更重要，控制粒度從“一句話”上移到了“一堆信息”。

到了2025~2026年，隨著Agent系統(tǒng)逐步進(jìn)入真實(shí)開發(fā)流程，問題繼續(xù)往外擴(kuò)展。

這時(shí)人們發(fā)現(xiàn)，光給信息和上下文也不夠了，AI得能接工具、能跑代碼、能調(diào)接口、能走權(quán)限審批。

因此，你得給它搭一個(gè)能干活、能約束、能調(diào)取真實(shí)世界資源的運(yùn)行環(huán)境。

“Harness Engineering”正是為此而生。

而在Harness的基礎(chǔ)上，“l(fā)oop Engineering”成了最新的進(jìn)化方向。

如果說Harness解決的是“AI能不能在真實(shí)環(huán)境里干活”的問題，那loop解決的就是“AI能不能在這個(gè)環(huán)境里持續(xù)干活、自己推進(jìn)任務(wù)、不需要人一步步盯著”的問題。

它的核心不再是單次執(zhí)行能力，而是一個(gè)閉環(huán)系統(tǒng)的運(yùn)行能力。

所以從Prompt到Context，再到Harness，再到loop，看起來像是概念的更替，但本質(zhì)上是一條連續(xù)的遷移路徑：

人類對AI的控制粒度不斷上移，從“寫一句話”，變成“提供信息”，再變成“搭建系統(tǒng)”，最終變成“設(shè)計(jì)循環(huán)”

一個(gè)逐漸解放人類雙手的過程。

實(shí)際上，雖然loop這玩意兒剛在工業(yè)界火起來，但學(xué)術(shù)界其實(shí)早就有了類似理念。

而且很多重要工作都和我們今天熟悉的一個(gè)人有關(guān)：姚順雨（騰訊那個(gè)）。

他在大模型Agent方向最具代表性的工作之一，是2022年的ReAct框架（Reason+Act）

這篇工作在ICLR 2023拿到Oral級別，也在后續(xù)獲得了上萬引用量。

ReAct做了一件很關(guān)鍵的事：把“推理”和“行動(dòng)”綁定成一個(gè)循環(huán)過程

大模型不再是一次性輸出答案，而是先進(jìn)行可解釋的思考，再調(diào)用工具執(zhí)行動(dòng)作，執(zhí)行之后再觀察環(huán)境反饋，然后進(jìn)入下一輪推理。抽象出來就是：

• 思考→行動(dòng)→觀察→再思考→再行動(dòng)…

這個(gè)結(jié)構(gòu)本質(zhì)上就是一個(gè)最早被系統(tǒng)化表達(dá)的“agent loop”雛形。

在ReAct之后，這條路線被不斷擴(kuò)展，比如Reflexion引入“從錯(cuò)誤中學(xué)習(xí)”的反饋機(jī)制，Tree of Thoughts擴(kuò)展成多路徑搜索式推理，以及后續(xù)一系列tool-use agent工作逐步完善“規(guī)劃+執(zhí)行+反饋”的完整鏈路。

這些學(xué)術(shù)成果一點(diǎn)一點(diǎn)往前拱，最終才在工程界收斂成今天所說的“l(fā)oop系統(tǒng)”。

所以從學(xué)術(shù)視角看，loop不是某一個(gè)人的發(fā)明，它是一條逐步收斂的技術(shù)路徑。

只不過在這條路上，恰好有個(gè)我們熟悉的華人站在了一個(gè)關(guān)鍵節(jié)點(diǎn)上。

最后不得不感慨，從Prompt到loop，AI的發(fā)展還是太快了。

太快帶來的后果是，有人興奮激動(dòng)，也有人難掩擔(dān)憂。

而loop Engineering的命名者、Google工程主管Addy Osmani，正是后者當(dāng)中的一員。

他在《loop Engineering》這篇長文里寫得很明白：

• 還很早期。我持保留態(tài)度。token成本你必須非常小心。

卡帕西的話更讓人深思，他在紅杉資本AI Ascent 2026大會上引用過一句讓他本人反復(fù)回想的話：

• 你可以外包你的思考，但你沒法外包你的理解。

翻譯翻譯，AI可以替你想辦法，但你自己得真懂問題本身。

這大概是整場loop熱潮里最清醒的聲音。