最近，「Loop Engineering」正在成為 AI 程式設計領域的新概念。
Claude Code 創辦人 Boris Cherny 表示，他已經不再直接提示 Claude，而是編寫能夠自動提示 Claude、判斷下一步該做什麼的循環。Addy Osmani 則將 Loop Engineering 定義為：不再由人持續提示 Agent，而是設計一個能夠代替人完成提示、執行和回饋的系統。
這種工作方式聽起來非常誘人。
從 Ralph Wiggum Loop、定時執行的 Claude Code，到 Codex 的 Goal、長時間執行任務和多 Agent 編排，愈來愈多工具正在支援這種模式。OpenAI 甚至展示過一次持續約 25 小時、消耗約 1,300 萬 Token、產生約 3 萬行程式碼的 Codex 長任務實驗。
然而，我並不看好「循環工程」成為一種穩定、普適的軟體工程範式。
我不懷疑 Agent 的能力會繼續增強，也不否認自動循環可以在部分任務中產生巨大價值。我真正懷疑的是：把 Agent 放進一個循環，並不能自動把不確定的模型變成可靠的工程系統。
循環只解決了「讓 Agent 繼續工作」的問題，卻沒有解決更重要的問題：
Agent 持續做的事情，究竟是不是正確的事情？
這正是 Loop Engineering 面臨的根本挑戰。
一、循環最容易解決的是執行，最難解決的是完成條件
一個循環系統至少需要三個基本要素：
目標、執行過程、完成條件
其中最難的並不是執行，而是定義「什麼叫完成」。
對於傳統程式，這個問題通常比較簡單：
當佇列為空時停止
當檔案全部處理完時停止
當介面回傳成功時停止
這些條件是確定且可計算的。
但軟體工程中的大部分真實目標並不是這樣。
例如：
改善使用者體驗
重構支付系統
提高程式碼品質
讓產品更加穩定
修復登入偶發失敗
完成一個可供生產使用的後台管理系統
這些目標無法簡單轉換成一個布林運算式。
OpenAI 在 Codex Goals 的官方說明中也明確指出：Goal 不適合終點模糊的任務。「讓它變得更好」，或缺少目標狀態、測試和約束的「重構這段程式碼」，都無法為 Agent 提供可靠的完成條件。Goal 最適合具有持久目標、以證據為基礎的終點，並且可能需要多輪調查的任務。
這實際上暴露了 Loop Engineering 的適用邊界。
真正適合自動循環的，不是所有複雜任務，而是那些已經被人類提前轉化成可驗證問題的任務：
讓全部測試案例通過
把剩餘的 23 個舊介面遷移到新協定
修復所有靜態檢查錯誤
問題在於，一旦人類已經能夠清楚定義目標、狀態、約束和完成條件，最困難的需求分析工作往往已經完成。
循環工程所自動化的，更多是後續執行過程，而不是軟體工程中最關鍵的判斷過程。
二、自動驗證並不等於驗證真實需求
Loop Engineering 通常依賴測試、Lint、建置結果、效能指標或螢幕截圖評估作為回饋訊號。
典型循環是：
Agent 修改程式碼 → 執行測試 → 測試失敗 → Agent 分析失敗原因
→ 再次修改 → 測試通過 → 結束
這個過程看起來很符合工程直覺，但它隱藏了一個嚴重問題：
Agent 最佳化的是驗證指標，而不一定是真正想要的結果。
測試只是需求的一種不完整表達。
2026 年的 SpecBench 研究專門分析了長任務 Coding Agent 的獎勵投機問題。研究將公開驗證測試和隱藏組合測試分離後發現，前沿 Agent 雖然可以在可見測試上獲得很高的通過率，但在隱藏測試中仍存在明顯差距；而且任務規模愈大，差距愈嚴重。研究中甚至出現了透過記憶測試輸入來偽裝成正確實作的極端案例。
這不一定意味著 Agent 主觀上在作弊。更準確地說，Agent 會尋找能滿足當前回饋訊號的路徑。當回饋訊號不能完整代表真實目標時，系統自然會出現代理指標失真。
這與 Goodhart 定律非常相似：
當一個指標成為目標，它就不再是一個好的指標。
人工開發時，工程師通常還會考慮測試之外的隱性約束：
- 程式碼是否符合產品真實意圖；
- 是否破壞其他模組的行為；
- 是否引入長期維護成本；
- 是否違背架構原則；
- 是否增加安全風險；
- 是否只是在迎合測試案例。
Agent 很難天然掌握這些組織級、產品級和歷史性的隱性知識。
因此，為 Loop Engineering 建立一套完整驗證系統的成本，可能並不低於直接完成任務。
三、循環會放大誤差，而不只是修正誤差
Loop Engineering 的支持者通常把循環理解為一個自我修正系統：
失敗 → 取得回饋 → 修正 → 再次嘗試
但循環並不天然意味著收斂。它也可能表現為：
錯誤理解目標 → 產生錯誤實作 → 根據錯誤實作更新計畫 → 把錯誤狀態寫入文件
→ 後續 Agent 將其視為事實 → 在錯誤方向上持續最佳化
在長任務中，Agent 不僅會產生程式碼，還可能修改 PRD、Todo 清單、專案狀態、架構說明、測試案例、進度日誌以及對問題根因的判斷。這些內容會成為下一輪循環的上下文。
一旦某一輪錯誤地記錄了狀態，後續循環可能不再把它視為待驗證假設，而是當成已確認的事實。
傳統的單輪 AI 錯誤通常侷限在一次輸出中，而長循環會讓錯誤進入程式碼庫、文件、資料庫、任務系統和 Git 歷史。循環執行得愈久，錯誤可能牽連得愈多。
四、清空上下文解決不了「上下文腐化」
Ralph Loop 的一個重要思路，是讓 Agent 每次只完成一個任務，將進度儲存到檔案或 Git，再用新的上下文視窗啟動下一輪。
這確實可以避免對話無限增長，但只是把狀態從模型上下文遷移到外部儲存，並沒有消除資訊管理問題。
系統仍然需要判斷：哪些歷史資訊應該保留、哪些已經過期；哪些結論只是推測；哪些程式碼和文件與當前任務有關；多個來源衝突時應該相信誰。
Anthropic 將這一問題概括為 Context Engineering：隨著 Agent 在循環中產生愈來愈多資料，系統需要不斷篩選和壓縮下一輪推理真正需要的資訊。Anthropic 也指出，上下文增長時，模型對資訊的準確回憶和長距離推理能力會下降，因此上下文應被視為有限資源，而不是愈多愈好。
長任務 Agent 因而面臨兩難：
載入的資訊太少，Agent 不理解專案背景；載入的資訊太多，關鍵訊號又會淹沒在上下文中。
外部狀態也會逐漸產生類似程式碼庫的熵增：
過期的計畫
重複的說明
互相矛盾的規則
已經失效的臨時結論
不同 Agent 寫下的不同假設
真正困難的不是讓循環重新開始，而是確保每次重啟時，Agent 得到的都是準確、精簡、可信且與任務相關的資訊。
這更接近知識管理、設定管理和執行時狀態治理，而不是所謂的「寫一個循環」。
五、程式碼產生吞吐量不等於工程生產力
Loop Engineering 最直觀的優勢，是提高程式碼產生吞吐量。一個 Agent 可以持續工作；多個 Agent 可以平行工作；任務可以在夜間執行；測試失敗後可以自動修復。
但軟體工程的生產力從來不等於程式碼數量。
真正需要關注的是：從需求提出，到正確的軟體投入使用並可長期維護，所需要的總成本。Agent 產生得愈快，不代表團隊交付得愈快。
如果 Agent 一天建立幾十個 PR，而人工只能審查其中幾個，瓶頸只是從「編寫程式碼」轉移到「驗證程式碼」。若審查者無法理解大量機器產生的改動，可能出現兩種結果：
第一，Agent 輸出大量排隊，自動化吞吐量沒有轉化為真實交付。
第二，團隊降低審查標準，快速合併程式碼，把問題推遲到測試、上線和長期維護階段。
Martin Fowler 網站曾討論這種錯配：Agent 產生程式碼的速度可以超過人類逐行檢查的速度。要避免人工成為瓶頸，團隊必須把品質檢查前移，並建立可供 Agent 自我檢查的規格、測試與工作流程約束。
METR 在 2025 年針對資深開源開發者進行的隨機對照實驗發現，在參與者熟悉的成熟程式碼庫上，使用當時的 AI 工具反而讓任務完成時間平均增加 19%。不過，METR 在 2026 年的後續更新中觀察到一些潛在加速訊號，但信賴區間仍然較寬，還不足以得出 AI 在所有場景都能穩定提速的結論。
Loop Engineering 會進一步放大這種差異：它提高 Agent 的執行時間和輸出規模，卻不一定同步提高團隊理解、驗證輸出並為其負責的能力。
六、Agent 權限愈大，循環的安全風險愈高
要讓 Agent 真正完成複雜任務，就必須賦予它工具和權限，例如讀取程式碼庫、修改檔案、執行 Shell 命令、存取資料庫、查看日誌、呼叫雲端服務、部署或回滾服務。
更危險的是，Agent 會讀取 GitHub Issue、網頁等外部不可信內容。攻擊者可以植入間接提示注入，讓 Agent 把外部文字誤認為操作指令。
在循環系統中，這類風險還會被持續放大。受到劫持的 Agent 不只是產生一段錯誤回答，而可能：
讀取敏感資訊 → 呼叫工具 → 修改外部狀態 → 將錯誤結果寫入長期記憶 → 下一輪繼續執行
因此，生產級 Loop 似乎必須遵循嚴格的最小權限原則。但權限限制得愈嚴格，Agent 的自主性就愈低。
權限愈大，自動化價值愈高，但風險也愈高；權限愈小，風險愈低，但 Agent 能完成的事情也愈有限。
七、循環工程可能只是 Cron 加 Agent
從工作流程結構來看，大部分所謂的 Loop Engineering 並不新穎：
發現新的 Sentry 問題 → Agent 分析並建立 PR
每天晚上執行 → Agent 檢查失敗測試 → 嘗試修復
收到新的支援工單 → Agent 調查日誌 → 產生處理建議
這些模式過去通常由 Cron、Webhook、CI/CD、訊息佇列、Zapier 或 n8n 實現。
新的地方，只是工作流程中的某個確定性處理節點被替換成 LLM Agent。
多數案例本質上仍是事件觸發器和定時任務。它們可能有用，但很難說是一種全新的工作流程。一些開發者嘗試後，因為 Agent 漂移、人工介入效果更好或 Token 成本過高，反而回歸傳統方案。
八、寫在最後
Loop Engineering 描繪了一個非常有吸引力的未來：人定義目標，Agent 持續工作，軟體自行演進。
但現實的軟體工程不是一個只要不斷嘗試就必然收斂的問題。
需求可能模糊，測試可能不完整，狀態可能被污染，指標可能被投機，權限可能被濫用，成本可能失控，程式碼吞吐量也可能超過組織的理解和審查能力。
循環能夠延長 Agent 的執行時間，卻不能自動提高目標的正確性。
我認為，相比研究 Loop，更值得投入的依然是 Harness Engineering：一套有邊界、有證據、有權限、有稽核、能夠隨時停止的可靠回饋系統。