让 AI 开个会——开源了 Open Council

单个 AI 模型回答问题，有幻觉、有偏见、有时深度不够。你多半也有过这种经验：同一个问题问不同的模型，答案还不一样，到底信谁？

Open Council 的思路很直接——别只问一个，让几个模型开个会。 它们各自作答、互相评审、算出一个共识度，最后由一位「主席」模型综合成一个比任何单模型都更可靠的答案。全程在你自己机器上跑。

$ council "Redis vs Memcached，电商场景日均 5000 万 PV 该怎么选？"

[auto] → debate  理由: 检测到架构决策关键词 | 预估: ~120s, 3 Agent
[1/4] Broadcasting to 3 agents...
  ✓ claude-opus   (analyst)    12.3s
  ✓ openai-o4mini (engineer)    9.1s
  ✓ deepseek-chat (innovator)   8.7s
[2/4] Peer review...
[3/4] 共识度: 0.82 ████████████████░░░░ (高)
[4/4] Synthesizing final answer...

一场辩论怎么进行

debate 模式下，一个问题会走完整的五个阶段：

1. 路由：用关键词启发式判断问题类型和复杂度，决定派几个模型、每个演什么角色（分析师、工程师、创新者……）——零 LLM 成本；
2. 广播：多个模型带着各自的角色并行作答；
3. 互评：每个模型匿名评审别人的回答（看不到自己的），从准确性、完整性、实用性、洞察力四个维度打分；
4. 共识：把互评的打分压成一个 0–1 的共识度。达到阈值就收，没到就把分歧点喂回去再辩一轮（最多三轮）；
5. 综合：主席模型带着「谁的回答被同行评得高」这个信息，把多方观点合成最终答案——评分高、批评少的观点权重更大。

不是每个问题都值得这么兴师动众。auto 模式会自动判断：简单问题走 quick（单模型直接答），要对比的走 compare（并行答 + 综合），高价值决策才升到 debate。

几个刻意的设计

• 共识度不是摆设：低共识时系统不早停、强制多辩一轮，但也不拒答——它把偏低的共识度如实亮给你，让你自己判断可信度，而不是把一个分歧很大的结论直接盖章。这套「保留信号、标注不确定性」的取向贯穿始终。
• 纯本地、可追溯：所有数据存在 ~/.council/，不上传任何外部服务；配合本地兼容端点（Ollama、vLLM 等）可以完全离线。每一场辩论的完整过程——原始回答、互评、评分——都持久化到本地，随时用 council history / council show 回溯。
• 管道友好：council "问题" | jq .synthesis——stdout 只输出结果，进度信息走 stderr，天然能接进你的脚本。
• 只走标准 API：接入只有两种协议（anthropic 和 openai），凭证只用环境变量或 0o600 key 文件，通过 base_url 能接任意兼容端点（DeepSeek、Moonshot、Ollama、vLLM、LM Studio）。为什么砍掉 OAuth/CLI 只留标准 API，单开了一篇讲。

适合用在哪

Council 不是用来查「Python list 和 tuple 的区别」的——那种问题一个模型秒答，开会纯属浪费。它的场景是值得多花一两分钟确认的高价值问题：架构决策、技术选型、代码审查、安全审计。这类问题里，一个模型的盲区可能很贵，让几个模型从不同角度互相挑一遍毛病，比单模型一锤定音靠谱得多。

除了命令行，council serve 会起一个本地 Web 控制台（只绑 127.0.0.1），在浏览器里发起辩论、实时观看多专家发言→互评→共识→综合逐阶段展开，也能回看历史。适合不习惯终端的场景。

小结

Open Council 想做的事很窄：把「多问几个 AI 再交叉验证」这件你本来手动在做的事，自动化成一条可复现、可追溯的流水线。

• 多视角覆盖：不同角色从不同维度审问题；
• 交叉验证：互评阶段模型互相挑错，过滤低质量回答；
• 量化置信：共识度告诉你模型间多一致，低共识不硬给结论；
• 纯本地可追溯：数据不出机器，每场辩论可回放。

MIT 协议，代码在 github.com/mahui/open-council。后面几篇会把共识度计算、路由与角色分配、综合前压缩、标准 API 收敛这些实现细节一篇篇拆开讲。