Loop Engineering 是新詞，控制迴圈是老朋友：SRE 視角的 AI Agent 設計觀

2026 年六月起，「Loop Engineering」成了討論度很高的一個詞。它的核心主張是：不要再一句一句去指揮 AI agent，而是設計一個能自己運作的迴圈，讓系統替你下指令。這個想法很誘人，但也帶來疑問：它跟我們已經在用的東西有什麼不同？什麼時候該用？會不會出問題？

這篇文章想換一個角度來看這件事。如果我們把 Loop Engineering 放回「控制迴圈（control loop）」這個更老、也更成熟的脈絡裡，前面那些疑問會清楚不少。控制迴圈是 SRE 與自動化領域用了很多年的概念，它累積下來的一些經驗，剛好可以回答 Loop Engineering 現在還沒講清楚的問題。本文的目的不是重述一次「Loop Engineering 是什麼」，（這類介紹網路上已經很多了），而是透過 SRE 的角度來說明，並用它來想清楚幾個實務上真正重要的問題。

一、Loop Engineering 本質

Google Cloud 的 Addy Osmani 在他那篇被廣泛引用的長文裡，把 Loop Engineering 定義為「把負責下指令的那個人，從你自己換成一套你設計好的系統」。在過去 Prompt Engineering 的模式下，開發者跟 AI 是一來一往的：你提需求、AI 產出、你看完再給下一個指令，人始終是流程的控制者。Loop Engineering 想做的，是把這個控制的角色交給一個迴圈：它會自動發現工作、指派任務、驗證結果、記錄狀態，再決定下一步。實作上它由幾個元素組成：Automation、工作區隔離 Worktree、Skills、Connector、Sub-Agent，以及 State Memory。

這裡有個容易被熱潮蓋過的事實值得先說：這並不是一個全新發明。Anthropic 在 2024 年的《Building Effective Agents》裡，就已經描述過 Evaluator-Optimizer（一個模型產出、另一個模型批判修正）與 Orchestrator-Workers（主代理分派工作給子代理）這類架構，它們本質上都是 agent 迴圈。真正改變的其實是工具的成熟度，一年前你想做這件事，得自己寫一堆 bash script 跟排程，現在這些能力已經直接內建進 Claude Code、Codex 這類產品裡。所以與其說 Loop Engineering 是新技術，不如說它是一種因為工具到位、而變得人人可做的新工作方法。

那麼，從更基礎的角度看，這個「迴圈」到底是什麼？它其實就是一個控制迴圈。控制迴圈是個歷史悠久的概念：系統持續觀測現在的狀態，跟期望的狀態比對，採取行動讓兩者靠近，然後不斷重複這個過程。家裡的恆溫器就是最簡單的例子——量溫度、跟設定值比、太冷就加熱、再量、再比。在我們這個領域，Kubernetes 的 reconciliation loop 做的也是同一件事：它不斷確認「實際跑的容器」是否符合「你宣告的期望」，不符合就動手調整。如果你把控制迴圈裡的「期望狀態」換成「任務目標」、把「控制器」換成「AI agent」，你會發現 Loop Engineering 的骨架，跟 Kubernetes controller 是一樣的。

理解這一點為什麼有用？因為控制迴圈不是一個剛誕生、還在摸索的東西。它已經被研究、被實作、被踩雷很多年，關於「怎麼讓一個自動運作的迴圈不出事」，這個領域早就累積了不少經驗。把 Loop Engineering 看成控制迴圈的一個新應用，等於讓我們可以直接借用這些經驗，而不必從頭再學一次。

二、用幾個對照，把它看得更清楚

要借用控制迴圈的經驗，最快的方式是把 Loop Engineering 的詞彙，對照到 SRE 領域已經有的對應概念。下面這張表，是我覺得最能幫助理解的幾組對照：

