Claude Code 多代理資安審查：Alberta 案例的架構判斷

如果你看到「50 個 AI 同時掃程式碼，20 小時做完 6.5 年的工作」，第一個反應是「那我也想試試」——我很懂這個感覺。
但在你決定導入 Claude Code 或任何 multi-agent 系統 之前，有幾件事比速度數字更值得看清楚。

這篇不是要打壓 Alberta 省的案例。
相反地，這個案例確實做對了很多事。
但「做對了什麼」和「數字代表什麼」，是兩個不同的問題。

Alberta 案例真正值得學的，不是 50 個 AI agent 同時跑有多快，而是它背後的架構紀律：職責怎麼切、輸出怎麼鎖、人工審核放在哪裡，以及封閉模型用在政府資安審查時，主權風險要怎麼評估。

Claude Code 掃描 4.66 億行程式碼，速度代表什麼？

2026 年 7 月，加拿大亞伯達省政府發布一個 Claude Code 多代理資安審查 案例。
他們用大約 50 個 Claude Code agent 平行掃描全省 1,280 個應用程式、3,400 個程式碼倉庫，也就是 repo，共 4.66 億行程式碼，並在 20 小時內完成初步資安審查。
官方對比指出，如果用傳統方式執行，可能需要 6.5 年。

這個數字很吸引人，也很適合被放在簡報第一頁。
但它來自 Anthropic 自家發布的案例研究，計算假設沒有完整公開，也尚未經過第三方獨立驗證。
這不是說數字一定是假的，而是說：這是一組供應商自述的效率對比，閱讀時要帶著這個前提。

Anthropic 本身持有超過 2 億美元的政府合約，這類案例研究同時也是行銷素材。
對 IT 決策者來說，真正該問的不是「20 小時是不是真的等於 6.5 年」，而是：這套 multi-agent 系統為什麼能同時跑 50 個 agent，卻沒有變成一團混亂？

答案不在模型速度，而在架構設計。

Alberta 多AI代理系統做對了哪些架構紀律？

Alberta 案例的核心，不是速度，而是架構紀律。
它不是把 50 個 AI agent 丟進程式碼庫，讓它們自由發揮；而是事先設計好職責、輸出格式與人工審核流程。

Red team 與 blue team 職責切分

Alberta 的 AI 資安審查系統把 agent 分成兩組。

• Red team 模擬攻擊方，負責探測漏洞路徑，預測攻擊者可能如何利用系統弱點。
• Blue team 則扮演防守方，對照 95 項安全控制，為每個應用程式撰寫修補計畫。

這個設計的重點是：兩組 AI 不互相干擾。
Red team 不負責修補，blue team 不負責找攻擊路徑。
職責從一開始就被切開，降低 AI agent 自我循環與角色混亂的風險。

輸出格式鎖定到檔案與行號

AI 的輸出不是模糊地說「這裡可能有安全問題」。
它必須精確引用到具體檔案名稱與行號。
工程師拿到的不是描述性語言，而是可驗證的具體座標。

這一點非常重要。
在 AI 程式碼審查 中，模糊描述會把負擔轉嫁給下游工程師；精確到檔案與行號，才有辦法快速驗證、追蹤與修補。

人工審核成最後關鍵

所有 AI 生成的修補計畫，上線前都需要人工審核才放行。
這不是選配功能，而是整個系統設計的核心。

AI 負責擴大掃描規模、加速初步分析；人負責最後判斷與放行。
這種分工，才是目前 AI agent 資安審查 比較成熟的部署方式。

這四個設計決策，才是 Alberta 案例真正值得學的地方。
不是「用了 50 個 AI」，而是「50 個 AI 被放進一套可追蹤、可驗證、可人工放行的架構裡」。

multi-agent 為什麼容易在交接點失敗？

我自己在建多代理內容工作流程時，也踩過類似的坑。

最早一版系統，我讓研究 AI 負責收集資料，再把結果傳給內容 AI 寫稿。
但交接方式很鬆散，只是讓研究 AI 輸出一段「總結文字」，沒有固定格式。
結果內容 AI 在解讀時走調，引用了錯誤統計數字，那一週連續發出去的三篇文章都有同樣錯誤。

那次讓我第一次真實感受到：錯誤在沒人把關的多代理流程裡，傳播速度是線性的，但修補成本是指數的。

後來我重新設計交接方式。
研究 AI 的輸出必須變成固定欄位封包，包含 key_facts、source_items、counter_perspectives。
內容 AI 只能讀這些欄位，不能自由解讀一整段模糊文字。
最後再加回人工審核關卡，系統才穩定下來。

Alberta 的 red team 輸出鎖定到具體檔案行號，blue team 接手寫修補計畫，背後就是同一個邏輯：結構化 handoff 比長對話更可追溯、更可維護。

structured handoff，也就是結構化任務交接鏈，指的是一個 AI 步驟完成後，用固定格式把結果交給下一個 AI。
不是讓 AI 自由理解上一段話，而是讓每個 agent 只接收它需要處理的欄位。

