shield_lock
JinDaGe
← Back to skills
extension
Category: OtherNo API key required

Roundtable Skill

RoundTable v3.0 通用多 Agent 圆桌讨论引擎：支持异构模型路由、MMR 意图解析、收敛控制和 170+ 专家库。

personAuthor: krislu1221hubclawhub
open_in_newRepositorydownloadDownload package

RoundTable v3.0 — 通用多 Agent 圆桌讨论引擎

Overview / 概览

RoundTable simulates a real roundtable meeting: multiple AI Agents assume distinct expert personas and produce high-feasibility proposals through 5 rounds of progressive, structured discussion. Its core design goal is to break single-Agent perspective blind spots — one mind inevitably circles within its own cognitive frame; cross-validating ideas under pressure from multiple expert viewpoints is far more reliable than solitary reasoning.

概览：RoundTable 模拟真实圆桌会议：多个 AI Agent 扮演不同专家角色，通过 5 轮渐进式讨论产出高可行性方案。核心目标是打破单一 Agent 视角盲区——一个大脑容易在自己的框架内打转；多视角交叉验证远比单一视角更可靠。

Design Philosophy / 设计哲学

Why RoundTable / 为什么需要 RoundTable

Single Agents have inherent limitations:

  • Narrow perspective — No matter how deep one thinks, it cannot escape its own cognitive frame. A backend engineer will always reason like a backend engineer.
  • No adversarial check — Without challenge, proposals become echo-chamber self-validation. The agent confirms its own assumptions and calls it "analysis."
  • Pseudo-depth — Looks like thorough reasoning, but it is the same angle repeated with different wording. Real depth requires friction between opposing viewpoints.

RoundTable's structured adversarial design breaks this cycle through 5 mandatory rounds:

R1 Independent → R2 Cross-Reference → R3 Forced Critique → R4 Debate & Revise → R5 Arbitrate

After 5 rounds, the system surfaces 15+ risks, 9+ defects, and produces a plan that has been thoroughly stress-tested against diverse expert scrutiny.

为什么需要 RoundTable：单一 Agent 存在天然局限——视角单一（无法跳出自身认知框架）、缺乏对抗检验（没有挑战的方案容易沦为回声室自证）、伪深度（看似全面实则同一角度反复展开）。RoundTable 通过结构化对抗设计打破这一循环：R1 独立提出 → R2 交叉引用 → R3 强制质疑 → R4 辩论修订 → R5 仲裁总结。5 轮后系统可暴露 15+ 风险、9+ 缺陷，产出经过充分压力测试的方案。

Core Design Principles / 核心设计原则

  1. Real sub-Agent isolation — Every utterance in every round is an independent sessions_spawn. Models and thought-chains are fully isolated; no shared context leaks between experts.
  2. Forced critique depth — No vague hand-waving allowed. The critique round (R3) must produce exactly 5 risks + 3 defects, each backed by concrete reasoning.
  3. Dynamic proposal evolution — R4 is not a repeat of R1. Experts must show an explicit "Original → Revised + Reason" comparison table, proving their thinking evolved under challenge.
  4. Explicit disagreement arbitration — The R5 Host cannot dodge conflicts. Every disputed point must receive a ruling with rationale, even when experts fundamentally disagree.
  5. Directly executable output — Not "recommendations." The final deliverable is an 8-week task table with named owners, deliverables, and risk contingencies.

核心设计原则：

  1. 真实子 Agent 隔离：每轮每句都是独立 sessions_spawn，模型与思维链完全隔离，避免专家之间共享上下文造成观点污染。
  2. 强制质疑深度：不允许模糊敷衍；R3 质疑轮硬性要求输出 5 个风险 + 3 个缺陷，并给出具体依据。
  3. 方案动态演进：R4 不能重复 R1，必须展示「原方案 → 修订方案 + 修订理由」对比表，证明观点在质疑后发生了真实变化。
  4. 明确分歧仲裁：R5 主持人不能回避冲突，必须对争议点逐条裁决并说明理由。
  5. 直接可执行输出：最终交付不是泛泛建议，而是带负责人、交付物、时间安排和风险预案的执行计划。

5 轮讨论流程

R1 独立提案  →  R2 交叉引用  →  R3 深度质疑  →  R4 辩论修订  →  R5 主持人总结
      ↓              ↓              ↓              ↓              ↓
  3 位专家       引用彼此观点      5 风险 + 3 缺陷   回应质疑并修订     仲裁分歧并输出计划
  800-1200 字    800-1200 字       明确证据         1000-1500 字      1500-2000 字

