前言

最近接連研究了 Agent Skills 與平行執行 coding agent 的工具。當 skill 已經能保存工程流程、Git worktree 也能隔開多個任務，下一個問題自然會出現：難道每天還是要由人打開工具、檢查 CI 與 issue，再逐次告訴 agent 接下來做什麼嗎？

cobusgreyling/loop-engineering 想處理的正是這一層。它主張不要只研究如何寫出更好的單次 prompt，而要設計一個能定期發現工作、保存上次結果、安排 agent、驗證產出，必要時停下並交給人的開發迴圈。

這聽起來很像「讓 AI 自己一直寫程式」，但我研究完整個專案後，認為它真正有價值的地方反而是限制：哪些工作可以重複、一次最多做多少、什麼檔案不能碰、失敗幾次必須停，以及哪些決定永遠要由人負責。

Loop Engineering 是什麼？

Loop Engineering 不是新的 AI 模型或 coding agent。它是一套 reference repository，裡面包含設計方法、七種常見 pattern、不同 agent 的 starter、Agent Skills，以及用來評分、估算成本、管理狀態、建立 worktree 與執行安全規則的 CLI 工具。

官方對 loop 的描述可以整理成以下流程：

  1. 排程或事件觸發一次執行。
  2. Triage skill 讀取 CI、PR、issue 與上一次 state。
  3. 將值得處理與等待人決定的項目寫回持久狀態。
  4. 需要修改程式時，建立隔離的 Git worktree。
  5. Implementer agent 進行最小範圍修改。
  6. 另一個 verifier agent 執行測試與規則檢查。
  7. 透過 GitHub、ticket 或 MCP connector 回報或採取動作。
  8. 低風險且符合 allowlist 才繼續，其餘情況交給人。
  9. 下一次排程再從更新後的 state 開始。

官方 README 的架構圖 很容易讓人只注意到多 agent orchestration，但真正把一次性 agent 變成 loop 的，是「下次還知道上次發生什麼」與「有明確停止條件」。如果沒有這兩件事，只是定時重跑一段很長的 prompt。

從 Prompt Engineering 到 Loop Engineering

單次 prompt 通常依賴人維持上下文：人發現問題、選擇優先順序、補充限制、判斷結果，再決定下一步。Loop Engineering 則嘗試把其中可重複的部分寫進系統。

例如每天早上，開發者可能依序做這些事：

  • 查看 main 的 CI 是否失敗。
  • 找出長時間沒人 review 的 PR。
  • 確認昨天新增的 issue 是否需要立即處理。
  • 回想昨天已經試過哪些方法。
  • 把真正重要的事項貼到 Slack 或 standup 筆記。

這不是一個「幫我修完所有 bug」的模糊目標，而是範圍清楚、會反覆發生、輸出可以檢查的工作，因此很適合先設計成 Daily Triage loop。

差別可以這樣看：

層次 解決的問題 持續時間
Prompt 這一次要 agent 做什麼 單次對話
Skill 這類工作應遵守什麼流程與規則 跨任務重用
Harness 單次 agent 在哪些工具、權限與環境中執行 單次 session
Loop 何時重跑、如何記住狀態、如何驗證與停止 跨多次執行

Concepts 文件 也特別區分 harness 與 loop：harness 管理單次執行環境，loop 則在其上加入 schedule、state 與 verification chain。這個專案可以協助設計與建立 loop；如果要把 loop 變成有版本、trace 與 session 的 runtime，官方另外導向 harness-foundry，並不是全部塞在同一個 repository 裡。

五個 Building Blocks，再加一條記憶主幹

Automations／Scheduling

排程是 loop 的心跳，可以來自 Codex Automations、cron、GitHub Actions 或其他 scheduler。重點不只是「每隔多久執行」，還包括第一次是否立即執行、重開機後是否持續、沒事可做時能否快速結束，以及什麼情況應自動停用。

Git Worktrees

只要 loop 會修改程式，就不應和人的工作目錄或另一個 agent 共用 checkout。每次 attempt 使用獨立 worktree 與 branch，失敗時可以丟棄，平行工作也不會直接踩到同一份檔案。

