深度调研（Deep Research）
先摸清内部现状，再对标外部水位，找到差距，指导行动。产出有判断、有依据、经得起反面追问的专业研究报告。
核心理念：6 步是能力库，不是必走流程。技能将调研拆解为六个步骤：理解命题 → 多跳搜集 → 分析结论 → 图表生成 → 撰写报告 → 质量自检。这 6 步是能力清单，按命题复杂度调用——简单事实查询硬走 6 步是浪费，复杂研究跳过任何一步都会丢深度。
一、调研深度判断与路径
收到调研需求后，先判断命题复杂度决定路径。简单事实（单一明确问题，如「Redis 7 新特性」「某 API 用法」）由 Lead 自查直接搜索，输出简短答复，不出报告；对比类（两到三方案对比，如「Redis vs Dragonfly」）走缩减版流程，派 2-4 个 sub-agent，输出中等篇幅 MD；复杂研究（需建立全景认知，如「AI Agent 赛道」）走完整 1-6 步；超深度（跨产业链、多维度，如「半导体国产替代」）走完整流程加多轮迭代与 sub-sub-agent，输出长篇 HTML。
核心原则包括：简单事实查询禁止启动 Multi-Agent；对比类调研可省略部分能力；复杂研究走完整 6 步；报告结构由内容形态决定，没有对应内容就不要硬上对应组件。
二、第一步：理解命题，摸清现状
命题解析需向用户确认核心问题、调研动机、期望深度、关注维度、已有认知、内部数据源、评估基准等，已知的跳过、模糊的追问。随后判断调研类型：技术选型、行业分析、概念研究、性能评测、竞品分析、可行性探索。评估不是独立类型，所有调研类型都内含评估逻辑——先理解内部现状，再对标外部水位。
信源矩阵加载设有多道闸门：具体查询由 Lead 自查官方 docs，跳过 YAML 加载；命题调研则进入关键词匹配，按金融、学术、技术/AI 等类别加载对应信源，并全域加载黑名单过滤。搜索预算分配上，有白名单时 70% 倾斜冷门权威 + 20% 开放搜索 + 10% 启发式发现；纯启发式时 60% P1 一手 + 30% P2 原厂/评测 + 10% P3 审核社区。
现状摸底（所有调研类型必做）在外部搜索前先理解自身状态，数据来源分内部数据、半公开数据、公开数据三个层级，并按调研类型明确摸底重点，如技术选型关注当前技术栈、性能瓶颈、团队技能。无内部数据时记录为「内部数据缺失」。
快速扫描围绕命题设计 3-5 个不同角度搜索词，只看摘要与标题，耗时 1-2 分钟，产出简短扫描摘要。基于内部现状与扫描结果形成 2-4 个「我认为 X，因为 Y」格式的可验证假设。最后与用户对齐，展示调研命题、类型、报告风格、输出格式、复杂度、执行预算、预计 Token 消耗、初始假设、内部数据源、预计涵盖维度等，确认后进入下一步。输出格式默认 Markdown，用户提到「HTML」「网页版」「富文本」「交互式」等时选 HTML。
三、第二步：多跳信息搜集
采用 Orchestrator-Subagent 架构，Lead Agent 负责规划与整合，Sub-agent 独立并行深挖，避免单一 context 被原始材料撑爆。Lead 职责包括拆解子问题、按 Scaling Rules 决定 sub-agent 数量与预算、写入 plan 文件、维护拓扑记录文件、注入信源矩阵、只读压缩 JSON 回传、按触发规则判断是否 fork、最终 synthesis 产出报告。Sub-agent 独立 context、专注单一子问题、预算内完成并回传结构化 JSON，长文档存 /tmp/。所有 sub-agent 必须使用 Agent 工具派发，指定 subagent_type: "general-purpose" + model: "sonnet"，Lead 保持当前调用模型不变，sub-agent 之间不直接通信。
迭代式深挖设迭代上限：synthesis 轮次 ≤ 3 轮，递归深度 ≤ 3。节点级 Fork 触发规则包括：confidence 为 low 且关系核心结论、出现 surprises、不同 sub-agent 证据矛盾、核心命题反面 findings 少于 2、仅有 T2/T3 支撑。终止条件为所有假设有 T1 源或 2+ 独立 T2 源支撑、反面证据搜索无新发现、Round 3 后无新信息。
Scaling Rules 规定各类命题的 sub-agent 数与工具预算，如复杂研究 5-10 个 sub-agent、每个 WebSearch ≤ 10 / WebFetch ≤ 15。并指出 Multi-Agent 架构消耗约 15x chat tokens，简单事实查询禁止开 Multi-Agent。
Sub-agent 压缩回传协议要求回传结构化 JSON，包含 topic、findings（claim、evidence、urls、source_tier、confidence、date）、surprises、gaps、budget_used、whitelist_hits、heuristic_hits、blacklist_avoided 字段，禁止回传原始 HTML、未精简搜索结果、单条引文超 100 字、省略 source_tier 或 confidence。
调查拓扑记录协议使用 /tmp/research-topology-<timestamp>.json 记录 agents 条目与 abandoned_leads，Spawn 前追加条目，回传后更新 budget_used / findings_count / status，fork 时填 parent_id 和 round，主动放弃线索不得静默丢弃，报告完成后清理临时文件。
搜索执行使用 WebSearch 与 WebFetch，涉及本地项目时结合 Grep/Read。页面抓取采用分层策略：WebFetch 直接请求 → 失败则 Playwright 浏览器模拟 → 仍失败则换源搜索。抓取纪律要求同域名连续请求间隔至少 2 秒，连续 2 次失败放弃该站点，Playwright 用完即关。
信息记录与来源分级将来源分为一手 [T1]、二手 [T2]、三手 [T3]，并记录数据范围、年份、统计口径等属性。核心结论必须基于至少 1 个一手来源或 2 个独立二手来源。信息验证原则包括多源交叉、时效性、去伪存真、标注不确定性、假设对照。
四、第三步：分析与结论形成
对信息去重分类，识别共识点与争议点，提取关键数据点。根据调研类型和行业背景从框架库选择分析方法，选择流程为：确定调研类型 → 查通用框架推荐 → 判断行业背景叠加特化框架 → 判断分析视角调整产出重点；不确定时默认通用底座框架加咨询视角。形成判断阶段逐一回顾初始假设，标注已验证、已证伪、证据不足三种结果，并作为核心结论骨架。结论要求有数据或事实支撑并标注来源层级，每个核心结论标注置信度（高/中/低），存在不确定性时说明条件和假设，给出可操作建议。反面观点环节对每个核心结论考虑「如果反过来呢」，列出反面证据并给出回应。
五、第四步：图表生成
报告配图不带标题，图表 title 设为空字符串，由正文章节标题承担。统一使用 Diagram Skill 的固化脚本（bridge.py 和 capture.py），禁止手动调用 Playwright MCP 工具截图。统计图表（柱状图、折线图、饼图/环形图、雷达图、热力图、散点图/气泡图、漏斗图、瀑布图、矩形树图、柱线混合图）通过 bridge.py 以 JSON 配置生成；结构图表（流程图、架构图、泳道图、时序图、ER 图、类图、状态图、思维导图、甘特图、决策树、网络图、组织结构图、时间线、数据流图、C4 图、桑基图、旅程图、Kanban、Git Graph）通过编写 HTML 再经 capture.py 截图。
Markdown 模式输出保存到 docs/research/assets/ 目录，文件名格式为 <报告名>-<图表描述>.png，默认 2x Retina 输出；禁止 Read PNG 文件，生成后只用 ls -la 确认。HTML 模式图表暂存 /tmp/ 目录，用 Read 读取后提取 <body> 内内容嵌入报告。图表必须包含标题、坐标轴标签（统计图）、图例（多系列时）。每张图表紧跟相关分析文字之后，配简要说明。