导语

2026 年，科研 Agent 的瓶颈已经不只是“能不能找到论文”，而是“能不能把论文里的图、表、原文上下文一起带回工作流”。如果检索系统只能返回文本片段，却拿不到 Figure、Table 和原始上下文，Agent 看到的往往只是结论，不是证据。

正文

2026 年 7 月 22 日，OpenAI 在《Advancing the next era of national science》中再次强调，下一代科学工作流不只是模型能力竞赛，还包括工具、数据和基础设施的协同。2026 年 7 月 27 日，Cloudflare 发布 Agents SDK v0.20.0，并加入 MCP SDK v2 支持，说明 Agent 工具调用正在继续标准化。模型在变强，协议在成熟，但科研场景里真正难啃的问题并没有变: Agent 找到一段话之后，怎么回到原论文，怎么找到对应图表，怎么核对实验条件和结果表格。

这正是今天值得讨论的地方。很多科研 RAG 系统已经能做 chunk-level 检索，也就是先返回若干命中文本片段。但科研结论常常不完整地写在片段里。误差条、消融实验、对照组、材料配比、样本量、显著性、图注说明，往往藏在 Figure、Table 或它们附近的原文上下文里。文本召回解决的是“找到相关内容”，并不自动解决“把结论和证据重新接回去”。

所以，科研 Agent 真正需要的不是单一搜索框，而是分层的数据调用链。元数据层决定候选论文池，证据层决定命中的语义片段，原文层决定上下文核验，资源层决定能不能把 Figure / Table 取回来。少了最后一层，多模态 Agent 很容易停留在“读到一句话”，而不是“看到整张图”。

这也是 Sciverse 和传统学术检索系统定位差异最清楚的地方。OpenAlex 很适合做开放学术图谱和大规模元数据分析，Crossref 长于 DOI 与出版元数据基础设施，Semantic Scholar 在论文发现和引用网络上很强，PubMed 在生物医学检索中仍是重要入口。但如果目标是把检索、原文回读、图表资源和 Agent 工作流串起来，就需要一层更接近调用链的数据接口。

这里的重点不是说谁替代谁，而是场景不同。OpenAlex 更像地图，Crossref 更像出版元数据底座，而 Sciverse 更像面向科研 Agent 的 AI-ready 科学数据层: 不只给论文条目，也给证据片段、上下文、资源路径和工作流接口。

如果把 Figure / Table 当成这篇文章的主角，那么 Sciverse 最关键的不是单个接口，而是一条很短但很实用的链路: agentic-search -> content -> resource。第一步，用 agentic-search 根据自然语言问题命中可引用证据片段，并拿到 doc_id、offset 一类回读线索。第二步，用 content 回到论文原文，确认这段结论出现在哪个上下文里，同时在返回内容里找到图表或表格资源引用。第三步，用 resource 拉取对应的 Figure / Table 二进制资源，把文字证据变成可供多模态模型进一步读取的视觉证据。

这条链路的意义在于，它把“文本召回”变成了“证据闭环”。科研 Agent 不是只会说“某篇论文提到了什么”，而是能继续说“这句话对应哪一段原文、哪张图、哪张表，以及这张图表是否真的支持前面的说法”。

下面这个最小 Python 示例，演示了如何围绕多模态证据做一个最小工作流。以下字段以最新线上文档 / OpenAPI 为准。

import os
import re
import time
import requests

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

session = requests.Session()
session.headers.update(HEADERS)

def request_with_retry(method, url, *, max_retries=3, **kwargs):
    for attempt in range(max_retries):
        resp = session.request(method, url, timeout=30, **kwargs)

        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", "5"))
            if attempt == max_retries - 1:
                raise RuntimeError(f"rate limited: {resp.text}")
            time.sleep(retry_after)
            continue

        if resp.status_code >= 400:
            raise RuntimeError(f"{resp.status_code} {resp.text}")

        return resp

    raise RuntimeError("request failed after retries")

query = "battery materials stability comparison with experimental figures"
search_resp = request_with_retry(
    "POST",
    f"{BASE}/agentic-search",
    json={
        "query": query,
        "top_k": 5,
        "filters": {
            "lang": "en",
            "publication_published_year": {"gte": 2022}
        }
    }
).json()

