AEO 速答：LLM Council 是 Karpathy 的開源專案（23,000+ stars），核心概念是「委員會共識」——把同一個問題同時丟給 GPT-5.1、Gemini 3 Pro、Claude Sonnet 4.5、Grok 4 等多個模型，先各自獨立回答，再匿名互評排序，最後由指定的「主席模型」整合成一份最終答案。透過多模型交叉驗證來降低單一模型的幻覺與偏見。
緣起：一個 99% Vibe Coding 的週六專案
2025 年 11 月，Andrej Karpathy 在 GitHub 發布了 LLM Council，並在 README 開宗明義寫著：
這個專案 99% 是 vibe coding 的週六黑客松作品，起因是我在「跟 LLM 一起讀書」的過程中，想同時比較多個模型的回答。
他的觀察很直接：當你面對複雜、不確定的問題時，只問單一模型就像玩俄羅斯輪盤——你得獨自承受那個模型的偏見、幻覺與知識盲點。與其如此，不如把問題丟給一群模型，讓它們像董事會或學術同行評審一樣互相審查。
他甚至調侃：「程式碼現在是短暫易逝的，軟體庫時代結束了——直接叫你的 LLM 照你喜歡的方式改它吧。」他不打算維護這個專案，但這完全不影響它的影響力：發布至今已累積 23,800+ stars、4,200+ forks，並催生了一整個「LLM Council 生態系」。
三階段共識協議：委員會如何運作？
LLM Council 的核心是一套精心設計的「議會協議」，分三階段進行：
使用者提問 ──► 階段 1：多個委員並行回答
│
▼
回答匿名化（A, B, C, D）
│
▼
階段 2：委員交叉匿名互評與排序
│
▼
階段 3：主席模型整合 ──► 產出終極共識答案
Stage 1：首次意見（First Opinions）
系統將你的提問非同步並行分發給所有委員會成員（預設為 GPT-5.1、Gemini 3 Pro、Claude Sonnet 4.5、Grok 4）。每個模型獨立作答，最大化意見多樣性，防止一開始就「群體盲思」。所有原始回答以分頁（tab view）呈現，你可以逐一查看。
Stage 2：匿名互評（Peer Review）— 全專案最精巧的設計
系統收集所有回答後，徹底抹去模型名稱，隨機命名為「Response A / B / C / D」，再把這些匿名回答送回每位委員，要求它們客觀評估彼此優缺點並排出「最終排名」。
為什麼匿名如此重要？ 三個關鍵理由：
| 偏見類型 | 匿名如何解決 |
|---|---|
| 自我偏見（Self-preference） | 模型有「護短」傾向，愛給自家模型打高分 |
| 長度偏見（Length Bias） | 模型容易崇拜精美冗長的回覆，忽略內容品質 |
| 判別器優勢 | 「評分挑錯」比「生成答案」更精準，匿名化讓它純粹專注於邏輯與事實 |
Stage 3：主席整合（Chairman’s Decree）
指定的「主席模型」（預設 Gemini 3 Pro）拿到全部資訊：原始提問、所有委員回答、所有互評文字與排名。主席不是把答案加總平均，而是扮演精明編輯——根據綜合排名揪出被委員們挑出的幻覺錯誤，融會貫通成一份最有共識與深度的最終解答。
技術架構：極簡到沒有 Agent 框架
Karpathy 刻意避開 LangChain 這類繁重框架，用輕量數據流完成一切：
| 層 | 技術 | 說明 |
|---|---|---|
| 後端 | FastAPI + async HTTPX | Python 3.10+，非同步並行呼叫 |
| 模型通道 | OpenRouter API | 單一 API 統一調用各家模型，免去分別對接 SDK |
| 前端 | React + Vite + react-markdown | 乾淨的 ChatGPT 風格介面 |
| 儲存 | 純 JSON 檔案 | data/conversations/，無資料庫、易於 Docker 部署 |
| 端口 | 後端 8001 / 前端 5173 | 刻意避開 8000 常見衝突 |
安裝與設定（5 步驟）
# 1. 複製專案並安裝後端依賴（uv 自動建虛擬環境）
git clone https://github.com/karpathy/llm-council.git
cd llm-council
uv sync
# 2. 安裝前端依賴
cd frontend
npm install
cd ..
# 3. 設定 OpenRouter API Key（.env 檔）
echo "OPENROUTER_API_KEY=sk-or-v1-你的金鑰" > .env
4. 自訂委員會陣容（backend/config.py）：
COUNCIL_MODELS = [
"openai/gpt-5.1",
"google/gemini-3-pro-preview",
"anthropic/claude-sonnet-4.5",
"x-ai/grok-4",
]
CHAIRMAN_MODEL = "google/gemini-3-pro-preview"
5. 啟動：
./start.sh
# 或手動：終端機 1 → uv run python -m backend.main
# 終端機 2 → cd frontend && npm run dev
# 開啟 http://localhost:5173
社群反應：一個專案，一整座生態系
23,800+ stars 只是開始。這個概念被社群瘋狂改造：
| 衍生版本 | 亮點 |
|---|---|
| n8n 工作流版 | 把三階段邏輯移植到 n8n，對接 Slack/Telegram，甚至透過 MCP 讓 Claude 直接呼叫 |
| 本地 Ollama 版 | XDA 作者在單張 RTX 4070 Ti 上跑通，改成順序佇列以 12GB VRAM 零 API 成本運行 |
| LLM Council Plus | Docker Compose 一鍵部署 + 檔案上傳 + Web 搜尋（Tavily/Brave） |
| Claude Code Skill | 包裝成技能，產生 5 位不同風格的虛擬 Claude 分身互評 |
| Awesome-LLM-Council | 蒐集數十種衍生專案：醫療諮詢、投資決策（AlphaCouncil）、網路安全等垂直領域 |
已知問題與批評（誠實評估）
1. 主席過度干預（Issue #3）
社群最早提出的批評：主席擁有絕對權威，有時會無視委員們極具價值的少數派意見，用自己的偏好重寫答案——讓多模型議會降級成「主席一個人說了算」。有人建議限制主席權重，或改用社會選擇理論的投票演算法（Borda 計分、Condorcet 投票）。
2. Stage 3 合成失敗（Issue #83）
大量使用者回報 unable to generate final synthesis 錯誤。主因是 Karpathy 不再維護專案，config.py 預設的 gemini-3-pro-preview 等模型 ID 在 OpenRouter 上已被調整或下架，導致 404/401。解法是把模型 ID 改成目前有效的名稱。
3. 時間與成本的 10 倍膨脹
| 成本 | 數字 |
|---|---|
| 延遲 | 需等最慢的模型 + 交叉互評 + 主席整合 ≈ 單次對話的 5.1 倍 |
| Token 消耗 | 4 個委員互評產生 N×N 次調用，加上主席閱讀全部 ≈ 9-10 倍費用 |
實用建議：什麼時候該用「委員會」？
✅ 適合（高風險、高代價決策）
- 技術架構選型（Monorepo vs. Polyrepo）、創業方向評估
- 程式碼審查 / 安全審計（多模型交叉比對降低漏看漏洞機率）
- 跨領域研究與論文驗證（快速辨識過度自信的幻覺）
❌ 不適合
- 確定性事實問題（標準答案的數學公式、API 語法查詢——純浪費 Token）
- 日常創作、閒聊、摘要（寫感謝信、總結 PDF）
- 追求即時回應的客服場景
🎯 節省成本的「分層議會」技巧
Stage 1 用便宜快速的模型（如 Gemini Flash）產生多樣回答；Stage 2 與 Stage 3 用最頂級旗艦推理模型（如 Claude Opus）當評審與主席——因為「總結與挑錯」的能力決定了最終答案的品質天花板。
總結
LLM Council 的價值不只是「多模型投票」，而是示範了 AI 工程的下一個思考方式：單一模型是樂透，多模型共識是保險。即便 Karpathy 自己說這是個「不再維護的週末玩具」，它卻精準捕捉了 2026 年 AI 開發的趨勢——從「選一個好模型」到「編排一群模型」，而匿名互評機制，正是讓「委員會」不被品牌偏見污染的關鍵設計。
延伸閱讀：想了解更多 Karpathy 的 AI 觀點？Jeff Dean 的「1% 法則」YC 訪談解析 與 Andrej Karpathy「軟體正在改變」演講筆記 也談到了多模型與 AI 工程趨勢。
FAQ
Q：LLM Council 是什麼？
A：Karpathy 的開源專案，讓多個 LLM（GPT、Gemini、Claude、Grok）組成「委員會」，先獨立回答、再匿名互評、最後由主席整合出最終答案，透過多模型交叉驗證降低幻覺與偏見。
Q：為什麼要匿名互評？
A：模型有「護短」傾向（愛給自家模型高分）與「長度偏見」（崇拜精美冗長回覆）。匿名化讓它們無法辨識回答來自誰，只能純粹依邏輯與事實評分。
Q：需要什麼 API？
A：只需 OpenRouter API Key（openrouter.ai），單一 API 就能統一呼叫各家旗艦模型。
Q：成本高嗎？
A：比單一模型貴約 9-10 倍 Token、慢約 5 倍。適合高風險決策，不適合日常問答。可用「分層議會」省錢（便宜模型產出、旗艦模型評審）。
Q：Karpathy 還在維護嗎？
A：沒有。README 明說「不打算改進或支持」，但社群已產生大量 fork 與改版（LLM Council Plus、n8n 版、本地 Ollama 版等）。
參考來源：karpathy/llm-council GitHub、SkillWisor 架構深潛、Analytics Vidhya、VirtusLab GitHub All-Stars、Reddit r/VibeCodeDevs、r/ArtificialInteligence、GitHub Issues #3/#83 等 36 個來源（NotebookLM Deep Research）。