Question
幫我整理一下 ai agent 中 loop engineering 相關的詳細內容，用繁體中文說明，特定專有名詞保留英文，目標是讓我能理解 loop engineering 並套用在我的工作流程中
Answer
1. 什麼是 Loop Engineering
Vault 中 5 篇文章對 loop engineering 的定義幾乎一致，可以歸納成一句話：
Prompt 是一個問題，Loop 是一份工作（job）。
傳統用法（prompting）是「人類驅動」的循環：你打字、等待、檢查結果、再打字。人類本身就是那個迴圈。Loop engineering 則是把這個迴圈外部化成一個系統：你定義目標（goal），系統自己發現要做什麼、規劃、執行、驗證結果、決定下一步，直到目標達成或觸發停止條件，整個過程不需要你在場盯著。
業界最常被引用的兩句話（出自 Loops explained 與 Loop Engineering: The AI skill…）：
“You should not be prompting coding agents anymore. You should be designing loops that prompt your agents.” — 業界流傳語 “I do not prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.” — Boris Cherny（Claude Code 負責人）
2. 五個階段（Loop 的基本骨架）
幾乎每篇文章都用同一個五階段循環來描述 loop 的運作機制：
DISCOVER（發現）→ PLAN（規劃）→ EXECUTE（執行）→ VERIFY（驗證）→ ITERATE（迭代）
- Discover：找出有什麼需要處理（例如：掃描 CI failure、新 issue）
- Plan：決定怎麼做
- Execute：實際動手做
- Verify：用客觀標準檢查結果是否達標
- Iterate：沒過關就把結果丟回迴圈重新跑，過關就停止
其中 Verify 是整個 loop 的核心。沒有真正的驗證機制，loop 就只是 agent 自己跟自己說「做得不錯」，這不是進步，只是重複。
3. 是否值得建立一個 Loop？（4-Condition Test）
這是套用前最該先做的篩選，三篇文章都用幾乎相同的四條件測試：
- 任務會重複發生（至少每週一次）——如果是一次性任務，寫一個好 prompt 比建 loop 划算
- 驗證可以自動化——要有 test、type check、build、linter 等「能客觀判斷失敗」的機制，否則 agent 是在自己批改自己的作業
- Token 預算能吸收浪費——loop 會反覆重讀 context、重試、探索，這些都燒 token，且每一輪都更貴（因為 context 越滾越大）
- Agent 有資深工程師等級的工具——能看 log、有可重現的環境、能執行並觀察自己寫的程式碼結果
只要漏一個條件，就維持手動 prompt，不要建 loop。（Loop engineering 14-step roadmap、Loops explained 皆強調這點）
4. 六個構成要素（Building Blocks）
跨文章一致提到的 loop 組成要素：
| 要素 | 作用 | 說明 |
|---|---|---|
| Automation | 心跳（heartbeat） | 讓 loop 自動觸發的排程或事件機制，沒有它 loop 只是你跑過一次的 script |
| Worktree | 平行不衝突 | 多個 agent 同時改 code 時，各自獨立的 git checkout + branch，避免互相覆寫 |
| Skill | 可重複使用的知識 | 把專案規則、慣例、「絕不能做的事」寫成一份檔案（SKILL.md），每次執行都讀取，不用每次重新解釋 |
| Connector / Plugin | 真實工具存取 | 透過 MCP 等方式連到 GitHub、Slack、Linear、Jira 等，讓 loop 能「真的去做」而不只是「建議該怎麼做」 |
| Subagent | 製作者與檢查者分離 | 寫程式碼的 agent 對自己的成果通常太寬容（self-preferential bias），用獨立的 agent／model 來審查，是提升品質最有效的單一手段 |
| Memory / State | 跨輪記憶 | Model 會忘記，但 repo 不會。用 STATE.md、Linear ticket、GitHub Issue 等外部紀錄保存「做了什麼、卡在哪、下一步是什麼」，讓明天的 run 是「接續」而不是「從零開始」 |
在 Claude Code 中，這些要素具體對應：
- Automation →
/loop（session 內、固定或動態間隔排程）、/goal（跑到某個條件成立為止，由獨立的 checker model 判斷，不是寫程式碼的 model 自己判定）、Routines（雲端託管、不需開著 session，最短間隔 1 小時，會有最多 30 分鐘的排程抖動） - Worktree →
--worktreeflag、isolation: worktree設定 - Skill →
.claude/skills/下的 SKILL.md - Subagent →
.claude/agents/下定義的子代理，用--agent=<name>呼叫
5. Open Loop vs Closed Loop
- Closed Loop（封閉式）：人類先設計好路徑，包含明確目標、固定步驟、每步都驗證、有停止條件、卡住時有交接點。便宜、可靠、輸出乾淨，是現在實際該從這裡開始的版本。
- Open Loop（開放式）：給 agent 一個寬泛目標，讓它自己探索路徑。能發現你沒想到的東西，但容易嘗試太多路徑、燒太多 token、漂離真正目標、難以控制。
建議：先從 Closed Loop 開始，等驗證機制夠強之後再考慮開放。
6. 正確的建置順序
四篇文章（Loops explained、14-step roadmap、Loop Engineering: The AI skill）都強調順序比工具選擇更重要：
1. 先讓「一次手動執行」變得可靠
2. 把這次執行的方法寫成 Skill
3. 把 Skill 包進一個 Loop（加上 gate + 停止條件）
4. 最後才排程（schedule）
跳過前面步驟直接排程，是「loop 在你睡覺時突然爆炸」最常見的原因。
7. 常見失敗模式（必須知道）
- Ralph Wiggum Loop（工程師 Geoffrey Huntley 命名）：agent 過早判定「完成」，loop 在任務只做一半時就退出，卻持續安靜地花錢，不會崩潰也不會報錯，只是默默燒 token。修法：要有客觀的 gate（test/build/lint 結果），不能只靠「另一個 agent 覺得做完了」。
- Goal drift（目標漂移）：長對話中每次摘要都會丟失一些資訊，「不要做 X」這類限制條件在第 47 輪可能就消失了。緩解方式：用一份固定重讀的 VISION.md / AGENTS.md。
- Self-preferential bias（自我偏好偏誤）：寫程式的 agent 對自己的成果評分太寬容。緩解方式：獨立 reviewer subagent，不看 maker 的推理過程。
- Agentic laziness：loop 在還沒真正做完時就宣告「夠好了」。緩解方式：
/goal配合獨立 checker model 的客觀停止條件。 - Comprehension debt（理解債）與 cognitive surrender（認知放棄）：loop 跑得越好，repo 裡的程式碼和團隊實際理解的落差就越大；放棄形成自己的判斷、無腦接受 loop 輸出的誘惑也越大。緩解：讀 diff、定期檢查 gate 是否真的還能抓到問題、把 loop 限制在小範圍可機器驗證的工作，不要讓它碰架構決策。
- 沒有 token 上限：每次重試、每個 subagent、每輪驗證都在燒錢，沒有上限的 loop 容易燒到 5-10 倍預期成本。
- 模糊的排程指令／升級規則：例如「每小時幫我看通知」沒有明確的「只在 X 情況才通知我」規則，結果變成資訊轟炸，一個無法略讀的報告等於沒人會看（出自 17 prompts that make Hermes run while you sleep 的實戰教訓）。
8. 真正該追蹤的指標
不是「燒了多少 token」或「跑了幾次 loop」，而是 cost per accepted change（每個被接受變更的成本）。如果 loop 產出 10 個結果你丟掉 6 個，等於你在做它本該幫你省下的審查工作；接受率低於 50% 時，loop 是虧本的。
9. 規模：Single-Agent Loop vs Fleet Loop
- Single-Agent Loop：一個 agent 跑完整個五階段循環，適合範圍小、目標單一的任務（bug fix、研究摘要、內容草稿）。
- Fleet Loop：一個 orchestrator agent 拆解任務，分給多個 specialist agent，每個 specialist 又可以用自己的 subagent。適合大型、多步驟目標（例如「建一個生產力 App」）。Boris Cherny 的 Tier 3（
/batch與動態 JavaScript workflow，用agent()/parallel()/pipeline()）就是 Fleet Loop 的具體實作，曾用 800 個 agent 完成 4000 個檔案的 monorepo 改名任務，每個 agent 有自己的 worktree 並被另一個 agent 做對抗式審查（adversarial review）。
10. 如何套用在你的工作流程
具體的落地步驟建議：
- 先用 4-Condition Test 篩選：你目前手動重複做的工作中，哪些符合「每週重複、可自動驗證、agent 有能力做、token 預算可接受」？例如 vault 的
/lint-vault、/analyze-vault本身就是很適合的 closed loop 候選（有明確驗證標準：YAML 是否合法、frontmatter 是否齊全）。 - 從最小可行循環開始（The minimum viable loop，出自 14-step roadmap）：一個 automation + 一個 skill + 一個 state file + 一個 gate，不要一次上 Fleet。
- 先手動跑一次，確認可靠，再寫成 Skill，再包成 Loop，最後才排程——不要跳步。
- 把 maker 和 checker 分開：如果是程式碼類任務，讓另一個 agent／model 做審查，不要讓寫程式的 agent 自己批改自己。
- 明確寫出升級規則 / 停止條件：每個排程型 prompt 都要包含「只在 X 情況才通知我」與「跑 N 次或 N 小時就停」，否則會收到資訊轟炸或無限燒錢。
- 用一份外部 state 檔案記錄進度（例如 vault 的
log.md模式），讓 loop 下次執行時是接續，不是從零開始。 - 定期檢查 gate 是否還有效：gate 會「rot（腐化）」，要抽樣檢查 loop 通過的結果是否真的符合你在意的品質標準。
Sources
Vault notes consulted:
- Clippings-Loops explained Claude, GPT, Mira and what actually works — 最完整的第一原理解說，含 4-condition test、五階段循環、token 成本複利問題、cost per accepted change 指標
- Clippings-Loop Engineering The AI skill every builder needs in 2026 — 六個 building blocks、open vs closed loop、single-agent vs fleet loop 的清楚分類
- Clippings-Loop engineering the 14-step roadmap from prompter to loop designer. — 4-condition test 的「30 秒檢查清單」版本、minimum viable loop、Ralph Wiggum loop、comprehension debt / 安全稽核（第 14 步）
- Clippings-The Three-Tier Agent Stack Boris Cherny Actually Runs — Claude Code 實際工具對應（
/loop、Routines、/batch、動態 workflow）與三層如何透過共享檔案串接 - Clippings-17 prompts that make Hermes run while you sleep (copy-paste inside) — 個人/生活場景下的實戰案例與失敗教訓（模糊排程、無 token 上限、用便宜模型導致 tool call 失敗）
Follow-up Questions
- vault 目前沒有任何文章實測「cost per accepted change」的具體計算方法或工具，若要真的追蹤這個指標，需要額外研究或自行設計記錄方式。
- 5 篇來源中有 4 篇高度重疊（同一波文章潮，互相引用同樣的 Boris Cherny 語錄），可能反映社群迴聲而非獨立驗證的最佳實踐；尚未有 vault 內容是「loop 失敗的真實案例覆盤」或「大規模生產環境的長期維運報告」，可作為未來
/research-vault的延伸題目。 - 三層 Tier 中的 Tier 2 Routines（雲端排程）與 Tier 3 動態 workflow 的具體設定語法（cron 表示式、
.claude/agents/TOML 格式）目前只在 Three-Tier Agent Stack 一篇中有範例，若要實作可能需要查官方文件補齊細節。