🏛️ 多模型决策委员会
专为 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 或检查当前会话元数据,确认通道类型。
环境适配矩阵:
| 环境 | Runtime | Mode | 额外参数 | 结果回收方式 |
|---|---|---|---|---|
| Webchat | subagent | "run" | 无 | subagent_announce 事件回流 |
| Feishu(支持thread) | acp | "session" | streamTo: "parent", thread: true | 流式回流 |
| Telegram/Discord | acp | "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段式共识报告
决策完成后,输出标准化报告,包含:
- 投票记录 — 量化评分矩阵(含决策点级别评分)
- 汇总说明 — 各委员核心论点(注明大模型)
- 执行方案 — 结论版 + 说明版
- 决策点通过清单 — 各决策点通过状态
- 结论摘要 — 一句话裁定 + 置信度
- 风险提示 — 主要风险与缓解建议
决策点通过状态标注:
| 状态 | 含义 | 标注 |
|---|---|---|
| 全员通过 | 所有评委在该决策点评分均≥阈值 | ✅ 绿色 — 通过 |
| 待决策 | 推荐顺序一致但有评委评分低于阈值 | 🟡 黄色 — 待用户确认 |
| 有分歧 | 推荐顺序不一致 | 🔴 红色 — 有分歧,附原因 |
子Agent结果回收机制(重要)
Push-based 结果回收流程
组织者使用 Push-based(推送式) 而非轮询来回收子Agent结果:
Spawn 子Agent → sessions_yield 挂起 → 收到 subagent_announce 事件 → 提取结果 → 更新跟踪
关键步骤:
- Spawn 子Agent 后,立即调用
sessions_yield主动结束当前 turn - 等待 OpenClaw 以 inter-session message 形式推送
subagent_announce事件 - 识别 消息中的
BEGIN_UNTRUSTED_CHILD_RESULT块,提取评审结果 - 记录 结果到会话上下文(见「轻量级状态跟踪」章节)
- 检查 是否所有评委都已返回:
- 是 → 进入下一轮或输出最终报告
- 否 → 继续等待(再次 yield)
⚠️ 禁止行为:
- 禁止用
sessions_list、subagents list或exec 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.md | 6段式报告完整模板 + 评委 Prompt |
| references/SCHEMA.md | 状态文件字段规范(已归档,V1.6.0 起不再强制使用) |
| references/TROUBLESHOOTING.md | 常见失败模式与排查指南(V1.6.0 新增) |
🏛️ 兼听则明,万模共鉴。