导语

2026 年 8 月上旬，行业在集中讨论更自主的 personal agent 和 agent workflow。但对科研场景来说，问题从来不只是“能不能调用工具”，而是“能不能拿到可复核的证据对象”。文本检索解决的是找到论文，Figure / Table 接口解决的才是读懂实验结果、方法流程和对比结论。下一代科研 Agent 的分水岭，不会只在更长上下文，而在它能否把论文、原文段落、图表资源和引用关系接成一条可验证链路。

正文

过去一周，Agent 话题重新升温。8 月 6 日，Axios 讨论了 AI lab 对更自主系统的判断；8 月 8 日，Business Insider 报道 Meta 将 personal agent 视为下一阶段重点。这个讨论很热，但放到科研工作流里，常常会跑偏成“给 Agent 更多 token、更多工具、更多对话轮次”。

问题是，科研 Agent 的瓶颈并不首先出在对话框，而出在证据对象。

在科研场景里，很多关键信息根本不适合只用纯文本描述：材料实验的性能对比图、生命科学论文中的 pathway 图、模型架构图、消融实验表、误差条、样本分布、评价指标表。一个 Agent 即使已经检索到了相关论文标题，甚至已经拿到了若干 chunk，也仍然可能缺少最关键的那一层信息载体。它知道“这篇论文可能相关”，但不知道“结论具体画在了哪张图里、哪个表里、与正文哪一段相互对应”。

这也是为什么科研 RAG 和通用 RAG 的差异会越来越大。通用 RAG 可以在很多企业知识库场景里止步于“片段召回 + 回答生成”，但科研工作流通常还要往前走两步：

1. 从论文级候选集缩小到具体证据位置。
2. 从文字证据继续下钻到图表、表格和原文上下文。

如果做不到这两步，Agent 的回答看上去可能很流畅，但很难复核。

这时就能看出不同数据系统的定位差异。OpenAlex、Crossref、Semantic Scholar、PubMed 都很重要，但它们强项并不完全相同。问题不在于谁“更强”，而在于谁更接近 Agent 的执行链路。

维度	Sciverse	OpenAlex	Semantic Scholar	PubMed
结构化元数据检索	支持	强	支持	支持
自然语言证据片段召回	支持	非核心	部分场景可近似	非核心
原文上下文续读	核心能力	需额外封装	非核心	依赖外部全文链路
Figure / Table 资源获取	支持	非核心	非核心	非核心
面向 Agent 的链式调用	强	需自行封装	需自行封装	需自行封装
适合的典型角色	科研 Agent 数据层	学术图谱 / 统计分析	论文发现 / 引文网络	生物医学检索入口

如果把这张表翻译成工程语言，结论很直接：OpenAlex 更像地图，PubMed 更像入口，Semantic Scholar 更像发现层，而 Sciverse 更接近科研 Agent 的执行数据层。它的价值不只是“返回论文列表”，而是让 Agent 能把元数据、原文、图表和关系对象串在同一个工作流里。

以最新公开文档为准，Sciverse 当前公开文档重点覆盖的主链路是 meta-search、agentic-search、meta-catalog、content、resource 和 meta-paper-relations。如果今天这篇文章只挑 3 个最贴合多模态科研 Agent 的接口主角，那应该是：

接口	角色	解决的问题
meta-search	候选论文池	先按年份、语言、DOI、期刊、主题等条件筛出“值得读的论文”
content	原文上下文层	从 doc_id 回到正文，确定图表前后的方法、实验设定和结论语境
resource	证据对象层	直接获取 Figure / Table 等二进制资源，给多模态 Agent 或评审流程使用

这三层叠起来，才更接近真实科研工作流。

很多团队现在的实现方式是：先做 metadata search，再把标题和摘要扔给大模型总结。这在“选论文”阶段够用，但在“读论文”阶段会明显失真。原因很简单，标题和摘要解决不了三类问题：

第一，实验结果到底落在哪个图或哪个表里。
第二，正文里对图表的限定条件是什么。
第三，模型引用的结论是否来自原文上下文，而不是摘要中的压缩表述。

所以更合理的链路不是“检索到就回答”，而是“检索到以后继续取证”。它看起来像这样：

步骤	调用	输出给下一步的关键对象
1	meta-search	doc_id、title、doi、年份等元数据
2	content	正文片段、Markdown 中的资源线索、上下文位置
3	resource	Figure / Table 二进制文件
4	多模态 Agent / 评审器	图表理解、证据包拼装、可复核回答

这条链的意义在于，Agent 不再只依赖“像答案的句子”，而是开始处理“像证据的对象”。

下面给一个最小化的 Python 示例。示例假设 content 返回的 text 中包含 Markdown 形式的资源相对路径；具体字段和内容结构以最新线上文档 / 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()

def request_with_retry(method, url, **kwargs):
    for attempt in range(3):
        resp = session.request(method, url, timeout=30, **kwargs)
        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", "5"))
            time.sleep(retry_after)
            continue
        resp.raise_for_status()
        return resp
    raise RuntimeError("Rate limited too many times; reduce page_size/top_k and retry later.")

# 1) 先用 meta-search 找到候选论文
search_body = {
    "filters": [
        {"field": "language", "value": "en"},
        {"field": "publication_published_year", "operator": "FILTER_OP_GTE", "value": 2023}
    ],
    "fields": ["title", "doi", "doc_id", "publication_published_year"],
    "page": 1,
    "page_size": 5
}

