AI 寫程式總是不穩定？Loop Engineering 可能是下一步解法

最近圍繞 OpenClaw 作者引發的「Loop Engineering」討論，表面上是在談 AI Coding 的新玩法，實際上更像是在重新發現 Kubernetes 社群十幾年前已經走過的一條路：用持續回饋的控制循環，讓系統不斷逼近期望狀態。

如果把過去兩年 AI 編程工具的發展串起來，可以看到一條清楚的遷移路徑：從 Prompt Engineering，到 Context Engineering，再到 Loop Engineering。最初大家關心如何寫好 prompt，後來發現真正影響 Agent 表現的是上下文、工具、記憶和環境。再往後，問題又變成了：即使上下文足夠，Agent 仍然不穩定，怎麼辦？

答案不是讓模型一次「想對」，而是讓它在觀察、行動、驗證、修正的循環裡逐步收斂。

這正是 Kubernetes 的基本世界觀。

從一次呼叫到持續循環

真實的軟體開發從來不是一次推理。它通常是這樣發生的：

1. 讀程式碼。
2. 理解目標。
3. 修改實作。
4. 編譯或執行測試。
5. 發現偏差。
6. 繼續修正。
7. Review。
8. 再修復。
9. 直到達到可接受狀態。

這不是「prompt -> answer」，而是「goal -> loop -> evaluation -> feedback」。Loop Engineering 的價值就在這裡：它不再把 AI Coding 理解成自動生成程式碼，而是理解成自動逼近目標。

早期的一些實踐已經很接近這個方向。比如用一個循環不斷喚起 Claude Code，讓它從倉庫、計畫文件和 Git 狀態裡重新讀取現狀，再推進一個小任務。這裡有一個很關鍵的經驗：Agent 會忘，倉庫不會忘。對話歷史是不可靠的，落盤狀態才是下一輪循環可以依賴的事實。

Kubernetes 已經證明過這套模式

很多人把 Kubernetes 理解成容器編排平台，但它更深層的貢獻，是把控制論帶進了軟體工程。

Kubernetes controller 做的事情可以概括成四步：

1
2
3
4
5

Desired State
  -> Observe
  -> Compare
  -> Act
  -> Repeat

也就是 Reconciliation Loop。Controller 反覆檢查實際狀態是否等於期望狀態。如果不一致，就繼續調節。

比如你聲明：

1

replicas: 3

你並不告訴 Kubernetes「啟動第一個 Pod、再啟動第二個 Pod、再啟動第三個 Pod」。你只是聲明期望狀態。至於當前有幾個副本、哪些 Pod 死了、是否需要補齊，都是 controller 自己在循環中處理。

AI Coding 正在形成類似結構。你不再一步步命令 Agent 打開某個文件、修改某個函式、加入某個測試，而是聲明一個目標：修復這個並發問題，並確保測試通過。Agent 負責觀察倉庫、修改程式碼、執行驗證、讀取回饋，再繼續下一輪。

Prompt 正在變成 Spec。

Loop Engineering 的元件

一個可用的 Loop Engineering 系統，通常會包含幾類東西：

• 自動觸發：定時器、cron、webhook、GitHub Actions，讓循環不依賴人工按鈕。
• 隔離工作區：透過 Git worktree 等方式，讓多個 Agent 並行工作而不互相踩踏。
• 專案知識：用 SKILL.md、AGENTS.md、規範文件和任務文件，把經驗固化成可重複讀取的上下文。
• 工具連接：透過 MCP、外掛、CI/CD、Issue 系統和資料庫，讓 Agent 能觀察真實環境。
• 子 Agent：把 maker、checker、reviewer 拆開，避免模型自己給自己打分。
• 外部狀態：用 Markdown、Issue、Git 提交或任務板記錄進度，讓循環可以被殺死、重啟和接續。

這些元件合在一起，很像 AI 時代的控制平面。模型只是執行器，真正決定系統能力的是循環如何組織、狀態如何保存、回饋如何進入下一輪。

相似之外，差異更重要

Loop Engineering 和 Kubernetes controller 結構相似，但二者並不等價。最關鍵的差異在於：Kubernetes 控制的是相對確定的系統，而 LLM 循環控制的是機率系統。

Kubernetes 建立一個 Pod，動作結果通常是可預測、可觀測、可重試的。LLM 接到同一句「修復支付系統並發問題」，今天可能這樣改，明天可能那樣改；Claude 和 GPT 也可能給出完全不同的方案。

這帶來幾個難題：

