deep-research深度调研技能：对任意命题进行系统性调研并输出专业研究报告。 覆盖技术选型、行业分析、学术研究、竞品分析、概念探索等所有调研场景。 核心方法论：快速扫描→假设驱动研究、内外数据结合（先摸清内部现状再对标外部水位）、 反面证据强制搜索、数据来源三级分类、结论置信度分级、多层次报告输出。 采用 Orchestrator-Subagent 架构（Lead+Sub-agent 并行深挖、压缩回传、Scaling Rules 预算控制）， 对齐 Anthropic 官方 Research 工程实践。 包含信息交叉验证、专业图表生成（Diagram Bridge 统一图表体系）、 数据来源分级标注、分析框架自动选择、报告组件驱动（不预设模板，按内容形态调用组件）、质量自检（6 步工作流）。 触发词：调研、研究、分析报告、对…
Independent GitHub snapshot · Automated classification · Original documentation governs
先摸清内部现状，再对标外部水位，找到差距，指导行动。 产出有判断、有依据、经得起反面追问的专业研究报告。
下面分 6 步介绍调研能力：理解命题 → 多跳搜集 → 分析结论 → 图表生成 → 撰写报告 → 质量自检。
这 6 步是能力清单，按命题复杂度调用——不是每次都得全部走完。简单事实查询硬走 6 步是浪费；复杂研究跳过任何一步都会丢深度。
收到调研需求后，先判断命题复杂度，决定走哪条路径：
| 命题类型 | 特征 | 调用的能力 | 报告形态 |
|---|---|---|---|
| 简单事实 | 单一明确问题（"Redis 7 新特性"、"某 API 用法"） | 1.1 命题理解 → 2.6 直接搜索 → 简短答复 | 对话式答复，不出报告 |
| 对比类 | 两到三方案对比（"Redis vs Dragonfly"） | 1.1 + 1.4-1.6（缩减版）→ 2 多跳（2-4 sub-agent）→ 3 分析 → 5 简报（核心结论 + 对比块 + 建议） | 中等篇幅 MD，按内容形态选组件 |
| 复杂研究 | 需要建立全景认知（"AI Agent 赛道"） | 完整 1-6 步 | 完整 MD/HTML，覆盖主要组件 |
| 超深度 | 跨产业链、多维度（"半导体国产替代") | 完整 1-6 步 + 多轮迭代 + sub-sub-agent | 长篇 HTML，覆盖全部组件 + 数据附录 |
调研需求来了
↓
命题是单一具体事实查询？（"X 是什么"、"如何配置 Y"）
├─ 是 → 走简单事实路径：Lead 自查官方源 → 直接答复（不进入"理解命题"流程）
└─ 否 → 进入 1.1 命题理解
↓
归类为对比类 / 复杂研究 / 超深度
↓
按 Scaling Rules（2.3）配置预算
↓
按需调用 1.4-6.4 各能力
核心原则：
收到调研需求后，先花时间理解命题本质和内部现状，不要急着搜索。
向用户确认以下信息（已知的跳过，模糊的追问）：
根据命题自动归类，不同类型决定后续的报告结构和搜索策略：
| 类型 | 特征 | 示例 |
|---|---|---|
| 技术选型 | 多个方案对比，需要做选择 | Redis vs Memcached、React vs Vue |
| 行业分析 | 了解市场格局、玩家、趋势 | AI Agent 赛道、低代码平台市场 |
| 概念研究 | 深入理解原理、机制、演进 | RAG 技术原理、CRDT 一致性算法 |
| 性能评测 | 量化对比、benchmark 数据 | 数据库读写性能对比 |
| 竞品分析 | 产品功能、定位、差异化对比 | Cursor vs Windsurf vs Claude Code |
| 可行性探索 | 验证某个想法是否可行 | 用 WebRTC 做实时协作编辑 |
如果命题跨多个类型，以主要目的为准，兼顾次要维度。
评估不是独立类型。所有调研类型都内含评估逻辑——先理解内部现状，再对标外部水位，识别差距。 用户说"评估一下 xxx"、"诊断"、"差距分析"时，根据具体命题匹配上述 6 种类型，评估视角在 1.4 现状摸底中统一处理。
加载信源矩阵（完成归类后执行，详见 references/sources/_router.md）：
references/sources/finance.yamlreferences/sources/academic.yamlreferences/sources/_source_heuristics.mdreferences/sources/blacklist.yaml（最高优先级过滤）Lead Agent 必须在派发 sub-agent 前，把加载的 YAML 内容注入 sub-agent prompt（见 2.1）。
根据调研类型自动选择图表风格主题，同一份报告内所有图表保持统一。
具体的风格配置见 references/chart-styles.md，根据调研类型查阅对应章节。
在进行任何外部搜索之前，先理解「我们自己」的状态。这是所有调研的起点——不知道自己在哪，就无法判断外部信息的价值。
数据采集来源：
| 层级 | 来源 | 获取方式 | 可信度 |
|---|---|---|---|
| 内部数据 | 本地代码库、内部文档、BI 报表、监控数据 | Read / Grep 读本地文件、用户提供 | 高（一手） |
| 半公开数据 | 付费数据库、专家访谈纪要、行业社群 | 用户提供路径或授权访问 | 中-高 |
| 公开数据 | 行业报告、财报、新闻、开源数据 | WebSearch / WebFetch / Playwright | 需交叉验证 |
按调研类型的摸底重点：
| 调研类型 | 摸底重点 | 典型内部数据 |
|---|---|---|
| 技术选型 | 当前技术栈、性能瓶颈、团队技能分布 | 代码库、监控数据、内部 ADR |
| 行业分析 | 公司在行业中的位置、已有业务数据 | BI 报表、OKR 文档、财务数据 |
| 概念研究 | 团队对该概念的当前理解和应用程度 | 现有实现代码、内部技术分享 |
| 性能评测 | 当前性能基线、监控数据、历史 benchmark | APM 数据、压测报告、CI/CD 日志 |
| 竞品分析 | 自身产品现状、用户反馈、内部竞品跟踪 | 竞品跟踪文档、客户反馈记录 |
| 可行性探索 | 现有技术储备、团队能力、资源约束 | 代码库技术栈、团队 roster |
执行方式：
在形成假设之前，先做一轮轻量级外部搜索，对命题领域建立基本认知。目的不是收集证据，而是了解「这个领域目前是什么状况」，让后续假设有事实基础而非凭空猜测。
执行方式：
产出：一段简短的扫描摘要（3-5 个要点），作为下一步形成假设的输入。
示例：
调研命题："是否应该从 Redis 迁移到 Dragonfly"
快速扫描发现：
- Dragonfly 定位为 Redis 的直接替代品，声称性能提升 25 倍
- 多个 benchmark 显示在多线程场景下确实显著优于 Redis
- 但社区讨论中有人指出生产环境稳定性存疑
- Redis 7.0 已引入多线程 IO，缩小了部分差距
- 迁移案例主要集中在中小规模部署
基于内部现状（1.4）+ 快速扫描结果（1.5），形成 2-4 个可验证/可证伪的假设：
示例（承接上面的扫描结果）：
假设 1：Dragonfly 在多线程高并发场景下性能显著优于 Redis
→ 依据：扫描发现多个 benchmark 支持此结论
→ 验证点：独立 benchmark 数据、生产环境案例、Redis 7.0 多线程对比
假设 2：Dragonfly 生态成熟度不足，大规模生产环境迁移风险高
→ 依据：扫描发现迁移案例集中在中小规模，社区有稳定性质疑
→ 验证点：客户端兼容性、大规模部署案例、已知 bug 和限制
假设 3：我们当前的性能瓶颈不在 Redis 层
→ 依据：内部摸底发现 APM 数据显示主要延迟在应用层
→ 验证点：内部监控数据、链路分析、Redis 慢查询日志
与旧流程的区别：假设不再基于猜测，而是基于内部数据和初步扫描的事实。每个假设的「依据」必须指向 1.4 或 1.5 中发现的具体信息。
将解析结果简要告知用户：
调研命题：xxx
调研类型：技术选型
报告风格：商务蓝灰
输出格式：Markdown / HTML
命题复杂度：对比类 / 复杂研究 / 超深度
执行预算：派发 N 个 sub-agent，每个 WebSearch ≤ X / WebFetch ≤ Y
预计 Token 消耗：约 Mx chat 基准
初始假设：
1. xxx
2. xxx
内部数据源：已读取 / 用户将提供 / 无
预计涵盖：A、B、C 几个维度
开始调研？
输出格式判断规则：
用户确认后进入下一步。如果是简单直接的调研需求（命题明确、无歧义），可以跳过对齐直接开始。
这是调研的核心环节。采用 Orchestrator-Subagent 架构：Lead Agent 负责规划与整合，Sub-agent 独立并行深挖，避免单一 context 被原始材料撑爆导致细节丢失。架构参考 Anthropic 官方 Research 系统实践。
Lead Agent（主 agent）
↓ 拆子问题 → 派发
Sub-agent A / B / C 并行（独立 context + 独立预算）
↓ 压缩回传
Lead 整合 → 触发规则命中？
↓ 命中 → 再 fork sub-agent
↓ 未命中 → synthesis 出报告
Lead Agent 职责：
/tmp/research-plan-<timestamp>.md（防 context 截断丢失）/tmp/research-topology-<timestamp>.json 追加条目，回传后补 budget_used / findings_count，Fork sub-sub 时记录 parent_id；线索被主动放弃也要记录（格式见 2.5）_source_heuristics.md 的规则 + 本命题所属子域推导示例whitelist_hits / heuristic_hits / blacklist_avoided 字段（见 2.4）Sub-agent 职责：
surprises 字段供 Lead 判断是否深挖/tmp/，不塞进回传硬性约束：
subagent_type: "general-purpose" + model: "sonnet"废弃"固定 3 层广度优先"模型，改为按节点兴趣度动态深挖。
迭代上限：
单轮流程：
Round N
↓
Lead 读全部 findings → 识别信息缺口 / 触发点
↓
Spawn 新一批 sub-agent（可含 sub-sub-agent）
↓
收集压缩回传
↓
满足终止条件 → 结束；否则 Round N+1
节点级 Fork 触发规则（满足任一条件，Lead 必须派新 agent）：
| 触发条件 | 深挖方向 |
|---|---|
confidence: low 且 finding 关系核心结论 | 派专员找 T1 源补证 |
出现 surprises（反直觉线索） | 单独派 agent 深挖该线索 |
| 不同 sub-agent 的 evidence 矛盾 | 派"裁判 agent"回溯权威一手源 |
| 某核心命题反面 findings 数 < 2 | 派反面证据专员（Devil's Advocate） |
| 关键命题仅有 T2/T3 支撑、未找到 T1 | 派一手源专员 |
终止条件（满足任一即可结束）：
根据命题复杂度配置 sub-agent 数量和工具预算。超预算必须强制收尾，防止 runaway。
| 命题类型 | 示例 | Sub-agent 数 | WebSearch / sub-agent | WebFetch / sub-agent |
|---|---|---|---|---|
| 简单事实 | "Redis 7 新特性" | 不开 Multi-Agent，Lead 自查 | ≤ 10 | ≤ 10 |
| 对比类 | "Redis vs Dragonfly 性能" | 2-4 | ≤ 8 | ≤ 12 |
| 复杂研究 | "AI Agent 赛道格局" | 5-10 | ≤ 10 | ≤ 15 |
| 超深度 | "半导体产业链 + 国产替代" | 10+ 按需迭代 | ≤ 12 | ≤ 20 |
Lead Agent 在派发前必须声明（写入 plan 文件，并在 1.7 对齐阶段展示给用户）：
命题复杂度评估：<类型>
计划派发：<N> 个 sub-agent
每个预算：WebSearch ≤ X / WebFetch ≤ Y
预计 Token 消耗：约 <M>x chat 基准
Token 成本红线：
核心原则：Sub-agent 不得将原始网页内容回流给 Lead Agent。回传必须是结构化压缩摘要，避免 Lead context 被撑爆导致细节丢失。
标准回传 JSON：
{
"topic": "本次调查的子问题",
"findings": [
{
"claim": "一句话结论",
"evidence": ["关键引文片段，每段 ≤100 字"],
"urls": ["https://..."],
"source_tier": "T1|T2|T3",
"confidence": "high|mid|low",
"date": "证据时间戳，如 2026-03"
}
],
"surprises": ["反直觉或意外发现，供 Lead 决定是否深挖"],
"gaps": ["未能验证的点 / 需其他 agent 补充的信息"],
"budget_used": { "search": N, "fetch": M },
"whitelist_hits": N,
"heuristic_hits": { "p1_official": 3, "p2_authoritative": 2, "p3_community": 1 },
"blacklist_avoided": ["csdn.net", "guba.eastmoney.com"]
}
信源矩阵字段说明：
whitelist_hits：若本次加载了 finance.yaml / academic.yaml，命中了几个白名单源（质量指标）heuristic_hits：若走启发式，按 P1/P2/P3 分类的命中源数（衡量 heuristics 有效性）blacklist_avoided：识别并避开的黑名单域列表（证明过滤生效）硬性禁止：
source_tier 或 confidence 字段Filesystem Pattern（处理大文档）：
| 场景 | 做法 |
|---|---|
| 长文档（财报 / 论文 / 长博客）需保全文 | Sub-agent 存到 /tmp/<subagent-id>-<topic>.md，回传只记录路径 |
| 后续 agent 需核对原文 | 按 urls 或 /tmp/ 路径按需回访，不塞进 Lead context |
| CitationAgent 做引用对齐 | 独立读取 /tmp/ 文件做位置校对 |
| 报告完成后 | 清理 /tmp/ 下本次调查产生的临时文件 |
Lead Agent Synthesis 阶段：
/tmp/ 路径按需读取目的：让调研过程可观测——派发了几个 sub-agent、递归了几层、消耗了多少搜索/抓取、放弃了哪些线索，最终写入报告"调查拓扑"段（见 5.2）。
记录文件：/tmp/research-topology-<timestamp>.json（同次调研使用同一文件名，与 plan 文件共享 timestamp）。
条目结构：
{
"session_id": "<timestamp>",
"root_topic": "本次调研命题",
"complexity_class": "simple|comparison|complex|super-deep",
"agents": [
{
"agent_id": "sub-01",
"parent_id": null,
"round": 1,
"topic": "子问题摘要",
"spawn_reason": "初始拆解 | confidence_low | surprise_followup | contradiction | devils_advocate | missing_t1",
"budget_plan": { "search": 10, "fetch": 15 },
"budget_used": { "search": 8, "fetch": 11 },
"findings_count": 4,
"status": "completed|aborted|budget_exceeded"
}
],
"abandoned_leads": [
{ "topic": "放弃的线索", "reason": "反爬无法验证 | 时效性不足 | 预算触顶 | 其他" }
]
}
硬性约束：
agents[] 条目（填 budget_plan + spawn_reason，budget_used 和 findings_count 留空）budget_used / findings_count / statusparent_id 和 round，识别出递归层级abandoned_leads，不得静默丢弃/tmp/ 下其他本次调研产物一并清理（synthesis 结束后 Lead 负责）简单事实查询：Lead 自查不开 Multi-Agent 时（见 2.3），仍需生成最小拓扑文件（agents 为空，记录自查的 budget_used），保证报告拓扑段统一。
很多高价值网站有反爬机制，WebFetch 可能拿不到内容。采用分层抓取策略：
第 1 层（默认）：WebFetch 直接请求
│ 成功 → 使用
│ 失败/内容为空/返回反爬页面 ↓
│
第 2 层（降级）：Playwright 浏览器模拟
│ 通过 Playwright MCP 工具模拟真实浏览器访问
│ 成功 → 使用
│ 失败 ↓
│
第 3 层（替代）：换源搜索
└── 放弃该 URL，搜索同一信息的其他来源
Playwright 浏览器抓取步骤（当 WebFetch 失败时）：
playwright__browser_navigate 访问目标 URLplaywright__browser_wait_for 等待页面加载完成（等待关键内容元素出现）playwright__browser_snapshot 获取页面可访问性快照（结构化文本内容）playwright__browser_evaluate 执行 JS 提取特定内容playwright__browser_close 关闭浏览器释放资源常见需要 Playwright 的高价值站点（非完整列表，遇到新的反爬站点时自动识别并切换）：
| 站点类型 | 示例 | 原因 |
|---|---|---|
| 技术文档 | 部分官方文档站 | JS 渲染 SPA |
| 论文平台 | arXiv、Google Scholar | 反爬+验证码 |
| 行业报告 | 各咨询公司报告页 | 严格反爬 |
| 社区论坛 | Reddit、HN 部分页面 | API 限制 |
| 新闻媒体 | 部分科技媒体 | 付费墙/反爬 |
抓取纪律：
搜索过程中，对每条关键信息记录：
| 层级 | 来源类型 | 可信度 | 引用标记 |
|---|---|---|---|
| 一手来源 | 官方财报、论文原文、官方文档、实测数据、内部系统数据 | 高 | [T1] |
| 二手来源 | 媒体报道、技术博客、分析师报告、行业白皮书 | 中 | [T2] |
| 三手来源 | 社区讨论、AI 生成摘要、转引、未署名文章 | 低，需交叉验证 | [T3] |
| 属性 | 说明 |
|---|---|
| 数据范围 | 地域、时间段、包含/排除条件 |
| 数据年份 | 所有数据标注来源年份 |
| 统计口径 | 收入确认方式、用户定义、市场边界等 |
来源分级规则：
搜集完信息后，进行系统性分析，形成有判断力的结论。
根据调研类型和行业背景，从框架库中选择合适的分析方法。
框架路由表见 references/frameworks/_index.md，各领域详细框架见 references/frameworks/<领域>.md。
此处只列选择逻辑：
选择流程：
frameworks/_index.md 路由表 + frameworks/general.md）frameworks/internet-*.md，金融 → frameworks/finance-*.md）不确定时默认：通用底座框架（PESTEL + 竞争格局 + 价值链）+ 咨询视角
调研报告的价值在于有判断，不只是罗列信息。
假设回顾：
结论要求：
反面观点：
报告中的图表是专业性的重要体现。根据内容需要自动选择合适的图表类型，不限制数量。
报告配图不带标题：图表标题由报告正文的章节标题承担，图表本身的
title设为空字符串。避免标题重复。
统一使用 Diagram Skill 的固化脚本（bridge.py 和 capture.py），无需安装额外依赖。
禁止手动调用 Playwright MCP 工具截图（
browser_navigate、browser_take_screenshot、browser_run_code等）。所有图表截图统一通过 bridge.py / capture.py 完成，它们内部已封装 HTTP 服务启动、ELKjs 异步等待、Retina 2x 输出等逻辑。
统计图表（bridge.py 生成，JSON 配置 → PNG）：
| 图表 | 适用场景 | bridge type |
|---|---|---|
| 柱状图 | 离散项对比（性能、功能评分、市场份额） | bar |
| 折线图 | 趋势变化（时间序列、版本演进） | line |
| 饼图/环形图 | 占比构成（市场份额、成本结构） | pie |
| 雷达图 | 多维度综合评估（产品能力雷达图） | radar |
| 热力图 | 矩阵型数据（功能支持矩阵、相关性） | heatmap |
| 散点图/气泡图 | 分布关系（性价比分布、性能-成本关系） | scatter |
| 漏斗图 | 转化漏斗（用户转化、销售漏斗） | funnel |
| 瀑布图 | 累计增减（利润变动、成本分解） | waterfall |
| 矩形树图 | 数据占比/层级面积（市场份额、成本结构） | treemap |
| 柱线混合图 | 柱状+折线叠加（收入趋势+增长率） | combo |
结构图表（需要时由 Claude 直接编写 HTML + capture.py 截图，参考 Diagram skill 模板）：
| 图表 | 适用场景 |
|---|---|
| 流程图 | 工作流程、决策流程、数据流 |
| 架构图 | 系统架构、技术栈、模块关系 |
| 泳道图 | 多角色协作流程、跨系统交互 |
| 时序图 | 调用链路、消息传递序列 |
| ER 图 | 数据库表结构、实体关系 |
| 类图 | 面向对象设计、接口关系 |
| 状态图 | 状态机、生命周期流转 |
| 思维导图 | 知识结构、主题发散 |
| 甘特图 | 项目排期、里程碑 |
| 决策树 | 选型决策、条件分支 |
| 网络图 | 网络拓扑、节点连接 |
| 组织结构图 | 团队架构、汇报关系 |
| 时间线 | 发展历程、版本演进 |
| 数据流图 | 数据管道、ETL 流程 |
| C4 图 | 系统上下文、容器、组件视图 |
| 桑基图 | 流量路径、资源分配 |
| 旅程图 | 用户体验旅程、触点分析 |
| Kanban | 项目管理看板、任务状态 |
| Git Graph | Git 分支工作流、合并策略 |
调用方式：
# ── Markdown 模式（默认）──
# 方式 1：JSON 文件输入
echo '<JSON配置>' > /tmp/chart-config.json
python ~/.claude/skills/diagram/scripts/bridge.py -c /tmp/chart-config.json -o docs/research/assets/<文件名>.png
# 方式 2：管道输入
echo '<JSON配置>' | python ~/.claude/skills/diagram/scripts/bridge.py -o docs/research/assets/<文件名>.png
# ── HTML 模式 ──
# 输出自包含 HTML 片段，后续直接嵌入报告
python ~/.claude/skills/diagram/scripts/bridge.py -c /tmp/chart-config.json -o /tmp/<文件名>.html -f html
JSON 配置格式：
{
"type": "bar",
"title": "图表标题",
"subtitle": "副标题（可选）",
"data": { ... }
}
各图表类型的 data 结构：
| type | data 结构 |
|---|---|
bar | { "categories": [...], "series": [{"name": "名称", "values": [...]}] } |
line | { "categories": [...], "series": [{"name": "名称", "values": [...]}] } |
pie | { "items": [{"name": "名称", "value": 数值}] } |
radar | { "labels": [...], "series": [{"name": "名称", "values": [...]}] } |
heatmap | { "xLabels": [...], "yLabels": [...], "data": [[x索引, y索引, 值], ...] } |
scatter | { "xLabel": "X轴", "yLabel": "Y轴", "series": [{"name": "名称", "data": [[x, y], ...]}] } |
funnel | { "stages": [{"name": "名称", "value": 数值}] } |
waterfall | { "items": [{"name": "名称", "value": 数值, "type": "start|increase|decrease|total"}] } |
treemap | { "items": [{"name": "名称", "value": 数值, "children": [...]}] } |
combo | { "categories": [...], "bars": [{"name": "名称", "values": [...]}], "lines": [{"name": "名称", "values": [...]}] } |
scatter 支持气泡图：data 中传 [[x, y, size], ...]，size 越大气泡越大。
需要流程图、架构图等结构图时，直接编写 HTML 文件，然后用 capture.py 截图/导出：
# ── Markdown 模式（默认）──
python ~/.claude/skills/diagram/scripts/capture.py <HTML文件路径> docs/research/assets/<文件名>.png
# ── HTML 模式 ──
# 输出自包含 HTML，或直接使用手写的 HTML 源文件
python ~/.claude/skills/diagram/scripts/capture.py <HTML文件路径> /tmp/<文件名>.html -f html
HTML 编写参考 ~/.claude/skills/diagram/templates/html/ 下的模板和 lib/base.css 样式。
Markdown 模式：
docs/research/assets/ 目录<报告名>-<图表描述>.png，例如 redis-benchmark-bar.pngls -la 确认文件存在和大小，不要用 Read 工具查看 PNG，避免图片加载到会话上下文触发多图尺寸限制HTML 模式：
/tmp/ 目录，后续直接读取 HTML 内容嵌入报告Read 工具读取生成的 HTML 文件，提取 <body> 内的 SVG/图表内容嵌入报告通用：
Markdown 模式：用相对路径引用 PNG：
HTML 模式：直接嵌入图表 HTML 片段，用 .chart-container 包裹：
<div class="chart-container">
<div class="chart-inner">
<!-- 此处粘贴 bridge.py -f html 输出的 SVG 或图表 HTML -->
</div>
<p class="chart-caption">图表说明文字</p>
</div>
每张图表紧跟在相关分析文字之后，配简要说明文字解读图表要点。
报告中不是所有"流程/命令"都值得调 bridge.py / capture.py。以下两类直接写成 Markdown 代码块，preview-md / HTML 报告会自动渲染为带样式的图示：
```flow：方法论流程、决策树、阶段串联（≤ 10 个节点）
```terminal：调研中执行的关键命令、CLI 输出示例
```bash完整语法和示例见 preview-md SKILL.md "扩展语法"章节。
选型决策：
需要图示？
↓
数据可量化？→ bridge.py（柱状/折线/饼图等）
↓
结构复杂或多角色？→ capture.py（流程/时序/架构图）
↓
轻量流程/命令展示 → ```flow / ```terminal 代码块
Markdown 模式（默认）：
docs/research/
├── YYYY-MM-DD-<命题关键词>.md ← 报告正文
└── assets/
├── <报告名>-<图表1>.png
├── <报告名>-<图表2>.png
└── ...
HTML 模式：
docs/research/
└── YYYY-MM-DD-<命题关键词>.html ← 自包含 HTML 报告（图表内嵌，无 assets）
报告结构由内容形态决定——先看手上有什么内容，再调对应组件，自然组合成文。不预设"必备章节"，不按调研类型套模板。
组件库：references/report-blocks.md 是调研报告的组件库（一句话结论 / Executive Summary / 现状基线 / 假设验证表 / 反面观点 / 置信度标注 / 对比表 / 评分雷达 / 场景化推荐 / 调查拓扑 / 来源分级 等）。通用组件（表格 / 卡片 / Timeline / Callout / Chart）复用 writing skill 的 references/components.md，本 skill 不重复。
| 你手上有什么内容 | 调哪个组件 |
|---|---|
| 一句话能说清的核心判断 | 一句话结论（report-blocks A1） |
| 3-5 条要点决策者得先看到 | Executive Summary（A2） |
| 调研投入数据需要被看见 | 报告头元信息（A3）+ 调查拓扑表（E1） |
| 内部数据 + 外部基准对比 | 现状基线段（B1）；无内部数据用 B2 一行 callout |
| 走完了 1.6 假设流程 | 假设验证表（C1） |
| 收到了真实反方证据 | 反面观点与回应（C2） |
| 结论置信度有差异 | 结论 + 置信度标注（C3） |
| 多方案多维度对比 | 对比表（D1）+ 评分雷达（D2，≥3 维度时） |
| 结论不应一刀切 | 场景化推荐表（D3） |
| 跨来源数据有口径差异 | 口径说明 callout（E2） |
| 引用了多个来源 | 来源分级参考资料（F1）+ 行内标注（F2） |
| 大段数据 / 趋势 | Chart-Container + bridge.py |
| 多角色流程 / 架构关系 | Chart-Container + capture.py |
| 多发展阶段 | Timeline（writing skill） |
| 关键数字独立强调 | Metric-Card（writing skill） |
内容 → 组件 → 组合 ✅ 内容驱动
调研类型 → 模板 → 填空 ❌ 模板驱动
references/templates/_common.md 收录了少量历史常见的章节顺序示例——只作为"别人通常怎么组合"的参考，不作为必备清单。直接看 report-blocks.md 选组件即可，不需要先选模板。
当输出格式为 HTML 时，参照 references/html-report-template.html 模板直接编写 HTML 报告。
写作流程：
references/html-report-template.html，复制完整 HTML 结构（含 CSS + JS）{{REPORT_TITLE}} 等占位符.exec-summary 区域<article> 标签内用 <h2>/<h3> 组织章节（目录 JS 自动提取）.chart-container 包裹嵌入.references 区域按 T1/T2/T3 分组可用的富文本组件（模板注释中有完整示例）：
| 组件 | 类名 | 适用场景 |
|---|---|---|
| 图表容器 | .chart-container | 嵌入 SVG/HTML 图表 |
| 卡片网格 | .card-grid + .card | 方案速览、关键发现并列展示 |
| 评分条 | .score-bar | 多维度量化评估（如性能/生态/成本） |
| 对比块 | .vs-block + .vs-col | 方案 A vs B 双栏对比 |
| 时间轴 | .timeline + .tl-item | 路线图、技术演进 |
| 行内徽章 | .badge | 表格/标题中的状态标签 |
| 提示框 | .callout | 关键发现、警告、提示 |
| 来源徽章 | .tier-badge | 数据来源层级标注 |
引用标注（HTML 模式）：
数据描述<sup><a href="#ref-1">1</a></sup><span class="tier-badge tier-t1">T1</span>
输出要求：
.html 文件，所有 CSS/JS 内联，浏览器直接打开docs/research/YYYY-MM-DD-<topic>.htmlopen 命令在浏览器中打开供用户 review正文中使用上标编号标注数据来源，指向末尾参考资料列表（不使用脚注，避免脚注和参考资料重复）：
Redis 在高并发场景下的 p99 延迟通常低于 2ms[1]，
而 Memcached 在相同条件下约为 1.5ms[2]。
末尾参考资料按来源层级分组，编号与正文对应：
## 参考资料
### 一手来源 [T1]
1. [Redis 官方 benchmark 文档](https://redis.io/docs/...) — p99 延迟数据
### 二手来源 [T2]
2. [InfoQ Redis vs Memcached 性能对比](https://www.infoq.cn/...) — 对比测试数据
引用原则：
报告写完后，自动执行以下 5 项检查。可自动修复的问题直接修复，需要判断的列出供用户决定。
不再检查"必备章节是否齐全"，改为检查 1.1-1.6 中识别出的内容形态是否都有对应组件承载——避免"忘了写"，但不强求模板。
| 内容形态（在调研中是否存在） | 应有的组件 | 检查方式 |
|---|---|---|
| 调研得出了核心判断 | 一句话结论（report-blocks A1） | 报告首句存在结论性表述 |
| 决策者需要快速看到 3-5 个要点 | Executive Summary（A2） | 存在 ≤500 字 summary 段 |
| 命题完整走了 1.6 假设流程 | 假设验证表（C1） | 表存在，1.6 列出的假设逐一出现 |
| 1.4 摸到了内部数据 | 现状基线段（B1） | 段存在并区分内部/外部 |
| 1.4 无内部数据 | 缺失声明 callout（B2） | 一行 callout 标注公开数据 |
| 搜集中找到了反方证据 | 反面观点与回应（C2） | 段存在，每条配回应 |
| 多个结论且置信度不一 | 结论 + 置信度标注（C3） | 每条结论带置信度 + 来源层级 |
| 走了 Multi-Agent | 调查拓扑表（E1） | 指标表 + sub-agent 分解，与拓扑文件对账 |
| 有引用来源 | 来源分级（F1） | 按 T1/T2/T3 分组，每条带层级 |
处理方式：
逐条扫描参考资料章节，检查：
[T1]/[T2]/[T3] 层级标记[标题](URL) — 引用说明处理方式：可自动修复。
检查假设验证表的完整性：
处理方式：
⚠️ 待补充），在终端提示逐条检查「核心结论」章节中的每个结论：
处理方式：不可自动修复。在终端逐条列出不达标结论及其当前来源情况，询问用户是否补充搜索。
核对报告的"调查拓扑"段与 /tmp/research-topology-<timestamp>.json 记录文件：
## 调查拓扑 段agent_id / parent_id / budget_used / status 字段与拓扑文件一致，不得遗漏abandoned_leads 非空时，报告必须列出"放弃的线索"子节处理方式：可自动修复。
报告写完
↓
读取报告全文 + 拓扑文件 `/tmp/research-topology-<timestamp>.json`，逐项执行 5 项检查
↓
自动修复可修项（检查 2 引用格式、检查 3 表格式、检查 5 拓扑段）
↓
在终端输出检查摘要
↓
有不可修项？→ 列出问题，逐项询问用户处理意见
↓
用户决策（补写 / 补充搜索 / 跳过）→ 执行 → 完成
↓
清理 `/tmp/` 下本次调研产物（拓扑 / 计划 / 子文档）
检查完成后在终端输出以下格式的摘要（不写入报告文件）：
📋 报告质量自检
─────────────────────────────────────
✅ 结构完整性：N/N 必备章节齐全（N = 当前模板必备章节数）
🔧 引用格式：修复了 N 处问题（具体：补充了 X 个层级标记，调整了 Y 条格式）
✅ 假设验证表：N 个假设均有验证结果和证据来源
⚠️ 核心结论来源支撑：
· "结论内容摘要A" → 仅 1 个 T3 来源，不达标
· "结论内容摘要B" → 2 个独立 T2 来源，达标
🔧 调查拓扑：派发 N 个 sub-agent，最深 L 层，search/fetch 共 M 次；自动回填 X 处数字
总计：N 项通过，M 项需处理
─────────────────────────────────────
如果有不达标项，逐项询问：
⚠️ "结论内容摘要A" 仅有 T3 来源支撑。
→ 补充搜索以找到 T1/T2 来源？(y/n)
如果全部通过：
✅ 质量自检全部通过，报告已完成。
文件路径：<报告文件路径>
以下维度不易自动化，作为自检提醒在完成 4 项自动检查后快速过一遍：
如发现问题，当场修复后继续。