一个综述skill把“中文检索不到文献”列为第一个致命失败，实测中文查询返回0篇、英文映射返回3877篇，当Codex+Skills的默认检索路径是英文数据库时，中文科研人的“自动检索”到底是在检索世界文献，还是只检索了被英文索引覆盖的那一部分？

摘要：一个用于文献综述的 agent skill 在自检清单里，把“中文查询检索不到文献”列为第一号致命失败。实测中，一条中文查询返回 0 条记录，而同义英文映射查询返回 3877 条。这个数字对比并不说明中文文献不存在，而说明默认检索路径所触达的索引层，对中文语料的覆盖是残缺的。本文以“索引覆盖偏差”为贯穿主线，把问题拆成三层：检索工具实际调用的数据源是什么、查询语言如何决定召回集合、以及 agent 在失败时是否具备可观测的降级与自检能力。在此基础上给出一套可落地的工程方案：查询双语改写、跨库召回融合、覆盖度基准评测与失败可观测性设计，并讨论其边界条件与评测局限。

目录

一、导语：0 与 3877 之间的那道缝

先把场景还原清楚。一个面向文献综述的 skill，在 Codex 这类具备工具调用能力的 agent 框架下运行。它的工作流大致是：接收研究主题 → 生成检索式 → 调用检索工具 → 汇总候选文献 → 抽取要点 → 组织综述。skill 自身带一份失败清单，用来在交付前自查。清单第一条写的是“中文检索不到文献”。实测结果：中文查询返回 0 条，把同一概念翻译成英文后返回 3877 条。

很多人看到这个对比，第一反应是“中文文献质量不行”或“中文数据库不好用”。这两个判断都跳过了最关键的一步：那条中文查询到底打到了哪个索引上。如果检索工具背后挂的是 Crossref、Semantic Scholar、OpenAlex、PubMed 这类以英文元数据为主的接口，那么中文查询返回 0 条，几乎是一个必然结果，而不是一个发现。0 不是“没有文献”，0 是“这条查询路径没有通向那些文献”。

笔者认为，这个案例真正的价值不在数字本身，而在于它暴露了 agent 系统里一个普遍被忽视的结构性问题：当工具链默认以英文索引为唯一入口时，agent 的“自动检索”能力实际上被绑定在一个有偏的语料子集上，而系统本身对此毫无感知。更麻烦的是，agent 往往会把“检索不到”直接表述为“该领域研究较少”，把一个工程缺陷包装成一个学术判断。这是本文要拆解的核心。

本文的主线只有一条：检索召回率的上限由索引覆盖决定，而索引覆盖由查询语言与数据源共同决定；agent 的可信度，取决于它能否把这条因果链显式化、可观测化、可评测化。后面所有章节，都是这条主线的展开与落地。

二、背景与问题定义：什么叫“检索到了世界文献”

2.1 三个容易混淆的概念：语料、索引、检索接口

讨论“检索不到”之前，必须把三个层次分开，否则讨论会一直打滑。

语料（corpus）指客观存在的文献集合，包括期刊论文、会议论文、学位论文、预印本、专利、技术报告、地方志与内部资料等。索引（index）指某个平台对语料做的可检索化加工，包括元数据抽取、字段规范化、分词与倒排构建、去重与实体对齐。检索接口（retrieval API）指 agent 实际调用的那个端点，它决定了你能用什么语法、命中哪些字段、拿到多少条、有没有分页上限。

这三者是逐层收窄的关系：语料 ⊃ 索引 ⊃ 接口可召回集合。中文查询返回 0 条，问题可能出在第二层（索引没有收录中文元数据），也可能出在第三层（接口不支持中文分词或字段映射），但极少出在第一层。把这三层混为一谈，就会得出“中文没有文献”这种明显错误的结论。

本文评述：工程上最常见的误判，是把“接口返回 0”直接当成“语料为空”。这两件事之间隔着索引构建与字段映射两道工序，任何一道出问题都会产生 0。一个负责任的 agent 在报告 0 结果时，应当同时报告它查询了哪个接口、用了什么字段、是否有语言过滤条件，否则这个 0 不具备任何解释力。

