deep-research-cellcog-x-6

原始内容

---
name: deep-research
description: |
  Seven-stage deep research pipeline for substantive research questions.
  Activates when user asks for deep research, 深度研究, research report,
  evidence-backed investigation, or a sourced long-form answer.
  Trigger keywords: 研究、调研、深度分析、写报告、综述、report、deep research、
  investigate、research report、深度研究、调研报告、帮我了解、全面梳理、综合分析。
---

# Deep Research Pipeline — 深度研究七步法

> Migrated from DuMate's qianfan-deepresearch skill.
> This is a 7-stage systematic workflow, NOT a simple search-and-summarize.

---

## 整体工作流（7 阶段）

```
阶段 1：解析需求   → 2-3 个选择题（用户可跳过）→ 提炼课题 + 子问题清单 + 受众判断
阶段 2：生成大纲   → 先定骨架，再找内容 → 必须给用户确认大纲
阶段 3：规划任务   → 大纲拆成 ≤5 个有序任务
阶段 4：顺序执行   → 逐任务搜索 + 爬取 + 结论展示（直接在对话中，400-600字）
阶段 5：反思补充   → 覆盖缺口扫描 + 洞察提炼
阶段 6：撰写报告   → 综合全部阶段性结论成文 → 保存 .md 文件
阶段 7：HTML渲染   → 报告完成后主动询问用户是否生成 HTML
```

**两处主动确认 + 一处询问**：
- 阶段 1 开场：2-3 个选择题（可跳过）
- 阶段 2 大纲生成后：给用户审一次
- 阶段 7 报告完成后：询问是否生成 HTML

---

## 阶段 1：解析需求

### 1a. 开场选择题（仅此一次，必须放在最前）

用 `ask_user` 工具一次性问完，不要一个一个问。

**推荐问题（选 2-3 个，不要更多）：**

```
Step 1 — 目标读者：
- A. 普通读者 / 非专业实践者（默认）
- B. 专业从业者
- C. 学术 / 高级研究者
- D. 企业决策者

Step 2 — 报告侧重：
- A. 全面调研（系统覆盖，深度展开，默认）
- B. 趋势综合（提炼模式，典型案例支撑）
- C. 方案对比 / 决策建议（结论明确，须给判断）
- D. 可操作指南（步骤、模板、落地导向）

Step 3 — 篇幅期望：
- A. 标准（6000-10000字，默认）
- B. 精简（3000-5000字）
- C. 详尽（10000字以上）
```

**用户回复处理：**
- 用户做出选择 → 按选择推进
- 用户回复"跳过"/"skip"/"随便"/"你定" → 按默认值推进，立即进入下一步推断
- 用户提供补充信息 → 整合进参数，继续推进

### 1b. 自主推断剩余参数

根据用户原始输入 + 选择题答案，自行推断：
- **研究标题**：将输入提炼为一句清晰的研究课题
- **核心研究问题**：这次研究要回答的根本问题是什么？
- **范围与边界**：时间范围、地域范围、关注重点
- **报告类型**（见下方识别表）
- **语言**：用户用什么语言提问，就用什么语言研究和报告

**报告类型识别表：**

| 用户提问信号 | 报告类型 | 大纲策略 | 写作策略 |
|------------|---------|---------|---------|
| "总结"、"梳理"、"了解趋势"、"分析特点" | **合成型** | 以趋势/主题为主轴 | 每个趋势 1 核心判断 + 2-3 典型案例 |
| "调研"、"深度分析"、"全面研究" | **全面型** | 按主题或实体组织 | 系统覆盖，数据与案例并重 |
| "哪些…被用到"、"哪些因素"、"哪种方案" | **筛选型** | 主章节列"入选项"，小节说"排除项" | 重点在入选内容 |
| "帮我做…"、"提供一份…"、"制定…" | **交付型** | 直接按交付物格式组织 | 可操作性优先 |
| "评估/预测/是否可行/哪个最好" | **决策型** | 末尾给出明确判断 | 对比前置，结论明确 |
| "用户画像/人群分析/受众分析" | **人群洞察型** | 先统计维度，后叙事段落 | 每类人群必须有叙事段落 |

