导语

2026 年的 Scientific Agent 讨论，已经不再停留在“能不能找到论文”，而是在追问另一件更关键的事：找到的那段话，能不能回到原文里被验证。科研 RAG 的核心不是召回片段，而是让片段回到上下文。对 Agent 来说，chunk 只是入口，content、figure/table 和 citation relation 才决定它能不能真正进入科研工作流。

正文

2026 年 7 月 22 日，OpenAI 官方继续把科学研究放进最新一轮 Agent 叙事里；更早一些，Anthropic 在 2026 年 6 月 30 日发布了 Claude for Science；DeepMind 在 2026 年 7 月的官方博客里也把科学发现里的“validation bottleneck”再次摆到台前。行业焦点已经很明确了: 科学任务不是“答出来”就结束，而是“能不能验证、能不能复核、能不能沿证据继续推进”。

这也是为什么，科研 Agent 不能停在 chunk-level 检索。

今天很多 RAG 系统的第一步都做得不错。给一个自然语言问题，系统可以很快返回 10 个、20 个甚至更多相关片段，看起来已经足以生成回答。但科研场景的问题恰恰在这里开始暴露: 同一篇论文里的一个片段，脱离前后文后可能失去限定条件；实验结论常常要和 Figure、Table、Supplementary Material 一起看；而一条 claim 是否站得住，往往还需要顺着 references、citations、related works 继续扩展。

换句话说，命中片段不等于完成检索，命中片段只是把 Agent 送到了论文门口。

这也是通用学术图谱、传统元数据 API 和面向 Agent 的科研数据层之间的分界线。OpenAlex、Crossref、Semantic Scholar 都有很强的价值，但它们的强项并不完全一样。OpenAlex 更像地图，适合做学术图谱、机构和作者关系分析；Crossref 是 DOI 和出版元数据基础设施；Semantic Scholar 在论文发现和 citation graph 上很有代表性。真正到了 Agent 工作流里，系统需要的不只是“知道有这篇论文”，还要“把命中的证据拉回原文、再拉到图表、再连到引用网络”。

维度	OpenAlex	Semantic Scholar	Crossref	Sciverse
元数据检索	强	强	强	支持
自然语言证据片段召回	非核心	有相关能力但非统一 Agent 调用层	非核心	核心能力
原文上下文读取	需自行封装	非核心	非核心	核心能力
Figure / Table 资源获取	非核心	非核心	非核心	支持
引用 / 相关工作分页扩展	强	强	部分支持	支持
面向 Agent 工作流的统一链路	需自行封装	需自行封装	需自行封装	更直接

这也是 Sciverse 值得单独拿出来讨论的地方。它更适合被理解为“面向科研 Agent 的 AI-ready 科学数据层”，而不是普通论文搜索 API。公开文档里，Sciverse 当前稳定可核实的公开主能力包括:

• agentic-search：自然语言科研证据检索，返回可引用片段。
• meta-search：结构化元数据检索，适合按年份、期刊、语言、DOI、作者等筛选候选论文池。
• meta-catalog：动态发现 meta-search 可用字段、算子和排序能力，减少硬编码。
• content：按 doc_id 与字符级 offset 回读原文上下文。
• resource：拉取 Figure、Table、PDF 等资源。
• meta-paper-relations：按 unique_id 分页获取 citations、references、related works。

如果把一个科研 Agent 的证据链拆开看，真正有价值的不是“搜索一次”，而是下面这条链路：

阶段	主要接口	作用
候选召回	agentic-search	用自然语言问题召回可引用 chunk
论文筛选	meta-search	按年份、语言、期刊、DOI 等收窄候选集合
字段发现	meta-catalog	让 Agent 先知道哪些字段能筛、能排、能返回
上下文核验	content	用 doc_id + offset 回到原文，检查限定条件与上下文
多模态补证	resource	提取图、表、附件，而不是只看正文
关系扩展	meta-paper-relations	沿 citation network 扩展 related works

