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 字

上下文传递机制

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. 模型路由器：异构模型分配

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

三层路由策略：

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()

容错机制

输出内容

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

v3.0 相比 v2.0 的改进

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

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

适用场景

使用策略

本地开发

使用 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

🔒 数据处理透明度

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

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

版本：3.0.13

更新日期：2026-05-26