### 1c. 建立子问题清单

仔细阅读用户原始输入，提取所有**明确要求的信息维度**，建立清单：

```
□ 子问题 A：[用户明确要求的第一个方面]
□ 子问题 B：[用户明确要求的第二个方面]
□ 子问题 C：[用户提到的特定框架/算法/模型的基本原理]
□ ...
```

**规则：**
- 用户提到特定框架/算法/方法论，必须包含一项"介绍其基本原理"
- 用户要求按多个维度比较，每个维度都是独立子问题
- 用户要求"评估/预测/推荐"，该结论本身是必须直接回答的子问题
- **定量问题**（"比重是多少"、"数量是多少"）必须用数字回答，给出估算区间并说明依据

### 1d. 领域标准类别扩展（覆盖广度保障）

**这是决定报告覆盖广度的关键步骤。** 仅靠用户显式提到的内容往往不够——专业读者对某个领域有默认的"期待覆盖范围"。

| 课题类型 | 需要枚举的标准类别 |
|---------|------------------|
| **策略/干预类** | 该领域公认的所有主要干预/策略类别 |
| **技术/方法类** | 该技术领域的所有主流方法/路线 |
| **市场/行业类** | 行业内所有主要子行业/玩家类型 |
| **学术/理论类** | 研究该问题的标准理论框架/分析视角 |
| **政策/制度类** | 政策体系的所有关键组成部分 |
| **比较分析类** | 所有需要被比较的实体 |

**操作：**
1. 列出标准类别清单（5-10 项）
2. 标记哪些已被用户显式提及（✓），哪些是隐性类别（⊕）
3. 覆盖率须 ≥80%。若某类别信息不足，章节末尾注明"[类别X]目前公开信息有限"但不得完全略去

### 1e. 受众判断与写作风格映射

| 受众类型 | 判断信号 | 写作风格 |
|---------|---------|---------|
| **普通读者** | 问题描述日常化，关注"怎么做" | 通俗语言；缩写必须有全称+解释；每个建议给具体步骤 |
| **专业从业者** | 使用行业术语，关注技术方案 | 可用专业术语但首次全称；以数据和方案优先 |
| **学术研究者** | 使用学术框架，关注方法论 | 可用专业缩写；重视方法论严谨性 |
| **企业决策者** | 关注投资、市场、竞争格局、ROI | 结论前置；横向比较为主；量化数据优先 |

> **普通读者模式要求**：优先用日常语言替代缩写；每个策略必须有"怎么做"的具体步骤；以工具书的语气写作。

**阶段 1 结束：** 完成 1a-1e 后直接进入阶段 2，不再向用户做整体确认。

---

## 阶段 2：生成研究大纲

**目标：** 在搜索之前先确定报告骨架，确保覆盖所有子问题，**完成后必须给用户确认**。

### 生成规则

1. 阶段 1c 清单中每个子问题，大纲中至少有一个对应小节
2. 阶段 1d 标准类别覆盖率 ≥80%
3. "三必有"结构规则（按课题类型强制应用）：

| 课题类型 | 必须包含的章节 |
|---------|-------------|
| 市场/行业/政策类 | 独立的"宏观环境与政策背景"节 |
| 策略/干预/解决方案类 | 独立的"实施要素与落地条件"节 |
| 比较分析类 | 每个实体章节内所有用户指定维度都要出现；末尾必须有汇总对比表 |
| 学术理论类 | 用户要求的每个理论视角必须有独立子节 |

### 大纲第一原则：用户结构优先

| 信号 | 示例 | 大纲策略 |
|------|------|---------|
| 用户列出了 N 个问题/维度 | "请分析 A、B、C 三个方面" | N 个专属章节，标题用用户原话 |
| 用户要求 N 个实体按相同维度比较 | "各公司需包括技术路径、融资、团队" | **以实体为主轴**：每实体一节，节内按维度展开 |
| 提问开放，无明显结构 | "帮我了解 X 领域" | 使用通用模板 |

### 通用模板（仅提问开放时使用）