| 轮次 | 主题 | 核心任务 | 硬性要求 | | --- | --- | --- | --- | | R1 | 独立提案 | 每位专家从自身视角给出方案 | 至少 1 个对比表 + 5 个量化指标 | | R2 | 交叉引用 | 引用其他专家观点并补足盲区 | 至少 3 个引用标记 + 明确赞同/反对立场 | | R3 | 深度质疑 | 找出真实风险和缺陷 | 5 个风险 + 3 个缺陷，每项都要有依据 | | R4 | 辩论修订 | 回应质疑并修订方案 | 必须提供「原方案 / 修订方案 / 修订理由」对比表 | | R5 | 主持总结 | 仲裁分歧并形成最终计划 | 8 周任务表 + 风险预案 + Top 3 风险 |

上下文传递机制

v2.0 的核心缺陷是 R2-R5 对前序轮次缺乏充分感知，导致每轮都像重新开始。v3.0 强制注入完整讨论历史：

  • R2：注入全部 R1 专家发言，用于引用和交叉补充。
  • R3：注入 R1 + R2 历史，确保质疑针对真实内容。
  • R4：注入 R1-R3 历史，确保回应真实争议。
  • R5 主持人：注入 R1-R4 完整历史，否则无法完成有效仲裁。

架构

┌─────────────────────────────────────────────────────────┐
│                    RoundTable Engine                    │
├─────────────────────────────────────────────────────────┤
│  意图解析器        │  模型路由器       │  收敛控制器       │
│  MMR Intent        │  异构模型路由     │  防循环机制       │
├────────────────────┼──────────────────┼──────────────────┤
│  专家选择器        │  提示词构建器     │  通知模块         │
│  170+ 专家库       │  结构化模板       │  飞书/Lark        │
└─────────────────────────────────────────────────────────┘

1. 意图解析器：基于 MMR 的专家选择

不是简单关键词匹配，而是使用 Maximal Marginal Relevance（MMR，最大边际相关性）：

score = λ × 相关性 − (1−λ) × 与已选专家的最大相似度
  • λ 控制相关性与多样性的平衡，默认 0.7，更偏向覆盖不同视角。
  • 避免“回音室效应”：3 位专家不能全部来自同一领域。
  • 170+ 专家库覆盖工程、设计、产品、安全、性能、增长、DevOps、数据等方向。

2. 模型路由器：异构模型分配

不同专家角色使用不同模型，充分利用各模型优势：

| 专家角色 | 能力需求 | 推荐模型标签 | | --- | --- | --- | | 工程 / 架构 | 代码、逻辑、技术判断 | code、technical、engineering | | 设计 / 创意 | 长上下文、创意表达 | creative、long-context、design | | QA / 测试 | 均衡、快速、严谨 | balanced、fast、general | | 产品 / 商业 | 中文表达、领域知识、业务判断 | chinese、knowledge、product | | 主持总结 | 逻辑、裁决、归纳 | logic、summary、decision、max |

三层路由策略：

  1. 用户显式配置（最高优先级）：读取自定义 local_models.json。
  2. OpenClaw 官方 API（推荐）：自动发现可用模型。
  3. 单模型降级（兜底）：由一个模型扮演全部角色。

ClawHub 合规要求：不扫描 os.environ，不读取 apiKey / baseUrl 等敏感字段；模型信息只来自公开配置文件。

3. 收敛控制器：防止无限循环

R1 → R2 → R3 → R4 → R5
                    ↑
          语义分歧低于阈值 → 提前停止
          达到最大轮次 → 强制仲裁
  • 语义重复检测：连续 2 轮内容重合度超过 80% 时自动停止。
  • 共识检测：R4 后确认 3 个以上共识点时，加速进入 R5。
  • 硬性上限：最多 5 轮，防止 Token 爆炸。

4. 专家选择器：170+ 专家库

领域覆盖：

  • 技术：后端、前端、全栈、架构、DevOps、安全、DBA、算法、数据工程。
  • 产品：产品经理、增长、数据分析、UX、客户成功。
  • 商业：市场策略、品牌、销售、公关、商业分析。
  • 设计：交互、视觉、服务设计、设计系统。
  • 管理：项目经理、技术负责人、敏捷教练。

选择策略：MMR 算法 + 领域权重 + 用户强制指定。