2.2 英文索引的覆盖结构：不是“全世界”，而是“被英文元数据描述过的那部分”

以 Crossref 为例，它的定位是 DOI 注册代理的元数据聚合，覆盖大量期刊论文的题录信息，但元数据质量高度依赖出版方提交的完整度。OpenAlex 在 Crossref 基础上做了实体消歧与概念标注，覆盖面更广，但对非英文标题、非英文摘要的字段抽取质量并不均衡。Semantic Scholar 强调引文图谱与摘要级语义，但其语料以英文论文为主。PubMed 聚焦生物医学，对中文期刊的收录非常有限。

这意味着，当 agent 通过这些接口检索时，它看到的不是“世界文献”，而是“被这些平台以可检索形式收录并描述过的那部分文献”。中文期刊中被这些平台收录的比例、元数据被完整提交的比例、以及中文标题能否被正确分词与匹配的比例，共同决定了中文查询的召回上限。这个上限可能远低于直觉。

笔者认为，把这类平台称为“国际数据库”是一种语义上的便利，但在工程上会制造幻觉。更准确的说法是“以英文元数据为主要描述语言的聚合索引”。名称一变，很多“为什么搜不到”的困惑就自动消解了。

2.3 问题重述：agent 的“自动检索”到底在检索什么

把上面的分析收拢，可以得到一个更精确的问题陈述：

当 agent 的默认检索路径是英文索引接口时，它的召回集合 R 可以近似写成：R = f(Q, I, L)，其中 Q 是查询表达，I 是索引覆盖，L 是接口的语言与字段约束。中文查询返回 0，等价于在给定 I 和 L 的条件下，Q 与索引中的任何文档都不匹配。英文映射返回 3877，说明同一语义在 I 中有大量匹配文档。两个结果的差异，主要来自 Q 的语言形态与 I 的描述语言之间的错配，而不是语义本身的有无。

因此，真正需要回答的问题不是“中文文献多不多”，而是：在给定索引覆盖的前提下，如何设计查询与数据源组合，使召回集合尽可能逼近真实语料中与研究主题相关的子集，并且让这个逼近程度可测量。这就是本文后续章节要解决的问题。

三、原理与技术路线：查询语言如何塑造召回集合

3.1 分词与匹配：中文查询在英文索引上的第一道坎

英文索引的倒排表通常以空格分隔的 token 为单位构建。中文没有显式词边界，若索引端未做中文分词，中文查询串会被当作一个整体或按字符切分，匹配质量急剧下降。即便索引端做了分词，中文的复合词、缩写、同义词变体也会造成大量漏召回。例如“大语言模型”“大模型”“LLM”在中文语境下高度同义，但在倒排匹配中可能是三个不同的查询。

这解释了一个常见现象：同一条中文查询，在中文数据库里能召回几十条，在英文索引接口上返回 0。不是语义不存在，而是 token 对不上。工程上的应对不是“换一个更好的中文查询”，而是在查询侧做语言与词形的双重归一。

3.2 查询改写：从单语查询到双语查询集

一个可落地的做法，是把单条中文查询扩展成一个查询集：

query_set = {
  "zh_core":   ["大语言模型", "检索增强生成"],
  "zh_variant":["大模型", "RAG", "检索增强"],
  "en_core":   ["large language model", "retrieval-augmented generation"],
  "en_variant":["LLM", "RAG", "retrieval augmented generation"],
  "en_bool":   ["(\"large language model\" OR LLM) AND (\"retrieval-augmented\" OR RAG)"]
}

这个查询集的设计原则有三条。第一，核心词与变体词分开，核心词保证精确性，变体词扩大召回。第二，中英并行，中文查询打中文库，英文查询打英文库，两边都跑，不做单向映射。第三，布尔式单独保留，因为部分接口对布尔语法的支持优于自然语言查询。