```
一、背景与概述
  · 定义与基本概念
  · 历史演变（技术/学术/人文类课题必须展开）

二、核心主题一
  ...

三、核心主题二
  ...

四、应用 / 案例 / 影响（含横向对比分析）
  ...

五、批判性视角：挑战、争议与局限性
  ...（几乎所有课题都必须有）

六、结论与展望
  ...
```

### 全景总览 + 重点深入（方法/策略/方案类课题必须用）

1. **全景总览层**：一张汇总表，简明列出所有主要选项，每个选项一句话描述
2. **重点深入层**：对最重要的 3-5 个选项详细分析（机制、数据、案例、局限性）

### 章节描述写法

每个章节描述必须说明"研究要探查什么问题"，不是"要收集什么信息"。

### 阶段 2 结束：向用户确认大纲

展示完整大纲后：
```
以上是大纲，请审核。需要增删/合并/调序请直接告诉我；
回复"确认"或"开始"即可启动调研，也可以回复"跳过"直接采用此大纲。
```

收到确认后再进入阶段 3。

---

## 阶段 3：规划研究任务

**目标：** 把大纲转化为有顺序的研究任务列表，**总数严格 ≤5 个**。

### 任务规划规则

- **硬上限 5 个**——宁可合并也不要超
- 大纲若有 6+ 章节，按主题相关性合并
- 每个任务需要明确：标题、覆盖的大纲章节、要回答的核心问题

### 任务格式

```
任务 1：[任务标题]
  目标章节：背景与概述、定义与基本概念
  描述：搜集 [课题] 的基本定义、发展历程、现状概览

任务 2：[任务标题]
  目标章节：核心主题一
  描述：深入研究 [核心主题一]，收集数据/案例/专家观点
```

### 执行顺序

- 主 Agent **顺序执行**所有任务（不并行派发子 Agent，不写笔记文件）
- 先做基础背景类任务，再做需要背景做铺垫的深入分析类任务
- 每个任务执行完，**直接在对话中展示精简结论**（阶段 4 Step F 格式），再进入下一个

---

## 阶段 4：顺序执行研究任务

主 Agent 按阶段 3 顺序，逐任务执行以下步骤。

### 搜索工具选择

统一使用 `web_search` + `web_fetch`：
- `web_search`：发起搜索；可用 `freshness` 参数（day/week/month/year）
- `web_fetch`：爬取选中的页面原文

### 数据来源优先级

**一手官方数据 > 行业协会统计 > 权威媒体报道 > 分析师估算**

### Step A：生成多个搜索查询

针对当前任务，生成 **5-8 个不同角度的搜索查询**：
- 角度互补，覆盖任务不同维度
- 包含时间限定词；优先用 `freshness` 参数而不是硬塞年份
- 包含权威来源词（"学术"、"研究报告"、"官方"）
- 学术/技术课题额外添加来源词（"arxiv"、"CNKI"、"wanfang"、"IEEE"）

### Step B：执行搜索

`web_search` 逐一执行 Step A 生成的查询。

### Step C：爬取关键页面

对每条搜索结果，选取**最相关的 2-3 个 URL**，用 `web_fetch` 获取完整内容。

### Step D：提取与记录

1. 提取与当前任务相关的信息片段
2. 记录来源：`标题 | URL`
3. 标注目标章节
4. **特别标记**：哪些是"主流共识"，哪些是"争议性/少数观点"

### Step E：覆盖缺口扫描 + 洞察提炼

**E1. 覆盖缺口扫描：**

对照阶段 1d 的领域标准类别清单，逐项检查：
- **完全未覆盖** → 立即发起补充搜索
- **仅有浅层描述** → 标"待深化"，优先在下一轮补全
- **并列子问题均衡检查**：各问题的内容量是否大致均衡（最多/最少比 ≤ 2:1）？

**E2. 洞察提炼：**

1. **跨来源模式**：多来源共同指向什么结论？
2. **矛盾与张力**：不同来源的数据有何矛盾？背后原因？
3. **意外发现**：有哪些与常识不符的数据点？
4. **结构化重组**：能否用简洁框架把碎片组织成新结构？给框架起名

