deep-research

深度研究——迭代式研究引擎

一款自主、多步骤的研究引擎，可进行全面的信息收集与综合分析。与单次 web_search 不同，此技能实现了一个迭代循环，由 Agent 规划、搜索、提取、综合信息并决定何时停止，最终生成一份附有引用的报告，其中包含结构化证据、来源质量等级，以及明确列出的空白和矛盾。

有关 evidence.json 层，请参阅 references/structured-evidence-format.md；有关自适应深度概念映射，请参阅 references/docsgpt-concepts.md。

适用场景

• 用户提出“深度研究”“研究报告”“全面分析”等要求
• 用户想要针对某个主题撰写报告（而非仅获取快速解答）
• 问题需要综合多个来源并附上引用
• 用户说“深入调查 X”或“撰写一份关于 X 的报告”

不适用场景

• 实体审查/档案 → 使用 entity-research（具备制裁筛查和结构化视角）
• 定期新闻摘要 → 使用 news-monitoring（具备 cron、去重和多语言支持）
• 基于已收集来源的问答 → 使用 notebooklm-mode（具备知识库 + RAG）
• 快速事实查询 → 直接使用 web_search
• 单一来源提取 → 使用 web_search + web_extract

架构

User question
  → Step 0: Clarification (optional — assess if question is too vague)
  → Step 1: Plan (sub-questions, key topics, success criteria, category, language, complexity)
  → Step 2: Date grounding + language anchor
  → Step 3: Iterative loop (max rounds = complexity cap: simple=2, moderate=3, complex=5)
      ├─ 3a: Generate gap-driven queries (incl. refute queries from round 2+, empty-search refinement)
      ├─ 3b: Search (web_search) + fetch (web_extract)
      ├─ 3c: Quality filter + extraction + source quality classification + numbered citations
      ├─ 3d: Synthesize into cumulative research state (with token budget check)
      ├─ 3e: Structured evidence (optional: evidence.json for 5+ sources)
      └─ 3f: Stopping check (LLM evaluates coverage + token budget)
  → Step 4: Final report (overview-first structure, see template)
  → Step 5: Stats summary

报告输出顺序（概览优先）： 执行摘要 → 对比/概览表 → 各子问题的详细分析 → 矛盾 → 信息空白 → 结论 → 来源表。读者可先获取答案和一目了然的对比，再阅读详细推理。

步骤 0——澄清（可选）

开始规划前，先评估问题是否足够具体，能否开展有效研究。此步骤可避免在过于模糊的问题上浪费轮次。

需要澄清的情况：

• 问题只有 1 至 5 个词，且没有范围限定（“研究 AI”“介绍一下量子计算”）
• 问题可能因意图不同而有截然不同的含义（“X 好吗？”——对什么好？适合谁？）
• 问题缺少明确的切入点（“研究气候变化”——科学、政策还是经济方面？）

无需澄清的情况：

• 问题已包含子问题或具体参数
• 用户明确表示“直接研究”或“别问，开始吧”
• 问题足够具体，可立即生成有效的搜索查询
• 问题是简单的事实查询（“X 的最新版本是什么？”“Y 是什么时候发生的？”）——即使问题很短，只要意图明确，就直接开始
• 用户正在回应此前的澄清问题（不要循环追问）

方式： 向用户提出 1 至 3 个简短问题，以缩小范围。简明扼要即可——这是范围确认，不是面试：

“开始研究前，我想先确认：

1. [缩小范围的问题 1]
2. [缩小范围的问题 2]

请提供这些信息，我就开始。”

如果问题已经足够具体，则完全跳过此步骤，直接进入步骤 1。

第 1 步 — 研究计划

搜索之前，先将问题拆解为研究计划。输出：

