Deep Discussion Skill

Multi-agent deep discussion through intelligent Orchestrator coordination with agenda checklist tracking.

Quick Start

CODEBLOCK0

Result: Agenda items × 3 rounds = 根据议程数量而定

输出文件

每个讨论会生成以下文件（保存到 workspace/deep-discussion/{topic-slug}/）：

文件	内容
INLINECODE1	议程清单（checklist 格式），追踪讨论进度
INLINECODE2

⚠️ 讨论完成后不要创建其他文件（如 discussion.md），避免与 discussion-log.md 重复。

⚠️ agenda.md 规范

议程清单采用 checklist 格式，追踪讨论进度：

CODEBLOCK1

Orchestrator 职责：

- 讨论前创建 INLINECODE5
议程第 1 项：讨论是否要修改议程
根据专家反馈更新议程（考虑依赖关系）
每完成一项 → 打勾 ✅
实时更新讨论进度

⚠️ discussion-log.md 规范

必须包含所有专家的原始输出！

CODEBLOCK2

Orchestrator 职责：

- 每次 spawn 专家后，立即将专家输出追加到 discussion-log.md
不要只保存到单独文件，必须汇总到一个文件
按 Phase → 议题 → Round → Expert 组织

⚠️ Pre-flight Checks

Check 1: maxSpawnDepth

CODEBLOCK3

Value	Orchestrator 运行位置	说明
INLINECODE6	Orchestrator: Subagent ⭐	启动独立 Orchestrator subagent 协调专家
INLINECODE7

💡 不管什么模式都需要 Orchestrator 角色，区别只是运行位置。

Check 2: Topic Alignment

⚠️ 重要：话题对齐不是固定问题，而是自然对话式理解。

根据讨论主题灵活调整问题，目标是理解：

- 讨论目标是什么？
需要哪些视角/专业知识？
期望产出是什么？

示例：

主题	话题对齐问题
预制菜行业	"是做投资研究、产品规划、还是市场调研？"
技术选型

"是要做架构决策，还是技术调研报告？" |
| 产品功能 | "是解决具体问题，还是探索新方向？" |

避免机械地问 5 个固定问题！

Check 3: Expert Confirmation + Final Go

基于话题对齐，推荐专家角色供用户确认：

CODEBLOCK4

用户确认后 → 直接 spawn Orchestrator，不再追问！

示例：

CODEBLOCK5

用户回复 "确认" 或 "y" → 立即启动 Orchestrator

Core Concepts

议程清单（Agenda Checklist）

议程清单是讨论的核心追踪工具：

CODEBLOCK6

关键规则：

1. 第一项必须是"讨论是否要修改议程"
Phase 是议程的逻辑分组（不是独立阶段）
每完成一项 → 打勾 ✅
Orchestrator 根据依赖关系编排议程顺序

三轮讨论机制（每个议题）

每个议题都经历三轮讨论：

Round	目标	方式	结束条件
Round 1: Diverge	发表观点	并行 spawn 所有专家	全部完成
Round 2: Discuss

议题完成后 → 进入下一议题

议程依赖关系

Orchestrator 在修改议程时需要考虑依赖关系：

CODEBLOCK7

依赖关系示例：

- "技术方案" 依赖于 "问题定义"
"实施计划" 依赖于 "技术方案" 和 "资源评估"
"测试策略" 依赖于 "技术方案"

Orchestrator 工作流程

架构

CODEBLOCK8

议程第 1 项：讨论是否要修改议程

CODEBLOCK9

每个议题的讨论流程

CODEBLOCK10

Round 1: 发表观点（并行 spawn）

CODEBLOCK11

Round 2: 互相讨论（依次 spawn）

CODEBLOCK12

Round 3: 收敛共识

CODEBLOCK13

状态追踪

Orchestrator 需要维护讨论状态：

CODEBLOCK14

智能专家选择（Round 2）

CODEBLOCK15

Orchestrator 运行模式

方面	Subagent ⭐	Main
运行位置	独立 subagent	主 Session
专家 spawn

Orchestrator: Subagent 启动命令

⚠️ 重要：Orchestrator 必须使用 mode: "session"，而非 mode: "run"！

mode	行为	适用场景
INLINECODE11	一次性执行，spawn 子任务后立即返回	简单任务，不需要协调
INLINECODE12 ⭐

持久会话，持续追踪子任务，可等待/轮询结果 | 多轮协调、需要收集结果 |

为什么 Orchestrator 需要 mode: "session"？

- Orchestrator 需要 spawn 多个专家，并等待他们完成
需要收集专家输出，写入 discussion-log.md
需要持续追踪讨论进度（哪个议题、哪个 Round）
INLINECODE14 会立即返回，无法等待子任务结果

