← 所有文章

多代理審議:當共識本身就是漏洞

我的 AI 代理產出最危險的結果不是錯誤。錯誤很容易處理。Linter 能抓到語法錯誤,測試套件能抓到回歸問題,而我建構的 95 個 hooks 能攔截 except: pass 和強制推送。真正危險的是一個自信且論述合理、卻恰好是錯誤的建議。

我請一個單一代理檢視某個 API 端點的安全問題。代理檢查了身份驗證、驗證了輸入消毒,並確認了 CORS 標頭。結論是一切正常。第二個代理以滲透測試員的角色獨立被提示後,發現該端點接受了無限制的查詢參數,可能透過資料庫查詢放大觸發阻斷服務攻擊。第一個代理從未檢查這一點,因為其評估框架中沒有將查詢複雜度視為安全攻擊面。

這個缺口是結構性的。再多的提示工程也無法修復,因為限制不在於提示本身。限制在於讓單一視角來評估一個多維度的問題。

我建構了一個多代理審議系統來彌補這個缺口。具有不同人設的代理獨立研究、辯論發現結果,並透過結構化投票達成共識。該系統執行 141 項測試,在代理之間強制執行上下文隔離,並使用雙閘門驗證架構來阻止過早的一致同意。

TL;DR

單一代理 AI 系統有一個結構性盲點:它們無法質疑自己的假設。一個執行 Sonnet 的 Ralph 迴圈能以每小時 10 美元的成本產出程式碼,但模型中每一個盲點也以相同的速度被交付。多代理審議在任何決策鎖定之前,強制從多個視角進行獨立評估。我的實作使用 10 個研究人設、一個 7 階段狀態機,以及兩個驗證閘門(共識檢查 + 品質檢查),運行於 Claude Code hooks 之上。該系統在低信心決策(低於 0.70)時觸發,每次審議大約增加 3 倍的 token 成本。對於安全決策、架構選擇以及任何不可逆的操作,這筆成本在第一次捕捉到單一代理遺漏的問題時就已回本。對於文件修正和例行編輯,則完全跳過審議。


我的代理們一致同意搞壞一切的那個夜晚

2026 年 2 月。一個星期二。我請我的代理「調查改善 hook 調度系統」,然後走開去泡咖啡。代理將自身信心評估為 0.58(低於 0.70 閾值),觸發了審議。系統生成了 3 個研究代理。每個研究代理評估問題、發現子問題,並生成了自己的研究代理。那些代理又生成了更多。

七分鐘後:23 個活躍的代理程序。燒掉了 4.80 美元的 API 額度。~/.claude/state/ 目錄被 JSON 狀態檔案填滿,因為每個代理都盡職地持久化其發現。Token 消耗以每分鐘約 0.70 美元的速度攀升,且沒有收斂跡象。

我為品質系統建構的遞迴防護追蹤的是深度(父代生成子代,子代生成孫代),而非廣度(父代生成 12 個子代,每個子代各生成 12 個子代)。深度限制 3 從未觸發,因為代理是水平擴展的。我手動終止了程序,盯著那些狀態檔案。

每個代理都同意 hook 調度系統需要改善。每個代理都提出了聽起來合理的修改方案。沒有一個代理質疑調查本身的範圍是否正確。二十三個代理在錯誤的問題上達成了共識。

修復只花了 20 分鐘:一個追蹤每個父代活躍子代總數的生成預算,上限為 12。更深層的教訓花了更長時間。我記錄的基礎設施加速曲線使得審議系統得以在 2 週內建構完成,正是因為 hook 基礎設施已經存在。但快速建構並不能防止結構性失誤。從單一代理 RAG 管線到自主系統的演進遵循著可預測的弧線。多代理審議位於最終端是有原因的:只有在單一代理自信地交付了錯誤答案之後,您才會去建構它。

共識,而非分歧,才是危險的失敗模式。


審議的解剖學

該系統有兩個結構性元件:一個排序工作的狀態機,以及兩個防止錯誤共識被交付的驗證閘門。

狀態機

七個階段,每個階段以前一階段為前提:

IDLE -> RESEARCH -> DELIBERATION -> RANKING -> PRD_GENERATION -> COMPLETE
                                                                    |
                                                              (or FAILED)