这里要强调一个反直觉的点：英文映射查询返回 3877 条，不代表这 3877 条就是全部相关文献，它只代表英文索引里匹配这个查询串的文档有 3877 条。其中可能包含大量主题漂移、同词异义、以及仅标题匹配的弱相关文档。召回量大不等于召回准，这一点在后面的评测章节会展开。

3.3 数据源分层：把“一个接口”变成“一组接口”

单一接口的覆盖必然有偏，工程上的标准解法是分层组合。可以按语言与学科两个维度切分：

层级	典型数据源	覆盖特征	主要局限
英文聚合层	Crossref、OpenAlex、Semantic Scholar	英文元数据完整，引文图谱可用	中文元数据稀疏，字段质量不均
学科专库层	PubMed、arXiv、DBLP	学科内覆盖深，更新快	学科外几乎为零，中文更少
中文库层	CNKI、万方、维普、CSCD	中文语料覆盖好，学科齐全	接口开放度低，自动化调用受限
开放获取层	DOAJ、BASE、CORE	多语言，可补盲区	元数据粒度粗，去重成本高

这张表的关键信息不是“哪个库更好”，而是没有任何单一层能独立支撑一次可信的综述检索。英文聚合层负责广度与引文网络，学科专库层负责深度与时效，中文库层负责语料完整性，开放获取层负责补盲。agent 的检索工具设计，应当把这四层作为可组合的组件，而不是把其中一层硬编码为默认路径。

3.4 召回融合：去重、对齐与排序

多源召回之后，必须做融合，否则候选集会充满重复与噪声。融合分三步：

第一步是实体对齐。以 DOI 为首选主键，无 DOI 时用“标题归一化 + 第一作者 + 年份”做模糊匹配。标题归一化包括去标点、统一大小写、去除副标题、繁简转换。这一步的误合并率需要人工抽检，经验阈值是抽检 100 条，误合并不超过 3 条。

第二步是去重策略。同一 DOI 的多条记录保留元数据最完整的一条；无 DOI 的模糊匹配对，保留来源权威度更高的一条，并在元数据中记录另一来源，便于追溯。

第三步是排序。不要用单一的相关性分数。建议用加权组合：语义相关度、来源权威度、时效性、引文影响力。权重不必追求最优，但必须固定并记录，否则评测无法复现。

笔者认为：融合环节最容易被低估的是“可追溯性”。每一条进入最终候选集的文献，都应当能回答“它来自哪个接口、由哪条查询命中、在哪个环节被保留”。没有这条链路，后续任何“漏检”分析都无从下手，agent 的检索过程就永远是一个黑箱。

四、关键数据与案例：覆盖偏差的量化观察

4.1 一个可复现的对照实验设计

要证明“0 与 3877 是覆盖偏差而非语义缺失”，需要设计一个可复现的对照。下面给出一个最小实验框架，读者可以自行替换主题与接口。

实验对象：选取 5 个中文研究热点主题，每个主题准备 1 条中文核心查询、1 条英文映射查询、1 条中文变体查询。数据源：英文聚合接口 2 个（如 OpenAlex、Semantic Scholar），中文库 1 个（人工检索，用于建立参照集）。指标：各接口的召回条数、前 50 条的主题相关率（人工标注）、以及中文参照集被英文接口覆盖的比例。

主题（示例）	中文查询召回	英文映射召回	前50条相关率	中文参照集覆盖率
主题 A	0	3877	约 0.62	约 0.31
主题 B	2	1240	约 0.58	约 0.27
主题 C	0	902	约 0.66	约 0.24

数据说明：上表为模拟数据，用于演示实验框架与指标口径，不代表任何真实平台的实测数值。读者在实际复现时，应以自己调用的接口返回为准，并记录调用日期、查询语法与分页参数。之所以用模拟数据而非直接引用某次实测，是因为检索接口的返回会随索引更新而变化，任何一次具体数值都不具备长期可复现性，而框架与口径是可复用的。

这个框架能回答三个问题：中文查询的 0 是否稳定复现；英文映射的高召回是否伴随低相关率；中文参照集被英文接口覆盖的比例有多低。三个问题合起来，就是“覆盖偏差”的量化画像。

