企業級的迴圈工程（Loop Engineering）

過去三年，應用 AI 領域最受矚目的技能是 prompt engineering——把一句話寫得夠好，讓模型第一次就把事情做對。但在 2026 年 6 月的第二週，這個框架悄悄地不再是最有意思的問題。投入 OpenClaw agent 專案的 Peter Steinberger 提出，如今真正關鍵的技能，是設計驅動 agent 的那層迴圈，而不是迴圈裡的那句 prompt。隔天，Google 的 Addy Osmani 發表了一篇文章，替這套實作正式命名：Loop Engineering（迴圈工程）。

這個區別並不只是換個說法。一句 prompt 是單一回合；一個迴圈則是一種控制結構——agent 行動、觀察結果、決定下一步，然後反覆進行，理想上一路跑到目標真正達成，而不是跑到操作者失去耐心為止。設計的單位，從「一句話怎麼寫」，移到了「包在它外面的整個流程長什麼樣」：agent 朝什麼目標前進、用什麼訊號校準、又在什麼條件下該停。

這個重新框定，在企業場景裡最為要緊——因為 agent 如今會無人看管地，對著正式環境系統一口氣跑上數分鐘、甚至數小時。在我們的導入經驗裡，這個模式一再出現：絕大多數的 agent 失效，是迴圈設計的失效，而不是模型的失效。把一個能力很強的模型，放進一個沒有可驗證終止條件的迴圈，它只會空轉、發散，或把預算燒光；把一個能力普通的模型，放進一個設計良好的迴圈，它會收斂到一個可驗證的結果，然後停下來。團隊往往一直在升級模型，其實該修的是迴圈。

本白皮書把 Loop Engineering 當成一門正式環境的工程紀律來談。內容涵蓋：把可靠迴圈與失控迴圈區隔開來的兩項要件、我們最常見到的反模式、能把它們收住的設計模式、迴圈在程式撰寫以外的落點，以及如何治理那些無人看管的迴圈。最後，以一份檢查清單作結——一份能讓你願意把迴圈丟著、讓它跑一整晚的清單。