RESEARCH(研究):獨立代理調查主題。每個代理獲得不同的人設(技術架構師、安全分析師、效能工程師,以及其他 7 個角色)。上下文隔離確保代理在研究期間無法看到彼此的發現。L0(系統規則)和 L1(專案上下文)是共享的。L2(代理特定焦點)是私有的。L3(領域模式)根據人設載入相關的模式庫。1

DELIBERATION(審議):代理看到所有研究發現並產生替代方案。辯論代理識別各視角之間的衝突。綜合代理合併不矛盾的發現。

RANKING(排名):每個代理在 5 個加權維度上對每個提案進行評分:

維度 權重
影響力 0.25
品質 0.25
可行性 0.20
可重用性 0.15
風險 0.15

加權分數彙總為共識分數。閾值根據任務調適:安全決策為 0.85,架構為 0.80,預設為 0.70,重構為 0.65,文件為 0.50。2

雙閘門

閘門 1:共識驗證(PostToolUse:Task hook)。每個審議代理完成後執行四項檢查:

  1. 階段必須至少達到 RANKING
  2. 最少 2 個代理完成(可配置)
  3. 共識分數達到任務調適閾值
  4. 若有任何代理持異議,其關注點必須被記錄

任何一項檢查失敗都會阻止審議推進。3

閘門 2:品質檢查(Stop hook)。在工作階段關閉前執行五項品質檢查:

  1. 方法多樣性:多個獨特人設有所參與
  2. 矛盾透明度:異議有記錄的原因
  3. 複雜度處理:至少產生 2 個替代方案
  4. 共識信心:分數歸類為強(高於 0.85)或中等(0.70-0.84)
  5. 改善證據:最終信心超過初始信心

雙閘門架構在不同階段捕捉問題。閘門 1 防止過程中的過早收斂。閘門 2 防止交付看似完整但缺乏嚴謹性的結果。


情報分析師率先遇到了這個問題

我在 2026 年 1 月建構了審議系統。兩週後,我在一份關於結構化決策的閱讀清單中發現了 Richards Heuer 的《情報分析心理學》(Psychology of Intelligence Analysis)。第 8 章描述了競爭假說分析法(Analysis of Competing Hypotheses,ACH):分析師同時對多個假說評估證據,而非為其偏好的結論建構論據。4

這個對照令人不安。Heuer 的框架於 1999 年為 CIA 出版,解決的是我一直在除錯的同一個結構性失敗:聰明人收斂到單一解釋,因為他們從未強迫自己去評估替代方案。

以下是 ACH 在實務中的運作方式。一位調查疑似武器計畫的情報分析師不會問「這是武器計畫嗎?」(確認偏誤)。相反,分析師列出每一個合理的假說(武器計畫、民用研究、軍民兩用設施),對每一個假說評估每一條證據,並識別哪些證據最能區分假說之間的差異。

我的系統用不同的詞彙做著同樣的事情。三個代理評估一個提議的資料庫結構變更。代理 A(技術架構師)寫道:「結構乾淨,正規化到第三正規形式。」代理 B(效能工程師)寫道:「查詢模式將需要在每次讀取時跨 4 個資料表進行聯結。」代理 C(安全分析師)寫道:「個人識別資訊欄位在靜態狀態下未加密。」同一個結構,三種不同的評估,三條區分性的證據。排名階段根據這些獨立評估來評估提案,就像 ACH 根據證據評估假說一樣。

我並非從 Heuer 的框架出發來設計這個系統。我透過反覆試驗重新發明了 ACH 的一個子集,然後發現有人已經寫好了教科書。誠實的版本比自我吹捧的版本更有用:獨立得出相同的架構,證實了底層問題是真實存在的,而非理論性的。


為何共識是危險的失敗模式

Charlan Nemeth 從 1986 年到其 2018 年出版的著作《為搗蛋鬼辯護》(In Defense of Troublemakers)一直在研究少數異議。有異議者的群體比迅速達成一致的群體做出更好的決策。異議者不需要是對的。異議的行為本身迫使多數人檢視他們原本會跳過的假設。5