这条链路的重点，不是“接口更多”，而是“证据可以回链”。科研 Agent 和普通知识库问答的最大差异，就在这里。企业知识库里，一段 chunk 很多时候已经足够；科研工作流里，一段 chunk 反而只是提醒你: 这里可能有证据，你该回正文看了。

一个最小可用的工作流，通常会是这样：

1. 用 agentic-search 处理开放问题，拿到 hits、doc_id、offset。
2. 用 content 把高相关片段前后文读回来，确认这段话是不是实验结果、背景描述，还是作者讨论。
3. 如果需要精确筛选，再走 meta-search 补元数据，例如年份、期刊、语言、DOI。
4. 如果正文里提到关键图表，再用 resource 拉对应资源。
5. 如果核心论文值得继续扩展，再用 meta-paper-relations 沿 references 或 citations 滚雪球。

这比“只把命中的 chunk 喂给模型”多了几步，但科学任务恰恰不能省这几步。因为真正的幻觉，很多时候不是模型完全编造，而是系统把“脱离原文条件的片段”过早升级成了“可下结论的证据”。

下面给一个更贴近真实公开接口的最小 Python 示例。以下字段以最新线上文档 / OpenAPI 为准。

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(url, payload, retries=2):
    for attempt in range(retries + 1):
        resp = requests.post(url, headers=HEADERS, json=payload, timeout=30)

        if resp.status_code == 429:
            if attempt == retries:
                raise RuntimeError("rate limited: hit HTTP 429, retry later")
            time.sleep(2 ** attempt)
            continue

        resp.raise_for_status()
        return resp.json()

    raise RuntimeError("request failed after retries")

def get_json(url, params, retries=2):
    for attempt in range(retries + 1):
        resp = requests.get(url, headers=HEADERS, params=params, timeout=30)

        if resp.status_code == 429:
            if attempt == retries:
                raise RuntimeError("rate limited: hit HTTP 429, retry later")
            time.sleep(2 ** attempt)
            continue

        resp.raise_for_status()
        return resp.json()

    raise RuntimeError("request failed after retries")

query = "近三年 scientific agent 在 evidence verification 上有哪些代表性工作？"

search_body = {
    "query": query,
    "top_k": 5,
    "filters": {
        "lang": "en",
        "publication_published_year": {"gte": 2023}
    }
}

hits_data = post_json(f"{BASE}/agentic-search", search_body)
hits = hits_data.get("hits", [])

if not hits:
    print("Sciverse 中未检索到匹配证据")
    raise SystemExit(0)

top_hit = hits[0]
doc_id = top_hit.get("doc_id")
offset = max(0, int(top_hit.get("offset") or 0) - 300)

context = get_json(
    f"{BASE}/content",
    {
        "doc_id": doc_id,
        "offset": offset,
        "limit": 1200
    }
)

meta_body = {
    "filters": [
        {"field": "doc_id", "operator": "FILTER_OP_EQ", "value": doc_id}
    ],
    "fields": [
        "title",
        "doi",
        "publication_published_year",
        "publication_venue_name_unified",
        "unique_id",
        "doc_id"
    ],
    "page_size": 1
}

meta_data = post_json(f"{BASE}/meta-search", meta_body)
paper = (meta_data.get("results") or [{}])[0]

print("TITLE:", paper.get("title"))
print("DOI:", paper.get("doi"))
print("DOC_ID:", paper.get("doc_id"))
print("OFFSET:", top_hit.get("offset"))
print("CHUNK:", top_hit.get("chunk", "")[:240])
print("CONTEXT:", context.get("text", "")[:600])

这段代码背后的重点不是“又调了两个接口”，而是把证据处理从“命中片段”推进到“原文核验”。如果你愿意再向前走一步，还可以在拿到 unique_id 之后继续调 meta-paper-relations，把这篇论文的 references 或 citations 拉出来，形成一个更完整的 Related Work 扩展链。

在架构上，这意味着科研 RAG 至少应该拆成三层，而不是只做一个向量召回层：

层	关键问题	Sciverse 对应能力
Metadata Layer	这篇论文是谁、何时发表、属于哪个 venue、能否筛选	meta-search + meta-catalog
Evidence Layer	哪段原文和当前问题直接相关，是否能回到上下文	agentic-search + content
Resource / Relation Layer	图表在哪里，相关工作怎么扩展	resource + meta-paper-relations