search_resp = request_with_retry(
    "POST",
    f"{BASE}/meta-search",
    headers=HEADERS,
    json=search_body,
)
papers = search_resp.json().get("results", [])
if not papers:
    raise RuntimeError("No papers found.")

paper = next((p for p in papers if p.get("doc_id")), None)
if not paper:
    raise RuntimeError("Metadata found, but no doc_id is available for content reading.")

doc_id = paper["doc_id"]

# 2) 用 content 读取正文上下文
content_resp = request_with_retry(
    "GET",
    f"{BASE}/content",
    headers=HEADERS,
    params={"doc_id": doc_id, "offset": 0, "limit": 4000},
)
content_data = content_resp.json()
text = content_data.get("text", "")

# 3) 从正文中提取可能的图表资源路径
# 以下提取逻辑仅作演示，实际以最新线上文档 / OpenAPI 为准
matches = re.findall(r'!\[[^\]]*\]\(([^)]+)\)', text)
resource_path = next((m for m in matches if not m.startswith("http")), None)
if not resource_path:
    print("No figure/table resource found in the current content slice.")
else:
    resource_resp = request_with_retry(
        "GET",
        f"{BASE}/resource",
        headers={"Authorization": f"Bearer {TOKEN}"},
        params={"file_name": resource_path},
    )
    with open("sciverse-resource.bin", "wb") as f:
        f.write(resource_resp.content)
    print("Saved resource:", resource_path)

print({
    "title": paper.get("title"),
    "doi": paper.get("doi"),
    "doc_id": doc_id,
    "next_offset": content_data.get("next_offset"),
    "more": content_data.get("more"),
})

这段代码真正想说明的，不是怎么写 requests，而是工作流拆分方式。很多科研 Agent 失败，不是因为模型太弱，而是因为调用顺序错了：它把图表问题当成文本问题，把证据对象问题当成摘要问题。

如果把这个思路再往前推一步，就会发现 Figure / Table 其实也是一个产品分界线。

当下很多系统把“论文理解”理解成“论文摘要 + 若干文本片段”。但多模态科研 Agent 真正要做的是：

1. 用元数据接口建立候选池。
2. 用正文接口定位论证上下文。
3. 用资源接口提取图表对象。
4. 把图表与正文、标题、DOI、doc_id、引用关系一起封装成 Evidence Pack。

这也是为什么 Sciverse 更适合被描述成“面向科研 Agent 的 AI-ready 科学数据层”，而不是普通搜索 API。它不是直接给最终科学结论，而是给 Agent 提供一组能进入执行链路的科研数据对象：论文记录、原文上下文、图表资源、关系网络和可回溯标识。

如果说上一代科研检索系统主要回答“能不能找到论文”，那下一代科研 Agent 更关心的是“能不能把论文里的证据对象拿出来”。前者决定召回，后者决定复核。

评测 / 验证方案

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

一个可复现的多模态科研 Agent 评测，可以按下面四个维度设计：

评测维度	测试问题	通过标准
候选集质量	meta-search 能否稳定筛出带 doc_id 的候选论文	返回结果可继续进入 content
上下文可追溯性	content 是否能把关键结论还原到正文上下文	关键结论可定位到具体段落/偏移
图表可获取性	resource 是否能取回正文引用的图表资源	返回有效二进制文件且路径安全
证据包完整性	最终回答是否同时携带标题、DOI、doc_id、图表或正文引用	回答可被第三方复核

如果要继续严谨一些，可以把同一批问题同时放到“只用 metadata/摘要”的系统和“metadata + content + resource”的系统里对比，重点不看回答是否流畅，而看三件事：证据定位是否更快、图表解释是否更准确、结论是否更容易复核。

最后再补一个事实边界：今天没有提供 Sciverse 的内部接口调用分布，所以这篇文章没有把任何内部产品信号写成公开行业事实，也没有对 meta-count 或 meta-aggregate 做未核实的外推。以最新公开文档为准，当前最稳定、最适合这篇主题的公开链路，仍然是 meta-search、content 和 resource。

对科研 Agent 来说，找到论文只是开始。真正决定它能不能进入生产，不是它会不会说，而是它能不能把论文里的证据对象取出来、连起来、交还给用户复核。Figure / Table 不一定是今天调用量最高的接口入口，但它很可能会成为下一阶段多模态科研 Agent 最关键的能力分水岭。

如果你在用 Cursor、Claude、Codex 或 MCP 工作流构建科研 Agent，现在最值得补上的，可能不是再加一个总结 prompt，而是把 Sciverse 的原文与资源链路真正接进来。先让 Agent 不只会找论文，再让它开始读图、读表、读上下文，这才是科研场景里更像“工作流”的那一步。

参考来源

• Sciverse Overview: https://sciverse.opendatalab.com/docs#sciverse/overview
• Sciverse API Docs: https://sciverse.opendatalab.com/docs#sciverse/api
• Sciverse FAQ: https://sciverse.opendatalab.com/docs#faq
• Sciverse llms.txt: https://sciverse.opendatalab.com/llms.txt
• Sciverse llms-full.txt: https://sciverse.opendatalab.com/llms-full.txt
• Sciverse OpenAPI: https://sciverse.opendatalab.com/openapi.json
• Sciverse Agent Tools: https://github.com/opendatalab/Sciverse-Agent-Tools
• Axios, 2026 年 8 月 6 日关于 AI 自主系统讨论的报道: https://www.axios.com/
• Business Insider, 2026 年 8 月 8 日关于 personal agent 方向的报道: https://www.businessinsider.com/