深
深入研究
作者：鹿Sir学术研究v5
对技术主题进行系统的深入研究，通过来源验证、三角测量和引用支持生成研究报告。当用户需要深入调研、技术分析、方案对比、趋势研判时触发。触发词：深入研究、调研、技术分析报告。
下载量
264
点赞
66
价格
免费
技能文档
---
name: deep-research
title: 深入研究
category: 学术研究
description: 对技术主题进行系统的深入研究，通过来源验证、三角测量和引用支持生成研究报告。当用户需要深入调研、技术分析、方案对比、趋势研判时触发。触发词：深入研究、调研、技术分析报告。
---
# 深入研究
## 核心目标
通过结构化的多阶段流水线，交付有引用支撑、经过验证的研究报告。每个事实性声明都必须可追溯到来源。
**自主原则：** 独立执行检索与综合，无需用户中途确认。
> **关键 — Phase 0 为必选步骤。** 你对用户的**首次回复**必须基于歧义分析（Phase 0）提出澄清问题。在用户回答之前，不要执行任何搜索、启动子代理或开始 Phase 1。跳过 Phase 0 是本技能最常见的失败模式。即使提示词很精确，也要在开始前确认你的假设。
Phase 0 之后**不再暂停**：所有后续阶段（1 至 5）**连续执行**。在输出中展示研究计划（Phase 1）以保证透明度，但不要等待确认 — 直接进入检索阶段。
---
## 决策树
```
收到请求
├── 简单查询（1-2 次搜索即可）？ → 停止：使用常规 WebSearch
├── 调试 / 代码修复？ → 停止：使用标准代理模式
└── 需要复杂分析？ → 继续 ↓
深度选择
├── 标准 → 2-3 个子代理，约 4,000 字，阶段 0-1-2-3-[QG]-3.1-3.5-4-5 [默认]
└── 深度 → 4-6 个子代理，6,000+ 字，阶段 0-1-2-3-[QG]-2-3-3.1-3.5-4-5
[QG] = 质量门禁：如来源目标已达成则跳过下一轮
```
如用户未指定深度，默认为**标准**。
---
## 代理架构
本技能使用**主代理 / 子代理**模式。主代理编排整个流水线；子代理负责检索、验证和（深度模式下）综合。每个阶段都有明确的负责方。
### 代理角色
| 角色 | 代理 | 职责 |
|------|------|------|
| **编排者** | 主代理 | 澄清、定范围、规划、三角验证、批判审查、撰写报告 |
| **检索** | 子代理（角色 1） | 在分配的关键领域广泛搜索（Wave 1） |
| **补缺** | 子代理（角色 2） | 针对特定证据缺口的定向搜索（Wave 2+） |
| **验证** | 子代理（角色 3） | 引用抽查：来源是否支持其声明？ |
| **综合** | 子代理（角色 4） | 起草领域摘要并附引用（仅深度模式） |
### 各阶段代理分配
| 阶段 | 标准模式 | 深度模式 |
|------|----------|----------|
| 0 澄清 | 主代理 | 主代理 |
| 1 定范围 | 主代理 | 主代理 |
| 2 检索（Wave 1） | 2-3 个检索子代理 | 4 个检索子代理 |
| 2b 检索（Wave 2+） | 1 个补缺子代理 | 1-2 个补缺子代理 |
| 3 三角验证 | 主代理 | 主代理 |
| 3.1 引用检查 | 1 个验证子代理 | 1 个验证子代理 |
| 3.5 大纲优化 | 主代理 | 主代理 |
| 4 批判审查 | 主代理 | 主代理 |
| 5 撰写报告 | 主代理 | 主代理（1 个综合子代理协助） |
**关键设计决策：**
- **验证代理在标准和深度模式下均作为子代理运行**，为主代理释放工具调用预算用于协调和写作。
- **补缺代理**比通用检索代理有更精确的提示词 — 它知道缺少什么并定向搜索。
- **深度模式**下，综合代理在主代理撰写最终报告前预起草领域摘要。这减少了主代理的综合负担并产生更一致的交叉引用。
- 主代理**在 Phase 2 中绝不运行 WebSearch/WebFetch**。所有检索都委派给子代理，以便主代理保留工具调用预算用于 Phase 3-5。
### 子代理模型选择
检索（角色 1）和补缺（角色 2）子代理使用 `model: "fast"` — 它们只需搜索和提取，无需深度推理。这可降低成本和延迟。验证（角色 3）和综合（角色 4）子代理使用默认模型（无 `model` 参数），因为它们需要谨慎判断。
### 来源可信度层级
子代理（检索 + 补缺）在提取时为每个来源标记可信度层级。这不需要额外的工具调用 — 代理已经读取了 URL、作者和内容。Phase 3 使用层级进行置信度分配。
| 层级 | 标签 | 示例 |
|------|------|------|
| **1** | 权威 | 同行评审期刊（arxiv、ACM、IEEE）、官方文档、知名研究实验室（Microsoft Research、Google Research）、公认行业权威（Fowler、Thoughtworks Radar、DORA/State of DevOps） |
| **2** | 可信 | 知名公司的工程博客（Netflix、Spotify、Airbnb 技术博客）、会议演讲（QCon、STAREAST、SeleniumConf）、有已发表记录的知名从业者 |
| **3** | 补充 | 个人博客、Medium 文章、Reddit/HN 讨论、厂商营销内容、无日期文章、无可识别作者的来源 |
**标记规则：** 来源列表中的每个来源获得 `Tier: 1/2/3` 标签。Phase 3 使用层级确定置信度：**`[High]` 需要至少一个 Tier 1 或 Tier 2 来源。仅三个 Tier 3 来源 = 最高 `[Medium]`。**
---
## 工具约束与子代理策略
单个代理轮次有有限的工具调用预算和有限的上下文窗口。**子代理绕过这些限制：** 每个子代理（通过 `Task` 工具生成）获得自己的工具预算和隔离上下文。通过在单条消息中发出多个 `Task` 调用来并行运行多个子代理。
### 子代理扩展
| 深度 | 子代理 | 有效工具调用 | 来源目标 |
|------|--------|--------------|----------|
| 标准 | 2-3 个并行 | ~75 | 15-25 |
| 深度 | 4 个并行 | ~100 | 30-50 |
### 工作流程
1. **Phase 0 + 1** 在**主代理**上运行（澄清、定范围、规划）。
2. **Phase 2** 将关键领域分配给**并行子代理**。每个子代理获得明确的任务说明：
- 分配的关键领域（如"领域 1-2"与"领域 3-4"）
- 与其领域相关的搜索词
- 返回带摘要的结构化来源列表的指令
3. 主代理**收集**子代理结果，去重来源，执行 Phase 3（三角验证），识别空白。
4. 如仍有空白，启动**第二轮**补缺子代理填补。
5. **Phase 3.1** 将引用抽查委派给验证子代理。
6. **Phase 5**（撰写）在主代理上运行。深度模式下，综合子代理先预起草领域摘要。
> 子代理提示词模板详见 → [references/subagent-prompts.md](references/subagent-prompts.md)
---
## 各阶段
### 预阶段 — 上下文加载（始终执行）
开始新的研究运行前，执行两项检查：
**1. 研究上下文文件：**
先在项目根目录搜索 `RESEARCH_CONTEXT.md`。如未找到，对 `**/RESEARCH_CONTEXT.md` 执行一次 Glob 搜索。如存在则加载。此文件包含用户的持久研究偏好（如默认受众、常见约束、已知术语）。用它预填 Phase 0 各维度 — 仅询问上下文文件尚未回答的维度。
**2. 现有报告检查：**
使用 Glob 搜索 `DEEP_RESEARCH_*.md` 文件。
- 如找到匹配：通知用户，说明文件最后修改日期，询问是**更新**（以现有报告为基线，填补空白）还是**替换**（全新运行）。
- 如无匹配：进入 Phase 0。
### Phase 0 — 澄清（始终执行 — 必选的首次回复）
> **停止。** 在完成本阶段之前，不要调用 WebSearch、WebFetch 或 Task。你的第一条消息必须是澄清问题 — 别无其他。这是整个流水线中唯一的用户交互暂停点。
从五个维度分析用户查询的**歧义**。对于存在歧义的每个维度，生成**一个**澄清问题。跳过查询已经明确的维度。
| # | 维度 | 何时询问 | 示例问题 |
|---|------|----------|----------|
| 1 | **范围** | 主题边界可宽可窄 | "你指的是所有 QA 角色还是仅测试自动化？" |
| 2 | **目标** | 不清楚研究支持什么决策或交付物 | "这是决策依据还是知识积累？" |
| 3 | **受众** | 读者的技术深度未知 | "报告谁来读 — 你的团队、领导层还是外部？" |
| 4 | **约束** | 未说明的限制可能改变研究方向 | "有技术栈、预算或时间线要求吗？" |
| 5 | **假设** | 查询包含需要验证的隐含假设 | "你假设了 X — 我需要质疑还是作为前提接受？" |
**规则：**
- 生成 **1-5 个问题**（仅针对有歧义的维度）。
- 如五个维度都无歧义，说明你做了哪些假设并请求一次确认："我将范围理解为 X — 对吗？" 绝不跳过 Phase 0。
- 如在预阶段加载了 `RESEARCH_CONTEXT.md`，用它先解决已知维度再提问。
**展示问题并停止。等待回答后再继续。**
### Phase 1 — 定范围
1. 用一句话重述研究问题，纳入 Phase 0 的回答。
2. 将主题拆分为 **4-7 个关键领域**，每个领域 3-5 个子问题。
3. 起草 **10-15 个搜索词** — 变化：
- 语言（英文 + 中文或领域语言）
- 具体性（宽泛术语 + 精确术语）
- 时效标记（如"2025"、"2026"）
- **视角** — 每个关键领域至少包含一个批判或对立视角的搜索词（如"[技术] 批评"、"[方法] 失败案例"、"[工具] 替代方案对比"、"[概念] 风险 缺陷"）。这防止单方面检索。
4. 说明所选深度（标准 / 深度）。
5. **将关键领域分配给子代理** — 均匀分配领域，分配 START_INDEX 范围使来源编号不冲突（如子代理 A 从 [1] 开始，B 从 [20]，C 从 [40]）。
6. **在输出中展示计划**以保证透明度，然后**立即进入** Phase 2。不要等待用户确认。
### Phase 2 — 检索（并行子代理 + 迭代轮次）
**Wave 1：**
1. 将 Phase 1 的关键领域分配给 **2-4 个检索子代理**（各一个 Task 调用，在单条消息中启动以并行执行）。
2. 每个子代理获得：
- 其分配的关键领域 + 子问题
- Phase 1 计划中的相关搜索词
- 其 START_INDEX 用于来源编号
- 检索代理提示词模板（角色 1）
3. 等待所有子代理返回。
4. **合并结果**（见合并协议）。
5. 不暂停直接进入 Phase 3（三角验证）。
**Wave 2（如 Phase 3 后发现空白）：**
1. 启动 1-2 个**补缺子代理**（角色 2），仅针对薄弱领域。每个获得：具体空白、现有来源摘要和所需内容。
2. 将结果合并到主来源列表。
3. 再次执行 Phase 3。
**Wave 3（仅深度模式，如仍有空白）：**
1. 最后一轮补缺子代理处理剩余空白。
2. 最终合并 + 三角验证。
**所有轮次后的来源目标：**
| 深度 | 轮次 | 子代理总数 | 来源数 |
|------|------|------------|--------|
| 标准 | 1-2 | 2-4 | 15-25 |
| 深度 | 2-3 | 4-6 | 30-50 |
**搜索策略（适用于所有子代理）：**
- 交替使用宽泛和精确查询。
- 如搜索结果不佳，重新表述 — 不要重复相同查询。
- 对相关主题尝试中英文术语。
- 添加年份限定词（"2025"、"2026"）以查找近期内容。
- 追踪引用链：如来源引用了其他文献，直接搜索该文献。
- **深度 vs. 广度：** 如早期结果显示某子领域已有充分覆盖（3+ 个强来源），将剩余工具调用转向覆盖不足的领域。不要继续为已有高置信度证据的领域获取更多来源。
### Phase 3 — 三角验证（每轮检索后）
1. 对每个关键声明检查：是否有 **2+ 个独立来源**支持？
2. 使用来源数量和可信度层级分配**置信度**：
- `[High]` — 3+ 个独立来源一致，**至少包含 1 个 Tier 1 或 Tier 2 来源**
- `[Medium]` — 2 个来源一致（任意层级），或 1 个高度权威的 Tier 1 来源，或 3+ 个 Tier 3 来源一致（上限：不超过 Medium）
- `[Low]` — 仅单一来源，或仅 Tier 3 来源且少于 3 个
3. 应用**分层时效规则**：
- **趋势、工具、基准** — 严格 <18 个月。丢弃更旧的来源。
- **方法论基础**（如 Fowler、Google Testing Blog、Microsoft Research、开创性论文） — 不受年限限制。在来源列表中标记为 `[foundational]`。
- **中间层** — 如无更新来源覆盖同一声明，允许最多 36 个月。在报告中明确注明年限。
4. 记录来源间的矛盾 — 这些成为发现，而非错误。
5. 识别**薄弱领域**（任何关键领域来源 <2 或无 `[High]` 声明）→ 通过补缺子代理反馈到下一轮 Phase 2。
### 质量门禁（轮次之间）
每次三角验证后，检查是否需要下一轮检索：
```
所有关键领域都有 ≥2 个来源？
且来源目标已达成（标准 15+，深度 30+）？
且无关键领域整体为 [Low] 置信度？
且每个关键领域至少 1 个来源代表批判/对立视角？
→ 是：跳过剩余轮次，进入 Phase 3.1
→ 否：启动下一轮补缺子代理，仅针对薄弱领域
```
这防止在覆盖已充分时浪费工具调用。
### Phase 3.1 — 引用抽查（两种深度）
三角验证通过后，将引用验证委派给**验证子代理**（角色 3）。这释放主代理的工具调用预算，并捕捉深度研究系统最常见的失败模式（经实证测量，商业工具的引用准确率为 40-80%）。
1. 选择已收集证据中 **5-10 个最高影响力的声明** — 优先选择驱动报告主要结论的声明。
2. 将声明及其引用来源 URL/摘要发送给验证子代理。
3. 子代理返回验证表后，处理结果：
- **SUPPORTED** — 保持原样。
- **PARTIAL** — 重新表述声明以匹配证据内容。
- **UNSUPPORTED** — 启动一个补缺子代理为此声明寻找替代来源（最多 3 次 WebSearch + 2 次 WebFetch）。如未找到替代来源，降级为 `[Low]`。
4. 在最终报告的方法论附录中记录任何修正。
### Phase 3.5 — 大纲优化（两种深度）
三角验证完成后，将计划的报告结构（来自 Phase 1）与实际收集的证据进行对比：
1. **审查匹配度**：计划的章节是否与证据支持的内容匹配？
2. **按需调整**：
- 为意外但有充分证据的发现添加章节。
- 降级或合并证据不足的章节。
- 按证据强度和重要性重新排序。
3. **记录变更**：说明变更内容及原因（证据驱动，非推测性）。包含在最终报告的方法论附录中。
**护栏：**
- 调整必须由已收集的证据驱动。
- 不要添加没有支持来源的章节。
- 不要放弃原始研究问题 — 保持主题聚焦。
- 最大 50% 结构变更。如证据推动超过 50%：
1. **标准模式：** 在方法论中记录不匹配，在 50% 限制内应用最合适的结构，在开放问题中标记范围问题。
2. **深度模式：** **暂停并向用户展示**修订后的大纲及证据偏离原始范围的简要说明。询问是 (a) 按新重点继续，(b) 收窄回原始范围，还是 (c) 拆分为两份报告。这是 Phase 0 之外**唯一的额外用户检查点**。
### Phase 4 — 批判审查（两种深度）
在撰写最终报告前，对已收集证据进行自我批判，提出以下红队问题：
1. **缺少什么？** — 是否有代表性不足的视角、地域或来源类型（学术、行业、社区）？
2. **什么可能是错的？** — 哪些声明基于薄弱证据？来源和结论之间是否有逻辑跳跃？
3. **怀疑论者会怎么说？** — 如果有人不同意主要发现，他们最有力的论点是什么？
**如批判审查发现关键空白**（不仅是细微差别）：
- 启动 1 个补缺子代理填补空白（从主来源列表分配下一个可用 START_INDEX）。
- 时间框定最多 5 次工具调用。
- **不要**重启整个流水线。
**输出**：一段简短的内部备注（不包含在最终报告中），列出：
- 发现的空白及是否已解决
- 在报告"开放问题"部分需提及的剩余注意事项
### Phase 5 — 综合与撰写
**仅深度模式：** 撰写前，启动**综合子代理**（角色 4），传入完整来源列表、领域要点和置信度标签。子代理返回每个关键领域的报告级散文。主代理将其纳入最终报告结构。
**标准模式：** 主代理直接根据 Phase 2-3 收集的领域要点和来源摘要撰写。
创建输出文件：`DEEP_RESEARCH_[TOPIC].md`
#### 必需结构
```markdown
# Deep Research: [Topic]
> Generated [YYYY-MM-DD] | Depth: [standard/deep] | Sources: [N]
## TL;DR
（2-3 句话：决策要点。读者应该知道或做什么？面向不读完整报告的利益相关者。）
## Executive Summary
（200-400 字 — 关键发现，无废话）
## 1. Status Quo [Confidence: High/Medium/Low]
（当前实践状态，附引用 [N]）
## 2. Emerging Trends [Confidence: High/Medium/Low]
（过去 6-12 个月获得关注的内容，附引用 [N]）
## 3. Critical Assessment [Confidence: High/Medium/Low]
（趋势在实践中为何失败、已知权衡、风险，附引用 [N]）
## 4. Action Plan
- [ ] [行动 1 — 一句话，具体可操作]
- [ ] [行动 2 — ...]
- [ ] ...
（适用时关联代码库 / architecture-documentation.md）
## 5. Open Questions & Caveats
（无法明确回答的问题 — 包括未解决的矛盾和批判阶段标记的发现）
## Methodology
（所选深度、子代理数量、运行轮次、大纲变更（如有）、Phase 3.1 引用修正、降级说明（如适用））
## Bibliography
[1] Author — Title — URL — Accessed YYYY-MM-DD — Tier: N
[2] ...
## Source Extracts
（子代理原始数据 — 保留供后续会话使用）
### [1] Title
- **Summary:** [2-3 句摘要]
- **Key quotes:** [报告中使用的直接引用]
- **Source type:** [academic / industry / blog / docs / community]
- **Credibility tier:** [1 / 2 / 3]
### [2] Title
- ...
```
> 质量规则、置信度标签、章节指南、合并协议和错误处理详见 → [references/quality-and-operations.md](references/quality-and-operations.md)
---
## 输出
- 将报告保存到项目根目录：`DEEP_RESEARCH_[TOPIC].md`
- 如主题与项目相关，同时注明相关的 architecture-documentation.md 章节。
- 撰写完成后进行自检：扫描是否有 `[N]` 引用缺少对应的参考文献条目。交付前修正。
---
## 不适用场景
- 简单事实性问题 → 一次 WebSearch 调用即可。
- 调试或代码修复 → 标准代理模式。
- 仅关于*本代码库*的问题 → 使用代码库搜索工具。使用说明
# 深入研究 对技术主题进行系统的多阶段深入研究，通过来源验证、三角测量和引用支持生成结构化研究报告。 ## 适用场景 - 技术方案对比分析与选型 - 行业趋势研判与前沿技术调研 - 架构评估与最佳实践梳理 - 需要多来源交叉验证的深度分析 ## 工作流程 1. **Phase 0** — 澄清：分析歧义，提出 1-5 个澄清问题 2. **Phase 1** — 定范围：拆分关键领域，制定搜索策略 3. **Phase 2** — 检索：并行子代理多轮检索与补缺 4. **Phase 3** — 三角验证：多来源交叉验证，分配置信度 5. **Phase 4** — 批判审查：红队自检，填补关键空白 6. **Phase 5** — 撰写报告：输出带引用的结构化研究报告 ## 研究深度 | 深度 | 子代理 | 来源数 | 报告字数 | |------|--------|--------|----------| | 标准 | 2-3 | 15-25 | ~4,000 | | 深度 | 4-6 | 30-50 | 6,000+ | ## 输出格式 报告保存为 `DEEP_RESEARCH_[TOPIC].md`，包含 TL;DR、执行摘要、现状分析、趋势研判、批判评估、行动计划、方法论附录和完整参考文献。 ## 不适用 简单事实查询、代码调试、仅涉及本代码库的问题。
支持平台：Qoder · QoderWork · Claude · Codex 等 AI 编程助手