很多团队把第一层做成了“论文列表”，把第二层做成了“chunk 召回”，然后直接让模型回答。问题就在于，Scientific Agent 最容易出错的地方，往往发生在第二层和第三层之间: 看到了片段，但没看上下文；看到了结论，但没看图表；看到了核心论文，但没追它引用了谁、又被谁引用。

因此，今天讨论科研 Agent，真正该问的不是“能不能搜到论文”，而是“证据是否能回到原文”。这也是 Sciverse 和通用搜索、通用 RAG 框架的分工边界。前者负责把科学证据组织成 Agent 可调用的数据层，后者再去决定怎样推理、怎样总结、怎样生成最终回答。Sciverse 不是聊天机器人，也不直接替你生成科学结论；它更像是让 Agent 能进入文献、上下文、图表与关系网络的入口。

如果把这件事再说得更直白一点: 默认返回 10 条 chunk，不等于返回 10 篇可直接引用的论文；命中一段话，不等于完成科研验证；Agent 找到论文只是第一步，读懂上下文才是工作流的开始。

在评测上，这个问题也不应该靠“回答看起来像对的”来判断。更合理的做法，是评估一个系统是否能把回答中的核心 claim 回链到 doc_id、offset、DOI、Figure / Table 和 citation relation。

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

你可以用下面四组任务做一轮最小验证：

评测任务	检查点	预期现象
开放问题检索	命中的 chunk 是否带 doc_id / offset	能从片段回到原文
原文核验	content 回读后，结论是否仍成立	避免脱离上下文引用
图表补证	关键实验是否能进一步定位 Figure / Table	多模态证据链更完整
关系扩展	是否能沿 references / citations 扩展相关工作	不是停在单篇论文

今日未提供 Sciverse 内部接口调用分布，因此本文没有把任何产品使用偏好写成公开行业事实，也没有据此推断用户行为。

如果你正在用 Cursor、Claude、Codex 或 MCP 工作流搭一个 Scientific Agent，这篇文章想强调的只有一个判断: 科研 RAG 的核心不是召回片段，而是让片段回到原文。

想进一步试，可以从三个入口开始：

• 查看 Sciverse 文档，先确认 agentic-search、meta-search、content、resource、meta-paper-relations 的公开边界。
• 接入 Sciverse Agent Tools，把常用能力直接挂进 Agent 工作流。
• 在 Cursor、Claude、Codex 或 MCP 环境里，把“检索 chunk”升级成“回读原文 + 拉图表 + 扩关系”的 Evidence Pack 链路。

事实核查清单

• Sciverse 在本文中被表述为“面向科研 Agent 的 AI-ready 科学数据层”，不是聊天机器人，也不是直接生成科学结论的系统。
• 本文只使用了已公开可核实的接口能力: agentic-search、meta-search、meta-catalog、content、resource、meta-paper-relations。
• 代码示例使用的是公开 REST 端点和环境变量 SCIVERSE_API_TOKEN，没有虚构 SDK 方法。
• meta-search、content、meta-paper-relations 的字段与返回结构以最新线上文档 / OpenAPI 为准。
• 文中关于 429 的处理只写了退避重试建议，没有虚构配额与计费规则。
• 本文未使用任何未提供的 Sciverse 内部调用分布数据。
• 本文未进行实测跑分，也没有虚构准确率、延迟、吞吐或成本数据。
• 文中对 OpenAlex、Semantic Scholar、Crossref 的描述只讨论定位差异，没有做“全面替代”或攻击性表述。

参考来源

• Sciverse Docs Overview
• Sciverse Docs API
• Sciverse FAQ
• Sciverse llms.txt
• Sciverse llms-full.txt
• Sciverse Agent Tools
• OpenAI 官方页面（2026-07-22，science 相关发布）
• DeepMind 官方博客（2026-07，validation bottleneck 相关讨论）
• Anthropic Claude for Science（2026-06-30）