【手把手】把 Agent Loop 寫成能自跑的檢查流程
整理版優先睇
用目標、檢查、退出、輪數四要素建立自動化Agent Loop，讓Claude Code或Codex自行運行檢查並停在明確結果。
呢篇文章係作者分享點樣將agent loop寫成可以自動運行嘅檢查流程，用喺Claude Code或Codex呢啲AI工具。作者想解決嘅問題係每次都要臨場寫一大段指令，效率好低。而家只需要填四個要素：目標、檢查命令、退出條件、輪數上限，就可以整出一張任務卡。整體結論係呢個loop可以大幅節省時間，關鍵係Check同Exit要寫得具體，同時要有Max loops做安全閥。
文章介紹咗幾個常見場景模板，例如Ship PR Until Green，流程包括拎spec、改code、跑測試、開PR、監察CI至全綠。CI Failure Watcher係每5分鐘查一次CI，紅咗就自動修復。Guardrails Learning Loop更加聰明，同一種失敗出現兩次就會寫入guardrails文件，避免重複錯路。Pre-Commit Guard係hook-based，每次提交前自動檢查，紅咗就攔住。呢啲模板覆蓋咗唔同使用場景。
最後作者建議由一個最煩嘅重複任務開始，先用最小模板跑通一次，確認效能提升之後先擴展到其他場景。重點唔係模板本身，而係背後嘅四行要素：目標、檢查、退出、輪數。只要掌握呢個結構，就可以適應各種自動化需求。
- 結論：Agent Loop嘅核心係「目標、檢查、退出、輪數」四要素，Check同Exit要具體可執行。
- 方法：先揀一個有明確結果嘅任務（例如修到npm test通過），再寫本機可執行嘅檢查命令，最後定退出條件同失敗規則。
- 差異：傳統prompt靠AI自己理解「完成」，loop用機器命令判斷進度，減少模糊空間。
- 啟發：Guardrails Learning Loop會記錄失敗模式，避免重複錯路，係提升效率嘅關鍵一步。
- 可行動點：由一個最煩嘅重複任務開始，用最小模板跑通一次，再複製去其他場景。
Agent Loop 最小模板
Goal: 實現用戶資料頁的頭像上傳功能 Check: npm test && npm run lint Exit: 所有檢查通過，並說明改了哪些文件 Max loops: 10 Rules: 每輪失敗後先讀錯誤日誌，不要重複同一種修法
Agent Loop 嘅四要素：目標、檢查、退出、輪數
呢個寫法可以令 Claude Code 或 Codex 自己改 code、自己跑檢查、自己停喺明確結果。以前每次都要臨場寫一大段，而家只需要填四個嘢：目標、檢查命令、退出條件、輪數上限。呢個就係 agent loop，其實係一張任務卡。
四個嘢：目標、檢查命令、退出條件、輪數上限
Goal: 實現用戶資料頁的頭像上傳功能
Check: npm test && npm run lint
Exit: 所有檢查通過，並說明改了哪些文件
Max loops: 10
Rules: 每輪失敗後先讀錯誤日誌，不要重複同一種修法重點唔係「請你努力完成」，而係 Check 同 Exit。Check 係機器能跑嘅命令，例如測試、lint、typecheck、構建、CI 查詢。Exit 係停下來嘅標準，例如「測試通過」「PR checks 全綠」。Max loops 係安全閥，10 輪仲唔得就停，睇日誌或者俾人接手。
Check 同 Exit
Max loops 係安全閥
常見場景模板，直接套用省時間
例如 Ship PR Until Green。呢個 loop 嘅流程係：拎 feature spec，改 code，跑測試，推分支，開 PR，再用 gh pr checks 睇 CI。如果紅咗，讀失敗項，繼續修，最多 10 輪。適合已經有測試同 CI 嘅項目。
Ship PR Until Green
- CI Failure Watcher：每 5 分鐘查一次 CI，若某個 run 紅咗就去讀日誌，本地修復再推上去。適合長期分支或團隊趕版本時用。
- Guardrails Learning Loop：如果同一個檢查連續失敗兩次，會將失敗模式寫入 guardrails 文件，下一輪先讀文件。呢步別省，好多 agent 因為反覆行同一條錯路而失敗。
- Pre-Commit Guard：係 hook-based，每次提交前自動跑檢查，紅咗就攔住提交。適合放 project root，一次裝好以後唔使再提醒 agent。
呢啲模板覆蓋咗唔同場景，由 CI 監控到預提交檢查，都可以直接用或者改少少。
自己寫 loop 嘅步驟同注意事項
自己寫 loop 時，可以按呢個順序來。先揀一個有明確結果嘅任務。唔好由「幫我優化項目」開始，太大。揀「修到 npm test 通過」「將 PR checks 修綠」「提交前跑完 lint」呢類。再寫檢查命令。命令必須能在本機跑。唔好寫「檢查一下有冇問題」，要寫 npm test、npm run lint 等。然後寫退出條件。越具體越好。最後寫失敗規則。
呢個順序
有明確結果嘅任務
檢查命令
退出條件
失敗規則
- 1 先揀一個有明確結果嘅任務。唔好由「幫我優化項目」開始，太大。揀「修到 npm test 通過」「將 PR checks 修綠」「提交前跑完 lint」呢類。
- 2 寫檢查命令。命令必須能在本機跑。唔好寫「檢查一下有冇問題」，要寫 npm test、npm run lint、npm run typecheck、gh pr checks。
- 3 寫退出條件。越具體越好，例如「所有命令退出碼為 0，並列出修改文件」。如果要開 PR，就寫「PR 已創建，checks 全綠」。
- 4 寫失敗規則。例如：同一種錯誤出現兩次，就寫入 guardrails.md；每輪開始前先讀 guardrails.md；唔好修改無關文件；如果需要密鑰或登錄，停低並說明卡點。
寫到呢度基本就能跑。先唔好急住套 40 個模板，揀一個你最煩嘅重複任務，跑通一次。
由一個任務開始，擴展成自動化習慣
真正有用的是那四行：目標、檢查、退出、輪數
記住，核心唔係模板而係四要素。先從一件小事開始，跑通一次循環，你就會發現 agent loop 嘅威力。之後自然可以應用到更多場景。
原來每次都要臨場寫一大段。而家只係填四個嘢：目標、檢查命令、退出條件、輪數上限。
呢個就係 agent loop。個名聽落好大，其實係任務卡。
呢張卡會要求 agent 一輪一輪咁執行，直到檢查通過，或者達到上限。
一個最細嘅模板係咁樣：
Goal: 實現用戶資料頁的頭像上傳功能
Check: npm test && npm run lint
Exit: 所有檢查通過，並說明改了哪些文件
Max loops: 10
Rules: 每輪失敗後先讀錯誤日誌，不要重複同一種修法
你睇，重點唔係「請你努力完成」。重點係 Check 同 Exit。
Check 係機器可以執行嘅命令。例如測試、lint、typecheck、構建、CI查詢。
Exit 係停低嘅標準。例如「測試通過」「PR checks 全綠」「提交前檢查冇紅項」。
Max loops 係安全閥。唔好俾 agent 無限修落去。10 輪都唔得，就應該停低讀日誌，或者俾人接手。
呢類網站真正省事嘅地方，係將常見場景都寫成現成模板。你唔使每次重新諗。
例如 Ship PR Until Green。
呢個 loop 嘅流程係：拎 feature spec，改代碼，跑測試，推分支，開 PR，再用 gh pr checks 睇 CI。如果紅咗，讀失敗項，繼續修。最多 10 輪。
啱咩時候用？
適合你已經有測試同 CI 嘅項目。冇測試都可以跑，但效果會差好多，因為佢冇辦法判斷自己係咪修啱咗。
再睇 CI Failure Watcher。
佢每 5 分鐘查一次 CI。只要某個 run 紅咗，就去讀日誌，揾原因，本地修復，再推上去。
呢個思路適合長期分支，或者團隊正在趕一個版本嘅時候用。你唔使一直睇實個頁面。
Guardrails Learning Loop 更加有意思。
如果同一個檢查連續失敗兩次，佢唔係只係繼續試。佢會將呢個失敗模式寫入 guardrails 文件。下一輪先讀呢個文件。
呢一步唔好慳。好多 agent 失敗，唔係因為唔識改，而係因為重複行同一條錯路。你叫佢寫低「唔好再咁做」，下一輪就少啲浪費時間。
Pre-Commit Guard 係另一類。
佢唔係 prompt-only，而係 hook-based。裝好之後，每次提交前自動跑檢查。紅咗就攔住提交。
呢類適合放入項目根目錄。一次裝好，以後唔使每次提 agent。
你自己寫 loop 嘅時候，可以跟呢個順序做。
先揀一個有明確結果嘅任務。
唔好從「幫我優化項目」開始。太大咗。揀「修到 npm test 通過」「將 PR checks 修綠」「提交前跑完 lint」呢類任務。
再寫檢查命令。
命令必須可以喺本機跑。唔好寫「檢查一下有冇問題」。要寫：
npm test
npm run lint
npm run typecheck
gh pr checks
然後寫退出條件。
退出條件越具體越好。例如「所有命令退出碼係 0，仲要列出修改文件」。如果要開 PR，就寫「PR 已經創建，checks 全綠」。
最後寫失敗規則。
比如：
如果同一種錯誤出現兩次，把它寫入 guardrails.md。
每輪開始前先讀 guardrails.md。
不要修改無關文件。
如果需要密鑰或登錄，停止並說明卡點。
寫到呢度，基本上就可以跑。
先唔好急住套 40 個模板。揀一個你最煩嘅重複任務，成功跑一次。等你確認呢個 loop 真係可以慳時間，再將佢複製到其他場景。
模板只係起點。真正有用嘅係嗰四行：目標、檢查、退出、輪數。
原來每次都要臨場寫一大段。現在只填四個東西：目標、檢查命令、退出條件、輪數上限。
這就是 agent loop。名字聽着大，其實是任務卡。
這張卡會要求 agent 一輪一輪執行，直到檢查通過，或者達到上限。
一個最小模板長這樣：
Goal: 實現用戶資料頁的頭像上傳功能
Check: npm test && npm run lint
Exit: 所有檢查通過，並說明改了哪些文件
Max loops: 10
Rules: 每輪失敗後先讀錯誤日誌，不要重複同一種修法
你看，重點不在「請你努力完成」。重點是 Check 和 Exit。
Check 是機器能跑的命令。比如測試、lint、typecheck、構建、CI 查詢。
Exit 是停下來的標準。比如「測試通過」「PR checks 全綠」「提交前檢查沒有紅項」。
Max loops 是安全閥。別讓 agent 無限修下去。10 輪還不行，就該停下來讀日誌，或者讓人接手。
這類網站真正省事的地方，是把常見場景都寫成現成模板。你不用每次重新想。
比如 Ship PR Until Green。
這個 loop 的流程是：拿到 feature spec，改代碼，跑測試，推分支，開 PR，再用 gh pr checks 看 CI。如果紅了，讀失敗項，繼續修。最多 10 輪。
適合什麼時候用?
適合你已經有測試和 CI 的項目。沒有測試也能跑，但效果會差很多，因為它沒法判斷自己是不是修對了。
再看 CI Failure Watcher。
它每 5 分鐘查一次 CI。只要某個 run 紅了，就去讀日誌，找原因，本地修復，再推上去。
這個思路適合長期分支，或者團隊正在趕一個版本時用。你不用一直盯頁面。
Guardrails Learning Loop 更有意思。
如果同一個檢查連續失敗兩次，它不只是繼續試。它會把這個失敗模式寫進 guardrails 文件。下一輪先讀這個文件。
這一步別省。很多 agent 失敗，不是因為不會改，而是因為反覆走同一條錯路。你讓它寫下「別再這麼做」，下一輪就少浪費時間。
Pre-Commit Guard 是另一類。
它不是 prompt-only，而是 hook-based。裝好之後，每次提交前自動跑檢查。紅了就攔住提交。
這類適合放進項目根目錄。一次裝好，以後不用每次提醒 agent。
你自己寫 loop 時，可以按這個順序來。
先選一個有明確結果的任務。
不要從「幫我優化項目」開始。太大了。選「修到 npm test 通過」「把 PR checks 修綠」「提交前跑完 lint」這種任務。
再寫檢查命令。
命令必須能在本機跑。不要寫「檢查一下有沒有問題」。要寫：
npm test
npm run lint
npm run typecheck
gh pr checks
然後寫退出條件。
退出條件越具體越好。比如「所有命令退出碼為 0，並列出修改文件」。如果要開 PR，就寫「PR 已創建，checks 全綠」。
最後寫失敗規則。
比如：
如果同一種錯誤出現兩次，把它寫入 guardrails.md。
每輪開始前先讀 guardrails.md。
不要修改無關文件。
如果需要密鑰或登錄，停止並說明卡點。
寫到這裏，基本就能跑。
先不要急着套 40 個模板。挑一個你最煩的重複任務，跑通一次。等你確認這個 loop 真的能省時間，再把它複製到其他場景。
模板只是起點。真正有用的是那四行：目標、檢查、退出、輪數。