專案中的 loop-worktree 不只包裝 git worktree add，還用 manifest 記錄 run、branch、建立時間與狀態，提供 cleanup、過期清理與 path lock。實際程式會建立 loop/<run-id> branch；新版 lock 也有重疊路徑與 deadlock 檢查。原始碼 顯示它確實是可執行工具，不只是一份操作建議。

不過 worktree 只是 Git 工作目錄隔離，不是 OS sandbox。Agent 仍可能讀取環境變數、SSH key 或操作外部 API；repository 以外的副作用，也不能靠刪除 branch 復原。

Agent Skills

Skill 保存專案慣例、build 與 test command、review 標準，以及「曾經因為什麼事故，所以不要再這樣做」的背景。沒有 skill，每次排程都可能重新猜一次團隊意圖。

Loop Engineering 內建的 loop-triage、minimal-fix、loop-verifier、loop-budget 與 loop-constraints 是起點，實際導入時仍應改成符合自己的 repository，而不是原封不動把通用規則當成公司政策。

Plugins／Connectors（MCP）

Connector 讓 loop 能讀取 GitHub、Linear、Slack 或其他真實工作系統。這會讓 loop 從「在 Markdown 建議下一步」進展到「更新 ticket、留言或建立 PR」，也同時放大權限風險。

官方安全建議是每個角色使用最小權限：GitHub bot 可以讀 issue、PR、check，寫入能力先限於 comment 與 label；merge 不應預設開放。資料庫則不應讓一般 loop 直接寫 production。Safety 文件 有更完整的權限範例。

Sub-agents

專案把 maker／checker split 視為可靠 loop 的核心：寫程式的 implementer 不應自己判斷工作是否完成，應由另一個 agent 以不同指令、必要時較強的模型執行測試與找出拒絕理由。

這不代表多一個 agent 就一定可靠。如果 verifier 只回答「看起來沒問題」、沒有真的執行測試，仍只是專案所說的 verifier theater。分開 session 是結構條件，清楚的驗收標準與可重現測試才是品質條件。

Memory／State

模型不會自然記得昨天的獨立 session，因此 loop 必須讀寫 STATE.md、ticket board 或資料庫。好的 state 至少回答三件事：現在處理什麼、上次試過什麼、什麼事情正在等人。

State 也必須整理。若每次只新增、不清除已合併 PR 與已關閉 issue，agent 會對不存在的問題採取動作。這就是專案 failure catalog 所稱的 state rot。Five Primitives + Memory 因此把 state 稱為整個 loop 最重要的產物之一。

用 Daily Triage 看一次完整演進

我認為最容易理解這個專案的方法，不是直接開啟自動修 bug，而是從每天一份報告開始。

第一週的 Codex Automation 可以只執行：

Run $loop-triage on this project. Read STATE.md if present.

Update High Priority, Watch List and Last run in STATE.md.
Week 1: report only. Do not modify source files.
Flag ambiguous items for the Triage inbox.

每天由人核對 STATE.md：它有沒有找到真正重要的 CI failure？Dependabot 是否被誤判成高優先？已處理項目有沒有被正確清除？這段 report-only 時期看似沒有自動寫 code，實際上是在校準 triage 規則。

當多次結果都穩定後，第二階段才開放非常狹窄的動作，例如「只處理單一檔案、原因明確的測試失敗」：

  1. Triage 判定項目符合範圍。
  2. loop-worktree 建立隔離 branch。
  3. Implementer 產生最小修改。
  4. Verifier 在 worktree 執行測試並檢查修改範圍。
  5. loop-gate 檢查 denylist、檔案數與 auto-merge allowlist。
  6. 建立 PR，仍由人 review；模糊或超出範圍就升級。
  7. 將嘗試、結果與等待事項寫回 state 和 run log。

Daily Triage pattern 建議先跑一至兩週 report-only。官方 story 也記錄一個案例：連續十次穩定後，才加入 minimal-fix 與 verifier，並把範圍限縮為單檔 test failure。這種「先證明發現工作是準的，再授權採取小動作」比直接追求全自動更符合實際團隊導入方式。

七種現成 Pattern

Repository 目前整理了七種 production pattern：