Alberta 案例的規模比一般內容流程大得多，但核心架構紀律是一樣的：
multi-agent 系統能不能穩定，不取決於 agent 數量，而取決於交接格式是否清楚、責任邊界是否明確、人工閘門是否放在正確位置。

Alberta 案例在 AI 三階段中屬於哪一階段？

如果用 AI 工作流三階段來看，Alberta 案例已經超過單點工具化，進入第二階段。

• 第一階段是工具化。
  也就是用 AI 做單點任務，例如請 Claude Code 找某個 bug、生成某段修補建議，或協助閱讀程式碼。
• 第二階段是生產系統化。
  多個 AI agent 以固定角色分工，透過結構化 handoff 接力完成任務。
  Alberta 的 red team / blue team 架構，就是這個階段的典型案例。
• 第三階段是自動優化與高速迭代。
  系統不只會接力完成任務，還能根據執行結果自動修正策略、調整檢查規則、降低下次失敗機率。

Alberta 目前比較像第二階段，而不是第三階段。
因為人工審核仍是最後放行關卡，系統尚未完全自動根據結果修正整體策略。
這不是缺點，而是成熟的階段判斷。
知道自己在哪個階段，才不會把第二階段的系統誤當成第三階段全自動部署。

AI 生成程式碼:獨立數據怎麼說？

看 Alberta 案例之前，必須先知道業界基準線在哪裡。
如果只看 Anthropic 自家案例，很容易高估 AI agent 的穩定性。

AI 生成的安全問題

Veracode 是一家獨立資安廠商，非 Anthropic 相關方。
他們在 2025 年做了一項系統性研究，測試超過 100 個 AI 語言模型，涵蓋 80 項程式設計任務與 Java、Python、JavaScript、C# 四種主要程式語言。
結果發現，45% 的 AI 生成程式碼含有安全漏洞。

這個結果說明，AI 程式碼審查與 AI 程式碼生成不能只看速度。
AI 生成程式碼的方式，本質上是預測下一個最可能出現的程式碼片段。
它可能寫出看起來合理、甚至能通過測試的程式碼，但不一定真正理解安全語意。

這也解釋為什麼 Alberta 的人工審核不是錦上添花，而是整個系統成立的前提。
在 AI 生成程式碼仍可能引入漏洞的現況下，「AI 掃描、AI 建議、人類審核放行」是比較合理的分工。

企業 AI agent 專案的失敗因素

Gartner 預測，超過 40% 的企業 AI 代理專案，在 2027 年前面臨取消風險。
主因包括治理落差、ROI 不明確、失控成本。
更關鍵的是，失敗最常發生在 agent 之間的交接點，而不是核心模型能力不足。

這一點和 Alberta 案例形成鮮明對比。
Alberta 展示的是理想運作情境：職責明確、輸出格式清楚、人工審核存在。
但業界平均水位遠低於此。
很多 multi-agent 系統不是因為模型太弱失敗，而是因為交接不清楚、權限過大、審核缺位、成本失控。

Claude Code 用在政府資安審查，有什麼風險？

Alberta 案例還有一個比效能數字更結構性的問題：封閉模型主權風險。
這在台灣 IT 決策與政府 AI 採購討論中，常被低估。

Anthropic 的 Claude 是封閉權重模型，也就是 closed-weight model。
意思是採購方，包括政府或企業，無法看到模型內部權重，也無法完整稽核 AI 是如何得出結論的。
當 Claude Code 被用來做政府資安審查時，這件事就不只是技術選型，而是供應鏈與主權治理問題。

TechPolicy Press 的政策評論指出，對主權部署者來說，封閉模型本身就是供應鏈風險。
美國五角大廈曾將 Anthropic 列為供應鏈風險。
Alberta 選擇用封閉模型做政府資安審查，本身就是一個取捨，不是單純「有沒有效果」的問題。

台灣數位部現行指引採取較保守路線：禁止將機密資訊或個人資料輸入 AI，AI 輸出不得作為行政決策的唯一依據。
這和 Alberta 的大膽部署形成對比。

我對這個問題的條件性判斷是：
Alberta 的人工審核閘門，部分緩解了封閉模型帶來的主權風險。
因為 AI 不直接放行，人仍是最後決定者。
但這不代表封閉模型風險消失了，只是被控制在一個相對可接受的邊界內。

如果台灣政府或企業正在評估類似部署，「能不能稽核 AI 的推理過程」應該放進採購評估清單，而不是等導入後才補問。

台灣 IT 決策者該怎麼看 Alberta 案例？

如果你是台灣的 IT 主管、資安負責人，或正在評估 AI 自動化採購，Alberta 案例給出的不是一套可以直接複製的方案，而是一組判斷框架。

判斷一：多代理系統穩定靠架構紀律，不靠模型升級

