用途
LLM Council 的核心思路是：不再只向单一 LLM 提问，而是把多个模型（例如 OpenAI GPT、Google Gemini、Anthropic Claude、xAI Grok 等）组织成一个「LLM 议会」，让它们先各自作答，再互相评审排名，最后汇总成一个最终答案。它适合希望并排比较多个模型输出质量、观察模型之间交叉意见的使用者。
主要能力
提交一个查询后，流程分为三个阶段：
- Stage 1：初步意见。用户查询被分别发给议会中的每个 LLM，各自的回答被收集，并以标签页视图展示，方便逐个查看。
- Stage 2：评审。每个 LLM 会拿到其他 LLM 的回答。底层将模型身份匿名化（Response A/B/C/…），避免评判时偏袒自家模型；模型被要求按准确度和洞察力对这些回答排名。
- Stage 3：最终回答。指定的 Chairman（主席）模型汇总所有模型的回答，编译成一份最终答案呈现给用户。
该 fork 版本在此基础上补充了以下能力：
- 对话历史持久化：从后端 data/conversations.json 加载历史记录，并兼容旧版 data/ 布局（包含 data/conversations/ 下按会话拆分的 JSON 文件），使较早的运行记录重新出现在界面中。
- 侧边栏完整列表：前端请求 /api/conversations?limit=500，避免历史记录被过早截断。
- Stage 2 评委去重：对评委模型去重，避免同一评委被重复计入。
- 标题持久化：Stage 3 完成后生成标题并保存到会话记录，刷新后仍保留并出现在历史中。
- 决策可审计：每次议会回答都会保存一份精简决策追踪（Stage 1 答案、Stage 2 排名、Stage 2 到模型的映射），便于事后检查 Chairman 为何得出该结论。
- 排名与得分可复现：持久化聚合排名（平均排名 + 计数），便于在不同运行、不同提示之间比较议会行为。
- 工具与可复现性：新增 Stage 2 冒烟/质量脚本与配套评测产物，让回归测试可重复。
- 角色设定：实现中的角色集为 Builder / Reviewer / Synthesizer / Contrarian，并在 backend/roles.py 中提供 provider 默认映射；早期 fork 说明中曾描述为 Analyst / Researcher / Critic / Provocateur。
- 真实 SSE 端点：/api/conversations/{id}/message/stream 使用 text/event-stream，逐步推送 stage*_start/complete 事件。
- 持久化 meta/metadata（label_to_model、aggregate_rankings、model_roles），使 Stage 2 正确渲染且运行可事后审查。
- 前端 Stage 2 读取 msg.meta || msg.metadata，兼容 fork 与上游两种载荷结构。
使用方式
- 安装依赖：项目使用 uv 进行项目管理。
- 配置 API Key：在项目根目录创建 .env 文件，在 openrouter.ai 获取 API key，并购买所需额度或开通自动充值。
- 配置模型（可选）：编辑 backend/config.py 自定义议会成员。
- 运行应用：可使用启动脚本，或手动运行——后端一个终端、前端一个终端，然后在浏览器打开 http://localhost:5173。
技术栈：后端为 FastAPI（Python 3.10+）、async httpx、OpenRouter API；前端为 React + Vite，使用 react-markdown 渲染；存储为 data/conversations/ 下的 JSON 文件；包管理为 Python 用 uv、JavaScript 用 npm。
适用场景
- 并排对比多个 LLM 对同一问题的回答。
- 观察多个模型对彼此输出的交叉评价与排名。
- 需要保留历史运行记录、复查决策过程的研究或实验用途。
限制
- 该项目被作者描述为 99% vibe coded 的周末实验，原版作者明确表示不提供任何支持、不打算改进，代码仅供启发使用。
- 需要自行准备 OpenRouter API key 并购买额度。
- 具体费用、性能与效果未在资料中提供。
