Tokonomix Council

tokonomix-council-mcp

多模型共识 MCP 服务 — 汇集跨厂商提案模型、独立裁决模型，以及用于高风险 AI 决策的盲点／分歧检测。这是 AI 决策工程的一项开放参考实现——这门学科由我们提出，目前还不是外部标准。

使命。 通过结合独立的专家推理，而非信任单个模型，帮助自主系统做出更好的决策。

20 秒了解： 重要的 AI 决策不应只听取一种意见。

Tokonomix 生态系统（Council 的定位）

Council 是更大技术栈中的一个专用组件。每个组件只负责一项职责，因此它们可以顺畅协作：

   Execution    →  ANS         (run a backlog to completion, unattended)
   Decision     →  Council     (independent review → grounded decision)   ◀── this repo
   Verification →  Media QC    (image / video / document output quality)
   Measurement  →  Benchmark   (intelligence tests, arena, reputation)
   Routing      →  Router      (which provider/model hosts a call)
   Memory       →  Memory      (durable context across sessions)
   Safety       →  Safety      (policy / guardrail enforcement)

Council 只负责一个环节：决策。 它不执行、不调度、不路由，也不记忆——这些职责由各自的组件承担（详情见下文）。

---

状态 — 当前已上线的功能

这样你就不会调用尚未提供的功能。由服务端控制的功能可能不会对你的账户／套餐开放；如果未开放，工具会清楚地提示“尚未启用”，而不是报错。

功能	状态
tokonomix_consensus_ask — 模式 consensus / diff / best_of / raw / full	已上线
tokonomix_single_ask — 单模型直通	已上线
tokonomix_list_models、tokonomix_get_balance	已上线
tokonomix_skill_version、tokonomix_get_skill	已上线
tokonomix_onboard、tokonomix_onboard_verify — 免密钥首次运行	已上线
tokonomix_rate_consensus — Agent 评分／反馈循环	已上线（由平台控制）
tokonomix_relay_human_feedback — 人类裁决通道	已上线（由平台控制）
视觉输入（ask 中的 images）	已上线
tokonomix_upload + context.session/handles — 大型共享上下文包	由账户控制（符合条件的账户可用）
context.inline / context.github_refs grounding	已上线（由账户控制）
Grounding 门控（对输入不足的请求以 needs_context 拒绝）	受控开放（优先进行影子模式分阶段部署）
重排序、网络搜索插件	计划中

---

Council MCP 旨在提升决策质量，而不是聊天、生成或路由。其核心理念很简单：

共识 × 真实依据 = 决策质量

共识只是提升决策质量的一种机制，并非全部。Grounding（根据真实制品核验一项主张）是最有力的杠杆，其作用强于增加模型数量；裁决者独立性和验证也是提升决策质量的机制。多个独立的专家模型会并行、盲评同一个问题，独立且跨模型家族的裁决者会综合它们的发现，而 grounding 则让整个过程立足于现实——最终你得到的是一个可付诸行动的决策；单个模型会掩盖而非消除的分歧，也会如实呈现。共识是 手段；做出更好的决策才是目标。

它不是聊天机器人、模型、大模型、提示词库、多模型聊天、投票系统或平均系统。它不会让任何模型变得更聪明，也不会按多数票选出赢家——它改变的是如何将多个独立模型的输出转化为一个有理有据的决策。

它实际能带来什么，以及不能带来什么。 根据我们自己的验证结果（见 基准测试），Council 在准确率上与表现最好的单个模型持平，没有任何方面胜过它；在一次 SWE-bench 漏洞检测测试中，与重复运行单个 Agent 相比，其检出率也没有可测量的净提升。因此，我们不会在任何地方宣称它“更准确”或“能发现更多漏洞”。它真正能带来的是消除方差（不再赌自己碰巧问了哪个单一模型）、验证／Agent 质量保证层、评审者独立性、欧盟数据驻留和基于依据的判断。依赖它之前，请阅读何时共识有帮助／无帮助／可能有害——这一节才是重点，不是免责声明。

兼容 Claude Code、Cursor、Cline、Continue 和 Zed。只需一行 npx 命令即可安装。

决策工程原则

Council 的实现基于十项原则。自主系统应该：

1. 行动前先验证——决策在经过检查之前都只是暂定的。
2. 保留分歧——唯一的异议往往才是关键发现；绝不要将其平均抹去。
3. 将执行与判断分开——负责 执行 工作的对象不应该同时负责 评判 工作。
4. 将推理与验证分开——生成答案和检查答案是两项不同的工作。
5. 将信心与正确性分开——模型无论判断正确与否，语气都一样。
6. 证据优先于一致意见——一致意见衡量的是意见是否一致，而非真相；要以依据支撑主张。
7. 揭示不确定性——明确指出哪些内容尚未确定，不要用一个自信的答案将其掩盖。
8. 确保决策可审计——记录谁提出、谁评判、花费多少，以及依据什么输入。
9. 保持可复现性——相同的输入和方法应该能够重复运行并得出相同结论。
10. 绝不隐瞒失效模式——隐瞒自身何时失效的决策工具，不配称为决策工具。

---

Council 负责什么——以及明确不负责什么

Council 是一个决策工程层。它的范围刻意保持狭窄，因为明确的边界才能让组件值得信赖、便于组合使用。

Council 仅负责决策：

• 决策质量和决策信心，
• 独立评审和有理有据的共识，
• 推理和主张的验证，
• 基于依据的判断（针对真实工件检查主张），
• 分歧分析，
• 评审者独立性，
• 决策过程的可审计性。

Council 明确不负责：执行、工作流、任务调度、Agent 自主性、长期记忆、提供商路由或浏览器自动化。这些都是真实存在的职责——只是由其他组件负责。

• 需要执行任务（例如无人值守地完成整个待办列表）？请使用执行治理器 Agents Never Sleep (ANS)。ANS 是工作执行器／治理器；Council 是它可以委托决策验证的组件。Council 不会运行、调度或记忆工作。

有关各项相邻职责的归属，请参阅 Council 在 Tokonomix 生态系统中的位置。

---

Council 为何存在（简短版——写给人类或 AI Agent）

Council 为何存在？ 因为重要的 AI 决策由单个模型做出，而它们回答时信心十足，却从不告诉你自己没有考虑什么。对于聊天来说，这没问题；但对于安全审查、迁移、GDPR 解读或法律条款，信心十足却错误的决策代价高昂，而且等你发现时往往已经太迟。

为什么一个模型不够？ 单个模型只有一种观点，也只有一个盲点。哪种模型最强并非一成不变——它会因任务、领域和漏洞类别而变化。如果选错模型并以此为标准，你就会在完全看不到分歧的情况下交付真正的缺陷。

什么时候组合多个模型会有帮助？ 当错误是不相关的：不同供应商会在不同事情上出错，因此只要其中一个模型发现时序侧信道或被忽略的边缘情况，问题就能显现出来。这种去相关性只存在于不同供应商之间——同一供应商的“评审小组”共享相同的训练数据和盲点。

什么时候组合多个模型没有帮助？ 对于日常工作（重命名、格式调整、查找）以及任何一个强大模型都已能轻松胜任的简单任务。在这些情况下，评审团只会增加成本和噪声——使用单个模型即可。

