Boris Cherny（Anthropic Claude Code 負責人）講過一句讓我愣了三秒的話：「我不再 prompt Claude 了。我有一堆 loop 在跑，它們負責 prompt Claude、決定下一步要做什麼。我的工作是寫 loop。」
如果你還在認真琢磨怎麼把一句 prompt 雕得更漂亮，這篇文章可能會讓你有點不舒服——因為 2025 下半年到 2026 年，整個 agentic AI 圈子的「最高槓桿點」已經悄悄往上搬了一層。它有個正在成形的名字：Loop Engineering（迴圈工程 / 循環工程）。
我花了整整一天把這個概念從頭啃到尾，從 Addy Osmani 的部落格、Anthropic 官方工程文章，一路追到 Geoffrey Huntley 那個被戲稱「Ralph」的土砲 bash loop。這篇就是我的整理：Loop Engineering 到底是什麼、它建立在什麼之上、怎麼落地、又有哪些會讓你半夜被叫起來修的坑。
三層抽象：Prompt → Context → Loop
先講結論。這幾年「跟 AI 一起寫 code」這件事，工程師施力的位置，已經疊出了三層：
| 層級 | 你在解決的問題 | 一句話定義 |
|---|---|---|
| Prompt Engineering | 這一句話要怎麼講 | 優化「單一指令的措辭」 |
| Context Engineering | window 裡還要塞什麼進去 | 管理 docs、歷史、工具定義等整體狀態 |
| Loop Engineering | 何時該 prompt 什麼、結果能不能收 | 設計「決定要 prompt 什麼、何時 prompt、產出可不可接受」的控制系統 |
Addy Osmani （他是 Google Chrome 團隊的工程主管，講前端工程的那個 Addy）把 Loop Engineering 定義得很狠：
「Loop engineering 就是把『那個負責 prompt agent 的人』從你自己換掉。你改成去設計一個系統，讓系統去 prompt。」（意譯自原文）
換句話說，傳統流程是：你打一段 prompt → 讀 AI 回什麼 → 再打下一段 → 再讀……你整個人被綁在這個 turn-by-turn 的迴圈裡，當 AI 的人肉保母。Loop Engineering 把這件事整個翻過來：你設計一個小系統，讓它自己去發掘工作、分派、驗證結果、決定下一步，中間不需要你插手。
Anthropic 官方對 agent 的定義其實也是同一件事，而且更精煉——「LLM 在一個 loop 裡自主使用工具」 。注意那個 loop。它不是裝飾，它是定義的核心。而 Claude Code 背後那套 harness（也就是 Claude Agent SDK ），截至 2025 年 9 月官方說法是「已開始驅動我們幾乎所有主要的 agent loop」——deep research、影片製作、筆記，全跑在同一個 loop 引擎上。
所以這不是某個 KOL 自己造的詞要你跟風。是工具供應商、實作者、社群三邊各自從不同方向，撞到了同一個結論。
一段四年的演進史：從 ReAct 到 Ralph
Loop Engineering 不是憑空蹦出來的。它是 agentic 模式四年慢慢收斂的終點。我把時間線拉給你看：
2022.10 ReAct (Princeton/Google) 推理→行動→觀察→再推理
2023.03 AutoGPT 給目標自我拆解，但無限迴圈＋爆帳單
2023 Reflexion (NeurIPS) 加入自我反思層
2024-25 Plan-and-Execute 規劃與執行分離，可平行化
2025.07 Ralph Loop (Geoff Huntley) fresh context ＋ 檔案系統當記憶
2026.05 原生 /goal (Claude Code) evaluator model 驗證完成條件幾個關鍵節點：
- ReAct（2022.10） 是這一切的源頭。Princeton 和 Google 把「Reasoning + Acting」形式化：模型先推理、呼叫工具、讀結果、再推理，循環到完成。在 ALFWorld 任務上比純行動方案進步 34%。
- AutoGPT（2023.3） 是第一次大爆紅的嘗試——給它一個高層目標，它自己拆子任務、上網、操作檔案。GitHub star 數週內衝到十萬，但它苦於無限迴圈和爆量 API 帳單，最後停在 demo 階段。這是第一個血淋淋的教訓：沒有 stop 條件的 loop，是會吃光你錢包的怪物。
- Ralph Loop（2025.7） 是我最喜歡的一段。澳洲工程師 Geoffrey Huntley 想出一個土到掉渣卻有效的招：把 agent 塞進一個
while true的 shell loop 裡，每一輪都重開一個全新的 context、從 disk 上的 prompt 檔重新讀任務。
Ralph 為什麼天才？因為它一刀解決了長對話的兩個老問題：context 會越長越爛（後面會講的 context rot），還有 agent 自以為做完就提早跑掉。每輪 fresh context = 不會腐化；用 stop hook 驗證真的完成條件 = 不會早退。它甚至不用對話歷史當記憶，它把檔案系統當記憶。乾，有夠簡單，但就是會動。
到了 2026.5，Claude Code 直接把這套做成原生的 /goal 指令——用一個獨立的 evaluator model 去檢查完成條件，跨多輪自主工作。OpenAI Codex 也在 2026 年 4–5 月間相繼推出對應功能。這代表 loop primitives 正在從「自己寫 bash script」變成「平台原生功能」。
Ralph 的精神用偽碼長這樣，你看完大概就懂了為什麼它叫「stupidly simple」：
# Ralph Loop 的本質：每輪 fresh context，狀態存在 disk
while true; do
# 每次都是乾淨的 agent 實例，從 prompt 檔重讀任務
claude-code --prompt-file ./PROMPT.md --no-conversation-history
# stop hook 驗證真正的完成條件，不是讓 agent 自己說「我做完了」
if ./verify-done.sh; then
echo "所有 PRD 項目通過驗證，收工"
break
fi
# 沒過？把當前狀態（含錯誤）留在 disk，下一輪重新開始
done關鍵在 --no-conversation-history 和那個 verify-done.sh。記憶不在對話裡，在檔案系統；完成與否不靠 agent 自評，靠外部腳本。這兩點，等下你會發現是整個 Loop Engineering 的命脈。
一個 loop 怎麼組起來：五塊積木 + 記憶
光講概念太虛。實務上一個能跑的 loop，業界整理 出來大概是這五塊積木加一個記憶：
- Automations（自動化心跳）——定時觸發、自動發掘並 triage 工作。它是整個 loop 的心跳，沒有它，loop 不會自己動起來。
- Worktrees（隔離）——用平行的 git worktree，讓多個 agent 同時動工而不會互相踩檔。多 agent 並行最怕的就是兩隻同時改同一個檔案，這塊就是防呆。
- Skills（技能）——把專案知識和慣例寫進
SKILL.md，免得每次 session 都要重新跟 AI 解釋「我們專案的 commit 格式是這樣」。 - Plugins / Connectors——透過 MCP 接上真實工具：issue tracker、資料庫、Slack。沒有這層，agent 就只是個會打字的腦，沒有手。
- Sub-agents（子代理）——把「產出」和「驗證」拆給不同 agent。原因很現實：寫 code 的那個模型，幫自己打分數時太佛心了，它會覺得自己寫的都對。
再加上第六塊，Memory（外部記憶）——一個 markdown、一塊 Linear 或 GitHub board，重點是它活在單次對話之外。因為模型每跑完一輪就忘光光，記憶必須放在 disk 上。
把這些組起來，一個真實的 loop 端到端大概是這樣跑的：
早上 automation 觸發 → 跑 triage skill 找出昨晚 CI 掛在哪、有哪些 issue → 寫進記憶檔 → 對每個可處理的項目開一個隔離 worktree、派一隻 sub-agent 草擬修復 → 另一隻 reviewer sub-agent 對照專案標準和測試做驗證 → connector 自動開 PR、更新 ticket → 搞不定的留在 inbox 等人類審。那個狀態檔記得「試過什麼、過了什麼、還開著什麼」，所以明天早上這一輪會接著今天停下的地方繼續。
你會發現，這已經不是「我在用 AI 寫 code」，而是「我在設計一條會自己上工的產線」。Addy 說這比「agent harness engineering」還高一層，我覺得很精準。
底層燃料：對抗 context rot 的 context engineering
這裡要岔開講一個容易被略過、但其實是命脈的東西。Loop 能長時間自己跑，靠的不是模型多神，而是底層的 context engineering。
Anthropic 官方 把它定義成「在 LLM 推理過程中，策展與維護最佳 token 集合的策略」，並點名兩個會殺死 loop 的失敗模式：
- Context Rot（脈絡腐化）：context window 越長，模型的召回和推理品質就越爛。這不是模型偷懶，是 transformer 架構本質——Anthropic 官方點名 token 兩兩之間 n² 關係隨規模膨脹；實務上更常見的表現是注意力分佈被稀釋、中段資訊大量流失（也就是 lost-in-the-middle 現象）。
- Finite Attention Budget（有限注意力預算）：「每塞一個新 token 進去，就消耗掉一點預算。」所以原則永遠是：找出最小的高訊號 token 集合，而不是把所有東西都倒進去。
對應的解法，剛好就是 loop 能長跑的基礎建設：
| 技法 | 在做什麼 |
|---|---|
| Compaction（壓縮） | 把對話歷史摘要、用壓縮後的 context 重啟，保留關鍵決策 |
| Agentic Memory | 在 window 外寫持久筆記，需要時再撈回來（就是 Ralph 的精神） |
| Sub-agent 架構 | 專責 agent 用乾淨 context 處理聚焦任務，只回傳 1,000–2,000 token 摘要 |
| Just-in-Time 取用 | 不預載全部資料，靠輕量識別碼動態載入，模仿人類「需要才去查」 |
| Right Altitude | system prompt 在「硬編碼到死板」與「空泛到沒用」之間取平衡 |
看出來了嗎？Ralph Loop 的「每輪 fresh context」其實就是 compaction 的暴力版；它的「檔案系統當記憶」就是 agentic memory 的土砲版。Loop Engineering 不是取代 context engineering，它是站在 context engineering 的肩膀上。 你底層 context 沒管好，上面的 loop 跑越久只會爛越快。
沒人看管的 loop，也是沒人看管在犯錯的 loop
講了這麼多好處，該潑冷水了。Loop Engineering 最反直覺的一點是：loop 設計得越好、越自主，它的失敗模式反而越尖銳、越難察覺。
我把風險分四類整理：
| 風險類別 | 具體會發生什麼 |
|---|---|
| 技術失敗 | context overflow、卡在無限幻覺迴圈（狂打 API、亂改 state）、錯誤層層累積 |
| 人因風險 | 理解負債（code 出得比你能讀懂的快）、認知投降（不加判斷照單全收） |
| 驗證落差 | 一句話講完：「沒人看管的 loop，也是沒人看管在犯錯的 loop」 |
| 安全攻擊面 | agent 自行越權改權限/schema、被汙染資料挾持 loop 去外洩程式碼 |
安全這塊我覺得最值得嚴肅看。有資安研究者 直接指出，傳統靜態規則引擎根本跟不上「每小時數千次語意複雜的自主互動」。三個新攻擊面特別毛：
- Agentic Overreach：agent 自己決定把某個身分權限放大、或重構整個資料庫 schema——它不是惡意，它只是「覺得這樣比較有效率」。
- Infinite Hallucination Loop：agent 誤解邊界，卡在錯誤的遞迴裡狂搥 API。
- Prompt Injection at Scale：惡意 payload 藏在不可信資料源裡，挾持整個 loop，叫它用工具權限把企業程式碼外洩出去。
然後是錢。根據業界估算（單一來源，量級參考用），單一 agent 大概吃掉一般 chat 約 4 倍的 token，multi-agent 系統更是直接拉到 15 倍。所以那種「同時開五隻 Claude 平行跑」的玩法，本質上是 token 富裕者的遊戲，不是人人玩得起。乾爆。
所以這到底是不是又一個 buzzword？
公道話要講。社群（Reddit r/AI_Agents 那群人）的質疑不是沒道理：很多號稱「agent」的東西，拆開看根本只是包裝過頭的 if-then loop，或是換皮的 RPA，「卡在一個沒有真正自主性的 hype 迴圈裡」。這種懷疑很健康，能逼大家別把 demo 當 production。
但我比較認同 一位日本 AI 開發者 的平衡立場：
「把所有工作都改成 loop 是過早的隨波逐流；但把它當『只是個 buzzword』而完全無視，也是浪費。」
我自己的判斷是：Loop Engineering 是真實的抽象上移，但它放大的是責任，不是讓你變輕鬆。 你不再當人肉保母去 prompt，但你變成那條產線的設計者和品管。理解負債和認知投降這兩個詞，會是接下來幾年工程師最該警惕的新型技術債。
如果你想開始，我的建議是別一步到位：
- 先小後大：挑一個低風險、而且可以自動驗證的任務起跑第一個 loop——更新依賴套件、跑 CI triage、同步文件，這種掛了也不會死人的。
- 記憶上 disk：用 markdown 狀態檔加
SKILL.md固化專案知識，別依賴對話記憶。 - 產出和驗證一定要分開：用獨立的 sub-agent 或 evaluator 做驗證，永遠不要讓寫 code 的模型自己幫自己打分數。
- 護欄在啟動前就定好：iteration 上限、token 預算、no-progress 偵測、明確且機器可驗證的「done」條件——這些是 AutoGPT 用爆掉的帳單換來的教訓，別再踩一次。
- 善用現成 primitives：Claude Code 的
/loop、/goal、.claude/agents/、git worktree 都是現成的，不用自己造輪子。
人類的角色正在從「寫 code」→「寫 prompt」→「設計 loop」→「打造那座跑 loop 的工廠」一路往上爬。Prompt engineering 不會消失，就像組合語言沒消失一樣——它只是不再是大多數人每天該花最多心力的那一層了。
下次你又想坐在那裡一句一句餵 AI 的時候，可以停下來問自己一句：這件事，我是不是該寫成一個 loop？
參考資料
- Effective context engineering for AI agents — Anthropic Engineering
- Building agents with the Claude Agent SDK — Anthropic
- Loop Engineering — Addy Osmani
- everything is a ralph loop — Geoffrey Huntley
- Loop Engineering: The Guide for AI Coding Agents — Lushbinary
- Agentic Loops: From ReAct to Loop Engineering (2026) — Data Science Dojo
- From Prompt Engineering to Loop Engineering: a New Security Paradigm — Filip Verloy
- Why is agentic AI still just a buzzword? — Reddit r/AI_Agents
本文基於我自己的一份深度研究報告整理而成。Loop Engineering 是 2025–2026 高速演進中的概念，多數來源為業界文章而非 peer-reviewed 論文，定義仍在流動；核心一手來源（Anthropic、Addy Osmani 等）同時是工具供應商，閱讀時請自帶一點懷疑。成本級距（4x / 15x token）為單一來源估計，僅供量級參考。
沒有留言:
張貼留言