# Multi Source Inquiry

> 当答案需要联网检索或独立多源验证，包括事实核查、技术对比、当前信息、冲突说法、重要建议，以及需要多轮深挖、迭代收敛的深度研究时使用。

- Skill: `cuipengfei/multi-source-inquiry` (Agent Skill)
- Install (CLI): `npx skillmds@latest add cuipengfei/multi-source-inquiry`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cuipengfei/multi-source-inquiry/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: cuipengfei (https://skillmd.com/u/cuipengfei)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/cuipengfei/multi-source-inquiry

---


# 多源研究技能

先评估研究规模，再按统一的多轮骨架执行：探路、定指标、深挖、收敛、报告。规模不决定走不走多轮，只决定每轮的广度、并行度和轮次预算。任何输入先 SIFT 一遍：Stop（先暂停别急着用）、Investigate the source（查谁说的）、Find better coverage（找更可信的覆盖）、Trace claims（追到原始出处），再决定规模档。

## 1. 评估主题规模

主题不清时，只问一个澄清问题：研究对象、范围或成功标准。主题清楚时直接打分：

| 维度 | 满足条件 |
|------|----------|
| 子主题 | 涉及 2+ 个独立问题或对象 |
| 来源 | 需要 2+ 类来源，如官方文档、论文、源码、新闻、社区 |
| 分析 | 需要比较、排名、趋势、因果或方案判断 |
| 时效 | 结论依赖日期、版本、政策或近期变化 |
| 风险 | 错误结论会影响重要决策、金钱、法律、医疗或安全 |

| 得分 | 档位 | 轮次预算与并行度 |
|------|------|------------------|
| 0-1 | 小型 | 探路轮即主轮：1-2 个高可信来源，证据足则当场收敛 |
| 2-3 | 中型 | 探路 + 定指标 + 至多 2 个深挖轮；多类 MCP 搜索工具并行自搜 |
| 4-5 | 大型 | 探路 + 定指标 + 至多 3 个深挖轮；按缺口派并行 sub-agent |

用户指定范围或禁用来源时，以用户限制为准。用户指定轮次上限时，以用户上限为准。

## 2. 多轮研究循环（默认骨架）

所有档位共用同一骨架：探路、定指标、深挖、收敛、报告。档位只决定每轮的广度、并行度和轮次上限（见【规模档表】）。

先宽后窄（中/大型题或多轮研究）：宽查询在前，指标、子题、关注点从宽结果里长出来，窄深挖在最后；跳过宽查询直接深挖单点，是违规。小型题按【规模档】收敛，不受此限。

次序：**探路（宽查询）→ 定指标（维度/子题从宽结果长出）→ 深挖（窄，只攻缺口）→ 收敛。**

1. **探路（宽）**：用 1-2 类搜索工具做一轮宽查询，产出主题地形简报：关键实体、核心争议、可用来源类型、子问题候选。小型题在这一轮证据已足就直接收敛，不强制后续轮。
2. **定指标（从宽产出）**：主 agent 读探路简报，定出本次研究的评估维度或子题清单。大型题复用【MECE 维度表】拆分；中小题列 2-5 个待证关键问题即可。指标来自探路发现的线索，不套固定模板。多对象对比时，维度必须所有研究对象都能回答。
3. **深挖（窄）**：每轮只攻上一轮留下的缺口。查询词或子任务必须由上一轮的发现显式驱动：新实体、新冲突、未覆盖维度。不重复已覆盖的查询。大型题按维度派并行 sub-agent（委托契约见【大型研究路径】）；中小题自己搜。深挖双触发：缺口驱动 + 用户点名维度；点名时升级 effort，直读底层实现（源码/状态机/协议原文）。
4. **每轮结束做缺口盘点**：列出已覆盖（附证据标记）、仍缺口、新线索三栏，据此决定下一轮打哪里，或者停。
5. **收敛判停**：以下任一信号满足即停，并在报告写明判停依据：
   - a) 覆盖全：所有关键维度已有证据，或显式标 `[unknown]` 并说明查过什么；
   - b) 无新增：本轮没有新增关键事实或独立来源，继续搜的预期收益约为零；
   - c) 到上限：用完【规模档表】的轮次预算。上限是安全预算，不代表信息已饱和；到上限而停时，必须把未覆盖维度标 `[unknown]`。
