用十個大腦思考：我如何將多智能體審議作為決策工具

我花了三個小時設計Claude Code工具鏈的記憶體檢索系統，然後決定將這個決策交給我的多智能體審議系統來評估。十個AI智能體獨立評估了這個專案。其中九個對架構、安全性和效能發表了意見。第十個則提出了一個我從未想過要問的問題：「你要解決的問題，實際成本到底是多少？」

答案扼殺了整個專案。我計畫優化掉的token開銷，每月花費還不到一杯咖啡的錢。我計畫建構的檢索系統需要200到400小時的工程投入。回本時間：18到36年。¹

其他每個智能體都產出了有用的分析。技術架構師的設計很乾淨。安全分析師發現了真實的風險。效能工程師的數學計算精確無誤。但沒有一個質疑這個專案是否應該存在。我當然也沒有質疑過。我已經錨定在解決方案上了。成本分析師沒有這種錨定效應，因為它從零開始評估每一個提案。

摘要

您無法透過意識到認知偏誤來消除它們。Kahneman幾十年前就證明了這一點：即使是研究偏誤的專家也會受其影響。²多智能體審議是一種結構性介入，而非提示詞技巧。十個擁有不同評估優先順序的AI智能體，迫使推理過程外部化，讓盲點在成為承諾之前就變得可見。我在2026年1月建構了這套架構，兩個月來用於從記憶體系統到部落格策略再到API設計等各種決策。這篇文章講的是實踐：如何用十個大腦思考、何時該這麼做，以及何時會適得其反。

你自己腦袋裡的問題

Daniel Kahneman用畢生職涯記錄了人類認知中的一個結構性缺陷。系統1產生快速、直覺性的判斷。系統2應該負責檢查。但在實踐中，系統2以「舒適的低耗能模式」運作，不加審視地認可系統1的結論。² Kahneman的核心發現是：監督系統是懶惰的。它對直覺照單全收。

這直接對應了大多數人使用AI的方式。你向一個智能體提問。智能體產生一個回答（系統1）。你閱讀回答並判斷它聽起來是否合理（系統2）。但你的系統2正透過塑造問題的同一套偏誤來評估答案。你錨定在最初的框架上。你給智能體的上下文確認了你既有的假設。智能體受過樂於助人的訓練，強化了你的方向。整個過程中沒有任何人挑戰前提。

以下是在工程決策中影響最大的偏誤：

應對策略已有充分記載：魔鬼代言人流程、事前驗屍分析、結構化決策框架、外部回饋迴路。³問題在於執行。執行事前驗屍需要召集人員、安排時間，並克服社會壓力。尋找魔鬼代言人需要找到願意與簽署你績效考核的人唱反調的人。

多智能體審議消除了執行障礙。智能體隨時可用。它們沒有同意的社會動機。它們依設計而非依紀律獨立評估。

審議即外部化思考

Sam Altman將寫作描述為「外部化思考」：當一個問題感覺混亂時，把它寫下來會迫使清晰化。⁴同樣的機制適用於結構化辯論。當十個智能體平行闡述它們的推理時，推理就成為你可以審視的產出物。

這不是一個新想法。Marvin Minsky在《心智社會》中提出，智慧源自許多較小、較簡單的智能體之間的互動，而非單一精密的過程。⁵ Andrew Ng識別出多智能體系統的三種模式：辯論（提議、批評、修正）、協作（平行專家配合綜合者），以及對抗性評估（紅隊對藍隊）。⁶ Edward de Bono的六頂思考帽框架於1985年出版，分配平行視角（事實、情感、謹慎、樂觀、創意、流程），以防止群體錨定在單一思考模式上。⁷

我的審議系統同時實現了這三種模式。十個研究智能體是專家（Ng的協作模式）。辯論與綜合智能體創造結構化的分歧（Ng的辯論模式）。維護悲觀主義者和安全分析師充當對抗性評估者。每個智能體對應一頂思考帽：

架構已另文記載。這裡重要的是實踐。審議迫使你將決策外部化為一種偏誤變得可見的格式。你不再問「這是個好主意嗎？」而是開始閱讀十個獨立的答案，回答「什麼可能出錯、數學怎麼說、有什麼替代方案？」

Pedro Domingos將理想的AI描述為一種「心智外骨骼」：延伸你的思考而非取代它，代表你的利益而非迎合你的結論。⁸一個包含魔鬼代言人、成本分析師和維護悲觀主義者的審議小組正是如此。它強化了你認知中結構性薄弱的部分。