> **洞察 = 对比 + 推演 + 结构化重组**，不是摘录。

### Step F：直接向用户展示阶段结论

**不写文件**。每个任务执行完，直接在对话中输出，**总长度控制在 400-600 字以内**。

格式：
```markdown
### ✅ 任务 N：[任务标题] —— 调研结论

**对应章节**：[大纲章节名]

**核心发现**（3-5 条，每条 1 句）
- ...

**定量数据**
| 数据 | 来源 | 年份 |
|------|------|------|

**洞察**（2-3 条，"[A] + [B] → [C]" 一行格式）
- ...

**意外发现 / 争议**（≤ 2 条）
- ...

**信息缺口**
- ...

**引用来源**
- [标题] | [URL]
```

### 单任务自检（达标后才进入下一个任务）

- [ ] 来源 ≥ 3 个不同域名
- [ ] 至少 1 条具体数量/规模/比例/时间节点数据
- [ ] 有对主流观点的局限说明、批判性内容或失败案例
- [ ] "洞察"部分包含跨来源推断
- [ ] 领域主要标准子类别覆盖率 ≥80%
- [ ] 并列子问题覆盖深度大致均衡（最多/最少比 ≤ 2:1）
- [ ] 任务结论已在对话中展示

不达标的任务，**当场补搜**。

### 搜索失败处理

- **失败任务禁止原样重试**：必须换角度或换关键词
- **连续失败 3 次**：放弃该角度，从完全不同方向继续
- **部分成功**：对缺失部分补充一次针对性查询

---

## 阶段 5：反思、验证与补充搜索

所有任务执行完毕、阶段性结论已在对话中展示后，主 Agent 回顾所有结论，分三步审查：

### 第一步：覆盖完整性检查

- 对照阶段 1d 领域标准类别清单，对每个"完全未覆盖"的发起最后补充搜索
- 对照阶段 1c 子问题清单，逐项确认每个问题有实质性回答
- **并列子问题均衡检查**：各问题覆盖量是否大致均衡？
- 每个主章节 ≥ 3 个不同来源，≥ 1 个具体定量数据
- 是否有主流观点的反驳/局限性/失败案例？（几乎所有章节都需要，没有则补搜）

### 第二步：结构完整性检查

- "三必有"规则验证
- 用户要求的每个理论框架维度是否都有独立、实质性内容？

### 第三步：洞察质量检查

- 每个主章节是否有至少 1 条**跨来源推断性结论**？
- 是否有对比性发现？是否有出人意料的发现？
- 整体核心叙事是否清晰？（能否用 1-2 句话说明最重要发现？）

对每个缺口，发起补充搜索，结果同样在对话中以简短结论形式补充。

---

## 阶段 6：撰写研究报告

### 跨任务综合

1. 覆盖完整性确认：整体上是否还有标准类别缺口
2. 跨章节模式：多份结论共同指向什么整体结论？
3. 数据一致性：不同任务给出的数字有无矛盾？
4. 核心叙事：用 1-2 句话概括整个研究最重要的发现
5. 高价值洞察定位：哪 2-3 个发现最出人意料、最有决策价值？

### 撰写要求

- **标题格式**：普通文字（如"## 一、背景与概述"或"## 背景与概述"），**不要**使用 C1/C2 编号前缀
- 综合所有对话中已展示的阶段性结论（每个任务的结论都在上下文里）
- 按受众类型对应风格写作（普通读者 vs 专家 vs 决策者）

### 保存

报告以 Markdown 保存到 `reports/[研究标题简写]_[YYYY-MM-DD].md`，告知用户路径。

---

## 阶段 7：HTML 渲染（可选）

报告完成后，**主动询问**用户是否需要生成 HTML 版：

```
报告已生成：[文件名].md

是否需要我生成一个精简的 HTML 网页版（响应式、左侧 TOC、可直接浏览器打开）？
- 回复"是" → 我会生成
- 回复"否" → 流程结束
```

---

## 质量红线