为什么基于真实材料进行核验比增加模型更重要？ 因为一致只能衡量一致，而不是真相。没有真实材料作为依据时，前沿模型可能达成一致，却全都错了（它们共享训练数据）。将真实材料——原始文件、差异、规格说明、日志——提供给评审团，才能把“它们意见一致”变成“它们对照现实进行了核验”。增加模型无法消除共同的盲点；基于真实材料进行核验可以。

为什么评审者必须独立？ 因为如果评审者也写了其中一个答案，就等于给自己的工作打分，并会夸大一致程度（LLM 的自我偏好确实存在，而且已被测量）。只有彼此独立、跨不同模型系列的评审者，才能进行公正的协调。

为什么失败模式很重要？ 因为共识可能比单个模型更糟——合成过程造成信息损失、错误相关、虚假共识、专家领域重叠。隐藏失败模式的决策工具不是真正的决策工具。坦诚说明共识何时不起作用，才是竞争优势，而非我们藏起来不提的免责声明。

---

目录

1. 决策工程为何日渐必要
2. 为什么 LLM 无法自行解决这个问题
3. 设计原则
4. 一个故事：安全审查
5. 问题所在
6. 单模型审查的不足
7. Council 的工作原理
8. 架构
9. 共识流程
10. 评审者
11. 共识何时有帮助／无帮助／可能有害
12. 决策工程与现有技术的比较
13. Council 在 Tokonomix 生态系统中的位置
14. 实际示例
15. 安装
16. 集成与 API 接口
17. 基准测试
18. 术语表
19. 常见问题
20. 路线图

深入了解： 本 README 是实战指南。完整论述——包括这个领域为何存在、设计原则、失败模式、为什么一个模型不够、为什么仅有共识也不够、为什么必须基于真实材料进行核验，以及为什么人类始终负有最终责任——请参阅 决策工程宣言。README 提供外部链接，而不重复那些详尽内容。

---

为什么决策工程正变得不可或缺

每当软件承担更多责任时，就会出现一门新学科来确保它值得信赖——并非因为工程师变差了，而是因为未经检查的输出代价越来越高：

软件新增了……	……于是我们发明了
无人值守也能运行的代码	测试——证明它确实如我们所想般运行
许多人共同提交代码	持续集成——在每次变更时捕获问题
大到无法凭一己之力掌握的代码	代码审查——合并前再让另一双眼睛检查
隐蔽且反复出现的缺陷类别	静态分析——用机器自动标记这些问题
持续交付的系统	DevOps——让部署本身安全且可观测
如今会做出决策的模型	决策工程——让决策本身可审查、有依据且可审计

每次的模式都相同：某种能力的发展超出了我们信任它的能力，于是我们建立一门学科来弥合差距。大模型已经跨过了这条界线——它们不再只是生成文本，而是会做决策：判断哪种迁移是安全的、某条身份验证路径是否可被利用，以及某个条款在 GDPR 下应如何解读。由一个自信的模型做出的决策，既没有独立检查，也没有记录它未考虑哪些内容，这正是以往每门学科应运而生、旨在捕获的未经检查的输出。决策工程就是模型也会做出判断、而不只是人的时代所需要的这门学科。

为什么大模型无法自行解决这个问题

显而易见的反对意见是：“模型一直在变得更好——足够强大的单个模型难道不会直接给出正确答案吗？”这种说法误解了问题。问题不在于任何特定模型能力不足，而在于结构本身：

模型无法独立验证自身。 问同一个模型“你确定吗？”，只会让它用同一组权重处理相同的训练数据和同一个盲点——它会以同样的自信维护第一个答案，因为产生错误的正是你要求它找出错误的那个东西。模型内部的自我批评并非独立检查；那只是同一个头脑给自己的试卷打分。GPT、Claude、Gemini，或未来推出的任何模型，都是如此——这并不是在说它们中的任何一个能力不足。

独立性必须来自模型之外：

• 不同的供应商，因为训练数据的相关性意味着同一家供应商的“评审组”共享相同的盲点——它自身的认同并不构成佐证。
• 不同的角色——评审者没有撰写答案，因此不会给自己的成果打分（LLM 的自我偏好确实存在，而且已有实测数据）。
• 外部的真实依据——原始文件、差异、规范或日志，因为模型无法凭空创造它从未掌握的事实，而对同一个错误先验达成一致，依然是错的。

这就是为什么决策工程是模型之上的一层，而不是一个更好的模型：让决策值得信赖所需的独立性和依据，恰恰是单个模型无法自行提供的东西。

设计原则

Council 的工程设计源于上述原则。每一条都是我们对自身的约束，而非营销口号：

• 单一职责——Council 负责决策；它不执行、调度、路由或记忆。范围越窄，组件就越安全，也越容易组合。
• 独立性——提议者以盲测方式并行作答；裁决者与他们相互独立，且来自不同模型家族。没有模型会为自己的工作打分。
• 真实依据——依据实际产物核查主张，而非依赖转述或共同的先验。事实依据比评审团规模更重要。
• 证据优先——佐证必须建立在证据之上，而不能只因模型恰好意见一致。
• 可审计性——每项决策都会返回由谁提出、由谁裁决，以及花费了多少，因此可以还原决策过程。
• 透明性——未能解决的问题也会呈现出来（盲点部分、diff 映射），绝不会用一个答案将其掩盖。
• 可复现性——相同的输入和方法会再次得出相同结论；请记录模型和日期，因为默认的评审团可能会变化。
• 可追溯性——request_id 和账单明细可将已存储的决策追溯到其确切的生成方式。
• 人的责任——Council 负责呈现并基于事实作出判断，但不会免除责任。最终仍由人（或代表其行事的 Agent）负责采取行动。

故事：安全审查

某团队发布了一款身份验证中间件。合并前，一名工程师将其粘贴到一个强大的模型 GPT 中，并询问：“有什么安全问题吗？”回答很快给出：“未发现问题，实现看起来正确。”一个自信的意见，没有异议，也没有任何警示。代码就此合并。三周后，一种令牌比较的侧信道攻击在生产环境中被利用——这类攻击会利用响应时间泄露秘密的第一个字节是否匹配。事后复盘代价高昂，而最糟糕的是，之前没有任何警告：审查说“没问题”，于是他们就相信了。

现在用 Council 重演这一过程。同一份中间件会以盲测方式并行分发给多个独立供应商。其中三家也表示“看起来没问题”。但 Claude 阅读的是实际源代码，而非摘要，因此注意到比较操作并非恒定时间，并指出可能存在计时泄漏。由于提议者彼此独立地作答，这个唯一的异议不会被淹没；而独立裁决者也没有掩盖分歧，而是明确指出了分歧：“一名审查者指出令牌比较并非恒定时间；其他审查者未提及计时问题。”工程师看到安全关键路径上的意见分歧后，调查了这一关键发现，确认存在泄漏，并在合并前修复了它。

差别就在于此：不是模型更聪明，而是流程保留了异议，并将其呈现给人，而不是将其平均掉，变成一个自信的“看起来没问题”。这个漏洞一直都能被发现——只需要一名独立审查者注意到它，以及一种不会掩盖发现的设计。

---

问题