6. **报告**：按【输出格式】写，首行记录实际轮次与判停信号。

## 3. 大型研究路径

仅当得分 4-5，或用户明确要求深度研究/多 agent 并行时使用。

**MECE 拆分**：选择一个主维度，必要时加一个次维度。

| 维度 | 适用场景 |
|------|----------|
| 对象 | A/B/C 方案、产品、框架、公司对比 |
| 视角 | 技术、商业、用户、合规、安全等视角 |
| 时间 | 历史、现状、近期变化、趋势 |
| 来源域 | 官方/源码、学术、一手数据、社区/媒体 |

生成候选子题后，合并重叠项、补齐遗漏项，最终保留 **3-6 个**边界清晰的子任务。每个子任务必须能独立完成，且共同覆盖用户问题。

**委托规则**：无依赖子任务并行交给 sub-agent；若当前环境没有 sub-agent 工具，则按子任务顺序手动执行并在结果中标注未并行。主 agent 不重复全量搜索，只做汇总、去重、冲突处理和最终判断。

多对象对比且对象间可独立取证、对比维度已统一时，按对象切分，每对象一子代理，交付压缩简报、禁止倾倒原文；否则沿用 MECE 维度切分。用户澄清范围时，立即重发已派子任务，不沿用旧范围。子代理分批补交时，逐条标「修正/补强」——修正指推翻旧结论，补强指新增证据；更新报告只标注，不重写全文。

每个 sub-agent prompt 必须包含：

- 子任务边界、排除范围、成功标准
- 建议来源类型或工具类型
- 输出格式：2-3 句摘要、关键证据、完整精确 URL、可信度标记；只交付支撑关键结论的 URL，不列辅助命中大全
- 反方查询（见【搜索与证据】）的 `工具 / 完整 query / 命中数 / 结论` 必须写进交付，不能只写「已查」
- 「编码相关任务请先加载 `karpathy-guidelines` skill 并在最终回复末尾给出 karpathy 证据小结。」

## 4. 搜索与证据

- 先盘点当前可用的搜索类 MCP 工具：网页搜索、内容抓取、官方文档、代码搜索、仓库文档、结构化数据等。
- 在不扩大用户范围的前提下，尽可能使用多种相关 MCP 搜索工具；默认目标是 3 类，至少 2 类。只有 1 类可用时标注 `单源限制`。
- 优先高可信来源：官方文档、源码、release notes、标准、论文、一手数据。
- 社区、博客、教程可补充解释，但不能单独支撑关键结论。
- 独立请求尽量并行；每条结果必须先提炼主判断，再按“判断 / 限定 / 证据”分层组织。最终输出必须留出清楚留白，写成可扫描的短块；禁止把结论、限定、证据、来源、冲突塞进同一段或同一条密集 bullet。
- 记录来源工具、标题、完整精确 URL、发布日期或版本。完整精确 URL 必须指向支撑该说法的具体页面、源码 permalink、论文 DOI/landing page、release note、标准页或一手公告；不要用搜索结果页、站点首页、短链、聚合页替代。
- 对关键重要信息必须保留完整精确 URL。关键重要信息包括：要点区结论、置信度标记依据、排名/推荐/风险判断、冲突来源、反方证据、会影响用户行动或技术决策的事实。
- 辅助来源只用于理解背景时，不必全部列入最终输出；若未列全，说明“辅助来源已查但未逐条列出”。不要把搜索命中结果当 bibliography 堆给用户。
- **反方查询**：任何会被标 `[verified]` 的关键结论，必须至少跑一次反方向查询，针对该结论的**具体否命题或反主张**（例如原结论「X 比 Y 快」→ 反方查询「Y 比 X 快的 benchmark」「X 的性能退化案例」，而不是泛泛的「X criticism」）。实际跑过的反方 query 串与命中条数需写进证据链或单独一段，供主代理与用户审查。未找到反证只能记为「未发现反对证据」（可能只是查询词/语言域/工具覆盖不够），不能单独提高置信度；搜出实质反对意见则原结论降级为 `[conflicting]` 或 `[likely]`。

