multi-model-consensus

多模型决策委员会 — 消除单模型偏见,通过多轮分歧讨论产出客观决策参考。支持3-13个模型同时评审,提供量化投票矩阵和6段式共识报告。触发条件:包含「多模型决策」或「多模型委员会」时自动激活。

Safety Notice

This listing is from the official public ClawHub registry. Review SKILL.md and referenced scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "multi-model-consensus" with this command: npx skills add zeekr0808-hue/multi-model-consensus

🏛️ 多模型决策委员会

专为 OpenClaw 设计的"数字智库",通过多模型独立评审与共识合成,消除单模型偏见,为复杂决策提供客观参考。


🎯 插件定位

多模型决策委员会 是专为 OpenClaw 设计的"数字智库"。它支持调动多个不同架构的大模型(如 GPT、Gemini、豆包等)同时对同一任务进行协同思考、对抗辩论与共识合成,有效消除单模型偏见,综合性给出最优建议。


核心优势

  • 去中心化决策:交叉验证不同模型逻辑,确保方案的严谨性。
  • 对抗性评审:通过模型间的互评,快速锁定潜在的逻辑漏洞。
  • 弹性扩容:根据任务难度,随时增加或减少"决策委员"的数量。
  • 消除偏见:多模型独立评审,避免单一AI的认知盲区。
  • 量化决策:6维度评分 + 加权矩阵,结论有据可查。
  • 透明可信:实名委员制、模型身份透明。
  • 灵活配置:参数可调,如决策成员人数、决策轮次、通过阈值等,均可可自定义。

核心治理原则:身份纯净

为了确保结果的绝对客观,本插件强制执行 "身份纯净原则"

  • 角色透明化:决策委员会成员均会注明其身份(大模型名称),保持可视化透明。
  • 严禁设定角色:禁止给委员设定诸如"架构师"、"审计员"等身份标签。
  • 严禁引导提示:任务下发时不得针对评审委员设置诱导性提示词或诱导性身份角色,防止产生的偏见。
  • 严禁子Agent委托:评委严禁spawn任何子Agent,只能独立思考和输出结论;禁止二次委托,所有子任务由组织者统一分发和回收,确保链路完全可控
  • 评审不重复原则:若组织者(即当前使用模型)是评审委员会成员,则组织者提交内容即视同为其在本轮的评审结果,无需重复自评。若组织者不是评审委员会成员,则仅负责组织实施和汇总评委意见,不参与评审。

使用方法

  • 启动:在OpenClaw中,当用户输入的内容包含「多模型决策」或「多模型委员会」时,自动激活多模型决策委员会。首次使用时会提醒用户进入配置模式,并选择模型组合。
  • 配置:根据需要,可配置参数,如:轮数、阈值、委员数量、委员模型等。

参数配置

配置参数可采用指令方式,如:"修改配置"、"调整参数"、"增加委员"、"确认配置"。

指令关键词可调参数说明
"换模型"委员模型组合从用户本地接入的模型列表中选择模型组合加入
"改轮数"决策轮数默认3轮,日常事务可设为2轮,重大决策可设3-6轮
"收敛分差阈值"收敛判定分差已废弃
"改阈值"判定阈值通过阈值:默认≥90%;待决策阈值:默认[72%, 90%);否定阈值:默认<72%
"改判定方式"通过判定方式全票通过(默认):所有评委均需≥阈值;均分通过:评委均分≥阈值;多数票通过:超过半数评委≥阈值
"增加委员" / "减少委员"委员数量支持2-6个模型同时评审
"确认配置"确认当前配置确认当前参数后开始决策

参数建议

  • 模型选择:建议至少包含 1 个具备强逻辑推理能力的模型和 1 个具备强中文语境理解能力的模型。
  • 轮次建议:日常事务建议 2 轮;涉及架构,资金、核心规则的决策,建议 3-5 轮。
  • 阈值设定
    • 严谨型:≥95%(全票通过)
    • 效率型:≥75%(多数通过)

决策流程(3轮决策机制)

多模型决策委员会采用 3 轮决策机制,基于决策点级别评审,每轮进行100分制评分,最终给出决策结果。


第 0 轮:准备与框架确认 (Preparation & Framework Confirmation)

