---
name: Deep Research
slug: deep-research-18
category: AI Engineering
description: Deep Research structures a Claude Code research run around primary sources, comparison, validation, and a single final report. Use it when you need a defensible judgment instead of a source roundup.
github: "https://github.com/SeanEllyJames/deep-research-skill"
stars: 201
forks: 0
install: "npx degit https://github.com/SeanEllyJames/deep-research-skill ~/.claude/skills/deep-research-skill"
installs_to: ~/.claude/skills/deep-research-skill
source_path: SKILL.md
collection_size: 1
category_size: 3101
added: 2026-09-05T05:30:52.584Z
last_synced: 2026-09-05T05:30:52.584Z
canonical_url: "https://dirskills.com/skills/deep-research-18"
---

# Deep Research

Deep Research structures a Claude Code research run around primary sources, comparison, validation, and a single final report. Use it when you need a defensible judgment instead of a source roundup.

**Install:**

```bash
npx degit https://github.com/SeanEllyJames/deep-research-skill ~/.claude/skills/deep-research-skill
```

## README

# 深度调研工作流

> 🚦 **硬上限：任意时刻并行 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 的情况：直接引用他人原话或观点；任何数字/统计/评分；正面或负面评价的出处；产品/课程/公司的官方描述。

格式：
```markdown
**来源描述**（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 中强调"深度"、"具体"、"原文" |
| 中间文件堆积 | 只生成一个最终报告，不保存中间结果 |
| 跳过 Phase 0 | 主 agent 必须先写出假设和"好答案标准"再派 subagent |
| subagent 结构 = 报告结构 | 打散 subagent 返回结果，按论证链重组 |
| 表格驱动代替思考驱动 | 表格只放参考数据，论证全用段落 |
| 子 agent 递归派 agent | 子 agent prompt 里禁止使用 Agent 工具；平台层硬限流每会话派发次数 |