论文里的 Figure / Table，为什么会成为多模态科研 Agent 的下一块入口？
导语
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 工作流串起来，就需要一层更接近调用链的数据接口。
| 维度 | Sciverse | OpenAlex | Semantic Scholar | Crossref |
|---|---|---|---|---|
| 结构化元数据检索 | 支持 | 强 | 支持 | 强 |
| 自然语言证据片段检索 | 支持 | 非核心 | 部分场景可替代 | 非核心 |
| 原文上下文回读 | 核心能力 | 需自行拼接 | 非核心 | 非核心 |
| Figure / Table 资源获取 | 支持 | 非核心 | 非核心 | 非核心 |
| 面向 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 为准。
importosimportreimporttimeimportrequests 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)defrequest_with_retry(method,url,*,max_retries=3,**kwargs):forattemptinrange(max_retries):resp=session.request(method,url,timeout=30,**kwargs)ifresp.status_code==429:retry_after=int(resp.headers.get("Retry-After","5"))ifattempt==max_retries-1:raiseRuntimeError(f"rate limited:{resp.text}")time.sleep(retry_after)continueifresp.status_code>=400:raiseRuntimeError(f"{resp.status_code}{resp.text}")returnrespraiseRuntimeError("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",[])ifnothits:raiseRuntimeError("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=[pforpinresource_pathsifnotp.startswith("http")]fori,file_nameinenumerate(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}"withopen(out,"wb")asf:f.write(res.content)print("saved:",out,"from",file_name)这段代码的关键不在于“下载了图片”，而在于它让 Agent 从问题出发，一路走到原文和资源。对开发者来说，这和普通论文列表 API 的差别非常大。因为你真正需要的不是十条标题，而是一个能进入 Agent 工作流的数据层。
从系统设计看，这条链路至少能支持三类典型任务。
| 任务 | 主要问题 | 建议链路 |
|---|---|---|
| Scientific RAG | 片段看起来对，但上下文不完整 | agentic-search -> content |
| Claim Checker | 结论是否真的被原文支持 | agentic-search -> content -> meta-search |
| Multimodal Review Agent | 需要图表、表格、图注与正文联动 | agentic-search -> content -> resource |
这也是为什么“Figure / Table 是下一块入口”这个判断并不夸张。科研工作里，很多真正有区分度的信息并不在摘要里，甚至不在正文主段落里，而在图表和图注。一个只会读 chunk 的 Agent，通常只能做第一轮筛选；一个能把 Figure / Table 拉回来的 Agent，才更接近科研助理。
从产品角度看，这也解释了为什么 Sciverse 不该被理解成普通文献搜索 API。它的价值不在“把论文搜出来”，而在“把可调用的科研证据层整理出来”。meta-search让候选论文池可控，agentic-search让证据片段可召回，content让原文上下文可核验，resource让图表和表格进入多模态链路。引用关系、聚合和计数能力则更适合扩展到系统综述、趋势分析和图谱工作流；具体字段和公开能力边界仍应以最新官方文档为准。
如果你今天还在把科研 Agent 理解成“模型 + 向量数据库”，很可能会低估这个问题。科研场景真正难的不是回答要不要更流畅，而是证据能不能被复核。文本片段只是第一层，原文上下文是第二层，Figure / Table 则是第三层。多模态科研 Agent 的下一步，不是多返回几个 chunk，而是让这些证据重新接回论文本身。
评测 / 验证
本文未进行实测跑分，仅提供可复现评测方案。
可以用下面三组任务验证一个科研 Agent 是否真正具备多模态证据能力。
| 评测项 | 任务设计 | 观察指标 |
|---|---|---|
| 图文一致性 | 给出一个结论，要求 Agent 找到对应 Figure / Table | 是否能返回原文段落、图表路径、图注位置 |
| 上下文完整性 | 对命中 chunk 继续回读前后文 | 是否能避免脱离上下文复述 |
| 证据可复核性 | 输出结论时附带doc_id、offset、资源来源 | 人工是否能按引用链回查 |
如果一套系统只能返回“相关段落”，却不能继续给出原文位置、图表资源和可追溯引用，它更像检索增强问答，而不是真正能进入科研工作流的 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 是面向科研 Agent 的 AI-ready 科学数据层”。
依据: 官方llms.txt、llms-full.txt和开发者文档定位。“Sciverse 当前公开核心能力包括
agentic-search、meta-search、meta-catalog、meta-paper-relations、content、resource”。
依据: 官方llms-full.txt、Sciverse-Agent-ToolsREADME、公开 OpenAPI。“Sciverse-Agent-Tools 当前 README 展示 6 个工具，其中包含
list_paper_relations”。
依据: GitHub README 最新公开内容。“2026 年 7 月 22 日 OpenAI 发布《Advancing the next era of national science》”。
依据: OpenAI 官方页面。“2026 年 7 月 27 日 Cloudflare 发布 Agents SDK v0.20.0，并加入 MCP SDK v2 支持”。
依据: Cloudflare 官方 changelog。“本文未提供准确率、延迟、吞吐、成本等实测数值”。
依据: 本文仅给出可复现方案，未做跑分。
参考来源
- 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