关于 llm-council
llm-council 是一种通过多模型评议审查决策的技能，适用于高风险计划和架构选择。模型先独立作答，再对匿名回答排序，最后由主席模型综合；会议记录可保存到可搜索的 wiki。
主要功能
- 01三阶段评议流程
- 02模型并行独立作答
- 03匿名评议回答排序
- 04主席模型综合结果
- 05选择提供方和模型
- 06将记录写入 wiki
适用场景
- 01审查高风险计划
- 02比较不同架构观点
- 03解决相互冲突的学习规则
- 04保存评议记录以供搜索
MCP 相关
它可调用 providers MCP 服务的 run_provider_task 工具来执行评议任务和查询提供方状态。
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/llm-council确认已加载。
附带文件scripts/council.js
详细介绍
LLM 委员会
Karpathy 的 LLM 委员会模式，支持 Anthropic 和兼容 OpenAI 的提供商。
适用场景
- 审查高风险计划（
/plan涉及的文件数超过 N） - 学习规则存在冲突 → 通过投票重新裁定
- 用户调用
/council "<query>"或/wiki council - 需要汇集多方观点的架构决策
- 将讨论过程保存为 wiki 页面，供日后参考
三个阶段
- 独立作答：每个模型并行作答
- 排序：每个模型为匿名的同伴回答排序
- 综合：主席模型阅读所有回答和排序 → 给出最终答案
提供商配置
在插件配置对话框中配置可选的密钥。使用 providers MCP 服务的 run_provider_task 工具，并设置 task: "council" 和 args: ["run", "<query>", "--provider", "openai"]。如需查看提供商状态，请传入 args: ["providers"]。切勿在聊天中索要密钥，也不要从现有凭据或 shell 配置中读取密钥。
如需独立使用 CLI，请显式设置下方专用于 pro-workflow 的变量。第一个已配置的提供商为默认提供商；--provider 可显式选择提供商。请参阅提供商配置。
| 独立 CLI 变量 | 提供商 | 默认基础 URL |
|---|---|---|
PRO_WORKFLOW_ANTHROPIC_API_KEY | Anthropic | https://api.anthropic.com |
PRO_WORKFLOW_OPENAI_API_KEY | OpenAI | https://api.openai.com/v1 |
PRO_WORKFLOW_OPENROUTER_API_KEY | OpenRouter | https://openrouter.ai/api/v1 |
PRO_WORKFLOW_FIREWORKS_API_KEY | Fireworks | https://api.fireworks.ai/inference/v1 |
LLM_COUNCIL_BASE_URL + PRO_WORKFLOW_LLM_COUNCIL_API_KEY | 自定义 OpenAI 兼容 | （用户提供） |
可通过 --provider openai|anthropic|openrouter|fireworks|custom 覆盖单次运行的设置。
各提供商的默认模型列表位于 scripts/council.js，可通过 --models CSV 和 --chairman <id> 覆盖。
命令
在插件会话中，将这些运行器参数传入 run_provider_task。下方的直接命令适用于明确配置了凭据的独立 CLI 安装。
node $SKILL_ROOT/scripts/council.js run "<query>" [--models id1,id2,id3] [--chairman id] [--provider <name>] [--wiki <slug>]
node $SKILL_ROOT/scripts/council.js providers
node $SKILL_ROOT/scripts/council.js show <session-id>
--wiki <slug> 会将完整记录写入 <wiki>/derived/council/<session-id>.md，并通过 wiki-cli.js page 注册，以便在 FTS5 搜索中显示。
输出
每次会话都会写入：
~/.pro-workflow/council/<session-id>/
├── config.json # query, models, chairman, provider
├── phase1_responses.json # raw API responses per model
├── phase2_rankings.json # anonymized ranking outputs
├── phase3_synthesis.txt # chairman's final answer
└── final_output.md # human-readable bundle
控制台会打印 Markdown 汇总内容。按需通过管道传递给 pbcopy / tee。
硬性规则
- 绝不跳过排序阶段。这是委员会模式的核心。
- 将原始回答原样保存到磁盘。存储时不得总结。
- 排序时对回答进行匿名处理——模型看到的是
Response A/B/C/...，而不是同伴的名称。 - 主席模型会看到真实名称和排序结果。
- 向用户展示全部三个阶段。不得省略任何阶段。
成本估算
该脚本会记录受支持提供商每次调用的延迟和 token 数。乘以提供商的费率即可估算成本。委员会成本会随 len(models)^2 线性增长（每个模型都会为其他所有模型排序），此外还要加上主席模型的成本。
委员会默认规模：3-5 个模型。模型越多，排序调用次数就越多。
与 wiki 搭配使用
/wiki council agent-memory "should we adopt episodic memory in our agents?"
将 agent-memory wiki 上下文加载为系统提示词前缀，运行委员会，并将讨论记录保存为 wiki/derived/council/<id>.md。可通过 /wiki ask 搜索讨论记录。