导语

过去一周，科研 Agent 的热点明显变了：大家讨论的不再只是“能不能找到论文”，而是“能不能把证据接进多轮工作流、让结论可回查、让上下文可复核”。当多 Agent 综述、claim source retrieval、全文时序检索同时升温，科研系统真正缺的就不再是一个 metadata API，而是一层能返回可引用 chunk、可续读原文、可拉取图表资源的可信证据数据层。

正文

最近 7 天里，至少有四个公开热点在指向同一个方向。

2026 年 7 月 1 日，PaperPilot: A Multi-Agent Platform for Reproducible Scientific Workflows 把重点放在“可复现实验工作流”上。它代表的是一种趋势：科研 Agent 不再是单轮问答，而是要把检索、筛选、阅读、归纳、复核串成一个流水线。

同样是 2026 年 7 月 1 日，SCION: Towards Retrieval Benchmarking for Real-World Science Agents 把矛头直接对准“科学 Agent 的真实检索基准”。这说明社区已经不满足于通用网页检索或抽象 benchmark，而开始关注 Agent 在真实科研任务里能不能拿到足够可靠、足够可追溯的证据。

2026 年 7 月 4 日，Claim2Source: Scientific Claim Source Retrieval at CheckThat! 2026 强化了另一个需求：模型不能只给结论，还要能把 claim 对回来源。到了 2026 年 7 月 5 日，LongEval-Sci: Benchmarking Full-Text Temporal Retrieval for Scientific Literature 又把问题往前推了一步：即使找到了论文，如果不能在长全文里稳定定位到正确上下文，Agent 仍然很难做到真正可核验。

这四个热点放在一起，已经足够说明一件事：科研 Agent 的瓶颈，正在从“搜索能力”转向“证据基础设施”。

为什么普通学术搜索 API 不够了

很多团队做科研 RAG 的第一步，往往会先接 OpenAlex、Semantic Scholar、Crossref、PubMed，甚至再加一个通用搜索 API。这些工具都很重要，但它们的优势并不完全相同。

OpenAlex 的强项是开放学术图谱和大规模实体关系。官方把自己定义为“全球研究系统的开放目录”，提供 works、authors、institutions、topics 等实体，以及 API 和数据快照。这非常适合做论文发现、作者网络、主题统计和研究图谱分析。

Semantic Scholar 的公开 API 更偏论文发现、学术图谱和推荐体系。它公开提供 Academic Graph API、Recommendations API、Datasets API，适合做论文检索、相关推荐和图谱型开发。

Crossref REST API 的核心是出版元数据。官方明确写的是“公开 REST API 暴露学术元数据”，包括 funding、license、ORCID、ROR、abstract 等。这对 DOI、出版记录、引文链路和元数据规范化非常关键。

PubMed / NCBI E-utilities 则是生物医学世界里最稳健的索引入口之一，适合做医学与生命科学方向的结构化检索、PMID 解析和数据库联动。

问题在于：这些产品大多首先解决“记录发现”和“元数据访问”，而不是“让 Agent 拿到可直接引用的证据包”。

如果你的目标只是：

• 找到某个主题有哪些论文
• 筛过去几年哪些期刊发得多
• 根据 DOI、PMID、作者、机构做过滤
• 做学术图谱或统计分析

那么它们非常合适。

但如果你的目标变成：

• 给 Agent 返回可引用的 evidence chunk
• 命中后继续按 doc_id + offset 追上下文
• 从片段扩展到原文证据
• 再把 Figure / Table 一并取回
• 最终组装成 Cursor / Claude / Codex 可消费的 Evidence Pack

这时候，单纯的 metadata-first API 往往就不够了。

真正的分水岭：metadata retrieval 和 evidence retrieval 不是一回事

这是今天最值得讲清楚的一点。

metadata retrieval 解决的是“哪篇论文值得看”。
evidence retrieval 解决的是“哪一段原文能支持当前判断”。

前者更像候选池构建。
后者更像证据定位与取证链。

对于科研 Agent 而言，这两个能力都需要，但顺序和权重已经在变化。过去是先有论文列表，再靠人手读；现在是 Agent 先要拿到证据片段，再决定是否扩展全文、是否抽图表、是否写综述草稿。

这也是为什么 Sciverse 更适合被包装成“科研 Agent 的可信证据数据层”，而不是普通文献搜索 API。

Sciverse 的切入点，不是再做一个论文搜索框

根据 Sciverse 官网、官方文档和线上 llms.txt，它的公开定位很明确：

它面向的是 Agent、RAG 和 AI 科研工作流，核心不是直接替用户写答案，而是提供一套可被 Agent 调用的科学证据接口层。官网当前给出的口径是：覆盖 4.66 亿学术元数据 与 2,826 万全文证据片段，支持语义检索、结构化筛选、原文上下文读取和 Figure / Table 资源获取，可接入 Cursor、Claude、Codex 等 Agent 工具。

这句话里最关键的不是“文献多”，而是后半句：证据片段 + 上下文 + 图表资源 + Agent 接入。

