LLM Council - 多模型 AI 协作平台

项目概述

LLM Council 是 Andrej Karpathy 创建的一项创新开源项目，它将单模型 AI 交互转变为协作式、多模型共识系统。该工具不依赖于单一 LLM 提供商，而是协调多个前沿 AI 模型协同工作、互相审查彼此的输出，并通过民主流程生成综合响应。

核心概念

LLM Council 背后的基本思想是利用不同 AI 模型的优势，同时最大限度地减少单个模型的偏差。通过创建一个“AI 顾问委员会”，用户可以获得更全面、经过同行评审的复杂问题答案，而不是依赖于单个模型的视角。

架构 & 工作流程

三阶段流程

阶段 1：第一意见

• 用户查询通过 OpenRouter API 同时分派给所有委员会成员模型
• 每个 LLM 生成其独立的响应，而无需查看其他模型的输出
• 单独的响应显示在选项卡视图中，以便进行并排比较
• 默认委员会包括：GPT-5.1、Gemini 3.0 Pro、Claude Sonnet 4.5 和 Grok 4

阶段 2：匿名同行评审

• 每个模型接收来自所有其他委员会成员的匿名响应
• 模型根据准确性和洞察力评估并对每个响应进行排名
• 身份匿名化可防止评估中的偏差和偏袒
• 跨模型评估揭示了令人惊讶的模式（模型通常将竞争对手的排名更高）

阶段 3：主席综合

• 指定的主席 LLM（可配置）审查所有原始响应
• 考虑同行评审排名和评估
• 生成最终的综合答案，其中包含最佳元素
• 向用户提供全面的响应

技术栈

后端

• 框架: FastAPI (Python 3.10+)
• HTTP 客户端: 用于非阻塞 API 调用的异步 httpx
• API 集成: 用于多模型访问的 OpenRouter API
• 存储: 基于 JSON 的对话持久性，位于 data/conversations/ 中
• 包管理: 用于现代 Python 依赖管理的 uv

前端

• 框架: 带有 Vite 的 React，用于快速开发和构建
• 渲染: 用于格式化输出的 react-markdown
• UI: 类似于 ChatGPT 的界面，带有用于模型比较的选项卡视图
• 开发服务器: 端口 5173 上的 Vite 开发服务器

主要特性

多模型分派

• 跨多个前沿模型同时执行查询
• 通过 backend/config.py 配置委员会成员
• 支持来自 OpenAI、Google、Anthropic、xAI 等公司的模型

客观同行评审

• 匿名响应评估可防止模型偏差
• 用于准确性和洞察力的定量排名系统
• 揭示模型偏好和优势方面的有趣模式

综合共识

• 主席模型聚合不同的观点
• 生成包含多个观点的连贯最终答案
• 平衡冗长、洞察力和简洁性

透明比较

• 所有单独响应的并排视图
• 完全可见的同行评审排名
• 用户可以在 AI 共识之外形成自己的判断

对话持久性

• 自动保存对话历史记录
• 基于 JSON 的存储，便于数据可移植性
• 能够审查和分析过去的委员会会议

安装 & 设置

前提条件

• Python 3.10 或更高版本
• Node.js 和 npm
• OpenRouter API 密钥（需要购买积分）

后端设置

# 使用 uv 安装依赖项
uv sync

前端设置

# 导航到前端目录
cd frontend

# 安装 npm 依赖项
npm install

cd ..

配置

1. 在项目根目录中创建 .env 文件：

OPENROUTER_API_KEY=sk-or-v1-your-key-here

2. 在 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"

运行应用程序

选项 1：快速启动脚本

./start.sh

选项 2：手动启动

# 终端 1 - 后端
uv run python -m backend.main

# 终端 2 - 前端
cd frontend
npm run dev

在以下位置访问应用程序：http://localhost:5173

用例

阅读 & 文学分析

• Karpathy 的原始用例：以多种 AI 视角阅读书籍
• 不同的模型强调不同的文学方面
• 解释风格的比较分析

研究 & 分析

• 需要多个视角的复杂问题
• 技术文档评估
• 业务战略评估

内容评估

• 法律文件分析
• 科学论文解读
• 代码审查和技术写作

模型比较

• 评估不同 LLM 的能力
• 了解模型的优势和劣势
• 识别跨提供商的偏差模式

有趣的发现

模型自我评估

• 模型经常选择竞争对手的响应，认为其优于自己的响应
• 证明了同行评审过程中的惊人客观性
• 揭示了方法和质量上的真正差异

