多代理程式碼安全與審查：Claude Code、獨立審查與 FoneClaw 治理啟示

多代理系統何時能提升程式碼安全審查

多代理程式碼安全與審查的價值，來自明確分工，而不是代理數量本身。當一個代理負責實作、一個代理負責測試、一個代理負責安全審查，再由人類擁有最後合併權，整個流程可以同時保留速度、交叉檢查與責任邊界。若所有代理共用同一段推理、同一組權限、同一份結論，平行執行只會把同一種盲點複製多次。

Anthropic 的多代理系統研究把協調、共用資源、從眾、溝通與串通放在同一個問題面上觀察。這對 Claude Code多代理系統、AI程式碼審查代理和一般多代理治理都很關鍵：協作能提高覆蓋率，也會放大治理缺口。安全價值出現在代理能提出不同證據、挑戰實作假設、檢查權限與依賴風險，並把異議保留到合併前。

我們在 FoneClaw 做 Android 任務治理時也採用同一種判斷方式：先定義誰能做什麼，再談自動化能做多快。程式碼審查要看 diff、測試、依賴、祕密外洩與權限變化；手機任務要看目前畫面、權限、核准、停止與復原。若你想延伸理解代理身分、權限與稽核證據，可閱讀 AI 代理身份與權限治理：逐工具核准、稽核紀錄與 FoneClaw Android 控制。

協調者、實作代理、審查代理與人類合併者怎麼分工

多代理拓樸要先決定所有權。協調者負責拆任務、設定邊界、決定每個代理能讀哪些資料、能用哪些工具、何時要回報。實作代理負責完成明確範圍內的 patch、測試或文件。審查代理負責保持獨立，從安全、依賴、資料流、權限、錯誤處理和回復路徑檢查結果。人類合併者擁有最後決策，尤其是安全例外、架構變更與外部效果。

協調者主導的模式適合大型任務，因為它能控制工作切分和資源順序。風險是協調者若下錯範圍，所有後續代理都會朝錯方向前進。對等協作模式適合探索性工作，能產生多種方案，但也容易在共用討論中過早形成共識。獨立審查模式最適合安全關卡：審查代理先拿到需求、diff、測試輸出和風險清單，再獨立寫出阻擋項與證據。

我們建議把「產出」和「審查」分成兩條線。實作代理可以收到需求、既有設計和測試目標；審查代理應取得最小足夠背景、完整 diff、測試結果、依賴變更和權限變更，而不是全程跟著實作代理討論。這樣能保留真正的第二視角。若團隊正在建立回歸測試或評估 harness，自我改進手機 AI Agent：技能版本、回歸測試與安全回復提供了把任務結果轉成可驗證案例的延伸思路。

辨識協調失敗、共用資源衝突、從眾與串通

Anthropic 研究提醒，多代理效能高度依賴協調品質。放到程式碼安全審查，協調失敗通常長這樣：兩個代理同時修改同一個檔案，彼此覆蓋；一個代理更新測試假設，另一個仍依舊規格審查；協調者要求安全審查，卻只提供摘要而沒有 diff。表面上代理都在工作，實際上證據鏈已經斷裂。

共用資源是第二個風險。多個代理共用同一個 worktree、同一組憑證、同一個測試資料庫或同一個部署環境時，會產生交叉污染。某個代理跑了資料遷移，另一個代理把錯誤結果當成測試失敗；某個代理使用高權限 token 查資料，另一個代理把 token 暴露在輸出摘要裡。共用資源需要明確擁有者、鎖定規則、讀寫範圍和審計紀錄。若要深入沙盒與權限邊界，可參考 AI Agent 沙盒與手機權限：安全 Agent 為什麼仍需要邊界。

從眾是第三個問題。多代理看似有多個觀點，但如果代理共享中間結論、互相引用同一段錯誤推理，最後會形成低變異輸出。安全審查尤其需要保留差異：一個代理檢查資料流，一個代理檢查依賴供應鏈，一個代理檢查權限與祕密暴露。過早共享「看起來沒問題」會讓後續審查變成背書。

溝通本身有兩面。代理之間交換狀態能避免重工，也能協調資源；同時，過度溝通會讓錯誤假設傳染，甚至出現研究中提到的串通風險。實務上可以把溝通分層：工作狀態可以共享，安全結論要獨立產生；阻擋項可以彙整，證據來源要可追溯；合併前要保留少數意見，而不是只留下共識摘要。

建立獨立多代理程式碼安全審查流程

一個可落地的 Claude Code多代理系統安全審查流程，應從威脅模型開始，而不是從「派更多代理」開始。先寫清楚變更要保護什麼：使用者資料、憑證、付款流程、權限控制、檔案系統、網路邊界、外掛載入，或手機端外部效果。接著把實作任務和審查任務分離，讓審查代理在明確證據上工作。