• 執行器不確定：同一輸入不保證同一輸出。
• 收斂不可證明：循環可能反覆修改、原地打轉，甚至把已經修好的東西改壞。
• 完成判斷不可靠：模型說「任務完成」，不代表真的完成。
• 目標常常模糊：「優化支付系統」到底是優化效能、穩定性、安全性，還是可維護性？
• 驗證成本很高：測試通過不等於沒有效能退化、安全漏洞或架構債務。

所以 AI Coding 比 Kubernetes Operator 更難。它不只需要 reconcile，還需要更強的 goal definition 和 evaluation system。

Maker-Checker 像 Admission Controller

為什麼現在越來越多 Agent 系統要拆成 maker 和 checker？原因很簡單：不能完全相信執行器。

寫程式碼的 Agent 可能會自我確認。它會說「已經修復」，但測試沒跑全；它會說「方案更簡潔」，但實際引入了新風險。於是需要另一個獨立角色來審查它：執行測試、檢查 diff、做安全掃描、讀日誌、判斷是否真的滿足目標。

這和 Kubernetes 裡的 Admission Controller、Validating Webhook 有相似的工程直覺：不要讓執行動作直接進入系統，要先經過策略、驗證和約束。

未來的 Agent 系統大概率會越來越多層：

1
2
3
4
5

Maker
  -> Checker
  -> Reviewer
  -> Policy Engine
  -> Human

這不是把流程複雜化，而是在機率執行器外面補控制系統。

真正的上限在 Goal 與 Evaluation

Loop Engineering 的核心不只是設計循環。更深一層看，它真正要解決的是 Goal 和 Evaluation。

Kubernetes 之所以能穩定工作，是因為 Desired State 被形式化了。replicas: 3 的完成條件非常清楚：實際副本數等於 3。這裡沒有審美判斷，也沒有「差不多完成」。

AI Coding 最大的問題恰好在這裡。很多目標是模糊的：

• 「幫我優化這個系統。」
• 「重構使用者模組。」
• 「修復線上穩定性問題。」
• 「讓這段程式碼更好維護。」

這些目標如果不被拆成可觀察、可驗證、可停止的條件，循環就很難收斂。Agent 不知道什麼時候該繼續，也不知道什麼時候該停。

更合理的寫法應該接近這樣：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

goal:
  description: "修復支付系統的並發問題"
  metrics:
    correctness:
      unit_test_pass_rate: "100%"
      integration_test_pass_rate: "100%"
    performance:
      latency_p99: "< 100ms"
      throughput: ">= 1000 tps"
    safety:
      critical_vulnerability: 0
      data_race: 0

evaluation:
  layers:
    - unit_test
    - integration_test
    - e2e_test
    - benchmark
    - static_analysis
    - security_scan
  judge:
    model: "independent-checker"
    threshold: "all_layers_pass"

loop:
  max_iterations: 20
  strategy: "exponential_backoff"

到了這一步，大家寫的就不再是 prompt，而更像 Agent CRD。真正重要的欄位也不是選 Claude 還是 GPT，而是 goal.metrics 和 evaluation.layers。

軟體工程師會更像控制系統工程師

這場變化不一定意味著 AI 會直接替代工程師。更可能發生的是，工程師的工作重心發生遷移。

過去，工程師主要寫程式碼。未來，工程師會更多設計目標、驗證、狀態和回饋：

• 把模糊業務意圖翻譯成可收斂的目標。
• 設計多層 Evaluation Pipeline。
• 把 Agent 的記憶從對話裡移到倉庫、任務板和持久化狀態裡。
• 設計 maker、checker、reviewer 的邊界。
• 定義終止條件和失敗重試策略。
• 判斷什麼必須交給人類最終確認。

Prompt Engineer 可能會逐漸退場，不是因為 prompt 沒用，而是因為寫 prompt 這件事本身會被系統化。更稀缺的能力會變成 Goal Engineering 和 Evaluation Engineering。

結語

Loop Engineering 並不是憑空出現的新概念。它更像控制論、狀態機、回饋系統、Kubernetes controller 和 Operator Pattern 在 AI Coding 時代的一次復活。

理解這場變化，可以分成四層：

1. 結構相似：Loop 類似 Operator。
2. 實現相似：Agent 類似 Controller。
3. 本質相似：Goal 類似 Spec，Evaluation 類似 Status。
4. 最重要的一層：AI Coding 不是自動化寫程式碼，而是自動化逼近目標。

一切自動化逼近目標的系統，最終都會回到控制論：目標是否清楚，狀態是否可觀察，回饋是否準確。

所以，未來十年 AI Native 軟體工程最值得研究的問題，可能不是「哪個模型更強」，而是：當軟體開始自己修改自己時，我們該如何設計那個約束它、驗證它、糾正它，並最終決定是否信任它的控制循環？