James Surowiecki 的《群眾的智慧》(The Wisdom of Crowds)識別了群體智慧決策的四個條件:意見多樣性、判斷獨立性、去中心化,以及彙總機制。6 違反獨立性(讓代理在研究期間看到彼此的成果),您就會得到羊群效應。違反多樣性(對每個代理使用相同的提示),您就會得到回聲室。

我直接測試了獨立性條件。兩個代理在能看到彼此發現的情況下評估同一個部署策略:代理 A 將風險評為 0.45。代理 B 看到該分數後給出了 0.48。相同的代理在沒有可見性的情況下:0.45 和 0.72。0.48 和 0.72 之間的差距就是羊群效應的代價。代理 B 的獨立評估標記了一個容器編排風險,而當社會壓力進入評估時,這個風險就消失了。

近期研究證實這兩種模式在 LLM 代理中同樣成立。Choi 等人在 NeurIPS 2025 中發現,獨立提示的代理之間進行多數投票,能捕捉多代理系統中大部分的品質提升。7 Kaesberg 等人在 ACL 2025 中量化了差異:投票在推理任務上提升 13.2%,而共識協議在知識任務上提升 2.8%。8 這表明選擇應取決於任務類型。這就是我的系統使用任務調適閾值而非單一共識數值的原因。

Wu 等人測試了 LLM 代理是否能真正辯論,發現在沒有結構性異議激勵的情況下,代理會收斂到聽起來最自信的初始回應,而不論其正確性。9 Wynn 等人更進一步:辯論可能是有害的。模型在回應同儕推理時,會從正確答案轉向錯誤答案,即使較強的模型在數量上超過較弱的模型。10 Liang 等人識別了根本原因為「思維退化」(Degeneration-of-Thought):一旦 LLM 對某個立場建立了信心,自我反思就無法產生新穎的反論,使得多代理評估在結構上成為必要。11

我的系統透過上下文隔離(研究期間 L2 層對各代理是私有的)來解決獨立性問題。多樣性來自 10 個具有不同評估優先順序的獨特人設。彙總使用跨 5 個維度的加權評分,而非簡單投票。異議的結構性激勵較弱:我追蹤異議是否被記錄,但不獎勵代理提出異議。從眾檢測模組試圖解決這個缺口,效果參差不齊。


偵測虛假的異議

從眾模組追蹤暗示代理在未經真正評估的情況下同意的模式。記錄的關注點在代理之間重複相同的用語、分數可疑地集中在閾值附近,或每個人設都一致支持(安全分析師和效能工程師很少在所有事情上意見一致),都會觸發警告。

它能捕捉的:樣板式異議(代理複製彼此的關注用語)、分數集群(每個代理在 10 分制中的評分差距在 0.3 分以內)、以及缺失的少數觀點(來自具有衝突優先順序的人設的一致批准)。

一個來自我日誌的範例:五個代理評估了一個身份驗證重構。五個都將安全風險評分在 7.1 到 7.4 之間。從眾檢測器標記了此集群。當我重新執行並刷新上下文隔離(清除 L2 快取)後,分數分散至 5.8-8.9。原始的集群反映的是共享上下文污染,而非真正的共識。

它遺漏的:精密的一致同意,其中代理確實從各自人設的角度進行了評估,但恰好因為不同的原因得出了相同的結論。該模組在推理看起來獨立時,無法區分真正的共識與羊群效應。我嘗試用真正共識與製造共識的範例來訓練分類器,但訓練資料太少(不到 50 場審議),訊號太弱。從眾檢測器能捕捉明顯的案例,但遺漏了微妙的案例。

誠實的評估:從眾檢測在代理收斂過快的 10-15% 審議中增加了有用的完整性檢查。對於其餘 85-90%,共識和品質檢查閘門提供了充分的驗證。我考慮過建構更精密的從眾系統,但決定工程投入不會匹配邊際改善。


行不通的嘗試

死胡同 1:自由形式的辯論回合

第一個版本讓代理針對彼此的發現撰寫長篇反駁:3 輪的文字往返。我看著一場關於資料庫索引策略的審議,用了 7,500 個 token 的辯論。第 1 輪:關於複合索引與單欄索引的真正分歧。第 2 輪:略加闡述的重述立場。第 3 輪:幾乎相同的論點包裹在不同的措辭中。有價值的訊號在第 1 輪達到峰值,之後便持續衰退。