## Research Plan
Question: [user's question]
Date: [current date]
Language: [BCP 47 tag — e.g. en, zh-Hans, ja. Detect from query; user's explicit language preference overrides. Use consistently throughout the report.]

Sub-questions:
1. [specific sub-question 1]
2. [specific sub-question 2]
3. [specific sub-question 3]
4. [up to 6 total]

Key topics:
- [topic 1]
- [topic 2]

Success criteria:
- [what would comprehensive coverage look like?]
- [minimum: each sub-question has ≥1 source]

Report category: [factual | comparison | product | how-to | fact-check | explainer]

Complexity: [simple | moderate | complex]

复杂度评估与自适应深度： 对问题的复杂度进行分类，以确定最多可进行多少轮研究。这可以避免对简单问题过度搜索，也避免对复杂问题搜索不足。

复杂度	最多轮数	每轮广度	适用场景
简单	2	2	单一事实问题，范围较窄，包含 1-2 个子问题。例如：“Python 的最新版本是什么？”
中等	3	3	涉及多个方面的问题，包含 3-4 个子问题、比较或操作指南。例如：“比较 Qdrant 与 pgvector 在 RAG 中的表现”
复杂	5	4	范围广，包含 5-6 个子问题，需要跨领域进行深入综合分析。例如：“全面分析 AI 基础设施中自托管与托管 API 之间的权衡”

复杂度上限是最大值，而非目标。停止检查（第 3f 步）仍决定是否提前结束。若简单问题在 1 轮内就找到全面答案，则应在第 1 轮结束；上限为 2 意味着必要时可以进行第 2 轮，而非必须进行第 2 轮。

搜索预算（根据上游 research-input.ts 预设和 estimateMaxSearches 调整）：在计划中公布预算——“搜索预算：≤N 次查询”，其中 N = 每轮广度 × 最多轮数（脚本：estimate-budget --breadth B --rounds R）。当第 2 轮及之后进行深度挖掘链（§3a）时，上限采用树形模式：estimate-budget --breadth B --rounds R --halving，即上游的广度折半递归。预算是循环不得超出的上限；根据 §3f 停止检查，应优先选择能够充分回答问题的最低成本轮次。

**语言锚定：**根据查询检测输出语言，并将其规范化为 BCP 47 标签（例如 en、zh-Hans、zh-Hant、ja）。在整个过程中保持一致——包括执行摘要、分析、矛盾点、信息缺口和结论。来源标题、URL、专有名词和代码可以保留原语言；搜索查询可以使用任何有助于收集证据的语言。如果用户在研究过程中明确切换语言，则更新语言锚定，并在后续所有输出中使用新语言。

报告类别检测：

• “vs”、“compare”、“better than” → 比较
• “best”、“top”、“recommend”、“buy” → 产品
• “how to”、“guide”、“steps” → 操作指南
• “is it true”、“verify”、“fact check” → 事实核查
• “what is”、“explain”、“overview” → 说明
• 默认 → 事实

第 2 步 — 日期校准

在任何搜索之前注入当前日期。这是强制要求——大模型默认使用训练数据截止年份，导致查询过时。

今天的日期是 {以“DD Month YYYY”格式表示的当前日期}。当搜索查询需要年份，或提到“最新”“当前”“今年”时，使用 {当前年份} 或相对表述——切勿使用根据训练数据推断的年份。

第 3 步 — 迭代循环

轮次结构

每轮按以下顺序进行：查询 → 搜索 → 提取 → 综合 → 检查是否停止

最多运行 N 轮，其中 N = 步骤 1 中的复杂度上限（简单=2，中等=3，复杂=5）。大多数主题在 2–3 轮内即可收敛。上限是最高限制，不是目标。

查询规则、抓取预算、引文锚定、综合模板、证据库和停止条件详见 references/step3-iterative-loop.md。

遇到以下情况时	阅读
查询生成、搜索和抓取、提取、锚定、综合或停止检查	references/step3-iterative-loop.md
证据库命令和三个交付门槛	references/validation-gates.md
evidence.json 中间文件	references/structured-evidence-format.md

1. 3a — 查询生成（由缺口驱动） — 广度由步骤 1 的预设决定（简单=2，中等=3，复杂=4）。第 1 轮针对计划中的子问题；后续轮次针对缺口和记录的后续问题。
2. 3b — 搜索和抓取 — 用户要求使用 donsetch MCP 搜索/抓取工具时，就使用这些工具；否则使用 web_search / web_extract。绝不要因服务提供方偏好而中止。
3. 3b.1 — 证据持久化（针对含 5 个或更多来源的报告为必需） — 从第 1 轮起，使用 scripts/research_validation.py 中的 init-run、register-source、add-claim、add-evidence 和 check-quote 进行持久化。
4. 3c — 质量筛选和提取 — 提取前剔除低质量结果。
5. 逐字摘录锚定（存储主张时为必需） — 每条存储的主张都必须附带摘自该来源页面文本的连续原文摘录。
6. 证据依据——四标签规范 — 为每项重要事实标注所依据的证据类型。
7. 3d — 综合 — 将本轮提取的内容纳入累计研究状态。
8. 3e — 结构化证据（针对含 5 个或更多来源的报告，建议采用） — 在最终报告前编写 evidence.json 中间文件。格式：references/structured-evidence-format.md。
9. 3f — 停止检查 — 综合后，判断报告是否足够全面。否则，开始下一轮，最多不超过上限。

步骤 4 — 最终报告

撰写最终报告。至少 800 字（根据主题复杂度调整）。

输出顺序应先概览：读者应先看到答案和一目了然的对比，再看到详细推理。不要把对比表放在各主题分析之后。

为每项重要事实内联标注其证据依据标签（§3c），优先呈现 [VERIFIED] / [SOURCED]，将 [REASONED] / [ESTIMATED] 主张表述为参考性内容，并在来源表下方粘贴证据键图例以说明这些标签的含义。

综合提示词结构： 撰写最终报告时，明确参考：（1）原始问题；（2）研究计划（子问题、成功标准）；（3）所有轮次的累计研究状态；（4）如已生成的 evidence.json；（5）带编号的来源列表。若累计研究状态经过多轮压缩，不要只依赖它——应回看各轮发现，以核实关键主张。这样可以避免因令牌预算压力而对研究状态进行大幅概括，导致细节丢失。

结构

# [Report Title]

> **Research date:** [date] · **Rounds:** [N] · **Sources:** [N] · **Category:** [type]

## Executive Summary
[2-3 paragraph overview of key findings — the answer up front. If using structured evidence, note claim count and refute count here so the reader knows the evidence base.]

## [Comparison Table | Overview | Key Findings at a Glance]
[For comparison reports: a markdown table comparing options/entities across criteria. For factual/explainer reports: a numbered list of key findings with claim references. This section gives the reader the complete picture in one screen — the detailed analysis below is the supporting reasoning, not the main event. If using structured evidence, cite claim IDs like [c1], [c3] in table cells or list items.]

## [## Section per sub-question]
[Detailed analysis with inline citations — this is the supporting reasoning for the overview above. Each section traces back to the overview claims.]

### [### Subsections as needed]
[...]

## Contradictions
[If sources disagree, present both sides with attribution. Do not silently arbitrate. If no contradictions found, state "No direct contradictions between sources." This section is REQUIRED — its absence is a quality signal that counter-evidence wasn't searched.]

## Gaps
[What couldn't be determined from available sources. Each gap should note: what's unknown, why it matters, and whether it could be resolved with more research. If using structured evidence, reference the writing_context items. If no gaps, state "No significant gaps identified." **Source-set bias check (mandatory):** the first gap line must state the bias your whole source set shares — one dominant language, era, school, jurisdiction, or industry — adapted from Munger inversion. A homogeneous source set is itself a gap, even when every individual source is primary-tier.]

## Conclusion
[Synthesis of findings, implications, remaining uncertainties — ties back to the executive summary and overview. The conclusion confirms or qualifies the overview, it doesn't introduce new analysis.]

---
## Sources

**Quality distribution:** [N] primary · [N] secondary · [N] tertiary — [healthy/acceptable/weak]

| # | Title | URL | Quality | Accessed |
|---|-------|-----|---------|----------|
| 1 | [title] | [url] | primary/secondary/tertiary | [date] |

**Citation format:** Inline citations use `[N]` matching the source table above. On first mention of a source, include `[N]` — subsequent mentions may use `[N]` alone. For claims from the same source, cite the number once per paragraph unless the source is paginated.

**Evidence key** — `[VERIFIED]` corroborated across ≥2 independent, cited, dated sources · `[SOURCED]` from one named source, not independently corroborated · `[REASONED]` analytical judgement / inference · `[ESTIMATED]` calculation or stated assumption.

按类别划分的概览部分

类别	概览部分格式
comparison	使用 Markdown 表格按标准比较各个选项，并添加结论行或列。下方的详细部分会说明各个选项的理由。
product	按排名列出选项，并说明优缺点、价格范围及“首选”推荐。详细部分会介绍各个产品。
how-to	按编号概述步骤。详细部分会分别介绍各步骤的前提条件、执行方式和故障排除方法。
fact-check	使用两列表格列出支持或反驳该说法的证据，并给出初步结论。详细部分会评估来源的可信度和推理过程。
explainer	按编号列出关键发现，或采用“逐步深入”的概览（从简单到深入）。详细部分会深入介绍各个概念。涉及技术内容时添加术语表。
factual	按编号列出关键发现并标注对应的说法。详细部分会为各项发现提供支持证据。

后备报告

如果大模型综合失败（超时、出错或输出乱码），请将原始发现整理成一份基础报告：

• 按子问题归类列出所有发现
• 包含来源 URL，并保留每项发现的证据依据标签
• 添加说明：“这是原始发现汇编；尚未完成综合。”
• 如果已获取任何来源，绝不要输出“未能收集到任何信息”——始终整理现有内容。

步骤 5 — 研究统计

报告完成后，输出一个简洁的统计信息块：

---
📊 Research stats: [duration] · [N] rounds · [N] queries · [N] page fetches · [N] sources cited · provider: [donsetch/built-in]

步骤 5.5 — 验证关卡（交付前必须完成）

确定性关卡 — scripts/research_validation.py，仅使用标准库，只检查结构，不做判断。每份包含 5 个或更多来源的报告都必须在交付前通过三项关卡：validate-report（结构）、verify-citations（文内 [N] ↔ Sources 行）以及 verify-claims --strict（存储的证据必须支持每项事实性说法；标记为 basis: verified 的说法需要来自 ≥2 个不同网站的来源；至少要有一项 polarity: refute 的说法，否则需使用 --refute-none "<what you searched>"）。**循环：**验证 → 修复 → 重新运行全部三项，最多 3 轮；仍未通过 → 停止，并如实向用户报告剩余问题。绝不要跳过关卡，也绝不要在关卡未通过时交付。对于包含 2–3 个来源的快速报告（无存储）：verify-claims 会发出警告，而非判定失败——请在统计信息块中记录这一点。完整规范、标志和失败处理流程见 references/validation-gates.md。

可选的 Jev 预筛查。 在已配置 TypeSafe Jev 的实例上，可为 verify-claims 添加 --jev-prescreen，进行辅助性的语义预检查，在确定性运行前标记关卡的误报和漏报。如果未设置 Jev，该功能会正常降级为一行 SKIPPED 提示——不会阻止流程，也不会更改关卡的退出代码。规范见 references/validation-gates.md。

片段锚定前置要求。 verify-claims 会评估已存储的片段——它无法判断引用是准确摘录还是恰当转述。这正是 check-quote（§3c）的用途：如果某个红色关卡中的片段从未通过 check-quote，就说明跳过了锚定；这本身就是一个缺陷。先锚定，再存储，最后运行关卡。

第 6 步 — 后续报告修订（可选）

对于已交付报告中“核实早期报告中的 X”或“更新定价部分”这类请求。改编自上游的证据面板和 report-revision.ts：后续研究范围要窄，并且只修补引用该发现的段落——报告其余内容必须保持字节级不变。

1. 定位。 python3 <skill_dir>/scripts/research_validation.py map-citations --report <report.md> [--citation N] 会返回引用每个 [N] 的顶层区块（不包括代码围栏；退出码为 1 表示没有区块引用 N）。这精确界定了后续修订可以触及的内容——除此之外一律不得改动。
2. 有限范围的后续研究。 进行一轮研究，最多使用 2 个根据目标发现和用户指示推导出的查询方向。采用相同的先看摘要片段的筛选流程和质量过滤规则（§3b/§3c）；将新页面文本加入现有运行目录；引用新来源前先登记。
3. 仅修补引用到的区块。 修订第 1 步中定位的区块（表格和列表按整个区块更新）。不要改动无关段落。如果证据与现有说法矛盾，应说明更正内容；如果证据不足，应如实说明，而不是编造修正内容。
4. 来源。 使用下一个可用编号，将新条目追加到 Sources 表格；绝不重新编号现有引用——旧的行内 [N] 必须仍能正确解析。
5. 历史记录。 将修订版保存为原文件旁边的 <name>-rev.md（后续修订依次使用 -rev2、-rev3……）。原文件保持不变；如果失败或取消，不保存任何内容。
6. 重新运行所有三项检查（第 5.5 步），确认修订后的报告通过后再交付。修订后若有检查未通过，说明修订未正确完成——先修复，不要交付。

后续投资分析（可选）

当报告涉及投资问题，且用户提供了交易参数时，使用 execute_code 构建定量的形式预测。始终将按现状使用方式作为基准。模板见 references/real-estate-investment-analysis.md。

证据.json 架构以及写作上下文与论断的区别，见 references/structured-evidence-format.md。

知识库集成（可选）

对于较大型的研究任务（10 个以上来源），或用户可能希望基于资料继续进行问答时：

1. 按照 notebooklm-mode，在 <project_folder>/research-<topic>/ 创建知识库
2. 将每个来源的原文摘录保存为 sources/ 中带编号的文件
3. 使用 ingest_source.py 原子地写入并建立索引
4. 报告完成后，告知用户：“来源已保存到 [path] 的知识库中。你可以基于这些来源提出后续问题——说‘notebooklm mode’即可查询知识库。”

此项为可选功能——对于一次性报告，该技能无需知识库也能完整运行。

子 Agent 模式（可选）

对于确实可以并行开展的不同子主题研究（例如研究 3 家互不相关的公司）：

delegate_task(
  goal="Research [sub-topic] as part of a deep-research project. Run web searches, extract content, and return findings with source URLs and titles.",
  context="You are a research subagent. Topic: [sub-topic]. Sub-questions: [list]. Use web_search and web_extract. Return structured findings with citations.",
  toolsets=["web"]
)

规则：

• 只有在各子主题确实相互独立时才使用子 Agent
• 收集所有子 Agent 的结果，然后自行综合
• 绝不委派综合步骤——协调者必须查看所有发现
• 子 Agent 的摘要属于其自述——引用前须核实来源 URL 确实存在

并发与速率限制

• 完整页面抓取按需进行，并受预算限制（§3b）：每轮最多 2 次，整个运行的上限按复杂度设定——摘要片段用于初步筛选
• 如果 web_extract 无法处理某个 URL，记下情况并继续——不要无休止地重试
• 如果 web_search 没有返回结果，按照 §3a 的细化流程处理，包括在改写后仍无结果时停止

常见陷阱

• 夸大依据 — 在两个标签之间犹豫不决时，选择较弱的标签。来源中的“约一半”应保留为 ~50% [SOURCED]。
• 混淆论点与上下文 — 主题事实属于论点；范围、方法和可用性限制属于 writing_context。
• 子 Agent 自我报告 — 引用前请确认来源 URL 存在。由编排器综合信息。
• 澄清：一轮即可 — 如果回复仍含糊不清，就按对意图的最佳理解继续。
• 复杂度分类错误 — 复杂度指综合分析的广度，而不是主题听起来有多高深。包含六个子问题的狭窄事实主题属于中等复杂度。
• 令牌预算在达到上限前就耗尽 — 长篇提取时，如果上下文吃紧，应积极总结，而不是等到轮次上限。
• 按词边界匹配 — “port”匹配到“transport”或“support”属于误命中；应根据主题相关性筛选，而不是只看子串重叠。
• 存储的论点必须与引文匹配 — 确定性评分器只有在一条存储的片段涵盖论点文本中的每个数字、年份和实体时，才会支持该论点；否则评分最高为 partial−0.01（事实性内容严格标红）。此规则已在一次会话中实时验证三次：多事实论点要按片段拆分；论点文本必须与引文逐字节对齐；散文改写应留在报告正文中。同一规则的具体情况包括：CJK 论点不会提取出任何令牌，因此即使片段完全相同，得分也只有约 0.33——应使用字节级完全相同的论点文本（实体轴为 1.0），或通过 check-quote 锚定（不依赖分词）；粘连的大写词串（“Scrape URL FIRECRAWL” → 单个实体 scrape url）永远无法与仅写“Firecrawl”的论点匹配；字母数字品牌前缀（“x402” → 数字 402）会导致评分受限，除非片段包含品牌文本。改写前，先用脚本的 _figures／_entities／_tokens 辅助函数进行诊断。
• 锚定到错误的底层文件 — check-quote --source-id 会读取 pages/<source_id>.txt；在认定内容系捏造之前，先确认该 id 对应的 URL 就是句子的实际来源——同一句话出现在另一页面的文件中会导致误报。
• 未锚定的片段 — 存储从未通过 check-quote 检查的片段（或证据），会让流畅的改写变成“证据”：评分器看到熟悉的令牌，就会将其评为有支持。请逐字引用，并与保存的页面文本（<run_dir>/pages/<source_id>.txt）核对；不匹配时只修正一次——绝不要把片段改得更贴近论点，也绝不要拼接跨段文字。若不存在连续的原文片段，该论点就没有证据支持；请如实存储，并让门禁标记出来。
• 存储 CLI 参数顺序和字段配对 — 子命令必须放在 --dir 之前（research_validation.py add-claim --dir <d> ...，绝不能写成 --dir <d> add-claim）。add-claim 接受 claim+kind+polarity+basis+snippet+source_id；add-evidence 接受 evidence_snippet+source_id——如果交换这两组字段，就会把片段存入 source_id，之后还会显示 unregistered-source_id 警告。basis 只接受四个标签——不接受来源 TIER 名称（primary／secondary，否则返回 rc 2）；kind 不接受 refute 值：refute 是 polarity。在脚本中循环调用存储命令时，请检查每条响应的 JSON——被拒绝的调用会静默退出 2，而循环里的“stored”消息却会谎称存储成功。
• 正文中的引用密度 — 每一行 Sources 都必须至少被引用一次（未引用的行会导致 verify-citations 失败）；必需章节（## Executive Summary、## Contradictions、## Gaps、## Conclusion）必须使用 ## 级标题，不能使用 #。
• 综合失败时的回退方案 — 汇总原始发现并附上引文和标签；空输出才是失败状态。
• 证据标签说明 — 在 Sources 表下方粘贴四标签图例，以说明 [VERIFIED]／[SOURCED]／[REASONED]／[ESTIMATED] 的含义。

相关工作

Odysseus — PewDiePie 的可自托管 AI 工作空间 — 包含一项名为“深度研究”的功能，可进行多步网页研究并阅读来源，其理念与此技能的“思考 → 搜索 → 提取 → 综合 → 停止”循环相似。此技能是纯提示词工作流（无 UI、无服务），旨在任何 Agent 的工具循环中运行。

AnotiaWang/deep-research-web-ui（MIT）— 一个封装了 dzhng/deep-research 的 Nuxt UI，采用了强化后的引擎，也是此技能的主要供应来源。已引入： 逐字引用证据锚定，v1.8.2（shared/utils/search-learning.ts → check-quote，§3c）；带冻结约束的结构化搜索迷你计划、规划规范和提供方指导，v1.9.0（shared/utils/search-plan.ts → §3a）；搜索预算预设 + 广度减半估算，v1.9.0（shared/utils/research-input.ts → 第 1 步 + estimate-budget）；基于后续方向的有界深挖线程，v1.9.0（lib/core/deep-research.ts → §3a）；六类轮次结果分类及按原因限定的重试，v1.9.1（shared/utils/search-assessment.ts → §3a）；以摘要片段优先、按需阅读并设置抓取预算，v1.9.0（lib/core/read-source.ts → §3b）；基于术语评分的逐字段落选择，v1.9.0（lib/core/source-context.ts → §3d）；带引用→区块映射的精准报告修订，v1.9.0（shared/utils/report-revision.ts → 第 6 步 + map-citations）。已评估，未引入： 完整树递归、流式 JSON 结构化输出修复、UI/部署层，以及 dzhng 的“来源无关紧要”提示词（与此技能的来源溯源规范相矛盾）。完整的双向映射：references/anotiawang-deep-research-concepts.md。

Anjos2/recursive-research（MIT）— 用于长周期递归研究的 Claude Code 提示词技能。已引入（v1.9.2，指导层面）： 基于饱和度的停止信号（§3f）、平衡各计划子问题的覆盖范围（§3a）、在“缺口”部分强制检查来源集偏差（第 4 步）。未引入： 循环机制、WDM 加权来源评分、按领域划分的种子来源列表、预防性上下文暂停阈值、本地语料库模式。≤5% 的阈值未经上游验证（仓库最后推送于 2026-04-22，未经实地强化）；此阈值作为信号提供，而非规则。映射：references/recursive-research-concepts.md。

DocsGPT（arc53，MIT）— ResearchAgent 的“规划 → 研究 → 综合”流程，支持自适应深度、澄清、令牌预算跟踪和空搜索优化。映射：references/docsgpt-concepts.md。

references/skills-monetization.md — 汇总了关于 AI 技能变现的知识库（市场平台、畅销内容、定价），内容来自 2026-07-01 的研究档案。

评估

evals/routing-fixtures.json 存放轻量级契约测试样例 — 示例请求 → 预期路由、必需输出字段和禁止的输出模式。它们是规范，不会针对实时模型运行；仓库根目录中的 tests/test_routing_fixtures.py 会验证这些样例格式正确，并能路由到真实技能。