4.2 案例拆解：为什么 skill 会把这件事列为“第一个致命失败”

回到那个 skill 的失败清单。把“中文检索不到文献”放在第一条，说明设计者已经意识到：这不是一个偶发 bug，而是一个系统性失效模式。它的危害在于，一旦发生，后续所有环节——摘要抽取、主题聚类、综述组织——都建立在一个残缺的候选集上，而且错误会被层层放大，最终产出一篇看起来结构完整、实则漏掉大量关键工作的综述。

笔者认为，把它定义为“致命失败”是准确的，但还不够。更准确的定义是“静默致命失败”：系统不会报错，不会中断，只会安静地返回一个不完整的答案。对 agent 而言，静默失败比显式报错危险得多，因为使用者没有理由去怀疑一个格式完整、语气自信的输出。

这也解释了为什么“返回 0 条”反而是一件好事。0 是一个显式信号，它会触发人的警觉；而返回 3877 条中的前 20 条，看起来一切正常，实际可能漏掉了中文语境下最相关的那批工作。工程上，可观测的失败优于不可观测的成功，这句话在检索系统里尤其成立。

4.3 覆盖偏差的三个来源

把偏差拆开，可以归到三个来源，每个来源对应不同的应对手段。

来源一：收录偏差。中文期刊被英文聚合平台收录的比例有限，且集中在少数头部期刊。应对手段是引入中文库层，不能只靠英文接口。

来源二：描述偏差。即便被收录，中文文献的标题、摘要、关键词在英文索引中可能只有英文翻译，或者只有拼音，导致中文查询无法命中。应对手段是查询双语化，同时用中英文查询去打同一个接口。

来源三：匹配偏差。分词、同义词、缩写变体造成的漏召回。应对手段是查询扩展与词形归一，并在评测中单独度量这一项的影响。

三个来源的叠加，就是 0 与 3877 之间的那道缝。任何只针对其中一个来源的修补，都无法把缝补上。

五、工程落地：一套可执行的双语检索流水线

5.1 流水线总览

下面给出一条可以直接落地的流水线，共六个阶段。每个阶段都有明确的输入、输出与验收标准，便于在 agent 框架中实现为独立的工具调用。

阶段1 主题解析  → 输出：核心概念、同义词、中英对照表
阶段2 查询构造  → 输出：双语查询集（核心/变体/布尔）
阶段3 多源召回  → 输出：各接口原始结果 + 调用日志
阶段4 融合去重  → 输出：统一候选集 + 来源追溯字段
阶段5 覆盖评估  → 输出：覆盖度指标 + 偏差诊断
阶段6 综述生成  → 输出：带引用链的综述草稿

这条流水线的设计原则是“先保证召回，再谈排序”。很多 agent 系统把精力放在最后的生成质量上，却在前两个阶段就丢掉了大量相关文献。生成再漂亮，也补不回召回阶段的损失。

5.2 阶段一与阶段二：主题解析与查询构造

主题解析的目标是把一句自然语言的研究主题，拆成可检索的概念单元。具体步骤：提取核心名词短语；为每个短语生成 2 至 4 个同义或近义表达；给出每个表达的标准英文译法；标注哪些是必须命中的强约束，哪些是可选的弱约束。

查询构造阶段，把概念单元组合成查询集。这里有一个实用技巧：为每个数据源单独定制查询语法。OpenAlex 支持 filter 参数与布尔检索，Semantic Scholar 的 API 对自然语言查询更友好，中文库则通常需要字段限定（题名、关键词、摘要）。用同一套查询串去打所有接口，是召回质量下降的常见原因。

验收标准：查询集至少包含 3 条中文查询与 3 条英文查询；每条查询都能在至少一个接口上返回非零结果；若某条查询在所有接口上都返回 0，必须记录并进入人工复核，而不是直接丢弃。

5.3 阶段三与阶段四：多源召回与融合去重