每次審議的 token 成本達到 2-4 美元,而有用的資訊密度隨每一輪下降。修復方案:結構化維度評分取代了自由形式辯論。代理用數值對 5 個維度的提案進行評分,而不是寫文章。成本和時間降低了約 60%,最終排名的品質實際上有所提升,因為數值評分迫使產生散文所掩蓋的精確性。

死胡同 2:基於深度的遞迴審議

無限生成事件暴露了一個根本的建模錯誤。遞迴防護追蹤深度:父代在深度 0 生成子代在深度 1,子代生成孫代在深度 2,最大深度 3。但審議代理應該廣泛展開(10 個研究代理在同一層級),而非深入(一個代理生成一個子代再生成一個孫代)。深度限制 3 從未觸發,因為 23 個在深度 1 的代理仍然是「深度 1」。

修復方案是生成預算模型:審議代理繼承父代的深度而非遞增,並共享一個上限為 12 的子代生成總預算。預算模型映射到實際的失敗模式(代理總數過多),而非一個替代指標(巢狀層級過深)。代理血統追蹤在 JSON 檔案中,使預算在非同步代理完成之間持續有效。12

死胡同 3:單一驗證閘門

第一版實作在工作階段結束時執行一個驗證 hook,將共識檢查和品質檢查合併在一起。失敗模式在第一週內就出現了。一個代理以 0.52 的共識分數完成了審議——低於 0.70 閾值。然後它繼續處理不相關的任務 20 分鐘,才由工作階段結束 hook 標記出失敗。這 20 分鐘的工作建立在未通過驗證的基礎之上。

拆分為兩個閘門修復了時機問題。閘門 1(共識驗證)作為 PostToolUse:Task hook 執行,在審議代理完成後立即捕捉錯誤共識。閘門 2(品質檢查)在工作階段結束時執行,捕捉跨步驟累積的品質問題。在不同生命週期點的兩個 hook 匹配了失敗實際發生的方式:有些是即時的(低分),有些是漸進的(低多樣性、缺少異議記錄)。


誠實的數學

審議消耗 token。每個研究代理處理大約 5,000 個 token 的上下文並產生 2,000-3,000 個 token 的發現。以 3 個代理(有用審議的最低要求)來算,每個決策額外增加 15,000-24,000 個 token。以 10 個代理(完整研究小組)來算,大約 50,000-80,000 個 token。

以 Opus 定價(每百萬 token $15/$75)計算,一次 3 代理審議約花費 $0.68-0.90。一次 10 代理審議約花費 $2.25-3.00。我的系統在大約 10% 的決策(信心低於 0.70 的決策)上觸發審議,因此所有決策的分攤成本為每次工作階段 $0.23-0.30。

這是否值得取決於一個錯誤決策的代價。在生產部署中遺漏一個安全漏洞,需要數小時的事件回應。一個錯誤的架構選擇需要數週的重構。文件中的一個錯字則毫無代價。

信心模組決定哪些決策觸發審議。四個維度(模糊性、複雜性、利害程度和上下文依賴性)各產生一個 0-1 的分數。需要多個維度得分較高,整體信心才會降到 0.70 以下並觸發審議。單一維度的問題(「這很複雜但不模糊」)保持在閾值以上並跳過審議。13


兩個代理,一條規則

您不需要 10 個研究人設、8 個 Python 模組或 141 項測試就能從多代理審議中獲得價值。從 2 個代理和 1 條規則開始:代理必須在看到彼此的成果之前獨立評估。

最小可行審議

Decision arrives
  |
  v
Confidence check: is this risky, ambiguous, or irreversible?
  |
  ├── NO  -> Single agent decides (normal flow)
  |
  └── YES -> Spawn 2 agents with different system prompts
             Agent A: "Argue FOR this approach"
             Agent B: "Argue AGAINST this approach"
             |
             v
             Compare findings
             |
             ├── Agreement with different reasoning -> Proceed
             ├── Genuine disagreement -> Investigate the conflict
             └── Agreement with same reasoning -> Suspect herding

