Claude Council
把同一个问题并行投给多个 AI 编码助手，将各家回答并排展示并给出综合分析，帮你避免单一模型的偏见误导关键决策。
数据流披露出色：明示 OpenRouter 为双重披露、缓存以明文存储完整提示并落 .gitignore、图像字节不写入缓存/导出、/claude-council:advise 在发送会话摘录前展示摘要并请求确认，自动上下文限制为 5 文件约 1 万 token。扣分点：auto-context 默认开启会把源码自动发往第三方 API，虽有 --no-auto-context 但默认选择偏激进；缓存明文长期驻留本地磁盘；导出与后台作业落盘后无明确的撤销/回滚路径；发布者未经注册处验证。CI 中按 digest 固定 action 并对 shellcheck 做 SHA256 校验，加分。
README 内部一致且详尽（CLI 优先于 API、回退与缓存键规则都写明）；依赖外部 API/CLI 时有发现与回退机制（本地 council 兜底、视觉兄弟回退并在输出前缀说明）。扣分点：本次仅见 README 与 CI/测试文件，核心脚本的错误处理无法静态核实；失败信息仅见片段（stderr 角色提示、作业标记 failed）。
能力边界处理是亮点：'Stated vs Assumed' 一节明确指出供应商只能基于描述推理、一致同意可能源于共同错误前提；--local 的诚实警告说明同模型一致不等于跨厂商佐证。环境适配好（bash 3.2 兼容目标、tmux、Windows Git Bash 分片、安装陷阱）。扣分点：proactive agent 的触发条件较宽泛，可能造成打扰；目标场景描述偏重个人开发者工作流。
信息架构清晰（Quick start/Usage/Configuration/Reference/Development），安装说明详细并指出两个真实陷阱，已知限制以诚实警告形式充分陈述，MIT 许可完整。扣分点：未见 CHANGELOG 或版本记录；命名稳定性方面，位置式角色与 OPENROUTER_MODELS 顺序耦合的脆弱性作者自己承认；维护责任仅见 SECURITY.md 的响应承诺与 stale 工作流，无具体维护者/路线图。
输出可用性强：并排展示、综合分析区分共识与分歧、quiet/export/async 等模式；边际价值明确——多模型交叉核对与偏差对冲，且对重复模型的一致性做出去伪处理；成本效益透明（标准 vs agent 模式的延迟与费用对照表、缓存节省费用）。扣分点：多供应商查询本身成本天然较高，缓存未覆盖辩论第二轮等场景。
README 对行为的声明具体且可追溯到功能（缓存键、角色绑定规则、字节/turn 数展示），但静态评审只能核实文档层面的自洽，无法对照核心脚本——扣分；唯一提供的佐证文件是 CI 与测试运行器，无法与 README 中大量行为声明相互印证；产品本身通过 OBSERVED/NOT VERIFIED 标签区分事实与推断，值得肯定，但评审自身的声明与实现之间的分离只能给中等分。
- auto-context 默认开启：普通提问可能自动把源码文件发送给第三方 API，敏感代码库建议习惯性使用 --no-auto-context。
- 缓存与 council-*.md 导出以明文保存完整提示（含文件内容），本地磁盘留有敏感副本；共享或镜像工作区前需清理。
- OpenRouter 提示会经过路由商与上游两方，属于双重披露；对数据驻留有要求的团队应绕过该席位。
- 位置式 --roles 与 OPENROUTER_MODELS 顺序耦合，增删供应商会静默改变角色分配，建议使用 provider=role 显式绑定。
- --local 模式的多个成员同为 Claude，其一致同意不构成跨厂商佐证，不要据此作为独立验证。
- 静态评审未见 CHANGELOG 与核心脚本源码，版本演进与实际错误处理需在采纳前另行核实。
这个 Agent 能做什么，适合哪些场景？
claude-council 是一个 Claude Code 插件，通过 /claude-council:ask 等斜杠命令把同一问题同时发给 Gemini、OpenAI、Grok、Perplexity、Kimi 以及任意 OpenRouter 可路由的模型，也支持 codex、antigravity（agy）、grok、kimi 等 CLI 的订阅认证方式和本地 ollama 模型。它把各家回答以厂商配色横幅并排展示，并生成一段综合（synthesis），区分各家一致与分歧之处；当所有模型一致时，还会指出该共识所依赖的假设。在 tmux 中结果会实时流入侧边窗格；支持角色分配、两轮辩论模式、--agents 深度分析、--async 后台任务、响应缓存和 Markdown 导出。部署形态即 Claude Code 插件（通过 hex/claude-marketplace 安装），也可直接运行 scripts/query-council.sh 用于自动化场景，要求 curl 和 jq，MIT 许可。
安装后，/claude-council:ask 会按配置发现可用提供方（API 密钥、PATH 上的 codex/agy/grok/kimi CLI、或本地 ollama），自动注入最多 5 个相关文件（约 1 万 token 上限）或通过 --file/--image 手动附加上下文，随后用 curl 并行查询各家 API 或调用各 CLI。响应以 JSON 结构返回（metadata + round1/round2），在 tmux 侧边窗格流式渲染，包含厂商色横幅、耗时和模型名，并生成综合分析：分歧点、共识及其前提，还会把可核验的声明标注为 OBSERVED 或 NOT VERIFIED。可选项包括：--roles（security/performance/devil 等角色）、--debate（第二轮互相反驳）、--agents（每个提供方一个 Claude 分析代理，成本约 4 倍、延迟 15-25 秒）、--local（无任何密钥时用多个互相隔离的 Claude 子代理组成议会）、--async 后台任务（/claude-council:result 获取或取消）、响应缓存（默认 1 小时 TTL）、--output 导出 Markdown，以及可选的 stop-gate（在 Claude 结束回合前用第二个模型审查未提交的 git diff）。
- 架构决策者要在 UUID 与 BIGINT 主键、REST 与 GraphQL 等方案间抉择，希望听到多家模型互为校验而非依赖单一模型的偏见
- 工程师调试陷入死胡同时，让多个模型从不同角度审视问题，proactive 的 council-advisor 代理会主动建议召开议会
- 安全审查场景：用 --roles=security,devil,compliance 预设让不同模型分别承担安全审计、唱反调和合规角色审查代码
- 使用推理或深度研究模型（可能耗时数分钟）的用户，用 --async 把查询转后台，之后用 /claude-council:result 获取结果
- 预算有限或注重隐私的本地开发者：无任何 API 密钥时用 --local 运行纯 Claude 议会，或用 ollama 让回答完全不出本机
- 需要留存 AI 辅助决策审计记录的团队，用 --output 将问答与综合导出为 Markdown 存入文档目录
这个 Agent 有哪些优点和局限？
- 跨厂商交叉验证是核心差异化能力：API 密钥、四个订阅制 CLI 和本地 ollama 共约十种接座方式，openrouter 座位默认可补上 Anthropic Claude，让议会覆盖原本缺席的厂商
- 综合分析诚实标注不确定性：区分各家一致与分歧，全员一致时点名共识依赖的假设，并把可核验声明标注为 OBSERVED / NOT VERIFIED，防止错误的自信一致
- 丰富的决策增强机制：角色分配（security/devil 等 8 种）、两轮辩论模式、--agents 结构化深度分析（可断点续跑）、本地议会模式
- 工程化细节完善：响应缓存与模型可用性缓存分离、推理模型 token 上限自动 8 倍提升、CLI 失败自动回退 API 兄弟、tmux 流式窗格支持失败重试与自适应明暗主题
- 强依赖 Claude Code 生态：斜杠命令、Workflow 工具（--agents 需要）和插件机制都绑定 Claude Code，脱离它只能裸用 bash 脚本
- 成本与延迟可显著放大：--agents 模式约 4 倍 Claude API 用量加 15-25 秒延迟（实测一次八座议会约 45.6 万分析 token）；多提供方并行查询本身也按各家计费
- 隐私需主动管理：缓存目录以明文保存完整提示词（含 --file 内容），OpenRouter 座位会双重披露（发到 OpenRouter 再转到上游），stop-gate 会把整个未提交 diff 发给外部提供方
- 文档自述的局限：提供方只能看到问题描述而非真实系统，错误前提会引发「自信的全员一致」；kimi CLI 曾处理 64KB 文件超过 15 分钟，CLI 提供方单次尝试无重试
如何安装或部署这个 Agent？
推荐方式是通过 Claude Code 插件市场：
/plugin marketplace add hex/claude-marketplace
/plugin install claude-council随后至少配置一个提供方，任一即可：
export OPENAI_API_KEY="..."（或 GEMINI_API_KEY、XAI_API_KEY、PERPLEXITY_API_KEY、KIMI_API_KEY、OPENROUTER_API_KEY）；或者安装 codex / agy（Antigravity）/ grok / kimi CLI，用现有订阅认证，无需 API 密钥；或本地安装 ollama。
运行要求：curl 与 jq；macOS、Linux 或 Windows（经 Git Bash）。
手动方式（仅限开发/离线）：git clone https://github.com/hex/claude-council.git 后用 claude --plugin-dir /path/to/claude-council 加载，注意不要克隆进 ~/.claude/plugins/（那是托管缓存，不会扫描手动插件）。
如何使用这个 Agent？
基本用法：
/claude-council:ask "Should I use UUID or BIGINT primary keys for a SaaS users table?"常用变体：
/claude-council:ask --providers=gemini,openai "..." 指定提供方
/claude-council:ask --roles=balanced "Review this implementation" 角色预设
/claude-council:ask --debate "..." 两轮辩论
/claude-council:ask --file=src/auth.ts "..." 附加文件
/claude-council:ask --image=shot.png "..." 附图（支持 png/jpg/jpeg/webp/gif，≤10MB）
/claude-council:ask --quiet "..." 只显示综合
/claude-council:ask --async "..." 后接 /claude-council:result <job-id> 后台任务
/claude-council:status 检查配置与连通性
/claude-council:advise "..." 把当前会话摘要送交议会
不使用 Claude Code 时可直接运行脚本：
bash scripts/query-council.sh --providers=gemini,openai --roles=balanced -- "Review this pattern"关键环境变量：COUNCIL_PROVIDERS 固定默认名册、COUNCIL_VERBOSITY=brief|standard|detailed、COUNCIL_CACHE_DIR/TTL、各提供方 <PROVIDER>_MODEL 覆盖默认模型。
这个 Agent 与同类方案有什么区别？
与直接在 Claude Code 里逐一咨询各模型相比，claude-council 的价值在于并行查询、并排对比和自动综合；相比单一模型自查，它通过多厂商立场与角色/辩论机制降低单一偏见风险。若用户只需要一个外部模型视角，配置单个 API 密钥的轻量方案即可；若需要跨厂商交叉验证，该插件是明显更完整的工具。