5. 提示词构建器：结构化模板

每一轮都有独立的提示词框架（prompts/framework.md），不是自由发挥：

  • 硬约束：最低字数、表格要求、引用数量。
  • 角色化内容：不同专家角色使用对应行业模板。
  • 历史注入：将前序轮次内容加入当前轮提示词。

执行引擎

核心流程

engine = RoundTableEngine(
    topic="智能客服技术方案",
    agents=["工程专家", "产品专家", "架构专家"],
    mode="pre-ac"  # pre-ac: 本地预分析；full: 完整模式
)
success = await engine.run()

容错机制

| 场景 | 处理策略 | | --- | --- | | 子 Agent 超时 | 最多重试 2 次，间隔 5 秒 | | sessions_spawn 不可用 | 直接失败，不使用假数据兜底 | | R5 主持人失败 | 从已有轮次中自动抽取总结 | | 模型不可用 | 自动降级到 FALLBACK_MODEL |

输出内容

  1. JSON 报告：data/roundtable/{topic}.json，结构化数据，便于机器读取。
  2. Markdown 报告：人类可读版本，包含完整 5 轮讨论。
  3. 飞书 / Lark 通知（可选）：按轮次推送实时进度。
  4. 聊天室模式（可选）：将讨论广播到指定会话。

v3.0 相比 v2.0 的改进

| 维度 | v2.0 | v3.0 | | --- | --- | --- | | 上下文传递 | R2-R5 缺少前序上下文 ❌ | 强制注入完整历史 ✅ | | 质疑深度 | 泛泛而谈，约 3 个风险 | 硬性要求 5 个风险 + 3 个缺陷 | | 方案演进 | R1-R4 内容容易重复 | R4 必须给出修订对比表 | | 分歧处理 | 没有明确仲裁 | R5 主持人逐条裁决 | | 输出质量 | 400-600 字，缺少表格 | 800-2000 字 + 强制表格 | | 可执行性 | 约 50% | 90%+ |

基准测试数据（2026-03-19）

主题：智能客服技术方案
参与专家：工程 / 产品 / 设计（3 位）
子 Agent 调用：15 次
识别风险：15 个
发现缺陷：9 个
修改建议：13 条
8 周计划：W1-W8，含每日工作量估算
分歧裁决：4 项，均有理由
总输出：约 8,500 字

适用场景

| ✅ 推荐使用 | ❌ 不推荐使用 | | --- | --- | | 技术方案评审：架构、技术选型、复杂实现路线 | 简单问答：直接问主 Agent 即可 | | 产品立项：功能规划、MVP 边界、路线图 | 紧急决策：完整讨论通常需要 15-20 分钟 | | 复杂决策：多因素权衡、跨角色冲突 | 代码生成：请使用 Auto-Coding 类技能 | | 跨团队对齐：需要多视角共同校验 | 快速事实查询 |

使用策略

本地开发

使用 local_models.json 定义自定义模型阵容：

{
  "engineering": "deepseek/deepseek-v4-flash",
  "design": "minimax/minimax-latest",
  "host": "deepseek/deepseek-v4-pro"
}

ClawHub 公开模式

使用 roundtable_config.yaml 声明模型能力标签。只读取模型元数据，不访问 API Key、Base URL 或其它敏感配置。

文件路径

  • core/model_router.py
  • core/intent_parser.py
  • core/prompt_builder.py
  • core/convergence.py
  • prompts/framework.md

🔒 数据处理透明度

本技能运行期间会处理以下数据：

| 行为 | 说明 | 用户控制 | | --- | --- | --- | | 模型配置读取 | 读取模型 ID、标签、优先级，用于异构路由 | ✅ 可通过参数覆盖 | | 讨论历史注入 | R2-R5 注入前序轮次摘要，默认每轮截断到约 200 字符 | ✅ 截断限制暴露范围；用户控制讨论主题 | | 报告持久化 | 保存 JSON 与 Markdown 讨论报告 | ✅ 可配置输出目录 | | 聊天室广播 | 可选：将截断后的 Agent 输出（≤1000 字符）广播到独立会话 | ✅ 默认关闭（enable_chat_room=False） |

⚠️ 隐私提醒：如果讨论包含敏感信息，报告文件、聊天室会话和轮次通知可能暴露主题名称、专家角色和部分讨论内容。处理保密议题时，请关闭聊天室和通知渠道。

版本：3.0.13
更新日期：2026-05-26