傳統人工審查建立在「系統先產出結果，再由人確認」的節奏上。
當 AI 只協助產生一段程式碼時，開發者還能在生成後閱讀內容、執行測試，再決定是否採用。每一次變更都有清楚的開始與結束，人也有時間停下來理解內容。
AI 代理人（AI Agent）開始具備讀取整個儲存庫（Repository）、搜尋相關程式、修改多個檔案與執行指令的能力後，一次任務裡就會包含一連串判斷與操作。AI 可以自行拆解任務、呼叫工具、修改資料、檢查結果，並依照執行結果決定下一步。
例如，開發者要求 AI 代理人完成會員折扣功能。它可能先搜尋訂單與會員模組，判斷折扣邏輯適合放在哪一層，接著修改領域模型（Domain Model）、API、測試與資料存取邏輯。
第一次測試失敗後，它會根據錯誤訊息調整實作，再次執行測試。等到開發者看到最終成果時，AI 代理人可能已經完成十幾次甚至更多的小型決策。
這些決策出現得很快，人工逐步審查會很吃力。若要求開發者在每一次檔案修改、測試失敗或工具呼叫前批准，AI 代理人會被大量等待切斷執行節奏。若只在最後閱讀差異（Diff），開發者又難以掌握中間做過哪些判斷，以及哪些錯誤曾經出現又被修正。
連續開發任務需要把部分審查放進執行過程。檔案修改範圍、測試結果、架構依賴、靜態分析（Static Analysis）與安全掃描等可明確定義的規則，可以交給 Harness 與持續整合與持續交付（CI/CD）自動檢查。
當任務涉及需求取捨、架構調整、正式環境操作或其他高風險變更時，再中止自動執行並交由開發者判斷。
程式碼審查（Code Review）常以拉取請求（Pull Request, PR）的最終差異為主要材料。這套方式在人類逐步開發時容易理解，因為提交者大多掌握修改過程與設計理由。
大量修改改由 AI 代理人自主完成後，最終差異只留下最後狀態，中間曾經嘗試過哪些方向、為什麼改變做法，可能都不會留下來。
AI 代理人可能先採用某個設計，測試失敗後換成另一套實作，接著為了解決型別錯誤調整共用介面。每一次修改單獨看都有理由，累加起來卻可能讓影響範圍從一個功能延伸到數個模組。
審查者（Reviewer）只看最後結果時，很難判斷哪些變動直接來自需求，哪些是 AI 代理人在修正前一步問題時留下的連帶修改。
自動修正循環也需要控制。AI 代理人為了讓測試通過，可能反覆修改實作、增加例外條件或擴大 Mock 範圍。
若同一輪任務允許它同時修改正式程式與測試，測試甚至可能跟著錯誤實作一起改變。最後持續整合顯示綠燈，需求與實作之間的偏移仍留在程式裡。
團隊可以保留 AI 代理人的執行歷程，觀察修改檔案數、差異變動量、測試重跑次數、同一段程式被反覆修改的次數，以及任務是否曾經跨出原定範圍。
這些訊號能補足最終差異缺少的過程資訊，也能作為暫停 AI 代理人、限制修改範圍或要求開發者介入的判斷依據。
AI 代理人的影響已經超過單純產生文字。它可以執行 Shell 指令、修改檔案、安裝套件、操作 Git、建立提交（Commit）、執行測試，有些環境甚至能建立拉取請求或觸發持續整合與持續交付管線（CI/CD Pipeline）。每一次工具呼叫都會改變開發環境的狀態，後續判斷也會根據新的狀態繼續進行。
例如，AI 代理人為了解決編譯問題新增套件，接著修改專案設定，又因新的相依套件造成測試失敗，於是繼續調整測試設定。最初只是修改一項功能，幾輪之後已經牽涉相依套件、建置流程與測試環境。若沒有事先限制任務邊界，修改範圍可能沿著錯誤一路擴大。
多個 AI 代理人共同開發時，行動鏈會變得更複雜。不同角色的 AI 代理人會根據彼此的產出接續工作，只要前面的規格存在模糊處，後續代理人就可能沿用相同假設，讓理解偏差一路延伸到實作、測試與審查。
若這些 AI 代理人使用相近的基底模型與上下文，也可能各自得出相似結論，最後形成彼此確認同一個誤解的情況。
開發流程需要看見 AI 代理人使用過哪些工具、修改哪些檔案、哪些測試已通過、哪些檢查失敗，以及任務範圍是否正在擴張。
當 AI 代理人出現大量重試、反覆修改相同區域、差異繼續變大，或開始跨越原定模組時，系統就需要暫停執行並要求人工介入。
人工審查仍負責需求取捨、架構調整與其他重要判斷。AI 代理人連續執行期間的安全，則需要由工具權限、修改範圍、測試門檻與自動停止條件等工程邊界共同控制。
AI 代理人能讀取整個儲存庫、執行指令與修改檔案後，團隊需要先定義它可以操作哪些區域。
這些限制可以依儲存庫、檔案目錄、檔案類型、分支與執行環境設定，讓 AI 代理人只取得完成任務所需的權限。
例如，一個只處理前端會員頁面的任務，可以允許 AI 代理人修改 src/features/member 與相關測試，並限制它不可調整共用元件、建置腳本（Build Script）或資料庫遷移（Migration）腳本。
若任務需要跨模組修改，也應先列出允許變更的範圍。AI 代理人一旦準備超出邊界，就應停止執行並要求人工確認。
正式環境憑證（Credential）、正式資料庫、雲端管理權限與部署金鑰，也不適合直接提供給一般 AI 代理人。開發與驗證階段可以使用沙盒（Sandbox）、測試帳號與短期憑證。需要部署或修改正式環境時，再透過獨立部署管線與人工批准取得對應權限。
這些限制可以落在 AI 代理人執行設定、容器環境與工具代理層。即使提示詞（Prompt）寫錯，或 AI 代理人對任務做出錯誤判斷，它能修改的檔案、可執行的指令與可存取的環境，仍會受到預先設定的工程邊界限制。
AI 代理人可以自行執行測試、搜尋程式碼、修改檔案與重新嘗試後，任務可能進入長時間的自動修正循環。單次操作看不出明顯問題，反覆執行後可能產生大量差異、消耗資源，甚至讓 AI 代理人一直圍繞同一個錯誤反覆修改。
工具使用因此需要設定明確的次數與範圍限制。例如，單一任務最多允許執行幾輪測試、同一個失敗測試最多重新嘗試幾次、單次任務最多修改多少檔案，或差異超過多少行後就停止執行並要求人工確認。這些門檻可以在修改範圍開始擴大時提早中止任務。
同一輪任務可以再限制允許修改的內容。若目標是讓既有測試通過，就要求 AI 代理人只能修改產品程式碼。若目標是補齊測試，就只允許修改測試檔案。
這能降低 AI 代理人為了讓執行狀態變成綠燈，同時調整實作與測試，最後產生假性成功。
不同工具也需要設定不同的使用門檻。讀取儲存庫、搜尋程式碼與查看測試結果可以給予較高自由度。安裝相依套件（Dependency）、修改建置腳本、變更 GitHub Actions、建立遷移或調整專案設定，則需要更嚴格的限制，必要時直接要求人工批准。
透過工具風險分級，AI 代理人可以自由進行低風險的搜尋與分析，高風險操作則受到額外限制。這樣能保留 AI 代理人的探索能力，也能避免原本只修改一項功能的任務，沿著錯誤修正一路擴張成跨模組、建置流程與基礎設施的變更。
AI 代理人可以協助撰寫程式、分析錯誤與提出修正方案，品質與安全驗證則應交由外部 Harness 執行。
AI 代理人不應負責審查自己的核心安全指標。若程式碼由 AI 代理人產生，接著又讓同一個 AI 代理人判斷「這份程式碼是否安全、測試是否充分、是否可以合併」，驗證結果仍會受到相同上下文與推理偏差影響。
程式碼檢查（Linting）、靜態分析、安全掃描（Security Scanning）、測試與變異測試（Mutation Testing）等檢查，可以放在 AI 代理人外部的 Harness 或持續整合中執行。
這些工具依照固定規則、測試案例與門檻產生結果，而非由 AI 代理人判定自己是否通過。變異測試則會刻意修改程式內容，再確認既有測試能否偵測這些變化。
AI 代理人可以讀取驗證結果，再根據失敗內容修正程式。例如靜態分析發現不允許的相依關係，AI 代理人可以調整設計。變異測試發現某段邏輯被修改後測試仍然通過，AI 代理人可以補強測試案例。是否通過門檻仍由外部工具判定，AI 代理人只能針對結果修正內容。
高風險門檻也應由 Harness 控制。例如安全掃描出現嚴重缺失、變異測試分數低於團隊設定門檻、架構檢查失敗，或修改範圍跨入禁止區域時，Harness 可以直接阻止提交、推送或拉取請求合併。
AI 代理人可以提出修正方案，不能自行忽略、重新解釋或關閉這些限制。
這樣的分工能讓驗證機制與 AI 代理人的推理流程分離。AI 代理人負責產生與修正，Harness 負責判定是否符合規則，團隊也能清楚知道哪些安全門檻不會因 AI 代理人當下的判斷而改變。
AI 代理人在開發過程中會遇到一些需要工程判斷的節點，例如改動資料模型、增加新的外部相依套件、修改公開 API、變更架構邊界，或調整持續整合與持續交付管線。
這些變更可能影響其他模組、團隊協作方式與後續維護，因此需要先由開發者確認。
團隊可以預先定義升級條件。當 AI 代理人發現任務需要跨越模組邊界、修改架構決策紀錄（Architecture Decision Records, ADR）涉及的設計、建立新的資料表，或變更部署流程時，就停止自動執行，整理影響範圍與修改計畫，再交由開發者決定是否繼續。
批准內容也需要足夠具體。AI 代理人可以先列出預計修改的檔案、受影響模組、測試範圍、相依套件變更、資料結構調整與已知風險，讓開發者能根據實際影響判斷這項變更是否符合需求與既有架構。
這套升級流程也能套用到多 AI 代理人開發。開發 AI 代理人（Coding Agent）若發現實作需要修改既有規格，可以先停止並送回需求 AI 代理人（Requirements Analyst Agent）或人工確認。測試 AI 代理人（Testing Agent）發現規格缺少必要情境時，也可以標示未定義項目並暫停產生測試。
每個 AI 代理人都維持清楚的責任邊界，當遇到超出授權範圍的決策時，再交由對應角色處理。
當多個 AI 代理人分別負責需求分析、程式開發、測試、審查與部署時，整個流程會接近一個小型軟體團隊。不同工作可以平行進行，同時也增加了協調與交接成本。
只要前面的 AI 代理人對需求產生錯誤理解，後續 AI 代理人就可能沿著相同前提繼續執行，最後產生完整、可執行，方向卻錯誤的結果。
每個 AI 代理人都需要有清楚的責任範圍。需求 AI 代理人負責整理規格（Spec）與驗收條件，開發 AI 代理人根據已確認規格實作，測試 AI 代理人依照規格建立測試，審查 AI 代理人（Review Agent）再檢查需求意圖、架構邊界與風險。
當 AI 代理人發現上一階段內容有問題時，應先回報並要求重新確認，避免直接修改其他 AI 代理人的輸入，讓規格、實作與測試之間保有清楚的追蹤關係。
AI 代理人交接時也需要固定版本基準。多個 AI 代理人應使用同一版規格、架構決策紀錄、背景檔案（Context File）與程式庫，並透過任務識別碼（Task ID）、規格版本（Spec Version）、背景版本（Context Version）等資訊綁定。
若開發 AI 代理人已經依照新版規格實作，測試 AI 代理人卻仍根據舊版內容產生測試，兩邊即使各自執行正常，整合時仍可能出現衝突。多個 AI 代理人平行工作時，這類版本偏差會擴散到後續流程。
不同 AI 代理人也不適合直接被當成彼此獨立的驗證來源。若開發 AI 代理人、測試 AI 代理人與審查 AI 代理人使用相同或相近的基底大型語言模型（Large Language Model, LLM），面對同一份模糊規格時，可能產生相似的理解偏差。
測試 AI 代理人應該只讀取規格與驗收條件，不直接利用開發 AI 代理人的推理內容。或是搭配不同模型、不同提示詞或人工審查，增加判斷來源的差異，降低多個 AI 代理人同時接受同一個錯誤假設的風險。
當 AI 代理人能連續修改程式與執行工具後，只保存最後的 Git 差異已經不足以還原完整過程。
團隊還需要知道 AI 代理人收到什麼任務、讀取哪些上下文、修改過哪些檔案、執行哪些指令，以及每一輪測試結果如何影響後續修改。
關鍵紀錄可以包含提示詞或任務規格、使用的背景檔案、工具呼叫紀錄、測試輸出、靜態分析結果、提交與拉取請求。這些資料能幫助審查者理解某項修改是如何形成，也能在結果偏離需求時，回頭找到問題從哪一個步驟開始。
Git 可以成為主要的變更追蹤邊界。AI 代理人每完成一個可驗證的小步驟，就建立內容清楚的提交，持續整合與持續交付再保存對應的測試與掃描結果。
若後續方向出現偏差，團隊可以回到前一個通過驗證的狀態，也能直接比較兩個階段之間新增了哪些修改。
多 AI 代理人協作時，紀錄還需要標示是哪一個 AI 代理人執行修改，以及它當時使用哪一版規格與上下文。需求、實作、測試與審查的紀錄才能串成完整的執行路徑。
當同一個錯誤假設一路傳到多個 AI 代理人時，團隊也能追查最早出現偏差的位置，再調整規格、上下文、提示詞或交接流程。
AI 代理人開發流程會經過儲存庫、Git 平台、持續整合與持續交付、測試環境與部署系統。若每個工具只記錄自己的狀態，團隊很難判斷一連串異常是否來自同一批 AI 代理人任務。
例如，Git 平台只看到拉取請求數量增加，持續整合平台只看到管線佇列變長，測試環境則看到大量容器被建立。單獨來看都只是使用量上升，將紀錄串起來後，才會發現某批 AI 代理人正在反覆建立分支、推送修改、觸發測試，再根據失敗結果重新執行。
因此，AI 代理人任務最好使用一致的任務識別碼、AI 代理人識別碼（Agent ID）與提交中繼資料（Commit Metadata）。每次修改、測試、工作流程與資源使用都能回到同一個任務，團隊才能掌握一項需求實際經過多少修改輪次、觸發多少次持續整合，以及消耗多少運算資源。
多 AI 代理人協作時，還需要追蹤彼此使用的版本基準。需求 AI 代理人更新規格後，編碼 AI 代理人、測試 AI 代理人與審查 AI 代理人若仍使用舊版本，就可能同時產生互相矛盾的結果。
系統需要記錄規格版本、背景版本與提交 SHA（Commit SHA），確認每個 AI 代理人都建立在一致的前提上，再允許工作繼續推進。
AI 代理人連續修改程式時，需要避免一路執行到最後才發現方向偏離。一次任務可能跨越多個檔案、測試與設定。若所有修改最後才整理成一個大型差異，開發者接手後就得重新閱讀整包變更，再判斷哪些內容可以保留、哪些需要撤回。
AI 代理人執行過程中可以建立可回復的安全點。每完成一個能獨立驗證的小步驟，就保留對應的 Git 提交、檢查點（Checkpoint）或工作目錄狀態。
這些安全點應通過該階段必要的測試與靜態分析，讓後續修改發生問題時，可以直接回到已知可用的版本。
例如，AI 代理人先完成領域模型修改並通過單元測試（Unit Test），再繼續處理 API 與資料存取。若後續修改開始跨越過多模組，或測試反覆失敗，開發者就可以直接回到前一個安全點，重新規劃接下來的修改。這能減少逐項拆除錯誤變更的工作，也能縮小重新執行任務的範圍。
復原範圍還需要包含 AI 代理人的上下文記憶（Context Memory）。當某個 AI 代理人因為錯誤推理被中止時，只復原程式碼仍不夠。如果錯誤假設、失敗推理歷史或過期規格已經被寫進共享記憶、快取、摘要或後續 AI 代理人會讀取的上下文中，新排入的 AI 代理人仍可能沿用相同前提，再次產生類似修改。
因此，AI 代理人發生異常後，也需要處理它使用過的上下文與記憶狀態。團隊可以建立上下文清除或回復機制（Purge / Rollback Context Memory），把規格版本、摘要、快取、背景檔案與檢查點一併版本化，讓系統能回到最後一次通過驗證的上下文狀態。
若某段記憶已確認受到錯誤推理影響，就應從後續任務的檢索來源與快取中移除，避免新的 AI 代理人再次取得相同內容。
安全點需要涵蓋程式碼、規格、架構決策紀錄、背景檔案與 AI 代理人的記憶狀態。這些內容需要對應到同一個版本基準，避免程式碼已經回復，AI 代理人卻繼續使用事故發生後產生的規格摘要或錯誤記憶。
完成回復後，後續 AI 代理人才能從一致且經過驗證的狀態重新執行任務，降低錯誤假設經由上下文記憶、摘要或快取再次進入開發流程的風險。
開發流程中的某些操作無法只靠 git revert 完整復原。例如 AI 代理人已經建立資料庫遷移、修改遠端分支（Branch）、建立拉取請求、更新測試資料，或觸發持續整合與持續交付流程。這些狀態已經存在於儲存庫之外，需要另外執行補償動作（Compensating Action）。
團隊可以事先替這些操作定義對應的復原方式。建立遷移後要有回復腳本，建立暫時性雲端資源後要能自動刪除，推送錯誤分支後要能關閉相關拉取請求，測試資料被修改後則要能重新建立。AI 代理人在執行這些操作前，就應取得對應的復原程序與限制。
當 AI 代理人已經出現失控、反覆重試或推理混亂等狀態時，同一個 AI 代理人不應再負責自己的補償與復原。
造成錯誤的上下文、判斷方式與工具使用策略仍可能留在目前執行狀態中，再要求它處理復原，可能讓相同錯誤假設繼續進入後續操作。
補償動作應由外部控制面啟動。控制層可以依照既定規則，使用事前準備好的腳本（Scripts）強制執行回復，例如還原指定提交、撤銷憑證、刪除暫時資源、取消工作流程、重建測試資料或回復資料庫狀態。每個動作都應具備明確的完成條件，讓系統能直接驗證復原結果。
復原流程也需要定義執行順序。若 AI 代理人同時修改資料庫結構、程式碼與部署設定，補償動作就要依照彼此的相依關係執行。順序錯誤可能讓資料庫版本、應用程式與部署環境處於不一致狀態，產生新的故障。
補償能力可以放進 Harness 或持續整合的固定控制流程，由外部控制面判斷觸發時機，再透過可重複執行的腳本完成復原。AI 代理人負責留下事故前的工具呼叫、狀態變更與修改紀錄，外部控制面則根據這些紀錄執行補償，避免失控中的 AI 代理人同時負責造成變更與撤銷變更。
AI 代理人在某個任務中出現錯誤時，系統需要避免這個狀態繼續影響其他工作。
例如，一個 AI 代理人修改共用函式庫（Library）後測試失敗，其他 AI 代理人若同時基於這個未完成版本繼續開發，錯誤可能擴散到更多分支與拉取請求。
因此，每個 AI 代理人任務最好使用獨立的分支、工作樹（Worktree）、容器（Container）或沙盒。任務失敗時，可以直接隔離該環境，避免未驗證的修改進入其他 AI 代理人的工作區。
多 AI 代理人同時開發時，這個邊界也能降低彼此覆蓋檔案，或誤用尚未完成的中間版本。
隔離機制也可以延伸到持續整合與持續交付。尚未通過必要檢查的 AI 代理人變更，只能停留在功能分支（Feature Branch）或草稿拉取請求（Draft PR），不能進入主幹。
若某個 AI 代理人反覆造成相同測試失敗，系統也可以暫停它對相關模組的修改權限，先交由開發者確認問題來源。
當錯誤只存在於單一任務時，隔離範圍可以維持在該分支、工作樹或沙盒。若多個 AI 代理人同時出現相似錯誤，例如大量拉取請求都開始修改同一個 API 契約，就代表問題可能已經超出單一任務。這時需要擴大隔離範圍，暫停相關 AI 代理人任務，再重新確認共用規格、架構決策紀錄與架構上下文。
Git 提供了良好的版本控制能力，團隊仍需要確認整條 AI 代理人開發流程是否真的能回復。可以定期模擬 AI 代理人修改方向錯誤、測試反覆失敗、分支污染或遷移無法使用等情境，實際執行停止、隔離與復原流程。
演練時可以檢查提交是否切得足夠細、檢查點是否真的可用、測試環境能否重新建立，以及儲存庫之外的狀態是否都有對應的補償程序。
若每次復原都需要開發者重新查找指令、手動建立資料或修正環境，代表復原流程仍高度依賴個人經驗。
可重複執行的復原工作可以放進 Harness 或持續整合流程，例如自動建立工作樹、保存 AI 代理人執行前狀態、失敗後清除暫存資源、重建測試資料，並回到最近一次通過驗證的提交。
開發者再根據任務狀態確認是否接受回復，以及接下來要從哪個安全點重新開始。
這類增強復原（Enhanced Recovery）能力可以支撐時間較長、修改範圍較大的 AI 代理人任務。AI 代理人能在預先設定的邊界內探索與修正，團隊也能隨時停止任務、隔離問題環境，並沿著既定復原程序回到可用狀態，避免錯誤修改一路累加成需要人工大規模清理的變更。
在 AI 代理人協助開發的流程中，單次修改常有自己的檢查條件，例如測試是否通過、程式碼檢查是否成功，以及是否符合目錄與檔案範圍限制。
這些檢查能判斷單一任務是否符合規則。多個 AI 代理人同時工作後，風險還會出現在整體變更量、資源競爭與任務之間的互相影響。
例如，三個 AI 代理人分別處理不同需求，每個 AI 代理人都只修改少數檔案，也都通過自己的測試。若這些需求同時碰到共用模組，合併時就可能產生大量衝突。
另一種情況是多個 AI 代理人根據同一份規格調整 API 契約，各自的修改都能通過檢查，最後卻讓多個拉取請求同時建立在持續變動的介面上。
持續整合與持續交付也會承受這類連鎖影響。AI 代理人可以快速建立提交、推送分支、觸發測試與重新執行管線（Pipeline）。單一工作流程都符合規則，短時間內大量累積後，持續整合佇列可能就被塞滿，測試環境與資源也可能被占滿，其他開發者提交的正常變更就會開始等待。
團隊因此需要觀察整個開發系統的狀態，包括同時執行的 AI 代理人任務數量、拉取請求數量、同一模組的變更密度、持續整合失敗率、佇列長度與資源消耗。
當多項指標同時超出預先設定的門檻時，系統就需要從限制單一 AI 代理人，進一步限制整體任務數量、暫停新的 AI 代理人工作，或停止特定模組的自動修改。
AI 代理人開發流程需要先建立基本的資源配額控管（Quota / Rate Limiting）。
這一層負責限制正常情況下可使用的資源，例如同時執行的 AI 代理人數量、單一任務可呼叫工具的次數、持續整合的併發量、單位時間內可建立的拉取請求數量，以及 Token、運算資源與測試環境的使用上限。
配額控管可以避免單一 AI 代理人或單一任務在短時間內占滿整個開發平台的資源。
這類限制適合處理可預期的資源消耗。例如某個 AI 代理人在幾分鐘內反覆執行相同測試，可以透過資源配額控管降低重試頻率。同時執行的 AI 代理人超過團隊設定上限時，新的任務可以先排入隊列。這些控制能讓平台保留必要資源，也能避免大量 AI 代理人平行工作擠壓開發者使用資源的空間。
全域斷路器（Market-wide Circuit Breakers）負責處理開始形成系統性影響的異常行為。
系統可以觀察一段時間內的測試失敗比例、持續整合失敗率、程式碼合併衝突、差異變動率（Diff Churn）、工具重試次數，以及同一模組被反覆修改的程度。當多個 AI 代理人出現相似異常，或失敗率在短時間內快速升高，就代表影響範圍已經跨出單一任務。
這裡也可以加入語意級循環偵測（Semantic Loop Detection）。 AI 代理人陷入循環時，不一定會重複完全相同的指令，也可能持續換不同做法處理同一個錯誤。例如連續幾輪都修改相同模組、測試失敗類型高度相似、差異不斷增加，通過的測試數量卻沒有進展。
要比較每一輪的錯誤類型、修改範圍、工具呼叫模式與測試結果，判斷任務是否長時間停留在相似狀態。
當「狀態高度重複」、「同一批檔案反覆修改」、「測試結果沒有收斂」與「差異變動率持續升高」等訊號同時出現，系統可以提高無效循環分數。分數超過門檻後，可以先停止單一 AI 代理人。
若多個 AI 代理人出現相同行為，則進一步啟動全域斷路器，暫停該類 AI 代理人任務或鎖定特定模組的自動修改。
斷路器啟動後，可以依照風險等級限制不同能力。讀取儲存庫、分析問題與產生修改計畫等低風險操作可以繼續執行，寫入程式碼、推送程式碼、建立拉取請求與修改共享模組等操作則先停止。
開發者可以利用保留下來的執行紀錄，判斷問題來自規格模糊、上下文記憶污染、測試環境異常，或多個 AI 代理人採用了相同的錯誤假設。
資源配額控管負責容量與使用限制，語意級循環偵測負責辨識 AI 代理人是否陷入無效修正循環，全域斷路器則在異常開始跨任務擴散時限制相關行動。三層控制各自處理不同訊號，讓 AI 代理人數量與自主程度提高後，開發平台仍能維持可控的執行範圍。
斷路器啟動後，團隊可以保留低風險的開發能力，同時停止可能擴大影響的自動操作。例如暫停 AI 代理人自動建立新的拉取請求，仍允許它讀取儲存庫、分析問題與產生修改計畫。也可以停止自動推送，只讓 AI 代理人在沙盒中繼續探索與驗證。
若問題集中在持續整合資源，可以先停止自動重試，讓失敗任務進入人工佇列。若異常集中在某個共用模組，則可以暫時鎖定該區域，只允許指定開發者或單一 AI 代理人修改。這類降級措施能限制新的變更量，也讓其他不受影響的工作繼續進行。
人工接手時，需要看到斷路器被觸發的原因，包括目前有哪些 AI 代理人正在執行、涉及哪些分支、最近修改哪些檔案、測試失敗模式、持續整合使用量與差異變動率。
團隊可以依照這些資訊決定取消哪些任務、保留哪些修改，以及是否需要重新整理規格、調整任務邊界或拆小工作範圍。
重新開放 AI 代理人執行時，可以分階段解除限制。團隊先降低同時執行的 AI 代理人數量、限制單次任務大小與持續整合重試次數，確認失敗率、衝突量與資源使用回到設定範圍後，再恢復原有權限。
全域斷路器讓團隊能在異常出現時收縮自動化範圍，避免 AI 代理人的大量變更超過開發流程與工程基礎設施可以承受的程度。
AI 代理人進入連續開發流程後，團隊需要保留一個可以立即中止執行的機制。當 AI 代理人開始大量修改檔案、反覆重試、跨出任務範圍，或多個 AI 代理人互相覆蓋彼此的變更時，若還繼續讓流程自動執行，影響範圍可能快速擴大。
緊急停止開關（Kill Switch）可以直接終止 AI 代理人執行程序、取消尚未完成的工具呼叫，並阻止新的任務繼續建立。
這個機制需要獨立於 AI 代理人的判斷，不能只在提示詞中要求它停止。當上下文理解錯誤、重試邏輯異常或工具狀態不一致時，AI 代理人仍可能繼續執行後續動作。
停止範圍可以分級處理。單一 AI 代理人出現異常時，只停止該任務。同一模組出現大量衝突時，可以停止所有正在修改該區域的 AI 代理人。若持續整合與持續交付、儲存庫或其他共用開發資源已受到廣泛影響，則可以暫停整個自動開發流程。
緊急停止開關也需要讓開發者能快速操作，並搭配清楚的權限控制。值班人員或負責系統的開發者需要知道從哪裡啟動、會停止哪些流程、哪些工具呼叫可以立即取消，以及停止後仍有哪些工作會繼續執行。
這些資訊若能事先寫入處理手冊（Runbook）並定期演練，事故發生時就能直接執行，不需要臨時確認停止範圍。
停止 AI 代理人主程序仍不足以處理所有情況。AI 代理人可能已經送出 Git 推送（Git Push）、觸發 GitHub Actions、建立背景測試工作，或啟動其他 AI 代理人。
這些流程如果繼續執行，新的提交、拉取請求與測試結果仍可能繼續出現。
完整的停止機制需要涵蓋工具層。系統可以撤銷 AI 代理人對 Git、Shell、套件管理工具與外部 API 的使用權限，也可以取消尚未完成的持續整合與持續交付工作流程。
若 AI 代理人使用短期憑證，緊急停止開關啟動後就應立即讓相關憑證失效，避免後續工具呼叫繼續執行。
流程層也需要一起中斷後續工作。例如 AI 代理人完成後原本會自動交給測試 AI 代理人，測試 AI 代理人再交給審查 AI 代理人。緊急停止開關啟動後，這條任務接續鏈也要停止，避免其他 AI 代理人根據尚未確認的結果繼續產生測試、審查或新的修改。
多 AI 代理人開發環境可以再透過集中式控制層管理讀取、修改與執行權限。緊急停止開關觸發時，由控制層統一關閉相關 AI 代理人的工具權限、取消進行中的工作，並阻止新的任務被排入。
這樣才能避免 AI 代理人主程序停止後，其他背景流程或衍生 AI 代理人仍沿著原本的工作鏈繼續執行。
停止 AI 代理人後，團隊需要保留足夠資訊，才能理解它為什麼偏離原本任務。若停止流程同時刪除工作樹、清除暫存紀錄或覆蓋 AI 代理人日誌（Log），開發者之後只能從程式碼最終的差異反推中間發生過哪些事情。
因此，緊急停止開關啟動時可以先保存目前的分支、提交、未提交差異、測試結果、工具呼叫紀錄與 AI 代理人使用的任務規格。若同一個任務已經歷多輪修改，也應保留各個檢查點，方便開發者比較每個階段的差異，找出偏移開始的位置。
提示詞、背景檔案與規格版本也需要一併保存。AI 代理人的錯誤可能來自上下文過期、規格描述不清，或不同 AI 代理人使用了不同版本。只留下程式碼，很難確認問題究竟出在實作過程，還是任務一開始的輸入條件就已經有誤。
這些紀錄可以透過任務識別碼、AI 代理人識別碼、提交 SHA與工作流程執行識別碼（Workflow Run ID）串接起來。
團隊接手後，就能沿著同一條任務紀錄，從規格、AI 代理人執行、程式修改一路查到持續整合與持續交付結果，再判斷哪些修改可以保留、哪些需要回復，以及後續應該從哪個安全點重新開始。
緊急停止開關平常很少被使用，時間久了容易出現權限失效、指令改版或操作人員不熟悉的情況。
團隊可以安排固定演練，模擬 AI 代理人大量重試、修改範圍快速擴張、CI 佇列塞滿，或多個 AI 代理人同時修改相同模組。
演練時需要實際執行停止流程，確認 AI 代理人是否真的終止、工具權限是否撤銷、背景工作流程是否取消，以及新的 AI 代理人任務是否還能被建立。這些檢查能找出操作文件沒有反映的控制缺口。
停止之後也要演練恢復流程。團隊需要決定回到哪一個提交、哪些分支要保留、哪些持續整合與持續交付工作流程可以重新啟動，以及哪些 AI 代理人任務可以重新排入。
重新開放時，可以先限制同時執行的 AI 代理人數量，觀察失敗率、衝突與資源使用狀況，再恢復原有的自動化範圍。
每次演練都應記錄停止是否成功、需要哪些人工操作，以及哪些外部工具沒有被完整中斷。這些問題再回到 Harness、持續整合與權限設計中修正，確保緊急停止開關在真正需要使用時能直接執行，並完整中止相關的 AI 代理人與工具流程。
AI 代理人（AI Agent）開始連續執行任務後，風險會出現在一連串工具呼叫、檔案修改、測試重跑與決策累加之中。只看最後的差異（Diff），開發者很難還原中間發生過哪些判斷與修正。
人工審查仍要處理需求取捨、架構調整與高風險決策。檔案範圍、測試結果、靜態分析（Static Analysis）、安全掃描與持續整合與持續交付（CI/CD）等可明確定義的檢查，適合放進自動化 Harness 中先行把關。
AI 代理人的權限需要被限制在任務所需的最小範圍。讀取儲存庫（Repository）、修改檔案、執行指令、安裝相依套件、建立遷移（Migration）或調整建置腳本，都應依風險等級設定不同門檻。
多個 AI 代理人協作時，需要清楚定義需求、開發、測試、審查與部署之間的責任邊界。規格版本、背景檔案、任務識別碼、提交（Commit）與執行紀錄要能串接起來，避免不同 AI 代理人沿用不一致的前提。
增強復原（Enhanced Recovery）不只回復程式碼，也要處理規格、背景檔案、檢查點與上下文記憶。若錯誤假設已經進入摘要、快取或共享記憶，後續 AI 代理人仍可能重新拿到同一組錯誤條件。
破壞性操作需要事先準備補償動作（Compensating Action）。資料庫遷移、遠端分支、拉取請求（Pull Request, PR）、測試資料與工作流程（Workflow）等狀態存在於儲存庫之外，復原時要由外部控制面依既定順序處理。
全域斷路器（Market-wide Circuit Breakers）用來處理跨任務、跨模組與跨工具的連鎖風險。當測試失敗率、差異變動率、工具重試次數、持續整合佇列或同一模組的修改密度超出門檻時，系統可以暫停一整類 AI 代理人行動。
緊急停止開關（Kill Switch）是最後一道安全邊界。它要能停止 AI 代理人主程序、取消工具呼叫、撤銷短期憑證、中斷後續任務鏈，並保留分支、提交、測試結果、工具紀錄與任務規格，讓開發者能接手判斷與復原。
iThome鐵人賽
看影片追技術