若搜索为空，说明已尝试的 MCP 工具、关键词和来源类型，并给出下一步建议。

## 5. 交叉验证

| 标记 | 条件 |
|------|------|
| `[verified]` | 关键结论：3+ 独立来源支持，且至少 1 个高可信。一般事实：2+ 独立来源支持，且至少 1 个高可信。**若结论依赖时效**（标的是当前状态、版本、政策、价格等），来源发布日期还需落在主题对应的时效窗口内（例如「当前 API 行为」要求近 12 个月内来源），否则只能标 `[likely]` |
| `[likely]` | 2+ 来源但未达 `[verified]` 门槛（例如缺高可信来源，或属关键结论但只有 2 个来源） |
| `[single-source]` | 仅 1 个来源支持 |
| `[conflicting]` | 来源之间存在实质矛盾 |
| `[unknown]` | 未找到足够证据 |

`[verified]` 的关键结论还必须能给出完整精确 URL 证据；无法给出完整精确 URL 时，即使有多源摘要，也只能标 `[likely]` 或更低。

**证据形态轴**，与上述标记正交：一手直读（源码/实测/原文）/ 文档声明（官方文档/规范）/ 推断（分析得出）。固定写法：置信度仍只用 `[verified]` 等 canonical 方括号标记；形态另写为 `证据形态：一手直读/文档声明/推断`，不放进方括号、不造组合标记。

**独立性判定**：同一新闻稿转载、同一项目文档镜像、同一作者重复发布不算独立来源。**区分一手与转引**：3 个媒体转引同一份原始报道按 1 个独立来源算；只有追到不同的一手出处才算多源。**无法追到一手出处或无法判定是否同源时，按 1 个独立来源计**，并在标记后注 `[来源独立性未验证]`。矛盾无法消解时，列出各方说法和证据，不把推测写成事实。

## 6. 输出格式

### 关键 URL 引用规则

- 关键重要信息在正文里可以只保留短标签引用，例如 `[S1]`；完整精确 URL 必须出现在紧邻的来源条目中。不要为了就地塞 URL，把判断区写成密集大段。
- 每条关键结论默认引用 1-3 个最强来源；多源验证用最权威、最独立、最贴近原始出处的来源代表，不罗列所有辅助来源。
- 若一个 URL 同时支撑多条关键结论，可在来源小节列一次，并在正文用短标签引用，例如 `[S1]`，但 `[S1]` 对应条目必须包含完整精确 URL。
- 若无法取得完整精确 URL，不得标 `[verified]`；降级为 `[likely]`、`[single-source]` 或 `[unknown]`，并说明缺口。
- 用户明确要求完整 bibliography、审计清单或研究日志时，才列出全部来源 URL；否则保持关键来源最小集。

### 基调：像给人讲清楚，不像填表

报告形态由话题和研究发现决定，不套固定章节。查得浅就短答，冲突多就展开讲冲突，流程复杂就画图。证据可追溯是底线，不是格式要求。

### 底线（缺一即违规）