- ❌ 不要只看摘要，关键信息必须 WebFetch 读原文
- ❌ 不要过度引用同一来源
- ❌ 禁止虚构数据，涉及具体数字必须能找到来源
- ❌ 搜索重试必须换角度，不能用相同关键词
- ✅ 适应用户语言（中文用户用中文，英文用户用英文）
- ✅ 每个任务的结论直接展示在对话中（400-600字），不写中间文件

---

## 研究输出格式

```markdown
# [研究标题]

**生成日期：** YYYY-MM-DD
**研究范围：** [scope]
**受众类型：** [audience]
**报告类型：** [type]

## 摘要
[2-3 段落核心发现概述]

## 各章节内容
...

## 引用来源
- [标题] | [URL] — [描述] — [date]
```

---

## Notes

- 语言匹配：用户用什么语言提问，就用什么语言研究和报告
- 代码标识符、路径、CLI 命令保持原生形式
- 如果用户指定了格式，按要求执行；无说明则产出标准 Markdown 研究报告
- 写 skill 入口在用户的语言（中文/English）

name: deep-research description: | Seven-stage deep research pipeline for substantive research questions. Activates when user asks for deep research, 深度研究, research report, evidence-backed investigation, or a sourced long-form answer. Trigger keywords: 研究、调研、深度分析、写报告、综述、report、deep research、 investigate、research report、深度研究、调研报告、帮我了解、全面梳理、综合分析。

Deep Research Pipeline — 深度研究七步法

Migrated from DuMate's qianfan-deepresearch skill. This is a 7-stage systematic workflow, NOT a simple search-and-summarize.

整体工作流（7 阶段）

阶段 1：解析需求   → 2-3 个选择题（用户可跳过）→ 提炼课题 + 子问题清单 + 受众判断
阶段 2：生成大纲   → 先定骨架，再找内容 → 必须给用户确认大纲
阶段 3：规划任务   → 大纲拆成 ≤5 个有序任务
阶段 4：顺序执行   → 逐任务搜索 + 爬取 + 结论展示（直接在对话中，400-600字）
阶段 5：反思补充   → 覆盖缺口扫描 + 洞察提炼
阶段 6：撰写报告   → 综合全部阶段性结论成文 → 保存 .md 文件
阶段 7：HTML渲染   → 报告完成后主动询问用户是否生成 HTML

两处主动确认 + 一处询问：

阶段 1 开场：2-3 个选择题（可跳过）
阶段 2 大纲生成后：给用户审一次
阶段 7 报告完成后：询问是否生成 HTML

阶段 1：解析需求

1a. 开场选择题（仅此一次，必须放在最前）

用 ask_user 工具一次性问完，不要一个一个问。

推荐问题（选 2-3 个，不要更多）：

Step 1 — 目标读者：
- A. 普通读者 / 非专业实践者（默认）
- B. 专业从业者
- C. 学术 / 高级研究者
- D. 企业决策者

Step 2 — 报告侧重：
- A. 全面调研（系统覆盖，深度展开，默认）
- B. 趋势综合（提炼模式，典型案例支撑）
- C. 方案对比 / 决策建议（结论明确，须给判断）
- D. 可操作指南（步骤、模板、落地导向）

Step 3 — 篇幅期望：
- A. 标准（6000-10000字，默认）
- B. 精简（3000-5000字）
- C. 详尽（10000字以上）

用户回复处理：

用户做出选择 → 按选择推进
用户回复"跳过"/"skip"/"随便"/"你定" → 按默认值推进，立即进入下一步推断
用户提供补充信息 → 整合进参数，继续推进

1b. 自主推断剩余参数

根据用户原始输入 + 选择题答案，自行推断：

研究标题：将输入提炼为一句清晰的研究课题
核心研究问题：这次研究要回答的根本问题是什么？
范围与边界：时间范围、地域范围、关注重点
报告类型（见下方识别表）
语言：用户用什么语言提问，就用什么语言研究和报告

报告类型识别表：

