import { ArticleLayout } from '@/layouts/article-layout' export default ArticleLayout
Loop Engineering 實戰失敗深度總結
當設計文件無法執行時
2026 年 6 月 7 日，OpenClaw 創始人 Peter Steinberger 發文："You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." 同日，Anthropic Claude Code 負責人 Boris Cherny 公開表示："I don't prompt Claude anymore. I have loops running. My job is to write loops."
6 月 8 日，Google 工程總監 Addy Osmani 發布長文，正式將這套方法論命名為 Loop Engineering。
6 月 13 日，我們用一整天嘗試從零構建一個完整系統。
結果：失敗。
我們到底建了什麼
36 個文件。7 個模塊。10 個 cron jobs。8 個 Loop。1 個 Dashboard。
從紙面上看，這是一個完整的 Loop Engineering 系統：
- 三層架構（Main → Looper → coder-*）
- 七階段內循環（Observe → Plan → Execute → Verify → Diagnose → Adjust → Retry）
- 30 次自我修正上限 + 四級策略遞進
- 五維意義評估模型（≥70 分才轉化為 Loop）
真相：什麼都沒發生
當我們用 openclaw cron run 觸發一個刻意會失敗的測試 Loop 時 — 文件未被創建，STATE.json 完全空白。
根因：沒有 Loop Runtime Engine。
LOOP.md 的 YAML frontmatter 定義了 executor、checker、inner_loop、escalation。但 cron 觸發後，沒有任何程式碼去解析和執行這些定義。
以下是行業標準和我們的實際差距：
| 行業標準 | 我們 |
|---|---|
| Maker ≠ Checker | ❌ 設計階段兩者都是 looper |
| Separate verifier model | ❌ 寫了但無程式碼執行 |
| /goal: run until condition met | ❌ 內循環從未發生 |
| State on disk, not in context | ✅ 設計正確 |
三個致命錯誤
1. 文件 ≠ 系統。 36 個設計文件不等於一個可運行的系統。
2. sessions_spawn ≠ Loop。 我們用 sessions_spawn 繞過內循環完成了所有「交付」。這不是 Loop Engineering，這是排程多 Agent。
3. 盲點只在運行時暴露。 Maker/Checker Split 的錯誤在設計階段完全沒被發現，因為系統從未被執行過。
下一步
核心洞察：Loop Engineering 的難點從來不是寫 LOOP.md，而是寫那個能執行 LOOP.md 的引擎。
三條路徑：Python Loop Runner（自建 200 行）、Claude Code /goal（原生機制）、混合方案。