Loop Engineering from First Principles — Kyle Mistele, HumanLayer

• 1

  問題根源：盲目迴圈的失敗模式

• 2

  業界普遍認為可以直接把提示詞丟進迴圈給編碼代理，透過多個驗證器檢查，但最後仍產生40000行無人敢審查的PR。這種方法在獨立開發或非關鍵系統中可行，但對有真實客戶、服務等級協議、合規要求的團隊系統來說完全不適用。

• 3

  控制論的核心應用

• 4

  將程式碼庫視為動態系統，建立感測器（測量當前違規）→控制器（決定增量改變策略）→執行器（Agent執行改變）的反饋迴圈。好的控制器會選擇風險最低的改變（如最小的程式碼單元），避免一次過度改變導致系統不穩定。

• 5

  人類融入迴圈的低摩擦設計

• 6

  透過版本控制的反饋檔案（Markdown格式）讓人類在不改動迴圈基礎設施的情況下，用slash指令動態調整迴圈行為。每個迴圈workflow被標籤化，使用者留下`/iterate`評論時，迴圈自動載入PR差異、評論、反饋文件進行修正。

• 7

  流量控制與加速策略

• 8

  設定流量控制確保同時最多一個迴圈PR開啟（檢查前一個PR是否被人類審查），避免堆積重複工作。加速時可多工執行（同時遷移3-5個程式碼單元、分多個實現階段、或由多人分別執行），每個階段各有獨立context window。

• 工具與技術
• AST Grep：語言無關的模式匹配工具，掃描程式碼庫找出違反規則的模式（如未遷移的程式碼單元）
• GitHub Actions / GitLab CI / CircleCI：執行迴圈workflow，有程式碼存取、密鑰存取、排程原始碼
• React Doctor（Aiden By's）：混合感測器與控制器，同時診斷問題與提供修復建議
• Markdown反饋檔案：版本控制中追蹤的指令文檔，Agent每次執行前載入
• 迴圈設計流程
• 感測器（Sensor）：用AST Grep掃描全庫，找出違規模式清單並排序
• 防守機制（Disturbance Dampener）：main分支設定基準線，每個PR檢查是否引入新違規
• 控制器（Controller）：決定優先順序（最簡單、最多錯誤、最差instrumentation的程式碼單元）
• 執行器（Actuator）：Agent + Skill組合，執行遷移並建立PR
• 人類反饋：用`/iterate`指令觸發PR comment listener，loop重新處理
• 實踐案例數據
• 人物：Kyle（Human Layer聯合創始人）
• 遷移目標：150個RPC程式碼單元遷移至Effect框架
• 時間估算：逐個遷移需6個月；改為一日一PR排程後，確保每天一次增量改進
• 排程：GitHub Actions每日執行一次workflow
• 流量控制邏輯
• ```
• if (exists open PR with loop label):
• shut down workflow
• else:
• execute sense→control→actuate→create PR
• ```

“用控制論設計AI迴圈比盲目堆疊代理更務實：增量改進、人類可審查、低成本反饋，才能在真實系統中確實獲得AI加速的好處。”