Skip to content
Research
Skill

/deep-research-skill

🚦 **硬上限:任意时刻并行 subagent ≤7 个。** 维度多就分批,不要抬高上限。**子 agent 禁止再派子 agent**——递归 fan-out 是最烧钱的失败模式(见错误 6)。如果你的平台自带一个 fan-out 到几十个 agent 的"deep research"模式,不要用它,用本流程做受控并行。

BOOST
From plugin
deep-research-skill
1871 skill
Install
$ npx -y skills add SeanEllyJames/deep-research-skill --skill deep-research-skill --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/deep-research-skill

Context preview

The summary Claude sees to decide when to auto-load this skill.

🚦 **硬上限:任意时刻并行 subagent ≤7 个。** 维度多就分批,不要抬高上限。**子 agent 禁止再派子 agent**——递归 fan-out 是最烧钱的失败模式(见错误 6)。如果你的平台自带一个 fan-out 到几十个 agent 的"deep research"模式,不要用它,用本流程做受控并行。

SKILL.md

deep-research-skill.SKILL.md

深度调研工作流

> 🚦 **硬上限:任意时刻并行 subagent ≤7 个。** 维度多就分批,不要抬高上限。**子 agent 禁止再派子 agent**——递归 fan-out 是最烧钱的失败模式(见错误 6)。如果你的平台自带一个 fan-out 到几十个 agent 的"deep research"模式,不要用它,用本流程做受控并行。

元数据

  • **类型**: Workflow
  • **适用场景**: 需要对某个主题进行深度、全面、可验证的第三方调研,并且你要的是一个"判断",不是一份综述
  • **输出位置**: 你指定的一个输出目录

核心原则

1. **一手源优先**: 先找原始文献(官方公告、技术论文、创始人博文、财报电话会议),精读后再做广度搜索。二手信息层层转手会蒸发洞见 2. **论点驱动**: 报告的结构是论证链(观察 → 分析 → 判断),不是主题分类(市场 → 竞争 → 趋势)。每一章推进一个论点,前后有逻辑递进 3. **交叉对比**: 选 2-3 个核心案例做深度对比,找收敛点和分歧点。收敛本身就是洞见,分歧背后的原因更是洞见 4. **标注不确定性**: 诚实区分"确定知道的"、"合理推断的"、"不确定的"。过于确定的结论是分析不严谨的信号 5. **可追溯性**: 所有引用必须保留 URL,关键引用保留原文摘录 6. **单一交付**: 最终只交付一个汇总报告,中间结果不保存

关键区分:Wide Research vs Deep Research

Wide Research(信息搬运):搜索多个来源 → 按主题分类摆放 → 输出 checklist。这是 LLM 的默认模式,产出的是"正确的废话"。

Deep Research(分析):精读一手源 → 提炼矛盾和张力 → 用分析框架产出独特判断。深度来自认知维度(你用什么框架看问题),不是信息维度(你覆盖了多少个角度)。

本 workflow 的目标是后者。

模型分工策略

调研 subagent(Phase 1/2 的信息搜索、抓取、摘要)使用便宜/快速的模型。这类任务判断密度低、信息密度高,小模型质量持平且成本低得多。

主 agent 保持最强模型执行 Phase 0(元思考)、Phase 3(交叉验证)、Phase 4(写作)。这些步骤需要综合判断力。

搜索工具选择规则

所有搜索和网页抓取操作,无论主 agent 还是 subagent,遵循以下优先级:

1. **首选专用搜索/抓取工具**(如 Tavily 这类搜索 MCP,或等价工具):返回内容更干净、更完整 2. **降级条件**:仅当首选工具不可用(连接失败、工具未加载、返回错误)时,才切换到内置 WebSearch / WebFetch 3. **降级时必须告知**:切换到备选工具时说明原因

---

工作流程

Phase 0: 元思考与框架对齐(主 agent 执行,不委派)

**目标**: 质疑问题本身,定义"好答案"的标准,确定分析视角

**Step 0a: 质疑问题**。动手搜索之前,先回答三个问题: 1. 用户为什么要问这个?背后的隐藏假设是什么?这些假设是否合理? 2. 如果突破这些假设,能否问出更好的问题?(例如:"A 收购 B 意味着什么",更好的问题可能是"为什么 A 必须在此刻用这种方式收购 B,而不是别的选项") 3. 这个问题有没有一个"显而易见但其实不对"的标准答案?如果有,这篇报告的价值就在于说清楚它为什么不对

**Step 0b: 定义好答案的标准**。明确写出这篇报告要满足什么条件才算"好",通常包括:

  • 读者读完后获得了至少一个此前没有的判断(不是信息,是判断)
  • 核心论点如果放到一群业内人面前,至少会引发争论(而非所有人点头说"没错")
  • 有明确的"我不知道什么"部分,诚实标注盲区

**Step 0c: 框架选择与假设形成** 1. 明确调研的核心问题(不是"主题",是"问题") 2. 选择 1-2 个分析框架,例如:价值链分析、Porter's Five Forces、技术采纳曲线、Jobs-to-be-Done、类比推理(历史上最相似的案例是什么,结局如何)、反事实分析 3. 形成 2-3 个待验证的假设/论点,其中至少一个应该是反直觉的