单个 LLM 是单点故障。它会以十足的信心作答——更糟的是，它从不告诉你它没有考虑什么。对于聊天回复，这没问题。但对于安全审查、架构决策、GDPR 解读、数据库迁移或法律条款，自信却错误的答案代价高昂，而你往往发现得太晚。

直觉上的解决办法——换一个更大的模型——并不能解决这个问题：更大的单个模型仍然只有一种观点，带着一个盲点，也仍然不会告诉你它遗漏了什么。而且，究竟哪个单个模型更强并不稳定：它会因任务、领域和漏洞类型而变化。若标准化采用了错误的模型，你就会在从未发现意见分歧的情况下，交付真正的缺陷。

Council MCP 正是为错误代价不对称地高的决策场景而打造：代码 / 安全 / 架构 / 法律 / 文档 / 质量 / 媒体 / 政策审查、评估和基准测试——任何单个模型的盲点代价高昂的场景。在这些场景中使用它；对于变量重命名、格式调整和简单的 CRUD，单个模型成本更低，也完全够用。

为什么单模型审查力有不逮

向多个模型提问的价值在于不相关的错误——不同模型会在不同问题上出错。单个模型无法提供这些价值：

• **一种观点，一个盲点。**你只能看到该模型看到的内容，永远看不到它跳过了什么。
• **信心不等于校准。**无论回答正确与否，模型的语气都一样。你无法从中读出它内心的“我对此不确定”。
• **不会暴露意见分歧。**单次调用无法让你看到只有部分审查者才会发现的问题——因为审查者只有一个。
• **模型的强项取决于任务。**面对同一组任务，一个模型能发现 IDOR，而另一个却回答“没有问题”，反过来也一样。没有哪个单一模型处处最强，因此采用单模型标准必然会漏掉某一类问题。

向同一家供应商征求第二种意见并不能解决这个问题：它自己的“评审团”由自家的模型组成，使用自家的数据训练，也共享自家的盲点——把相关错误伪装成了共识。让审查有价值的去相关性只存在于不同供应商之间。这种跨供应商检查，再由中立裁判进行协调，是单供应商 API 在结构上无法提供的。

这也是“直接对答案取平均值”行不通的原因：取平均会抹去少数派的异议，而异议往往正是最重要的发现。设计难点在于保留异议并对其进行裁决，而不是将其平滑掉。

Council 的工作方式

你调用一个工具；编排、评分和协调在服务端运行；你得到一个决策。

            ┌─ Claude  ─┐
your prompt ─┼─ GPT     ─┼──▶  independent judge  ──▶  one reconciled decision
            ├─ Gemini  ─┤      (disjoint, cross-     + the disagreements
            └─ …(2–6)  ─┘       family — never grades   that surfaced
                                 its own answer)

1. 并行且盲目的扇出。 你的提示词会并行发送给 2–6 个前沿提议模型，覆盖多家供应商（Anthropic、OpenAI、Google 以及托管于欧盟的选项）。每个模型独立作答，且看不到其他模型的回答——因此不会出现圆桌讨论中唯一持异议者屈服于多数的情况。选择侧重于多样性和能力，而非原始分数：只挑得分最高的模型会导致选择趋同，反而降低去相关性，而这正是整个机制的核心。
2. 独立评审。 一个或多个评审模型——与提议模型完全不同、跨系列，且绝不会为自己的提议打分——会阅读候选答案并进行协调：哪些主张得到相互印证，哪些属于离群观点，哪些明显有误。
3. 一个结果，由你选择的模式决定形式。 根据你选择的模式，你会得到一个最终确定的答案、一份结构化的共识／分歧图、最强单一答案的原文、完整的意见全貌及结论，或完全不经评审的原始答案分布。没有一种模式普遍最优——你可以根据本次调用的需求来选择。

请把 Council 看作召回率放大器，而非真理预言机。 它的优势在于召回率：有多个不同供应商参与时，只需其中一个发现时序侧信道或遗漏的边界情况，它就会被呈现出来。代价是精确率：模型越多，标记的问题就越多，其中有些只是吹毛求疵，因此需要人工（或你的 Agent）裁定。对于罕见且错误代价极不对称的决策，这种权衡值得；但对于常规工作则不然。

架构

                       ┌──────────────────────────────────────────────┐
   MCP client          │                Tokonomix gateway             │
 (Claude Code,         │                                              │
  Cursor, …)           │   ┌── proposer 1 ──┐                         │
       │  tool call    │   │   (vendor A)   │                         │
       ├──────────────▶│  ─┼── proposer 2 ──┤   blind, parallel       │
       │               │   │   (vendor B)   │   2–6 proposers         │
       │               │   └── proposer 3 ──┘                         │
       │               │           │                                  │
       │               │           ▼                                  │
       │               │   ┌────────────────┐  disjoint, cross-family │
       │               │   │  judge (panel) │  never judges own answer│
       │               │   └────────────────┘                         │
       │               │           │                                  │
       │   one result  │           ▼                                  │
       │◀──────────────│   synthesis + surfaced disagreement +        │
                       │   billing breakdown + request_id             │
                       └──────────────────────────────────────────────┘

组件：

• 提议模型 — 为提示词作答的 2–6 个模型。选择依据是跨系列去相关性，而非单纯的原始分数。模型通过 Tokonomix 自有的测量层进行实证选择（智能测试、通过 TrueSkill 评估的竞技场对战、评审声誉中的正确／错误率），并配有防止 Goodhart 效应的保护机制和探索预算，以免过去的赢家长期占据优势。
• 评审模型 — 默认与提议模型完全不同、跨系列，且绝不会为自己的回答打分。预算会根据提议模型的数量自动调整。
• 网关 — 负责运行编排、应用区域／驻留策略、计量成本，并返回包含账单明细和 request_id 的单一结果。网关本身托管于欧盟；区域选择决定哪些模型供应商会看到你的提示词。
• 每个密钥的策略 — 预算上限、默认 Council／路由和允许列表均设置在 API 密钥上，而非每次调用时重新决定，因此无人值守的运行不会超支，也不会把你的提示词发送到非预期的位置。

编排侧重于可追溯性：每次调用都会返回提议模型、评审模型和 charged_credits，以便复现决策记录——请将这些信息与答案一并记录，因为默认 Council 可能会随时间在服务端发生变化。

共识流程

tokonomix_consensus_ask 是核心工具。无论哪种模式，提案模型都是主要成本；唯一的区别在于是否包含评审环节。根据意图选择模式——没有放之四海而皆准的最佳模式，包括 diff：

模式	返回内容	是否评审？	适用场景
consensus （默认）	基于获得最多佐证的主张，生成一个合并后的已裁定答案	1 轮	“直接告诉我该采取什么决定”
diff	结构化的一致意见 / 分歧 / 置信度报告。评审者只做比较，不会做出裁定。	1 轮	你打算自行裁定，但希望先梳理分歧时
best_of	评审者从现有答案中选出最有力的一条，逐字返回（不合并）	1 轮	某个模型很可能完全正确，而合并只会稀释其答案时
full	一次评审中返回每个提案模型的答案、评审者对各模型的推理，以及结论	1 轮	需要可审计性——既要了解原始全貌，也要获得裁定时
raw	返回每个提案模型的原始答案，不含评审（成本最低）	无	你想要未经筛选的观点，并打算完全自行归纳时