决策准备:组织者(当前使用模型)接收到决策任务后,将用户背景、需求、待审方案汇总,拆解为决策点及权重,发起决策申请。内容格式为:

  • 项目名称:{项目名称}
  • 项目背景:{项目背景}
  • 项目需求:{项目需求}
  • 待审方案:{待审方案}
  • 评审方案类型:{单方案评审 / 二选一评审 / 决策点拆分评审}
  • 决策点拆分及权重(仅决策点拆分评审时填写):
    • 决策点1({维度名称}):{权重}%
    • 决策点2({维度名称}):{权重}%
    • ……
  • 决策成员:{决策成员:调取已配置的模型组合}
  • 决策轮次:{决策轮次:调取已配置的轮数}
  • 阈值设置:{阈值设置:调取已配置的阈值}
  • 提交决策:{用户确认决策点、权重及配置后开始决策}

运行时自检(第 0 轮附加步骤,仅供内部决策)

组织者在启动评委前,必须执行环境自检,选择合适的子Agent调用方式。此信息仅供组织者内部决策用,不展示给用户。

自检方法:通过 session_status 或检查当前会话元数据,确认通道类型。

环境适配矩阵

环境RuntimeMode额外参数结果回收方式
Webchatsubagent"run"subagent_announce 事件回流
Feishu(支持thread)acp"session"streamTo: "parent", thread: true流式回流
Telegram/Discordacp"session"streamTo: "parent", thread: true流式回流
Unknown/不确定subagent"run"subagent_announce 事件回流(兜底方案)

第 1 轮:独立评估 (Blind Evaluation)

动作说明:组织者接收到决策确认后,将准备流程相关内容分发至各选定模型的独立子会话中。每位委员在完全无法感知他方意见的情况下进行背对背评审。

评审方案类型(由组织者根据方案复杂程度判断):

  • 单方案评审:简单/日常方案,评委直接对整体方案打分(0-100分制)
  • 二选一评审:提供方案A和方案B两套完整方案,评委先选择其中一个方案(落选方案直接PASS),再对选中方案的每个决策点逐项打分(0-100分制),加权平均计算总分
  • 决策点拆分评审:复杂/多维度方案,组织者将方案拆解为若干「决策点」,每个决策点对应一个具体评审维度。评委对每个决策点逐项打分(0-100分制)。整体方案得分为各决策点评分的加权平均值,由组织者自动计算,不再由评委单独打分

评审维度示例:方案逻辑合理性、完整性、潜在风险分析、实施资源消耗预估、可行性评审、优化建议。

评审时长:不超过120秒/轮。若120秒仍未回收所有子会话,组织者将结束流程并返回结果。

核心产出:组织者汇总各委员对所有决策点的评分结果,标记出未通过(评分 < 阈值)的决策点,提取为「未通过决策点清单」。


第 2 轮:分歧讨论(Dispute Discussion)

动作说明:组织者将第1轮中标记为「未通过」的决策点整理为「未通过决策点清单」,仅将这些未通过项下发给所有委员,要求评委只针对这些未通过决策点进行讨论并重新评分。已通过的决策点不再讨论。

评审时长:不超过120秒/轮。若120秒仍未回收所有子会话,组织者将结束流程并返回结果。

核心产出:汇总本轮重新评分结果,若所有决策点全员通过则直接输出最终报告;若仍有未通过项则进入下一轮。


最后一轮:最终辩论 (Final Duel)

特殊说明:无论配置多少轮,最终辩论始终是最后一轮

  • 3轮配置:第3轮为最终辩论
  • 5轮配置:第5轮为最终辩论
  • N轮配置:第N轮为最终辩论

动作说明:经过分歧讨论后,仍有决策点未通过时启用。组织者将仍未通过的决策点再次下发给所有委员,要求评委进行最后一轮讨论和重新评分。

评审时长:不超过120秒/轮。若120秒仍未回收所有子会话,组织者将结束流程并返回结果。

核心产出:若所有决策点全员通过,输出最终报告;若仍有未通过项,将未通过项标注状态后输出最终报告。


轮次扩展说明

