Loop Engineering 是什麼？AI Agent 時代的迴圈工程完整解析
Loop Engineering（迴圈工程）由 Addy Osmani 於 2026 年 6 月提出，指把「一直對 AI Agent 下提示的人」換成一套系統：由它找出待辦工作、派給 Agent、驗證結果、記錄進度並決定下一步，需定義觸發條件、目標、工具、驗證方式、停止規則與狀態保存。Andrew Ng 另提出三個以不同速度運轉的關鍵迴圈。
從 Prompt Engineering 到 Loop Engineering：工程重心的第三次轉移
2021 到 2023 年，業界的焦點是 Prompt Engineering：怎麼把一句提示詞寫好，讓模型一次給出可用的答案。2025 年 2 月，Andrej Karpathy 提出 Vibe Coding，工程師開始習慣讓 AI 寫第一版程式碼、自己負責收尾。那個階段的人與 AI 比較像保母帶小孩：AI 動手做，人在旁邊全程盯著，隨時準備接手收拾。2026 年 6 月，Addy Osmani 發表〈Loop Engineering〉，Andrew Ng 隨後稱它是當紅的熱門詞；隨著 Claude Code、Codex 這類 agentic coding 工具成為日常，Loop Engineering（迴圈工程）快速在開發者社群流傳。要提醒的是，這三者是逐層疊加的工作方式，不是按年份互相取代。
這個轉移背後的邏輯很直接：模型生成單次程式碼的成本持續下降，但讓 Agent 反覆跑迴圈，會把 token、工具呼叫與人工審查的成本一起放大。稀缺的資源因此從「寫得出程式碼」，變成「在有限預算內把迴圈設計得可靠」。在同一個模型之下，工具、脈絡管理、驗證方式與停止條件都會明顯左右最終結果；模型能力與迴圈設計是同樣重要的兩個變因。
Loop Engineering 是什麼？
提出這個詞的 Addy Osmani 給了一句很精準的定義：迴圈工程就是把「那個一直在對 Agent 下提示的人」換掉，改由你設計一套系統來做這件事。這套系統負責找出待辦工作、派給 Agent、檢查結果、記錄進度，然後決定下一件事。實作上它要講清楚六件事：什麼條件觸發、目標是什麼、可以用哪些工具、如何驗證、什麼時候該停、狀態存在哪裡。
它把「AI 一次就要答對」的期待，換成「AI 在一個設計好的迴圈裡持續逼近正確」的工程結構。
用生活一點的比喻：Loop Engineering 就是把自己從保母的位置換到教練的位置。教練不會下場替學員跑步，而是設計訓練菜單、設好過關標準，讓學員在一次次練習與回饋中自己變強。人不再盯著 AI 的每一步，改成盯著關卡設計得對不對。
單次提示像是拋硬幣：你把需求丟給模型，祈禱結果可用。迴圈則像是裝了回饋控制器的系統：每一輪的輸出都會被檢驗（跑測試、編譯、比對規格），檢驗結果回饋給 Agent 作為下一輪的輸入。模型會犯錯不要緊，重點是錯誤能不能被迴圈捕捉並修正。
Andrew Ng 的三層巢狀迴圈
AI 領域學者吳恩達（Andrew Ng）分享過他做 0 到 1 產品時的三個關鍵迴圈。它們彼此銜接、以不同速度運轉，可以理解成由內而外的三個層次：
- Agentic Coding Loop（每幾分鐘一輪）：由 AI Agent 自己運轉：寫程式、跑測試、看結果、修正，直到符合規格。當規格、測試與權限邊界都夠清楚時，這一層可以大幅減少人工逐步介入；但高風險操作仍應保留審核或停止條件。
- Developer Feedback Loop（十分鐘到小時級）：由工程師運轉：審查 Agent 的產出、修正方向、更新規格。工程師的角色從「寫程式的人」變成「駕駛迴圈的人」。
- External Feedback Loop（小時到週級）：由真實世界運轉：測試用戶、A/B 實驗、上線後的生產數據，回頭修正產品方向。
這三層就像一間餐廳的運作：內場廚師照著 SOP 出菜並自我檢查是內層，主廚巡場試菜、調整配方是中層，市場口碑與訂位量回頭決定菜單方向是外層。三層迴圈的速度差，正是分工的依據：能自動驗證的交給最快的內層迴圈，需要人類判斷的放在中層，需要市場驗證的放在外層。Loop Engineer 的工作，就是決定什麼事情放進哪一層迴圈、每層迴圈的驗證器怎麼設計。
常見的四種迴圈模式
實務上，迴圈設計已經沉澱出幾種可複用的做法。以下沿用 MindStudio 的整理，四種模式分別適合不同型態的任務；要說明的是各家框架的命名並不統一，這不是正式標準：
- Retry（重試迴圈）：最簡單的形式：失敗就帶著錯誤訊息重來。適合有明確成功判準的任務，例如程式編譯、格式驗證。實作時務必設定重試上限與「沒有進展就停」的條件，否則原封不動地一直重試只會燒掉預算。
- Plan-Execute-Verify（規劃-執行-驗證）：先讓 Agent 產出計畫，逐步執行，每步驗證。適合多步驟的複雜任務，例如資料管線建置。
- Explore-Narrow（發散-收斂）：先平行嘗試多個方向，再由評審機制收斂到最佳解。適合解法空間大的問題，例如架構設計、文案生成。
- Human-in-the-Loop（人類在迴圈中）：在關鍵節點設置人類審核閘門。Agent 會走進死路、誤讀限制條件，或需要領域判斷；好的迴圈設計讓人可以暫停流程、修正方向、補充脈絡，而不必整個重來。這需要系統本身能保存執行狀態，並不是每個工具都內建這個能力。
舉一個具體的例子：假設要 Agent 產出一份月度輿情報告。Retry 模式會在報告缺少必要章節時自動重寫；Plan-Execute-Verify 會先列出「抓取資料 → 統計聲量 → 撰寫摘要 → 產出圖表」四步，每步完成後檢查產物是否存在且格式正確；Explore-Narrow 可以讓三個 Agent 各寫一版摘要再由評審模型選優；而 Human-in-the-Loop 則在報告送出給客戶之前，設一道分析師審核的閘門。同一個流程可以同時採用多種做法，例如先規劃、每步設有限次重試，並在對外送出前加一道人工核准。要注意這種組合和前面 Andrew Ng 的三個迴圈是兩回事：前者講的是單一流程裡的設計手法，後者講的是產品開發的三種回饋節奏。
為什麼企業現在就該理解 Loop Engineering
這不只是開發者圈的新流行語，它對企業導入 AI 有三個直接的含意：
1. 評估 AI 工具時，看迴圈而不是看模型
兩個掛著相同模型的產品，體驗可以天差地遠，差別就在迴圈：有沒有自動驗證？錯誤怎麼回饋？人類介入的介面好不好用？企業選型時應該把「迴圈設計」納入評估清單，而不是只比較模型跑分。
2. 內部流程自動化，從「可驗證的任務」開始
迴圈需要驗證器才能運轉。報表格式對不對、數字加總是否一致、文件是否包含必要欄位，這類有明確判準的任務，最適合先交給 agentic 迴圈。反之，判準模糊的任務（例如策略判斷）應該保留人類在迴圈中的位置。
3. 知識要能回流，下一輪迴圈才不必從零開始
每一輪迴圈產生的錯誤、修正與決策脈絡，都是有價值的組織知識。如果這些脈絡散落在對話紀錄裡，每次都得從零開始；如果能沉澱成經過篩選與版本管理的知識庫，後續迴圈就能重用既有脈絡。要說清楚的是，這改善的是 AI 拿得到的脈絡，不代表模型自己變聰明了；沒有篩選就把錯誤與過期決策一起存進去，反而會污染後面的判斷。這正是企業知識管理系統（如 RAGi 這類企業 RAG 平台）在 agentic 時代的新角色：不只回答員工的問題，更是 AI 迴圈取用長期脈絡的地方；會議與決策脈絡的整理（如 AIMochi）則讓人類這一層迴圈的判斷得以被記錄與傳承。
值得注意的是，迴圈不是越自動越好。在金融、公部門這類受監管的場景，是否必須逐件人工核准，要看具體用途、風險等級與適用法規而定；即使沒有逐件審核的義務，通常仍需建立責任分工與可稽核的紀錄：誰批准了什麼、依據什麼資訊。這也是為什麼在企業環境裡，迴圈基礎設施必須同時解決「自動化」與「可追溯」兩件事：迴圈每一輪的輸入、輸出與人類決策，都應該像程式碼的版本控制一樣可以回放。缺了這一層，agentic 自動化的規模越大，治理的風險就越高。
給不同角色的行動建議
- 工程師：練習把工作拆成「可自動驗證」與「需要人工判斷」兩類，前者設計成迴圈交給 Agent，後者專注做好 review。你的價值正在從寫程式碼轉移到設計與駕駛迴圈。
- 技術主管：重新檢視團隊的 Definition of Done。若希望迴圈能無人值守地自行收工，成功條件就要盡量寫成機器可驗證的形式；涉及主觀判斷或高風險決策時，Definition of Done 本來就可以包含一道人工核准。
- 企業決策者：導入 AI 的投資重點，正在從「買最強的模型」轉向「建立可驗證、可回饋、可累積知識的迴圈基礎設施」。先盤點哪些流程有明確判準，從那裡開始。
結語
Prompt Engineering 教我們怎麼對 AI 說話，Loop Engineering 教我們怎麼跟 AI 協作。當模型能力持續進步、token 成本持續下降，企業與工程師之間真正的差異化能力，會落在迴圈的設計上：驗證器夠不夠嚴謹、人類介入的時機對不對、知識有沒有沉澱回系統。對企業來說，「會用 AI」需要的能力也正在擴大：除了會下提示詞，還要能設計驗證、設定停止條件、管好權限，並讓知識回流到下一輪迴圈。
參考資料：Addy Osmani: Loop Engineering、Andrew Ng 談他的三個關鍵迴圈、MindStudio: What Is Loop Engineering?、The Agentic Loop: A Practical Field Guide、Loop Engineering Guide (2026)