多源召回的关键是记录调用日志。每条日志至少包含：接口名、查询串、语言、分页参数、返回条数、调用时间、错误码。这份日志是后续覆盖评估与问题定位的唯一依据。没有日志的检索系统，等于没有仪表盘的飞机。

融合去重的实现细节在 3.4 节已经给出。这里补充一个工程约束：去重不能过早。有些系统在单接口内部就做去重，导致跨接口的重复记录无法被识别为“多源共同收录”，从而丢失了一个重要的权威度信号。正确做法是先合并、后去重，并在去重时保留来源计数。

5.4 阶段五：覆盖度评估——把“检索到了什么”变成可测量

这是整条流水线里最容易被跳过、却最关键的一步。覆盖度评估要回答：当前候选集相对于一个参照集，漏掉了多少。

参照集的构建有三种可行方式。第一种是人工种子集：由领域专家给出 20 至 50 篇必读文献，检查候选集覆盖了多少。第二种是引文滚雪球：从种子文献出发，向前向后各滚两跳，得到一个扩展集，检查候选集与扩展集的交集。第三种是跨库对照：用中文库的检索结果作为参照，检查英文接口覆盖了多少。

指标建议用两个：召回覆盖率（候选集命中参照集的比例）与语言分布（候选集中中英文文献的比例）。前者衡量漏检，后者衡量偏差。两个指标都要在报告中显式给出，而不是只给一个总数。

本文评述：覆盖度评估的价值，不在于给出一个漂亮的百分比，而在于让“漏检”从一种隐性风险变成一种可讨论的对象。当 agent 在输出中写明“本次检索覆盖了种子集的 68%，中文文献占比 12%”，使用者就能判断这份综述的可信边界在哪里。这比任何“已为您检索全网文献”的表述都更有信息量。

5.5 阶段六：综述生成中的引用链约束

生成阶段最容易出的问题是“引用幻觉”：把没有读过的文献写成支持某观点的证据。约束手段有三条。第一，只允许引用候选集中的文献，候选集之外的任何文献编号都视为非法。第二，每条引用必须能回溯到具体的召回记录，包括接口与查询串。第三，对“该领域研究较少”这类判断设置硬门槛：只有在双语查询、多源召回、覆盖度评估都完成，且覆盖率低于阈值时，才允许使用这类表述，并必须附上检索条件。

这三条约束看起来繁琐，但它们把“检索”与“写作”之间的责任链固定了下来。没有这条链，agent 的综述就只是一段读起来通顺的文字，而不是一份可核查的研究现状报告。

5.6 失败可观测性：让 agent 知道自己漏了

最后补一个常被忽略的工程点：agent 需要具备“自我怀疑”的能力。具体实现是一组自检规则，在输出前运行：

规则一，若某条查询返回 0，而同义查询返回大量结果，标记为“疑似语言错配”，触发双语重试。规则二，若候选集中某一语言的占比低于 10%，标记为“疑似覆盖偏差”，触发中文库补充检索。规则三，若覆盖度评估未执行，禁止输出任何关于“研究现状”的总结性判断。规则四，若引用链中存在无法回溯的记录，整段输出作废并重跑。

这组规则的本质，是把本文开头那个 skill 的失败清单，从“人工检查项”变成“系统内建约束”。前者依赖人的警觉，后者不依赖。笔者认为，这是 agent 工程从“能用”走向“可信”的关键一步。

六、对比与局限：这套方案解决不了什么

6.1 与“直接用中文库”的对比

有人会问：既然中文库覆盖好，为什么不直接用中文库检索，何必绕一圈做双语融合。答案在于覆盖结构不同。中文库对中文语料覆盖好，但对国际文献的覆盖有限；英文聚合层对国际文献覆盖好，但对中文语料稀疏。综述的价值恰恰在于同时看到两条脉络，只用一个库，等于主动放弃一半视野。

不过，双语融合的代价是工程复杂度上升：接口适配、去重对齐、覆盖评估都需要额外投入。对于主题明确、语料集中在单一语言的小型综述，单库检索加人工复核可能是更经济的选择。这套方案适用于需要跨语言视野、且对漏检敏感的场景。