Pattern 用途 第一週建議 成本
Daily Triage 彙整 CI、issue、PR 與近期變更 L1 報告 低
PR Babysitter 追蹤 review、check 與停滯 PR L1 監看 高
CI Sweeper 分析失敗並嘗試小型修正 非常保守的 L2 非常高
Dependency Sweeper 檢查與測試 dependency update 僅 patch 範圍 中
Changelog Drafter 依 commit、PR 或 tag 產生草稿 L1 草稿 低
Post-Merge Cleanup 找死碼、文件與合併後清理事項 L1、離峰執行 低
Issue Triage 分類、去重與建議 label／owner L1、只提案 低

這些 pattern 的 cadence 差異很大。Daily Triage 每天一次可能只產生一份報告；PR Babysitter 或 CI Sweeper 若每五分鐘執行，則一天最多觸發 288 次。是否能在沒有 actionable item 時提前退出，常常比單次 prompt 是否節省幾百 token 更重要。

不只是文件：CLI 工具如何補上控制面

專案的工具鏈大致可分成四組：

階段 工具 作用
建立 loop-init Scaffold pattern、skills、state、budget 與 constraints
評估 loop-audit、loop-cost、loop-sync 評分 readiness、估算 token、檢查文件與 state 漂移
執行 loop-context、loop-worktree、MCP server 保存嘗試、控制重試、隔離修改與提供 runtime 查詢
治理 loop-gate 機械式執行 denylist、檔案數與 auto-merge allowlist

其中 loop-context 很值得注意。它不是只把聊天摘要壓短，而是會比較最近的錯誤與動作；相似錯誤重複、連續無進展、達到 token budget 或 max iterations 時，會回傳停止並交給人的結果。Circuit breaker 原始碼 將「不要永遠重試」做成可測試的程式邏輯。

loop-gate 也不是期待模型記得安全文件。它讀取 gate.yaml，先檢查敏感路徑，再檢查變更檔案數；若動作是 auto-merge，每一個路徑還必須符合 allowlist，否則要求 human review。Gate implementation 展示了自然語言規則如何再補上一層機械式 enforcement。

L1、L2、L3 不是 Agent 能力等級

Loop Engineering 用四個 readiness level 描述自治程度：

  • L0 — Draft：只有目的與範圍。
  • L1 — Report：能 triage 並更新 state，不自動修改。
  • L2 — Assisted：在隔離環境做小修正，由 verifier 檢查並交給人核准。
  • L3 — Unattended：可以不持續盯場，但完整 budget、log、denylist、觀測與 human gate 都必須存在。

這裡的 L3 不是「模型變聰明」，而是系統有足夠的邊界與回饋。即使到了 L3，security、authentication、payments、PII、production infrastructure、dependency upgrade 與多次失敗等高風險情況仍應回到人手上。

Loop Ready Score 是 Checklist，不是安全認證

loop-audit 會檢查 STATE.md、triage 與 verifier skill、LOOP.md、GitHub workflow、MCP、worktree、safety、budget、run log、constraints、最小權限、停滯偵測、升級路徑與真實執行紀錄，再計算 0 到 100 分。

我從查核 commit 建置工具後，直接對 repository 自己執行 audit，得到 100 分與 L3；同一份報告仍警告沒有 .foundry/stack.yaml。這個結果很能說明分數的正確用途：它是專案自行定義的結構性檢查，能找出漏掉的基礎設施，但不能證明 verifier 真的懂業務、測試沒有盲點、權限配置安全，或這個 loop 已經可以 auto-merge。

官方自己的失敗文章也明確寫出「Score 不等於 permission」。一個 CI Sweeper 在沒有獨立 verifier、branch allowlist 與硬性每日 token 上限的情況下，以 15 分鐘 cadence 執行，48 小時消耗約 6–8M tokens，並反覆對 flaky test 做症狀修補。完整 story 最後把高分比喻成降落檢查表，而不是開放無人寫入的綠燈。

成本會被 Cadence 放大

專案文件用很直觀的方式估算：輕量 triage 約 50k tokens，一次包含 implementer 與 verifier 的執行可能到 200k。這不是固定報價，而是協助規劃的量級。

若 CI Sweeper 每 15 分鐘完整跑一次，一天有 96 次，token 很快就會累積到數百萬。合理的 loop 應拆成兩段：先用便宜的 triage 判斷是否真的有工作，沒有就以很小的 context 提前結束；只有確認 actionable 時才啟動 implementer 與 verifier。