扩展类型说明
增加轮次(4轮及以上)倒数第2轮参照「分歧讨论」;最后一轮参照「最终辩论」;中间轮次循环分歧讨论
减少轮次(3轮以下)第1轮参照「独立评估」;第2轮直接输出最终报告(视为最后一轮)

自动化通知规则

为防止评委评审时间过长导致用户对当前状态不知情,组织者必须在每轮评审开始前主动通知用户:

  • 进入第1轮:通知用户「各位评委已开始独立评估,请稍候」
  • 进入第2轮:通知用户「各位评委已开始分歧讨论,请稍候」
  • 进入最后一轮:通知用户「各位评委已开始最终辩论,请稍候」
  • 输出最终报告:通知用户「最终报告已生成」

中间结果输出规则(webchat 适配)

当环境为 webchat 时,用户无法像 Feishu thread 那样看到有序的中间消息。为提升用户体验,每轮结束后应立即向用户展示本轮汇总,而不是等到全部轮次结束后再统一输出。

环境中间结果处理
webchat每轮结束后立即输出本轮汇总矩阵 + 判定结果 + 提示语,然后继续下一轮
Feishu / Discord(thread 模式)按原流程执行,threaded 消息天然有序,无需特殊处理
Unknown / 不确定默认视为 webchat,执行中间输出规则

webchat 环境每轮输出模板

## 📊 第 X 轮评分汇总
[本轮评分矩阵]

## ⚖️ 第 X 轮判定结果
[通过/未通过/进入下一轮]

[未通过决策点清单(如有)]

**进入第 Y 轮:[轮次名称]。各位评委已开始[环节],请稍候。**

通过判定规则

每轮结束后必须进行判定,不可跳过。

【核心概念:决策点】 每个方案的评审内容拆解为若干「决策点」,评委对每个决策点评分(0-100分)。通过判定基于决策点级别进行。

【判定方式】(默认全票通过制)

  • 全票通过(默认):所有评委在所有决策点上的评分均需≥阈值,任一评委在任一决策点低于阈值即判定为不通过
  • 均分通过:所有评委在所有决策点上的平均分均≥阈值
  • 多数票通过:超过半数的评委在所有决策点上的评分均≥阈值

通过判定逻辑

轮次判定时机判定结果后续动作
第1轮结束后汇总所有决策点评分全员通过(所有决策点所有评委均≥阈值)直接输出最终报告
第1轮结束后汇总所有决策点评分非全员通过(存在未通过决策点)提取未通过的决策点,进入第2轮
第2轮结束后汇总未通过决策点全员通过直接输出最终报告
第2轮结束后汇总未通过决策点仍有未通过进入最后一轮最终辩论
最后一轮结束后汇总未通过决策点全员通过直接输出最终报告
最后一轮结束后汇总未通过决策点仍有未通过输出最终报告,标注各决策点状态
任意轮超限标记超时评委,以已返回结果继续汇总

各轮次讨论范围

轮次讨论范围
第2轮(分歧讨论)仅讨论上一轮中未通过的决策点
第3轮(最终辩论)仅讨论第2轮中仍未通过的决策点
后续轮次循环「分歧讨论」逻辑,直至所有决策点全员通过或已达最后一轮

最终输出:6段式共识报告

决策完成后,输出标准化报告,包含:

  1. 投票记录 — 量化评分矩阵(含决策点级别评分)
  2. 汇总说明 — 各委员核心论点(注明大模型)
  3. 执行方案 — 结论版 + 说明版
  4. 决策点通过清单 — 各决策点通过状态
  5. 结论摘要 — 一句话裁定 + 置信度
  6. 风险提示 — 主要风险与缓解建议

决策点通过状态标注

状态含义标注
全员通过所有评委在该决策点评分均≥阈值✅ 绿色 — 通过
待决策推荐顺序一致但有评委评分低于阈值🟡 黄色 — 待用户确认
有分歧推荐顺序不一致🔴 红色 — 有分歧,附原因

子Agent结果回收机制(重要)

Push-based 结果回收流程

组织者使用 Push-based(推送式) 而非轮询来回收子Agent结果:

Spawn 子Agent → sessions_yield 挂起 → 收到 subagent_announce 事件 → 提取结果 → 更新跟踪