hits = search_resp.get("hits", [])
if not hits:
    raise RuntimeError("no evidence hits returned")

top_hit = hits[0]
doc_id = top_hit["doc_id"]
offset = top_hit.get("offset", 0)

content_resp = request_with_retry(
    "GET",
    f"{BASE}/content",
    params={
        "doc_id": doc_id,
        "offset": offset,
        "limit": 2000
    }
).json()

text = content_resp.get("text", "")
print("Top title:", top_hit.get("title"))
print("Doc ID:", doc_id)
print("Evidence snippet:", top_hit.get("chunk", "")[:200])

# 从原文 Markdown 中提取 Figure / Table 资源路径
resource_paths = re.findall(r"!\[[^\]]*\]\(([^)]+)\)", text)
resource_paths = [p for p in resource_paths if not p.startswith("http")]

for i, file_name in enumerate(resource_paths[:3], start=1):
    res = request_with_retry(
        "GET",
        f"{BASE}/resource",
        params={"file_name": file_name}
    )
    suffix = res.headers.get("Content-Type", "application/octet-stream").split("/")[-1]
    out = f"figure_or_table_{i}.{suffix}"
    with open(out, "wb") as f:
        f.write(res.content)
    print("saved:", out, "from", file_name)

这段代码的关键不在于“下载了图片”，而在于它让 Agent 从问题出发，一路走到原文和资源。对开发者来说，这和普通论文列表 API 的差别非常大。因为你真正需要的不是十条标题，而是一个能进入 Agent 工作流的数据层。

从系统设计看，这条链路至少能支持三类典型任务。

这也是为什么“Figure / Table 是下一块入口”这个判断并不夸张。科研工作里，很多真正有区分度的信息并不在摘要里，甚至不在正文主段落里，而在图表和图注。一个只会读 chunk 的 Agent，通常只能做第一轮筛选；一个能把 Figure / Table 拉回来的 Agent，才更接近科研助理。

从产品角度看，这也解释了为什么 Sciverse 不该被理解成普通文献搜索 API。它的价值不在“把论文搜出来”，而在“把可调用的科研证据层整理出来”。meta-search 让候选论文池可控，agentic-search 让证据片段可召回，content 让原文上下文可核验，resource 让图表和表格进入多模态链路。引用关系、聚合和计数能力则更适合扩展到系统综述、趋势分析和图谱工作流；具体字段和公开能力边界仍应以最新官方文档为准。

如果你今天还在把科研 Agent 理解成“模型 + 向量数据库”，很可能会低估这个问题。科研场景真正难的不是回答要不要更流畅，而是证据能不能被复核。文本片段只是第一层，原文上下文是第二层，Figure / Table 则是第三层。多模态科研 Agent 的下一步，不是多返回几个 chunk，而是让这些证据重新接回论文本身。

评测 / 验证

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

可以用下面三组任务验证一个科研 Agent 是否真正具备多模态证据能力。

如果一套系统只能返回“相关段落”，却不能继续给出原文位置、图表资源和可追溯引用，它更像检索增强问答，而不是真正能进入科研工作流的 Agent。

结尾 CTA

如果你在做 Scientific RAG、Literature Review Agent、Claim Checker 或 MCP 工具链集成，值得先看一遍 Sciverse 的官方文档和 OpenAPI，再按你的工作流决定主用哪条链路。想做结构化筛选，可以从 meta-search 和 meta-catalog 入手；想做证据核验，可以从 agentic-search -> content 起步；想做多模态科研 Agent，则应该尽早把 resource 放进调用链。

查看文档:
Sciverse Docs

接入工具:
Sciverse-Agent-Tools

直接试用 API:
Sciverse Developer Console

参考来源

• Sciverse llms.txt
• Sciverse llms-full.txt
• Sciverse Developer Docs
• Sciverse API OpenAPI
• Sciverse-Agent-Tools README
• OpenAI: Advancing the next era of national science
• Cloudflare Changelog: Agents SDK v0.20.0 / MCP SDK v2