DeerFlow deep-research 技能解析：四阶段深度调研方法论与 Skill 加载机制

在 DeerFlow（deer-flow）中，deep-research 是内置于 skills/public 目录下的一个公共技能，用于回答"什么是 X"、"对比 X 与 Y"、"调研 X"这类需要联网多源检索的问题，并在生成 PPT、文章、报告等内容前强制执行系统性预调研。本文完整拆解该技能的四阶段调研方法论、查询策略与时间感知规则，并结合 DeerFlow 后端的 skill 加载链路（<skill_index> → describe_skill → read_file）、web_search/web_fetch 工具来源与 <current_date> 动态上下文注入机制，说明这套方法论是如何在运行时真正被 Agent 执行与验证的。

技能定位：为什么需要 deep-research

deep-research 的核心主张写在 SKILL.md 的 "Core Principle" 一节：绝不基于纯通用知识生成内容。输出质量直接取决于调研的质量与数量，单次搜索永远不够（"A single search query is NEVER enough"）。

该技能的 frontmatter 明确了它的触发语义：

---
name: deep-research
description: Use this skill instead of WebSearch for ANY question requiring web research.
  Trigger on queries like "what is X", "explain X", "compare X and Y", "research X",
  or before content generation tasks. Provides systematic multi-angle research
  methodology instead of single superficial searches. Use this proactively when the
  user's question needs online information.
---

从 description 的措辞可以看出两点设计意图：

1. 替代关系：它明确声明"any question requiring web research 时用它而不是裸 WebSearch"，即把单点搜索升级为多角度的方法论约束；
2. 主动触发："Use this proactively" 要求模型在用户问题需要在线信息时主动加载，而不是等用户指名道姓。

适用场景在文档中分为两类：

调研类问题（Research Questions）

• 用户提问 "what is X"、"explain X"、"research X"、"investigate X"；
• 需要深入理解某个概念、技术或主题；
• 问题需要来自多个来源的最新、全面信息；
• 单次 web 搜索不足以给出合格答案。

内容生成前置（Content Generation Pre-research）

• 制作 PPT/幻灯片；
• 设计前端页面或 UI 原型；
• 撰写文章、报告或文档；
• 生成视频或多媒体内容；
• 任何需要真实世界信息、示例或最新数据的内容。

这与文档开头的 "Load this skill BEFORE starting any content generation task" 形成闭环：调研不是内容生成的可选项，而是前置关卡。

四阶段调研方法论（Research Methodology）

这是整个技能的骨架，按文档顺序完整展开如下。

Phase 1: Broad Exploration（广度探索）

以宽泛搜索摸清全貌，三个动作：

1. Initial Survey：先搜主主题，理解整体上下文；
2. Identify Dimensions：从初步结果中识别需要深挖的子主题、主题、角度；
3. Map the Territory：记录存在的不同视角、利益相关方与观点。

文档给出的标准示例：

Topic: "AI in healthcare"
Initial searches:
- "AI healthcare applications 2024"
- "artificial intelligence medical diagnosis"
- "healthcare AI market trends"

Identified dimensions:
- Diagnostic AI (radiology, pathology)
- Treatment recommendation systems
- Administrative automation
- Patient monitoring
- Regulatory landscape
- Ethical considerations

要点是：广度探索的产物不是答案，而是维度清单——后续所有深挖都以这份清单为任务分解依据。

Phase 2: Deep Dive（定向深挖）

对 Phase 1 识别出的每个重要维度做定向研究，四个动作：

1. Specific Queries：用精确关键词针对每个子主题搜索；
2. Multiple Phrasings：尝试不同的关键词组合与表述；
3. Fetch Full Content：用 web_fetch 读取重要来源的全文而非搜索摘要；
4. Follow References：来源中提到的其他重要资源也要继续检索。

文档示例：

Dimension: "Diagnostic AI in radiology"
Targeted searches:
- "AI radiology FDA approved systems"
- "chest X-ray AI detection accuracy"
- "radiology AI clinical trials results"

Then fetch and read:
- Key research papers or summaries
- Industry reports
- Real-world case studies

关于 web_fetch 的底层实现，DeerFlow 在后端社区工具包中提供了多套供应商实现，如 ddg_search/tools.py、exa/tools.py、firecrawl/tools.py、jina_ai/tools.py 等，它们都暴露了统一的 web_search_tool(query) / web_fetch_tool(url) 接口形态。也就是说，SKILL.md 中提到的 web_fetch 并不是某个单一实现，而是由当前配置的搜索供应商（Brave、DDG、Exa、Jina、Firecrawl、SearXNG 等）具体落地，方法论本身与供应商解耦。

Phase 3: Diversity & Validation（多样性与交叉验证）

通过主动寻找不同类型的信息来保证覆盖度，文档给出了一张"信息类型—目的—示例查询"对照表：