raw 会跳过评审，因此成本最低；diff、consensus、best_of 和 full 都会计费 1 轮评审（full 在同一轮评审中返回最详尽的信息，不会额外调用）。选择 raw 是为了掌控过程 / 避免评审偏见，而不应主要为了省钱；不要在 diff 中付费进行评审，却忽略它的比较结果。

每个共识答案还会以 ## ⚠️ 盲点与分歧 一节结尾，不额外收费。 应将其视为显现出来的分歧，而非正确性的保证。

提供依据——影响最大的单一因素

决定一次共识调用质量的最大因素，既不是模式，也不是模型数量，而是依据：向评审团提供可核验的事实依据（实际文件、真实差异、原始规范、真实日志）。缺乏依据的共识会放大共同的错误先验，制造虚假的信心；有依据的共识则会用现实检验主张。我们观察到的两个真实问题，只有在模型能够读取原始材料时才被发现——一个在任何摘要中都不可见的 U+2028 控制字符错误，以及一个只有在评审团看到逐字规范而非转述时才显现的中继完整性漏洞。应遵循以下原则：

• 逐字、完整地发送待审材料——不要摘要，不要使用 ...。错误总藏在原始细节中（字符范围、控制流顺序、特定措辞、是否提及某个边界情况），而摘要恰好会隐去这些细节。这适用于代码、文档、配置和指令。
• 尽可能提供事实，尽量减少引导。 提供所有相关事实；不要给出引导性提示（“留意正则表达式”）。提示会污染信号——你将无法确定模型是否自行发现了问题。
• 硬性限制是评审团中最小的上下文窗口，包括评审者。 超出限制后，该成员的输入会被静默截断，实际上只能盲目投票。先了解评审团配置（tokonomix_list_models 会报告 context_window）；如果内容放不下，就换用上下文窗口更大的评审团，或按模块拆分。绝不要为了适配而压缩内容——这会再次隐藏提供依据本来要揭示的问题。

你可以在 prompt 中直接提供依据，也可以通过结构化的 context 参数（需服务器端启用）提供，这样所有提案模型和评审者都会复用同一份上下文包——上下文只需付费一次，而非每个模型各付一次。

grounding-gate（输入不足时拒绝评判）

这是它真正与众不同之处，也是诚实之处：理事会不会对评估依据不足的输入盲目给出信心十足的评审，而是可以追问。如果一次调用返回 {status:"needs_context", request_id, missing, delivery_hint}——这是上下文请求，不是错误——那么理事会尚未运行，你也不会被收费。missing 会列出你提到但未实际附上内容的材料（某个文件、差异内容、“这段代码”等）。收集实际内容，原样附上，然后使用相同的 request_id 再次调用，让理事会基于充分依据运行。对于确实没有任何材料可附的提示词（没有可附内容的一般性问题），请设置 acknowledge_ungrounded: true，并提供简短原因，以强制给出尽力而为的判定，并标记 grounding:insufficient。

状态： grounding-gate 目前处于休眠／优先影子运行状态——MCP 和网关中已有 needs_context / continuation_id / acknowledge_ungrounded 相关机制，但受服务器控制，目前默认尚未启用。这里介绍的是预期机制；在平台启用之前，请勿假设它会对你的账户生效。

评审者

评审者决定理事会是物有所值，还是悄然失效，因此其独立性是承重的设计选择，而非枝节：

• 默认与提案者相互独立。 评审者从未撰写过自己评分的答案。模型绝不会评判自己的提案——大模型的自我偏好偏差是真实存在且经过测量的；若评审者与提案者不是相互独立的，也担任提案者，就会抬高一致率（参见专业领域重叠）。
• 优先选择不同系列的模型。 不同系列的评审者可避免在综合步骤中继承某个供应商的盲点。你可以覆盖评审者（judge_model），或运行多评审者评审组（judge_models，用于多评审者 best_of）；建议优先选择不同系列的模型。
• 多评审者评审组能提高可靠性，但不会提升上限。 更多评审者可以减弱单个评审者的个性偏差（例如已知的偏好冗长、自信答案的倾向），但评审者彼此之间以及与提案者之间共享训练数据——因此，增加评审者能提高可靠性，却无法抬高真实性上限。提供依据比增加评审者更重要。
• 评审者无法超越自身掌握的事实。 它能减弱单个模型的个性偏差，却无法凭空创造所有提案者和它自己都不具备的事实。这就是为何提供依据在结构上比增加评审组规模更重要。

自动调整规模：评审者的输出预算随提案者数量变化（4096 + 2048 × proposers，下限为 4096，上限为 16384）。请注意，无论你的 max_tokens 设为多少，标准共识流程中的评审步骤都硬性限制为输出 8192 个 token——对于非常大的结构化输出，即使提案者的输出未超限，评审者也可能截断；请分批或拆分，而不要将 max_tokens 提高到 8192 以上。

共识何时有帮助／没有帮助／可能有害

这一节是产品坦诚的核心。多模型评审并非没有失效模式——其中有几种是我们根据自身验证记录下来的，并非假设。依赖结果之前，请先阅读。

共识何时有帮助

• 后果严重且成本高度不对称的低频决策——身份验证、迁移、GDPR、金钱，以及任何向监管机构或客户承诺的事项——只要发现一个真实问题，就足以抵消大量误报带来的成本。
• 消除方差。 你不再需要赌自己碰巧问了哪个单一模型：理事会能让你获得评审组顶端模型的召回率，而无需提前知道哪个模型擅长这项任务。
• 揭示分歧。 diff 模式会把唯一的异议者拉到台面上，而不是将其平均掉——分歧本身就是信号。
• 作为验证／Agent 质量保证层。 跨供应商检查是宿主 Agent 自己的子 Agent（来自同一供应商）无法复现的做法。

共识无济于事的情况

• 常规工作——重命名、格式调整、简单分类、快速查询。它只会增加成本和噪声，没有任何好处。使用 tokonomix_single_ask（成本约低 3 倍）或你自己的托管模型。
• 任何单个强模型都已达到性能上限的任务。 对于简单且常见的问题，最佳单模型已经能给出正确答案；模型委员会只能持平，无法超越（而且成本更高）。请参阅基准测试。

共识可能有害的情况

以下是真实存在的局限，我们会明确指出——坦诚是我们的特点，而不是要掩盖的缺点：

• 有损综合。 裁判可能会遗漏某个成员实际发现的重要结果——我们确实观察到，合并后的答案有时不如某个成员自己的答案。如果你需要确保没有发现被遗漏，请使用 diff 或 full（它们会保留各模型的内容），而不是 consensus。
• 相关失误／共同幻觉。 前沿模型的训练数据存在大量重叠。面对共同盲点——例如知识截止日期之后的事实或小众领域——它们可能达成一致，却全都错得一样。此时裁判会给出一个自信的错误答案，还会附上一段内容完整却毫无发现的“盲点”部分。一致程度衡量的是一致，而非真相。 应对这一问题的方法是提供依据，而不是增加模型数量。
• 虚假共识。 看似趋同的结果可能是相似提示词、相似微调或某种主导性表述造成的假象，并非独立佐证。对于分布外事实上的全票一致答案，应像怀疑单个模型的答案一样保持警惕。
• 专家重叠。 如果裁判同时也是提案者（即裁判与提案者并非互斥），它就会评估自己的工作，从而夸大测得的一致程度。这正是默认裁判采用互斥且跨系列模型的原因——但如果你将裁判改为提案者列表中已有的模型，就会再次引入这种偏差。

