Loop Engineering：設計一個循環讓Agent自己跑
整理版優先睇
從寫提示詞轉向設計循環系統：五個構建塊加記憶層，讓Agent自動運行
呢篇文章係 Addy Osmani 寫嘅一篇長文，講一個新趨勢叫「Loop Engineering」。佢指出而家嘅程式設計Agent已經唔再係手動寫提示詞咁簡單，而係要設計一個循環系統，由個系統自己去提示Agent、分配任務、檢查結果同記錄進度。之前兩年，你用Agent嘅方式係逐輪手動控制，寫一條好提示，等佢輸出，再寫下一條。但而家嘅做法係構建一個細系統，佢自己會自動做曬所有嘢。
Osmani 將呢個循環系統分成五個構建塊（自動化、工作樹、技能、插件同子Agent）再加一個記憶層（狀態）。自動化係心跳，令系統可以定時自動執行；工作樹解決並行時嘅文件衝突；技能避免每次冷啓動都要重新解釋項目；插件同連接器俾Agent觸達真實工具（如Issue tracker、數據庫）；子Agent將寫代碼同驗證分開，避免自己打分太寬容。狀態係一個Markdown文件或看板，記錄做過咩同下一步，因為模型喺兩次運行之間會忘記一切。
Osmani 清醒咁指出循環解決唔到嘅三個問題：驗證仍然係你嘅責任，無人值守嘅循環會無人值守咁犯錯；你嘅理解會退化，循環越快產出代碼，你實際理解嘅差距越大，形成「理解債務」；同埋認知投降，容易停止自己判斷。佢總結話槓桿點已經移動咗，設計循環比提示工程更難，因為你要保持判斷力。最後佢話：設計循環，但要好似一個打算繼續當工程師嘅人咁去設計，而唔係一個只負責撳掣嘅人。
- 結論：循環設計比提示工程更重要，槓桿點已經從寫 prompt 轉向設計系統，讓 Agent 自動運行。
- 方法：五個構建塊加一個記憶層——自動化（心跳）、工作樹（並行衝突）、技能（重用上下文）、插件（連接真實工具）、子Agent（分工驗證）同狀態（持久紀錄）。
- 差異：過去係手動逐輪提示Agent，而家係設計一個循環系統，系統自己提示Agent、分配任務同檢查結果。
- 啟發：循環會加劇理解債務同認知投降，設計者要保持判斷力，唔好逃避思考。
- 可行動點：先從一個簡單嘅自動化 triage 開始，逐步加入工作樹同子Agent，同埋留意 token 成本限制。
背景：當提示工程變成循環設計
Addy Osmani 指出一個正在發生嘅轉變：由「寫提示詞」轉向「設計循環系統」。佢話你唔應該再手動俾編程 Agent 寫提示詞，而應該設計一個循環，讓循環去提示 Agent。呢個觀點之前 Boris 已經表達過，而家呢篇文章更加系統咁介紹。
過去兩年，你用 Agent 嘅方式係逐輪手動控制；而家你構建一個小系統，佢自己會自動完成所有步驟。
呢篇文章將循環系統分成五個構建塊加一個記憶層，而 Codex 同 Claude Code 都已經支援曬呢六樣嘢，只係名唔同。
五個構建塊 + 一個記憶層
- 1 自動化（Automations）——心跳：透過 cron、/goal 或 hooks 令循環自動執行，唔使每次手動觸發。Codex 有 Automations tab，Claude Code 有 /loop 同 /goal。
- 2 工作樹（Worktrees）——並行不打架：每個 Agent 用獨立目錄編輯，避免文件衝突。Codex 內建支援，Claude Code 用 --worktree 標誌。
- 3 技能（Skills）——唔使每次都從頭解釋：一個 SKILL.md 檔案加可選腳本，寫一次意圖，每次運行都讀到，解決「意圖債務」。
- 4 插件同連接器（Plugins & Connectors）——觸達真實工具：基於 MCP 嘅連接器，令 Agent 可以讀 Issue、查數據庫、發 Slack 訊息。
- 5 子Agent（Sub-agents）——寫代碼同檢查分開：用唔同指令甚至模型嘅第二個 Agent 驗證第一個嘅輸出，避免自己打分太寬容。
再加上一個記憶層——狀態（State）：一個 Markdown 檔案或者看板，記錄做過咩同下一步，因為模型喺兩次運行之間會忘記一切。狀態必須存在磁盤上，而唔係上下文入面。
一個實際循環模式：早上自動化 triage
Osmani 分享咗一個常用模式：每日早上自動化跑一次，提示詞調用一個 triage skill，讀取昨日嘅 CI 失敗、打開嘅 Issue 同最近嘅 commit，將發現寫入 Markdown 或 Linear。
- 每個值得做嘅發現，開一個獨立工作樹，派子 Agent 起草修復。
- 第二個子 Agent 對照項目 skills 同現有測試審查。
- 連接器令循環自己開 PR、更新工單。
- 循環處理唔到嘅，入 Triage 收件箱等你。你只設計咗一次，冇手動提示任何一步。
你只設計咗一次。你冇手動提示任何一步。
循環嘅侷限同反思：唔好逃避思考
- 1 驗證仍然係你嘅責任；無人值守嘅循環會無人值守咁犯錯。
- 2 你嘅理解會退化——循環越快產出代碼，你實際理解嘅差距越大，形成「理解債務」。
- 3 認知投降，好容易停止判斷，拎咩係咩。
設計循環，但要好似一個打算繼續當工程師嘅人咁去設計，而唔係一個只負責撳掣嘅人。
最後佢提醒 token 成本嘅現實：循環能推多遠取決於你嘅 token 預算，有限計劃用戶要留意。
Addy Osmani 出咗篇長文，講嘅係一個新名詞：Loop Engineering。佢指出一個正喺度由「寫提示詞」轉向「設計循環系統」嘅趨勢。
「你唔應該再手動幫編程 Agent 寫提示詞喇。你應該設計一個循環，等循環去提示 Agent。」
之前 boris 已經講過呢個觀點：Claude Code 作者 Boris：我已經唔寫 prompt 喇，我寫 loop
今日呢篇文章更加系統噉介紹咗呢個觀點。
之前同而家
過去兩年，你用編程 Agent 嘅方式好簡單：寫一條好提示，塞夠 context，等佢輸出，你再寫下一條。Agent 係工具，你全程揸住佢，一輪接一輪。
而家唔同咗喇。你建立一個小系統——佢自己揾嘢做、分配任務、檢查結果、記錄進度、決定下一步。你唔再親自督 Agent，系統代你做呢件事。
Osmani 將呢件事分成 五個構建組件 + 一個記憶層。有意思嘅係，Codex 同 Claude Code 而家都支援曬呢六樣嘢，只係個名唔同。
五個構建組件
1. 自動化（Automations）——心跳
令循環真正循環起嚟嘅嘢。唔係 run 一次就搞掂，而係按計劃自動執行。
Codex 嘅 Automations tab 裏面，你揀項目、寫提示、set 頻率，run 出結果就入 Triage 收件箱，冇結果就自動歸檔。OpenAI 內部用佢做日常 issue 分類、總結 CI 失敗、寫 commit 簡報、捉上星期引入嘅 bug。
Claude Code 透過 /loop、cron 任務、hooks 同 GitHub Actions 實現同樣嘅嘢。/goal 仲犀利——你寫一個條件（例如「test/auth 下面所有測試通過而且 lint 乾淨」），佢一路 run 到條件滿足先停，而且每次疊代由一個獨立嘅細模型判斷係咪完成，唔係寫 code 嗰個自己打分。
2. 工作樹（Worktrees）——並行唔打架
同時 run 多個 Agent 嗰陣，檔案衝突係最大嘅坑。兩個 Agent 寫同一個檔案，同兩個工程師改同一行 code 冇分別。
git worktree 解決呢個問題——每個 Agent 自己有獨立嘅工作目錄，共享同一個 repository 歷史，但係編輯互相唔幹擾。Codex 內置支援，Claude Code 用 --worktree 標誌或 isolation: worktree 設定來實現。
但 Osmani 提醒：工具解決咗機械衝突，你先係真正嘅瓶頸——你嘅審查 bandwidth 決定咗可以並行 run 幾多個，唔係工具。
3. 技能（Skills）——唔使每次都由頭解釋個 project
每次新對話都要重新解釋 project 嘅 context，好似金魚噉。Skill 就係做呢樣嘢嘅。
格式好簡單：一個 folder，裏面放 SKILL.md 描述指令同 metadata，再加可選 script、參考檔案、資源。Codex 用 $ 或 /skills 調用，Claude Code 都係一樣。
Osmani 之前提過「意圖債務」（intent debt）——Agent 每次啟動都係 cold start，你嘅意圖有窿佢就會自信噉估。Skill 就係將意圖寫喺出面，寫一次，每次運行都讀到。冇 Skill，循環每次由零推導成個 project；有咗 Skill，知識就會累積。
4. 插件同連接器（Plugins & Connectors）——接觸真實工具
淨係睇到檔案系統嘅循環係弱雞嘅。基於 MCP 嘅連接器令 Agent 讀 issue tracker、查 database、call staging API、向 Slack 發消息。
Codex 同 Claude Code 都支援 MCP，所以俾一個寫嘅連接器通常另一個都用得。插件將連接器同技能打包，隊友一次安裝就可以用你成 set 配置。
呢樣決定咗 Agent 係講「呢個修復方案」，定係自己開 PR、關聯 Linear 工單、CI 綠咗之後自動喺頻道入面 @人。
5. 子 Agent（Sub-agents）——將寫 code 同檢查嘅分開
循環入面最有價值嘅結構設計。寫 code 嘅模型幫自己打分太寬鬆喇。第二個 Agent 用唔同嘅指令、甚至唔同嘅模型，嚟捉第一個自己呃自己嘅地方。
Codex 用 .codex/agents/ 下面嘅 TOML 檔案定義子 Agent，可以指定模型同推理強度。Claude Code 用 .claude/agents/ 同 agent teams。
通常嘅分工：一個探索，一個實現，一個對照規範去驗證。喺無人睇住嘅循環入面，一個你信得過嘅驗證者係你敢走開嘅唯一理由。
+1. 狀態（State）——第六樣嘢
一個 Markdown 檔案，或者 Linear 睇板——任何存在單次對話之外嘅嘢，記錄做咗啲乜、下一步做咩。
聽落太簡單喇，但每個長期運行嘅 Agent 都依賴呢個技巧。模型喺兩次運行之間會忘記曬所有嘢，所以狀態必須存在磁碟上面，而唔係 context 入面。 Agent 會唔記得，repository 唔會。
一個循環係點樣
Osmani 分享咗一個佢成日用嘅模式：
每日朝早自動化 run 一次。提示詞 call 一個 triage skill，讀取尋日嘅 CI 失敗、開咗嘅 issue、最近嘅 commit，將發現寫入 Markdown 或 Linear。每個值得做嘅發現，開一個獨立嘅工作樹，派子 Agent 起草修復，第二個子 Agent 對照 project skills 同現有測試審查。連接器令循環自己開 PR、更新工單。循環處理唔到嘅，入 Triage 收件箱等你。
你只係設計咗一次。你冇手動提示任何一步。
循環解決唔到嘅事
Osmani 好清醒噉列出咗三個會變得更尖鋭嘅問題：
驗證仲係你嘅責任。 無人睇住嘅循環都係無人睇住噉犯錯。將驗證者從寫 code 嘅分開只係令「做完了」更有意義少少，但「做完了」係聲稱，唔係證明。
你嘅理解能力會退化。 循環越快咁產出你冇寫嘅 code，你實際理解嘅嘢同 codebase 之間嘅差距就越大。呢個係「理解債務」（comprehension debt），順暢嘅循環只會令佢增長得更快——除非你讀循環產出嘅嘢。
認知投降。 循環自己 run 嗰陣，好容易停止有自己嘅判斷，攞咩就係咩。設計循環，如果你帶住判斷力去做，佢係解藥；如果你用佢嚟逃避思考，佢係催化劑。
小結呢篇文章最有價值嘅部分唔係嗰五個構建組件——呢啲嘢文件入面都有。佢真正點破嘅係：槓桿點已經移動咗喇。
Bcherny 話「我唔再提示 Claude 喇，我寫循環」，唔係話工作變輕鬆咗，係話發力點變咗。兩個唔同嘅人搭出完全一樣嘅循環，結果可能完全相反。一個用佢加速自己深度理解嘅工作，另一個用佢逃避理解工作本身。循環唔知分別。你知道。
呢個就係點解循環設計比提示工程更難，而唔係更容易。
最後 Osmani 嘅結語好節制，我直接引用：
Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.（設計循環。但要好似一個打算繼續做工程師嘅人噉去設計，而唔係一個淨係負責撳掣嘅人。）
附：關於 token 成本，之前文章已經有爭議，呢個係模型廠商為咗賣 token 融資上市造勢！
有人話「呢個係令錢從你户口度流出去嘅好方法」，有人話「有無限 token 嘅人教大家搞循環，其他人俾 Pro 計劃嘅週限額逼到要用 API」。Osmani 承認自己都係有限計劃用戶，話需要現實啲：循環能夠推到幾遠，取決於你嘅 token 預算。
關注公眾號回覆「入羣」入羣討論。
Addy Osmani 發了一篇長文，講的是一個新名詞：Loop Engineering。他指出一個正在從"寫提示詞"轉向"設計循環系統"的趨勢。
"你不應該再手動給編程 Agent 寫提示詞了。你應該設計一個循環，讓循環去提示 Agent。"
在此之前boris就表達過這樣的觀點：Claude Code 作者Boris：我已經不寫 prompt 了，我寫 loop
今天這篇文章更系統的介紹了這一觀點。
之前和現在
過去兩年，你用編程 Agent 的方式很簡單：寫一條好提示，塞夠上下文，等它輸出，你再寫下一條。Agent 是工具，你全程握着它，一輪接一輪。
現在不一樣了。你構建一個小系統——它自己找活幹、分配任務、檢查結果、記錄進度、決定下一步。你不再親自戳 Agent，系統替你做這件事。
Osmani 把這件事分成 五個構建塊 + 一個記憶層。有意思的是，Codex 和 Claude Code 現在都支持這全部六樣東西，只是名字不同。
五個構建塊
1. 自動化（Automations）——心跳
讓循環真正循環起來的東西。不是跑一次就完事，而是按計劃自動執行。
Codex 的 Automations tab 裏，你選項目、寫提示、設頻率，跑出結果進 Triage 收件箱，沒結果自動歸檔。OpenAI 內部用它做日常 issue 分類、彙總 CI 失敗、寫 commit 簡報、抓上週引入的 bug。
Claude Code 通過 /loop、cron 任務、hooks 和 GitHub Actions 實現同樣的事。/goal 更狠——你寫一個條件（比如"test/auth 下所有測試通過且 lint 乾淨"），它一直跑到條件滿足才停，而且每次迭代由一個獨立的小模型判斷是否完成，不是寫代碼的那個自己打分。
2. 工作樹（Worktrees）——並行不打架
同時跑多個 Agent 時，文件衝突是最大的坑。兩個 Agent 寫同一個文件，跟兩個工程師改同一行代碼沒區別。
git worktree 解決這個問題——每個 Agent 有自己的獨立工作目錄，共享同一個倉庫歷史，但編輯互不干擾。Codex 內建支持，Claude Code 用 --worktree 標誌或 isolation: worktree 配置實現。
但 Osmani 提醒：工具解決了機械衝突，你才是真正的瓶頸——你的審查帶寬決定了能並行跑多少個，不是工具。
3. 技能（Skills）——不用每次都從頭解釋項目
每次新會話都要重新解釋項目上下文，像金魚一樣。Skill 就是幹這個的。
格式很簡單：一個文件夾，裏面放 SKILL.md 描述指令和元數據，再加可選腳本、參考文件、資源。Codex 用 $ 或 /skills 調用，Claude Code 也一樣。
Osmani 之前提過"意圖債務"（intent debt）——Agent 每次啓動都是冷啓動，你的意圖有漏洞它就自信地猜。Skill 就是把意圖寫在外面，寫一次，每次運行都讀到。沒有 Skill，循環每次從零推導整個項目；有了 Skill，知識會累積。
4. 插件和連接器（Plugins & Connectors）——觸達真實工具
只能看文件系統的循環是弱小的。基於 MCP 的連接器讓 Agent 讀 issue 跟蹤器、查數據庫、調 staging API、往 Slack 發消息。
Codex 和 Claude Code 都支持 MCP，所以給一個寫的連接器通常另一個也能用。插件把連接器和技能打包，隊友一次安裝就能用上你整套配置。
這決定了 Agent 是說"這是修復方案"，還是自己開 PR、關聯 Linear 工單、CI 綠了自動在頻道里@人。
5. 子 Agent（Sub-agents）——寫代碼的和檢查的分開
循環裏最有價值的結構設計。寫代碼的模型給自己打分太寬容了。第二個 Agent 用不同的指令、甚至不同的模型，來抓第一個自己騙過自己的地方。
Codex 用 .codex/agents/ 下的 TOML 文件定義子 Agent，可以指定模型和推理強度。Claude Code 用 .claude/agents/ 和 agent teams。
通常的分工：一個探索，一個實現，一個對照規範驗證。在無人值守的循環裏，一個你信得過的驗證者是你敢走開的唯一理由。
+1. 狀態（State）——第六樣東西
一個 Markdown 文件，或者 Linear 看板——任何活在單次對話之外的東西，記錄做了什麼、下一步做什麼。
聽起來太簡單了，但每個長期運行的 Agent 都依賴這個技巧。模型在兩次運行之間會忘記一切，所以狀態必須存在磁盤上，而不是上下文裏。 Agent 會忘，倉庫不會。
一個循環長什麼樣
Osmani 分享了一個他常用的模式：
每天早上自動化跑一次。提示詞調用一個 triage skill，讀取昨天的 CI 失敗、打開的 issue、最近的 commit，把發現寫進 Markdown 或 Linear。每個值得做的發現，開一個獨立的工作樹，派子 Agent 起草修復，第二個子 Agent 對照項目 skills 和現有測試審查。連接器讓循環自己開 PR、更新工單。循環處理不了的，進 Triage 收件箱等你。
你只設計了一次。你沒有手動提示任何一步。
循環解決不了的事
Osmani 很清醒地列出了三個會變得更尖鋭的問題：
驗證還是你的責任。 無人值守的循環也是無人值守地犯錯。把驗證者從寫代碼的分開只是讓"做完了"更有意義一點，但"做完了"是聲稱，不是證明。
你的理解會退化。 循環越快地產出你沒寫的代碼，你實際理解的東西和代碼庫之間的差距就越大。這是"理解債務"（comprehension debt），順暢的循環只會讓它增長更快——除非你讀循環產出的東西。
認知投降。 循環自己跑的時候，很容易停止有自己的判斷，拿什麼是什麼。設計循環，如果你帶着判斷力去做，它是解藥；如果你用它來逃避思考，它是催化劑。
小結這篇文章最有價值的部分不是那五個構建塊——這些東西文檔裏都有。它真正點破的是：槓桿點已經移動了。
Bcherny 說"我不再提示 Claude 了，我寫循環"，不是說工作變輕鬆了，是說發力點變了。兩個不同的人搭出完全一樣的循環，結果可能完全相反。一個用它加速自己深度理解的工作，另一個用它逃避理解工作本身。循環不知道區別。你知道。
這就是為什麼循環設計比提示工程更難，而不是更容易。
最後 Osmani 的結語很剋制，我直接引用：
Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.（設計循環。但要像一個打算繼續當工程師的人那樣去設計，而不是一個只負責按按鈕的人。）
附：關於 token 成本，之前文章就有爭議，這是模型廠商為了賣token融資上市造勢！
有人說"這是讓錢從你賬户裏流出去的好方法"，有人說"有無限 token 的人教大家搞循環，其他人被 Pro 計劃的周限額逼到用 API"。Osmani 承認自己也是有限計劃用戶，說需要現實一點：循環能推多遠，取決於你的 token 預算。
關注公眾號回覆“進羣”入羣討論。