**输出**: 分析框架、初始假设、"好答案的标准"(在内存中,用于指导后续 agent prompt 和最终报告自检)

Phase 1: 一手源精读

**目标**: 找到 3-5 篇最重要的原始文献,提炼核心论点和矛盾

1. 启动 1-2 个 subagent(便宜模型),专门寻找和精读一手源:官方公告、新闻发布会原文、财报电话会议记录、创始人/CEO 的博客或采访原文、技术论文、产品文档、权威分析师的原始报告(不是媒体转述) 2. 每个 subagent 的 prompt 必须强调:

  • **找原文,不要找别人对原文的总结**
  • 完整阅读每篇源文献,提取:核心论点、关键数据、内部矛盾、未说的东西(沉默本身是信号)
  • 注意作者的立场和利益关系(CEO 说自家产品好不算证据)

这一步的目标不是广度覆盖,而是对少数源文献的深度理解。

**每个调研类 subagent 的 prompt 末尾必须附加的搜索工具指令:**

## 搜索工具规则(硬性约束,违反即失败)
搜索和抓取必须优先使用专用搜索/抓取工具(搜索 MCP 或等价工具)。
只有首选工具不可用(连接失败或工具未加载)时才降级到 WebSearch/WebFetch。
降级时说明原因。

Phase 2: 对比分析与广度补充

**目标**: 通过对比产生洞见,用广度搜索补充数据和反例

1. 基于 Phase 1 的发现,启动 2-3 个 subagent(便宜模型):

  • **对比 agent**: 选 2-3 个最有代表性的案例做深度对比。他们的选择为什么不同?背后反映了什么假设的分歧?
  • **反例 agent**: 专门寻找反面证据、失败案例、批评观点。搜索关键词加 "criticism"、"failure"、"problem"、"why not"
  • **数据 agent**: 补充定量数据(市场规模、融资、用户量等),但数据服务于论点,不是论点服务于数据

2. 维度之间保持 ≥50% 的 overlap,让不同 agent 发现同一信息的不同解读

每个 subagent 的 prompt 必须包含:Phase 0 确定的分析框架和假设;明确的对比维度或反例搜索方向;要求返回 URL 和原文摘录(不是总结);**不需要**将结果写入文件,只需返回给主 agent。

Phase 3: 整合、交叉验证与论点构建(主 agent 执行)

**目标**: 从原始材料中构建论证链,发现矛盾,形成独特判断

1. 对比各 subagent 返回的结果:多个 agent 都发现的信息 → 可信度高;只有单一来源 → 标注来源,提醒验证;互相矛盾的信息 → 特别标注,**分析矛盾本身意味着什么** 2. 回到 Phase 0 的假设,逐一验证:被确认(用什么证据)?被推翻(为什么,推翻本身是否产生新洞见)?无法判断(诚实标注)? 3. 构建论证链:观察 → 分析 → 判断 → 局限性 4. 如果发现重大矛盾或信息缺口,可以再启动 subagent 针对性验证

Phase 4: 撰写最终报告(主 agent 执行,不委派)

**写作原则**:

  • **论点驱动结构**: 每章推进一个论点,不是罗列一个主题。读者读完每章应该获得一个判断,不只是一堆信息
  • **段落论证为主**: 用自然语言段落展开论证,少用表格和 bullet points。表格用于速查数据,不用于传递洞见
  • **交叉对比产出洞见**: "A 和 B 从不同方向出发,收敛到了同一个结论"比"A 做了 X,B 做了 Y"有价值得多
  • **诚实标注局限**: 明确说出"这篇报告没有覆盖什么"、"哪些结论的确定性较低"、"哪些假设可能有问题"
  • **原文引用**: 关键论据引用原文,不要只给总结。让读者能验证你的解读是否准确
  • **不做投行路演 deck**: 不需要每个结论都乐观。如实呈现利好和风险,让读者自己判断
  • **反直觉优先**: 如果一个结论所有人都同意,花更多笔墨在"为什么这个共识可能错"上
  • **写给聪明的外行**: 技术细节服务于判断,不是炫技。一个好的类比比三段参数对比更有力
  • **回扣 Phase 0 的标准**: 写完后用 Phase 0b 定义的"好答案标准"自检。如果核心论点放到业内不会引发任何争论,重写

**格式要求**:

  • Markdown
  • 所有引用必须有 URL,关键引用保留原文摘录
  • **报告末尾必须附"信息源"章节**:集中列出本报告引用的所有原始链接,按引用顺序排列,每条包含来源标题/描述 + URL。这是报告的必要组成部分,不可省略

**重要**: 只生成一个最终报告文件;撰写必须由主 agent 完成(sub-agent 缺乏整体论证的上下文);不保存中间结果。

URL 留存规范

必须保留 URL 的情况:直接引用他人原话或观点;任何数字/统计/评分;正面或负面评价的出处;产品/课程/公司的官方描述。

格式:

**来源描述**(URL)
> 原文摘录