Loop Engineering 概念	SRE 對應概念	兩者共同的道理
驗證閘門（Gate）	SLO / 驗收條件	用一個可量測的標準，來定義「做完了」，而不是憑感覺
Token 預算	Error Budget	把有限的資源先定好上限，超過了就該停下來檢討
自我糾正 Hook	自動修復（Self-healing）	用確定的機制把偏差拉回正軌，而不是依賴「記得要檢查」
Sub-Agent 職責分離	職責分離（Separation of Duties）	寫程式的人不該同時當審查的人
State Memory	可觀測的系統狀態	沒有被記錄下來的狀態，就沒辦法被調節
Automation 觸發	控制迴圈的調節週期	持續地比對與修正，而不是執行一次就結束

這裡面我想特別講一下 Gate 閘門。Osmani 有一句話流傳很廣：「沒有閘門的循環，就是一台燒錢機器。」如果用 SRE 的話來講，這就是一個沒有 SLO、沒有保險絲的自動化系統：它跑得越快，只是錯得越快而已。閘門對迴圈的重要性，就像 SLO 對服務一樣：它是你讓「自主」不會變成「失控」的那道防線。一個迴圈值不值得信任，很大程度上取決於它的閘門設計得好不好。

Osmani 還提到一個我覺得很實在的觀察：負責寫程式的 agent，不太適合同時負責審查自己的成果，因為「模型替自己的作業打分數時，往往太寬容了」。比較好的做法，是讓不同的 agent 扮演不同角色，一個探索方案、一個負責實作、一個專門驗證。這其實就是職責分離，跟我們不會讓同一個人既部署又核准上線，是同一個道理。

我自己有一個不太正式的經驗可以印證這點。之前簡單做過一個多 agent 的 Telegram 討論機器人，裡面有不同角色的 agent 各自發言，最後由一個 Moderator agent 來整理出結論。我當初只是單純覺得「讓發言的人跟收斂的人分開」比較合理，並沒有想太多。是後來讀到這些討論，我才回頭意識到，那個 Moderator 扮演的就是驗證閘門的角色，而角色分離正好對應了職責分離。我提這個例子不是要說它做得多好，而是想說明：這些原則其實很自然，當你認真設計一個會自己運作的系統時，往往會自己走到這些地方。

三、幾個容易被忽略的問題

關於 Loop Engineering 的介紹文章大多把重點放在「怎麼建立」，但有三件事比較少被提到，而它們恰好是控制迴圈領域很重視的。

第一是可觀測性。一個能自己運作的迴圈，換個角度看，就是一個「沒有人在旁邊盯著的、長時間運行的工作」。如果它連續跑了幾個小時、改動了幾十個檔案，事後你必須有辦法回答：它在哪一步做了什麼決定、為什麼這樣決定。要做到這件事，就需要完整的執行紀錄、可追蹤的歷程、甚至能夠重播。少了這些，迴圈就不是自動化，而是一個你看不進去的黑盒子——它順利的時候沒事，一旦出錯，你會連從哪裡查起都不知道。

第二是成本。「燒錢機器」這句警語，其實可以更具體地落實成幾個工程手段：對呼叫頻率設限、對總用量設上限、在異常時自動熔斷。這其實就是 error budget 的精神——你在事前就決定「這個迴圈這個月最多花多少」，到了上限就停下來。把成本當成一開始就要設計的限制，而不是等月底帳單來了才驚訝，這在運維上是基本功，自主 agent 也沒有理由例外。

第三是權限與安全。有些文章把「agent 擁有完整的工具存取權限」當成導入迴圈的有利條件，這沒錯，但同一件事也是最大的風險來源。一個能存取程式碼倉庫、資料庫、通訊工具的自主 agent，相當於一組一直在線、而且會自己做決定的權限。一旦憑證外洩、或被惡意輸入誘導，影響範圍可能很大。所以「最小權限」在這個情境下不是一句建議，而是底線——你要很清楚地問自己：這個迴圈真的需要這麼大的權限嗎？能不能只給它完成任務所需的最小範圍？

四、不是每一件事都適合 Loop