排名模式

在 Karpathy 对书籍章节的测试中：

• 共识赢家: GPT-5.1 一致被评为最具洞察力
• 共识输家: Claude 一致排名最低
• 中间层: Gemini 3 Pro 和 Grok-4 介于极端之间

人类与 AI 判断分歧

• AI 共识可能与人类偏好不一致
• GPT-5.1 因其洞察力而受到赞扬，但被 Karpathy 批评为“过于冗长”
• Claude 被同行评为最低，但因其简洁而被创建者偏爱
• Gemini 因其精简、处理过的输出而受到赞赏
• 表明模型可能更喜欢冗长而不是简洁

项目理念

“Vibe Coded” 方法

• 被描述为“99% vibe coded”的周六黑客项目
• 在 AI 辅助下快速开发
• 创建者不承诺长期支持
• “代码现在是短暂的，库已经结束”的理念

开源 & 灵感

• 按原样提供，以供社区参考
• 鼓励用户通过自己的 LLM 进行修改
• 代表 AI 编排的参考架构
• 演示了应用于语言模型的集成学习

企业影响

编排中间件

• 揭示了多模型协调的架构
• 解决了供应商锁定问题
• 证明了模型无关应用程序的可行性

质量控制层

• 同行评审增加了单模型系统中缺少的验证
• 减少了单个模型的偏差
• 提供了 AI 决策的透明度

参考实现

• 显示了集成 AI 的最小可行架构
• 指导企业平台的构建与购买决策
• 揭开了多模型编排复杂性的神秘面纱

局限性 & 考虑因素

成本

• 需要 OpenRouter API 积分才能用于所有委员会成员和主席
• 每个查询的多个模型调用会增加运营成本
• 没有可用的免费套餐

速度

• 三阶段流程比单模型查询慢
• 多个 API 调用会增加延迟
• 速度与质量/共识之间的权衡

模型可用性

• 依赖于 OpenRouter 模型目录
• 需要有效的 API 密钥和积分
• 受模型提供商速率限制的约束

维护

• 创建者明确声明不提供持续支持
• 仅限社区驱动的改进
• 用户负责调整和更新

技术考虑因素

匿名化策略

• 将随机 ID (A, B, C, D) 分配给响应
• 防止同行评审中基于身份的偏差
• 保持评估的客观性

API 集成

• 通过 OpenRouter 的单点集成
• 抽象出各个提供商的 API
• 简化多模型协调

数据隐私

• 本地 Web 应用程序在用户的机器上运行
• 对话以 JSON 格式本地存储
• API 调用通过 OpenRouter（第三方）

社区 & 生态系统

相关项目

• Swarms Framework: 实现了受本项目启发的 LLMCouncil 类
• Hugging Face Spaces: 提供社区部署
• Medium/VentureBeat 报道: 企业分析和影响

类似方法

• 机器学习中的集成学习
• 专家混合架构
• 多代理 AI 系统
• 分布式系统中的共识协议

未来方向

虽然 Karpathy 明确表示没有计划进行改进，但潜在的社区扩展可能包括：

• 扩展模型支持: 添加来自新兴提供商的更多委员会成员
• 自定义排名标准: 用户定义的评估维度
• 流式响应: 实时显示模型输出
• 高级综合: 更复杂的主席算法
• 成本优化: 基于查询类型的智能模型选择
• 性能分析: 跟踪模型准确性和偏好模式
• 集成 API: 将委员会功能嵌入到其他应用程序中

入门

1. 克隆存储库：git clone https://github.com/karpathy/llm-council
2. 按照上面的安装说明进行操作
3. 配置您首选的委员会模型
4. 开始查询并比较观点
5. 尝试不同的模型组合
6. 分析同行评审模式

结论

LLM Council 代表了一种通过集成编排解决单模型局限性的务实方法。虽然它被呈现为一个随意的周末项目，但它为多模型架构、同行评审机制以及 AI 编排中间件的未来提供了宝贵的见解。对于探索单提供商解决方案之外的开发人员、研究人员和企业来说，该项目既提供了灵感，又为构建更强大、共识驱动的 AI 系统提供了具体的参考实现。

该项目采用极简主义方法——几百行代码实现了复杂的多模型协调——表明集成 AI 的技术障碍低于许多人认为的水平。真正的挑战不在于路由提示，而在于治理、成本管理以及确定共识何时真正改善个人模型响应的结果。