⚠️ 平台限制：mode: "session" 需要 thread: true，但飞书插件暂不支持 thread 模式。

替代方案：在 mode: "run" 模式下，Orchestrator spawn 专家后调用 sessions_yield() 等待子任务完成，系统会在所有子任务完成后通知继续。

CODEBLOCK16markdown

Phase {N}: {Phase 名称}

Round {M}: {Round 类型}

专家 {id}: {角色名}

{专家的完整原始输出，不要总结，不要省略}

专家 {id+1}: {角色名}

{专家的完整原始输出}


### ⚠️ 严格禁止：

1. ❌ 不要只保存到单独文件，必须汇总到 discussion-log.md
2. ❌ 不要总结专家输出，必须保留完整原始内容
3. ❌ 不要省略任何专家的输出
4. ❌ 不要在讨论结束后才写入，必须在 spawn 后立即追加

### 执行流程：

每次 spawn 专家：

1. 等待专家完成
读取专家输出
立即追加到 discussion-log.md（格式：Phase → Round → Expert）
继续下一个专家

CODEBLOCK18

Orchestrator: Main 运行方式

主 Session 直接执行 Orchestrator 工作流程，状态保存在主 Session 中。

Model Policy

Default: bailian/qwen3.5-plus (strong conversation ability)

If unavailable:

⚠️ Model unavailable: bailian/qwen3.5-plus

Options:
A. Wait for recovery
B. Use alternative model (user-specified)
C. Cancel

Key Points

1. 议程清单追踪：agenda.md 维护讨论进度，每完成一项打勾 ✅
第一项必是议程修改：讨论是否要修改议程
Phase = 议程分组：逻辑分组，不是独立阶段
三轮讨论机制：Round 1 并行 → Round 2 依次 → Round 3 收敛
thinking: "high"：所有专家和 Orchestrator 必须启用深度思考
议程依赖关系：修改议程时考虑依赖关系编排顺序
并行/依次规则：Round 1 可并行，Round 2 必须依次
统计追踪：记录每个议题讨论时间 + 每个专家发言次数
Orchestrator: Subagent - maxSpawnDepth ≥ 2 时推荐
Model: qwen3.5-plus - 对话能力强
⚠️ Orchestrator 必须用 mode: "session" - 持续追踪子任务，等待专家完成后再继续
⚠️ 断点续传机制 - Orchestrator 每完成一步更新状态文件，Main Session 检查并继续
⚠️ sessions_yield 循环模式 - Orchestrator 必须在 task 中写好循环结构

⚠️ sessions_yield 循环模式（核心）

问题分析

INLINECODE21 的正确用法：

- 结束当前 turn
携带 hidden payload 到下一个 turn
系统会在子任务完成后唤醒下一个 turn

关键问题：当所有子任务完成后，如果 Orchestrator 的代码没有更多要执行的，它就会返回。

解决方案：在 Orchestrator 的 task 中写好循环结构，让它知道还有更多工作要做。

正确的循环模式

CODEBLOCK20
while (还有未完成的议题) {
// 1. 执行当前议题的当前轮次
spawn 专家

// 2. yield 等待专家完成
sessions_yield({ message: "等待专家完成..." })

// 3. 系统唤醒后，收集结果
收集专家输出

// 4. 写入 discussion-log.md

// 5. 检查议题是否完成
if (议题完成) {
打勾 ✅
更新状态文件
进入下一议题
}
}
CODEBLOCK21

错误示范

CODEBLOCK22

正确示范

CODEBLOCK23

⚠️ 断点续传机制（解决 Orchestrator 中断问题）

问题背景

INLINECODE22 的设计让 Orchestrator 可以暂停等待子任务，但当所有子任务完成后，Orchestrator 会返回（认为任务完成）。这导致多议题讨论无法在一次 spawn 中完成。

解决方案：状态持久化 + Main Session 协调

核心思路：

1. Orchestrator 每完成一步，更新 orchestrator-state.json 状态文件
Main Session 检查状态文件
如果未完成，spawn 新的 Orchestrator 从断点继续

状态文件格式

文件位置：INLINECODE24

CODEBLOCK24

Main Session 协调流程

CODEBLOCK25

Orchestrator 任务模板（支持断点续传）

CODEBLOCK26json
// workspace/deep-discussion/{topic-slug}/orchestrator-state.json
{
"status": "in_progress",
"current_phase": "Phase X",
"current_topic": N,
"current_round": M,
"completed_topics": [...],
"pending_topics": [...],
"last_update": "ISO时间戳",
"next_action": "具体下一步操作"
}


### 完成所有议题后，设置：

json
{
"status": "completed",
"completed_topics": [1, 2, 3, ...],
"last_update": "..."
}
CODEBLOCK28