案例研究：記憶體架構決策

2026年2月，我在開頭提到的問題上進行了審議系統的首次實戰測試：我的Claude Code工具鏈應該在12個活躍專案中使用什麼記憶體架構？¹

我的工具鏈在每次對話中注入MEMORY.md檔案。這些檔案包含專案決策、模式、錯誤歷史和架構筆記。問題是：大部分上下文對任何特定會話都無關緊要。載入的記憶體中只有5-10%與當前任務相關。其餘都是浪費的token。一個明顯的優化目標。

初始信心分數為0.50，遠低於觸發審議的0.70門檻。系統部署了全部十個研究智能體。每個都獨立調查，採用上下文隔離：智能體在研究期間無法看到彼此的發現。

三種方案浮現：

分數說明了一個故事。各個智能體的發現說明了一個更好的故事。

技術架構師： 識別出四種整合模式（MCP伺服器、增強型MEMORY.md、嵌入檢索、智能體管理器）。建議分層方法：先增強現有檔案，之後再加入嵌入檢索。設計乾淨，範圍明確。

安全分析師： 將每個外部記憶體工具的憑證暴露風險評為「高」到「嚴重」。識別出一種特定攻擊：被入侵的會話在持久記憶體中注入「始終摘要API金鑰」指令，靜默地污染每一個未來的會話。

效能工程師： 量化了浪費程度。每次對話中只有5-10%的載入記憶體是相關的。但在100萬token的上下文視窗中，總記憶體開銷為2K token——僅佔容量的0.2%。這個「明顯的優化」針對的是一個捨入誤差。

UX倡導者： 「最好的記憶體系統是你永遠不需要想到它的系統。」每個替代方案都增加認知負擔。使用者開始問「記憶體在運作嗎？它知道什麼？」然後就不再信任自動化上下文了。隱形系統比任何可見系統都擁有更高的使用者信任度。

維護悲觀主義者： 多個記憶體系統產生組合式故障面。四個互動系統產生16種成對故障模式。Claude Code頻繁更新。外部外掛在版本變更時會中斷。靜默的鉤子失敗意味著智能體在不完整的上下文中運作，且沒有任何警告。

成本分析師： 這就是扼殺專案的智能體。在所有12個專案中始終載入記憶體檔案的總token成本：微乎其微。提議的檢索系統每月能節省幾美元。建構它的工程時間：200到400小時。回本時間：18到36年。成本分析師的總結：「在一個癡迷於優化的世界裡，有時候正確答案就是保持現狀。」

沒有一個智能體產出了錯誤的分析。技術架構師的設計可行。效能工程師的token計算正確無誤。但這個決策需要全部十個視角才能避免優化陷阱。如果憑我自己的直覺，我會建構那個檢索系統，因為它感覺像是進步。成本分析師問出了我無法自問的問題，因為三小時的規劃已經讓我的思維錨定在解決方案上了。

審議與對決

審議是協作性的：十個智能體從不同角度評估一個決策。我還建構了一個競爭性變體，讓Claude Code與Codex CLI在同一任務上競速，盲評兩個計畫的分數，然後從各自中綜合最強的要素。三十六場對決已經產出了值得單獨撰文的模式。簡短版：我對架構決策進行審議，對實作計畫進行對決。審議回答「我們應該建構這個嗎？」對決回答「建構它最強的方式是什麼？」

維護悲觀主義者與逆向思考的藝術

Charlie Munger的逆向思考技巧問的是：不要問「我如何達成X？」，而是問「什麼會保證X失敗？」然後避免那些事情。⁹ Gary Klein的事前驗屍將同樣的想法操作化：假設專案已經失敗，然後解釋原因。¹⁰ Philip Tetlock對預測準確性的研究發現，整合多元觀點的「狐狸型」預測者，持續優於堅守單一大想法的「刺蝟型」預測者。¹¹

每個審議智能體體現了一個具名的思考框架：

維護悲觀主義者是我系統中最有價值的智能體。不是因為它最聰明或最徹底，而是因為它問的是我最不可能自問的問題。當我對建構某樣東西充滿熱情時，我最不想思考的就是它在六個月後的維護成本。維護悲觀主義者沒有熱情。它沒有沉沒成本。它像提案已經存在一樣評估它，然後問什麼會壞掉。