用户提问信号	报告类型	大纲策略	写作策略
"总结"、"梳理"、"了解趋势"、"分析特点"	合成型	以趋势/主题为主轴	每个趋势 1 核心判断 + 2-3 典型案例
"调研"、"深度分析"、"全面研究"	全面型	按主题或实体组织	系统覆盖，数据与案例并重
"哪些…被用到"、"哪些因素"、"哪种方案"	筛选型	主章节列"入选项"，小节说"排除项"	重点在入选内容
"帮我做…"、"提供一份…"、"制定…"	交付型	直接按交付物格式组织	可操作性优先
"评估/预测/是否可行/哪个最好"	决策型	末尾给出明确判断	对比前置，结论明确
"用户画像/人群分析/受众分析"	人群洞察型	先统计维度，后叙事段落	每类人群必须有叙事段落

1c. 建立子问题清单

仔细阅读用户原始输入，提取所有明确要求的信息维度，建立清单：

□ 子问题 A：[用户明确要求的第一个方面]
□ 子问题 B：[用户明确要求的第二个方面]
□ 子问题 C：[用户提到的特定框架/算法/模型的基本原理]
□ ...

规则：

用户提到特定框架/算法/方法论，必须包含一项"介绍其基本原理"
用户要求按多个维度比较，每个维度都是独立子问题
用户要求"评估/预测/推荐"，该结论本身是必须直接回答的子问题
定量问题（"比重是多少"、"数量是多少"）必须用数字回答，给出估算区间并说明依据

1d. 领域标准类别扩展（覆盖广度保障）

这是决定报告覆盖广度的关键步骤。 仅靠用户显式提到的内容往往不够——专业读者对某个领域有默认的"期待覆盖范围"。

课题类型	需要枚举的标准类别
策略/干预类	该领域公认的所有主要干预/策略类别
技术/方法类	该技术领域的所有主流方法/路线
市场/行业类	行业内所有主要子行业/玩家类型
学术/理论类	研究该问题的标准理论框架/分析视角
政策/制度类	政策体系的所有关键组成部分
比较分析类	所有需要被比较的实体

操作：

列出标准类别清单（5-10 项）
标记哪些已被用户显式提及（✓），哪些是隐性类别（⊕）
覆盖率须 ≥80%。若某类别信息不足，章节末尾注明"[类别X]目前公开信息有限"但不得完全略去

1e. 受众判断与写作风格映射

受众类型	判断信号	写作风格
普通读者	问题描述日常化，关注"怎么做"	通俗语言；缩写必须有全称+解释；每个建议给具体步骤
专业从业者	使用行业术语，关注技术方案	可用专业术语但首次全称；以数据和方案优先
学术研究者	使用学术框架，关注方法论	可用专业缩写；重视方法论严谨性
企业决策者	关注投资、市场、竞争格局、ROI	结论前置；横向比较为主；量化数据优先

普通读者模式要求：优先用日常语言替代缩写；每个策略必须有"怎么做"的具体步骤；以工具书的语气写作。

阶段 1 结束： 完成 1a-1e 后直接进入阶段 2，不再向用户做整体确认。

阶段 2：生成研究大纲

目标： 在搜索之前先确定报告骨架，确保覆盖所有子问题，完成后必须给用户确认。

生成规则

阶段 1c 清单中每个子问题，大纲中至少有一个对应小节
阶段 1d 标准类别覆盖率 ≥80%
"三必有"结构规则（按课题类型强制应用）：

课题类型	必须包含的章节
市场/行业/政策类	独立的"宏观环境与政策背景"节
策略/干预/解决方案类	独立的"实施要素与落地条件"节
比较分析类	每个实体章节内所有用户指定维度都要出现；末尾必须有汇总对比表
学术理论类	用户要求的每个理论视角必须有独立子节

大纲第一原则：用户结构优先

信号	示例	大纲策略
用户列出了 N 个问题/维度	"请分析 A、B、C 三个方面"	N 个专属章节，标题用用户原话
用户要求 N 个实体按相同维度比较	"各公司需包括技术路径、融资、团队"	以实体为主轴：每实体一节，节内按维度展开
提问开放，无明显结构	"帮我了解 X 领域"	使用通用模板

通用模板（仅提问开放时使用）

一、背景与概述
  · 定义与基本概念
  · 历史演变（技术/学术/人文类课题必须展开）

二、核心主题一
  ...