Main Session 检查间隔

议题数	检查间隔	原因
≤5	2 分钟	短讨论，快速检查
6-15

5 分钟 | 中等讨论 | | >15 | 10 分钟 | 长讨论，减少检查开销 |

统计追踪功能

Orchestrator 需要实时记录讨论统计：

议题讨论时间

CODEBLOCK29

专家发言次数

CODEBLOCK30

最终报告中的统计

CODEBLOCK31

References

- expert-roles.md - 专家角色库
orchestrator-logic.md - 详细逻辑
discussion-protocol.md - 讨论协议

深度讨论技能

通过智能编排器协调与议程清单追踪实现的多智能体深度讨论。

快速开始

用户：深入讨论预制菜行业现状，使用 5 个专家

助手：

1. 检查 maxSpawnDepth
对齐话题（自然对话式）
确认专家
生成编排器子智能体（思考：高）

结果：议程项目 × 3 轮 = 根据议程数量而定

输出文件

每个讨论会生成以下文件（保存到 workspace/deep-discussion/{topic-slug}/）：

文件	内容
agenda.md	议程清单（checklist 格式），追踪讨论进度
discussion-log.md

⚠️ 讨论完成后不要创建其他文件（如 discussion.md），避免与 discussion-log.md 重复。

⚠️ agenda.md 规范

议程清单采用 checklist 格式，追踪讨论进度：

markdown

议程清单 - {topic}

阶段 1：价值定位

- [ ] 1. 讨论是否要修改议程
[ ] 2. 学习规划功能的价值主张是什么？
[ ] 3. 与自适应引擎如何协同？

阶段 2：实现方式

- [ ] 4. 时长预测技术路径？
[ ] 5. 数据需求与特征工程？

...

讨论进度

- 总议题数：{N}
已完成：{M}
进行中：{K}

编排器职责：

- 讨论前创建 agenda.md
议程第 1 项：讨论是否要修改议程
根据专家反馈更新议程（考虑依赖关系）
每完成一项 → 打勾 ✅
实时更新讨论进度

⚠️ discussion-log.md 规范

必须包含所有专家的原始输出！

markdown

完整讨论记录 - {topic}

阶段 1：价值定位

议题 2：学习规划功能的价值主张是什么？

第 1 轮：发表观点

专家 1：{角色名}

{专家 1 的完整原始输出}

专家 2：{角色名}

{专家 2 的完整原始输出}

...

第 2 轮：互相讨论

专家 3 回应专家 1 的问题

{专家 3 的完整原始输出}

...

第 3 轮：收敛共识

编排器总结

{共识总结}

议题 3：与自适应引擎如何协同？

...

编排器职责：

- 每次生成专家后，立即将专家输出追加到 discussion-log.md
不要只保存到单独文件，必须汇总到一个文件
按阶段 → 议题 → 轮次 → 专家组织

⚠️ 预检检查

检查 1：maxSpawnDepth

bash
openclaw config get agents.defaults.subagents.maxSpawnDepth

值	编排器运行位置	说明
≥2	编排器：子智能体 ⭐	启动独立编排器子智能体协调专家
=1

💡 不管什么模式都需要编排器角色，区别只是运行位置。

检查 2：话题对齐

⚠️ 重要：话题对齐不是固定问题，而是自然对话式理解。

根据讨论主题灵活调整问题，目标是理解：

- 讨论目标是什么？
需要哪些视角/专业知识？
期望产出是什么？

示例：

主题	话题对齐问题
预制菜行业	是做投资研究、产品规划、还是市场调研？
技术选型

是要做架构决策，还是技术调研报告？ |
| 产品功能 | 是解决具体问题，还是探索新方向？ |

避免机械地问 5 个固定问题！

检查 3：专家确认 + 最终启动

基于话题对齐，推荐专家角色供用户确认：

🎯 推荐专家（{N} 位）：

1. {角色 1} - {职责说明}
{角色 2} - {职责说明}
{角色 3} - {职责说明}

...

调整或确认？[y/N 或修改]

用户确认后 → 直接生成编排器，不再追问！

示例：

🎯 推荐专家（5 位）：

1. 行业分析师 - 市场规模、趋势分析
供应链专家 - 成本结构、效率优化
消费研究员 - 用户需求、行为分析
政策顾问 - 法规风险、合规建议
投资专家 - 估值逻辑、投资回报

调整或确认？[y/N 或修改]

用户回复确认或 y → 立即启动编排器

核心概念

议程清单（Agenda Checklist）

议程清单是讨论的核心追踪工具：

markdown

议程清单 - {topic}

阶段 1：价值定位

- [ ] 1. 讨论是否要修改议程
[ ] 2. 学习规划功能的价值主张是什么？
[ ] 3. 与自适应引擎如何协同？

