---
name: sn-deep-research
description: "深度调研全流程编排器（入口 skill）。自动完成：规划→分维度取证→综合→成稿。产物：report.md + plan.json + sub_reports/*.md + synthesis.md。触发词：深度研究/调研/全面研究/系统研究/调研报告/深度报告/deep research/research report/行业研究/市场研究/竞品分析/政策研究/技术研究。这是管线入口，内部会自动调用 sn-research-planning → sn-dimension-research → sn-research-synthesis → sn-research-report。不用于：单点事实问答、一句话摘要、已给定来源的整理。如果用户已有材料只需写报告，用 sn-research-report。"
---

# Deep Research Orchestrator

这是深度研究的总控 skill。它负责把用户请求推进成一条可执行、可续跑、可核查、可交付的研究链路，并把全过程落盘到同一个 `report_dir`。

它是**编排器**，不是某一阶段的方法本身。需要在对应阶段读取并遵循其他方法 skill，但这些 skill 仍然在当前会话内顺序执行；不要异步分派、创建后台专家、启动额外子会话，或把关键阶段留在对话里不落盘。

## 启动前硬检查：web_search 配置

在创建 `report_dir`、写 `request.md` 或进入任何研究阶段之前，必须通过一次极小的通用 `web_search` 探测确认当前会话搜索能力可用。未确认时不要开始研究，也不要用记忆或已有知识替代联网取证。

检查规则：
- 不判断自己运行在 OpenClaw、Hermes 还是其他宿主；不要读取或推断宿主专属配置路径。
- 发起一次低成本、低歧义的 `web_search` 探测，只需要确认工具能返回正常搜索结果。
- 探测成功且返回非空结果即可继续。
- 探测失败、工具不存在、返回缺 key、provider 未就绪、服务不可达、search disabled、权限不足或结果为空时，停止流程并提示用户配置当前宿主的 `web_search`。

```text
sn-deep-research 需要当前会话的 web_search 可用，但通用探测未通过。

请先按当前智能体宿主的文档配置 web_search provider、key / secret 与工具开关。
配置后重启或刷新智能体会话，再重新发起 sn-deep-research。
```

## 第一性原理

深度研究不能缺少的只有 5 个阶段：

1. **记录请求**：保留原始需求、约束、日期、上下文和执行假设，作为全流程锚点。
2. **规划研究**：把需求转成 `plan.json`，完成定界、维度拆解、报告形态设想、搜索策略和完成标准。
3. **分维度取证**：逐个维度做多轮检索、筛选证据、交叉验证，并落盘为子报告。
4. **综合判断**：把分散子报告提炼成能回答原始问题的主线判断、冲突解释和不确定性。
5. **生成终稿**：把综合判断转成面向读者的 `report.md`，而不是机械拼接子报告。

辅助动作可以精简，但不能跳过上述阶段。

## 产物链

```text
request.md
-> plan.json
-> sub_reports/*.md
-> synthesis.md
-> report.md
```

所有阶段都必须写入文件，并在进入下一阶段前再次读取确认文件存在、非空且结构完整。只在对话中说明进展不算完成。

## 目录规则

`report_dir`:

```text
{workspace}/reports/{YYYY-MM-DD}-{topic_slug}-{hex4}/
```

- `topic_slug`：保留汉字、字母、数字、短横线；其他字符替换为 `-`；合并连续 `-`；截断到 40 个字符；去掉首尾 `-`
- `hex4`：用 `exec` 运行 `openssl rand -hex 2`
- 初始化时创建 `sub_reports/`、`images/`
- 阶段文件一律使用绝对路径
- 若用户要求继续已有项目，优先复用现有 `report_dir`，不要新建平行目录

## 阶段协议

在对应阶段读取并遵循下列方法 skill。它们是执行方法，不是后台任务。

| 阶段 | 使用 skill | 主要产物 |
|---|---|---|
| 0 初始化 | 无 | `request.md` |
| 1 规划 | `sn-research-planning`，必要时辅以 `sn-report-format-discovery` | `plan.json` |
| 2 取证 | `sn-dimension-research` | `sub_reports/{dimension_id}.md`、更新后的 `plan.json` |
| 3 综合 | `sn-research-synthesis` | `synthesis.md` |
| 4 成稿 | `sn-research-report` | `report.md` |

## 执行流程

### 0. 初始化

创建 `report_dir` 与子目录。写入 `request.md`，至少包含：

- 用户原始需求
- 当前日期
- 工作目录
- 已知约束
- 目标用途或目标读者
- 澄清记录
- 当前执行假设

如果关键歧义会改变研究对象、时间范围、地域范围或交付形式，先问最多 3 个问题；如果用户暂不回答，就记录合理假设并继续。

### 1. 规划：Plan

读取 `sn-research-planning`，生成 `plan.json`。

规划阶段必须一次性完成：

- 明确研究目标、范围边界、受众/用途、时间/地域和关键假设
- 设定终稿结构建议，以及必须产出的表格、图、比较项或清单
- 把研究拆成可执行维度；普通研究控制在 3-5 个维度，复杂研究最多 8 个维度
- 为每个维度定义 `key_questions`、`method`、`search_strategy`、`expected_output`、`depends_on`、`status`
- 明确 `completion_criteria` 和 `execution_order`