在熱潮中，有一個提醒我覺得特別值得記住。《AlphaSignal》指出，其實大部分開發者目前還不需要建立 agent 迴圈。它列出四個條件，必須同時成立，迴圈才划算：任務本身高度重複、驗證已經能自動化、有足夠的 token 預算、而且 agent 有完整的工具存取權限。只要缺了其中一項，建立迴圈很可能只是在增加成本，而不是提升效率。

如果用 SRE 判斷「要不要自動化一件事」的習慣來看，這四個條件其實在講同一件事：這個任務的重複性勞動（toil）夠高，而且可以被安全地自動化嗎？Google SRE 對 toil 的定義是那些手動、重複、可被自動化、又沒有長期價值的工作：這跟上面四個條件幾乎是同一個意思的不同說法。

所以結論其實滿清楚的。適合用迴圈處理的，是像 CI 故障排查、相依套件更新、Lint 修正、把 Issue 轉成 PR 這類高度標準化、而且驗證明確的工作。不適合的，是架構重構、產品設計，以及任何需要大量判斷的事情。這跟自動化領域一向的態度是一致的：自動化的目的，是把人從重複勞動裡解放出來，去做需要判斷的事；而不是連判斷本身也一起交出去。

五、比技術更值得想的兩件事

Osmani 在原文裡提了兩個概念，

一個是「理解債（Comprehension Debt）」。當 agent 產出的程式碼越來越多，而開發者實際讀過的越來越少，團隊對系統整體的理解就會慢慢下降。短期內，開發速度看起來變快了；但時間拉長，可能會走到一個沒有人真正知道系統如何運作的處境。這其實就是技術債的另一種形式——只是這次欠的不是程式碼的整潔，而是團隊腦袋裡的理解。

另一個是「認知投降（Cognitive Surrender）」。當迴圈跑得越來越順，人會很自然地越來越少去思考，久了之後，可能連自己形成判斷的能力都退化了。

這兩件事，其實正是 SRE 文化一直在防範的。為什麼堅持做 blameless postmortem、堅持寫 runbook、堅持把知識留存下來？因為這個領域很早就體會到一件事：自動化可以接手操作，但不能接手理解。一個團隊如果只剩下「按下開始」的能力，卻沒有人能在半夜面對一個出狀況的系統、判斷該怎麼救，那它累積的就不是效率，而是風險。Osmani 講得很準：設計迴圈這件事本身不是答案；當你帶著判斷力去設計它，它是解方；當你用它來逃避思考，它反而會讓問題惡化得更快。同樣的動作，可能帶來完全相反的結果。

對管理者來說，這裡的重點是：Loop Engineering 改變的是工作的形態，而不是把人從工作裡拿掉。工程師不再逐行寫程式，但他們需要轉變成更好的「驗收標準設計者」，以及團隊理解的守門人。如果這個轉變沒有被有意識地帶著走，理解債會在你看不見的地方，安靜地累積起來。

結語

Osmani 那篇文章的結尾有一句話：「建立你的迴圈，但請以一個打算繼續當工程師的人來建立它，而不是只想按下『開始執行』按鈕的人。」

用控制迴圈的角度來說，這句話的意思是：一個好的迴圈，它的設計者永遠保留著踩煞車的能力，也保留著踩煞車的責任。我們不會去部署一個沒有停止開關的自動化系統，也不會去信任一個沒有 SLO 的服務。AI agent 的迴圈，不該是例外。

Loop Engineering 是一個好主意，它讓很多原本用 prompt 在思考的人，開始用系統的方式去思考，這是一件好事。而如果願意把它放回控制迴圈這個更老的脈絡裡，會發現我們手上其實已經有不少可以借用的經驗。剩下的問題，就回到那個一直都在、也一直不容易回答的老問題上：團隊準備好為一群會自己運作的 agent，建立一套真正可控的機制了嗎？

參考來源：
Addy Osmani,《Loop Engineering》（addyosmani.com）
Anthropic,《Building Effective Agents》(2024)
Google,《Site Reliability Engineering》（SRE Book）
AlphaSignal,《Most Developers Do Not Need Agent Loops》