01什麼是 Loop Engineering
大多數人用 AI coding agent 的方式還停留在：「打一段 prompt → 等回覆 → 手動修正 → 再打一段」。 這是 turn-by-turn 互動，你是那個一直在按按鈕的人。
Loop Engineering 是把你自己從「prompt agent 的人」這個角色替換掉。 你設計的是一個系統來做這件事。
「我不再直接 prompt Claude。我讓 loop 去 prompt Claude 並自行決定怎麼做。我的工作是寫 loop。」
Loop 不是讓 AI 無人監管地亂跑。它是把 automation、state、tool access、verification、human approval 這幾件事放在同一個控制系統內，在安全邊界中反覆執行可驗證的任務。
02典範演進
從手動 prompt 到自主系統，AI 工程經歷了三個明確的層級：
你手動寫 prompt，一來一回。每次都從零開始。
你設計 agent 的運行環境 — rules、tools、memory、context。Agent 更聰明了，但每次任務仍然需要你來啟動。
你設計一個會自己發現工作、分派任務、驗證產出、記住狀態的系統。Loop 跑在 timer 上、spawn sub-agent、self-feed。
Loop 不只做任務 — 還改寫做任務的規則本身。每一輪的失敗沉澱為下一輪的約束，系統指令在螺旋中自我演化。（§09 詳述）
關鍵差異：在 L0 和 L1，你是發動機。在 L2，系統是發動機，你是工程師。在 L3，系統在改善自己的引擎。
03加個 Timer 就是 Loop 了嗎？
最常見的誤解：「Loop 不就是 cron job 嗎？」不是。加 timer 只是自動按按鈕，
跟你手動打 /blog-analytics 沒有本質區別，只是省了你按那一秒。
Cron Job
每週一 → 跑分析 → 產報告 → 結束
每週一 → 跑分析 → 產報告 → 結束
每次獨立、無記憶、做一樣的事。
產出從未影響下一次。
Loop
→ 發現 CTR 掉了 → 查是哪些頁面
→ 跟兩週前的建議交叉比對
→ 「建議改 title 的 3 頁，2 頁改了」
→ 改了的 → 追蹤效果：A 頁 +12%
→ 沒改的 → 升級優先度，推通知
→ 記錄本次決策到 state
→ 下週從這個 state 接續
五個本質差異
Loop 的產出會變成下一輪的輸入。
它是螺旋上升的，不是平行重複的。
沒有 state → 沒有 decision → 沒有 verification → 不是 loop，只是定時任務。
04五大 Building Blocks
Addy Osmani 把 Loop Engineering 系統化為五個必要元件，加上一個隱藏的第六元素：
/goal 功能讓 loop 持續執行直到條件為真，
且用另一個 model 來判斷是否完成（不讓做事的 agent 自己打分）。
SKILL.md，寫一次，每個 loop cycle 都能複用。
不用每次重新解釋「我們的 API 風格是什麼」「測試要跑哪些」。
+1 隱藏的第六元素：Persistent State
Agent 跑完就忘，但 repo 會留。Markdown file、Linear board、或任何外部記憶系統 — 這是所有 long-running agent system 的基礎錨點。 沒有 state，loop 每次都從零開始，根本不是 loop。
05一個真正的 Loop 長什麼樣
以「每日自動 triage + 修復」為例，一個完整的 loop 這樣運作：
Autonomous Loop Lifecycle
早上排程自動啟動，不需要人按按鈕
讀昨天的 CI failure、open issues、recent commits，查 state file 判斷哪些處理過了
每個值得處理的 finding → 開 worktree → 派 sub-agent 寫修復
另一個 sub-agent review 修復結果，對照 skills + 現有測試
Connector 開 PR、更新 ticket、通知 channel。解不了的丟 triage inbox
State file 記錄嘗試過什麼、pass 了什麼、還剩什麼
一次性的架構設計，消除每次重複 prompt 個別步驟。 這就是為什麼 Boris Cherny 說「我的工作是寫 loop」— 寫好 loop 之後，loop 自己會 prompt agent。
06成熟度等級
不是每個 loop 都要一步到位。正確的做法是從 L1 開始，穩定後才升級：
Loop 只做觀察和產生報告，不做任何修改。 每天掃 CI failure 然後發一份摘要到 Slack；掃 dependency 版本然後列出過期清單。 零風險，是建立信任的起點。
Loop 可以開 PR、提修復建議，但需要人類 review 和 approve 才能 merge。 有了 L1 的信任基礎後，讓 loop 開始動手，但卡一道人類閘門。
Loop 自主判斷、自主交付，只在例外情況才 escalate 給人。 最高風險、最高槓桿。只適用於有充分測試覆蓋、且 L2 階段已經穩定運行一段時間的場景。 順序錯了，成本和風險會一起放大。
07三大陷阱
Loop 跑得越順，越容易掉進這三個坑：
無人看管的 loop = 無人看管的錯誤。Sub-agent verifier 提高可靠度， 但不等於證明。跑得越快，你越需要在關鍵節點設人類閘門。
Code 產出速度 > 理解累積速度。Loop 越順暢，你離 codebase 越遠。 如果你不讀 loop 的產出，你就是在對自己的 codebase 累積技術債， 只是這次債主不是 legacy code，是你自己的無知。
最危險的陷阱。Loop 自己跑得很好 → 你懶得看 → 你不再有自己的判斷。 這不是自動化，這是投降。Loop 應該讓你更快地做正確的事， 而不是讓你更快地不思考。
08工具比較：Claude Code vs Codex
目前兩大 AI Coding Agent 都已支援 Loop Engineering 的完整元件：
| Building Block | Claude Code | Codex |
|---|---|---|
| Automations | /schedule /loop hooks, GitHub Actions |
Codex app 排程 + triage inbox |
| Worktrees | --worktree flag, isolation: "worktree" |
內建 worktree 支援 |
| Skills | .claude/skills/ + SKILL.md |
.codex/skills/ + SKILL.md |
| Connectors | MCP servers + plugins | MCP + plugins |
| Sub-agents | .claude/agents/ + Workflow API |
.codex/agents/ + TOML 定義 |
09最被忽略的 Loop：你的日常對話
大多數人聽到 Loop Engineering，第一反應是去想「我哪個 cron job 可以升級」。 但最強大的 loop 不是自動化腳本 — 是你每天跟 AI 的工作對話本身。
Session-as-a-Loop
Session 開場搜記憶系統 — 上次做了什麼、卡在哪、決策了什麼
不是從零開始想「今天做什麼」，而是「上次的產出告訴我這次該做什麼」
寫 code、做分析、解問題。過程中發現失敗模式和改進機會
不只產出 code 和報告 — 把失敗模式寫成 rule，讓下一輪不再犯同樣的錯
Session 結束寫入記憶系統 — 決策、進度、教訓，全部持久化
為什麼這是 Meta-Loop
Addy Osmani 講的 loop 改的是 code。但 session loop 改的是改 code 的規則本身。
產出：Code
下輪輸入：接續修下一個 bug
Loop 本身不會變。
第 100 輪跟第 1 輪用同樣的規則。
產出：Code + Rules
下輪輸入：接續修 bug + 受新 rule 約束
Loop 本身在進化。
第 100 輪的規則比第 1 輪嚴格 10 倍。
螺旋上升的證據
如果你用 AI coding agent 超過幾個月，回頭看看你的系統是否有這些跡象：
no-guessing rule → 之後每個 session 都被約束。
Scope creep 過 → 產出 scope-discipline rule → 之後每次先確認邊界。
每一條 rule 都來自一次真實的失敗，不是理論推演。
這就是 loop 的產出變成下一輪的輸入。
最強的 Loop Engineering 不是讓 AI 自己跑。
是讓每一次 Human × AI 的協作，
都改善下一次協作的品質。
自動化 loop 改的是 code。Meta-loop 改的是改 code 的方式。
前者是效率，後者是能力的複利。
業界現況偵察（2026 年 6 月）
經過對 X/Twitter、GitHub、HN、Reddit、arXiv 的完整掃描，結論是： Session-level meta-loop 是一個真正的空白地帶。
社群大量抱怨「agent 每次都忘」「重複犯同樣的錯」，但公開的解法全部停在 L1：
關鍵設計教訓（來自 bmo 100+ session 實戰報告）：Self-improvement 不能和主任務同時跑。 LLM 的 recency bias 會讓主任務壓過 meta-level 的自我改善指令。 需要明確的 trigger（如「每 N 個 session 執行 battery change」）而非開放性的「有問題就改」。
10交棒機制：經驗、決策、影響
Loop 最難的不是「怎麼跑」，而是「怎麼把上一輪的東西交給下一輪」。 大部分系統的做法是 session 結束時 dump 一段摘要 — 但摘要是扁平的， 而 loop 需要交棒的東西有三種完全不同的生命週期：
curl 驗證 — 通過就 close，沒通過就 escalate。
活在 Baton（Hot State）裡，驗證完畢後歸檔到記憶系統。
--update-env-vars，因為 --set-env-vars 會清掉既有變數（上週 production 事故的 root cause）。」
帶編號（DEC-021）、帶證據、帶被拒絕的替代方案。
活在記憶系統（Warm State）裡，被搜尋到時提供歷史脈絡。被新決策推翻時標 superseded，不刪除。
rules/，可加 hook 強制執行。
這是 loop 產出永久約束的路徑。
三層交棒架構
因果鏈不能斷
三種東西用 ID 互相指向：PAT-005（經驗）→ DEC-021（決策）→ OL-008（影響）。
不是模糊的「我記得上次好像有這回事」，而是可追溯的因果鏈。
11核心原則
槓桿點已經從 prompt engineering 移到了 loop architecture。 工作沒有變簡單，是施力點移動了。
兩個開發者寫一模一樣的 loop，結果可以完全相反： 一個用 loop 在深度理解的領域加速前進；另一個用 loop 逃避理解。
「Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.」
人類驗證、主動理解、有意識的設計 — 無論自動化多成熟，這三件事不可談判。
當 agent 變得越強，真正的槓桿不是叫它
「Do something for me」
而是設計一個可追蹤、可驗證、可停止的系統，
讓它在正確的邊界內持續做對的事。
★Open Source 實作
以上所有概念已實作為 Session Baton — 開源的跨 session 狀態交棒系統。
pip install session-baton
python -m session_baton
# Server runs on http://127.0.0.1:9101