1. 定義：Loop Engineering 是 Agent 外層的控制系統
來源事實：Addy Osmani 在 2026 年 6 月 7 日發表〈Loop Engineering〉，把它描述為不再由人逐回合提示 Agent，而是設計一個會自行找工作、分派、檢查、記錄並決定下一步的小型系統；他也明確指出此概念仍在早期。AI 判讀：截至 2026 年 7 月 23 日，Loop Engineering 比較像新興業界方法論，而不是已有正式規格的標準。它位在單一 Agent 的 Harness 之上：Prompt Engineering 處理一句指令怎麼寫，Context Engineering 處理這次呼叫要帶什麼資訊，Harness Engineering 處理 Agent 可用的工具與執行環境，Loop Engineering 則決定何時啟動、如何反覆執行、由誰驗證、狀態放哪裡，以及何時停止或交還給人。
2. 理論根基：新的名稱，建立在既有回饋迴圈之上
來源事實：ReAct 讓模型交錯進行推理與環境行動；Reflexion 把任務回饋轉成文字反思並寫入記憶，供下一次嘗試使用；Self-Refine 以產生、回饋、修訂的方式反覆改善輸出；SWE-agent 則顯示 Agent 使用工具的介面設計會直接影響軟體工程任務表現。Anthropic 後來把常見模式整理成 Prompt Chaining、Routing、Parallelization、Orchestrator–Workers 與 Evaluator–Optimizer。AI 判讀：Loop Engineering 的新意不在發明「迭代」，而在把這些模式和排程、隔離工作區、技能、連接器、外部狀態、成本控制及人工閘門組成可長期運轉的工程控制面。
3. 先判斷是否適合：可驗證、可回滾、會重複的工作才值得做
AI 建議：優先選擇每週重複、輸入可取得、結果可機器驗證、失敗可回滾且單次價值高於推理成本的任務，例如 CI 失敗分流、依賴更新評估、測試報告摘要、文件與程式碼規則巡檢。若一個問題用單次模型呼叫、固定規則或普通工作流就能穩定解決，不要為了追求 Agent 而加上 Loop。Anthropic 建議從最簡單方案開始，因為 Agent 通常以更高延遲與成本換取彈性；多 Agent 系統在其研究案例中有明顯效益，但使用的 Token 也遠高於一般對話，且不適合子任務高度相依、必須共享完整上下文的工作。
4. 一個可上線 Loop 必須明確定義八個欄位
實作時先寫一份 `LOOP.md` 契約，至少包含八項：Trigger 說明由排程、事件或人工按鈕啟動；Goal 定義本次要改變的最終狀態；Observe 列出可讀取的資料與證據；Decide 定義分類、優先順序與下一步規則；Act 限定可呼叫的工具與可修改的範圍；Verify 指定測試、靜態分析、狀態查詢或第二 Agent 的檢查方式；Persist 規定要寫入哪些外部狀態；Stop／Escalate 定義成功、失敗、預算耗盡、權限不足與人工接手條件。沒有這八項的「一直做直到完成」，通常只是一個沒有煞車的重試器。
5. 先寫完成條件，再寫 Agent 指令
完成條件要描述可觀察的環境狀態，而不是讓 Agent 自己宣稱完成。以修復登入錯誤為例，條件可以是：指定失敗測試由紅轉綠、既有回歸測試仍全數通過、型別與安全掃描無新增問題、Diff 不超出允許目錄、沒有修改測試來規避失敗，且 Draft PR 已附重現證據。再加上硬性上限，例如最多 3 次嘗試、15 次工具呼叫、20 分鐘或固定 Token／金額預算；任一上限觸發就停止並回報目前證據。Anthropic 的 Agent 指南也建議每一步取得環境 Ground Truth，並設置最大迭代數與人工 Checkpoint。
6. 最小實作：四個元件就能跑出第一個受控迴圈
第一個版本不需要大型框架。準備 `LOOP.md` 保存目標、權限與停止契約；`STATE.json` 保存 task_id、status、attempt、evidence、last_verifier、next_action、cost 與 failure_reason；一個 Orchestrator 依序執行 observe → decide → act → verify → persist；最後是一個獨立 Verifier，優先使用測試、Lint、Schema、HTTP 狀態、資料庫狀態或檔案 Diff 等確定性檢查。單次 Tick 的流程是：先鎖定 task_id 並讀取狀態，若已成功或正在執行就安全退出；建立乾淨隔離環境；收集新證據；只執行一個最小行動；驗證最終狀態；以原子方式更新狀態；依結果標示 success、retry、blocked 或 needs_human。
7. 第一階段教學：先上線唯讀 CI 巡檢 Loop
建議第一週只做 Report Mode。每天固定時間讀取前 24 小時的 CI 失敗、未關閉 Issue 與近期 Commit，依錯誤指紋去重後，把項目分成產品缺陷、測試缺陷、環境／依賴問題與資訊不足；每一項輸出失敗步驟、首個關鍵錯誤、受影響測試、相關變更與建議下一步，然後更新 `STATE.json`，但不修改程式碼、不發通知給外部對象，也不關閉 Issue。先追蹤命中率、重複告警率、人工判讀節省時間與每次執行成本。若分類無法被人工穩定接受，就不應進入自動修復階段。OpenAI 公開說明其 Automations 也用於每日 Issue 分流、CI 失敗摘要、Release Brief 與找 Bug，這類窄而可檢查的工作正適合作為起點。
8. 第二階段教學：Maker 負責修，Checker 只負責否決或放行
當唯讀模式已累積足夠案例，才加入寫入能力。每個任務建立獨立 Branch 或 Git Worktree，Maker 只能在 Allowlist 目錄內做最小修改；Checker 使用全新 Context，讀取原始需求、Diff 與驗證結果，不接受 Maker 的自我評語。Checker 檢查需求覆蓋、測試是否被削弱、權限與資料處理是否越界、是否出現無關改動，通過後只建立 Draft PR 並附證據，不自動合併。Addy Osmani 把「寫的人不要同時當評分者」列為 Loop 的關鍵結構；Anthropic 的 Evaluator–Optimizer 模式也只在評估條件清楚且迭代確實能改善結果時適用。
9. 第三階段教學：只對低風險、可回滾工作開放自動動作
可逐步開放的候選工作包括格式修正、產生缺漏文件、更新可重現的 Snapshot、補上已存在規則可判定的測試資料，或在完整 Gate 下提交小型修補；仍應以 Draft PR 為預設。資料庫 Schema、認證授權、付款、正式環境設定、資安修補、病患資料、刪除資料、跨系統通知與不可逆操作應維持人工核准。AI 建議：用權限分級而不是一次開滿，Level 0 只讀報告，Level 1 建議 Patch，Level 2 建立隔離分支與 Draft PR，Level 3 只允許明確 Allowlist 的低風險動作；每升一級都要以真實 Eval 與故障演練證明風險可控。
10. HIS QA 範例：夜間回歸失敗分流 Loop
可把 Selenium 與 pytest 夜間結果做成一個醫療資訊系統 QA Loop。Observe 只讀取去識別化的測試名稱、瀏覽器版本、錯誤堆疊、截圖雜湊、環境健康狀態與最近測試碼變更；Decide 依規則先判斷是否為 Driver／瀏覽器不相容、元素等待、測試資料、環境服務或可能的產品缺陷；Act 在唯讀階段只產生分流報告，在第二階段最多建立測試分支並調整等待或 Locator；Verify 必須重跑原失敗案例、鄰近 Smoke Test 與跨瀏覽器基準集。安全邊界是不得讀取正式病患資料、不得連線正式環境、不得把截圖或 Payload 上傳到未核准服務；一旦偵測到可能的個資、權限需求或跨模組影響，立即標記 needs_human。
11. 狀態與記憶：不要把聊天紀錄當資料庫
來源事實：長時間 Agent 會跨越 Context Window 與多次執行，Anthropic 的實驗使用結構化功能清單、Progress File 與 Git Commit 保存進度，並要求一次只處理一個 Feature；其多 Agent 研究系統也把計畫寫入外部 Memory，利用 Checkpoint 與可續跑執行避免每次從頭開始。AI 建議：狀態要有 Schema 與版本，至少保存輸入指紋、目前階段、已嘗試動作、驗證證據、下次允許動作、成本與最後更新時間；更新要具冪等性，重跑同一事件不能重複開 Issue、重複送訊息或建立多個 PR。大型產物寫入檔案或物件儲存，只在狀態中保存可追蹤參照，避免多 Agent 傳話造成資訊失真。
12. 驗證與 Eval：看最終狀態，不看 Agent 說自己完成
Anthropic 將 Trace／Transcript 定義為完整行動紀錄，Outcome 則是執行後環境的真實狀態；評估應優先檢查 Outcome。對程式碼 Loop，先用 Unit、Integration、E2E、Lint、Type Check、SAST 與狀態查詢等確定性 Grader，再用有明確 Rubric 的第二模型補充可維護性或需求覆蓋，並定期由人校準。初期不必等到數百題，從 20–50 個真實失敗案例建立 Eval Set 即可；每次改 Prompt、工具、模型或規則都重跑。除了 pass@1，也要看 pass^k，因為能偶爾成功不代表連續多次都可靠。每個 Trial 應從乾淨隔離環境開始，避免快取、殘留檔案或先前 Commit 汙染結果。
13. 可觀測性與成本：每一次迴圈都要能回答發生了什麼
至少記錄 run_id、task_id、模型與版本、Prompt／Skill 版本、工具呼叫、輸入與輸出摘要、狀態轉移、Verifier 結果、重試原因、延遲、Token、估計成本、Diff 大小與外部副作用。儀表板不只看成功率，也要看人工接手率、誤報率、重複工作率、回滾率、每個成功任務成本與從偵測到可供審查 PR 的時間。多 Agent 只在可以真正平行、任務價值足夠高時啟用；Anthropic 公開案例中，多 Agent 研究系統相較單 Agent 在內部評估表現較高，但 Token 使用約為一般聊天的 15 倍，顯示「多叫幾個 Agent」不是免費的可靠性。
14. Kill Switch：相同錯誤反覆出現時，不要讓模型繼續猜
Stop 規則至少涵蓋：達成驗證條件；連續兩次得到同一失敗指紋；本次行動沒有改善任何指標；超過最大嘗試、工具呼叫、時間或成本；要求升權、連外或存取未授權資料；Diff 超出目錄或行數限制；Checker 與確定性測試衝突；偵測到敏感資料；外部服務不穩定；需要不可逆操作。觸發後要保留乾淨工作區、完整證據與可重現步驟，明確說明卡在哪裡，而不是用新的 Prompt 繞過 Gate。OpenAI 的實務指南也建議在超過失敗門檻或遇到高風險動作時交由人介入，並以多層 Guardrail、認證、授權和標準安全控制共同防護。
15. 七天導入順序：從觀察模式走到可審查的 Draft PR
Day 1 選一個窄、重複、可驗證的痛點並寫 Goal；Day 2 從既有人工檢查與 Bug Tracker 收集 20 個案例，定義成功與失敗；Day 3 完成 `LOOP.md`、`STATE.json` 與唯讀 Orchestrator；Day 4 加入去重、冪等、成本上限、追蹤與 Kill Switch；Day 5 建立乾淨 Worktree、Maker／Checker 分工與確定性測試；Day 6 進行故障演練，包括工具超時、錯誤權限、測試誤判、重複事件與狀態損壞；Day 7 只對通過 Gate 的案例建立 Draft PR，人工抽查 Trace 與 Outcome，再依誤報率、接手率、成本和回滾結果決定是否維持、縮小或升級權限。
16. AI 判讀：真正的槓桿是把工程判斷寫進系統
Loop Engineering 不等於無人值守，也不保證 Agent 會自行收斂。它把工程師的工作從逐回合下指令，移向定義狀態、工具介面、完成證據、風險邊界與升級規則。成功的 Loop 會讓例行判斷可重現、讓失敗留下證據、讓下一次執行可以續跑；失敗的 Loop 則只會更快累積驗證債、理解債與成本。最務實的落地標準是：即使模型換掉、排程重跑或某個工具失敗，系統仍能安全停止、清楚解釋目前狀態，並讓人從可回滾的位置接手。