关键步骤

  1. Spawn 子Agent 后,立即调用 sessions_yield 主动结束当前 turn
  2. 等待 OpenClaw 以 inter-session message 形式推送 subagent_announce 事件
  3. 识别 消息中的 BEGIN_UNTRUSTED_CHILD_RESULT 块,提取评审结果
  4. 记录 结果到会话上下文(见「轻量级状态跟踪」章节)
  5. 检查 是否所有评委都已返回:
    • 是 → 进入下一轮或输出最终报告
    • 否 → 继续等待(再次 yield)

⚠️ 禁止行为

  • 禁止用 sessions_listsubagents listexec sleep 轮询
  • 禁止在 spawn 后立即输出最终结论(必须等待所有结果回流)

标准调用示例

Webchat 环境(推荐默认)

SessionsSpawn:
  runtime: "subagent"
  mode: "run"
  model: "n1n/gpt-5.4"
  task: "评审任务..."
  timeoutSeconds: 180

Feishu/Discord 环境(支持 thread 的通道):

SessionsSpawn:
  runtime: "acp"
  mode: "session"
  thread: true
  streamTo: "parent"
  model: "n1n/gpt-5.4"
  task: "评审任务..."
  timeoutSeconds: 180

超时处理

单轮限时 120 秒(2分钟)。若超时:

  • 标记该评委为「超时-未提交」
  • 以已返回的评委结果继续汇总
  • 最终报告中注明超时评委

轻量级状态跟踪(替代状态文件)

组织者使用会话上下文变量跟踪评审状态,无需维护持久化状态文件。

状态跟踪格式(每轮开始时初始化):

[本轮状态跟踪]
Round: {1/2/3}
Spawned: {N}
Received: {M} ({评委A} ✅, {评委B} ✅)
Pending: {N-M} ({评委C} ⏳)

每收到一个子Agent结果,更新此跟踪块。全部完成后清空并进入下一轮。


异常处理规则

以下3类异常的处理标准:

异常类型处理标准
状态同步错误组织者检测到会话上下文中的状态跟踪与实际回收结果不符时,应立即中止当前流程,通知用户并提示重新发起决策
规则执行偏差组织者在执行中发现某委员的评审结果违反本skill规定的流程(如跳轮、跳过通过判定等),应要求该委员重新按规则执行,不得擅自修改委员结论
超时处理单轮超过120秒仍有评委未返回结果时,组织者对超时评委标记「超时-未提交」,以已返回的评委结果进行汇总和判定
结果未回流若 spawn 后未收到 subagent_announce 事件,检查是否使用了 sessions_yield 挂起,或 runtime/mode 配置是否正确

技术约束

  • 每个子会话最大执行时间:120秒(可通过 timeoutSeconds 配置,最大 300 秒)
  • 最大并发子会话数:13个
  • 状态文件有效期:24小时(V1.6.0 起不再使用状态文件,改用会话上下文跟踪)
  • 报告自动归档路径:~/.openclaw/workspace/memory/MONTHLY/mmd_<date>.md

参考文档

文档说明
references/STATE_MACHINE.md状态流转规则 + 异常处理(概念参考,V1.6.0 起实际使用会话上下文跟踪)
references/OUTPUT_TEMPLATE.md6段式报告完整模板 + 评委 Prompt
references/SCHEMA.md状态文件字段规范(已归档,V1.6.0 起不再强制使用)
references/TROUBLESHOOTING.md常见失败模式与排查指南(V1.6.0 新增)

🏛️ 兼听则明,万模共鉴。

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

Trading Card Generator

AI trading card generator for designing custom collectible card art in MTG, Pokemon, Yu-Gi-Oh, and sports card styles. Create fantasy TCG cards, spell cards,...

Registry SourceRecently Updated
General

youtube-channels

Use when a YouTube channel is the focus: pasted @handles or channel URLs, requests to browse a creator's uploads, see what a channel has posted recently, sea...

Registry SourceRecently Updated
General

Axi Send File

Convert workspace files into Telegram-downloadable attachments (PDF/ZIP). Use when the user asks to receive, download, or be sent a file that was generated o...

Registry SourceRecently Updated
General

memory-pro

This skill provides semantic search over your memory files using a local vector database.

Registry SourceRecently Updated