Harness 之後，硅谷 AI 圈又來新詞了：Loop Engineering
整理版優先睇
Loop Engineering：唔好再手動提示 AI，設計系統等佢自己循環做事
呢篇文係由 Google Cloud AI 總監 Addy Osmani 寫嘅，佢觀察到矽谷 AI 圈出現咗個新概念叫「Loop Engineering」，意思係唔再靠人手逐下提示 coding agent，而係設計一套自動化系統，等 agent 自己循環發掘任務、分配、檢查結果、記錄狀態同決定下一步。作者引述咗 Peter Steinberger 同 Claude Code 負責人 Boris Cherny 嘅講法，仲詳細拆解咗一個完整 loop 需要嘅五個核心模塊（Automations、Worktrees、Skills、Plugins/Connectors、Sub-agents）同記憶系統，並用 Codex 同 Claude Code 做例子，展示呢兩個工具點樣實現同樣嘅概念。
作者嘅整體結論係：Loop Engineering 係未來同編碼智能體協作嘅雛形，但 token 成本係現實問題，而且工程師仍然要承擔驗證責任，唔可以完全放手。佢強調「Build the loop. Stay the engineer.」，即係設計 loop 可以幫你放大能力，但如果用嚟逃避思考，就會令產品質量下滑同產生「理解債」。佢提醒設計 loop 比 prompt engineering 更難，因為槓桿點由寫提示詞變咗做設計系統，但工程師嘅判斷力先係關鍵。
文章仲提到 loop 嘅狀態文件、sub-agent 分工（生成者同檢查者…
- Loop Engineering 核心：設計自動化系統代替人手提示 agent，由系統循環管理任務、執行同檢查。
- 一個 loop 必需五個模塊：Automations（定時觸發）、Worktrees（並行隔離）、Skills（項目知識固化）、Plugins/Connectors（連接工具）、Sub-agents（生成同檢查分開）。
- 記憶必須放喺磁盤（如 Markdown 文件），唔好依賴上下文，因為 agent 每次運行都會忘記。
- Sub-agents 係最有用嘅設計：寫 code 同檢查 code 分開用唔同模型，避免 agent 對自己太好說話，特別係 loop 無人睇住嘅時候。
- 工程師要帶判斷設計 loop，唔好認知投降；要親自 review 生成嘅 code，否則會累積理解債同令產品質量下滑。
咩係 Loop Engineering？點解突然彈起？
Loop Engineering 唔係新工具，而係一種新思維：唔好再逐下逐下手動提示 coding agent，改為設計一套系統，等系統自己去觸發、管理同完成任務。Peter Steinberger 帶起咗呢個討論，話唔應該再手動提示編碼智能體。Claude Code 負責人 Boris Cherny 亦講佢而家係寫 loop 嚟提示 Claude，唔係自己打字。
Loop Engineering 用你設計嘅系統去替代你自己 prompt agent
呢個 loop 其實係一個遞歸目標：你定義一個目的，AI 反覆迭代直到完成。作者話呢樣嘢可能係未來同編碼智能體協作嘅雛形，但 token 成本同質量保證仲係好大嘅挑戰，所以佢自己都保持懷疑。
一個完整 Loop 需要五個模塊 + 記憶
一個 loop 要有五樣嘢，外加一個記憶地方，先至算係真正自我驅動。Codex 同 Claude Code 雖然叫法唔同，但能力係一樣嘅。
- Automations：loop 嘅心跳，按計劃自動觸發，獨立完成發現同分類（triage）。例如每日自動分類 issues、彙總 CI 失敗、寫 commit 簡報。
- Worktrees：令並行執行嘅多個 agent 唔會互相干擾。依靠 git worktree 做到隔離，每個 agent 各自用獨立 checkout。
- Skills：將項目知識寫入 SKILL.md，避免每次開新會話都要從頭解釋。Skills 係編寫格式，plugin 係發佈方式。
- Plugins 同 Connectors：基於 MCP 連接實際工具，例如 issue tracker、數據庫、Slack，令 loop 做到真正嘅操作，唔係淨係講「如果我可以……」
- Sub-agents：將寫 code 同檢查 code 分開，由另一個模型（或同一模型但唔同 instruction）負責驗證，避免生成者對自己太好說話。
第六樣係 memory，可以係一個 Markdown 文件或者 Linear 看板，記錄已完成同下一步要做嘅事。因為模型每次運行之間會忘記一切，記憶必須放喺磁盤，唔好靠上下文。
智能體會忘，但代碼倉庫唔會
作者特別提到子 agent 燒 token 多，所以要揀值得把關嘅地方先用，而 /goal 呢個 in-session primitive 背後嘅邏輯都係一樣：由一個獨立小模型決定 loop 係咪完成，唔係做緊工作嗰個模型。
完整 Loop 係點樣行嘅？一個日常例子
以下係作者自己用緊嘅形態：每個早上，一個 automation 自動喺倉庫上跑，triage skill 讀取 CI 失敗、open issues、最近 commits，將結果寫入 Markdown 或 Linear。
Automation 發現值得處理嘅嘢，就開隔離 worktree，派 sub-agent 起草修復方案
然後第二個 sub-agent 對照項目 skills 同現有測試審查草案，connectors 令 loop 自己開 PR、更新 ticket。處理唔到嘅就落入 triage 收件箱等作者睇。狀態文件係串起成個系統嘅線，記低嘗試過咩、通過咩、仲有咩未做，所以第二朝會喺今日停低嘅位繼續。
你只設計咗一次，冇手動提示任何一個步驟
## Triage Results (2025-04-10)
- CI failure in tests/auth: file locking issue (agent-1 working)
- Open issue #42: memory leak in cache (agent-2 pending review)
- Recent commit: added rate limiting (already verified, no action needed)
## Active Worktrees
- agent-1: fix-auth-lock (branch: fix/auth-lock)
- agent-2: fix-memory-leak (branch: fix/mem-leak, review pending)Loop 走得再順，都離唔開人
Loop 改變咗工作形態，但冇令你變得多餘。反而有三個問題會隨住 loop 變好而尖鋭：驗證仍然係你嘅責任，無人值守運行嘅 loop 亦係無人值守犯錯嘅 loop。
作者叫呢個做「認知投降」。設計 loop 可以係解藥，亦都可以係加速劑，關鍵係你帶住判斷去設計，定係用佢嚟逃避思考。
Build the loop. Stay the engineer.
佢提醒：兩個人可以搭一模一樣嘅 loop，一個人用嚟加速自己深刻理解嘅工作，另一個人用嚟逃避理解工作本身。Loop 唔知呢個分別，但你知道。所以設計 loop 難過 prompt engineering，唔係更容易。
矽谷 AI 圈又嚟咗個新詞：Loop Engineering。
大佬們紛紛表態，唔好再手動驗證同寫提示詞啦，應該俾 Agent 自己循環完成工作。
OpenClaw 開發者 Peter Steinberger 帶起咗呢個討論，Claude Code 負責人 Boris Cherny 都話佢已經唔多喺 Claude Code 度輸入提示詞，而係寫 loops。
仲有 Karpathy 嘅 AutoResearch 項目：令自己唔再成為瓶頸，將自己抽離出嚟。安排好一切，令佢哋完全自主運行，而且你越瞭解點樣最大化 Token 吞吐量而又唔身處循環之中，就越好。
Loop Engineering 嘅核心係，唔使人手再去提示 Coding agent，直接設計一套系統，等系統自動去觸發同管理 agent。呢套系統能夠自動發現任務、分配任務、檢查結果、記錄狀態、決定下一步。
當然，前提係你嘅 token 夠燒。Richard Sutton 有個精簡版嘅苦澀教訓，如果換成 Agent 嘅版本，倒係同 Loop Engineering 嘅理念一致。
唔好再咩事都自己上手解決。專注喺啲可以透過更多智能體實現擴展嘅系統，例如目標設定同編排，將一個人嘅能力擴展成一班 Agent 嘅執行力。
Google Cloud AI 總監、工程師大佬 Addy Osmani 寫咗篇文章，詳細拆解咗 Loop Engineering 係咩、一個完整 loop 需要嘅核心模塊，同埋喺 Claude Code 同 Codex 入面係點樣實現，值得當科普睇下。
⬆️關注 Founder Park，最及時最乾貨嘅創業分享
如果你正在做面向全球市場嘅 AI 產品，歡迎報名。
01
點解會出現 Loop Engineering？
Loop Engineering，就係用你設計嘅系統嚟代替你自己去 prompt agent。
呢度嘅 loop 可以理解為一個遞歸目標：你定義一個目的，AI 反覆迭代直到完成。佢大概由五個基本模塊構成，Claude Code 同 Codex 而家都已經具備咗。
我認為呢個可能係我哋未來同編碼智能體協作方式嘅雛形。不過而家仲早，我自己都保持懷疑，因為 token 成本係一個必須認真對待嘅問題，使用模式因人而異，差別可以好大。同時你仍然需要某種方式保證質量唔下滑，關於代碼越來越 slop 嘅擔憂都合理。雖然咁講，都好值得好好傾下 Loop Engineering 究竟係點回事。
Peter Steinberger 最近話過：「你唔應該再去手動提示編碼智能體。你應該設計令智能體自動運行嘅 loop。」
Anthropic Claude Code 負責人 Boris Cherny 都話：「我唔再手動提示 Claude 啦。我有 loop 喺度跑，佢哋負責提示 Claude、決定下一步做咩。我嘅工作係寫 loop。」
咁呢啲說話到底係咩意思？
過去大概兩年，你從編碼智能體度「拎到嘢」嘅方式，就係寫一個好嘅提示詞，然後提供足夠嘅上下文。你輸入一段話，讀佢返回嘅內容，再輸入下一段話。智能體係一個工具，你全程控制住佢，一輪接一輪。
但係呢種方式某程度上已經過去咗，或者話，至少有一批人認為佢要過去了。
而家，你構建一個小型系統，等佢自己去發現任務、分配任務、檢查任務、記錄完成情況、決定下一步，然後等呢個系統去觸發智能體。你唔使自己觸發智能體，等呢個系統嚟做呢件事。
我之前寫過同呢個相近嘅兩個概念：agent harness engineering（為單個智能體構建運行環境）同 factory model（構建軟件嘅系統）。Loop engineering 就喺 harness 嘅上一層，佢係一個跑喺計時器上、識得自己生成小助手、而且能夠自我驅動嘅 harness。
令我意外嘅係，呢件事已經唔再係工具層面嘅問題。一年前，如果你想跑一個 loop，你要自己寫一堆 bash 腳本，然後永遠維護嗰堆腳本，佢只屬於你一個人。而家呢啲模塊已經直接內置喺產品裏面。Steinberger 列出嘅清單同 Codex 應用幾乎一一對應，同 Claude Code 都幾乎完全一樣。
一旦你意識到兩者嘅結構係相同，你就唔會再糾結用邊個工具，你只需要設計一個喺任何工具入面都跑得起嘅 loop。
02
一個 Loop，
需要五個模塊+memory
一個 loop 需要五樣嘢，外加一個記憶嘅地方：
Automations：按計劃自動觸發，獨立完成發現同分類（triage）工作
Worktrees：等並行運行嘅多個智能體互不幹擾
Skills：將項目知識寫低，令智能體唔使每次都靠估
Plugins 同 Connectors：將智能體接入你已經用緊嘅工具
Sub-agents：一個負責生成，另一個負責檢查
第六樣嘢係 memory。一個 Markdown 文件，或者一塊 Linear 看板，任何能夠活在單次對話之外、記錄「已完成咗咩」同「下一步係咩」嘅地方都得。聽起嚟簡單得唔似真嘅，但呢個係所有長時間運行嘅智能體都依賴嘅同一個技巧。我喺《long-running agents》入面專門寫過：模型喺每次運行之間會忘掉一切，所以記憶必須存在磁盤上，而唔係喺上下文裏面。智能體會忘，但代碼倉庫唔會。
Claude Code 同 Codex 而家都具備咗呢五個模塊。
個名喺兩個產品入面略有唔同，但能力係同一回事。我想逐一講清楚，因為細節決定一個 loop 到底能否跑得好，處理唔好，佢就會喺你唔覺意嘅地方靜靜雞出問題。
Automations：loop 嘅心跳
Automations，係令 loop 成為真正嘅 loop、唔只係你手動跑咗一次嘅嘢。
喺 Codex 應用入面，你喺 Automations 標籤頁創建一個 automation，選擇項目、要運行嘅提示詞、運行頻率，同埋係本地 checkout 上跑定係後台 worktree 上跑。有發現嘅運行會入 Triage 收件箱，乜都發現唔到嘅運行會自動歸檔，呢個設計好貼心。
OpenAI 內部用佢嚟處理一啲沉悶嘅日常任務，例如每日 issue 分類、彙總 CI 失敗、寫 commit 簡報、排查上週某人引入嘅 bug。Automation 仲可以調用 skill，咁你嘅定期任務就能夠保持可維護性，用 skill-name 觸發，唔使將一大堆指令粘貼入一個冇人會去更新嘅定時任務度。
Claude Code 用另一種方式實現咗同樣嘅效果，透過 scheduling 同 hooks。你可以用 /loop 按間隔運行一個提示詞或命令，可以安排 cron 任務，可以用 hooks 喺智能體生命週期嘅特定節點觸發 shell 命令，或者直接推到 GitHub Actions 上，咁熄咗電腦佢都照樣跑。
核心思路完全一樣：定義一個自主任務，俾佢一個節奏，發現結果會主動嚟揾你，你唔使四圍去查。
仲有一個值得了解嘅「in-session primitive」，佢更接近呢篇文章真正想講嘅嘢。/loop 按節奏重複運行；/goal 就會持續運行，直到你寫低嘅條件真係成立，每一輪結束之後，一個獨立嘅小模型會檢查係咪已經完成，所以寫代碼嘅智能體唔係畀自己打分嗰個。你俾佢一個條件，例如「test/auth 入面所有測試通過，lint 都乾淨」，然後行開。Codex 入面有同樣嘅嘢，都叫 /goal，佢會跨輪次持續工作直到可驗證嘅停止條件成立，支援暫停、恢復同清除。
同一個原語，兩個工具都有，呢個其實係貫穿呢篇文章嘅整體規律。
呢一層嘅作用係將任務浮出水面，loop 嘅其餘部分負責對呢啲任務採取行動。
Worktrees：令並行唔變成一團亂麻
一旦你同時跑超過一個智能體嗰陣，文件就會開始互相衝突，呢個就係失敗嘅來源。兩個智能體同時寫同一個文件，同兩個工程師冇溝通就提交同一行代碼，係完全一樣嘅麻煩。
git worktree 解決咗呢個問題：佢係一個獨立嘅工作目錄，跑喺自己嘅分支上，但共享同一個倉庫歷史，所以一個智能體嘅改動從物理上就冇可能撞到另一個智能體嘅 checkout。
Codex 直接內置咗 worktree 支援，多個線程可以同時存取同一個倉庫互不幹擾。Claude Code 用 git worktree、--worktree flag（喺獨立 checkout 入面打開一個會話）、同 isolation: worktree 設定（俾 subagent 用，令每個助手都有一個用完自動清理嘅全新 checkout）嚟實現同樣嘅隔離。
我喺《orchestration tax》入面寫過呢件事嘅另一面：worktrees 消除咗機械層面嘅衝突，但你仍然係嗰個瓶頸，你一日能夠認真 review 幾多份產出，先係你實際可以跑幾多個 agent 嘅上限，唔係工具。
Skills：令智能體唔使每次都靠估
一個 skill，就係令你唔使每次開新會話都從頭解釋一次項目係點回事嘅方式。
兩個工具嘅格式相同：一個文件夾，入面有一個 SKILL.md，包含指令同元數據，加上可選嘅腳本、引用同資源文件。Codex 喺你用 $ 或 /skills 調用嗰陣運行 skill，或者喺任務描述同 skill 描述匹配嗰陣自動觸發。呢個就係點解一個簡潔、冇聊嘅描述比一個聰明嘅描述更好用。Claude Code 嘅做法完全一樣，我喺《agent skills》入面寫過呢個模式。
Skills 都係令 intent 唔再反覆付出成本嘅地方。我喺《intent debt》入面話過：智能體每次會話都係從零開始嘅，你冇講清楚嘅地方，佢會用一個「自信嘅猜測」嚟填上。一個 skill，就係將呢啲意圖寫喺外面，約定、構建步驟、「我哋唔咁做係因為嗰次事故」，寫一次，智能體每次運行都讀到。冇 skills，loop 每個週期都要從零推導你嘅整個項目；有咗 skills，佢就會複利增長。
有一點需要搞清楚：skill 係編寫格式，plugin 係發佈方式。當你想跨多個倉庫共享一個 skill，或者將幾個 skill 打包一齊，你就將佢哋打包成一個 plugin。Codex 同 Claude Code 都係咁。
Plugins 同 Connectors：令 loop 觸及真喺度用嘅工具
一個淨係睇到文件系統嘅 loop，係一個好細嘅 loop。
Connectors 基於 MCP 構建，令智能體能夠讀取你嘅 issue tracker、查詢數據庫、存取 staging API、喺 Slack 入面發消息。Codex 同 Claude Code 都支援 MCP，所以你為一個工具寫嘅 connector 通常喺另一個入面都可以直接用。Plugins 就將 connectors 同 skills 打包一齊，令你嘅隊友一鍵安裝你嘅成套配置，唔使從記憶度重新拼一次。
有咗 Connectors，loop 先可以真正喺你嘅實際環境入面做嘢，唔係齋同你講「如果我可以操作嘅話我會咁做」。呢個就係一個話「呢個係修復方案」嘅智能體同一個自己開 PR、關聯 Linear ticket、等 CI 變綠後自動 ping 頻道嘅 loop 之間嘅區別。
Sub-agents：令生成者同檢查者分開
loop 入面最有用嘅結構設計，冇之一，就係將寫代碼同檢查代碼嘅拆開。
等寫代碼嘅模型嚟評審自己嘅代碼，佢會對自己太好說話。一個揸住唔同指令、有時甚至係唔同模型嘅第二個智能體，能夠捉到第一個模型自己冇意識到、或者選擇忽略嘅問題。
Codex 只係你要求嗰陣先會生成 subagents，同時運行，然後將結果合併成一個答案。你喺 .codex/agents/ 入面用 TOML 文件定義自己嘅 agents，每個有名、描述、指令，同可選嘅模型同推理力度，你嘅安全審查員可以係一個高力度嘅強模型，而你嘅探索者可以係某個快速嘅唯讀工具。Claude Code 喺 .claude/agents/ 入面用 subagents 同 agent teams 做同樣嘅事，任務喺佢哋之間傳遞。兩個工具入面常見嘅分工都係：一個 agent 探索，一個實現，一個對照規格驗證。
我之前寫過兩次呢個邏輯，一次係《code agent orchestra》，一次係《adversarial code review》。佢喺 loop 入面之所以特別重要，係因為 loop 喺你唔睇住嗰陣跑，所以一個你真係信得過嘅驗證者，係你敢行開嘅唯一理由。
Sub-agents 的確會燒更多 token，因為每一個都要做自己嘅模型同工具調用。所以唔好周圍用，只有真係需要有人幫你再把多次關嘅地方先值得開。呢個其實都係 Claude Code 嘅 /goal 背後嘅邏輯：決定 loop 有冇完成嘅，應該係一個全新嘅模型，而唔係嗰個做咗呢啲工作嘅模型，生成者同檢查者分開呢件事，喺呢度被用咗喺「使唔使停」呢個判斷本身。
03
完整嘅 Loop 長成點樣？
將呢啲拼埋一齊，一個單線程就變成咗一個小型控制枱。以下係我一直用緊嘅一種形態：
每日朝早，一個 automation 喺倉庫上跑起嚟。佢嘅提示詞調用一個 triage skill，讀取尋日嘅 CI 失敗、open issues、最近嘅 commits，然後將發現結果寫入一個 Markdown 文件或 Linear 看板。對於每個值得處理嘅發現，loop 會開一個隔離嘅 worktree，派一個 sub-agent 去起草修復方案，再派第二個 sub-agent 對照項目 skills 同現有測試嚟審查呢份草案。
Connectors 令 loop 自己開 PR、更新 ticket。loop 處理唔到嘅嘢，落進 triage 收件箱等我睇。狀態文件（state file）係將成個系統串起嚟嗰條線，佢記得嘗試過咩、通過咗咩、仲有咩懸而未決，所以聽日朝早嘅運行會由今日停低嘅地方繼續。
睇下你實際做咗咩：你只設計咗一次，你冇手動提示任何一個步驟。呢個就係 Steinberger 嗰句話真正變成現實嘅樣，而且佢喺 Codex 入面同喺 Claude Code 入面係同一個 loop，因為兩邊嘅模塊係同樣嘅模塊。
04
Loop 仍然離唔開人
Loop 改變咗工作嘅形態，但佢冇令你變得冇用。隨住 loop 越來越好，有三個問題反而會變得更尖鋭：
驗證仍然係你嘅責任。一個無人值守運行嘅 loop，同時亦係一個無人值守犯錯嘅 loop。將驗證 sub-agent 同生成者拆開，係為咗令 loop 嘅「完成咗」呢個判斷有啲意義。即使係咁，「完成咗」都只係一個聲明，唔係證明。我一直重複同一句話：你嘅工作係發佈你親自確認過能夠運行嘅代碼。
如果你放任唔理，你對代碼庫嘅理解會腐爛。loop 跑得越快、產出越多，你冇親手寫過嘅代碼就越堆越多，實際存在嘅嘢同你真係理解嘅嘢之間嘅差距就越大。呢個就係理解債，跑得越順嘅 loop，只會令呢個差距增長得越快。唯一嘅解法係你真係去讀 loop 生成嘅嘢。
最舒服嘅姿勢，好可能係最危險嘅。當 loop 自己跑起嚟，你好容易停止發表意見，直接接受佢畀你嘅任何嘢。我將呢個叫做認知投降。設計 loop 係解藥，亦都可以係加速劑，帶住判斷去設計佢，佢係解藥；用佢嚟逃避思考，佢係加速劑。同一個動作，完全相反嘅結果。
05
工程師要帶住判斷去設計 Loop
Build the loop. Stay the engineer. 我認為呢個係我哋工作方式演進嘅一個預演。但話說回頭，如果我自己唔親自 review 代碼，或者完全依賴自動化 loop 嚟修復問題，產品質量就會下滑，好可能陷入一個越挖越深嘅惡性循環。
所以，去搭建你嘅 loop，但唔好忘記直接提示智能體仍然有效，關鍵係要揾到正確嘅平衡。
Loop 亦會因人而異，產生完全唔同嘅結果。兩個人可以搭出完全一樣嘅 loop，卻得到截然相反嘅結果。一個人用佢嚟喺自己深刻理解嘅工作上跑得更快；另一個人用佢嚟逃避理解工作本身。Loop 唔知呢兩者嘅分別，但你知道。
呢個就係點解設計 loop 比提示詞工程更難，唔係更容易。Cherny 講嗰句說話，唔係話工作變簡單咗，而係話槓桿點移動咗。
Build the loop，但要好似一個打算留喺工程師位置、唔只係「撳啟動掣嘅人」咁去 build 佢。
原文：https://x.com/addyosmani/status/2064127981161959567
Sarah Guo：能夠俾 Benchmark 衡量嘅工作，都唔應該係你嘅創業方向
轉載原創文章請加微信：founderparker
硅谷 AI 圈又來了個新詞：Loop Engineering。
大佬們紛紛表態，別再手動驗證和寫提示詞了，該讓 Agent 自己循環完成工作了。
OpenClaw 開發者 Peter Steinberger 帶火了這個討論，Claude Code 負責人 Boris Cherny 也說他已經不怎麼在 Claude Code 裏輸入提示詞了，而是去寫 loops。
還有 Karpathy 的 AutoResearch 項目：讓自己不再成為瓶頸，把自己抽離出來。安排好一切，使它們完全自主運行，並且你越瞭解如何最大化 Token 吞吐量且不身處循環之中，就越好。
Loop Engineering 的核心是，不用人手動再去提示 Coding agent 了，直接設計一套系統，讓系統自動去觸發和管理 agent。這套系統能夠自動去發現任務、分配任務、檢查結果、記錄狀態、決定下一步。
當然，前提是你的 token 夠燒。Richard Sutton 有個精簡版的苦澀的教訓，如果換成 Agent 的版本，倒是跟 Loop Engineering 的理念一致了。
別再什麼事都自己上手解決。專注於那些能夠通過更多智能體實現擴展的系統，例如目標設定和編排，把一個人的能力擴展成一羣 Agent 的執行力。
Google Cloud Al 總監、工程師大佬 Addy Osmani 寫了一篇文章，詳細地拆解了 Loop Engineering 是什麼、一個完整 loop 所需要的核心模塊，以及在 Claude Code 和 Codex 裏是如何實現的，值得作為科普看下。
⬆️關注 Founder Park，最及時最乾貨的創業分享
如果你正在做面向全球市場的 AI 產品，歡迎報名。
01
為什麼會出現 Loop Engineering？
Loop Engineering，就是用你設計的系統來替代你自己去 prompt agent。
這裏的 loop 可以理解為一個遞歸目標：你定義一個目的，AI 反覆迭代直到完成。它大概由五個基本模塊構成，Claude Code 和 Codex 現在都已經具備了。
我認為這可能是我們未來與編碼智能體協作方式的雛形。不過現在還早，我自己也保持懷疑，因為 token 成本是個必須認真對待的問題，使用模式因人而異，差別可以非常大。同時你仍然需要某種方式保證質量不下滑，關於代碼越來越 slop 的擔憂也是合理的。雖然這樣說，還是很值得好好聊聊 Loop Engineering 究竟是怎麼回事。
Peter Steinberger 最近說過：「你不應該再去手動提示編碼智能體了。你應該設計讓智能體自動運行的 loop。」
Anthropic Claude Code 負責人 Boris Cherny 也說：「我不再手動提示 Claude 了。我有 loop 在跑，它們負責提示 Claude、決定下一步做什麼。我的工作是寫 loop。」
那這些話到底是什麼意思？
過去大概兩年，你從編碼智能體那裏「拿到東西」的方式，就是寫一個好的提示詞，然後提供足夠的上下文。你輸入一段話，讀它返回的內容，再輸入下一段話。智能體是一個工具，你全程控制着它，一輪接一輪。
但這種方式某種程度上已經過去了，或者說，至少有一批人認為它要過去了。
現在，你構建一個小型系統，讓它自己去發現任務、分配任務、檢查任務、記錄完成情況、決定下一步，然後讓這個系統去觸發智能體。你不用親自去觸發智能體，讓這個系統來做這件事。
我之前寫過與此相近的兩個概念：agent harness engineering（為單個智能體構建運行環境）和 factory model（構建軟件的系統）。Loop engineering 就在 harness 的上一層，它是一個跑在計時器上、能自己生成小助手、並且能自我驅動的 harness。
讓我意外的是，這件事已經不再是工具層面的問題了。一年前，如果你想跑一個 loop，你得自己寫一堆 bash 腳本，然後永遠維護那堆腳本，它只屬於你一個人。現在這些模塊已經直接內置在產品裏了。Steinberger 列出的清單和 Codex 應用幾乎一一對應，和 Claude Code 也幾乎完全一樣。
一旦你意識到兩者的結構是相同的，你就不會再糾結用哪個工具了，你只需要設計一個在任何工具裏都能跑起來的 loop。
02
一個 Loop，
需要五個模塊+memory
一個 loop 需要五樣東西，外加一個記憶的地方：
Automations：按計劃自動觸發，獨立完成發現和分類（triage）工作
Worktrees：讓並行運行的多個智能體互不干擾
Skills：把項目知識寫下來，讓智能體不用每次都靠猜
Plugins 和 Connectors：把智能體接入你已經在用的工具
Sub-agents：一個負責生成，另一個負責檢查
第六樣東西是 memory。一個 Markdown 文件，或者一塊 Linear 看板，任何能活在單次對話之外、記錄「已完成什麼」和「下一步是什麼」的地方都行。聽起來簡單得不像話，但這是所有長時間運行的智能體都依賴的同一個技巧。我在《long-running agents》裏專門寫過：模型在每次運行之間會忘掉一切，所以記憶必須存在磁盤上，而不是在上下文裏。智能體會忘，但代碼倉庫不會。
Claude Code 和 Codex 現在都具備了這五個模塊。
名字在兩個產品裏略有不同，但能力是同一回事。我想逐一講清楚，因為細節決定一個 loop 到底能不能跑好，處理不好，它就會在你不注意的地方悄悄出問題。
Automations：loop 的心跳
Automations，是讓 loop 成為真正的 loop、不只是你手動跑了一次的東西。
在 Codex 應用裏，你在 Automations 標籤頁創建一個 automation，選擇項目、要運行的提示詞、運行頻率，以及是在本地 checkout 上跑還是在後台 worktree 上跑。有發現的運行會進入 Triage 收件箱，什麼都沒發現的運行會自動歸檔，這個設計很貼心。
OpenAI 內部用它來處理一些枯燥的日常任務，比如每日 issue 分類、彙總 CI 失敗、寫 commit 簡報、排查上週某人引入的 bug。Automation 還可以調用 skill，這樣你的定期任務就能保持可維護性，用 skill-name 觸發，不用把一大堆指令粘貼進一個沒人會去更新的定時任務裏。
Claude Code 用另一種方式實現了同樣的效果，通過 scheduling 和 hooks。你可以用 /loop 按間隔運行一個提示詞或命令，可以安排 cron 任務，可以用 hooks 在智能體生命週期的特定節點觸發 shell 命令，或者直接推到 GitHub Actions 上，這樣關掉電腦它也照樣跑。
核心思路完全一樣：定義一個自主任務，給它一個節奏，發現結果會主動來找你，你不用四處去查。
還有一個值得了解的「in-session primitive」，它更接近這篇文章真正想說的東西。/loop 按節奏重複運行；/goal 則會持續運行，直到你寫下的條件真正成立，每一輪結束後，一個獨立的小模型會檢查是否已經完成，所以寫代碼的智能體不是給自己打分的那個。你給它一個條件，比如「test/auth 裏所有測試通過，lint 也乾淨」，然後走開。Codex 裏有同樣的東西，也叫 /goal，它會跨輪次持續工作直到可驗證的停止條件成立，支持暫停、恢復和清除。
同一個原語，兩個工具都有，這其實是貫穿這篇文章的整體規律。
這一層的作用是把任務浮出水面，loop 的其餘部分負責對這些任務採取行動。
Worktrees：讓並行不變成一團亂麻
一旦你同時跑超過一個智能體時，文件就開始互相沖突了，這就是失敗的來源。兩個智能體同時寫同一個文件，和兩個工程師在沒溝通的情況下提交同一行代碼，是完全一樣的麻煩。
git worktree 解決了這個問題：它是一個獨立的工作目錄，跑在自己的分支上，但共享同一個倉庫歷史，所以一個智能體的改動從物理上就無法碰到另一個智能體的 checkout。
Codex 直接內置了 worktree 支持，多個線程可以同時訪問同一個倉庫互不干擾。Claude Code 用 git worktree、--worktree flag（在獨立 checkout 裏打開一個會話）、以及 isolation: worktree 設置（給 subagent 用，讓每個助手都有一個用完自動清理的全新 checkout）來實現同樣的隔離。
我在《orchestration tax》裏寫過這件事的另一面：worktrees 消除了機械層面的衝突，但你仍然是那個瓶頸，你一天能認真 review 多少份產出，才是你實際能跑多少個 agent 的上限，不是工具。
Skills：讓智能體不用每次都靠猜
一個 skill，就是讓你不用每次開新會話都從頭解釋一遍項目是怎麼回事的方式。
兩個工具的格式相同：一個文件夾，裏面有一個 SKILL.md，包含指令和元數據，加上可選的腳本、引用和資源文件。Codex 在你用 $ 或 /skills 調用時運行 skill，或者在任務描述與 skill 描述匹配時自動觸發。這就是為什麼一個簡潔、無聊的描述比一個聰明的描述更好用。Claude Code 的做法完全一樣，我在《agent skills》裏寫過這個模式。
Skills 也是讓 intent 不再反覆付出成本的地方。我在《intent debt》裏說過：智能體每次會話都是從零開始的，你沒說清楚的地方，它會用一個「自信的猜測」來填上。一個 skill，就是把這些意圖寫在外面，約定、構建步驟、「我們不這麼做是因為那次事故」，寫一次，智能體每次運行都讀到。沒有 skills，loop 每個週期都要從零推導你的整個項目；有了 skills，它會複利增長。
有一點需要搞清楚：skill 是編寫格式，plugin 是發佈方式。當你想跨多個倉庫共享一個 skill，或者把幾個 skill 打包在一起，你就把它們打包成一個 plugin。Codex 和 Claude Code 都是這樣。
Plugins 和 Connectors：讓 loop 觸及真實在用的工具
一個只能看到文件系統的 loop，是一個很小的 loop。
Connectors 基於 MCP 構建，讓智能體能讀取你的 issue tracker、查詢數據庫、訪問 staging API、在 Slack 裏發消息。Codex 和 Claude Code 都支持 MCP，所以你為一個工具寫的 connector 通常在另一個裏也能直接用。Plugins 則把 connectors 和 skills 打包在一起，讓你的隊友一鍵安裝你的整套配置，不用從記憶裏重新拼一遍。
有了 Connectors，loop 才能真正在你的實際環境裏幹活，不只是跟你說如果我能操作的話我會這麼做。這就是一個說「這是修復方案」的智能體和一個自己開 PR、關聯 Linear ticket、等 CI 變綠後自動 ping 頻道的 loop 之間的區別。
Sub-agents：讓生成者和檢查者分開
loop 裏最有用的結構設計，沒有之一，就是把寫代碼的和檢查代碼的拆開。
讓寫代碼的模型來評審自己的代碼，它會對自己太好說話。一個拿着不同指令、有時甚至是不同模型的第二個智能體，能抓住第一個模型自己沒意識到、或者選擇忽略的問題。
Codex 只在你要求時生成 subagents，同時運行，然後把結果合併成一個答案。你在 .codex/agents/ 裏用 TOML 文件定義自己的 agents，每個有名字、描述、指令，以及可選的模型和推理力度，你的安全審查員可以是一個高力度的強模型，而你的探索者可以是某個快速的只讀工具。Claude Code 在 .claude/agents/ 裏用 subagents 和 agent teams 做同樣的事，任務在它們之間傳遞。兩個工具裏常見的分工都是：一個 agent 探索，一個實現，一個對照規格驗證。
我之前寫過兩次這個邏輯，一次是《code agent orchestra》，一次是《adversarial code review》。它在 loop 裏之所以特別重要，是因為 loop 在你不盯着的時候跑，所以一個你真正信任的驗證者，是你敢走開的唯一理由。
Sub-agents 確實會燒更多 token，因為每一個都要做自己的模型和工具調用。所以別到處用，只在真正需要有人幫你再把把關的地方才值得開。這其實也是 Claude Code 的 /goal 背後的邏輯：決定 loop 有沒有完成的，應該是是一個全新的模型，而不是那個做了這些工作的模型，生成者和檢查者分開這件事，在這裏被用到了「要不要停」這個判斷上本身。
03
完整的 Loop 長什麼樣？
把這些拼在一起，一個單線程就變成了一個小型控制枱。以下是我一直在用的一種形態：
每天早上，一個 automation 在倉庫上跑起來。它的提示詞調用一個 triage skill，讀取昨天的 CI 失敗、open issues、最近的 commits，然後把發現結果寫進一個 Markdown 文件或 Linear 看板。對於每一個值得處理的發現，loop 會開一個隔離的 worktree，派一個 sub-agent 去起草修復方案，再派第二個 sub-agent 對照項目 skills 和現有測試來審查這份草案。
Connectors 讓 loop 自己開 PR、更新 ticket。loop 處理不了的東西，落進 triage 收件箱等我來看。狀態文件（state file）是把整個系統串起來的那根線，它記得嘗試過什麼、通過了什麼、還有什麼懸而未決，所以明天早上的運行會從今天停下來的地方繼續。
看看你實際做了什麼：你只設計了一次，你沒有手動提示任何一個步驟。這就是 Steinberger 那句話真正變成現實的樣子，而且它在 Codex 裏和在 Claude Code 裏是同一個 loop，因為兩邊的模塊是同樣的模塊。
04
Loop 仍然離不開人
Loop 改變了工作的形態，但它並沒有讓你變得多餘。隨着 loop 越來越好，有三個問題反而會變得更尖鋭：
驗證仍然是你的責任。一個無人值守運行的 loop，同時也是一個無人值守犯錯的 loop。把驗證 sub-agent 和生成者拆開，是為了讓 loop 的「完成了」這個判斷有點意義。即便如此，「完成了」也只是一個聲明，不是證明。我一直在重複同一句話：你的工作是發佈你親自確認過能跑的代碼。
如果你放任不管，你對代碼庫的理解會腐爛。loop 跑得越快、產出越多，你沒親手寫過的代碼就越堆越多，實際存在的東西和你真正理解的東西之間的差距就越大。這就是理解債，跑得越順的 loop，只會讓這個差距增長得越快。唯一的解法是你真的去讀 loop 生成的東西。
最舒服的姿勢，很可能是最危險的。當 loop 自己跑起來，你很容易停止發表意見，直接接受它給你的任何東西。我把這叫做認知投降。設計 loop 是解藥，也可以是加速劑，帶着判斷去設計它，它是解藥；用它來逃避思考，它是加速劑。同一個動作，完全相反的結果。
05
工程師要帶着判斷去設計 Loop
Build the loop. Stay the engineer. 我認為這是我們工作方式演進的一個預演。但話說回來，如果我不親自 review 代碼，或者完全依賴自動化 loop 來修復問題，產品質量就會下滑，很可能陷入一個越挖越深的惡性循環。
所以，去搭建你的 loop，但別忘了直接提示智能體仍然是有效的，關鍵是要找到正確的平衡。
Loop 也會因人而異，產生完全不同的結果。兩個人可以搭出完全一樣的 loop，卻得到截然相反的結果。一個人用它在自己深刻理解的工作上跑得更快；另一個人用它來逃避理解工作本身。Loop 不知道這兩者的區別，但你知道。
這就是為什麼設計 loop 比提示詞工程更難，不是更容易。Cherny 說的那句話，不是說工作變簡單了，而是說槓桿點移動了。
Build the loop，但要像一個打算留在工程師位置、不只是「按下啓動鍵的人」那樣去 build 它。
原文：https://x.com/addyosmani/status/2064127981161959567
Sarah Guo：能被 Benchmark 衡量的工作，都不應該是你的創業方向
轉載原創文章請添加微信：founderparker