当你不确定“这类报告应该长什么样”时，先读取 `sn-report-format-discovery`，为 `plan.json.report_shape` 提供结构依据；但不要把格式研究扩张成正文事实研究。

进入下一阶段前确认：

- `plan.json` 存在且非空
- `execution_order` 覆盖全部维度
- 每个维度都有可执行的搜索策略和停止条件
- `report_shape` 足以约束最终成稿

### 2. 取证：Dimension Research

按 `plan.json.execution_order` 逐个处理 `status != done` 的维度。每个维度都要读取 `sn-dimension-research`。

每个维度完成后必须确认：

- `sub_reports/{dimension_id}.md` 已写入且非空
- 子报告回答、部分回答或明确标注了每个 `key_questions`
- 子报告包含精简证据记录、充分性判断、不确定性与空白
- `plan.json` 中该维度 `status` 已更新为 `done`

不要把报告章节直接当维度来写，也不要凭单轮搜索或少量材料直接成文。

### 3. 研究中调整：Plan Maintenance

每完成 2-3 个维度，快速检查一次：

- 当前材料是否仍然能回答原始问题
- 当前维度集合是否足以支撑 `plan.json.report_shape`
- 是否出现了需要新增、合并、拆分、删除或重排的维度

只有确有必要时才调整 `plan.json`，并把原因写入 `plan.json.change_notes`。不要因为局部搜索不顺就频繁改计划。

### 4. 综合：Synthesis

当全部必要维度完成后，读取 `sn-research-synthesis` 生成 `synthesis.md`。

综合阶段必须完成：

- 回答原始问题，而不是只总结材料
- 提炼 2-5 条主线判断
- 标明每条主线的证据强弱和成立条件
- 汇总跨维度共识
- 解释关键冲突来自哪里
- 明确保留不确定性、信息缺口和可能推翻结论的条件
- 给终稿提供写作主线和章节分配建议

如果发现关键缺口导致主线无法成立，回到对应维度补研究，再重新综合。没有 `synthesis.md` 时，不要直接进入终稿阶段。

### 5. 成稿：Report

读取 `sn-research-report`，基于 `request.md`、`plan.json`、`synthesis.md` 和全部子报告生成 `report.md`。

终稿必须：

- 按 `plan.json.report_shape` 或其合理修订版组织
- 以 `synthesis.md` 的判断层为主线，而不是把子报告顺序拼接
- 处理跨维度共识、冲突、条件和不确定性
- 面向目标读者完成表达，而不是保留内部研究痕迹

若写作时发现仍有关键事实缺口，回到对应维度补研究或重做综合，而不是硬写。

### 6. 交付

交付前重新读取并确认 `report.md` 存在且非空。

回复用户时至少提供：

- `report_dir` 的绝对路径
- `report.md` 的绝对路径
- 必要时附一段简短摘要或说明仍存在哪些不确定性

## 阶段切换规则

只有在当前阶段产物已落盘并通过最基本检查后，才能进入下一阶段。

- 没有 `request.md`：不能开始规划
- 没有有效 `plan.json`：不能开始分维度取证
- 任一必要维度未完成：不能开始综合
- 没有 `synthesis.md`：不能开始终稿生成
- `report.md` 为空或结构明显缺失：不能宣称完成

## 续跑规则

如果用户要求继续已有研究，先检查 `report_dir`，从最早缺失或未完成的阶段恢复：

- 无 `request.md`：从初始化开始
- 有 `request.md` 无 `plan.json`：从规划开始
- 有 `plan.json` 但仍有 `status != done` 的维度：从第一个未完成维度继续
- 全部必要维度完成但无 `synthesis.md`：从综合开始
- 有 `synthesis.md` 但无 `report.md`：从成稿开始
- 有 `report.md`：直接交付；若用户要求补充或修订，判断需要回到综合还是某个维度

继续时不要重建目录，也不要覆盖无关阶段文件；只有在你明确正在修订该阶段时才更新对应产物。

## 质量守门

- 任何阶段文件缺失、为空、格式无效或明显不完整时，先补该阶段。
- 涉及最新信息、政策、市场、产品、人物、价格、法律、监管等，必须联网核查并明确时间范围。
- 高风险判断优先追溯原始来源，并做多源交叉确认；无法确认时显式写入不确定性。
- `plan.json` 必须能独立承担定界、执行地图和终稿形态约束。
- `sub_reports/*.md` 必须保留精简证据记录，而不是只写结论。
- `synthesis.md` 必须形成判断层，而不是维度摘要合集。
- `report.md` 必须做跨维度综合，而不是子报告拼接。
- 不写脚注、文末参考文献或来源编号后处理；来源追踪保留在子报告证据记录中。

## 禁止事项

- 不跳过 `synthesis.md` 直接从子报告写最终报告。
- 不把报告章节直接当研究维度。
- 不跳过维度搜索策略、充分性判断和交叉验证。
- 不把缺口包装成确定结论。
- 不把阶段产物只写在对话里。
- 不为了追求流程完整而保留无意义文件；每个产物都必须承担明确职责。