# Deep Research

深度研究编排方法论：澄清范围、拆解规划、并行调度子智能体调研、对抗式核验、综合成带引用的结构化报告。当任务需要多来源、可追溯、需事实核查的深度研究时使用此技能。

- Repository: https://github.com/xerrors/Yuxi (7566 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-10-31
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add xerrors/Yuxi --skill deep-research -g -a claude-code -y`
Codex: `npx skills add xerrors/Yuxi --skill deep-research -g -a codex -y`
Cursor: `npx skills add xerrors/Yuxi --skill deep-research -g -a cursor -y`
Gemini CLI: `npx skills add xerrors/Yuxi --skill deep-research -g -a gemini-cli -y`

## Description

深度研究编排方法论：澄清范围、拆解规划、并行调度子智能体调研、对抗式核验、综合成带引用的结构化报告。当任务需要多来源、可追溯、需事实核查的深度研究时使用此技能。

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 深度研究技能

当任务目标是产出**多来源、可追溯、经过核验**的深度研究结论（科研综述、行业/竞品调研、技术选型、专题分析等）时，使用此技能组织整个研究过程。本技能的核心是**编排**：你负责整体把控与子智能体调度，把繁重的检索与核验工作派发出去，自己专注规划与综合。

## 协作会话

通过 `create_session(name, description)` 派发，记录返回的 session_id 和 input_id；每个会话独立保存上下文并继承当前模型、资源与共享工作目录。description 必须包含目标和必要证据，不会继承父对话。互不依赖的工作先派发，再用 `wait_inputs(input_ids=[...])` 等待这些输入完成，并逐一用 `get_result(input_id=...)` 读取对应研究正文。`list_sessions` 仅用于查看成员状态；以每份任务的精确结果与引用作为综合依据。整棵树最多同时执行四个会话。

以下名称用于描述工作职责，可以创建多个不同名称的会话：

- 调研探索员：围绕一个明确子问题做多轮网页/知识库检索，返回按要点组织、带 `<cite>` 引用的结构化发现。**这是主力，按子问题并行多开。**
- 事实核查员：对给定的关键论断做对抗式核验，逐条给出 支持 / 存疑 / 反驳 + 依据来源 + 置信度，并标注冲突。

## 编排流程

### 1. 澄清范围
问题不明确时，先用 `ask_user_question` 补充 2-3 个关键问题（研究目标、受众、范围边界、地域/时效、输出语言与形式），对齐验收标准后再开工。已经清晰的任务不要反复追问。

### 2. 规划拆解
把研究目标拆成**可独立调研**的子问题，每个子问题写明产出标准（要回答什么、需要哪类证据），并在派发描述中明确。子问题应正交、覆盖完整，避免重叠或遗漏关键角度。

### 3. 并行派发调研
- 把互不依赖的子问题用**多个 `create_session` 调用并行**派发为独立调研会话。
- 每次派发在 `description` 中写清：子问题目标、已知上下文、期望输出格式（要点 + `<cite source="$URL" type="url">$INDEX</cite>` 引用 + 参考来源列表）。
- 何时派发 vs 自己直检：子问题复杂、需多轮检索、可隔离上下文、可并行时一律派发子智能体；仅在澄清范围、补一两个零散事实、或快速校正方向时才自己少量直接检索。
- 子问题之间有依赖时，先派发前置子问题，拿到结果后再派发后续。

### 4. 核验关键结论
对**影响最终结论的关键论断**、数字、以及子智能体之间相互冲突的发现，创建独立核查会话 做对抗式核验。要求其默认倾向「证据不足即标注存疑」。核验未通过的结论不要写进正文，或必须明确降级标注。

### 5. 综合成稿
证据充分后，由你统一综合为结构化报告，**不要**简单拼接子智能体返回的原文。根据研究主题组织内容，围绕论证而不是资料堆砌。

### 6. 停止准则
信息饱和、或确认无法获取更多有效信息即停。明确标注证据缺口与不确定性，不臆断、不编造来源。

## 引用

- 子智能体返回中间证据时沿用 `<cite source="$URL" type="url">$INDEX</cite>`；最终报告中的关键结论、数据和观点用指向原始来源的普通 `<a href="...">` 链接就近标注。
- 引用用户附件或知识库时标明文件名或路径。

## 输出

- 最终交付的是一份可直接使用的报告，而不是「我打算怎么研究」。
- 不要外泄中间推理过程、原始检索日志，也不要把内部规划原样输出成正文。
- 报告语言与用户提问语言一致，使用正式、克制、可复核的书面表达。
- 用户没有指定格式时，默认把完整报告写入当前 Workdir 中合适的位置，保存为一个 `.html` 文档；不要把完整报告直接铺在聊天正文里。用户明确要求 Markdown、纯文本、JSON 或其他格式时，以用户要求为准。
- 从系统提示读取当前 Project Workdir 的**绝对虚拟路径**，根据用户要求和项目结构选择报告位置，用 `write_file` 写入对应的绝对虚拟路径。不要把相对路径或宿主机路径传给文件工具。
- 写入成功后，把 `write_file` 返回的同一绝对路径传给 `present_artifacts`。最终聊天回复只需简要说明报告已完成并提示交付物，不要重复报告正文。

默认 HTML 应简洁、优雅并专注阅读，同时给模型保留版式判断空间：

The rest: https://github.com/xerrors/Yuxi/blob/HEAD/backend/yuxi/modules/extensions/skills/builtin/deep-research/SKILL.md
