摘要：本文以两份由 Kimi 生成的 PubMed 与 Google Scholar 检索记录为实证材料，分析 Kimi 学术文献检索功能在实际任务中的能力范围与结构性短板。研究发现，Kimi 的检索能力在“种子发现”层面表现合格——能够按检索式返回相关文献列表并附带元数据；但在“语料可用性”层面存在明显断层：PubMed 侧止步于题录与摘要，未跟进 PMC 或出版社全文；Scholar 侧则因抓取机制限制，摘要为截断片段而非完整内容。进一步分析表明，这一断层的根源不在于检索式设计，而在于 Kimi 当前学术检索的产品定位偏向“发现”而非“获取与结构化”，全文抓取与深度字段抽取尚未成为默认能力。本文以具体数据说明上述判断，并讨论其对科研工作流的实际影响。
关键词：Kimi；学术检索；文献语料；PubMed；Google Scholar
一、引言
Kimi 官方将学术文献检索列为 Agentic Search 的核心能力之一，声称支持“期刊、论文、预印本、学位论文、专利等学术信息”的查询，并覆盖“100+ 经过验证的可信来源”。在对外描述中，Kimi 的搜索能力经历了从 Explorer Search 到 Agentic Search 的演进，后者具备“自主规划与工具调用”能力，可处理“学术文献检索”等多模态任务。
然而，官方描述与用户实际获得的数据产品之间存在需要厘清的距离。“支持学术文献检索”这一表述至少可以对应三个不同层次的能力：（1）发现相关文献并返回标题与链接；（2）获取每篇文献的完整元数据与摘要；（3）获取全文并进行结构化抽取。本文利用两份真实检索记录，检验 Kimi 在当前产品形态下究竟达到了哪一层。
选择 PubMed 与 Google Scholar 作为分析对象，是因为二者分别代表了学术检索的两类典型场景：PubMed 是权威题录数据库，元数据规范、摘要完整，但不提供全文；Google Scholar 是宽口径学术搜索引擎，覆盖面广、附带被引数据，但摘要展示天然截断。两份记录合在一起，恰好可以检验 Kimi 在“规范源”与“宽口径源”上的处理差异。
二、数据与方法
2.1 数据来源
两份文件均为 Kimi 文献检索功能的直接输出，未经人工修改。
PubMed 记录：检索式为 (Nature[Journal] OR Science[Journal] OR Cell[Journal]) AND (plant microbiome OR rhizosphere OR root microbiota OR mycorrhizal OR nodulation) AND China[Affiliation]，返回 37 条记录。数据以嵌套 JSON 形式组织，results 数组每条包含 pmid、doi、title、authors、journal、date、abstract、abstract_sections、urls、is_retracted、warnings 等字段。
Scholar 记录：以 CSV 格式输出，表头为 title, authors, year, citations, abstract, result_id, publication_info, pdf_links, url, total_results, search_time。检索式未在文件中显式给出，但结果内容表明其覆盖面宽于 PubMed 记录，包含 Nature 子刊、Cell 子刊、ISME J、Microbiome 等期刊。预览约 45 条记录，文件末尾截断，完整数据已另存为 CSV。
2.2 分析方法
对两份记录进行字段级核查与内容抽样，重点关注：（1）摘要字段的完整性；（2）全文获取路径的存在性与跟进情况；（3）检索精度与噪音比例；（4）元数据解析的完备程度。分析不依赖外部工具，仅基于文件本身提供的信息进行判断。
三、发现
3.1 PubMed 侧：摘要完整，全文缺失
PubMed 记录的一个正面发现是，摘要字段是完整的。以 pmid 40267905（水稻分蘖与根微生物组，Cell 2025）为例，其 abstract 字段包含从“Rice tillering is an important agronomic trait…”到“…harnessing the root microbiota in sustainable agriculture”的完整段落，abstract_sections 亦提供了结构化的相同内容。这与 Scholar 侧的截断摘要形成鲜明对比。
然而，全文获取路径未被跟进。37 条记录中，仅 1 条（pmid 31813624）具有 pmcid，其余 36 条的 pmcid 均为 null。这意味着 Kimi 虽然从 PubMed 获取了 DOI 与 pubmed URL，但并未尝试通过 Unpaywall、PMC OA 接口或出版社链接进一步获取全文。对于植物微生物组这类高度依赖方法学细节的领域，仅有摘要不足以支撑任何实质性的机制分析或方法比较。
这一行为模式与 Kimi 自身的产品文档存在一定张力。官方帮助中心声称支持“直接存取 URL 以抓取互联网资源”，并举例“从这份财报 PDF 中撷取关键数据”。但在实际检索任务中，Kimi 并未将这一 URL 抓取能力应用于文献全文的获取。更可能的情况是：学术检索模块被设计为“返回检索结果”，而非“跟进每条结果的全文”。
3.2 Scholar 侧：摘要截断，但被引与 PDF 入口有价值
Scholar 记录的摘要字段是截断的。以 result_id: 32z4_Tbi8r8J（根毛发育调控与干旱微生物组，Nat Commun 2024）为例，其 abstract 为 “… evidence suggest plant microbiome affects plant drought … plants orchestrate the dynamic assembly of the microbiome … a dry hot valley in southwest China (containing drought-adapted …”。这显然是 Google Scholar 结果页的快照片段，而非原文摘要。Kimi 未回到 nature.com 的文章页面补全摘要，也未从 pdf_links 中提取 PDF 文本。
但 Scholar 记录提供了 PubMed 记录不具备的两个增量字段：citations（被引次数）与 pdf_links（PDF 链接列表）。citations 的范围从 0（2026 年新文）到 1358（Ling 等 2022 年综述），为影响力计量提供了基础数据。pdf_links 包含出版社官方 PDF、PMC 链接、ResearchGate 链接乃至 Google Drive 链接，理论上为全文获取提供了入口——尽管 Kimi 并未实际下载或解析这些 PDF。
此外，Scholar 记录的检索精度问题更为突出。预览的约 45 条记录中，虽然绝大多数属于植物微生物组主题，但期刊层级参差不齐，包含 ISME Communications、Molecular Plant、Plant Cell & Environment 等非 CNS 正刊。若用户目标是“中国团队 CNS 级植物微生物组成果”，则需额外的人工筛选。total_results 与 search_time 字段均为 unknown，说明 Kimi 未能解析 Scholar 页面的结果总数与耗时信息，召回率不可知。
3.3 两份记录的共性问题：检索式宽泛与结构化缺失
两份记录的检索式设计均呈现“宽口径 OR 堆叠”的特征。PubMed 记录中混入了肠道菌群与肿瘤免疫（pmid 38490195，Lactobacillus 代谢物增强免疫治疗）、肠道神经免疫（pmid 31813624，伤害感受器与沙门氏菌防御）、旱地放牧生态（pmid 36423285、39112697）等与植物微生物组无直接关系的记录。这说明 China[Affiliation] 与宽泛主题词的组合产生了可观的噪音，Kimi 未在返回前进行相关性过滤。
更关键的缺失在于字段结构化。两份记录均未将“研究对象物种”“微生物类群”“实验体系（田间/温室/离体）”“关键基因”“资助来源”等对领域分析至关重要的信息抽取为独立字段。所有信息都封存在摘要或标题字符串中，下游分析必须依赖额外的 NLP 处理。Kimi 的学术检索输出停留在“文献列表”层面，而非“可分析语料”。
四、讨论：能力边界的定位
将上述发现置于 Kimi 官方能力描述的框架中，可以更精确地定位其边界。
Kimi 官方强调 Agentic Search 的“自主规划与工具调用”能力，并声称覆盖“学术期刊数据库”。从两份记录看，这一能力在检索发起阶段是有效的：Kimi 能够构造合理的检索式、调用 PubMed 或 Scholar、返回结构化程度尚可的结果列表。问题出在检索结果的处理深度上。
一个合理的解释是，Kimi 的学术检索模块被设计为“搜索引擎式”而非“数据库式”。它模仿的是用户在浏览器中执行检索、浏览结果页的行为，而非像专业文献工具（如 Scopus API、PubMed E-utilities 配合全文获取管道）那样执行多步骤的数据获取。Scholar 侧的截断摘要正是这一设计逻辑的直接后果：用户看到的摘要与在 Scholar 网页上看到的一致，Kimi 没有“多走一步”去原文页补全。
这一设计选择在“快速了解某领域有哪些相关论文”的场景下是合理的，但在“构建可分析的文献语料库”的场景下则不够。后者要求的是：(1) 完整摘要，(2) 全文或至少 PDF 获取，(3) 结构化字段抽取。两份记录在第一项上表现分化（PubMed 好、Scholar 差），在第二项上均缺失，在第三项上均缺失。
值得注意的是，Kimi 并非在技术上不具备相关能力。其 API 文档显示，联网搜索 Basic 接口在设置 include_content=true 时可以“返回网页正文”。如果 Kimi 在学术检索流程中启用这一能力，对 pdf_links 或 url 字段执行内容抓取，Scholar 侧的摘要截断问题可以在相当程度上缓解。当前未这样做，更可能是产品优先级或流程编排的问题，而非底层能力的硬限制。
五、结论
基于对两份 Kimi 生成的检索记录的分析，本文得出以下结论：
第一，Kimi 的学术文献检索功能在“种子发现”层面是合格的。它能够按检索式返回相关文献列表，PubMed 侧提供完整摘要与规范元数据，Scholar 侧提供被引次数与 PDF 入口。对于“快速摸底”型需求，这一输出具有实用价值。
第二，Kimi 的检索能力在“语料可用性”层面存在明确边界。PubMed 侧不跟进全文，Scholar 侧摘要截断，两份记录均未将文献信息结构化。这意味着用户若要进行方法学比较、主题建模或系统性计量分析，Kimi 的输出只能作为起点，而非可直接使用的数据产品。
第三，这一边界的根源更可能在于产品定位与流程编排，而非技术能力缺失。Kimi 具备 URL 抓取与网页正文提取的能力，但学术检索模块未将这些能力应用于检索结果的深度处理。如果 Kimi 希望在学术场景中从“发现工具”升级为“研究助理”，补齐“全文跟进 + 字段结构化”两步是必要的，也是在其现有技术栈内可实现的。
第四，对于当前使用 Kimi 进行文献检索的研究者，合理的期望是：将其视为一个高效的“种子清单生成器”，而非“语料库构建器”。PubMed 记录可直接用于筛选，Scholar 记录的被引数据可用于初步的影响力判断，但全文获取与深度分析仍需依赖其他工具或人工完成。
参考文献
- Kimi. Agentic Search 帮助中心.
- Kimi. Kimi 搜索功能使用指南.
- Kimi API 开放平台. 联网搜索最佳实践.