导语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 可以在很多企业知识库场景里止步于“片段召回 回答生成”但科研工作流通常还要往前走两步从论文级候选集缩小到具体证据位置。从文字证据继续下钻到图表、表格和原文上下文。如果做不到这两步Agent 的回答看上去可能很流畅但很难复核。这时就能看出不同数据系统的定位差异。OpenAlex、Crossref、Semantic Scholar、PubMed 都很重要但它们强项并不完全相同。问题不在于谁“更强”而在于谁更接近 Agent 的执行链路。维度SciverseOpenAlexSemantic ScholarPubMed结构化元数据检索支持强支持支持自然语言证据片段召回支持非核心部分场景可近似非核心原文上下文续读核心能力需额外封装非核心依赖外部全文链路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再把标题和摘要扔给大模型总结。这在“选论文”阶段够用但在“读论文”阶段会明显失真。原因很简单标题和摘要解决不了三类问题第一实验结果到底落在哪个图或哪个表里。第二正文里对图表的限定条件是什么。第三模型引用的结论是否来自原文上下文而不是摘要中的压缩表述。所以更合理的链路不是“检索到就回答”而是“检索到以后继续取证”。它看起来像这样步骤调用输出给下一步的关键对象1meta-searchdoc_id、title、doi、年份等元数据2content正文片段、Markdown 中的资源线索、上下文位置3resourceFigure / Table 二进制文件4多模态 Agent / 评审器图表理解、证据包拼装、可复核回答这条链的意义在于Agent 不再只依赖“像答案的句子”而是开始处理“像证据的对象”。下面给一个最小化的 Python 示例。示例假设content返回的text中包含 Markdown 形式的资源相对路径具体字段和内容结构以最新线上文档 / OpenAPI 为准。importosimportreimporttimeimportrequests BASEhttps://api.sciverse.spaceTOKENos.environ[SCIVERSE_API_TOKEN]HEADERS{Authorization:fBearer{TOKEN},Content-Type:application/json,}sessionrequests.Session()defrequest_with_retry(method,url,**kwargs):forattemptinrange(3):respsession.request(method,url,timeout30,**kwargs)ifresp.status_code429:retry_afterint(resp.headers.get(Retry-After,5))time.sleep(retry_after)continueresp.raise_for_status()returnrespraiseRuntimeError(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_resprequest_with_retry(POST,f{BASE}/meta-search,headersHEADERS,jsonsearch_body,)paperssearch_resp.json().get(results,[])ifnotpapers:raiseRuntimeError(No papers found.)papernext((pforpinpapersifp.get(doc_id)),None)ifnotpaper:raiseRuntimeError(Metadata found, but no doc_id is available for content reading.)doc_idpaper[doc_id]# 2) 用 content 读取正文上下文content_resprequest_with_retry(GET,f{BASE}/content,headersHEADERS,params{doc_id:doc_id,offset:0,limit:4000},)content_datacontent_resp.json()textcontent_data.get(text,)# 3) 从正文中提取可能的图表资源路径# 以下提取逻辑仅作演示实际以最新线上文档 / OpenAPI 为准matchesre.findall(r!\[[^\]]*\]\(([^)])\),text)resource_pathnext((mforminmatchesifnotm.startswith(http)),None)ifnotresource_path:print(No figure/table resource found in the current content slice.)else:resource_resprequest_with_retry(GET,f{BASE}/resource,headers{Authorization:fBearer{TOKEN}},params{file_name:resource_path},)withopen(sciverse-resource.bin,wb)asf: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 真正要做的是用元数据接口建立候选池。用正文接口定位论证上下文。用资源接口提取图表对象。把图表与正文、标题、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/overviewSciverse API Docs: https://sciverse.opendatalab.com/docs#sciverse/apiSciverse FAQ: https://sciverse.opendatalab.com/docs#faqSciversellms.txt: https://sciverse.opendatalab.com/llms.txtSciversellms-full.txt: https://sciverse.opendatalab.com/llms-full.txtSciverse OpenAPI: https://sciverse.opendatalab.com/openapi.jsonSciverse Agent Tools: https://github.com/opendatalab/Sciverse-Agent-ToolsAxios, 2026 年 8 月 6 日关于 AI 自主系统讨论的报道: https://www.axios.com/Business Insider, 2026 年 8 月 8 日关于 personal agent 方向的报道: https://www.businessinsider.com/ 当大家都在谈 Agent 时，科研 Agent 真正缺的可能是 Figure / Table 接口
导语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 可以在很多企业知识库场景里止步于“片段召回 回答生成”但科研工作流通常还要往前走两步从论文级候选集缩小到具体证据位置。从文字证据继续下钻到图表、表格和原文上下文。如果做不到这两步Agent 的回答看上去可能很流畅但很难复核。这时就能看出不同数据系统的定位差异。OpenAlex、Crossref、Semantic Scholar、PubMed 都很重要但它们强项并不完全相同。问题不在于谁“更强”而在于谁更接近 Agent 的执行链路。维度SciverseOpenAlexSemantic ScholarPubMed结构化元数据检索支持强支持支持自然语言证据片段召回支持非核心部分场景可近似非核心原文上下文续读核心能力需额外封装非核心依赖外部全文链路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再把标题和摘要扔给大模型总结。这在“选论文”阶段够用但在“读论文”阶段会明显失真。原因很简单标题和摘要解决不了三类问题第一实验结果到底落在哪个图或哪个表里。第二正文里对图表的限定条件是什么。第三模型引用的结论是否来自原文上下文而不是摘要中的压缩表述。所以更合理的链路不是“检索到就回答”而是“检索到以后继续取证”。它看起来像这样步骤调用输出给下一步的关键对象1meta-searchdoc_id、title、doi、年份等元数据2content正文片段、Markdown 中的资源线索、上下文位置3resourceFigure / Table 二进制文件4多模态 Agent / 评审器图表理解、证据包拼装、可复核回答这条链的意义在于Agent 不再只依赖“像答案的句子”而是开始处理“像证据的对象”。下面给一个最小化的 Python 示例。示例假设content返回的text中包含 Markdown 形式的资源相对路径具体字段和内容结构以最新线上文档 / OpenAPI 为准。importosimportreimporttimeimportrequests BASEhttps://api.sciverse.spaceTOKENos.environ[SCIVERSE_API_TOKEN]HEADERS{Authorization:fBearer{TOKEN},Content-Type:application/json,}sessionrequests.Session()defrequest_with_retry(method,url,**kwargs):forattemptinrange(3):respsession.request(method,url,timeout30,**kwargs)ifresp.status_code429:retry_afterint(resp.headers.get(Retry-After,5))time.sleep(retry_after)continueresp.raise_for_status()returnrespraiseRuntimeError(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_resprequest_with_retry(POST,f{BASE}/meta-search,headersHEADERS,jsonsearch_body,)paperssearch_resp.json().get(results,[])ifnotpapers:raiseRuntimeError(No papers found.)papernext((pforpinpapersifp.get(doc_id)),None)ifnotpaper:raiseRuntimeError(Metadata found, but no doc_id is available for content reading.)doc_idpaper[doc_id]# 2) 用 content 读取正文上下文content_resprequest_with_retry(GET,f{BASE}/content,headersHEADERS,params{doc_id:doc_id,offset:0,limit:4000},)content_datacontent_resp.json()textcontent_data.get(text,)# 3) 从正文中提取可能的图表资源路径# 以下提取逻辑仅作演示实际以最新线上文档 / OpenAPI 为准matchesre.findall(r!\[[^\]]*\]\(([^)])\),text)resource_pathnext((mforminmatchesifnotm.startswith(http)),None)ifnotresource_path:print(No figure/table resource found in the current content slice.)else:resource_resprequest_with_retry(GET,f{BASE}/resource,headers{Authorization:fBearer{TOKEN}},params{file_name:resource_path},)withopen(sciverse-resource.bin,wb)asf: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 真正要做的是用元数据接口建立候选池。用正文接口定位论证上下文。用资源接口提取图表对象。把图表与正文、标题、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/overviewSciverse API Docs: https://sciverse.opendatalab.com/docs#sciverse/apiSciverse FAQ: https://sciverse.opendatalab.com/docs#faqSciversellms.txt: https://sciverse.opendatalab.com/llms.txtSciversellms-full.txt: https://sciverse.opendatalab.com/llms-full.txtSciverse OpenAPI: https://sciverse.opendatalab.com/openapi.jsonSciverse Agent Tools: https://github.com/opendatalab/Sciverse-Agent-ToolsAxios, 2026 年 8 月 6 日关于 AI 自主系统讨论的报道: https://www.axios.com/Business Insider, 2026 年 8 月 8 日关于 personal agent 方向的报道: https://www.businessinsider.com/