三、核心主题二
  ...

四、应用 / 案例 / 影响（含横向对比分析）
  ...

五、批判性视角：挑战、争议与局限性
  ...（几乎所有课题都必须有）

六、结论与展望
  ...

全景总览 + 重点深入（方法/策略/方案类课题必须用）

全景总览层：一张汇总表，简明列出所有主要选项，每个选项一句话描述
重点深入层：对最重要的 3-5 个选项详细分析（机制、数据、案例、局限性）

章节描述写法

每个章节描述必须说明"研究要探查什么问题"，不是"要收集什么信息"。

阶段 2 结束：向用户确认大纲

展示完整大纲后：

以上是大纲，请审核。需要增删/合并/调序请直接告诉我；
回复"确认"或"开始"即可启动调研，也可以回复"跳过"直接采用此大纲。

收到确认后再进入阶段 3。

阶段 3：规划研究任务

目标： 把大纲转化为有顺序的研究任务列表，总数严格 ≤5 个。

任务规划规则

硬上限 5 个——宁可合并也不要超
大纲若有 6+ 章节，按主题相关性合并
每个任务需要明确：标题、覆盖的大纲章节、要回答的核心问题

任务格式

任务 1：[任务标题]
  目标章节：背景与概述、定义与基本概念
  描述：搜集 [课题] 的基本定义、发展历程、现状概览

任务 2：[任务标题]
  目标章节：核心主题一
  描述：深入研究 [核心主题一]，收集数据/案例/专家观点

执行顺序

主 Agent 顺序执行所有任务（不并行派发子 Agent，不写笔记文件）
先做基础背景类任务，再做需要背景做铺垫的深入分析类任务
每个任务执行完，直接在对话中展示精简结论（阶段 4 Step F 格式），再进入下一个

阶段 4：顺序执行研究任务

主 Agent 按阶段 3 顺序，逐任务执行以下步骤。

搜索工具选择

统一使用 web_search + web_fetch：

web_search：发起搜索；可用 freshness 参数（day/week/month/year）
web_fetch：爬取选中的页面原文

数据来源优先级

一手官方数据 > 行业协会统计 > 权威媒体报道 > 分析师估算

Step A：生成多个搜索查询

针对当前任务，生成 5-8 个不同角度的搜索查询：

角度互补，覆盖任务不同维度
包含时间限定词；优先用 freshness 参数而不是硬塞年份
包含权威来源词（"学术"、"研究报告"、"官方"）
学术/技术课题额外添加来源词（"arxiv"、"CNKI"、"wanfang"、"IEEE"）

Step B：执行搜索

web_search 逐一执行 Step A 生成的查询。

Step C：爬取关键页面

对每条搜索结果，选取最相关的 2-3 个 URL，用 web_fetch 获取完整内容。

Step D：提取与记录

提取与当前任务相关的信息片段
记录来源：标题 | URL
标注目标章节
特别标记：哪些是"主流共识"，哪些是"争议性/少数观点"

Step E：覆盖缺口扫描 + 洞察提炼

E1. 覆盖缺口扫描：

对照阶段 1d 的领域标准类别清单，逐项检查：

完全未覆盖 → 立即发起补充搜索
仅有浅层描述 → 标"待深化"，优先在下一轮补全
并列子问题均衡检查：各问题的内容量是否大致均衡（最多/最少比 ≤ 2:1）？

E2. 洞察提炼：

跨来源模式：多来源共同指向什么结论？
矛盾与张力：不同来源的数据有何矛盾？背后原因？
意外发现：有哪些与常识不符的数据点？
结构化重组：能否用简洁框架把碎片组织成新结构？给框架起名

洞察 = 对比 + 推演 + 结构化重组，不是摘录。

Step F：直接向用户展示阶段结论

不写文件。每个任务执行完，直接在对话中输出，总长度控制在 400-600 字以内。

格式：

### ✅ 任务 N：[任务标题] —— 调研结论

**对应章节**：[大纲章节名]

**核心发现**（3-5 条，每条 1 句）
- ...

**定量数据**
| 数据 | 来源 | 年份 |
|------|------|------|