信息类型	目的	示例查询
事实与数据	具体证据	"statistics"、"data"、"numbers"、"market size"
案例与实例	真实应用	"case study"、"example"、"implementation"
专家观点	权威视角	"expert analysis"、"interview"、"commentary"
趋势与预测	未来方向	"trends 2024"、"forecast"、"future of"
对比	背景与替代方案	"vs"、"comparison"、"alternatives"
挑战与批评	平衡视角	"challenges"、"limitations"、"criticism"

这张表的工程价值在于把"调研是否充分"从主观感觉变成了可勾选的类型清单：六类信息缺哪类，就补哪类查询。

Phase 4: Synthesis Check（合成自检）

进入内容生成前的强制校验清单：

• [ ] 是否至少从 3–5 个不同角度搜索过？
• [ ] 是否 fetch 并完整阅读了最重要的来源？
• [ ] 是否掌握了具体数据、实例与专家视角？
• [ ] 是否同时覆盖了正面与局限/挑战？
• [ ] 信息是否足够新、且来自权威来源？

文档给出的规则是：只要有任何一项答案为否，就继续调研，不得开始生成内容。这是一条硬性的流程闸门。

查询策略：Effective Query Patterns

文档的 "Search Strategy Tips" 给出了一组正反对照的查询写法：

# 上下文要具体
❌ "AI trends"
✅ "enterprise AI adoption trends 2024"

# 加入权威来源暗示词
"[topic] research paper"
"[topic] McKinsey report"
"[topic] industry analysis"

# 按内容类型定向搜索
"[topic] case study"
"[topic] statistics"
"[topic] expert interview"

# 使用时间限定词 —— 必须使用 <current_date> 中的真实当前年份
"[topic] 2026"   # ← 替换为真实当前年份，绝不硬编码过去的年份
"[topic] latest"
"[topic] recent developments"

三条可操作的规律：

1. 上下文具体化：把泛词（"AI trends"）替换为带场景的短语（"enterprise AI adoption trends"）；
2. 来源暗示词：research paper、industry analysis 等词能引导搜索引擎返回更权威的页面；
3. 内容类型词：case study / statistics / expert interview 直接对齐 Phase 3 的信息类型表，检索词与验证清单一一呼应。

时间感知：为什么必须读 <current_date>

这是 SKILL.md 中最具工程细节的一节。文档要求：在构造任何搜索查询之前，先检查上下文中的 <current_date>，因为它给出完整的"年、月、日、星期"（例如 2026-02-28, Saturday），并应根据用户意图选择合适的精度：

用户意图	所需时间精度	示例查询
"today / this morning / just released"	月 + 日	"tech news February 28 2026"
"this week"	周区间	"technology releases week of Feb 24 2026"
"recently / latest / new"	月	"AI breakthroughs February 2026"
"this year / trends"	年	"software trends 2026"

配套规则：

• 用户问 "today" 或 "just released" 时，查询必须带上月 + 日 + 年才能拿到当日结果；
• 需要日级精度时绝不能退化为只用年份——"tech news 2026" 搜不到今天的新闻；
• 跨查询尝试多种写法：数字形式（2026-02-28）、文字形式（February 28 2026）、相对词（today、this week）。

文档还给出了一组正误对照：

❌ 用户问 "what's new in tech today" → 搜索 "new technology 2026" → 漏掉当日新闻
✅ 用户问 "what's new in tech today" → 搜索 "new technology February 28 2026"
   + "tech news today Feb 28" → 命中当日结果

这个 <current_date> 并非凭空出现。在 DeerFlow 后端中，它由 dynamic_context_middleware.py 负责注入：该中间件在消息流中维护形如 <current_date>2026-05-08, Friday</current_date> 的日期上下文，并在日期变化时更新提醒（模块内定义了 _DATE_RE = re.compile(r"<current_date>([^<]+)</current_date>") 以及 _format_current_date() 等函数）。也就是说，SKILL.md 里"永远用真实当前年份、绝不硬编码"这条规则之所以可执行，前提是运行时确实会把真实日期喂进上下文——技能文档与中间件实现是相互咬合的。

web_fetch 的使用时机与迭代式精炼

文档对"何时该 fetch 全文"给了四条判据：

• 搜索结果高度相关且权威；
• 需要超出摘要片段的细节；
• 来源包含数据、案例研究或专家分析；
• 需要理解某个发现的完整上下文。

与 fetch 配合的是"迭代式精炼"（Iterative Refinement）循环：

1. 回顾已获取的信息；
2. 识别理解上的缺口；
3. 针对缺口构造新的、更精准的查询；
4. 重复直到覆盖完整。

这与 Phase 1→2 的结构一致，但把它明确定义为循环而非线性流程——调研的终点是"缺口消失"，而不是"搜了 N 次"。

质量底线与常见错误

Quality Bar（质量标尺）

调研被认为"足够"，当且仅当你能自信地回答六个问题：

• 关键事实与数据点是什么？
• 有 2–3 个具体的真实世界实例吗？
• 专家怎么看这个主题？
• 当前趋势与未来方向是什么？
• 有哪些挑战或局限？
• 这个主题为什么在此时此刻重要？