除了 token，還有人的 review 頻寬、PR 數量、通知疲勞與 comprehension debt。Agent 產出越快，不代表團隊理解改動的速度也同步提高。若所有人開始說「loop 會處理」而不再對設計與正確性有意見，專案把這稱為 cognitive surrender。

安全規則要有兩層

第一層是 skill、LOOP.md 與 loop-constraints.md 中的語意規則，告訴 agent 哪些事情不可做、何時升級。第二層則是模型不能自行繞過的外部控制，例如：

  • gate.yaml 的 denylist 與 auto-merge allowlist。
  • GitHub bot token 不具備 merge 或 admin scope。
  • Agent 執行帳號無法讀 production secret。
  • Container 或 VM 隔離，而不只是一個 worktree。
  • Scheduler、CI 或 wrapper 在超過 budget 時真正停止 process。
  • Branch protection 與必要的人類 approval。

若只有第一層，規則仍可能因 context、指令衝突或模型錯誤而失效；若只有第二層，agent 會不斷撞牆，產生噪音與成本。Loop Engineering 提供了不少第一層文件與部分第二層 CLI，但 OS sandbox、secret vault、完整 scheduler 與審批平台仍要由使用者自己的基礎設施負責。

如何開始？

官方 quickstart 可先建立 Daily Triage：

npx @cobusgreyling/loop-init . --pattern daily-triage --tool codex
npx @cobusgreyling/loop-cost --pattern daily-triage --level L1
npx @cobusgreyling/loop-audit . --suggest

正式導入前，我會多做幾件事：

  1. 在測試用 repository 或低風險專案固定 CLI 版本，不直接讓 production repo 跟隨 latest。
  2. 先 review scaffold 出來的 skill、constraints、budget 與 connector 權限。
  3. 第一至兩週只輸出報告，記錄 false positive 與漏報。
  4. 為 state 設定固定 schema 與 prune 規則。
  5. 只有一種狹窄工作通過多次人工驗證後，才開放 L2。
  6. 將真正的停止條件放在 scheduler、CI、token ledger 或權限系統，不只寫在 prompt。

使用 npx 會下載並執行遠端 npm package，導入公司 repository 前仍應查核 package、固定版本或從已審查的 source 建置。這和安裝第三方 CI action、Agent Skill 或 shell script 是同一類供應鏈決策。

它適合哪些團隊？

比較適合：

  • 已經穩定使用 Claude Code、Codex 或其他 coding agent。
  • 有重複、範圍清楚且輸出可驗證的維護工作。
  • 願意維護 state、budget、run log 與安全規則。
  • 已有 CI、branch protection、bot account 與 code review 流程。
  • 想先把 triage 與資訊彙整自動化，再逐步增加 action。

不太適合：

  • 需求每天都在變，連「完成」都無法客觀判斷。
  • 測試與觀測不足，verifier 沒有可靠回饋。
  • 希望安裝後就得到完整託管式 agent platform。
  • 沒有人願意閱讀報告、review PR 或負責 human escalation。
  • 把 worktree、自然語言規則或 readiness score 當成安全邊界。

專案成熟度與我的看法

截至 2026 年 7 月 23 日查核，repository 約有 9,120 stars、1,245 forks 與 286 commits，最新 GitHub release 是 2026 年 7 月 20 日的 v1.6.0。專案採 MIT License，可以修改與商業使用，但散佈時需保留授權聲明。

這些數字顯示它短期內受到大量關注，卻也必須注意 repository 直到 2026 年 6 月才建立，仍是非常年輕、更新快速的專案。它有文件、starter、machine-readable registry、release 流程與多組測試，工程內容比單純概念 repository 完整；另一方面，工具版本分散、周邊 ecosystem 正在擴張，離「穩定的一站式平台」仍有距離。

我認為 Loop Engineering 最值得帶走的不是某個 CLI，而是三個設計順序：先讓 loop 正確看見工作，再讓它採取很小的動作，最後才討論無人盯場；先定義停止與升級，再增加執行次數；先建立可供人檢查的 state，再追求更多 agent。

如果只把它理解成「定時叫 AI 寫 code」，成本和錯誤也會被自動化。若把它當成一套控制系統設計方法，從 report-only、明確 state、獨立 verifier、機械式 gate 與硬性 budget 開始，它提供的是一個相當實用的檢查框架：讓 Agent 不只會開始工作，也知道什麼時候不該繼續。

參考資料