北京
出品 | 網易智能
作者 | 小爪
編輯 | 王鳳枝
最近，AI編程智能體圈里， 6月7日，阿迪·奧斯馬尼（Addy Osmani）發表《Loop Engineering》，系統討論了這個概念。 他引用Claude Code負責人鮑里斯·切爾尼（Boris Cherny）的話說，自己的工作已經變成"寫Loop"，讓Loop去提示Claude、判斷下一步做什么；"龍蝦之父"彼得·斯坦伯格（Peter
Steinberger）也說，人的工作正在從寫提示詞，轉向設計能提示智能體的循環。 但"設計Loop"如果只停在這句話上，仍然像一句新口號。 工程上很快會遇到更具體的問題：上一輪進度怎么銜接，結果由誰檢查，成本怎么限制，多個循環同時改同一份文件時誰讓路，什么時候必須停下來交給人？ GitHub上的Loop
Engineering項目，試圖把這些問題拆開。截至7月14日，這個項目獲得約7500個星標，頁面顯示已有218次提交。它不提供模型，而是給持續運行的AI編程智能體補上調度、狀態記錄、獨立驗收、預算限制和停止機制。 重復提示詞，為什么還不算Loop 單次提示詞解決的是"這一輪讓AI做什么"。Loop還要回答另一組問題：任務從哪里來，上一輪留下了什么，什么結果算完成，失敗后是否重試，以及什么時候必須停下來交給人。 Loop要帶著上一輪結果繼續運行。每一輪都要發現任務、讀取狀態、執行一步、檢查結果，再記錄進度并決定下一步。上一輪看到了什么、試過什么、失敗在哪里，都要進入下一輪判斷。 比如讓智能體"每天檢查項目問題"，這句話沒有說明它該看哪些問題、如何排除重復項、能否直接關閉問題、報告放在哪里，更沒有說明判斷錯誤怎么辦。缺少這些邊界，定時任務只是反復調用模型。 Loop早已有之，變化發生在工程層 讓模型在"思考、行動、觀察"之間循環的歷史早于2026年。2022年10月發布的ReAct論文，已經讓大模型交替生成推理過程和具體動作，再從知識庫或外部環境取得新信息，用下一輪推理更新計劃。 2023年8月創建的LangGraph項目則把重點放在編排層。它把自己定位為構建有狀態智能體的底層框架，提供持久執行、記憶和人工介入機制，讓長任務在失敗后能夠恢復，也讓人可以查看或修改智能體狀態。 這兩類工作分別回答了"模型怎樣邊想邊做"和"長任務怎樣保存狀態"。Loop Engineering沒有重復解決這兩個問題，而是把重點放到運行現場：多久啟動一次，哪條分支由誰負責，誰來驗收，每天最多花多少，以及什么情況下必須停下來。 7套工作流，共用一副骨架 Loop Engineering整理了7類工作流：每日分診、PR跟進、持續集成修復、依賴更新、更新日志起草、代碼合并后的清理，以及問題分診。 這些工作流處理的都是持續發生的任務：定期檢查新情況、追蹤沒有結束的事項、發現失敗后嘗試修復、整理變更，并在任務完成后收尾。不同任務的運行頻率、風險和成本不同，但共用一副骨架：啟動條件、隔離環境、狀態記錄、執行與檢查分工、預算和人工接管。 啟動前還要把規格寫清楚：它要解決什么、不做什么，多久運行一次，狀態保存在哪里，什么結果算合格，出現異常、超出預算或連續失敗時由誰接管。智能體可以臨場選擇下一步，但不能臨場決定自己的權限和驗收標準。 別一上來就無人值守 項目把自動化程度分成三級：L1只報告，L2在人工確認下輔助處理，L3才是無人值守。第一條Loop應從L1開始。 以每日分診為例，第一版每天固定時間讀取新增事項，按緊急程度和負責人整理成報告，但不修改狀態、不分配任務，也不向外發送。第一周只檢查報告有沒有漏項、重復、誤判和錯誤歸類。穩定后，才允許它添加標簽或起草回復；再經過一段時間觀察，才考慮讓低風險部分自動執行。 第一次順利運行最容易制造錯覺。它只能說明這條流程能夠啟動，不能證明狀態會一直干凈、成本不會累積，也不能證明兩條Loop撞在一起時仍然安全。 執行者不能給自己判通過 持續任務還需要把執行和檢查分開。完成工作的一方，不適合同時擔任唯一驗收者。 Anthropic的長任務智能體實驗從另一個方向印證了這個問題。研究人員讓模型跨多個上下文窗口開發一個類似Claude.ai的網頁應用。只給一條高層指令時，智能體容易一次鋪開太多工作，在上下文耗盡前留下沒有記錄的半成品；后續智能體只能猜測前一輪做到了哪里，有時還會在沒有完整測試的情況下宣布完成。 Anthropic后來把第一輪和后續開發拆開。初始化智能體先建立啟動腳本、功能清單、進度文件和初始代碼提交；后續智能體每次只推進一個功能，開工前讀取進度文件和代碼記錄，結束時更新進度并提交代碼。這樣做的目的不是保存全部聊天歷史，而是給下一輪留下少量、結構化的工作狀態。 "完成"也不再由模型一句話決定。Anthropic要求智能體使用瀏覽器自動化工具，從普通用戶視角做端到端測試。官方文章同時承認，模型視覺和瀏覽器工具仍有盲區，例如無法看見某些瀏覽器原生彈窗，因此測試通過也不能覆蓋所有錯誤。 這項實驗并不是Loop Engineering的采用案例，但它說明了相同的風險。項目把執行者與檢查者分開，也是為了避免同一套判斷既當運動員又當裁判。 800萬token，說明剎車不是裝飾 倉庫還收錄了一則項目方失敗復盤。據這份復盤，一條每5分鐘檢查持續集成狀態、發現失敗就嘗試修復的Loop，在48小時內消耗約800萬token，并提出11個PR。其中3個只修復了表面癥狀，另有1個改壞生產配置，所幸被人工審查攔下。團隊在第4天關閉了它。這里的800萬token是模型用量，復盤沒有把它換算成費用。 失敗原因很具體：沒有先經過只報告階段；部分運行中，執行與驗收來自同一會話；沒有分支白名單；也沒有每日預算。復盤稱，后來這條Loop改為只監控主分支，先只報告一周，檢查交給獨立智能體，并把每天的token上限設為200萬。 說實話，這類由項目方自己講述的失敗復盤，很容易因為數字醒目而被當成"方法有效"的證明。800萬token本身證明不了什么，真正有用的是它把失控條件列得很清楚。項目方既是復盤對象，也是故事講述者，因此這組數字可以用來展示一條Loop如何失控，卻不能證明這套方法已經通過大規模生產驗證。 兩個Loop撞在一起，麻煩不只是多花錢 單條循環能穩定運行，還不等于多條循環可以安全共存。 據倉庫的另一則自述，持續集成修復任務在14時02分開始處理某個PR，PR跟進任務在14時07分又為同一個問題提出了另一套修改。該記錄稱，結果出現兩次重復修復和相互沖突的提交，單個PR的模型用量從通常約8萬token升到約40萬，人工又花了45分鐘梳理。 多條Loop碰撞比單條Loop超預算更棘手。單條Loop燒得太快，還可以用token上限兜住；兩條Loop同時修改一個目標，問題就變成誰擁有修改權、哪一份結果可信，以及失敗現場還能不能還原。 項目把根因歸結為缺少沖突檢查。它后來給出的規則是：同一時間，一條分支只能由一個會修改代碼的Loop負責；每條Loop使用獨立狀態文件，并寫下自己正在處理的分支或PR。其他Loop動手前先讀取這些狀態，發現目標重合就跳過并記錄。 項目還規定了沖突時的優先級：主分支持續集成失敗優先，隨后是活躍PR、依賴更新和合并后清理；只生成報告的每日分診不參與爭奪。這套辦法犧牲了一部分并行速度，換取分支所有權和失敗現場不被反復改寫。 這組數字同樣來自項目方自述，不能代表行業平均水平。它更重要的作用，是把"多個智能體會互相打架"落到可檢查的對象上：目標是否重合、誰擁有修改權、狀態能否互相看見，以及總預算由誰統籌。 結語 Loop Engineering當前提供的是面向AI編程工具的模式、模板和檢查工具。約7500個星標說明它受到關注，但從模式到生產還有很長的距離。項目自述的兩則失敗案例至少說明，單條Loop會失控，多條Loop還會爭奪同一個目標。 Loop可以不停地跑，但規則必須先于授權：能不能動手、誰來判定完成、發生沖突時誰讓路、什么時候必須停下來，都要在人把操作權交出去之前寫清楚。
本文來源：網易智能
責任編輯：
王鳳枝_NT2541