**洞察**（2-3 条，"[A] + [B] → [C]" 一行格式）
- ...

**意外发现 / 争议**（≤ 2 条）
- ...

**信息缺口**
- ...

**引用来源**
- [标题] | [URL]

单任务自检（达标后才进入下一个任务）

来源 ≥ 3 个不同域名
至少 1 条具体数量/规模/比例/时间节点数据
有对主流观点的局限说明、批判性内容或失败案例
"洞察"部分包含跨来源推断
领域主要标准子类别覆盖率 ≥80%
并列子问题覆盖深度大致均衡（最多/最少比 ≤ 2:1）
任务结论已在对话中展示

不达标的任务，当场补搜。

搜索失败处理

失败任务禁止原样重试：必须换角度或换关键词
连续失败 3 次：放弃该角度，从完全不同方向继续
部分成功：对缺失部分补充一次针对性查询

阶段 5：反思、验证与补充搜索

所有任务执行完毕、阶段性结论已在对话中展示后，主 Agent 回顾所有结论，分三步审查：

第一步：覆盖完整性检查

对照阶段 1d 领域标准类别清单，对每个"完全未覆盖"的发起最后补充搜索
对照阶段 1c 子问题清单，逐项确认每个问题有实质性回答
并列子问题均衡检查：各问题覆盖量是否大致均衡？
每个主章节 ≥ 3 个不同来源，≥ 1 个具体定量数据
是否有主流观点的反驳/局限性/失败案例？（几乎所有章节都需要，没有则补搜）

第二步：结构完整性检查

"三必有"规则验证
用户要求的每个理论框架维度是否都有独立、实质性内容？

第三步：洞察质量检查

每个主章节是否有至少 1 条跨来源推断性结论？
是否有对比性发现？是否有出人意料的发现？
整体核心叙事是否清晰？（能否用 1-2 句话说明最重要发现？）

对每个缺口，发起补充搜索，结果同样在对话中以简短结论形式补充。

阶段 6：撰写研究报告

跨任务综合

覆盖完整性确认：整体上是否还有标准类别缺口
跨章节模式：多份结论共同指向什么整体结论？
数据一致性：不同任务给出的数字有无矛盾？
核心叙事：用 1-2 句话概括整个研究最重要的发现
高价值洞察定位：哪 2-3 个发现最出人意料、最有决策价值？

撰写要求

标题格式：普通文字（如"## 一、背景与概述"或"## 背景与概述"），不要使用 C1/C2 编号前缀
综合所有对话中已展示的阶段性结论（每个任务的结论都在上下文里）
按受众类型对应风格写作（普通读者 vs 专家 vs 决策者）

保存

报告以 Markdown 保存到 reports/[研究标题简写]_[YYYY-MM-DD].md，告知用户路径。

阶段 7：HTML 渲染（可选）

报告完成后，主动询问用户是否需要生成 HTML 版：

报告已生成：[文件名].md

是否需要我生成一个精简的 HTML 网页版（响应式、左侧 TOC、可直接浏览器打开）？
- 回复"是" → 我会生成
- 回复"否" → 流程结束

质量红线

❌ 不要只看摘要，关键信息必须 WebFetch 读原文
❌ 不要过度引用同一来源
❌ 禁止虚构数据，涉及具体数字必须能找到来源
❌ 搜索重试必须换角度，不能用相同关键词
✅ 适应用户语言（中文用户用中文，英文用户用英文）
✅ 每个任务的结论直接展示在对话中（400-600字），不写中间文件

研究输出格式

# [研究标题]

**生成日期：** YYYY-MM-DD
**研究范围：** [scope]
**受众类型：** [audience]
**报告类型：** [type]

## 摘要
[2-3 段落核心发现概述]

## 各章节内容
...

## 引用来源
- [标题] | [URL] — [描述] — [date]

Notes

语言匹配：用户用什么语言提问，就用什么语言研究和报告
代码标识符、路径、CLI 命令保持原生形式
如果用户指定了格式，按要求执行；无说明则产出标准 Markdown 研究报告
写 skill 入口在用户的语言（中文/English）