🌏 Read this article in English
上個月，團隊裡發生了一件事。
Junior 用 Claude Code 寫了一個新功能。效率很高，他自己也很滿意。
他提交了 PR。
我們在 CI 上跑了一輪 AI code review——單一模型，一次掃過所有檔案。
系統吐出一份 40 頁的報告。
120 個標記。
Senior 看了 20 分鐘。
80% 是風格。
15% 是誤報。
大概 5 個是真的。
然後？
剩下的 115 個，被無視了。
這就是代價。
當信號密度太低，注意力就會失準。
PR 是一個高頻、高雜訊的決策現場。每天都在發生，每次都不一樣。一份報告如果 95% 是噪音，下次再開的時候，那 5% 也跟著一起被滑掉。
問題的形狀，不是「再找一個更強的 reviewer」。
是 review 的結構該換了。
當工具變成噪音
先說清楚，靜態分析工具不是壞東西。
在過去十年，SonarQube、ESLint 是工程師的護城河。它們確保了代碼的基礎品質。
但情境變了。
當 AI 開始生成代碼，PR 的內容也變了。一個 PR 不再是「某人花兩天思考後寫的 200 行」，而是「AI 花兩小時寫的 500 行」。
review 的對象變了，review 的工具也得跟著變。
AI 生成的代碼往往符合語法，甚至符合某些設計模式，但它可能違反了業務邏輯的隱含假設。
更糟糕的是，AI 生成的代碼風格往往「太乾淨」。
乾淨到失去了人類閱讀時的上下文脈絡。
這時候，不管你是用傳統 linter 還是丟一個 AI reviewer 進去，結果都一樣：
通知疲勞（Notification Fatigue）。
開發者學會了忽略 PR 上的警告。
這不是因為他們專業度不足。
是因為警告信號密度偏低。
當一個工具 90% 的時間都在喊狼來了，你不會再相信它。
直到狼真的來了。
為什麼是 PR review，而不是別的場景？
你可能在想：
「多 Agent 不就是同樣的東西跑很多次嗎？這跟 PR review 有什麼直接關係？」
這是好問題。先承認一件事：多 Agent 不是萬靈丹。架構審查、安全稽核、效能調校——這些場景單一強模型就夠用了，跑很多次反而是浪費。
但 PR review 有兩個結構性特徵，讓它特別吃多 Agent 的紅利。
第一，PR review 是「同一份 diff，多視角同時成立」的工作
一段 30 行的改動，可以同時是：
- 合規問題（違反了 CLAUDE.md 的命名約定）
- 語義問題（這個 null check 寫得太樂觀）
- 歷史問題（這個欄位三年前就決定要 deprecate）
- 業務問題（這個折扣邏輯沒考慮 VIP 客戶）
四個角度，沒有誰更高一階。
但一個 reviewer——不管是人還是 AI——一次只能用一個視角讀。
你叫它「全部都顧」，它就什麼都顧不好。
這不是模型強不強的問題。
是「同時用四個鏡頭看一張照片」這件事，物理上做不到。
第二，PR review 是「高頻 × 低噪音容忍度」的場景
每天都在發生。
每次只看幾百行。
但只要 95% 是噪音，下次就沒人看了。
對比一下：架構審查一年做兩次，每次跑兩天，95% 噪音也忍得下去。安全稽核每季一次，發現一個真風險就值回票價。
PR review 沒有這個奢侈。
把這兩個特徵放在一起，多 Agent 的切入點就清楚了：
讓不同視角的 Agent 各自讀同一份 diff，然後只把多視角同意的東西，交給人類。
兩個獨立的 Agent 都指出同一個合規性風險。
信賴度，才站得住腳。
當它們意見不一致時，問題就變成了「品味」或「脈絡」的爭議——而這正是該交給人類仲裁的地方。
PR 上最後留下來的 comment，是經過至少兩個獨立視角同意的。其餘的，不上 PR。
多 Agent 在 PR review 的核心價值不是「更聰明」，而是「可交叉驗證」。
成本與效益對比
我們內部測試了 30 個 PR，對比單一強大模型（Claude 3.5 Sonnet，歷史基線）與 4 個輕量化 Agent 平行跑的結果：
| 方案 | Token 成本 (預估) | 發現真風險率 | 假陽性率 (Noise) |
|---|---|---|---|
| Single Agent | 1.0x | 65% | 45% |
| Multi-Agent (4x) | 1.8x | 88% | 12% |
Token 成本增加約 80%，但 PR 上的噪音減少 73%。
這筆帳，算得過來嗎？
在 PR 數量大、Senior 時間貴的場景下，這是一個值得考慮的方向。
對於減少開發者在 PR 之間 Context Switching 的成本來說，邊際效益會持續放大。
信賴度評分機制：量化不確定性
這是整個架構中最反直覺的部分。
傳統的 PR 工具只會告訴你：「這裡有風險」。
這個結構會告訴你：「這裡有風險，且我有 85% 的把握它是真的」。
評分流程
每個 Agent 獨立讀完 PR 後產出發現，進入評分階段。
邏輯很簡單：每個 Agent 獨立打分。
兩個都說有風險？信賴度 +20%。
聽起來很完美。
但問題是：如果兩個 Agent 都錯了怎麼辦？
兩個都錯的機率，比一個錯低很多——但不是零。所以門檻設高一點。
只有一個說有？直接丟棄，不上 PR。
門檻設在 80 分。
低於 80 分？
連 PR comment 都不寫。
想想看：
如果一份 PR 審查報告只有 3 個風險，且每個問題都有 ≥ 90% 的信賴度。
你會怎麼做？
通常會優先檢查，並決定是否修正。
因為你知道，這 3 個問題是經過嚴密篩選的「真風險」。
安全 override
但這裡有一個例外。
如果涉及安全、資料毀損或合規類風險，即使單一 Agent 命中，也保留並上到 PR。
嚴重性優先於信賴度。
品味 vs 正確性：誰該做最後的仲裁？
這裡有一個重要的區分。
正確性（Correctness）是客觀的。
品味（Taste）是主觀的。
可驗證的條件，Agent 們可以幫你掃一遍。但最後還是要跑測試，還是要人看過 PR。
但品味？
那是團隊的集體記憶，也是人類最後的堡壘。
新創團隊的好風格，不等於金融系統的好風格。
金融系統可能需要更多的冗餘和註解，因為它承擔的合規風險較高。
新創團隊可能需要更簡潔的代碼，因為它需要快速迭代。
CLAUDE.md 記載了團隊的品味。
但最終的 PR approve 按鈕，仍然是人類在按。
高信賴度項目，通常涉及正確性。
低信賴度項目，通常只是品味。
但這不是絕對的。
規範違反可能高信賴，但仍屬品味。
這讓開發者可以專注於真正重要的決策。
什麼時候不該用多 Agent？
如果你的團隊規模很小、PR 數量不多，且代碼庫非常穩定。
那麼，單一 Agent 加上良好的 Prompt 可能足夠。
如果你的場景是「一年兩次的架構審查」，那也不用多 Agent。一個強模型跑兩天，比四個 Agent 平行跑更劃算。
但如果你面臨的是：
- 快速迭代、PR 頻繁的代碼庫
- 多開發者協作
- 高標準的合規要求
那麼，多 Agent 架構在 PR review 上的邊際效益會顯著提升。
多 Agent 適合「高頻 × 多視角同時成立 × 低噪音容忍度」的審查場景，而 PR review 正好是這種場景。
換成別的場景，這套不一定劃算。
實作：如何接到你的 PR 流程？
如果你對這個架構感興趣，可以從以下步驟開始。
1. 定義你的規範
首先，你需要一個明確的規範文件，讓 Agent 知道這個 repo 的品味。
可以是 CLAUDE.md，也可以是其他的 YAML 文件。
規範應該包含：
- 代碼風格
- 命名約定
- 錯誤處理策略
- 測試要求
2. 設定多 Agent 與聚合器
使用 Claude Code 或其他支援多 Agent 的工具。
設定每個 Agent 的專精領域（合規、語義、歷史脈絡、業務邏輯）。
確保它們獨立運作，不共享狀態。
接著，你需要一個簡單的聚合器（Aggregator）。
它負責接收所有 Agent 對同一份 PR 的輸出，並執行評分邏輯。
3. 設定信賴度門檻
設定一個初始的信賴度門檻，例如 80 分。
觀察幾週的 PR 審查結果。
如果發現遺漏風險，降低門檻。
如果發現 PR 上的 comment 還是太多，提高門檻。
以 precision/recall 或 missed critical findings 作為調整依據。
4. 整合到 CI/CD Pipeline
建議的自動化流程如下：
- Developer Push：開發者提交 PR 至 GitHub。
- Multi-Agent Trigger：GitHub Actions 啟動多個 Agent 實例，各自讀同一份 diff。
- Parallel Analysis：各 Agent 針對
CLAUDE.md與語法進行獨立評估。 - Scoring Engine：執行評分邏輯，計算信心值與證據強度。
- PR Commenting：僅針對信心值 ≥ 80% 的風險，於 PR 頁面自動留言。
- Human Review：開發者在 PR 上專注於高信賴度風險，完成最終審核。
信賴度評分的門檻不是一成不變的。
它應該根據團隊的成熟度和代碼庫的穩定性進行動態調整。
初期可以設定較高的門檻，隨著團隊對系統的信任度增加，逐步降低門檻。
結語：判斷力至上
工具會放大既有判斷流程。
在多 Agent 架構中，你的能力體現在：
定義規範。
設定門檻。
PR 上的最終仲裁。
你知道什麼是好的代碼。
你知道什麼是重要的風險。
你知道何時該信任 AI，何時該懷疑 AI。
AI 越強，我們在 PR 上的角色越像「審核者」。
不是因為我們更懂技術，而是因為我們更懂「什麼該被忽略」。
你的工作從「寫得對」變成「判斷 PR 上哪些值得修」。
這才是資深的價值。
不是寫得快。
而是判斷得準。
下次打開 PR 看到 120 個標記，你還會全部讀完嗎？