1. 鎖定範圍：協調者列出需求、受影響模組、禁止觸碰區域、資料敏感度與發布風險。
2. 實作隔離：實作代理在獨立工作區完成 patch，保留測試指令、失敗紀錄和設計取捨。
3. 證據封包：合併前整理 diff、測試結果、依賴變更、權限變更、設定變更、祕密掃描與手動驗證。
4. 獨立審查：審查代理在證據封包上檢查注入、資料外洩、權限擴張、錯誤處理、日誌暴露、回復路徑和供應鏈風險。
5. 人類裁決：合併者查看阻擋項、剩餘風險、測試缺口和回復計畫，再決定合併、退回或拆小。

審查代理需要拒絕權。若它只能補充建議，安全審查會退化成潤飾文字。好的阻擋項要具體：指出檔案、行為、攻擊路徑、可重現條件與建議修復。好的通過結論也要具體：哪些風險已檢查、使用哪些測試或靜態分析、哪些項目仍靠人工判斷。

同時，通過測試只是安全證據的一部分。測試能證明某些預期行為成立，無法覆蓋所有攻擊路徑。多代理審查應把測試、靜態檢查、人工威脅模型和審查代理異議一起呈現。若團隊比較開放式手機 Agent 或框架安全風險，也可閱讀 OpenClaw 安全風險與手機 Agent 安全設計：如何更可靠地選擇 Android 代理，把程式碼治理延伸到產品邊界。

隔離工具、憑證、工作區、佇列與預算

多代理系統的控制面要從共用資源開始。每個代理都應有能力快照：可讀哪些檔案、可寫哪些目錄、可呼叫哪些工具、可使用哪些憑證、能否連網、能否提交變更、能否發送外部請求。能力快照讓審查者知道某個結果是怎麼產生的，也讓事件發生後能追溯影響範圍。

工作區隔離是基本要求。實作代理用自己的 branch 或 worktree，審查代理讀取固定 diff，測試代理使用可重建環境。憑證隔離則要更嚴格：讀取原始碼的代理通常不需要部署 token；跑測試的代理通常不需要生產資料；安全審查代理可以看到權限清單與設定摘要，但敏感值應被遮蔽。共享 mutable state 會讓錯誤擴散，也會讓責任歸屬變得模糊。

佇列與預算也屬於安全治理。多個代理同時跑昂貴測試、掃描相同目錄或呼叫外部 API，會造成成本、速率限制與結果干擾。任務佇列應標示優先級、互斥資源、逾時、取消條件與重試策略。停止代理代表停止後續動作；已經完成的外部效果，例如已發出的請求、已寫入的資料或已通知的系統，需要另外用補償流程處理。

這一點和我們在 Android 任務佇列上的經驗相通。FoneClaw 的治理思路強調任務隔離、核准與復原，避免多個任務互相踩到狀態。更完整的手機任務佇列設計可看 Android AI 代理任務佇列指南：多對話、任務隔離與核准復原。

把多代理治理原則映射到 Android 手機 Agent

程式碼代理的風險多半落在 repo、測試、部署與資料系統；手機 Agent 的風險直接落在使用者生活裡，例如訊息、聯絡人、行事曆、設定、位置、通知與外部 App。這讓多代理治理原則更有參考價值：每個任務要有明確邊界，每個工具要有權限理由，每個敏感步驟要有可見核准，每個失敗要能留下可接續狀態。

FoneClaw 的 Android 路線把這些原則轉成支援任務的控制點。使用者在 FoneClaw 中配置支援模型，模型負責理解與規劃；FoneClaw 負責把支援的 Android 動作放進可檢查流程。針對有外部效果的步驟，產品提供可見核准；針對執行中斷，流程提供停止、重試與權限復原；針對能力選擇，工具與支援範圍以清楚契約管理。

這裡的連結是治理類比。Claude Code 多代理研究幫我們更精準地描述協調、隔離和審查問題；FoneClaw 面對的是 Android 手機任務、權限和使用者確認。兩者共享治理語言，產品能力與執行環境各自獨立。依本文更新時可用的官方資訊，FoneClaw 的目前能力可查看 FoneClaw 功能頁，安裝資訊可查看 FoneClaw 下載頁。我們會持續把 100+ built-in tools、核准、停止、重試與權限復原整理成更可驗證的手機任務體驗。

多代理程式碼審查發布檢查表

發布前，先確認每個代理都有角色、工具範圍、輸入資料、停止條件與負責人。實作代理要留下 patch、測試和取捨；審查代理要留下阻擋項、證據和剩餘風險；協調者要留下範圍決策；人類合併者要留下核准理由。這些紀錄讓多代理流程可追溯，而不是只留下漂亮摘要。

執行中，檢查共用資源是否有鎖定機制、憑證是否最小化、工作區是否隔離、佇列是否能取消、預算是否有上限。合併前，保留審查代理的獨立意見，尤其是少數異議。事件後，記錄觸發原因、最早錯誤步驟、已完成的外部效果、補償措施和新回歸測試。

這份檢查表不能保證安全；它能把安全責任從模糊的「代理看過了」變成可審查的證據鏈。多代理治理的成熟度，不在於同時跑了多少代理，而在於每個代理的權限、證據、異議和停止條件是否在合併時仍然清楚。