multi-agent 系統穩不穩，核心不在「用最新版模型」，而在架構紀律。
職責切分、交接格式、人工閘門，優先順序都高於模型升級。
Gartner 提到的 40% 取消率，根本原因多半是架構失敗，而不是模型太弱。

判斷二：人工審核不是退步，是成熟設計

「導入 AI 就是要讓人不用管」是危險預設。
在 45% AI 生成程式碼含漏洞的現況下，「AI 生成、人工審核放行」是合理分工，不是半吊子的自動化。
真正成熟的 AI 資安審查，不是取消人，而是讓人站在最關鍵的決策點。

判斷三：封閉模型採購前，要問主權稽核問題

如果組織處理的是敏感資料，或涉及政府、金融、醫療、資安系統，就不能只問模型表現。
還要問：資料是否會外流？推理過程能否稽核？AI 出錯誰負責？是否能本地化部署？是否符合台灣現行 AI 使用指引？

一個可以帶走的判斷框架是：
多代理系統穩不穩，看的不是模型多強，而是你的架構紀律夠不夠撐住 50 個 agent 同時跑。

AI agent自我檢查

在導入 Claude Code、multi-agent 系統或任何 AI 資安審查工具之前，可以先問自己三個問題：

1. 你的 AI agent 之間的交接，有沒有固定格式？
   還是只是讓 AI 自己判斷怎麼傳給下一步？

2. 你的系統有沒有明確人工審核關卡？
   你知道人應該在哪個環節介入、審什麼、放行什麼嗎？

3. 如果你在評估政府或企業 AI 採購，有沒有問過「我能不能稽核這個 AI 的推理過程」？
   如果不能，這個風險是否已經被人工閘門、資料分級或本地化部署機制控制？

總結

Alberta 用 50 個 Claude Code agent 在 20 小時內掃描 4.66 億行程式碼，確實是一個令人印象深刻的 AI 資安審查 案例。
但真正值得台灣 IT 決策者學習的，不是「50 個 AI 跑得多快」，而是它如何設計多代理系統：red team / blue team 分工、輸出鎖定檔案行號、人工審核放在最後一道關。

multi-agent 系統的價值，不在於讓 AI 完全取代人，而在於讓 AI 放大人的檢查能力，並把人放在最關鍵的放行位置。
如果缺乏職責切分、結構化 handoff 與人工閘門，更多 agent 只會讓錯誤更快擴散。

對台灣政府與企業來說，Alberta 案例還提醒另一件事：封閉模型用在敏感系統時，不只是效率問題，也是 AI 主權風險與供應鏈治理問題。
採購前應先問清楚資料能不能進模型、推理能不能稽核、輸出誰負責、人工審核放在哪裡。

Claude Code 可以是很強的工具，但工具不是答案。
真正決定 AI agent 系統能否落地的，是架構紀律、驗收制度與主權風險評估。

常見問題

Claude Code 是什麼？
Claude Code 是 Anthropic 開發的 AI 程式工具，可以讀懂程式碼、執行任務、生成修補建議，並協助工程師處理開發與資安審查工作。
它可以被設定成多個 AI agent，同時平行處理不同任務。
Alberta 案例中，約 50 個 Claude Code agent 同時掃描政府應用程式與程式碼倉庫，是 multi-agent 系統應用在資安審查的代表案例。

multi-agent 系統跟一般 AI 工具有什麼差別？
一般 AI 工具通常是你問一次，它答一次，每次都需要重新給背景資料。
multi-agent 系統則是多個 AI 角色持續分工接力，每個 agent 有固定職責，上一步結果會透過規定格式傳給下一步。
Alberta 的 red team / blue team，就是一種多代理分工設計。

Alberta 案例可以直接複製到台灣嗎？
不建議直接複製。
Alberta 案例是 Anthropic 自家案例研究呈現的理想運作情境，數字尚未經第三方獨立驗證。
台灣若要借鏡，應學的是架構原則，例如職責切分、格式鎖定、人工審核與資料分級，而不是直接搬一套 50 個 agent 進組織。

台灣政府用 AI 做資安審查有什麼限制？
台灣數位部現行指引禁止將機密資訊或個人資料輸入 AI，AI 輸出也不得作為行政決策的唯一依據。
如果要導入類似 Alberta 的 AI 資安審查系統，必須先確認資料分類、部署位置、模型供應商、人工審核流程與稽核責任。

封閉模型用在資安審查有什麼風險？
封閉模型的主要問題是採購方無法完整稽核模型內部推理過程。
當它被用在政府資安審查、企業敏感系統或關鍵基礎設施時，就會產生供應鏈與主權治理風險。
人工審核可以降低風險，但不能完全消除風險。

AI agent 資安審查最容易失敗在哪裡？
最容易失敗的地方不是模型本身，而是 agent 之間的交接點。
如果交接格式不清楚、責任邊界模糊、人工審核缺位，錯誤就會在多代理流程中快速擴散。
因此，結構化 handoff 是 multi-agent 系統穩定運作的關鍵。