返回 Skill 列表
extension
分类: 开发与工程无需 API Key

sn-deep-research

深度调研编排器,覆盖 规划→分维度取证→综合→成稿(report.md)全流程,产物落盘到 report_dir,支持断点续跑;启动前必须用一次极小的通用 web_search 探测确认当前会话搜索能力可用,探测失败或无法确认时停止并提示用户配置。**遇到以下任一情况就主动使用本 skill,不要自行搜几条就回答**:①用户出现触发词:深度研究 / 深度调研 / 深入研究 / 全面研究 / 系统研究 / 调研 / 调查 / 尽调 / 行业研究 / 市场研究 / 竞品分析 / 政策研究 / 技术研究 / 趋势研究 / 事实核查 / 写一份研究报告 / 调研报告 / 深度报告 / research / deep research;②请求需要跨多来源取证、多维度对比、交叉验证才能给出可靠结论;③用户要求产出报告、白皮书、行业分析或尽调文档;④话题涉及最新政策/市场/产品/价格/法规,需要系统核查。模糊或宽泛的"研究/了解一下 X"也优先触发。仅不用于:单点事实问答("X 是什么")、一句话摘要、已给定单一来源的整理、纯文字润色改写。

person作者: gaclovehubgithub

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
sn-deep-research 需要当前会话的 web_search 可用,但通用探测未通过。

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

第一性原理

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

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

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

产物链

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

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

目录规则

report_dir:

{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_questionsmethodsearch_strategyexpected_outputdepends_onstatus
  • 明确 completion_criteriaexecution_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.mdplan.jsonsynthesis.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.mdplan.json:从规划开始
  • plan.json 但仍有 status != done 的维度:从第一个未完成维度继续
  • 全部必要维度完成但无 synthesis.md:从综合开始
  • synthesis.md 但无 report.md:从成稿开始
  • report.md:直接交付;若用户要求补充或修订,判断需要回到综合还是某个维度

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

质量守门

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

禁止事项

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