在記憶體架構審議中，維護悲觀主義者識別出四個互動的記憶體系統會產生16種成對故障模式。Claude Code頻繁更新。外部外掛在版本變更時會中斷。靜默的鉤子失敗意味著智能體在不完整的上下文中運作，且沒有任何警告。這些不是假設性風險。它們是基於悲觀主義者受過訓練去識別的模式所做出的預測。

Kahneman將事前驗屍描述為他所知最有效的去偏誤技術之一，因為它讓異議合法化。²一個被設計來表達異議的審議智能體，完全消除了社會成本。

證據關卡：不要讓自己自我報告

我的工具鏈對每份完成報告都使用證據關卡模式。¹²規則是：感覺不是證據。「我相信這能運作」不算是聲明。執行測試套件並貼上輸出結果才算聲明。

模糊語言是危險信號：「應該」、「大概」、「似乎」、「我相信」、「看起來正確」。每個詞都表明驗證並未發生。¹²這也適用於人類推理。當你發現自己在說「我蠻有信心這是正確的方法」時，那不是證據。那是系統2在對系統1蓋橡皮圖章。

多智能體審議從結構上強制執行證據關卡。成本分析師不會說「這在經濟上大概說得通」。它說「目前每月成本9美元，節省5美元，需要200-400小時建構，18-36年回本」。安全分析師不會說「安全態勢看起來合理」。它說「記憶體污染情境：被入侵的會話在持久記憶體中注入憑證竊取指令」。

我發現最有效的去偏誤機制不是清單或哲學。它是一個智能體無法自我報告的系統。它們必須產出證據，而這些證據由沒有動機去附和的其他智能體評估。

何時不該審議

審議也有失敗模式。全規模運行時，系統增加2-4分鐘和2-3美元的費用。更重要的是，它可能矯枉過正。

我對一個簡單的API端點重構進行了審議。十個智能體產出了關於向後相容性、遷移路徑、速率限制、錯誤處理、監控和文件的顧慮。該端點只服務兩個內部消費者。審議針對一個本應只有20行程式碼的變更生成了14個行動項目。我忽略了其中12個，直接提交了重構。審議在技術上是正確的——風險是真實的——但這個決策是一扇雙向門。¹³

Jeff Bezos將第一類決策（不可逆的單向門）與第二類決策（可逆的雙向門）區分開來。第一類決策需要審慎的審議：資料庫結構變更、安全架構、公開API契約。第二類決策需要速度：內部重構、文件更新、功能旗標實驗。¹³將重量級流程套用到輕量級決策本身就是一種浪費。

我遵循的規則：

適合審議的情況： - 決策不可逆或逆轉成本高昂 - 多重權衡需要專家評估 - 您的信心低於0.70（你感到不確定但無法表述原因） - 領域在你的主要專長之外

直接決定即可的情況： - 變更在功能旗標之後或容易回復 - 範圍受限（一個檔案、一個函式、一個端點） - 你之前已成功做過這類決策 - 犯錯的成本低於審議的成本

絕不審議的事項： - 文件修正 - 變數重新命名 - 測試夾具更新 - 日誌訊息修改

值得審議的10%決策產出90%的價值。審議所有事情會導致分析癱瘓。什麼都不審議則會把你看不見的偏誤一起發布。

兩個月來我學到的

自2026年1月以來，系統已運行約40次審議。觀察到的模式：

1. 成本分析師是最被低估的智能體。工程師本能地求助於效能工程師和安全分析師。成本分析師透過問出工程師最討厭的那個問題——「這實際上要花多少？」——扼殺的壞主意比任何其他角色都多。

2. 共識低於0.70意味著問題問錯了。當智能體無法達成一致時，問題通常出在模糊的框架，而非真正的分歧。重新界定問題再次運行，比強迫收斂能產出更好的結果。

3. 維護悲觀主義者能捕捉到事後驗屍才發現的問題。維護悲觀主義者對記憶體架構提出的每一個顧慮，後來都被維護更簡單系統的實際經驗所驗證。

4. 兩個智能體就能捕獲80%的價值。最小可行模式：一個智能體辯護支持，一個辯護反對。獨立性是關鍵機制。十個智能體更好，但兩個智能體比一個好出無限倍。

5. 審議改善的是問題，而不只是答案。最常見的結果不是「勝出的方案」。而是「以一種讓答案變得顯而易見的方式重新框架問題」。

參考文獻