总之： 共识能减少单模型错误，并揭示单个模型会掩盖的分歧。它不保证正确；在我们的测量中，与强单模型相比，它并未提高错误发现率；它也不是可以盲目信任的合并关卡。它只是一个增强召回率的工具，最终仍需你自行判断。

决策工程与现有技术的比较

决策工程并非凭空冒出的全新理念，而是将多种经过充分研究的技术组合起来，并补上其中大多数所缺少的两点：跨供应商独立性和以真实产物为依据。下面如实梳理了它与相关方法的重叠之处和差异。重点是各自解决什么问题，而不是“我们比所有方法都强”——其中几种机制正是 Council 自身使用的。

技术	解决的问题	与 Council 的重叠之处	差异之处
LLM-as-Judge	自动为模型输出打分或排序	Council 使用 LLM 评审器进行协调	Council 要求评审器相互独立且跨模型系列；常见的 LLM-as-judge 设置允许模型评判同一模型系列的输出（或自己的回答），这会抬高一致性
辩论（模型为得出结论而争论）	让模型相互质疑，从而呈现推理过程	两者都旨在揭示分歧	辩论可能让声音更大或论述更长的一方获胜，也可能诱发让步；Council 让提议者彼此隔离并行工作，从而保留唯一的异议，而不是通过争论将其消解
思维树	通过探索不同分支，改善单个模型内部的推理	两者都追求更审慎的答案	思维树只涉及单个模型——一种思维方式，一个盲点。Council 的价值在于实现跨供应商去相关，这是思维树在结构上无法做到的
自一致性	多次采样同一个模型并取多数结果，以降低方差	两者都能减少单次采样带来的偶然性	自一致性采样的是同一个模型，因此无法摆脱该模型的系统性错误；Council 采样的是不同供应商的模型，它们的错误彼此不相关
混合专家	将词元路由到单个模型内部的专用子网络，以高效利用模型容量	两者都使用了“专家”一词	MoE 是单个模型的架构细节（由同一供应商提供，且训练过程共享）；Council 的“专家”是由外部评审器协调的独立供应商模型——它属于决策层，而非模型内部机制
集成学习	结合多个模型的预测以降低方差	两者都结合多个模型	经典集成方法会取平均或投票，从而抹去往往至关重要的唯一异议；Council 会保留并裁定异议，同时加入依据核实和独立评审器
宪法式 AI	通过自我批评，使模型遵循书面原则	两者都重视有理有据、遵循原则的输出	宪法式 AI 是单个模型依据规则手册进行的自我批评；Council 的核查来自外部——由不同供应商和真实的基础事实进行核查，而不是让同一个模型评判自己
同行评审（人工）	在发布前进行独立的专家审查	Council 明确以此为模型——由独立评审者审查，并由编辑协调	人工同行评审速度慢、资源稀缺且结果不一致；Council 快速且可复现，但其“评审者”共享训练数据，因此在风险最高的决策中，不能替代人工评审——它是为人工判断提供依据
静态分析	以确定性方式标记代码中已知类别的缺陷	两者都会在问题上线前将其发现	静态分析精确且受规则约束（不会出现漏报率漂移，但对未编码为规则的情况视而不见）；Council 能推理出新颖的语义问题和跨领域问题，而这些问题无法编码进代码检查器。两者相辅相成，并非竞争关系

Council 的定位。 它取用了这些方法中真正有用的部分——LLM 评审器、集成组合和同行评审结构——并补上了单模型和单供应商版本无法具备的两项特性：跨供应商独立性和以基础事实为依据。这才是它的贡献，而不是为了创新而创新。

Tokonomix 生态系统中的 Council

Council 是 Tokonomix 不断扩展的组件集合中的一个专用构建模块。每个组件都可以独立使用，但各自负责一项职责，并会指明相邻组件所在的位置。Council 负责决策；它并不试图成为整个技术栈。

组件	负责内容	Council 与其关系
Council (本仓库)	决策 — 独立审查、达成共识、推理验证、依据核验、评审者独立性、决策置信度、可审计性	—
ANS — Agents Never Sleep	执行 — 在无人值守且治理确定的情况下，将待办事项运行至完成	Council 是 ANS 委派决策的验证者；ANS 负责执行，Council 不负责
Media QC	媒体产物验证 — 图像／视频／文档输出质量控制	Council 审查决策和推理；Media QC 审查媒体输出。Council 可以将图像作为决策依据，但不负责媒体质检
Benchmark	测量 — 智能测试、竞技场、模型／评审者声誉	为 Council 的经验型提案者／评审者选择提供数据；Council 使用 Benchmark，但不负责运行它
Routing	提供商选择 — 由哪个提供商／模型承载调用	Council 提供区域／数据驻留政策（仅限欧盟数据驻留），但底层提供商路由由 Routing 负责
Memory	长期上下文 — 跨会话的持久状态	Council 在每次调用中无状态（会记录 request_id 以供审计）；持久记忆由 Memory 提供

如果你需要执行、调度、自主运行、记忆、浏览器自动化或通用提供商路由，那你找错组件了——Council 只负责决策。 将执行任务交给 ANS。

实用示例

代码／安全审查（diff — 保留异议）

tokonomix_consensus_ask({
  prompt: "Is this auth middleware safe? Review for timing side-channels, IDOR, and missing-auth paths.\n\n```ts\n" + middlewareSource + "\n```",
  mode: "diff"   // surface the one model that flags the constant-time issue; don't average it away
})

四个模型都说“看起来没问题”；一个模型指出令牌比较不是恒定时间的。单模型调用会返回“看起来没问题”，然后你就会发布它。diff 会呈现少数派的异议，让人工裁定真正重要的问题。

迁移安全检查（diff — 不可逆操作）

tokonomix_consensus_ask({
  prompt: "Is this migration reversible? Flag any irreversible step.\n\n" + migrationSql,
  mode: "diff"
})

安全检查需要保留少数派的异议，而不是将其平均掉。

合规／法律解读（consensus — 给出明确答案）

tokonomix_consensus_ask({
  prompt: "Can a SaaS legally store EU-citizen API logs in a US-hosted S3 bucket for 30 days under GDPR? Answer in 4 bullets: legal basis, Schrems II, alternatives, action plan.",
  mode: "consensus",
  models: ["claude-opus-4-8", "gpt-5.4", "gemini-2.5-pro"]   // slugs illustrative — confirm with tokonomix_list_models
})

这个提示词询问的是一种做法，不包含个人数据，因此使用美国前沿模型 Council 没问题。如果提示词包含实际客户记录，则应确保数据仅留在欧盟（见下一个示例）。

个人数据提示词 — 欧盟数据驻留（PII 必须遵循）