- 关键结论保留证据标记：只用【交叉验证】的 5 个 canonical（`[verified]`/`[likely]`/`[single-source]`/`[conflicting]`/`[unknown]`）。`[来源独立性未验证]` 是附加注记，不算第 6 个标记。不造变体；冲突消解写 `[conflicting]`，结果在正文说明。
- 关键结论能给出完整精确 URL；给不出就降级标记并说明缺口。
- 冲突、不确定性、证据缺口必须写出来，不为顺口抹平。
- 末尾一行：`轮次：<实际轮数>，判停：<a/b/c + 一句理由>`；大型再加 `拆分方式：<主维度> × <次维度>，共 <n> 个子任务`。
- 报告末尾列验证边界：哪些一手直读、哪些文档声明、哪些推断/未实测。
- 反直觉或绕过类推断无实测时，显式标「未验证，非事实」。
- 用户明确反馈报告难读时，先用比喻+行为语言给主判断摘要；路径、行号、URL 等定位信息保留在独立证据子项，不替换、不删除。

### 图例块（开头必放）

报告开头列本报告实际用到的标记，每个给一句白话。术语同理：正文每个技术词，要么在图例里，要么首现处一句白话。

### 面向不熟读者

用户通常对话题了解不深。讲功能和影响优先，不默认读者懂实现细节。自检：不查资料，能否抓住主判断和理由。

### 留白与节奏

- 结论、限定、证据分开放，一段只讲一件事，不揉长句。
- 长短句交错，短句为主。读起来像研究笔记，不像流程表。
- 合适就用 mermaid 画图（流程、角色关系、时间线），图只画关键结构，不放全部细节。
- 主判断在前，限定和例外跟在后，别藏在段落中间。

### 反例（禁止）

- 信息密块：一段同时承担结论、限定、证据、来源、冲突。
- 官腔八股：「必须指出」「值得注意的是」「综上所述」这类空壳连接。
- 自造标记变体（如 `[conflicting→已消解]`）。
- 术语只抛不解释。

**来源小节规则**：
- 来源小节默认只列关键来源。关键来源指直接支撑要点区结论、置信度标记、冲突判断、反方证据、排名/推荐/风险判断的来源。普通背景、重复转载、弱相关教程、搜索命中页不进入来源小节，除非用户要求完整来源清单。
- 每个来源条目必须包含完整精确 URL；`URL/出处` 不得只写域名、首页、搜索页、短链或“官方文档”这类不可直接定位的描述。
- 对支撑关键结论、或被反复引用的来源，单行注明 `[可信度 高/中/低，偏见说明]`（例如「[可信度 高，厂商自述，存在利益相关]」）。偏见说明须指明**具体偏见方向或利益关系**，不接受「可能有偏见」「立场中立」这类无信息标注。普通辅助来源不用。
- 对支撑 `[verified]` 关键结论的易变内容（新闻页、政策页、商业声明、个人博客等），优先提交 `https://web.archive.org/save/<URL>` 留档并在引用里挂归档链接；无法归档时标注「未归档」及原因。稳定官方文档、论文 DOI、源码 commit/permalink 不强制归档。

## 边界情况

保存路径：用户要求保存时写入 `docs/research/YYYY-MM-DD-<topic>.md`，否则只在对话中输出。工具不足、sub-agent 失败、结果重叠等情况，按本 skill 通用原则降级（标注限制、保留可用结果、去重后保留最权威来源）。

## 何时切换出本 skill

本 skill 处理多源研究与交叉验证。出现以下信号时，优先切到更合适的工具或 subagent，不要在本 skill 里硬撑：

| 信号 | 更合适的处理方式 |
|------|------------------|
| 需要查仓库代码实现、调用关系、本地文件结构 | 交给代码检索工具或代码探索 subagent（grep / read / ast 类）|
| 需要查 npm/pip/cargo 包 API、官方文档、外部库行为 | 交给文档/网页检索工具或文档检索 subagent |
| 涉及架构判断、多系统权衡、技术选型决策 | 交给顾问型/二级评审型 subagent，或主 agent 明说推理边界 |
| 需要执行计算、数据处理、命令验证 | 交给 shell/脚本执行工具 |
| 用户要的不是研究而是写代码/改代码 | 退出研究模式，交给实现环节 |