一文讀懂Loop Engineering：6大板塊和三個大坑

AI應用風向標（公眾號：ZhidxcomAI） 作者｜畢偉豪 編輯｜漠影 智東西6月15日報道，Google Cloud AI總監、前Chrome工程負責人Addy Osmani前段時間發表長文，系統闡述了最近火爆AI圈的Loop Engineering（循環工程）。 過去兩年，很多開發者跟編程Agent打交道的方式是：寫好提示詞、塞夠上下文、敲回車、讀返回結果，然後再敲下一句，Agent是手上的工具，很多人全程握著它。 而現在，有人覺得這套流程已經快走到頭了。 OpenClaw創始人Peter Steinberger最近說了一句話：“你不該再親自給編程Agent寫提示詞了。你應該設計Loop，讓Loop替你去寫。” Claude Code之父Boris Cherny說得更直白：“我已經不給Claude寫提示詞了，我有Loop在跑，它們自己決定該幹什麼，我的工作是寫Loop。” 一時間，Loop Engineering風靡AI圈，Addy Osmani隨即撰寫文章，來解讀這個繼提示詞工程和Harness工程之後又一個爆火的“新詞”。 但對於這個看起來能讓日常工作全自動運行的提效模式，Addy Osmani在解讀的同時，非常認真地提出了其可能會帶來的負面影響，如果用一個很形象的詞來總結，就是Loop雖然很好，但是不要被其誘惑，變成不會思考、只會點“開始鍵”的人。 下面是文章的編譯，智東西做了不影響原意的改編： 一、loop的構成：五塊積木，外加一層記憶 Loop Engineering由5個部分組成，核心是讓Agent自己去發現、分發和檢查工作，隨後定義完成狀態，最終決定下一步幹什麼。五個部分分別是：自動化、工作樹、skill、插件和連接器、子Agent，外加一個跨會話的記憶層。 這些東西聽起來複雜，實際上在現有的Agent產品中都已經很成熟了，諸如在Codex和Claude Code中，開發者需要做的，只是把它們拼接起來。 而且在大多數情況下，這些“積木”的底層邏輯是相同的，這意味著開發者完全不需要為“使用哪個“AI工具”而糾結，也不用擔心換工具的問題，只需要設計Loop，跑通後，在哪個工具裡都可以運行。 詳細說說這五塊積木吧： 1、自動化。或者可以叫心跳、定時任務。它在固定的時間點或者特定事件發生時自動觸發，讓Loop真正成為一個自行運轉的“Loop”。 在Claude Code裡有很多種用法，用/loop跑定時任務，用cron做調度，用hook在Agent生命週期關鍵節點觸發，或者推到GitHub Actions，電腦合上了也可以繼續跑。 還有一個很重要的模式：/goal。它不按時間觸發，而是一直運行到最開始所制定的標準真正完成為止。每跑完一輪，會有一個獨立的Agent判斷是否完成，Claude Code和Codex都有這個玩法。 如果說自動化負責開啟Loop，那麼剩下的四塊積木就負責執行工作完成Loop。 2、工作樹。當開發者同時跑兩個以上Agent的時候，時常會出現兩個Agent寫同一個文件的撞車問題。 Git worktree的思路是在同一個倉庫歷史上切出一個獨立的工作目錄，一個Agent的修改完全碰不到另一個的工作內容，等於給每個Agent配了自己獨立的工位，互不干擾。 3、skill。skill是把開發者對於整個項目的要求，諸如代碼風格、規範、架構、踩過的坑等等這些打包展示給Agent看的關鍵功能。Agent每跑一遍都讀一次，無需每次都重新輸入。 如果沒有skill，Loop每一輪都要從零推導項目該怎麼做，有了skill，它每一輪都會吸取上一次的經驗。 4、插件和連接器。這決定了Loop能不能碰到真實的工具，一個只能看文件系統的Loop是個小Loop，能操作工具幹活才是真正的Loop，連接器基於MCP協議，讓Agent能讀取Issue Tracker、查數據庫等等。 5、子Agent。Loop中非常關鍵的的一步：把寫代碼的和檢查代碼的拆成兩個Agent。讓寫代碼的Agent給自己打分太容易放水了，第二個獨立的Agent配不同的指令，甚至有時用不同的模型，專門負責檢查其他Agent的工作成果。 Loop運行過程中，讓開發者敢放開監管的最大底氣就是子Agent，一個真正信得過的驗證者。這也是/goal命令中會去做的事——讓一個獨立Agent判斷目標是否完成。 6、最後一塊：記憶。聽起來最簡單，實際上是整條流水線的脊椎。一個Markdown文件，或一個Linear看板，或任何活在單個會話之外、記錄什麼做了、什麼沒做的東西。記憶文件必須存在磁盤上，不能在上下文窗口裡，Agent會忘，文件不會。 這些“積木”拼接好以後，整個工作流會從一條線變成一個控制面板，作者展示了自己最常使用的一個Loop： 每天早上，一個定時任務在代碼倉庫上自動啟動。它調用一個分診技能，可以把分診理解成一個急診護士，只不過它翻的不是病歷，是昨天的CI失敗記錄、Open Issue、最近誰提交了什麼代碼，翻完之後，它會把發現的問題寫進一個Markdown文件或Linear看板。 對每個值得修改的的問題，這個Loop會自動開一個獨立工作區（worktree），派一個子Agent去起草修復方案，再派第二個子Agent拿著項目的技能文檔和現有測試去審查那個方案。 如果修復方案過了審查，連接器會自動開PR、更新工單，Loop搞不定的東西，會放到一個Triage收件箱裡等人處理。 把整個流程串起來的，是state file，它記錄了什麼試過、什麼通過了、什麼還開著，第二天早上會從今天停下的地方繼續。 設計出這個Loop後的每一步，發現、分配、修復、審查、開PR，一個字都不用敲。 二、搭建Loop不是當甩手掌櫃，三個問題不注意會被廢掉 Loop改變的是工作量，不是讓人從流程裡消失，它只是讓一些工作可以自動運轉，但就像經營一家公司，即便公司可以自行運轉，老闆也不能當甩手掌櫃，有這樣三個問題，隨著Loop的建立和持續運轉，會更加需要重視。 1、驗證還是你的活。作者在文章中說：開發者的工作是發佈你確認能運行的代碼。把驗證子Agent和生產的子Agent拆開，是為了讓Loop的完成狀態更加可靠，但“完成了”這三個字依然只是一個聲明，不是證明。 2、你的理解還是會爛掉，只要你允許它爛。Loop產出速度越快，實際的代碼和人能真正理解的代碼之間的差距就越大，因為代碼不是自己寫的。這叫理解債務，一個絲滑的Loop只會讓這個債務膨脹更快，除非開發者去認真閱讀並思考Loop產出的東西。 3、最舒服的姿勢可能是最危險的。當Loop自己撒歡運行時，意志不堅定的開發者極其容易被誘惑，然後不再自己進行判斷，會選擇直接收下它給的一切結果。 作者管這個叫認知投降，設計Loop是解藥還是毒藥，取決於開發者是在用判斷力設計它然後輔助提效，還是在用它來逃避思考，同一種行為，往往會得到相反的結果。 結語：Loop雖好，但依然要保持思考 作者在文末寫了這樣一句話：“搭好你的Loop，但別忘了直接給你的Agent寫提示詞仍然有效。關鍵是找到正確的平衡。” 兩個不同的人可以搭完全一樣的Loop，然後得到完全相反的結果：個人用它加速自己透徹理解的工作，另一個人用它避開理解工作本身。Loop分不清，使用者自己要分清。 Loop替人類省掉的除了繁瑣的工作，還有參與感，不再需要親手敲提示詞的那一刻，使用者也就失去了親手驗證的機會。這就是為什麼作者在講完五塊積木之後，用了同樣的篇幅講三件事：驗證還是你的活、理解債務會滾雪球、舒服的姿勢是最危險的。事實上，他在說：Loop越強，你得越清醒。 Boris Cherny的原話是“我的工作是寫Loop”，這句話並沒有說工作減少，背後蘊含的，是工作難點的變化。 搭建Loop是大勢所趨，要學也要去做，但要保持思考，像一個還要繼續做工程師的人一樣搭建Loop，不要去做只會點開始鍵的人。