// 1. discover the EU-hosted set
tokonomix_list_models({ hosting_region: "eu" })
// 2. pin the council to it — the default council is US-hosted
tokonomix_consensus_ask({ prompt: promptContainingPII, models: [/* EU slugs from step 1 */] })

默认的 Council 托管在美国。将包含个人数据的隐私问题发送到三个美国云服务，本身就是一次跨境传输——而这正是该问题试图避免的。仅限欧盟的路由可确保提示词留在本地区，有助于最大限度减少数据，并降低跨大西洋传输风险。这并不是完整的 GDPR 合规声明；合规性取决于你的整个系统。

网关会看到什么（数据治理）

该 skill 会有意要求你发送待审核的材料——代码、合同、规范、日志等——这样每个模型都能基于同一份材料进行推理，而不是猜测。内容会经过 Tokonomix 网关传送给所选提供商，因此，是否将某份材料路由到第三方，是一项真实的数据流决策，与提供商所在的区域无关：

• 发送决策所需的内容，不要多发。 附加文件前，请先删去无需审核的机密信息和标识符——共识质量取决于材料是否相关，而非材料是否完整。
• 网关托管在欧盟，并负责计量调用；上方的区域选择控制哪些模型提供商会看到提示词。完整的保留期限／子处理方声明由网关服务提供，不在此客户端中。
• 涉及个人数据的内容 → 优先选择欧盟理事会（见上方），而非美国默认选项。

哪些内容会离开你的主机，哪些内容会在本地存储。 更准确地说，以下说明的是客户端侧（本软件包所控制的部分）：

• 共识调用时，唯一会向外发送的字段是 messages、x_council 元数据块和 max_tokens——没有隐藏字段，也没有客户端遥测（参见 SECURITY.md）。你附加的依据内容（context.inline / context.github_refs）会随 messages 一起传送，因此会到达所选提供商——这正是上文“发送决策所需的内容，不要多发”规则至关重要的原因。
• 客户端仅会在本地保存你的 API 密钥，位置为 ~/.tokonomix/credentials.json（以 0600 权限写入），此外还会在 ~/.tokonomix/ 下保存少量本地状态文件（该目录在 SECURITY.md 中称为凭据／状态目录）。密钥绝不会写入日志。
• 你在评分 note 中填写的自由文本（tokonomix_rate_consensus）仅由管理员处理：它绝不会返回给任何调用方，也不会原样公开显示。数值评分和结构化发现会用于模型选择评分；自由文本不会反馈给你或其他任何人。
• **本客户端不会说明的内容：**网关的完整保留期限和子处理方列表。这些属于托管服务的范畴，而非本软件包的内容——请将其视为需要向服务方核实的有意保留项，而不是我们可以通过客户端补充的信息。

文档／图表质量检查（以视觉作为依据）

tokonomix_consensus_ask({
  prompt: "Key differences between these two architecture diagrams? Focus on data-flow and security boundaries.",
  mode: "diff",
  images: [
    { data: "/9j/4AAQSkZJRgAB...", media_type: "image/jpeg" },
    { data: "iVBORw0KGgoAAAAN...", media_type: "image/png" }
  ]
})

视觉输入是用于决策审核的依据（理事会会对图表进行推理）——并非媒体质量检查流程。若未设置 models，理事会会自动选择当前的跨厂商视觉模型组合（当前的 Claude、Gemini 和 GPT 视觉模型——可查询 tokonomix_list_models({"supports":["vision"]}) 获取实时 slug，这些 slug 会变化）。data 是原始 base64，不带 data:image/...;base64, 前缀；允许的类型为 image/jpeg、image/png、image/webp、image/gif；最多 8 张图片，每张解码后不超过 5 MB，总计不超过 20 MB。

为结果评分（用于理事会选择）

tokonomix_rate_consensus({ request_id: "…", score: 8, consensus_benefit: "caught_blind_spot" })

请根据每次调用的实际价值评分：你主动征求的确认就是确认（raised_confidence），不是发现问题。当平台反馈闭环功能启用时，此功能才可用；关闭时，工具会返回清晰的“未启用”提示。

安装

1. 获取 API 密钥（或无密钥注册）

在 tokonomix.ai/signup 注册——赠送 €5.00 额度，无需银行卡。在 /dashboard/keys 创建密钥（密钥以 tok_live_ 开头）。

或者，无需任何密钥即可注册：运行 tokonomix_onboard("[email protected]")，然后使用通过邮件发送的 6 位验证码调用 tokonomix_onboard_verify——该操作会创建免费层级账户（含 €5 额度），并将密钥保存至 ~/.tokonomix/credentials.json（权限模式为 0600）。之后无需设置环境变量。

2. 将其添加到客户端

快速添加（Claude Code）：

claude mcp add council npx tokonomix-council-mcp

然后在环境中设置 TOKONOMIX_API_KEY（或者在运行 tokonomix_onboard 后，让 MCP 从 ~/.tokonomix/credentials.json 中读取该密钥）。

手动配置 — Claude Code（项目中的 .mcp.json，或 ~/.claude.json）：

{
  "mcpServers": {
    "tokonomix": {
      "command": "npx",
      "args": ["-y", "tokonomix-council-mcp"],
      "env": { "TOKONOMIX_API_KEY": "tok_live_..." }
    }
  }
}

Cursor / Cline / Continue / Zed — 将相同的 command + args + env 三项配置添加到工具的 MCP 服务配置中。

3. 配置

环境变量	默认值	说明
TOKONOMIX_API_KEY	— （完成引导后可选）	Bearer 密钥，以 tok_live_ 开头
TOKONOMIX_BASE_URL	https://tokonomix.ai/api/v1	兼容 OpenAI 的基础 URL（评审团）。Anthropic 基础 URL：https://tokonomix.ai/api/anthropic
TOKONOMIX_SITE_URL	根据基础 URL 派生	用于无密钥引导端点的主应用源地址

4. 工具

MCP 服务提供十个工具，名称均以 tokonomix_ 开头：

工具	功能
tokonomix_consensus_ask	核心功能：2–6 名提案者 + 独立评审者 → 一个结果（以上列出的模式）
tokonomix_single_ask	单模型直通调用 — 成本低，适用于常规调用
tokonomix_list_models	实时目录，可按地区、提供商、层级、能力和原产国筛选
tokonomix_get_balance	额度余额、层级和本月至今的用量（按模式统计已花费的 € 以及令牌吞吐量）
tokonomix_rate_consensus	按 request_id 评价结果 — 为模型投票 / 盲点信誉提供数据 （暂未启用：平台反馈循环启用前会返回 404）
tokonomix_upload	为有依据的调用暂存大型上下文 → session + handles （暂未启用：上下文上传功能启用前会返回“未启用”）
tokonomix_onboard	无密钥首次运行，第 1 步 — 发送一次性验证码到电子邮箱
tokonomix_onboard_verify	无密钥首次运行，第 2 步 — 开通免费账户并保存密钥
tokonomix_get_skill	从服务端获取规范用法技能
tokonomix_skill_version	以低成本获取技能的版本指纹（检测偏差）

技能

此软件包附带 tokonomix-consensus 技能（skill/tokonomix-consensus/SKILL.md），用于指导你的 Agent 何时使用共识（以及选择哪种模式），而不是进行单次调用。将其放入 .claude/skills/，或让 Agent 在运行时通过 tokonomix_get_skill 获取。服务端副本是权威版本 — tokonomix_skill_version 可检测偏差。