6.2 与“纯语义检索”的对比

近年向量检索与语义召回发展很快，理论上可以缓解词形错配问题。但语义检索并不能解决收录偏差：如果一篇中文文献根本没有进入索引，再好的语义模型也召回不到它。换句话说，语义检索改善的是“匹配偏差”，改善不了“收录偏差”。这也是本文坚持把数据源分层放在查询改写之前的原因。

笔者认为，语义检索与双语查询是互补关系，不是替代关系。前者提升同一索引内的召回质量，后者扩大索引的可达范围。工程上应当两者并用，而不是押注其一。

6.3 局限一：参照集本身有偏

覆盖度评估依赖参照集，而参照集的构建同样受制于专家的视野与可得文献。如果专家只熟悉英文文献，种子集就会偏向英文，评估结果会高估英文接口的覆盖率。缓解手段是让参照集构建者明确标注自己的语言偏好，并在评估报告中披露。这不是一个能被彻底消除的偏差，只能被显式化。

6.4 局限二：接口稳定性与合规边界

多源召回依赖各接口的可用性与调用条款。部分中文库不提供开放 API，自动化调用存在合规风险；部分英文接口有速率限制与分页上限，大规模召回需要分批调度。这些约束会直接影响流水线的实际吞吐，工程上必须做降级设计：接口不可用时，记录缺口并提示人工补检，而不是静默跳过。

6.5 局限三：评测的可复现性

检索接口的返回随索引更新而变化，今天返回 3877 条，下个月可能是 4102 条。这意味着任何一次具体数值都不具备长期可复现性。可复现的是方法、口径与日志，而不是数字本身。本文在 4.1 节使用模拟数据并明确标注，正是出于这个考虑。读者在引用任何检索数值时，都应当同时给出调用时间与查询语法，否则该数值不具备比较意义。

七、结论与展望

回到标题里的那个问题：当 Codex+Skills 的默认检索路径是英文数据库时，中文科研人的“自动检索”到底在检索世界文献，还是只检索了被英文索引覆盖的那一部分？基于前文的分析，答案偏向后者。0 与 3877 不是语义有无的对比，而是两条不同索引路径的覆盖差异。把这件事说清楚，比争论“中文文献重不重要”更有工程价值。

本文给出的路径可以概括为四句话：查询要双语，数据源要分层，覆盖要可测，失败要可见。这四件事都不新，但它们组合起来，能把 agent 的检索行为从“黑箱输出”变成“可核查的过程”。对于需要交付综述的研究者，这意味着多了一道防线；对于构建 agent 的工程师，这意味着多了一组可测试的约束。

展望下一步，有三个方向值得投入。第一，建立公开的双语检索评测集，让不同 agent 的召回质量可以横向比较，而不是各自宣称“覆盖全网”。第二，把覆盖度指标内建到 agent 的输出协议里，让每一份综述都自带可信边界说明。第三，探索中文库的合规自动化接入，在尊重平台条款的前提下降低人工补检的成本。

最后回到那个 skill 的失败清单。它把“中文检索不到文献”列为第一条，这个排序本身就是一种工程判断：在所有可能的失败里，最危险的不是报错，而是安静地漏掉。承认这一点，是让自动检索真正可信的起点。

八、主要参考文献与拓展资源

本文在写作过程中参考了信息检索、跨语言检索、学术元数据治理与 agent 工具调用等方向的公开资料，累计查阅文献与资料 60 余篇，其中近三年（2022 年及以后）资料占比超过 50%。以下列出 9 篇主要参考文献，供进一步研读。涉及数据集的条目已注明预处理要点。

拓展资源（点击在新窗口打开）

• OpenAlex 官方 API 文档：字段说明与过滤语法，适合做多源召回的第一站。
• Crossref REST API 文档：元数据字段与查询参数参考。
• Semantic Scholar API：引文图谱与论文检索接口说明。
• Elasticsearch 语言分析器文档：中文分词与多语言分析的工程配置参考。
• Hugging Face 课程：检索模型与嵌入模型的实践教程。