Common Mistakes to Avoid（常见错误）

• 只搜 1–2 次就收手；
• 只看搜索摘要、不读全文来源；
• 多面主题只搜一个方面；
• 忽略相反观点或批评；
• 有最新数据时仍用过时信息;
• 调研未完成就抢跑内容生成。

完成调研后的产出物

文档的 "Output" 一节规定了调研阶段的交付形态：一个多角度的全面理解、具体事实与数据、真实案例、专家视角与权威来源、当前趋势与语境。只有达到这个状态才允许进入内容生成，并用收集到的信息生产高质量、信息充分的成果。

运行时视角：deep-research 技能如何被加载与执行

理解完方法论本身，再从 DeerFlow 的源码看这套指令如何进入模型上下文——这能解释文档中每条规则为何以这种形式书写。

三级发现链路：skill_index → describe_skill → read_file

DeerFlow 没有把所有技能的完整描述塞进系统提示词，而是采用"延迟发现"（deferred discovery）：系统提示词中只渲染 <skill_index> 里的技能名列表，模型按需拉取元数据，确认匹配后再 read_file 加载完整的 SKILL.md。该协议由 describe.py 生成的 <skill_system> 提示段显式规定：

1. Check <skill_index> for a skill name that matches your task
2. Call describe_skill(name) to fetch its description and capabilities
3. If the skill matches, call read_file on the returned location to load full instructions
4. Follow the skill's instructions precisely

也就是说，"模型主动加载 deep-research 技能"在运行时的实际调用链是：

1. 模型在 <skill_index> 中看到 deep-research（技能名清单由 catalog.py 的 SkillCatalog.names 提供）；
2. 调用 describe_skill("select:deep-research")，工具返回 description、allowed-tools 与文件位置（渲染函数 _render_skill_metadata 会对 frontmatter 中来自不可信 .skill 包的 name/description 做 HTML 转义，防止伪造框架标签）；
3. 模型 read_file 打开该技能在容器内的 SKILL.md 路径，把本文所述的完整方法论载入上下文；
4. 模型按 "Follow the skill's instructions precisely" 执行四阶段流程。

describe_skill 还支持两种查询语法（见 catalog.py 的 search() 实现）："select:data-analysis,deep-research" 精确选取，以及 "chart visualization"、"+podcast gen" 这类关键词/必需前缀搜索（结果上限 MAX_RESULTS = 5）。

此外还有一条快捷路径：如果用户消息以 /deep-research 开头（slash 激活），运行时会直接注入该技能内容，模型无需再 read_file——这在 <skill_system> 提示段的 "Explicit Slash Skill Activation" 一节有说明。

Frontmatter 校验：name 与 description 是硬要求

技能包要进入目录，frontmatter 必须通过校验。validation.py 中的 _validate_skill_frontmatter 会拒绝：缺少 name 或缺少 description 的技能、以及含有 ALLOWED_FRONTMATTER_PROPERTIES 之外的未知字段（该白名单定义于 frontmatter.py）。deep-research 的 frontmatter 只声明了 name 与 description，没有 allowed-tools 限制，意味着激活后它可使用 Agent 基线工具集——这也是它能自由调用 web_search/web_fetch 的原因。对照 skills/AGENTS.md 的说明，可移植工具名 WebSearch/WebFetch 会分别映射到运行时工具 web_search/web_fetch。

方法论与运行时的三点咬合

• <current_date> 规则 ↔ dynamic_context_middleware.py 真实注入当前日期，使"用真实当前年份构造查询"有数据源可依；
• web_fetch 调用 ↔ 后端以可插拔社区工具包（DDG/Brave/Exa/Jina/Firecrawl/SearXNG 等）提供统一形态的 web_search_tool/web_fetch_tool，方法论不绑定供应商；
• "research is iterative" ↔ DeerFlow 的长程任务模型（SuperAgent harness，可运行分钟到小时级任务）允许模型执行多轮检索—阅读—再检索循环而不被过早终止。

适用前提与使用建议

• 该技能面向 DeerFlow 内置技能体系：技能位于 skills/public/deep-research/SKILL.md，以目录 + SKILL.md（YAML frontmatter + Markdown 正文）为最小结构；
• 前提是当前 Agent 配置了可用的 web 搜索供应商（web_search）与 web_fetch 工具，否则 Phase 2 的"读全文"环节无法落地；
• 实践上，把 Phase 3 的信息类型表当作任务分解器、把 Phase 4 清单当作准出闸门，是这套方法论可复制性的关键：任何"调研→生成"类工作（竞品分析、行业报告、PPT 素材准备）都可以直接套用这四阶段结构与质量标尺。

从源码结构看，deep-research 这类公共技能与 github-deep-research、systematic-literature-review、consulting-analysis 等技能共同构成了 skills/public 下的"调研家族"，各自覆盖不同场景（通用 web 调研、GitHub 仓库调研、文献综述、咨询分析），而 deep-research 是其中最通用、也是内容生成前默认应优先加载的一个。