上面的決策流程圖涵蓋了 80% 的價值。以下是最簡實作:

# Minimum viable deliberation: 2 agents, 1 rule
def deliberate(decision_description):
    agent_for = spawn_agent(
        f"Argue FOR this approach: {decision_description}",
        persona="advocate"
    )
    agent_against = spawn_agent(
        f"Argue AGAINST this approach: {decision_description}",
        persona="critic"
    )

    if same_reasoning(agent_for, agent_against):
        return "WARNING: Suspect herding. Verify independently."
    elif genuine_conflict(agent_for, agent_against):
        return "Investigate the specific disagreement."
    else:
        return "Proceed. Independent agreement with different reasoning."

其他一切都是增量改進:5 維度排名、任務調適閾值、從眾檢測。核心洞察依然簡單:兩個獨立的視角能捕捉一個視角所遺漏的失誤。

單一代理 vs. 多代理:有何不同

情境 單一代理 多代理審議
安全審查 「架構看起來很乾淨」 代理 A:「乾淨。」代理 B:「管理端點缺少速率限制」
結構設計 「正規化到第三正規形式」 代理 A:「乾淨。」代理 B:「每次讀取需跨 4 個資料表聯結」
依賴升級 「測試通過,交付吧」 代理 A:「測試通過。」代理 B:「變更日誌顯示 v3 有破壞性 API 變更」
文件更新 「README 已更新」 所有代理一致同意(正確跳過,低於信心閾值)

何時審議

審議 跳過
安全架構 文件錯字
資料庫結構設計 變數重新命名
API 契約變更 日誌訊息更新
部署策略 註解改寫
依賴升級 測試固定資料更新

測試審議

該系統跨三個層級執行 141 項測試:14

  • 48 項 bash 整合測試Hook 語法驗證、共識流程、品質檢查閘門、遞迴防護強制執行,以及跨設定相容性
  • 81 項 Python 單元測試:全部 7 個函式庫模組(狀態機、信心、上下文隔離、排名、代理、從眾、PRD 產生)
  • 12 項端到端測試:從信心評估到 PRD 輸出的完整管線模擬

測試一個旨在產生異議的系統需要測試兩個類別。正常路徑:代理有建設性地產生異議並達成共識。失敗路徑:代理收斂過快、永不收斂,或超出生成預算。端到端測試以確定性的代理回應模擬每個情境,驗證雙閘門能捕捉每一個已記錄的失敗模式。

從 2 代理模式開始。當 2 代理版本在特定方面遺漏時再增加複雜度。我系統中每一個額外的代理、閾值和驗證閘門的存在,都是因為更簡單的版本在特定任務上失敗了。您的失敗會不同,而您建構來捕捉它們的系統應該反映您的失敗,而非我的。


關鍵要點

  • 共識是危險的失敗模式。單一代理無法質疑自身的假設。兩個具有不同評估優先順序的獨立代理能捕捉品質閘門和理念無法解決的結構性盲點。
  • 兩個閘門勝過一個。過程中的共識驗證能及早捕捉問題。工作階段結束時的品質檢查能捕捉跨步驟累積的問題。將驗證拆分為不同生命週期點的兩個 hook,匹配了失敗實際發生的方式。
  • 選擇性審議。信心模組在大約 10% 的決策上觸發審議。審議所有事情浪費 token。不審議任何事情則遺漏了獨立視角最重要的那些決策。

常見問題

多代理審議每個決策的成本是多少?

以 Opus 定價計算,一次 3 代理審議約花費 $0.68-0.90 的 API token(額外 15,000-24,000 個 token)。一次完整的 10 代理小組約花費 $2.25-3.00。該系統在大約 10% 的決策上觸發審議,因此所有決策的分攤成本為每次編碼工作階段 $0.23-0.30。

每個決策都需要審議嗎?

不需要。信心模組在四個維度(模糊性、複雜性、利害程度、上下文依賴性)上對決策進行評分。只有整體信心低於 0.70 的決策才會觸發審議,大約佔總決策的 10%。文件修正、變數重新命名和例行編輯完全跳過審議。安全架構、資料庫結構變更和不可逆的部署則持續觸發。

