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