Deep Research（深度调研编排工作流）

把"深度调研"当作一个可复用、可并行的生产流程来执行：主控负责澄清目标、拆解子目标、调度子进程、聚合与精修；子进程负责采集/抽取/局部分析并输出结构化 Markdown 素材；最终交付物必须是独立成品文件而不是聊天贴文。

关键约束（必须遵守）

• 保持默认模型与配置不变：不要显式覆盖模型或用额外参数覆写默认模型/推理设置；只有在用户明确授权时才调整相关配置。
• 默认最小权限：子进程通过 --allowedTools 控制可用工具；仅在必要时启用网络等权限。
• 联网优先走 skills，其次 MCP：优先使用已安装 skills；若必须使用 MCP，则优先 firecrawl，其次 exa；确实无法满足时再考虑 WebFetch/WebSearch。
• 非交互式友好：子进程不使用 plan 工具，不与用户"等确认/等反馈"式互动；以文件落地、日志可追溯为主。
• 文件交付优先：最终交付物必须落地为独立文件，禁止在聊天中贴出完整成稿。
• 每一步输出决策与进度日志：尤其在拆分、调度、聚合、精修、交付前。
• 任务规模判断门槛：子目标数量 ≥3 时必须启动 claude -p 子进程；<3 个子目标时可由主进程直接执行，但仍需记录完整目录结构和原始数据。
• 必须等待用户确认：摸底完成后，必须明确询问用户"是否开始执行？"，在用户回复"执行/开始/go/yes"等肯定词前不得进入下一步。

任务目标

1. 从用户的高层目标推导出可并行的子目标集合（如链接清单、数据分片、模块列表、时间切片等）。
2. 为每个子目标启动独立的 claude -p 子进程，并为其分配合适权限（通过 --allowedTools 参数）。
3. 并行执行并产出子报告（自然语言 Markdown，可含小节/表格/列表）；失败时输出带原因的错误说明与后续建议。
4. 用脚本按顺序聚合子输出，生成统一的基础稿。
5. 对基础稿做理智检查与最小化修复，然后给出最终 artefact 路径与关键发现摘要。

交付标准

• 交付物必须是结构化、洞察驱动的整体成品；禁止把子任务 Markdown 直接拼接当作最终稿。
• 需要保留子任务原文时，将其另存为内部文件（例如 .research/<name>/aggregated_raw.md），在成品中仅吸收关键洞察/证据。
• 润色与修订要按章节逐段迭代，不得整篇删除后一次性重写；每次修改后核对引用、数据与上下文，保证可追溯。
• 默认交付详实、深入的分析型报告。
• 交付前做"双重体检质检"：
  1. 检查是否真的是"分章节、多轮整合"产出；若只是一次性生成，退回按章节重写。
  2. 评估是否足够细致；若偏单薄，先判断是"子任务素材不足"还是"统稿时压缩过度"：前者驱动补充/追加调研，后者在既有素材上继续扩展润色，直至达到详细标准。

任务规模分级与执行路径

根据子目标数量选择执行路径：

注意：即使是微型任务，也必须：

1. 将原始搜索结果保存到 raw/ 目录
2. 记录执行日志到 logs/dispatcher.log
3. 等待用户确认后再执行（除非用户明确说"直接执行"）

端到端流程（严格按序执行）

0. 预执行规划与摸底（必做；主控亲自完成）

   • 先澄清目标、风险、资源/权限约束，并识别后续扩散依赖的核心维度（主题簇、人物/组织、地域、时间切片等）。
   • 若存在公开目录/索引（标签页、API 列表等），用最小化方式抓取缓存并统计条目；若不存在，做"案头调研"获取真实样本（新闻、资料、数据集等），记录来源/时间/要点作为证据。
   • 形成清单前至少展示一次真实检索或浏览的代表样本；只靠经验推测不算完成摸底。
   • 摸底阶段必须至少通过一次"可追溯的工具链"拿到真实样本并记录引用：优先使用已安装 skills；若需要 MCP，则优先 firecrawl，其次 exa；若都不可用，记录原因并选择替代方案（必要时再降级到 WebFetch/WebSearch）。
   • 输出初步（或草拟）清单：列出发现的维度、各维度已掌握的选项及样本、规模估算，并标注不确定性/缺口。若尚未获得真实样本，先补齐调研，禁止进入下一步。
   • 依据上述结构补全可执行计划（拆分、脚本/工具、输出格式、权限、超时策略等），用用户语言汇报维度统计与计划内容；在得到明确"执行/开始"回应前保持等待。

1. 初始化与总体规划

   • 明确目标、预期输出格式与评价标准。
   • 根据当前任务生成一个语义化且不重复的名字 name（建议：<YYYYMMDD>-<短题>-<随机后缀>，全小写、短横线分隔、无空格）。
   • 创建运行目录 .research/<name>/，并把所有产物都保存到该目录下（子目录如 prompts/、logs/、child_outputs/、raw/、cache/、tmp/）。
   • 保持默认模型与配置不变；需要调整任何模型/推理/权限相关设置时先征得用户同意，并在日志中注明变更原因与影响范围。

2. 子目标识别

   • 通过脚本/命令提取或构造子目标列表。
   • 源数据不足时（例如页面只给两个主链接），如实记录原因，然后由主进程直接接手完成剩余工作。