阶段 2：实现方式

- [ ] 4. 时长预测技术路径？

...

关键规则：

1. 第一项必须是讨论是否要修改议程
阶段是议程的逻辑分组（不是独立阶段）
每完成一项 → 打勾 ✅
编排器根据依赖关系编排议程顺序

三轮讨论机制（每个议题）

每个议题都经历三轮讨论：

轮次	目标	方式	结束条件
第 1 轮：发散	发表观点	并行生成所有专家	全部完成
第 2 轮：讨论

议题完成后 → 进入下一议题

议程依赖关系

编排器在修改议程时需要考虑依赖关系：

正确的议程顺序：

1. 问题定义 → 2. 技术方案 → 3. 实施计划

错误的议程顺序：

1. 实施计划 → 2. 问题定义 → 3. 技术方案

（实施依赖于问题定义和技术方案）

依赖关系示例：

- 技术方案依赖于问题定义
实施计划依赖于技术方案和资源评估
测试策略依赖于技术方案

编排器工作流程

架构

主会话（深度 0）
│
└─→ 编排器（深度 1）[运行在子智能体或主会话]
│
├─→ 1. 创建 agenda.md（议程清单）
│
├─→ 2. 议程第 1 项：讨论是否要修改议程
│ ├─ 并行生成所有专家发表看法
│ ├─ 根据反馈更新议程（考虑依赖关系）
│ └─ 打勾 ✅
│
└─→ 3. 按议程逐项讨论：
├─ 第 1 轮：并行生成所有专家发表观点
├─ 第 2 轮：依次生成专家讨论（动态轮数）
├─ 第 3 轮：收敛共识
└─ 打勾 ✅ → 下一议题

议程第 1 项：讨论是否要修改议程

议程第 1 项：
├── 1. 并行生成所有专家
│ task: 请审视议程草案，提出修改建议
├── 2. 收集专家反馈
├── 3. 根据反馈更新议程
│ - 考虑依赖关系编排顺序
│ - 合并相似议题
│ - 拆分复杂议题
│ - 添加遗漏议题
├── 4. 更新 agenda.md
└── 5. 打勾 ✅

每个议题的讨论流程

议题 N：
├── 第 1 轮：发表观点（并行生成）
│ 所有专家同时发表对议题 N 的看法
│ 追加

deep-discussion深度讨论

deep-discussion

Deep Discussion Skill

Quick Start

输出文件

⚠️ agenda.md 规范

⚠️ discussion-log.md 规范

⚠️ Pre-flight Checks

Check 1: maxSpawnDepth

Check 2: Topic Alignment

Check 3: Expert Confirmation + Final Go

Core Concepts

议程清单（Agenda Checklist）

三轮讨论机制（每个议题）

议程依赖关系

Orchestrator 工作流程

架构

议程第 1 项：讨论是否要修改议程

每个议题的讨论流程

Round 1: 发表观点（并行 spawn）

Round 2: 互相讨论（依次 spawn）

Round 3: 收敛共识

状态追踪

智能专家选择（Round 2）

Orchestrator 运行模式

Orchestrator: Subagent 启动命令

Phase {N}: {Phase 名称}

Round {M}: {Round 类型}

专家 {id}: {角色名}

专家 {id+1}: {角色名}

Orchestrator: Main 运行方式

Model Policy

Key Points

⚠️ sessions_yield 循环模式（核心）

问题分析

正确的循环模式

错误示范

正确示范

⚠️ 断点续传机制（解决 Orchestrator 中断问题）

问题背景

解决方案：状态持久化 + Main Session 协调

状态文件格式

Main Session 协调流程

Orchestrator 任务模板（支持断点续传）

Main Session 检查间隔

统计追踪功能

议题讨论时间

专家发言次数

最终报告中的统计

References

深度讨论技能

快速开始

输出文件

⚠️ agenda.md 规范

议程清单 - {topic}

阶段 1：价值定位

阶段 2：实现方式

讨论进度

⚠️ discussion-log.md 规范

完整讨论记录 - {topic}

阶段 1：价值定位

议题 2：学习规划功能的价值主张是什么？

第 1 轮：发表观点

专家 1：{角色名}

专家 2：{角色名}

第 2 轮：互相讨论

专家 3 回应专家 1 的问题

第 3 轮：收敛共识

编排器总结

议题 3：与自适应引擎如何协同？

⚠️ 预检检查

检查 1：maxSpawnDepth

检查 2：话题对齐

检查 3：专家确认 + 最终启动

核心概念

议程清单（Agenda Checklist）

议程清单 - {topic}

阶段 1：价值定位

阶段 2：实现方式

三轮讨论机制（每个议题）