特斯拉前AI总监、OpenAI创始成员 Andrej Karpathy 在周六发布了一个有趣的开源项目 llm-council（LLM理事会），这是一个让多个大语言模型协作回答问题的Web应用。
核心创意：让AI模型互相评审
与传统的单一模型对话不同，LLM Council 采用了一个创新的三阶段流程：
阶段1：初始意见收集
•用户的问题同时发送给理事会中的所有模型
•目前默认包括：GPT-5.1、Gemini 3 Pro、Claude Sonnet 4.5、Grok 4
•每个模型独立给出自己的回答
阶段2：匿名互评
•每个模型会看到其他模型的回答（身份被匿名化）
•模型需要对所有回答进行排名，评估准确性和洞察力
•这避免了模型"偏袒"自己品牌的可能
阶段3：主席总结
•指定的"主席LLM"综合所有回答和评审意见
•生成最终的统一回答呈现给用户
发现
Karpathy 在使用这个工具阅读书籍时发现了一些有趣的现象：
模型会认可对手的优势
"令人惊讶的是，模型们经常愿意选择其他LLM的回答作为最佳答案，而不是自己的。这使得它成为一种有趣的模型评估策略。"
一致的评价趋势
在阅读书籍章节时，模型们一致认为：
•GPT 5.1 是最好和最有洞察力的模型
•Claude 被评为最差（在该领域过于简洁）
•其他模型介于两者之间
但 Karpathy 也指出，这与他自己的主观评价并不完全一致。他认为 GPT 5.1 有时"过于冗长和发散"，而 Gemini 3 则"更加精炼和经过处理"。
实现
这个项目是一个"周六vibe coding"的成果，采用了现代化的技术栈：
后端：
•FastAPI (Python 3.10+)
•异步 httpx
•OpenRouter API（统一多模型接口）
前端：
•React + Vite
•react-markdown 用于渲染
数据存储：
•JSON 文件存储对话历史
包管理：
•Python 使用 uv
•JavaScript 使用 npm
快速开始
安装依赖
uv synccd frontend && npm install
配置 API Key
创建 .env 文件：
OPENROUTER_API_KEY=sk-or-v1-...
运行应用
./start.sh
然后访问 http://localhost:5173
设计空间的探索
Karpathy 指出，LLM集成（ensemble）的构建仍然是一个未被充分探索的领域。LLM理事会的数据流设计存在着巨大的设计空间：
•如何组织模型之间的交互？
•评审机制应该如何设计？
•最终答案的综合策略有哪些可能？
项目定位
Karpathy 明确表示这是一个"vibe code"项目：
"这个项目99%是作为一个有趣的周六黑客项目vibe coded出来的，因为我想在与LLM一起阅读书籍的过程中并排探索和评估多个LLM。能够并排看到多个回答，以及所有LLM对彼此输出的交叉意见，这很好也很有用。"
他表示不会提供任何支持，代码按原样提供给其他人作为灵感来源。更有趣的是他的态度：
"代码现在是短暂的，库已经过时了，让你的LLM以你喜欢的任何方式改变它。"
应用场景
虽然是一个周末项目，但 LLM Council 展示了几个有价值的应用方向：
1.模型评估：通过互评机制了解不同模型的相对优势
2.质量提升：综合多个模型的优势得到更好的答案
3.并排比较：直观地看到不同模型对同一问题的处理方式
4.深度阅读：与多个AI助手一起阅读和讨论复杂内容