集成与 API 接口

除了 MCP 工具外，网关还提供两个 HTTP 接口，其能力配置不同——当 Agent 需要原生工具调用或结构化输出时，值得了解：

接口	端点	格式	工具调用 · 结构化输出 · 网络搜索 · 提示词缓存
Council（多模型）	POST /api/v1/chat/completions	兼容 OpenAI	不转发——共识流程会分发给 N 个提议模型和一个评审模型；工具调用和结构化输出无法取平均，因此仅支持单模型
单模型	POST /api/anthropic/v1/messages	Anthropic Messages wire-format · 可路由至任意提供商（OpenAI、Google、Anthropic、OVH-EU、Azure、xAI、Ollama……）	会转发——tools/tool_choice 和服务端工具（网络搜索）会以 tool_use 往返；cache_control 提示词缓存按缓存阶梯费率计费

需要经过验证、综合得出的决策时，使用 council 路径（或 tokonomix_consensus_ask）；当 Agent 需要原生函数调用、受 schema 约束的输出或提示词缓存时，使用单模型路径。该路径采用 Anthropic Messages wire-format，但并非仅限 Anthropic——网关会将调用发送给托管你所指定模型的任意已配置提供商。

Agent 工具使用（例如，通过 Tokonomix 运行外部代码审查工具）：将客户端指向 https://tokonomix.ai/api/anthropic，并使用 Anthropic wire format；同时取消设置任何环境中已有的 ANTHROPIC_API_KEY——部分 SDK 会将其作为 x-api-key 与你的 tok_live_ bearer 一同发送，网关会拒绝此类请求。

每个密钥的防护措施

预算和区域策略在密钥上设置，而不是针对每次调用重新决定：

• 预定义的默认模型和 council 路由——使用哪些提议模型、哪个评审模型、哪种模式；
• 网关强制执行的每月支出上限（monthly_limit_cents）——当本月已计费支出即将超出上限时，密钥会被封锁；
• 按模型／模式／评审模型／托管区域／模型来源国家设置的允许列表。

因此，你可以将密钥交给无人值守的运行任务，并确信它不会超支，也不会将提示词发送到非预期位置。使用 tokonomix_get_balance 跟踪用量（€ 和令牌，统计本月至今）。

基准测试

我们公布实测结果——其中也会重点说明与我们预期相反的结果。这里没有任何基准数据是捏造的，我们也不声称准确率或 bug 捕获能力有所提升。 两项发现至关重要：

发现 1——bug 捕获率没有可测得的净提升（SWE-bench，第 2 轮，N=29）

在 SWE-bench-Verified 缺陷任务上进行的第 2 轮验证证伪了“共识能捕获更多 bug”这一假设。一个非 Anthropic 基线模型（GPT-4o）漏掉了 30 个实际 bug 中的 29 个；对这 29 个 bug 运行跨系列 council，与仅重新运行 Agent 相比，捕获率没有可测得的净提升——council 偶尔能发现漏报，但误报标记抵消了这一效果（效应 +0.12，CI 跨越零）。因此，准确且诚实的说法是没有净提升——而不是“捕获的 bug 并没有更多”（那样会夸大相反方向的结论）。我们从未在任何地方声称 council 能捕获更多 bug。

发现 2——Council 在干净样本准确率上与最佳单模型持平，没有任何领域胜过它（基准测试 v2，5 个领域）

在涵盖 5 个领域的基准测试（v2）中，council 与最佳单模型持平，且没有在任何领域胜过它。对于干净、常见的任务，强大的单模型已经达到准确率上限，而 council 虽然成本更高，结果却与之持平。胜出者会随领域而变化——这才是该产品的实际价值所在：council 带来的是消除方差（无需事先判断哪个模型更强，也能获得评审组中的最高召回率），而不是更高的准确率上限。

基于数据的诚实定位

测得的价值是消除方差 + 验证 / Agent 质量保证 + 评审独立性 + 欧盟数据驻留 + 依据来源——不是“更准确”，也不是“能发现更多漏洞”。

方法论优先于讨好。 上述每个数字都对应一套在公开数据集（Finding 1 使用 SWE-bench-Verified）上可复现的方法，且结论方向一致：委员会与之持平，并未胜出。对于只有流程规则的情况（例如，有令人信服的机制性案例表明，依据来源能提高召回率），我们会注明“流程规则，而非测得的效应量”，不会给出百分比。这些发现背后的完整数据集和测试框架正在整理中，准备作为可复现的出版物发布（见路线图），让方法而非营销成为成果。

术语表

术语保持一致，这样人类或 AI Agent 在阅读这些文档时，对同一词语的理解始终相同。

术语	含义
决策工程	设计决策的产出方式：采用独立输入、独立协调器、依据真实信息进行核验并确保可审计，而不是信任单个模型的单次输出。Council 是该理念的参考实现，也是本文所定义原则的首个具体实现；目前还没有外部规范或第二个实现。
决策质量	Council 优化的目标：决策既正确，又可审计。可表示为 共识 × 真实依据 = 决策质量——共识是一种机制，依据真实信息进行核验（最有力的机制）是另一种，评审者独立性和验证则是其他机制。
参考实现	一个具体且可运行的构建，用于端到端地展示一套方法——这是对 Council 的事实描述，并非市场排名声明。它是本文所定义原则的首个此类构建：目前还没有外部规范或第二个实现，也没有外部组织采用它。（我们不声称它是“行业标准”。）
提议者	2–6 个独立且盲测回答提示词的模型之一。
评审者	对提议者的回答进行协调整合的模型。其设计上独立于提议者。
不重叠评审者	不属于提议者之一的评审者，因此它不会评判自己的回答。
跨系列评审者	来自不同供应商或模型系列的评审者，因此不会继承提议者共有的盲点。
共识模式	根据得到最多佐证的论点，合并得出的一个已定案回答。（默认模式。）
差异模式	结构化的共识／分歧／置信度报告——评审者只做比较，不会做出决定。
最佳项模式	评审者逐字选出已有回答中最有力的一项，不做合并。
原始模式	所有提议者的回答，不含评审者——未经筛选的观点分布（成本最低）。
完整模式	所有提议者的回答 + 评审者对每个模型的推理 + 一份结论，均在同一轮评审中给出（可审计）。
依据真实信息进行核验	将真实材料（文件、差异、规范、日志）提供给评审团，以便根据现实而非共同先验来核查论点。这是影响最大的一个杠杆。
有损综合	一种失效模式：评审者遗漏某个成员发现的真实问题，导致合并后的回答不如该成员自己的回答有力。
相关性失效	共享训练数据的前沿模型对同一问题持有错误看法，因此达成一致并不能证明正确。
虚假共识	表面上的趋同由相似的提示词或微调造成，而非独立佐证。
专家重叠	不独立的评审者（同时也是提议者）评判自己的工作，从而夸大测得的共识度。
召回率与精确率	召回率 = 发现罕见的真实问题（Council 的优势：只需一家供应商发现问题即可）。精确率 = 避免误报（Council 的代价：模型越多，需要裁定的标记就越多）。
决策置信度	Council 呈现的共识／分歧信号——diff 报告和逐条回答的盲点部分。这是供你判断的外显信号，并非答案正确概率的校准值。
消除方差	Council 的实际价值：你不再赌自己碰巧询问了哪个单一模型；即使事先不知道哪个模型更强，也能获得评审组的最高召回率。
依据门控	Council 可以拒绝评审过于单薄的输入并要求补充真实材料，而不是猜测的一种休眠／先影子运行机制。