這能用於 Claude 以外的模型嗎?

架構原則(獨立評估、結構化投票、雙閘門驗證)適用於任何能遵循人設指令並產生結構化輸出的 LLM。此實作使用 Claude Code hooks 和 Task 工具進行代理生成,這是 Claude 特定的基礎設施。移植到其他模型需要替換生成機制和提示範本,同時保留狀態機、排名系統和驗證閘門。

如何測試一個旨在產生異議的系統?

跨三個層級共 141 項測試:48 項 bash 整合測試驗證 hook 行為(共識流程、品質檢查閘門、遞迴防護),81 項 Python 單元測試以確定性輸入覆蓋每個函式庫模組,12 項端到端測試以固定代理回應模擬完整審議管線。端到端測試涵蓋成功路徑(有建設性的異議達成共識)和失敗路徑(過早一致、未能收斂、預算耗盡)。

審議的延遲影響是什麼?

一次 3 代理審議增加 30-60 秒的實際時間(代理透過 Task 工具循序執行)。一次 10 代理審議增加 2-4 分鐘。共識和品質檢查 hook 各在 200 毫秒內完成。主要瓶頸是每個代理的 LLM 推理時間,而非編排開銷。對於需要審議的決策,這個延遲是可接受的,因為替代方案(稍後才發現錯誤)的時間成本要高得多。


參考文獻


  1. 作者的審議上下文隔離模組。實作於 ~/.claude/lib/deliberation/context_isolation.py。四個隔離層級:L0(系統規則,共享)、L1(工作階段上下文,共享)、L2(代理焦點,私有)、L3(領域模式,依人設而異)。 

  2. 作者的審議配置。閾值定義於 ~/.claude/configs/deliberation-config.json。 

  3. 作者的審議後共識 hook。實作於 ~/.claude/hooks/post-deliberation.sh,連接至 PostToolUse:Task。 

  4. Heuer, Richards J., Psychology of Intelligence Analysis, Center for the Study of Intelligence, CIA, 1999. Chapter 8: Analysis of Competing Hypotheses. Full text (CIA)

  5. Nemeth, Charlan, In Defense of Troublemakers: The Power of Dissent in Life and Business, Basic Books, 2018. See also: Nemeth, C. J., “Differential Contributions of Majority and Minority Influence,” Psychological Review, 93(1), 23-32, 1986. 

  6. Surowiecki, James, The Wisdom of Crowds: Why the Many Are Smarter than the Few, Doubleday, 2004. Chapter 1. 

  7. Choi, H. K., Zhu, X., and Li, S., “Debate or Vote: Which Yields Better Decisions in Multi-Agent Large Language Models?” NeurIPS 2025 Spotlight. arXiv:2508.17536

  8. Kaesberg, L. B. et al., “Voting or Consensus? Decision-Making in Multi-Agent Debate,” Findings of ACL 2025, pp. 11640-11671. ACL Anthology

  9. Wu, H., Li, Z., and Li, L., “Can LLM Agents Really Debate? A Controlled Study of Multi-Agent Debate in Logical Reasoning,” arXiv:2511.07784, 2025. 

  10. Wynn, A., Satija, H., and Hadfield, G., “Talk Isn’t Always Cheap: Understanding Failure Modes in Multi-Agent Debate,” arXiv:2509.05396, 2025. 

  11. Liang, T. et al., “Encouraging Divergent Thinking in Large Language Models through Multi-Agent Debate,” EMNLP 2024, pp. 17889-17904. ACL Anthology

  12. 作者的遞迴防護。生成預算模型位於 ~/.claude/hooks/recursion-guard.sh。代理血統追蹤於 ~/.claude/state/agent-lineage.json。 

  13. 作者的信心模組。實作於 ~/.claude/lib/deliberation/confidence.py。四個維度:模糊性、複雜性、利害程度、上下文依賴性。 

  14. 作者的測試套件。48 項 bash 測試位於 ~/.claude/tests/test-deliberation-pipeline.sh,81 項 Python 測試位於 ~/.claude/tests/test_deliberation_lib.py,12 項端到端測試位於 ~/.claude/tests/test_deliberation_e2e.py。