一文讀懂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，不要去做只會點開始鍵的人。