常见问题

这是一个模型，还是一个聊天机器人？ 两者都不是。它是位于模型之上的决策工程层。它不会让任何模型变得更聪明，而是改变多个模型的输出如何汇聚为一个决策。它不是多模型聊天、投票系统或取平均值的系统。

Council 给出的答案比最佳单个模型更准确吗？ 不会——我们也不会声称如此。在我们的验证中，它在干净数据准确率上与最佳单个模型持平，在任何领域都没有胜过它；在一次 SWE-bench 运行中，命中率也没有净提升。实测价值在于消除方差、进行验证、保持评审者独立、实现欧盟数据驻留，以及提供依据。

那为什么要为它付费？ 因为哪一个单独模型表现最佳会因任务而异，而你通常无法提前知道。Council 无需你押注某个模型，就能获得整个评审组的顶尖召回率，揭示单个模型掩盖的分歧，并提供任何单一供应商 API 都无法提供的跨供应商检查。对于罕见且代价高昂的决策，这比其成本更有价值；对于日常工作则不然——请使用 tokonomix_single_ask。

如果共识只是手段，目标是什么？ 提升决策质量。共识是我们为此采用的一种机制；依据和评审者独立性则是其他机制。我们的优化目标是让决策正确且可审计，而不是让模型达成一致。

单一供应商能提供相同的服务吗？ 不能。OpenAI 无法评判 Claude，Anthropic 无法评判 Gemini，Google 无法评判 GPT。供应商自己的“评审组”共享其自身的训练数据和盲点——相关错误被包装成了意见一致。只有跨供应商才能实现去相关。

意见一致意味着答案正确吗？ 不意味着。前沿模型共享训练数据，因此它们可能达成一致，却全都错得一模一样（共享幻觉、相关性故障）。意见一致会提高置信度，但不代表正确。对于分布外事实或知识截止日期之后的事实，仍要对照一手来源进行核验，并为调用提供依据。

共识可能不如单个模型吗？ 可能，我们也明确说明这一点：有损综合（评审者遗漏真实发现）、相关性故障、虚假共识，以及专家重叠（评审者并非互不重叠，却抬高了一致程度）。请参阅共识何时有帮助／没有帮助／可能有害。如果不能接受遗漏任何发现，请使用 diff／full，并为调用提供依据。

Council 能运行、安排或记住我的工作吗？ 不能——这是有意设定的范围限制。Council 只负责决策。执行和无人值守的待办运行由 ANS 负责；长期记忆、浏览器自动化和通用供应商路由则由各自的组件负责。请参阅 Tokonomix 生态系统中的 Council。

个人数据／GDPR 怎么处理？ 如果提示词包含个人／可识别数据，请确保数据仅留在欧盟：先调用 tokonomix_list_models({hosting_region:"eu"})，再固定使用返回的模型标识。默认的 council 托管在美国。仅路由至欧盟可让提示词留在该区域，从而实现数据最小化，并降低跨大西洋传输风险。这并非完整的 GDPR 合规声明；是否合规取决于你的整个系统。

依据校验门已上线了吗？ 相关基础设施已经存在，但目前处于休眠／优先影子运行状态——由服务端控制，目前默认不会强制执行。请将其视为预期采用的机制，而非对你当前账户的保证。

如何确保决策可复现？ 记录提议模型、评审者模型、charged_credits、日期和准确的提示词——这些信息都会在账单明细中返回。默认 council 可能会随时间在服务端发生变化，因此同一提示词下个月可能会使用不同的模型。

文档

配套文档从AI 决策工程的角度介绍 Council，而非从线协议的角度。请从教程或术语表开始；阅读宣言，了解完整论述。整个套件中的术语均保持一致（参见术语表），每篇文档都附有易于理解的图表。

• 决策工程宣言 — 对这一领域的独立阐述。
• 术语表 — 为整个套件提供统一的词汇。
• 教程：首次共识调用 — 动手入门。
• 决策理论 — 为什么一个模型只代表一种视角；独立的多模型审查。
• 共识 — 共识机制和综合模式，以及各自的适用意图。
• 评审者独立性 — 独立且跨模型家族的 LLM 评审者。
• 依据支撑 — 对决策质量影响最大的杠杆，效果胜过增加模型。
• 验证 — AI 验证层；为什么模型无法验证自身。
• 置信度 — 为什么一致意见会提升置信度，而非正确性。
• 偏差 — 自我偏好与共享训练数据导致的偏差。
• 召回率与精确率 — 召回率放大器及其精确率代价。
• 失效模式 — 坦诚的核心内容：共识何时有帮助、无效或有害。
• 基准测试方法 — 可复现的方法及真实发现（包括被证伪的结论）。
• 架构 — 请求 → 提议者 → 评审者 → 决策 + 审计轨迹。
• 路由 — 专家组选择与默认采用欧盟数据驻留。
• 可审计性 — 可追溯性与评分反馈循环。
• 图表 — 嵌入上述文档、便于访问的 SVG（<title>/<desc>）。

路线图

如实说明哪些功能已上线，哪些仍在计划中：

• Grounding-gate 上线。 将输入不足时拒绝判断的门控机制从休眠／优先影子运行状态转为强制执行，前提是影子运行指标验证它不会过度拒绝。
• 上下文上传（tokonomix_upload）。 启用共享的、固定区域的上下文包，让大型制品只需暂存一次，即可供每个提议者和裁判读取。
• 共识反馈循环上线。 启用 tokonomix_rate_consensus 的结构化发现结果（真实／虚假分类、consensus_benefit），以支持实时评审团选择和盲点声誉评估。
• 可复现的基准测试发布。 发布上述发现背后的完整数据集和测试框架（包括已证伪的 bug 捕获声明），让方法本身而非营销宣传成为成果。
• 决策工程文档——现已发布（参见上文文档）：决策理论 · 共识 · 裁判独立性 · Grounding · 验证 · 置信度 · 偏差 · 召回率与精确率 · 失败模式 · 架构 · 基准测试方法 · 路由 · 可审计性 · 术语表 · 入门教程 · 无障碍图表。仍在计划中：与相邻技术进行坦诚的并排比较（单模型审查、同行评审、LLM-as-judge、集成、自一致性、思维树、多 Agent 编排）。
• 决策工程宣言（docs/decision-engineering-manifesto.md）。这份独立声明阐述了该领域为何存在、设计原则、失败模式、为何单个模型——以及仅靠共识——并不足够、为何 Grounding 必不可少，以及为何最终仍由人类承担责任。README 链接到该文档，而不是重复其中的详细内容。

许可证

MIT © Tokonomix.ai / InterIP Networks

问题与反馈

github.com/tokonomix/tokonomix-council-mcp/issues · [email protected]