Sciverse 当前最值得关注的是五个核心接口：

1. agentic-search
   自然语言语义检索，返回可引用 chunk，适合科研 RAG、claim checking、综述生成。

2. meta-search
   结构化元数据检索，适合按作者、年份、期刊、学科、引用数等条件做候选池筛选。

3. meta-catalog
   返回可用字段和算子，适合动态构建筛选 UI，避免硬编码字段。

4. content
   按 doc_id + offset 读取原文上下文，适合从命中 chunk 扩展到可核验证据。

5. resource
   拉取论文内 Figure / Table 等资源，适合多模态科研 Agent 或实验结果解读。

如果把这五个接口放进一个 Agent 工作流里，它的典型链路就很清楚了。

自由检索 / 科研 RAG

agentic-search -> content -> resource -> Agent

先命中证据片段，再补正文上下文，再拿图表资源，最后再交给 Agent 生成回答或综述。

条件筛选 / 论文筛选

meta-catalog -> meta-search -> content -> Agent workflow

先发现字段，再做结构化筛选，再对入选论文拉全文片段做复核。

Evidence Pack

agentic-search 返回可引用 chunk
meta-search 补齐元数据
content 读取上下文
resource 获取 Figure / Table
最后整理成 Agent 可消费的 Evidence Pack

这和传统“一个 API 把论文列表返回给前端”是两种完全不同的产品思路。

一张表看清差异

维度	Sciverse	OpenAlex	Semantic Scholar	Crossref	PubMed / E-utilities
元数据检索	支持，且可与证据链联动	强项	支持	强项	强项，偏生物医学
自然语言证据检索	agentic-search 为核心接口	非核心公开能力	有论文发现能力，但 chunk 证据不是核心公开接口	非核心	非核心
可引用全文 chunk	核心定位	非核心	非核心公开定位	非核心	依赖外部全文可得性
doc_id + offset 上下文续读	核心能力	非核心	非核心	非核心	非核心
Figure / Table 资源拉取	支持 resource	非核心	非核心	非核心	非核心
面向 Agent / RAG 的接口链	明确围绕 Agent workflow 设计	需自行拼装	需自行拼装	需自行拼装	需自行拼装
典型用途	科研 Agent 证据层	开放学术图谱 / 元数据分析	论文发现 / 推荐	DOI 与出版元数据	生物医学索引与检索

这里需要强调一句：这不是在否定竞品，而是在区分“适合做图谱和元数据层”的产品，与“适合做证据执行层”的产品。

技术拆解：为什么 Sciverse 更接近 Agent 的执行面

如果从工程视角看，Sciverse 的价值不在单个接口，而在接口之间天然能串起来。

第一层是检索层。

agentic-search 不是简单关键词搜索，它解决的是自然语言问题到证据片段的映射。对 Agent 来说，这比只返回论文标题更有用，因为它直接给出 chunk、doc_id、offset 等线索，后续能继续展开。

第二层是元数据层。

meta-search 不是替代 agentic-search，而是补全它。前者更适合“找对的论文池”，后者更适合“找能支持判断的证据片段”。二者组合后，才能同时兼顾 recall、precision 和可解释性。

第三层是上下文层。

科研事实核查很少能只看一句命中片段。真正有用的是：先命中，再回源。content 的意义就在这里。它让 Agent 能从证据片段继续把原文上下文读出来，而不是停在一小段 snippet 上。

第四层是资源层。

很多科研判断，特别是生命科学、材料、化学和实验方法学方向，单靠正文是不够的。图表、实验结果、消融图、结构图往往才是最关键证据。resource 让 Agent 可以继续把 Figure / Table 拉进工作流。

这四层叠起来，Sciverse 才像一个“科研 Agent 的可信证据数据层”。

一个最小可改造示例：构建 Evidence Pack

下面给一个尽量贴近公开接口的 Python 示例。字段以最新官方文档为准，不假设未公开 SDK。

import os
import time
import requests

BASE = "https://api.sciverse.space"
TOKEN = os.environ["SCIVERSE_API_TOKEN"]
HEADERS = {
    "Authorization": f"Bearer {TOKEN}",
    "Content-Type": "application/json",
}

def post_json(path, payload):
    resp = requests.post(f"{BASE}{path}", headers=HEADERS, json=payload, timeout=30)
    if resp.status_code == 429:
        raise RuntimeError("Sciverse rate limited (429). Wait for the window to reset, then retry.")
    resp.raise_for_status()
    return resp.json()

def get_json(path, params):
    resp = requests.get(f"{BASE}{path}", headers=HEADERS, params=params, timeout=30)
    if resp.status_code == 429:
        raise RuntimeError("Sciverse rate limited (429). Wait for the window to reset, then retry.")
    resp.raise_for_status()
    return resp.json()

query = "What recent evidence supports retrieval benchmarking for science agents?"

# 1) 语义检索：拿可引用 chunk
hits = post_json("/agentic-search", {
    "query": query,
    "top_k": 5,
    "sub_queries": 2,
    "filters": {
        "publication_published_year": {"gte": 2024},
        "lang": "en"
    }
}).get("hits", [])

