本文來自微信公眾號(hào)： 葉小釵 ，作者：葉小釵，原文標(biāo)題：《OpenClaw 創(chuàng)始人吹的 Loop 工程到底是個(gè)撒？不用寫提示詞了？》
來，又來，AI領(lǐng)域又來新名詞了！這次是Loop Engineering。
借此機(jī)會(huì)，大家也順便復(fù)習(xí)下過去3年一些火過的名詞，看還記得撒：
Prompt Engineering、RAG、Context Engineering、ReAct、Agent、MCP、Skills、Harness...
如果對(duì)AI工程有一定認(rèn)知的同學(xué)會(huì)了解：上述名詞很多都是在炒冷飯，他們很有點(diǎn)對(duì)某個(gè)概念再包裝的嫌疑，比如：
提示詞工程往前走一步，做得更復(fù)雜、更系統(tǒng)一點(diǎn)就會(huì)變成上下文工程；而如果要維護(hù)好整個(gè)Agent/AI所依賴的上下文環(huán)境，就會(huì)變成Harness工程。
所以，這次出現(xiàn)的名詞Loop大概率也不會(huì)是新的，因?yàn)锳gent的經(jīng)典架構(gòu)ReAct本來就行一個(gè)循環(huán)執(zhí)行框架。
所以，這個(gè)Loop Engineering到底是怎么個(gè)事呢？
Loop Engineering
6月7日，OpenClaw創(chuàng)始人發(fā)了一條消息，大概意思是：
你不再需要為編碼智能體編寫提示詞了，你應(yīng)該設(shè)計(jì)循環(huán)來提示你的Agent
所以，對(duì)于我這種喜歡腦補(bǔ)的選手，我第一反應(yīng)就是這人又在“胡吹”了，OpenClaw在生產(chǎn)環(huán)境實(shí)際運(yùn)行的穩(wěn)定性、效率和成本，你自己心里沒一點(diǎn)逼數(shù)嗎，還在扯循環(huán)...
Peter本身是某產(chǎn)品的負(fù)責(zé)人，他說話是帶有立場(chǎng)和產(chǎn)品IP效應(yīng)的，他跟我們?cè)谡f的軟件日拋是一個(gè)事，這只是觀點(diǎn)、想法，并不是真的，大家不要說風(fēng)就是雨
但這次有些不一樣，他不是“一家之言”，Claude Code、Google的Addy Osmani也在對(duì)Loop Engineering做各種補(bǔ)充說明
于是，Loop又火了，他成功擊中了人類想要更簡(jiǎn)單、想要大力出奇跡的美好愿望。
那么Loop的價(jià)值到底在哪，他為什么要出現(xiàn)，他出現(xiàn)是為了解決什么問題呢？
Why Loop Engineering？
首先需要澄清的是：ReAct和Loop Engineering不是一個(gè)事，或者不是一個(gè)層面的事。
ReAct是Agent內(nèi)部經(jīng)典的循環(huán)架構(gòu)：推理—行動(dòng)—觀察模式，他回答的是Agent每一步如何思考、如何和外部有效交互的問題；
而Loop Engineering不解決Agent架構(gòu)層面的事，他在回答另一個(gè)問題：
當(dāng)ReAct（Agent Loop）已經(jīng)存在后，誰來持續(xù)驅(qū)動(dòng)這個(gè)Loop？
誰來給它目標(biāo)、狀態(tài)、反饋、驗(yàn)收、停止條件和恢復(fù)機(jī)制？
所以，這里的ReAct是內(nèi)部框架循環(huán)，他可能是AI工程師的活、隸屬于Agent RunTime的范疇；
而Loop Engineering是外循環(huán)工程，他是需要讓Agent持續(xù)干正事的策略、他解決的是外部任務(wù)如何持續(xù)的問題，這可以是Agent產(chǎn)品經(jīng)理的工作：
大家這里聽起來應(yīng)該是有點(diǎn)懵，我舉個(gè)案例做說明。傳統(tǒng)客服BUG反饋鏈路是這樣的：
客服在群里反饋一個(gè)問題，值班的測(cè)試看到后先判斷這是操作問題、Bug還是需求；
如果是BUG就轉(zhuǎn)給研發(fā)，研發(fā)看代碼、看日志、然后開發(fā)上線；
如果不嚴(yán)重（體驗(yàn)問題）且短時(shí)間改不了就變成Todolist第二天處理；
我們這里只關(guān)注BUG鏈路，其他邏輯略去...
這是經(jīng)常會(huì)發(fā)生的流程，而程序員對(duì)此也是很煩的，誰也不想愛愛的時(shí)候被打擾；如果這里按照Loop Engineering的定義，邏輯就變了：
客服在群里反饋問題后（甚至客服也可以用Agent替代，但我們這里不討論那么復(fù)雜的場(chǎng)景），Agent自動(dòng)監(jiān)聽并接管后續(xù)鏈路。
它會(huì)先判斷問題類型，再收集足夠的上下文：
如果問題簡(jiǎn)單、低風(fēng)險(xiǎn)，Agent可以自己修改代碼、上線，并同步給程序員和客服群。
如果問題有一定復(fù)雜度，Agent會(huì)先改好代碼，但不直接上線，而是發(fā)給程序員確認(rèn)；程序員確認(rèn)后，再繼續(xù)上線；
如果問題不清楚或風(fēng)險(xiǎn)較高，Agent就停止自動(dòng)執(zhí)行，轉(zhuǎn)人工判斷；
而整個(gè)這套機(jī)制，就是我們所謂的Loop Engineering。
至此，我相信大家也看懂了，這跟我們各個(gè)企業(yè)在推行的AI原生，其實(shí)是一個(gè)事情，換句話說：
Loop Engineering不是個(gè)工程技術(shù)的事，他是個(gè)如何與Agent合作的事，并且這里的關(guān)注點(diǎn)要從人上升到組織
這個(gè)案例是我方便大家理解而類比做的說明，接下來我們看看國(guó)外大佬的案例：
Loop的五個(gè)組件
Addy在他那篇長(zhǎng)文里，把一個(gè)完整的loop拆成了五個(gè)組件+一個(gè)外部記憶：
其實(shí)Addy也有個(gè)案例說明，但我讀下來覺得太程序員了就沒用，大家可以自己感受下：
一、Automations
Automations解決的是：Agent為什么會(huì)啟動(dòng)，也就是什么時(shí)候被觸發(fā)的問題。
比如傳統(tǒng)鏈路里，客服在群里反饋問題，得等測(cè)試、研發(fā)或者負(fù)責(zé)人看到，才會(huì)有人處理。
Loop里第一件事，就是讓Agent有自己的任務(wù)入口。比如客服群出現(xiàn)報(bào)錯(cuò)、打不開、支付失敗、提交不了這類信息，Agent自動(dòng)監(jiān)聽、自動(dòng)識(shí)別、自動(dòng)創(chuàng)建任務(wù)。
所以Automations就沒那么神秘，他就是一個(gè)規(guī)則，只要規(guī)則合理，代碼就是分分鐘的事情，
二、Connectors
Connectors解決的是：Agent如何接入真實(shí)業(yè)務(wù)系統(tǒng)？也就是連接機(jī)制的問題。
這東西的背后其實(shí)很不簡(jiǎn)單的，往小了說需要構(gòu)建整個(gè)研發(fā)團(tuán)隊(duì)的信息流、往大了說需要構(gòu)造整個(gè)公司體系的信息通道。
比如，客服簡(jiǎn)單一句：用戶說按鈕點(diǎn)不動(dòng)，這句話本身不夠處理問題。
我們?nèi)ヌ幚淼臅r(shí)候可能需要，查訂單、查日志、看用戶截圖、看最近發(fā)布記錄...
Agent要處理問題也是一樣的，所以它必須能連接客服群、訂單系統(tǒng)、日志系統(tǒng)、監(jiān)控系統(tǒng)、代碼倉(cāng)庫、工單系統(tǒng)和發(fā)布系統(tǒng)。
所以Connectors的本質(zhì)是信息通道和動(dòng)作通道，并且在這里大家就可以看出來了：Addy舉的案例太狹窄了，如果一般企業(yè)要用好他這個(gè)所謂的Loop，其實(shí)需要做很多工作的。
三、Worktrees
Worktrees解決的是：多個(gè)Agent或多個(gè)任務(wù)同時(shí)執(zhí)行時(shí)，怎么不互相污染？
比如客服群同時(shí)反饋三個(gè)問題：支付失?。ㄟ@個(gè)會(huì)直接升級(jí)為人工）、優(yōu)惠券不展示、訂單狀態(tài)異常，Agent不能在同一個(gè)環(huán)境里亂改。
在代碼場(chǎng)景里，Worktrees是獨(dú)立分支和獨(dú)立工作區(qū)；放到業(yè)務(wù)場(chǎng)景里，就是每個(gè)問題獨(dú)立工單、獨(dú)立分支、獨(dú)立測(cè)試、獨(dú)立發(fā)布判斷。
Worktrees是系統(tǒng)的隔離機(jī)制、也是邊界的控制，我相信無論Agent多智能，這兩年也一定不會(huì)有人膽敢用他在支付系統(tǒng)上面去搞事情。
四、Skills
Skills解決的是：Agent做事時(shí)依據(jù)什么經(jīng)驗(yàn)、規(guī)范和SOP？這也是我們常見的朋友了，我們知道他承擔(dān)的是團(tuán)隊(duì)工作流的執(zhí)行：
Agent從怎么去拿上下文到拿到上下文如何去做，這都要依賴與公司的處理規(guī)則，這個(gè)規(guī)則就是Skills：
比如什么問題算BUG，什么問題是操作問題，什么問題是需求；
什么問題可以自動(dòng)修，什么問題只能提方案；
哪些模塊低風(fēng)險(xiǎn)，哪些模塊涉及支付、訂單、權(quán)限、資金，必須人工確認(rèn)。
在Loop的真實(shí)使用過程中，大家多數(shù)的工作都會(huì)變成準(zhǔn)備各種skill。
五、sub-agents
Sub-agents解決的是：一個(gè)Agent不應(yīng)該既當(dāng)運(yùn)動(dòng)員又當(dāng)裁判。其實(shí)就是工程解耦的思維，有點(diǎn)之前提示詞一事一議的感覺，核心邏輯是分工：
傳統(tǒng)流程里，本來就有分工：客服反饋、研發(fā)修復(fù)、測(cè)試驗(yàn)證......
Agent接管鏈路后，也不能讓同一個(gè)Agent自己判斷、自己修改、自己驗(yàn)證。
更合理的是：一個(gè)Agent做問題分診，一個(gè)Agent做修復(fù)，一個(gè)Agent做測(cè)試或Review，復(fù)雜場(chǎng)景再交給程序員確認(rèn)。
這里倒不是說Agent能力不行，多Agent架構(gòu)是為了符合我們的習(xí)慣，畢竟單Agent維護(hù)起來要簡(jiǎn)單很多。
六、Memory
Memory解決的是：Agent如何不失憶，如何接力，如何恢復(fù)？
其實(shí)無論對(duì)于Agent架構(gòu)，還是對(duì)于機(jī)制流程，做狀態(tài)機(jī)制都是很燒腦細(xì)胞的事情。
一個(gè)BUG從客服反饋到最終上線，中間會(huì)經(jīng)歷很多狀態(tài)：已監(jiān)聽、已分類、已查日志、已定位、已修復(fù)、測(cè)試通過、等待人工確認(rèn)、已上線、已通知客服、已沉淀規(guī)則...
這里應(yīng)該是Connectors的延續(xù)，或者說整個(gè)企業(yè)信息通道建設(shè)在這個(gè)場(chǎng)景可以被打散為Memory與Connectors。
好了，上述就是Addy關(guān)于Loop的實(shí)踐方法論。
Loop到底是什么？
綜上，我們?cè)谶@里就可以為L(zhǎng)oop Engineering下一個(gè)真正的定義了：
Loop Engineering可以被看作一次AI原生研發(fā)團(tuán)隊(duì)的實(shí)踐案例
或者說，是AI原生在研發(fā)協(xié)作場(chǎng)景里的一個(gè)具體切面
它甚至都不是一次完整的AI原生組織實(shí)踐，這里切的是已從個(gè)人使用AI工具進(jìn)入了團(tuán)隊(duì)流程被Agent接管的階段，大家可以參考這張圖：
所以，你如果問我對(duì)Addy《Loop Engineering》
https://addyosmani.com/blog/loop-engineering/
這篇文章怎么看？我會(huì)說如果就我這幾個(gè)月的企業(yè)咨詢視角的話：
Addy巧妙的用了一個(gè)coding agent的案例，展示了一次AI原生研發(fā)團(tuán)隊(duì)的雛形，并給這個(gè)案例取了一個(gè)名字Loop Engineering
然后大家也就知道了，這個(gè)案例居然TMD火了：
而我真正打開去看了下，貌似大家并不了解他的內(nèi)涵，甚至有人說什么提示詞已死，這個(gè)犢子就扯大了......
結(jié)語
那么問題來了：為什么一個(gè)AI原生研發(fā)團(tuán)隊(duì)雛形的案例，能在國(guó)內(nèi)外技術(shù)圈引發(fā)如此廣泛的討論？
答案或許有些反直覺：因?yàn)榻^大多數(shù)人還停留在第一層，而Addy已經(jīng)把鏡頭拉到了第三層。
當(dāng)前多數(shù)開發(fā)者還停留在第一層（個(gè)人工具適配層），他們的目光還聚焦在：怎么寫提示詞讓Agent把代碼寫對(duì)；
而Addy在思考如何設(shè)計(jì)一套系統(tǒng)，讓Agent在無人值守的情況下持續(xù)產(chǎn)出可用代碼，這是接近第三層（組織適配）要考慮的問題。
這側(cè)面說明當(dāng)前AI行業(yè)的認(rèn)知差距可能還是不小的，依舊是魚龍混雜啊！
所以，為什么Loop會(huì)火？因?yàn)樗戎辛艘粋€(gè)沉默的痛點(diǎn)
AI Coding工具普及后，團(tuán)隊(duì)效率并沒有等比提升
為什么會(huì)這樣呢，因?yàn)闄C(jī)制沒有匹配、因?yàn)榻M織結(jié)構(gòu)沒有匹配，而這里L(fēng)oop的本質(zhì)，還是在走機(jī)制流程的爬坡，他的目標(biāo)是把隱性流程變成顯式代碼。
什么意思呢？意思是把每一步隱性的判斷標(biāo)準(zhǔn)顯性化，比如：
什么樣的問題算BUG？什么樣的算需求變更？
哪塊代碼可以快速修復(fù)？哪塊必須經(jīng)過Code Review？
什么情況可以自動(dòng)上線？什么情況必須等人工確認(rèn)？
因?yàn)锳gent必須依賴完整的規(guī)則和上下文才能能力最大化，所以這里L(fēng)oop真正在做的事其實(shí)是在構(gòu)造AI需要的舒適環(huán)境。
最后也吐槽一句，Loop Engineering又在炒冷飯，我覺得這個(gè)概念是沒必要存在的...