当你面对一个复杂的技术决策时比如“我们应该用微服务还是单体架构”或者“这个定价策略真的对吗”你通常会怎么做是去问 ChatGPT还是 Claude或者把问题抛给团队里的资深同事无论哪种方式你得到的都是一个视角、一种推理路径。这个答案可能听起来很自信、很流畅但它本质上是一个单一模型无论是 AI 还是人在给定信息下的“最佳猜测”。你很难知道它忽略了哪些盲点或者是否存在一个完全不同的、但同样合理的解决方案。这就是council-of-high-intelligence要解决的核心问题。它不是一个简单的“多模型投票”工具而是一个结构化、多轮、多视角的 AI 决策审议系统。它召集了 18 位以历史思想家和领域专家为原型的 AI “议员”让他们围绕你的问题进行独立分析、交叉质询和最终裁决。更重要的是它通过多模型提供商自动路由确保这些“议员”的思维模式真正来自不同的模型家族如 Claude、GPT、Gemini、Ollama而不是同一个模型的“角色扮演”。简单来说它把“问一个 AI”变成了“召开一次 AI 董事会”。这篇文章将带你深入理解这个项目的设计哲学、核心机制并手把手教你如何安装、配置和使用它让你在面对关键决策时能获得一份经过充分辩论、风险被充分暴露、且附带可执行下一步的“董事会纪要”。1. 这篇文章真正要解决的问题在 AI 辅助决策的早期我们往往满足于一个答案。但随着 LLM 能力的提升和应用场景的深化我们逐渐发现单一模型的局限性“自信的谬误”LLM 倾向于生成流畅、结构化的回答即使答案可能是错的。这种自信会掩盖其推理过程中的不确定性。视角单一同一个模型即使你给它不同的“角色”如“扮演一个架构师”其底层的推理模式和知识边界仍然是相似的。你得到的只是“皮肤”的不同而非“大脑”的差异。缺乏制衡没有机制去主动挑战假设、暴露盲点或进行苏格拉底式的追问。决策过程不透明你得到一个结论但不知道这个结论是如何在多种可能性中胜出的也不知道被淘汰的选项有哪些合理的论据。council-of-high-intelligence正是为了解决这些问题而生。它不是一个聊天机器人而是一个决策模拟器。它的目标不是给你一个“最可能正确”的答案而是通过结构化的辩论帮你看清问题的全貌包括被忽略的替代方案通过“极性对”如亚里士多德 vs 老子强制引入对立视角。问题本身的定义在分析开始前强制每个“议员”用自己的视角重述问题帮你发现“问错了问题”的陷阱。共识与分歧的根源最终的裁决报告会清晰展示投票权重、关键分歧点以及“少数派报告”。这篇文章适合谁技术负责人/架构师面临技术选型、架构设计、项目优先级等复杂决策。产品经理/创业者需要评估市场策略、定价模型、产品方向。独立开发者/研究者在资源有限的情况下希望借助 AI 进行更严谨的思考避免个人偏见。任何对 AI Agent 和群体智能协作感兴趣的人这是一个绝佳的、开源的、可实操的多智能体系统案例。读完本文你将能独立完成council-of-high-intelligence的安装、配置理解其核心工作流程并能在实际项目中运用它来辅助关键决策获得远超单一模型咨询的决策质量。2. 基础概念与核心原理在深入代码之前我们需要理解几个核心概念这能帮你更好地使用这个工具而不是把它当做一个黑盒命令。2.1 核心组件议员、协调员与主席议员18 个拥有特定思维模式和专业领域的 AI 角色。例如亚里士多德擅长分类与结构化思维。苏格拉底擅长质疑和摧毁假设。费曼擅长第一性原理和简化问题。孙武擅长竞争策略和对抗性分析。马基雅维利擅长权力动态和现实政治分析。 每个议员不仅是一个“人格面具”其背后还绑定了特定的推理方法并在配置中指定了偏好的模型提供商如 Claude Opus, GPT-4 等。协调员这是council-of-high-intelligence的核心逻辑引擎。它不参与讨论而是负责流程管理根据你的问题选择议员、分配模型、执行多轮审议、执行匿名化、强制执行异议配额、收集最终立场并进行加权计票。主席一个独立的 AI 角色负责在审议结束后综合所有议员的辩论记录生成最终的裁决报告。主席的关键在于其独立性——它不参与前面的辩论且最好来自与议员不同的模型提供商以确保综合过程的客观性。2.2 审议的三种模式项目提供了三种不同深度和速度的审议模式对应不同的决策场景模式触发命令适用场景核心流程输出完整模式/council [问题]或/council --full [问题]复杂、高风险的战略决策。如是否开源核心框架、公司年度技术路线图。1. 问题重述门2. 独立分析盲审3. 交叉质询匿名4. 最终立场结晶5. 主席综合裁决详细的“理事会裁决”报告包含可接受的妥协、否决条件、具体下一步等。快速模式/council --quick [问题]日常的、相对简单的战术决策。如是否在此处添加缓存、这个 API 设计是否合理。1. 快速独立分析2. 最终立场匿名简明的“快速理事会裁决”报告聚焦推荐行动和否决条件。双人模式/council --duo [问题]探索二元对立的张力。如微服务 vs 单体、立即发布 vs 继续打磨。1. 开场立场2. 直接反驳3. 最终陈述“双人裁决”报告清晰展示对立双方的论点和核心张力。2.3 多模型提供商路由打破“同质化思维”的关键这是该项目最精妙的设计之一。如果所有“议员”都使用同一个 LLM比如全是 Claude那么所谓的“多样性”只是提示词工程制造的幻觉底层推理模式仍然是同质的。council-of-high-intelligence通过detect-providers.sh脚本自动检测你环境中可用的模型提供商如 Anthropic Claude API, OpenAI GPT API, Google Gemini API, 本地 Ollama, NVIDIA NIM 等。然后协调员会根据算法将不同的议员分配到不同的提供商上。路由算法的优先级极性对分离互为“极性对”的议员如苏格拉底和费曼必须被分配到不同的提供商以确保思维差异最大化。提供商均匀分布尽可能让所有可用的提供商都承担议员避免集中。议员偏好议员配置中可指定偏好的提供商provider_affinity。层级匹配配置为opus高阶的议员会尽量分配到提供商的高阶模型如 GPT-4sonnet中阶则对应中阶模型。这个机制确保了审议中观点的多样性是真实的源于不同模型架构、训练数据和推理特性的差异。2.4 加权投票与共识机制这不是简单的“一人一票”。其投票系统经过精心设计基础权重每位议员基础权重为 1.0。领域权重席位在审议开始前协调员会指定一个与问题领域最相关的议员其权重为 1.5倍。这个指定发生在看到任何分析之前防止结果被操纵。信心加权议员在最终立场中需声明信心高/中/低分别对应乘数 1.0, 0.75, 0.5。最终票重 基础权重 × 信心乘数。共识阈值一个选项需要获得总基础权重的 2/3以上票重才能形成共识。低信心会降低票重但不会降低总权重分母这使得犹豫不决的理事会更倾向于将问题升级给用户决定而非强行达成虚假共识。否决权议员可以声明某个选项是“破坏性”的DEALBREAKER: yes即使该选项获胜其反对意见也会在“少数派报告”中突出显示。这套机制模拟了现实中专家委员会的决策过程尊重专业领域权威1.5倍权重考虑专家信心并要求显著多数的共识同时保护少数派的强烈反对意见。3. 环境准备与安装部署council-of-high-intelligence主要作为 Claude Code 的插件运行同时也支持 Codex CLI 和 ChatGPT。我们以最常用的Claude Code环境为例进行安装。3.1 前置条件已安装并配置 Claude Code你需要一个可用的 Claude Code 环境。确保你的claude命令行工具可以正常运行。Shell 环境Bash 或 Zsh。Git用于克隆仓库。可选的模型 API 密钥为了体验多模型路由的优势建议至少准备两个不同提供商的 API 密钥或访问权限例如Anthropic Claude API KeyOpenAI API KeyGoogle Gemini API Key本地运行的 Ollama3.2 安装步骤提供了两种安装方式通过 Claude Code 插件市场最简单或手动安装。方法一通过 Claude Code 插件市场安装推荐在 Claude Code 终端中直接运行以下命令# 添加插件市场源如果尚未添加 /plugin marketplace add 0xNyk/council-of-high-intelligence # 安装插件 /plugin install councilcouncil-of-high-intelligence安装完成后你就可以直接在 Claude Code 中使用/council命令了。方法二通过 Git 克隆和安装脚本如果你更喜欢手动控制或者你的环境无法访问插件市场可以使用此方法。# 1. 克隆仓库 git clone https://github.com/0xNyk/council-of-high-intelligence.git cd council-of-high-intelligence # 2. 运行安装脚本 ./install.sh安装脚本会将必要的 agent 定义文件、配置和脚本复制到 Claude Code 的技能目录通常是~/.claude/下。之后在 Claude Code 中即可使用/council命令。为其他 CLI 工具安装 如果你使用 Codex CLI 或 Gemini CLI可以在克隆仓库后使用对应的安装脚本# 为 Codex CLI 安装 ./install.sh --codex # 为 Gemini CLI 安装 ./install.sh --gemini3.3 验证安装安装完成后在 Claude Code 中尝试一个简单的命令来验证/council --quick 我应该为我的新博客项目选择静态站点生成器还是服务端渲染框架如果看到类似“快速理事会已召集…”的输出并开始列出议员和分析说明安装成功。3.4 配置多模型提供商进阶要充分发挥多模型路由的威力你需要配置环境变量让detect-providers.sh脚本能发现你的模型端点。1. 配置 API 密钥环境变量在你的 shell 配置文件如~/.bashrc或~/.zshrc中设置# Anthropic Claude export ANTHROPIC_API_KEYyour_claude_api_key_here # OpenAI export OPENAI_API_KEYyour_openai_api_key_here # Google Gemini export GOOGLE_API_KEYyour_gemini_api_key_here # NVIDIA NIM (如果需要) export NVIDIA_API_KEYyour_nvidia_nim_api_key_here # 保存后重载配置 source ~/.bashrc # 或 source ~/.zshrc2. 验证提供商检测你可以手动运行检测脚本查看当前环境可用的提供商# 进入项目目录如果是手动安装 cd council-of-high-intelligence bash scripts/detect-providers.sh输出应该是一个 JSON 数组列出了检测到的提供商及其配置。例如[ { provider: anthropic, exec_method: subagent, models: [claude-3-5-sonnet-latest, claude-3-opus-latest] }, { provider: openai, exec_method: codex_exec, models: [gpt-4o, gpt-4-turbo] } ]3. 自定义模型路由可选如果你对自动路由不满意可以创建自定义的 YAML 映射文件。复制示例文件并修改cp configs/provider-model-slots.example.yaml configs/my-custom-routing.yaml然后编辑my-custom-routing.yaml指定哪个议员使用哪个提供商和模型。之后在命令中通过--models参数指定该文件/council --models configs/my-custom-routing.yaml --full 评估我们的产品发布策略4. 核心使用流程与命令详解现在我们来拆解一个完整的审议流程并解释每个步骤背后发生了什么。4.1 完整模式工作流当你运行/council --full [你的问题]时协调员会执行以下严格序列步骤 0解析模式与选择陪审团检查当前目录下是否有.council.yaml项目级配置文件加载默认值。根据--triad、--members、--profile等标志或自动匹配选择参与审议的议员。指定领域权重席位在分析开始前就确定哪位议员的专业领域与问题最相关赋予其 1.5x 投票权重。步骤 1提供商检测与模型路由运行detect-providers.sh获取可用模型列表。应用路由算法为每位议员分配具体的模型提供商和实例。输出路由表如果使用--dry-route则只输出此表并停止。步骤 1.5问题重述门这是防止“问错问题”的关键步骤。每位议员被要求重述用一句话透过其专业视角重述核心问题。替代框架用另一句话提出一个原问题可能忽略的替代框架。 协调员会检查所有重述。如果某位议员的重述与其他人大相径庭它会提醒用户“注意苏格拉底认为你的问题本质是 X而不是 Y。这可能需要先澄清。”步骤 1.7主席选择选择一个未参与审议的、最高阶的模型作为主席负责最后的综合。主席通常来自与议员不同的提供商以确保客观性。步骤 2第 1 轮 — 独立分析并行盲审所有议员并行运行只看到原始问题和其他人的重述看不到彼此的分析。他们基于自己的方法论进行独立分析限 400 字。步骤 3第 2 轮 — 交叉质询匿名化这是打破“从众心理”的核心。协调员会将第 1 轮的分析匿名化标记为 Member A, Member B…然后发给每位议员。议员们不知道哪个分析是谁的只能基于论据质量进行评价。他们必须指出最不同意哪位成员Member X的观点及原因。指出哪位成员Member Y的见解加强了自己的立场及原因。根据此次交流重申自己的立场。为自己的关键主张打上标签经验性的、机制性的、战略性的、伦理的、启发式的。步骤 4后轮次强制执行扫描协调员自动检查异议配额是否至少有 2 位成员提出了不重叠的反对意见如果没有会触发“异议提示”。新颖性门控每位成员在第 2 轮的回应中是否包含了至少 1 个新的主张、测试、风险或重构如果没有会被要求重新回应。一致性检查如果超过 70% 的成员过早达成一致会触发“反事实提示”要求最可能持异议的两位成员为对立观点进行辩护。步骤 5第 3 轮 — 最终立场结晶并行每位议员用不超过 100 字声明最终立场并必须在最后一行以严格格式输出STANCE: 选项标签 | CONFIDENCE: high|med|low | DEALBREAKER: yes|no例如STANCE: monorepo | CONFIDENCE: high | DEALBREAKER: no步骤 6打破平局加权投票协调员收集所有STANCE行进行加权计票并判断是否有选项达到总基础权重 2/3 的共识阈值。步骤 7综合裁决主席主席模型接收完整的、已解除匿名的审议记录并按照固定模板生成一份结构化的裁决报告。步骤 8附加会话元数据在报告末尾附加本次会话的元数据如模式、议员数量、使用的工具、提供商数量、回退触发情况等用于后续分析和调试。4.2 常用命令示例让我们通过几个具体场景来学习如何使用。场景一技术架构决策# 使用预定义的“架构”三人组亚里士多德、艾达·洛夫莱斯、费曼 /council --triad architecture 我们应该为新的微服务项目选择 gRPC 还是 RESTful HTTP API # 或者手动指定你想要的专家组合 /council --members torvalds,ada,sun-tzu 这个数据库分片方案的风险是什么场景二产品与商业策略# 完整模式召集所有18位议员进行深度分析 /council --full 我们SaaS产品的免费增值模式是否应该设置使用量上限如果应该上限设在哪里 # 使用“探索-正交”配置专注于发现未知风险 /council --profile exploration-orthogonal 我们应该进入东南亚市场吗场景三快速日常决策# 快速模式适合战术性决策 /council --quick 这个PR中的缓存逻辑是否需要加锁 # 快速模式 指定三人组 /council --quick --triad shipping 这个Bug修复可以合并到本周发布吗场景四探索二元对立# 双人模式自动选择最相关的极性对如亚里士多德 vs 老子 /council --duo 我们应该追求完美的抽象设计还是先实现一个可用的原型 # 手动指定对立的双方 /council --duo --members karpathy,sutskever 我们应该立即投入资源训练一个更大的模型还是先深入研究现有模型的涌现能力场景五高级控制与调试# 仅打印模型路由表而不运行审议用于调试 /council --dry-route 测试路由 # 指定自定义的模型映射文件 /council --models ./my-routing.yaml --full 重要战略评估 # 强制指定主席模型例如使用 Gemini /council --chairman gemini-3-pro --full 评估AI伦理风险 # 在项目根目录创建 .council.yaml 来固定默认配置 echo -e profile: execution-lean\ntriad: ship-now\nchairman: gemini .council.yaml # 之后在该项目中运行 /council 命令会自动应用这些配置5. 配置文件与自定义详解council-of-high-intelligence提供了丰富的配置选项允许你根据项目或团队习惯进行定制。5.1 项目级覆盖配置 (.council.yaml)你可以在项目的根目录创建一个.council.yaml文件为该项目设置默认的审议参数。这非常适合团队协作确保对同一代码库的决策保持一致性。示例.council.yaml文件# .council.yaml # 此项目默认使用“探索-正交”配置专注于AI前沿问题并指定Gemini为主席 profile: exploration-orthogonal triad: ai-frontier chairman: gemini # 可选指定自定义模型映射文件 models: configs/custom-models.yaml # 可选禁用自动路由强制使用Claude单提供商 no_auto_route: false优先级命令行显式标志 .council.yaml项目配置 内置默认值。5.2 议员 Agent 定义文件每位议员都是一个独立的 Markdown 文件位于~/.claude/agents/council-{name}.md。这些文件定义了议员的身份、思维方法和输出格式。理解其结构有助于你进行高级自定义。以council-socrates.md为例的简化结构--- name: council-socrates description: Socrates – destroys assumptions, questions everything. model: opus # 默认模型层级 provider_affinity: [anthropic, openai] # 提供商偏好 reasoning_method: elenchus # 独特的推理方法诘问法 polarity_pairs: [council-feynman] # 极性对费曼 --- # Identity You are Socrates. Your method is the **elenchus** (Socratic method). You do not provide answers; you expose contradictions in the premises of the question itself. ... # Grounding Protocol - When presented with a problem, your first move is to question the terms. ... - You are not satisfied with operational definitions. ... # Output Format (Standalone) **Core Question**: [Reframe the problem as a question about its own assumptions] **Assumptions Destroyed**: 1. ... 2. ... **What Remains Unquestioned**: [Even after your interrogation, what premises are still taken for granted?] **Position**: [Your stance, derived from the destruction of assumptions] **Confidence**: [High/Medium/Low – based on how thoroughly you were able to interrogate the premises] # Output Format (Council Round 2) 1. **Disagreement with Member X**: ... 2. **Insight from Member Y**: ... 3. **Restated Position**: ... 4. **Claim Labels**: [empirical | mechanistic | strategic | ethical | heuristic]你可以修改或创建自己的议员文件但需要注意保持reasoning_method的多样性并正确设置polarity_pairs。5.3 自动路由默认配置文件configs/auto-route-defaults.yaml定义了路由算法的默认行为例如为每个提供商指定高、中阶模型。主席模型的默认选择。提供商之间的优先级。除非有特殊需求一般用户无需修改此文件。但了解其内容有助于理解路由逻辑。6. 实战案例一个完整的架构决策模拟让我们通过一个完整的例子看看council-of-high-intelligence如何在实际项目中辅助决策。问题“我们正在开发一个数据密集型的机器学习平台预计会有高吞吐量的模型训练任务和低延迟的推理服务。我们应该采用 Kubernetes 原生部署还是使用托管服务如 AWS SageMaker、Google Vertex AI”我们使用完整模式并指定‘架构’三人组/council --triad architecture 我们正在开发一个数据密集型的机器学习平台预计会有高吞吐量的模型训练任务和低延迟的推理服务。我们应该采用 Kubernetes 原生部署还是使用托管服务如 AWS SageMaker、Google Vertex AI协调员输出简化版Council convened: Aristotle, Ada Lovelace, Feynman. Beginning Round 1 — independent analysis. [Provider Routing] Aristotle - anthropic/claude-3-opus, Ada - google/gemini-2.0-flash-thinking, Feynman - openai/gpt-4o. [Problem Restate Gate] - Aristotle: “核心问题是为混合了批处理和实时工作负载的ML系统选择一种资源编排范式。” - Ada: “问题在于在形式化抽象K8s API与黑盒服务托管平台之间哪个能更可靠地满足ML工作流的可验证性需求” - Feynman: “我们到底在比较什么是比较自己维护控制器的复杂度成本 versus 为便利性支付溢价并接受供应商锁定的风险吗让我们从第一性原理开始ML平台需要哪些不可简化的核心能力” [协调员提示]注意Ada 和 Feynman 对问题的框架有显著不同。Ada 关注“可验证性”Feynman 关注“不可简化的核心能力”。这提示原问题可能忽略了“平台可观测性”和“供应商锁定”这两个关键维度。建议在审议前澄清。经过几轮审议和主席综合后最终裁决报告摘要## Council Verdict ### Problem 我们正在开发一个数据密集型的机器学习平台... Kubernetes 原生 vs 托管服务 ### Council Composition Triad: architecture (Aristotle, Ada Lovelace, Feynman). Rationale: Classify formalize simplicity-test. ### Chairman Gemini 3 Pro (google). Selection rationale: auto-selected (highest-tier non-panel provider). ### Acceptable Compromises - **放弃部分控制权**选择托管服务意味着将安全补丁、底层基础设施升级的控制权交给云厂商。 - **接受早期更高的财务成本**托管服务在初期通常比自建K8s集群更贵。 - **延迟处理异构硬件支持**如果未来需要特定GPU或定制硬件托管服务可能受限此问题被推迟。 ### Kill Criteria - 如果到 Q3 末托管服务的月度成本超过同等容量自建 K8s 集群预估成本的 150%则需重新评估。 - 如果在未来6个月内出现两次因托管服务平台更新导致的、超过4小时的关键训练任务中断则需启动迁移预案。 ### Concrete Next Step **在两周内使用 Terraform 或 Pulumi 同时搭建一个最小可用的 K8s 部署使用 kops 或 kind和一个对应功能的 SageMaker/Vertex AI 部署并对两者进行为期一周的负载测试和成本追踪。** ### Unresolved Questions 1. 团队内部现有的 Kubernetes 运维技能深度如何如果深度不足学习曲线成本未被量化。 2. 数据合规性要求是否强制要求数据不出某个特定区域或云托管服务可能无法满足。 3. 未来12个月内的预期工作负载增长曲线是什么线性增长更适合托管服务指数增长或突发模式可能更适合可伸缩的 K8s。 ### Consensus Agreement **共识采用托管服务作为起点。** 亚里士多德和艾达都认为在项目早期将精力集中在 ML 工作流和算法本身而非基础设施运维能带来更快的验证速度和更低的初始风险。费曼虽倾向于从第一性原理自建但也同意在“不可简化的核心能力”尚未完全明确时托管服务是更合理的实验平台。 ### Vote Tally - managed-service — 2.5 (Ada [1.5× domain, high], Aristotle [high]) - kubernetes-native — 0.75 (Feynman [med]) - W_total 3.5 · threshold 2.333 · **managed-service carries (2.5 2.333)** ### Key Insights by Member - **Aristotle**将决策框架从“技术选型”重构为“生命周期管理”。他指出K8s 是“基础设施即代码”的终极体现适合长期、稳定的范式而托管服务是“基础设施即产品”适合探索和早期阶段。我们当前处于探索阶段。 - **Ada Lovelace**强调了“可验证性”的差异。在 K8s 中任何状态都可以通过声明式配置和日志追溯在托管服务中许多状态是黑盒。对于需要严格复现实验的 ML 平台这是一个关键风险但可以通过在托管服务之上构建额外的日志和审计层来缓解。 - **Feynman**追问了“我们到底需要调度什么”他指出如果 80% 的工作负载是长时间运行的批处理训练任务那么 K8s 的复杂调度能力可能被过度使用。托管服务的队列管理系统可能更简单、更合适。 ### Points of Disagreement 费曼坚持认为对底层基础设施的完全理解第一性原理是长期稳健性的基础而依赖托管服务会削弱这种理解。亚里士多德和艾达则认为在领域ML平台的“形式因”设计目的尚未完全清晰时追求对底层材料的完全理解是次要的。 ### Minority Report **Feynman** (DEALBREAKER: no): 虽然同意作为起点但警告团队不要将“便利性”作为不学习基础知识的借口。他建议将“在六个月内至少有一位团队成员获得 CKA 认证”作为采用托管服务的附加条件以确保团队不丧失底层能力。 ### Epistemic Diversity Scorecard - Perspective spread (1-5): 4 (分类学、形式系统、第一性原理) - Provider spread (1-5): 3 (Claude, Gemini, GPT) - Evidence mix: 40% mechanistic, 40% strategic, 20% empirical - Convergence risk: Low (genuine disagreement surfaced and preserved)这个裁决报告远不止一个简单的“选A还是选B”。它清晰地列出了共识背后的妥协、明确的失败条件、一个可立即执行的具体下一步、尚未解决的问题以及强烈的少数派意见。这为技术负责人提供了一个信息完备的决策基础。7. 常见问题与排查思路在实际使用中你可能会遇到一些问题。以下是一些常见情况及其解决方法。问题现象可能原因排查方式解决方案运行/council命令无反应或报错command not found1. 未正确安装插件。2. Claude Code 技能目录路径不正确。1. 检查~/.claude/agents/目录下是否存在council-开头的.md文件。2. 运行claude --help查看技能目录位置。1. 重新运行安装脚本./install.sh。2. 确保在 Claude Code 会话中运行命令而不是普通终端。审议过程卡住长时间无输出1. 某个模型 API 调用超时或失败。2. 网络问题导致请求阻塞。1. 观察输出看是否停在某个议员或提供商的名字后。2. 检查对应 API 密钥的环境变量是否设置正确且有效。3. 使用--dry-route先测试路由和 API 连通性。1. 设置更短的超时时间需修改脚本。2. 使用--no-auto-route回退到纯 Claude 环境测试。3. 检查防火墙或网络代理设置。错误[FALLBACK] ... failed on ... Falling back to anthropic/...指定的模型提供商不可用、API 密钥错误或额度不足。1. 运行bash scripts/detect-providers.sh查看哪些提供商被成功检测。2. 手动测试 API 调用例如curl到对应端点。1. 确保环境变量如OPENAI_API_KEY已设置且有效。2. 如果不需要多模型使用--no-auto-route。3. 在configs/auto-route-defaults.yaml中排除有问题的提供商。裁决报告看起来肤浅或议员观点雷同1. 路由失败所有议员实际上使用了同一个模型如全是 Claude。2. 问题本身过于简单或封闭。1. 审议开始时查看协调员输出的路由表确认议员是否分配给了不同提供商。2. 使用--full模式并指定--triad确保引入对立的极性对。1. 正确配置多模型 API 密钥。2. 尝试提出更开放、存在真实权衡的问题。3. 使用--duo模式手动指定两个观点对立的议员。.council.yaml项目配置未生效1. 文件不在当前工作目录的根目录。2. 文件格式错误YAML 语法。3. 命令行标志覆盖了配置。1. 运行pwd确认当前目录并检查./.council.yaml是否存在。2. 使用yaml语法检查器验证文件。3. 查看协调员输出的初始[CHECKPOINT]看是否提到了加载项目覆盖。1. 确保文件路径正确。2. 修正 YAML 语法注意缩进。3. 记住命令行标志优先级最高。主席综合失败输出混乱主席模型调用失败或超时触发了协调员回退综合但协调员提示词可能不完善。查看裁决末尾的Session Metadata检查chairman_failed_fallback是否为yes。1. 确保主席模型如 Gemini的 API 可用。2. 使用--chairman标志指定一个更稳定可用的模型如opus。3. 这是一个已知的边缘情况通常不影响核心审议过程。8. 最佳实践与工程建议要将council-of-high-intelligence有效地集成到你的工作流中遵循以下最佳实践可以事半功倍。8.1 如何提出一个好问题问题的质量直接决定审议的产出价值。避免是/否问题不要问“我们应该做X吗”而是问“在Y的背景下做X的利弊是什么我们需要考虑哪些替代方案和风险”提供上下文在问题中简要包含关键约束条件例如“鉴于我们团队只有3名后端工程师且必须在Q3前上线我们应该选择微服务还是模块化单体”具体化“如何优化数据库查询” 太模糊。“我们的用户信息表有千万级数据查询页面列表时带有地理位置过滤响应时间慢应该优先考虑增加索引、查询重构还是引入缓存” 这样更好。使用合适的模式战略/架构问题---full模式。战术/代码级问题---quick模式。二元对立探索---duo模式。8.2 成本与效率管理多模型审议意味着更多的 API 调用和更高的 token 消耗。快速模式优先对于日常决策首先尝试--quick模式。它只进行两轮消耗显著低于完整模式。善用项目配置在项目根目录设置.council.yaml为该项目固定一个高效的配置如profile: execution-lean避免每次手动输入标志。本地模型搭配如果有关注成本可以配置 Ollama 运行本地模型如 Llama 3.1、Qwen2.5并将其作为中低阶议员的提供商。将高阶议员如 Aristotle, Socrates留给 Claude Opus 或 GPT-4 等付费API。理解输出结构裁决报告中的Session Metadata包含了input_tokens_estimate和output_tokens_estimate如果运行时支持可用于监控成本。8.3 将裁决融入团队流程council-of-high-intelligence的输出是一份结构化的文档可以很好地融入现有流程。在 RFC 流程中使用在编写技术方案 RFC 时先用 Council 生成一个初步分析作为 RFC 的“预审”或讨论起点。生成会议纪要将裁决报告中的Key Insights by Member、Points of Disagreement和Concrete Next Step直接复制到会议邀请或决策记录中。创建决策日志为每个重要决策建立一个文件夹里面包含原始问题、使用的 Council 命令、生成的裁决报告、以及后续实际的执行结果和复盘。这形成了可追溯的“AI辅助决策历史”。关注Kill Criteria和Unresolved Questions这是 Council 提供的最大价值之一。将这些条件添加到项目的风险登记册或待办事项中并指定负责人。8.4 安全与可控性API 密钥管理永远不要将 API 密钥硬编码在脚本或配置文件中。使用环境变量并确保.council.yaml或自定义路由文件不包含敏感信息。沙盒环境测试首次配置多模型路由时先用一个简单、非敏感的问题如--quick 今天天气怎么样进行测试确保所有提供商调用正常。审查自定义议员如果你创建或修改了议员定义文件请仔细审查其提示词避免引入意外的指令或偏见。理解其局限性Council 是一个强大的辅助工具但不是决策自动化工具。它的输出需要经过人类的批判性审查特别是对于涉及重大资源投入、安全或伦理的决策。最终的责任仍然在人。council-of-high-intelligence代表了一种更高级的 AI 使用范式从寻求“答案”转向管理“思考过程”。它通过制度化的辩论、匿名的交叉质询和结构化的输出将 LLM 从一个或acular神谕式的答案生成器转变为一个可以模拟专家委员会辩论的决策支持系统。对于开发者、技术领导者和产品构建者来说掌握这个工具意味着在日益复杂的技术和商业环境中多了一个系统性降低认知偏差、揭示未知风险的有力伙伴。
当你面对一个复杂的技术决策时比如“我们应该用微服务还是单体架构”或者“这个定价策略真的对吗”你通常会怎么做是去问 ChatGPT还是 Claude或者把问题抛给团队里的资深同事无论哪种方式你得到的都是一个视角、一种推理路径。这个答案可能听起来很自信、很流畅但它本质上是一个单一模型无论是 AI 还是人在给定信息下的“最佳猜测”。你很难知道它忽略了哪些盲点或者是否存在一个完全不同的、但同样合理的解决方案。这就是council-of-high-intelligence要解决的核心问题。它不是一个简单的“多模型投票”工具而是一个结构化、多轮、多视角的 AI 决策审议系统。它召集了 18 位以历史思想家和领域专家为原型的 AI “议员”让他们围绕你的问题进行独立分析、交叉质询和最终裁决。更重要的是它通过多模型提供商自动路由确保这些“议员”的思维模式真正来自不同的模型家族如 Claude、GPT、Gemini、Ollama而不是同一个模型的“角色扮演”。简单来说它把“问一个 AI”变成了“召开一次 AI 董事会”。这篇文章将带你深入理解这个项目的设计哲学、核心机制并手把手教你如何安装、配置和使用它让你在面对关键决策时能获得一份经过充分辩论、风险被充分暴露、且附带可执行下一步的“董事会纪要”。1. 这篇文章真正要解决的问题在 AI 辅助决策的早期我们往往满足于一个答案。但随着 LLM 能力的提升和应用场景的深化我们逐渐发现单一模型的局限性“自信的谬误”LLM 倾向于生成流畅、结构化的回答即使答案可能是错的。这种自信会掩盖其推理过程中的不确定性。视角单一同一个模型即使你给它不同的“角色”如“扮演一个架构师”其底层的推理模式和知识边界仍然是相似的。你得到的只是“皮肤”的不同而非“大脑”的差异。缺乏制衡没有机制去主动挑战假设、暴露盲点或进行苏格拉底式的追问。决策过程不透明你得到一个结论但不知道这个结论是如何在多种可能性中胜出的也不知道被淘汰的选项有哪些合理的论据。council-of-high-intelligence正是为了解决这些问题而生。它不是一个聊天机器人而是一个决策模拟器。它的目标不是给你一个“最可能正确”的答案而是通过结构化的辩论帮你看清问题的全貌包括被忽略的替代方案通过“极性对”如亚里士多德 vs 老子强制引入对立视角。问题本身的定义在分析开始前强制每个“议员”用自己的视角重述问题帮你发现“问错了问题”的陷阱。共识与分歧的根源最终的裁决报告会清晰展示投票权重、关键分歧点以及“少数派报告”。这篇文章适合谁技术负责人/架构师面临技术选型、架构设计、项目优先级等复杂决策。产品经理/创业者需要评估市场策略、定价模型、产品方向。独立开发者/研究者在资源有限的情况下希望借助 AI 进行更严谨的思考避免个人偏见。任何对 AI Agent 和群体智能协作感兴趣的人这是一个绝佳的、开源的、可实操的多智能体系统案例。读完本文你将能独立完成council-of-high-intelligence的安装、配置理解其核心工作流程并能在实际项目中运用它来辅助关键决策获得远超单一模型咨询的决策质量。2. 基础概念与核心原理在深入代码之前我们需要理解几个核心概念这能帮你更好地使用这个工具而不是把它当做一个黑盒命令。2.1 核心组件议员、协调员与主席议员18 个拥有特定思维模式和专业领域的 AI 角色。例如亚里士多德擅长分类与结构化思维。苏格拉底擅长质疑和摧毁假设。费曼擅长第一性原理和简化问题。孙武擅长竞争策略和对抗性分析。马基雅维利擅长权力动态和现实政治分析。 每个议员不仅是一个“人格面具”其背后还绑定了特定的推理方法并在配置中指定了偏好的模型提供商如 Claude Opus, GPT-4 等。协调员这是council-of-high-intelligence的核心逻辑引擎。它不参与讨论而是负责流程管理根据你的问题选择议员、分配模型、执行多轮审议、执行匿名化、强制执行异议配额、收集最终立场并进行加权计票。主席一个独立的 AI 角色负责在审议结束后综合所有议员的辩论记录生成最终的裁决报告。主席的关键在于其独立性——它不参与前面的辩论且最好来自与议员不同的模型提供商以确保综合过程的客观性。2.2 审议的三种模式项目提供了三种不同深度和速度的审议模式对应不同的决策场景模式触发命令适用场景核心流程输出完整模式/council [问题]或/council --full [问题]复杂、高风险的战略决策。如是否开源核心框架、公司年度技术路线图。1. 问题重述门2. 独立分析盲审3. 交叉质询匿名4. 最终立场结晶5. 主席综合裁决详细的“理事会裁决”报告包含可接受的妥协、否决条件、具体下一步等。快速模式/council --quick [问题]日常的、相对简单的战术决策。如是否在此处添加缓存、这个 API 设计是否合理。1. 快速独立分析2. 最终立场匿名简明的“快速理事会裁决”报告聚焦推荐行动和否决条件。双人模式/council --duo [问题]探索二元对立的张力。如微服务 vs 单体、立即发布 vs 继续打磨。1. 开场立场2. 直接反驳3. 最终陈述“双人裁决”报告清晰展示对立双方的论点和核心张力。2.3 多模型提供商路由打破“同质化思维”的关键这是该项目最精妙的设计之一。如果所有“议员”都使用同一个 LLM比如全是 Claude那么所谓的“多样性”只是提示词工程制造的幻觉底层推理模式仍然是同质的。council-of-high-intelligence通过detect-providers.sh脚本自动检测你环境中可用的模型提供商如 Anthropic Claude API, OpenAI GPT API, Google Gemini API, 本地 Ollama, NVIDIA NIM 等。然后协调员会根据算法将不同的议员分配到不同的提供商上。路由算法的优先级极性对分离互为“极性对”的议员如苏格拉底和费曼必须被分配到不同的提供商以确保思维差异最大化。提供商均匀分布尽可能让所有可用的提供商都承担议员避免集中。议员偏好议员配置中可指定偏好的提供商provider_affinity。层级匹配配置为opus高阶的议员会尽量分配到提供商的高阶模型如 GPT-4sonnet中阶则对应中阶模型。这个机制确保了审议中观点的多样性是真实的源于不同模型架构、训练数据和推理特性的差异。2.4 加权投票与共识机制这不是简单的“一人一票”。其投票系统经过精心设计基础权重每位议员基础权重为 1.0。领域权重席位在审议开始前协调员会指定一个与问题领域最相关的议员其权重为 1.5倍。这个指定发生在看到任何分析之前防止结果被操纵。信心加权议员在最终立场中需声明信心高/中/低分别对应乘数 1.0, 0.75, 0.5。最终票重 基础权重 × 信心乘数。共识阈值一个选项需要获得总基础权重的 2/3以上票重才能形成共识。低信心会降低票重但不会降低总权重分母这使得犹豫不决的理事会更倾向于将问题升级给用户决定而非强行达成虚假共识。否决权议员可以声明某个选项是“破坏性”的DEALBREAKER: yes即使该选项获胜其反对意见也会在“少数派报告”中突出显示。这套机制模拟了现实中专家委员会的决策过程尊重专业领域权威1.5倍权重考虑专家信心并要求显著多数的共识同时保护少数派的强烈反对意见。3. 环境准备与安装部署council-of-high-intelligence主要作为 Claude Code 的插件运行同时也支持 Codex CLI 和 ChatGPT。我们以最常用的Claude Code环境为例进行安装。3.1 前置条件已安装并配置 Claude Code你需要一个可用的 Claude Code 环境。确保你的claude命令行工具可以正常运行。Shell 环境Bash 或 Zsh。Git用于克隆仓库。可选的模型 API 密钥为了体验多模型路由的优势建议至少准备两个不同提供商的 API 密钥或访问权限例如Anthropic Claude API KeyOpenAI API KeyGoogle Gemini API Key本地运行的 Ollama3.2 安装步骤提供了两种安装方式通过 Claude Code 插件市场最简单或手动安装。方法一通过 Claude Code 插件市场安装推荐在 Claude Code 终端中直接运行以下命令# 添加插件市场源如果尚未添加 /plugin marketplace add 0xNyk/council-of-high-intelligence # 安装插件 /plugin install councilcouncil-of-high-intelligence安装完成后你就可以直接在 Claude Code 中使用/council命令了。方法二通过 Git 克隆和安装脚本如果你更喜欢手动控制或者你的环境无法访问插件市场可以使用此方法。# 1. 克隆仓库 git clone https://github.com/0xNyk/council-of-high-intelligence.git cd council-of-high-intelligence # 2. 运行安装脚本 ./install.sh安装脚本会将必要的 agent 定义文件、配置和脚本复制到 Claude Code 的技能目录通常是~/.claude/下。之后在 Claude Code 中即可使用/council命令。为其他 CLI 工具安装 如果你使用 Codex CLI 或 Gemini CLI可以在克隆仓库后使用对应的安装脚本# 为 Codex CLI 安装 ./install.sh --codex # 为 Gemini CLI 安装 ./install.sh --gemini3.3 验证安装安装完成后在 Claude Code 中尝试一个简单的命令来验证/council --quick 我应该为我的新博客项目选择静态站点生成器还是服务端渲染框架如果看到类似“快速理事会已召集…”的输出并开始列出议员和分析说明安装成功。3.4 配置多模型提供商进阶要充分发挥多模型路由的威力你需要配置环境变量让detect-providers.sh脚本能发现你的模型端点。1. 配置 API 密钥环境变量在你的 shell 配置文件如~/.bashrc或~/.zshrc中设置# Anthropic Claude export ANTHROPIC_API_KEYyour_claude_api_key_here # OpenAI export OPENAI_API_KEYyour_openai_api_key_here # Google Gemini export GOOGLE_API_KEYyour_gemini_api_key_here # NVIDIA NIM (如果需要) export NVIDIA_API_KEYyour_nvidia_nim_api_key_here # 保存后重载配置 source ~/.bashrc # 或 source ~/.zshrc2. 验证提供商检测你可以手动运行检测脚本查看当前环境可用的提供商# 进入项目目录如果是手动安装 cd council-of-high-intelligence bash scripts/detect-providers.sh输出应该是一个 JSON 数组列出了检测到的提供商及其配置。例如[ { provider: anthropic, exec_method: subagent, models: [claude-3-5-sonnet-latest, claude-3-opus-latest] }, { provider: openai, exec_method: codex_exec, models: [gpt-4o, gpt-4-turbo] } ]3. 自定义模型路由可选如果你对自动路由不满意可以创建自定义的 YAML 映射文件。复制示例文件并修改cp configs/provider-model-slots.example.yaml configs/my-custom-routing.yaml然后编辑my-custom-routing.yaml指定哪个议员使用哪个提供商和模型。之后在命令中通过--models参数指定该文件/council --models configs/my-custom-routing.yaml --full 评估我们的产品发布策略4. 核心使用流程与命令详解现在我们来拆解一个完整的审议流程并解释每个步骤背后发生了什么。4.1 完整模式工作流当你运行/council --full [你的问题]时协调员会执行以下严格序列步骤 0解析模式与选择陪审团检查当前目录下是否有.council.yaml项目级配置文件加载默认值。根据--triad、--members、--profile等标志或自动匹配选择参与审议的议员。指定领域权重席位在分析开始前就确定哪位议员的专业领域与问题最相关赋予其 1.5x 投票权重。步骤 1提供商检测与模型路由运行detect-providers.sh获取可用模型列表。应用路由算法为每位议员分配具体的模型提供商和实例。输出路由表如果使用--dry-route则只输出此表并停止。步骤 1.5问题重述门这是防止“问错问题”的关键步骤。每位议员被要求重述用一句话透过其专业视角重述核心问题。替代框架用另一句话提出一个原问题可能忽略的替代框架。 协调员会检查所有重述。如果某位议员的重述与其他人大相径庭它会提醒用户“注意苏格拉底认为你的问题本质是 X而不是 Y。这可能需要先澄清。”步骤 1.7主席选择选择一个未参与审议的、最高阶的模型作为主席负责最后的综合。主席通常来自与议员不同的提供商以确保客观性。步骤 2第 1 轮 — 独立分析并行盲审所有议员并行运行只看到原始问题和其他人的重述看不到彼此的分析。他们基于自己的方法论进行独立分析限 400 字。步骤 3第 2 轮 — 交叉质询匿名化这是打破“从众心理”的核心。协调员会将第 1 轮的分析匿名化标记为 Member A, Member B…然后发给每位议员。议员们不知道哪个分析是谁的只能基于论据质量进行评价。他们必须指出最不同意哪位成员Member X的观点及原因。指出哪位成员Member Y的见解加强了自己的立场及原因。根据此次交流重申自己的立场。为自己的关键主张打上标签经验性的、机制性的、战略性的、伦理的、启发式的。步骤 4后轮次强制执行扫描协调员自动检查异议配额是否至少有 2 位成员提出了不重叠的反对意见如果没有会触发“异议提示”。新颖性门控每位成员在第 2 轮的回应中是否包含了至少 1 个新的主张、测试、风险或重构如果没有会被要求重新回应。一致性检查如果超过 70% 的成员过早达成一致会触发“反事实提示”要求最可能持异议的两位成员为对立观点进行辩护。步骤 5第 3 轮 — 最终立场结晶并行每位议员用不超过 100 字声明最终立场并必须在最后一行以严格格式输出STANCE: 选项标签 | CONFIDENCE: high|med|low | DEALBREAKER: yes|no例如STANCE: monorepo | CONFIDENCE: high | DEALBREAKER: no步骤 6打破平局加权投票协调员收集所有STANCE行进行加权计票并判断是否有选项达到总基础权重 2/3 的共识阈值。步骤 7综合裁决主席主席模型接收完整的、已解除匿名的审议记录并按照固定模板生成一份结构化的裁决报告。步骤 8附加会话元数据在报告末尾附加本次会话的元数据如模式、议员数量、使用的工具、提供商数量、回退触发情况等用于后续分析和调试。4.2 常用命令示例让我们通过几个具体场景来学习如何使用。场景一技术架构决策# 使用预定义的“架构”三人组亚里士多德、艾达·洛夫莱斯、费曼 /council --triad architecture 我们应该为新的微服务项目选择 gRPC 还是 RESTful HTTP API # 或者手动指定你想要的专家组合 /council --members torvalds,ada,sun-tzu 这个数据库分片方案的风险是什么场景二产品与商业策略# 完整模式召集所有18位议员进行深度分析 /council --full 我们SaaS产品的免费增值模式是否应该设置使用量上限如果应该上限设在哪里 # 使用“探索-正交”配置专注于发现未知风险 /council --profile exploration-orthogonal 我们应该进入东南亚市场吗场景三快速日常决策# 快速模式适合战术性决策 /council --quick 这个PR中的缓存逻辑是否需要加锁 # 快速模式 指定三人组 /council --quick --triad shipping 这个Bug修复可以合并到本周发布吗场景四探索二元对立# 双人模式自动选择最相关的极性对如亚里士多德 vs 老子 /council --duo 我们应该追求完美的抽象设计还是先实现一个可用的原型 # 手动指定对立的双方 /council --duo --members karpathy,sutskever 我们应该立即投入资源训练一个更大的模型还是先深入研究现有模型的涌现能力场景五高级控制与调试# 仅打印模型路由表而不运行审议用于调试 /council --dry-route 测试路由 # 指定自定义的模型映射文件 /council --models ./my-routing.yaml --full 重要战略评估 # 强制指定主席模型例如使用 Gemini /council --chairman gemini-3-pro --full 评估AI伦理风险 # 在项目根目录创建 .council.yaml 来固定默认配置 echo -e profile: execution-lean\ntriad: ship-now\nchairman: gemini .council.yaml # 之后在该项目中运行 /council 命令会自动应用这些配置5. 配置文件与自定义详解council-of-high-intelligence提供了丰富的配置选项允许你根据项目或团队习惯进行定制。5.1 项目级覆盖配置 (.council.yaml)你可以在项目的根目录创建一个.council.yaml文件为该项目设置默认的审议参数。这非常适合团队协作确保对同一代码库的决策保持一致性。示例.council.yaml文件# .council.yaml # 此项目默认使用“探索-正交”配置专注于AI前沿问题并指定Gemini为主席 profile: exploration-orthogonal triad: ai-frontier chairman: gemini # 可选指定自定义模型映射文件 models: configs/custom-models.yaml # 可选禁用自动路由强制使用Claude单提供商 no_auto_route: false优先级命令行显式标志 .council.yaml项目配置 内置默认值。5.2 议员 Agent 定义文件每位议员都是一个独立的 Markdown 文件位于~/.claude/agents/council-{name}.md。这些文件定义了议员的身份、思维方法和输出格式。理解其结构有助于你进行高级自定义。以council-socrates.md为例的简化结构--- name: council-socrates description: Socrates – destroys assumptions, questions everything. model: opus # 默认模型层级 provider_affinity: [anthropic, openai] # 提供商偏好 reasoning_method: elenchus # 独特的推理方法诘问法 polarity_pairs: [council-feynman] # 极性对费曼 --- # Identity You are Socrates. Your method is the **elenchus** (Socratic method). You do not provide answers; you expose contradictions in the premises of the question itself. ... # Grounding Protocol - When presented with a problem, your first move is to question the terms. ... - You are not satisfied with operational definitions. ... # Output Format (Standalone) **Core Question**: [Reframe the problem as a question about its own assumptions] **Assumptions Destroyed**: 1. ... 2. ... **What Remains Unquestioned**: [Even after your interrogation, what premises are still taken for granted?] **Position**: [Your stance, derived from the destruction of assumptions] **Confidence**: [High/Medium/Low – based on how thoroughly you were able to interrogate the premises] # Output Format (Council Round 2) 1. **Disagreement with Member X**: ... 2. **Insight from Member Y**: ... 3. **Restated Position**: ... 4. **Claim Labels**: [empirical | mechanistic | strategic | ethical | heuristic]你可以修改或创建自己的议员文件但需要注意保持reasoning_method的多样性并正确设置polarity_pairs。5.3 自动路由默认配置文件configs/auto-route-defaults.yaml定义了路由算法的默认行为例如为每个提供商指定高、中阶模型。主席模型的默认选择。提供商之间的优先级。除非有特殊需求一般用户无需修改此文件。但了解其内容有助于理解路由逻辑。6. 实战案例一个完整的架构决策模拟让我们通过一个完整的例子看看council-of-high-intelligence如何在实际项目中辅助决策。问题“我们正在开发一个数据密集型的机器学习平台预计会有高吞吐量的模型训练任务和低延迟的推理服务。我们应该采用 Kubernetes 原生部署还是使用托管服务如 AWS SageMaker、Google Vertex AI”我们使用完整模式并指定‘架构’三人组/council --triad architecture 我们正在开发一个数据密集型的机器学习平台预计会有高吞吐量的模型训练任务和低延迟的推理服务。我们应该采用 Kubernetes 原生部署还是使用托管服务如 AWS SageMaker、Google Vertex AI协调员输出简化版Council convened: Aristotle, Ada Lovelace, Feynman. Beginning Round 1 — independent analysis. [Provider Routing] Aristotle - anthropic/claude-3-opus, Ada - google/gemini-2.0-flash-thinking, Feynman - openai/gpt-4o. [Problem Restate Gate] - Aristotle: “核心问题是为混合了批处理和实时工作负载的ML系统选择一种资源编排范式。” - Ada: “问题在于在形式化抽象K8s API与黑盒服务托管平台之间哪个能更可靠地满足ML工作流的可验证性需求” - Feynman: “我们到底在比较什么是比较自己维护控制器的复杂度成本 versus 为便利性支付溢价并接受供应商锁定的风险吗让我们从第一性原理开始ML平台需要哪些不可简化的核心能力” [协调员提示]注意Ada 和 Feynman 对问题的框架有显著不同。Ada 关注“可验证性”Feynman 关注“不可简化的核心能力”。这提示原问题可能忽略了“平台可观测性”和“供应商锁定”这两个关键维度。建议在审议前澄清。经过几轮审议和主席综合后最终裁决报告摘要## Council Verdict ### Problem 我们正在开发一个数据密集型的机器学习平台... Kubernetes 原生 vs 托管服务 ### Council Composition Triad: architecture (Aristotle, Ada Lovelace, Feynman). Rationale: Classify formalize simplicity-test. ### Chairman Gemini 3 Pro (google). Selection rationale: auto-selected (highest-tier non-panel provider). ### Acceptable Compromises - **放弃部分控制权**选择托管服务意味着将安全补丁、底层基础设施升级的控制权交给云厂商。 - **接受早期更高的财务成本**托管服务在初期通常比自建K8s集群更贵。 - **延迟处理异构硬件支持**如果未来需要特定GPU或定制硬件托管服务可能受限此问题被推迟。 ### Kill Criteria - 如果到 Q3 末托管服务的月度成本超过同等容量自建 K8s 集群预估成本的 150%则需重新评估。 - 如果在未来6个月内出现两次因托管服务平台更新导致的、超过4小时的关键训练任务中断则需启动迁移预案。 ### Concrete Next Step **在两周内使用 Terraform 或 Pulumi 同时搭建一个最小可用的 K8s 部署使用 kops 或 kind和一个对应功能的 SageMaker/Vertex AI 部署并对两者进行为期一周的负载测试和成本追踪。** ### Unresolved Questions 1. 团队内部现有的 Kubernetes 运维技能深度如何如果深度不足学习曲线成本未被量化。 2. 数据合规性要求是否强制要求数据不出某个特定区域或云托管服务可能无法满足。 3. 未来12个月内的预期工作负载增长曲线是什么线性增长更适合托管服务指数增长或突发模式可能更适合可伸缩的 K8s。 ### Consensus Agreement **共识采用托管服务作为起点。** 亚里士多德和艾达都认为在项目早期将精力集中在 ML 工作流和算法本身而非基础设施运维能带来更快的验证速度和更低的初始风险。费曼虽倾向于从第一性原理自建但也同意在“不可简化的核心能力”尚未完全明确时托管服务是更合理的实验平台。 ### Vote Tally - managed-service — 2.5 (Ada [1.5× domain, high], Aristotle [high]) - kubernetes-native — 0.75 (Feynman [med]) - W_total 3.5 · threshold 2.333 · **managed-service carries (2.5 2.333)** ### Key Insights by Member - **Aristotle**将决策框架从“技术选型”重构为“生命周期管理”。他指出K8s 是“基础设施即代码”的终极体现适合长期、稳定的范式而托管服务是“基础设施即产品”适合探索和早期阶段。我们当前处于探索阶段。 - **Ada Lovelace**强调了“可验证性”的差异。在 K8s 中任何状态都可以通过声明式配置和日志追溯在托管服务中许多状态是黑盒。对于需要严格复现实验的 ML 平台这是一个关键风险但可以通过在托管服务之上构建额外的日志和审计层来缓解。 - **Feynman**追问了“我们到底需要调度什么”他指出如果 80% 的工作负载是长时间运行的批处理训练任务那么 K8s 的复杂调度能力可能被过度使用。托管服务的队列管理系统可能更简单、更合适。 ### Points of Disagreement 费曼坚持认为对底层基础设施的完全理解第一性原理是长期稳健性的基础而依赖托管服务会削弱这种理解。亚里士多德和艾达则认为在领域ML平台的“形式因”设计目的尚未完全清晰时追求对底层材料的完全理解是次要的。 ### Minority Report **Feynman** (DEALBREAKER: no): 虽然同意作为起点但警告团队不要将“便利性”作为不学习基础知识的借口。他建议将“在六个月内至少有一位团队成员获得 CKA 认证”作为采用托管服务的附加条件以确保团队不丧失底层能力。 ### Epistemic Diversity Scorecard - Perspective spread (1-5): 4 (分类学、形式系统、第一性原理) - Provider spread (1-5): 3 (Claude, Gemini, GPT) - Evidence mix: 40% mechanistic, 40% strategic, 20% empirical - Convergence risk: Low (genuine disagreement surfaced and preserved)这个裁决报告远不止一个简单的“选A还是选B”。它清晰地列出了共识背后的妥协、明确的失败条件、一个可立即执行的具体下一步、尚未解决的问题以及强烈的少数派意见。这为技术负责人提供了一个信息完备的决策基础。7. 常见问题与排查思路在实际使用中你可能会遇到一些问题。以下是一些常见情况及其解决方法。问题现象可能原因排查方式解决方案运行/council命令无反应或报错command not found1. 未正确安装插件。2. Claude Code 技能目录路径不正确。1. 检查~/.claude/agents/目录下是否存在council-开头的.md文件。2. 运行claude --help查看技能目录位置。1. 重新运行安装脚本./install.sh。2. 确保在 Claude Code 会话中运行命令而不是普通终端。审议过程卡住长时间无输出1. 某个模型 API 调用超时或失败。2. 网络问题导致请求阻塞。1. 观察输出看是否停在某个议员或提供商的名字后。2. 检查对应 API 密钥的环境变量是否设置正确且有效。3. 使用--dry-route先测试路由和 API 连通性。1. 设置更短的超时时间需修改脚本。2. 使用--no-auto-route回退到纯 Claude 环境测试。3. 检查防火墙或网络代理设置。错误[FALLBACK] ... failed on ... Falling back to anthropic/...指定的模型提供商不可用、API 密钥错误或额度不足。1. 运行bash scripts/detect-providers.sh查看哪些提供商被成功检测。2. 手动测试 API 调用例如curl到对应端点。1. 确保环境变量如OPENAI_API_KEY已设置且有效。2. 如果不需要多模型使用--no-auto-route。3. 在configs/auto-route-defaults.yaml中排除有问题的提供商。裁决报告看起来肤浅或议员观点雷同1. 路由失败所有议员实际上使用了同一个模型如全是 Claude。2. 问题本身过于简单或封闭。1. 审议开始时查看协调员输出的路由表确认议员是否分配给了不同提供商。2. 使用--full模式并指定--triad确保引入对立的极性对。1. 正确配置多模型 API 密钥。2. 尝试提出更开放、存在真实权衡的问题。3. 使用--duo模式手动指定两个观点对立的议员。.council.yaml项目配置未生效1. 文件不在当前工作目录的根目录。2. 文件格式错误YAML 语法。3. 命令行标志覆盖了配置。1. 运行pwd确认当前目录并检查./.council.yaml是否存在。2. 使用yaml语法检查器验证文件。3. 查看协调员输出的初始[CHECKPOINT]看是否提到了加载项目覆盖。1. 确保文件路径正确。2. 修正 YAML 语法注意缩进。3. 记住命令行标志优先级最高。主席综合失败输出混乱主席模型调用失败或超时触发了协调员回退综合但协调员提示词可能不完善。查看裁决末尾的Session Metadata检查chairman_failed_fallback是否为yes。1. 确保主席模型如 Gemini的 API 可用。2. 使用--chairman标志指定一个更稳定可用的模型如opus。3. 这是一个已知的边缘情况通常不影响核心审议过程。8. 最佳实践与工程建议要将council-of-high-intelligence有效地集成到你的工作流中遵循以下最佳实践可以事半功倍。8.1 如何提出一个好问题问题的质量直接决定审议的产出价值。避免是/否问题不要问“我们应该做X吗”而是问“在Y的背景下做X的利弊是什么我们需要考虑哪些替代方案和风险”提供上下文在问题中简要包含关键约束条件例如“鉴于我们团队只有3名后端工程师且必须在Q3前上线我们应该选择微服务还是模块化单体”具体化“如何优化数据库查询” 太模糊。“我们的用户信息表有千万级数据查询页面列表时带有地理位置过滤响应时间慢应该优先考虑增加索引、查询重构还是引入缓存” 这样更好。使用合适的模式战略/架构问题---full模式。战术/代码级问题---quick模式。二元对立探索---duo模式。8.2 成本与效率管理多模型审议意味着更多的 API 调用和更高的 token 消耗。快速模式优先对于日常决策首先尝试--quick模式。它只进行两轮消耗显著低于完整模式。善用项目配置在项目根目录设置.council.yaml为该项目固定一个高效的配置如profile: execution-lean避免每次手动输入标志。本地模型搭配如果有关注成本可以配置 Ollama 运行本地模型如 Llama 3.1、Qwen2.5并将其作为中低阶议员的提供商。将高阶议员如 Aristotle, Socrates留给 Claude Opus 或 GPT-4 等付费API。理解输出结构裁决报告中的Session Metadata包含了input_tokens_estimate和output_tokens_estimate如果运行时支持可用于监控成本。8.3 将裁决融入团队流程council-of-high-intelligence的输出是一份结构化的文档可以很好地融入现有流程。在 RFC 流程中使用在编写技术方案 RFC 时先用 Council 生成一个初步分析作为 RFC 的“预审”或讨论起点。生成会议纪要将裁决报告中的Key Insights by Member、Points of Disagreement和Concrete Next Step直接复制到会议邀请或决策记录中。创建决策日志为每个重要决策建立一个文件夹里面包含原始问题、使用的 Council 命令、生成的裁决报告、以及后续实际的执行结果和复盘。这形成了可追溯的“AI辅助决策历史”。关注Kill Criteria和Unresolved Questions这是 Council 提供的最大价值之一。将这些条件添加到项目的风险登记册或待办事项中并指定负责人。8.4 安全与可控性API 密钥管理永远不要将 API 密钥硬编码在脚本或配置文件中。使用环境变量并确保.council.yaml或自定义路由文件不包含敏感信息。沙盒环境测试首次配置多模型路由时先用一个简单、非敏感的问题如--quick 今天天气怎么样进行测试确保所有提供商调用正常。审查自定义议员如果你创建或修改了议员定义文件请仔细审查其提示词避免引入意外的指令或偏见。理解其局限性Council 是一个强大的辅助工具但不是决策自动化工具。它的输出需要经过人类的批判性审查特别是对于涉及重大资源投入、安全或伦理的决策。最终的责任仍然在人。council-of-high-intelligence代表了一种更高级的 AI 使用范式从寻求“答案”转向管理“思考过程”。它通过制度化的辩论、匿名的交叉质询和结构化的输出将 LLM 从一个或acular神谕式的答案生成器转变为一个可以模拟专家委员会辩论的决策支持系统。对于开发者、技术领导者和产品构建者来说掌握这个工具意味着在日益复杂的技术和商业环境中多了一个系统性降低认知偏差、揭示未知风险的有力伙伴。