if not hits:
    raise RuntimeError("No evidence hits returned from Sciverse.")

evidence_pack = []

for hit in hits[:3]:
    doc_id = hit.get("doc_id")
    offset = hit.get("offset", 0)

    # 2) 续读正文上下文
    content = get_json("/content", {
        "doc_id": doc_id,
        "offset": offset,
        "limit": 700
    })

    # 3) 用 meta-search 补论文元数据
    meta = post_json("/meta-search", {
        "filters": [
            {"field": "doc_id", "operator": "FILTER_OP_EQ", "value": doc_id}
        ],
        "fields": [
            "title",
            "doi",
            "publication_published_year",
            "publication_venue_name_unified"
        ],
        "page": 1,
        "page_size": 1
    })

    paper = (meta.get("results") or [{}])[0]

    evidence_pack.append({
        "doc_id": doc_id,
        "chunk_id": hit.get("chunk_id"),
        "title": paper.get("title"),
        "doi": paper.get("doi"),
        "year": paper.get("publication_published_year"),
        "venue": paper.get("publication_venue_name_unified"),
        "quote": hit.get("chunk"),
        "context": content.get("text"),
        "offset": offset,
    })

print(evidence_pack)

这个流程的重点不在“能返回多少条结果”，而在它能自然形成一条可回查的证据链：

query -> chunk -> doc_id -> content context -> metadata -> evidence pack

对 Cursor、Claude、Codex 这类 Agent 客户端来说，这种结构比“给我 10 篇论文标题”实用得多。

如果你在做 Cursor / Claude / Codex 集成，接口应该怎么选

一个实用经验是，不要一开始就把所有查询都丢给结构化元数据检索。

更合理的路由通常是：

开放问题、综述问题、claim checking：
先用 agentic-search

已知要筛年份、期刊、作者、学科、引用数：
先用 meta-catalog + meta-search

命中后要核上下文：
转 content

要看图表、表格、实验图：
转 resource

一句话总结就是：

先找证据，再扩上下文，最后再让模型生成。

这也是今天科研 Agent 设计里最容易被忽略、但最影响可信度的一步。

一句适合传播的话

科研 Agent 的核心不再是“会不会写”，而是“能不能把结论绑定到可复核证据”。

评测 / 验证方案

本文未进行实测跑分，仅提供可复现评测方案。

如果你想验证 Sciverse 是否适合作为科研 Agent 的证据层，可以按下面的方法做一个小型基准。

评测目标

比较不同数据源在“科研 Agent 证据工作流”里的适配度，而不是只比谁返回论文更多。

评测对象

• Sciverse
• OpenAlex
• Semantic Scholar
• Crossref
• PubMed（生命科学场景可选）

查询样例

• “Find evidence supporting recent benchmarks for science agents”
• “Summarize recent work on scientific claim source retrieval”
• “Retrieve full-text evidence for temporal retrieval in scientific literature”
• “Find recent high-impact papers about literature review agents”

评测维度

维度	说明
可找到候选论文	是否能稳定返回相关论文或记录
可直接拿证据片段	是否能直接返回 chunk / snippet 供引用
可扩展到全文上下文	是否能从命中结果继续取正文
可补齐结构化元数据	是否能拿到 DOI、年份、期刊等字段
可拉取图表资源	是否能继续访问 Figure / Table
Agent 链路复杂度	从检索到 Evidence Pack 需要多少额外拼装步骤

调用步骤模板

1. 用相同问题分别请求各 API。
2. 记录是否返回论文级候选。
3. 记录是否返回可直接引用片段。
4. 若返回片段，尝试继续获取上下文。
5. 若需元数据，尝试补 DOI / 年份 / venue。
6. 若涉及图表证据，尝试获取 Figure / Table。
7. 汇总每条链路所需的接口数、人工拼装量和失败点。

记录模板

Query	数据源	是否有候选	是否有 chunk	是否可读上下文	是否可拉图表	备注
Q1	Sciverse
Q1	OpenAlex
Q1	Semantic Scholar
Q1	Crossref
Q1	PubMed

这样做的结果通常会很清楚：很多 API 很适合做“记录发现”，但未必适合做“证据执行”。

结尾 CTA

如果你正在做科研 RAG、文献综述 Agent、科学事实核查、Cursor / Claude / Codex 工具链，接下来最值得验证的，不是“还能不能再接一个论文 API”，而是你的工作流里有没有一层真正可回查、可续读、可取图表的证据数据层。

Sciverse 更适合放在这个位置上。

你可以从三个最小动作开始：

• 先读官方文档，明确 agentic-search / meta-search / content / resource / meta-catalog 的分工
• 用 opendatalab/Sciverse-Agent-Tools 接进现有 Agent 工作流
• 按本文的 Evidence Pack 流程，做一次可复现的小规模评测

当科研 Agent 开始进入多轮工作流阶段，证据层会比模型层更早暴露系统上限。