| name | deep-research |
| description | 深度调研/对比分析/研究报告：多轮检索 + 数据缺口回填 + 图表可视化 + 决策导向报告；也支持大规模多对象结构化调研（outline.yaml 拆解 + 断点续传 + 并行后台 agent + JSON 字段校验），后者来自 workbuddy 生态的 Deep-Research-skills |
| version | 1.2.0 |
| author | Hermes Agent |
| license | MIT |
| trigger | ["深度调研","调研","对比分析","研究报告","深度对比","全面对比","深度分析","deep research","market research","industry research","结构化调研","多对象调研","大规模调研","research outline"] |
| platforms | ["linux","macos","windows"] |
| metadata | {"hermes":{"tags":["Research","Analysis","Report","Comparison","Decision"],"related_skills":["arxiv","paper-analysis","llm-wiki"]}} |
| source | internal (hermes agent) + workbuddy Deep-Research-skills |
深度调研
把调研做成能帮人做决策的报告，不是资料堆砌。读者看完知道选什么、为什么。
输入识别（先判断再动手）
收到调研请求后，先识别类型再选策略：
| 类型 | 特征 | 策略 |
|---|
| 对比决策 | "X vs Y"、"哪个好"、"选哪个" | 走完整对比模板（速览表 + 决策矩阵） |
| 单主题深挖 | "调研 X 方案"、"X 怎么做" | 跳过对比速览，改为：现状→方案→优劣→建议 |
| 多候选选型 | 3+ 候选对象 | 对比速览扩展为多列，决策矩阵保留 |
维度确认：如果用户指定了维度（"从性能和价格两方面"），只深挖这些维度；未指定则由广度扫描自动发现。
附带材料：用户给了文档/链接作为输入时，先提取其中的关键信息作为调研起点，减少重复搜索已知内容。
调研方法论（3 阶段，按序执行）
本 skill 命中时，agent.md「搜索收敛原则」由下列数据清单替代——按清单逐项补全，不受 2-3 次限制。
渐进交付：调研过程中保持用户可感知的进度：
- 广度扫描后：输出"已识别 N 个维度：[维度列表]，开始逐项深挖"
- 每完成 1-2 个维度的深度补全：简短告知进展（如"定价和性能数据已收集完毕"）
- 缺口回填阶段如果耗时较长：说明正在核实哪些数据点
① 广度扫描（2-3 次搜索）
宽泛关键词勾勒全貌（如"X vs Y 对比"、"X 参数 性能 价格"）。目标：列出对比维度清单。
② 深度补全（逐维度抓一手来源）
每个维度抓官方/权威原始页面，不要只看二手博客：
- 参数 → 官方 spec / model card / HuggingFace
- 定价 → 官方 API pricing 页
- 性能 → 官方 blog + 权威榜单（Artificial Analysis、SWE-bench leaderboard、Arena）
- 市场 → 第三方统计（OpenRouter、头部媒体）
搜索策略：
- 语言：先英文搜（覆盖面广），再中文补充本地化信息（定价、合规、国内生态）
- 时效：优先近 6 个月来源；超过 1 年的数据需注明时间并标记可能过时
- 每维度 2-4 次搜索为上限，达到后进入下一维度
- 并行搜索：同一阶段内的多个维度可并行发起搜索请求
矛盾数据处理：来源间数据冲突时——①标注冲突（"A 称 X，B 称 Y"）②采信优先级：官方文档 > 权威榜单 > 第三方实测 > 媒体报道
③ 数据缺口回填（质量关键，不可跳过）
对照下方清单逐项检查，每项都要有数据，或标注"经 ≥3 处来源核实确未公开"：
- 搜不到 ≠ 不存在。换角度：官方英文文档、API pricing、HuggingFace、第三方实测、GitHub README。
- 同一数据交叉验证 ≥2 源；冲突取权威源并标注分歧。
- 禁止只搜 1-2 次就写"未公开/未披露"——至少试过官方定价页 + 2 个第三方来源后才可下此结论。
报告模板
根据输入识别的类型选模板。所有模板共享原则：决策优先 + 数据可视 + 来源可溯。
模板 A：对比决策（默认）
# {标题}
## 执行摘要（3-5 句，决策导向）
结论先行：推荐什么、关键数据**加粗**、点出 1 个反直觉发现。
## 对比速览（1 张表，全维度）
| 维度 | A | B | 差异 |
覆盖：参数/上下文/定价/开源/多模态/发布时间
## 关键维度深挖（每节配图表 + 内联引用）
### 定价与成本
- 价格表 + generate_chart(horizontalBar)
- ≥1 个成本场景计算（如 100K 输入 + 30K 输出总成本）
### 性能
- benchmark 表 + generate_chart(bar)
### 其他关键差异（按主题选）
## 选型决策矩阵
| 场景 | 推荐 | 理由 |（覆盖 5-8 个典型场景）
## 一句话结论
模板 B：单主题深挖
# {主题} 调研报告
## 执行摘要（3-5 句）
核心结论 + 关键数据 + 1 个意外发现或常见误区。
## 现状与背景
当前主流方案/做法是什么，痛点在哪。
## 方案梳理（每个方案配数据）
### 方案 1: {名称}
原理、适用场景、关键指标、局限性。
### 方案 2: {名称}
...
## 关键数据（配图表）
量化对比或趋势数据 + generate_chart
## 实践建议
| 场景 | 推荐方案 | 理由 |
## 一句话结论
图表（必须生成 ≥1 张）
用 generate_chart 工具，数据来自调研结果（不要编造）：
- 定价对比 →
horizontalBar（便宜的在上方直观）
- benchmark 对比 →
bar（多系列分组）
- 市场份额/排名 →
bar
- 趋势 →
line
内联引用（必须）
每个量化数据后标来源，格式：¥1/百万token `https://...` 或 [来源](url)。
web_search 返回卡片的 url 就是引用源，不要丢弃。
成稿前自检
完整 annotated 示例见 references/report-template.md（用 skill_read 查阅）。
模式二：大规模结构化调研（来自 workbuddy）
来源：本模式融合自 workbuddy 生态的 Deep-Research-skills（homepage: https://github.com/Weizhena/Deep-Research-skills），MIT 许可。与上面的「决策导向报告」互补：决策导向适合「X vs Y / 选哪个」这类给结论的报告；结构化调研适合「需要系统性盘点 N 个对象、每个对象按统一字段收集」的横向调研（学术综述、benchmark 对比、技术选型横评、竞品盘点）。
何时走模式二
当调研对象是多个并列实体、且每个都要按同一套字段收集数据时，用结构化流水线。典型：盘点 10 个 Agent 框架、对比 8 个向量库、综述某方向 20 篇论文、横向评估 5 家云厂商。
对象 ≤2 个、只要一个结论 → 走上面的决策导向模式，不要用本模式（重了）。
结构化流水线（4 步，按序）
Step 1 拆解：把话题拆成 items（调研对象）+ fields（统一字段），写入 outline.yaml / fields.yaml
Step 2 确认：展示 outline 给用户，确认 items 是否增减、字段是否齐全、并行度
Step 3 深挖：每个 item 一个后台调研任务（background_task 并行），逐字段收集数据，产出 <item>.json
Step 4 汇总：读全部 JSON，按 fields.yaml 结构汇总成 report.md
Step 1：拆解话题
基于已有知识列出：
- items：该领域的主要研究对象（如具体产品、框架、论文、公司）
- fields：每个对象要收集的字段（基本信息/技术特性/性能指标/定价/生态…），标注 required 与否
写入两个文件（模板见 references/structured-outline-template.yaml 和 references/structured-fields-template.yaml，用 skill_read 查阅）：
outline.yaml：
topic: 调研主题
items:
- name: 对象A
category: 分类
description: 一句话说明为什么纳入
execution:
batch_size: 3
items_per_agent: 1
output_dir: ./results
fields.yaml：
field_categories:
- category: 基本信息
fields:
- name: release_date
description: 发布日期
required: true
detail_level: 简要
Step 2：确认
把生成的 outline.yaml / fields.yaml 展示给用户，用 AskUserQuestion 确认：
- items 是否要增删？
- 字段框架是否够？
- 时间范围（近 6 个月 / 不限…）？
- 每批并行几个后台任务？
Step 3：深挖（断点续传 + 并行）
每个 item 发起一个 background_task，prompt 里写明：调研对象、要读的 fields.yaml 路径、输出 <item_slug>.json 路径、字段值中文、不确定标 [不确定] 并进 uncertain 数组。
断点续传：results/ 下已存在的 .json 视为已完成，跳过；中断后重跑只补缺的 item。一批跑完、用户同意后再起下一批。
每个后台任务产出 JSON 后，用 scripts/validate_json.py 校验字段覆盖率：
python <skill_dir>/scripts/validate_json.py -f <topic>/fields.yaml -j <results>/<item>.json
必填字段缺失（coverage < 100% 或 missing_required 非空）即视为失败，需补调研重跑。
Step 4：汇总报告
读全部 <item>.json，按 fields.yaml 的 field_categories 结构汇总为 report.md：
- 开头给总览表（每个 item 一行 + 关键摘要字段，如 stars/score/date）
- 正文按 item 分节，逐字段展示
- 值含
[不确定] 的字段跳过或标注"未确认"
- 多出的、fields.yaml 没定义的字段归入「其他信息」
脚本与模板
scripts/validate_json.py — 校验 JSON 是否覆盖 fields.yaml 全部必填字段（用法见上）references/structured-outline-template.yaml — outline.yaml 模板references/structured-fields-template.yaml — fields.yaml 模板（含常用字段分类，可扩展）- 完整工作流说明见
references/structured-workflow.md（用 skill_read 查阅）
