Everyone is talking about Loop Engineering... but no one explains it like this
三句話摘要
從提示工程到迴圈工程：AI 代理自動化執行任務的新範式演進。 Loop Engineering 將 AI 代理從被動回答工具升級為主動迭代改進的自主系統，讓開發者專注於目標設計而非逐步指揮。 上下文溢出是瓶頸：Context Rot 現象指出當輸入超過 20 萬個 token 時，模型效能急劇下降。Harness Engineering 通過將任務狀態寫入檔案（Memory.md、Agent.md）而非存在上下文中，解決了反覆緊縮上下文的性能損耗。
重點整理
重點- 1
上下文溢出是瓶頸：Context Rot 現象指出當輸入超過 20 萬個 token 時，模型效能急劇下降。Harness Engineering 通過將任務狀態寫入檔案（Memory.md、Agent.md）而非存在上下文中，解決了反覆緊縮上下文的性能損耗。
- 2
迴圈嵌套是核心：Loop Engineering 是三層迴圈結構——模型內部迴圈（工具調用）、Harness 迴圈（任務步驟）、以及最外層的自動迴圈（觸發→執行→驗證→下一週期），使代理能在無人干預下持續改進。
- 3
目標設定需可驗證：迴圈必須有明確的結束條件，分為五個驗證層級：布林值（編譯成功/否）、規則與指標（網頁載入 <100ms）、延遲驗證（需等待結果才能判定）、LLM 評判（由模型打分）、以及保險絲（最多嘗試次數或時間限制）。
- 4
自動化深度工作：Loop Engineering 適合需要長期迭代改進的任務——代碼優化、網頁爬蟲更新、GitHub issue 自動修復、機器學習訓練——讓開發者只需設定一次目標，模型即自主執行所有循環。
實用技巧與重點
乾貨- 發展歷程與工具
- 系統提示規模：Claude Fable 5 系統提示約 25,000 token
- 上下文視窗限制：前沿模型最多 100 萬 input token，效能下降點在 20 萬 token 以上
- 文件架構標準：Memory.md、Agent.md、Cloud.md、Dreams.md（夢想日誌）
- 引用：Boris Cherny（Cloud Code 創造者）、Andrew Carpati（Auto-Research 專案）
- Loop Engineering 命令語法
- `/loop [時間間隔] [提示詞]` — 例：`/loop 每天早上9點 從該網站取資訊並更新程式碼並測試`
- `/goal [目標] [驗證條件] [保險絲]` — 例：`/goal 優化程式碼使網頁載入 <100ms，最多嘗試 100 次或 8 小時內完成`
- 五層驗證級別
- 布林值判定：編譯成功（True/False）
- 規則與指標：數值條件（載入時間、準確率、記憶體消耗、字元數）
- 延遲驗證：結果需事後觀察（LinkedIn 貼文反應數、客戶滿意度、廣告投資報酬率）
- LLM 評判：模型自行評分（1-10 或 1-100 等級）
- 保險絲設定：最多嘗試次數或時間限制，防止無限迴圈
- 實測案例：矩陣乘法優化
- 初始效能：2000×3000 矩陣乘法需時 0.04~0.39 秒
- 優化結果：經 10 次自主迴圈達成 320 倍加速
- 優化手法：Float64 → Float32 → Float16、啟用 Tensor Core、記憶體加倍
- 記錄方式：每次修改寫入 Markdown 檔案供追蹤
結論
結論“Loop Engineering 將 AI 代理從被動回答工具升級為主動迭代改進的自主系統，讓開發者專注於目標設計而非逐步指揮。”
完整解析
詳細AI 工程的進化路徑反映了對模型能力與系統設計的深化理解。Prompt Engineering 時代只需撰寫系統提示詞，將指令內嵌於模型的單次對話——但這限制了模型只能依賴訓練資料。Context Engineering 打破了這道牆，引入工具（MCP 協議、檔案操作、網路查詢）讓模型成為真正的代理，能主動讀取資訊充實上下文。
然而隨著工具調用次數增加，上下文視窗迅速飽和。Harness Engineering 認識到這個瓶頸，提出將任務狀態外部化——不再依賴上下文記憶，而是將進度、決策、長期記憶寫入檔案系統，每次對話重啟時重新讀取。OpenAI 的代理架構正是這種思路的實踐：Memory.md 儲存核心知識、按日期命名的日誌檔案記錄每次對話、Dreams.md 追蹤實驗進度。
Loop Engineering 進一步拓展了這個概念——不是單次任務從開始到完成，而是一個持續的迴圈結構。開發者設定明確的目標與驗證條件，模型則自主執行：接收觸發事件（時間排程或事件通知）→ 執行 Harness 任務序列 → 驗證結果是否符合目標 → 若未達成則迴圈重試 → 達成時記錄並待下一次觸發。Boris Cherny 的觀察凸顯了這種範式轉移的意義：工程師不再逐步提示模型「做這個、再做那個」，而是設計迴圈結構，讓模型自行決定每個步驟。
目標設定的可驗證性是成敗關鍵。布林值條件（編譯成功）最簡單但過於剛硬；規則與指標（網頁載入 <100ms）引入了數值判定；延遲驗證承認某些結果需時間才能確認（如社交媒體互動度）；LLM 評判則容許模型用打分系統自我評估（如 UI 相似度 0.90）；保險絲則防止無限迴圈耗用 token。在矩陣乘法優化的案例中，「速度提升 320 倍」是明確的數值目標，模型循序嘗試型態轉換（Float64 → Float32 → Float16）與核心加速方案，每次改動都記錄在 Markdown 中供審視。這種自主改進的力度遠超手工提示——開發者只需一次性定義目標，模型便可在無人干預下進行深度探索。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