避免:"有人评价说..."(没有 URL)、"网上有文章批评..."(没有 URL)、只总结不引用原文(无法验证)。

---

执行纪律:最容易偷懒的地方

以下是实际执行中反复犯的错误。每次启动调研前,先检查自己有没有在犯这些错。

错误 1:跳过 Phase 0 直接派 subagent 搜索

最常见、最致命。跳过元思考意味着 subagent 在没有假设引导的情况下做广度搜索,返回的是信息碎片而非论证素材。正确做法:主 agent 先独立思考,写出假设和"好答案标准",然后带着这些假设去设计 subagent 的 prompt。

检测信号:如果你的 subagent prompt 里没有包含"假设"或"待验证的论点",说明你跳过了 Phase 0。

错误 2:用 subagent 的返回结构当报告骨架

subagent 返回的信息按搜索维度组织(功能、定价、用户评价),直接沿用这个结构写报告,产出的一定是主题分类式的信息汇总。正确做法:把 subagent 返回的所有信息打散,重新按论证链组织。报告的每一章推进一个论点,信息只是论点的证据。

检测信号:如果报告的章节标题可以直接用作搜索关键词("定价对比"、"功能对比"、"适合谁"),结构大概率是信息分类而非论证链。好的章节标题应该包含判断("能力趋同之后,竞争的新维度是什么")。

错误 3:用表格和 bullet points 替代思考

表格是速查工具,不是论证工具。如果一个洞见可以用表格传递,那它大概率不是真正的洞见。正确做法:表格只用于读者需要反复查阅的参考数据(定价、参数),论证部分全部用段落展开。

检测信号:如果删掉报告中所有表格和 bullet points 之后,剩下的段落不能独立成文,说明思考量不够。

错误 4:结论太安全

"A 适合 X 人群,B 适合 Y 人群"这种结论任何人都能说,不需要调研就知道。报告的价值在于给出读者此前没有的判断,这意味着结论必须有被反驳的可能性。

检测信号:把你的核心结论发到一个相关领域的专业群里,如果没有人会出来反驳或讨论,这个结论太安全了。

错误 5:把"全面"当成"深度"

覆盖 10 个维度每个维度 3 句话,不如深入 3 个维度每个维度 3 段论证。深度来自认知维度(你用什么框架看问题),不是信息维度(你覆盖了多少个角度)。

检测信号:如果报告超过 5000 字但核心论点可以用 3 句话总结,大概率是广度过多、深度不足。

错误 6:子 agent 递归 fan-out

一次真实事故:主 agent 派 3 个 agent → 这 3 个拆成 13 个 → 13 个拆成 50+ → 最终 149 个 agent,一笔意外的 API 账单。子 agent 拿到宽泛的研究命题后,会自然地继续拆维度、继续派 agent,形成递归爆炸。

检测信号:如果你发现自己在给子 agent 的 prompt 里写了"你可以用 Agent 工具进一步搜索"之类的话,stop。马上要炸。

正确做法:

  • **子 agent 只做搜索和摘要,不派孙 agent**。在子 agent prompt 里明确写清楚
  • 主 agent 自己控制并行度,需要更多维度时主 agent 亲自分批
  • 有条件的话在平台层做硬限流(如 PreToolUse hook 限制每会话 agent 派发次数)。但不要依赖限流兜底——设计层面就该避免递归

写作自检清单(Phase 4 完成后执行)

1. 删掉所有表格和 bullet points 后,剩余段落能否独立成文? 2. 每章标题是否包含判断(而非主题词)? 3. 核心结论是否有被反驳的可能性? 4. 是否有至少一个反直觉的发现或判断? 5. 是否明确写出了"我不知道什么"? 6. 引用的一手源是否被精读过(而非只提取了标题和摘要)? 7. 报告结构是否可以用"因为 X → 所以 Y → 这意味着 Z"的链条串联?

如果有 3 条以上不通过,报告需要重写核心论证部分。

陷阱与对策

| 陷阱 | 对策 | |-----|------| | 只搜到正面信息 | 专门搜索 "criticism", "negative review", "scam", "overpriced" | | 信息来源单一 | 强制要求 subagent 找多个独立来源 | | 过度总结丢失细节 | 要求保留原文摘录,不只是总结 | | 维度划分太干净没有 overlap | 设计维度时故意让边缘模糊 | | Subagent 返回的信息太浅 | 在 prompt 中强调"深

Read more
Ships withdeep-research-skill

逼 AI Agent 做「会下判断」的调研,而不是「会摆信息」的调研。     市面上绝大多数所谓的「AI 深度调研」,本质是 Wide Research:并行搜一堆来源,按主题分好类,给你一份工整的 checklist。看起来很全,事实也没错,但没用——它只有目录,没有判断。 这个 skill 把 Agent 掰到另一条路上:Deep Research。精读一手源,把它们之间的矛盾挑出来,最后落到一个业内人真的会跟你争论的判断上。

Get the whole plugin
Stats
187
Stars
0
Forks
Maintained
Maintenance
2mo ago
Last commit
2mo ago
Created
4d ago
Added

Repo: SeanEllyJames/deep-research-skill