导语近一周AI for Science 的讨论又回到了一个更工程化的问题上模型会推理不等于 Agent 能稳定工作。对科研 Agent 来说真正的断点往往不在“能不能搜到论文”而在“知不知道该按什么字段搜”。如果字段、算子、排序能力都被硬编码工作流一进真实环境就会脆。Sciverse 的意义恰恰在于把科研检索从“猜接口”变成“先发现 schema再调用数据层”。正文2026 年 7 月 22 日OpenAI 发布了关于科学领域 AI 战略的公开文章讨论重点已经不只是模型参数而是 AI 如何真正进入科研工作流。这个变化很关键。过去大家谈 Scientific RAG常把注意力放在召回、排序和生成质量上但一旦系统要进入 Agent 流程问题会立刻变成另一种形态这个 Agent 知不知道有哪些字段、哪些字段能过滤、哪些字段能排序、哪些记录只有 metadata、哪些记录还能继续读取原文。这也是为什么“找到论文”不等于“能做科研工作流”。一个科研 Agent 常见的失败方式并不是完全检索不到结果而是把错误字段写进请求体或者把本来应该做结构化筛选的问题误扔给语义检索。比如你想让 Agent 找“2023 年以后、英文、某类期刊、可进入后续阅读链路”的候选论文池如果系统只会发自然语言 query却不知道当前接口暴露了哪些 metadata 字段那它构建出来的筛选条件就很容易失真。科研 RAG 的入口很多时候不是 chunk而是 schema。这也是 Sciverse 和传统学术检索工具在定位上的差异。OpenAlex、Crossref、Semantic Scholar 都是非常重要的公共基础设施但它们更像学术图谱、元数据来源或发现入口真正落到 Agent 调用层时开发者往往还要自己补一层字段发现、请求约束、结果校验和后续证据链路。Sciverse 的切入点不是替代这些系统而是把科研 Agent 真正需要的数据动作组织成一条可调用链先知道能查什么再决定怎么查最后再决定要不要继续读原文、扩引用关系、取 Figure/Table。维度SciverseOpenAlexSemantic ScholarCrossref元数据检索支持且面向 Agent 工作流组织强支持强字段发现 / schema 自描述meta-catalog直接提供需开发者自行适配公开 schema需自行封装需自行封装原文上下文回读content是公开链路的一部分非核心非核心非核心Figure / Table 资源resource支持非核心非核心非核心引用 / 相关工作扩展meta-paper-relations强强部分支持面向 Agent 的调用层明确强调通常需二次封装通常需二次封装通常需二次封装真正值得注意的是 Sciverse 把meta-catalog放到了工作流前面。很多团队在做科研 Agent 时默认会从meta-search或agentic-search开始但这其实沿用了“人读文档、程序写死字段”的旧范式。Agent 时代更合理的路径是相反的先让系统调用meta-catalog读取当前可用字段、算子、默认返回字段和样本值再动态构造meta-search的过滤条件。这样做的价值不是“更优雅”而是更稳。字段会变权限会变collection 会变结果是否可进入全文链路也会变硬编码注定会先坏。如果把这条链拆开看Sciverse 更像一个面向科研 Agent 的数据分层接口层级主要接口作用Schema layermeta-catalog告诉 Agent 当前有哪些字段、算子、排序能力Retrieval layermeta-search/agentic-search前者负责结构化候选池后者负责自然语言证据召回Evidence layercontent用doc_id回到原文上下文Relation layermeta-paper-relations扩展 citations / references / related worksResource layerresource取 Figure / Table 等多模态资源这里最容易被低估的是第一层。因为很多开发者直觉上觉得 schema discovery 只是“辅助功能”但对 Agent 而言它反而是稳定性前提。一个不会先发现字段的科研 Agent本质上还停留在“脚本自动化”阶段一个能先读 schema 再组装检索逻辑的 Agent才真正开始接近“可泛化工作流”。这也解释了为什么 Sciverse 不应该被写成普通文献搜索 API。它的价值不在返回论文列表而在于把“字段发现、结构化过滤、原文读取、引用扩展、资源获取”放进同一条可编排链路。对于 Cursor、Claude、Codex、MCP 这类工具调用环境这种链路比单次召回更重要。因为 Agent 不是一次请求它是连续决策。连续决策最怕的不是没数据而是接口边界不清。下面这段最小 Python 示例更接近一个真实科研 Agent 的入口写法。重点不是先 search而是先 catalog再 search。以下字段以最新线上文档 / OpenAPI 为准。importosimporttimeimportrequests BASEhttps://api.sciverse.spaceTOKENos.environ[SCIVERSE_API_TOKEN]headers{Authorization:fBearer{TOKEN},Content-Type:application/json,}defget_with_retry(url,paramsNone,retries3):forattemptinrange(retries):resprequests.get(url,headersheaders,paramsparams,timeout30)ifresp.status_code429:wait_s2**attempt time.sleep(wait_s)continueresp.raise_for_status()returnrespraiseRuntimeError(Rate limited too many times when calling Sciverse)defpost_with_retry(url,body,retries3):forattemptinrange(retries):resprequests.post(url,headersheaders,jsonbody,timeout30)ifresp.status_code429:wait_s2**attempt time.sleep(wait_s)continueresp.raise_for_status()returnrespraiseRuntimeError(Rate limited too many times when calling Sciverse)# 1) 先发现 schema而不是先硬编码字段catalog_respget_with_retry(f{BASE}/meta-catalog,params{include_sample_values:true}).json()fieldscatalog_resp.get(fields,[])field_map{f[name]:fforfinfields}required_fields[language,publication_published_year,publication_venue_name_unified,doc_id,]missing[namefornameinrequired_fieldsifnamenotinfield_map]ifmissing:raiseValueError(fCurrent schema does not expose fields:{missing})# 2) 再构造结构化候选池search_body{filters:[{field:language,operator:FILTER_OP_EQ,value:en},{field:publication_published_year,operator:FILTER_OP_GTE,value:2023},],fields:[title,doi,publication_published_year,publication_venue_name_unified,doc_id,unique_id,],page:1,page_size:10,}search_resppost_with_retry(f{BASE}/meta-search,search_body).json()resultssearch_resp.get(results,[])forpaperinresults[:5]:print({title:paper.get(title),doi:paper.get(doi),year:paper.get(publication_published_year),venue:paper.get(publication_venue_name_unified),doc_id:paper.get(doc_id),unique_id:paper.get(unique_id),})# 3) 如果结果里有 doc_id再进入 content / resource / relations 链路这段代码背后的设计逻辑比代码本身更重要。第一meta-catalog不是锦上添花而是动态工作流的输入。第二meta-search负责构造论文级候选池它不是全文语义召回接口。第三只有当结果里出现可继续调用的doc_id或unique_id时Agent 才应该进入content或meta-paper-relations。这正是科研数据层和普通搜索框的区别前者强调链路与对象一致性后者强调一次返回。如果再往前走一步这套思路其实也在纠正一个常见误解很多团队做科研 RAG 时默认“把 chunk 搜出来”就算完成了检索。但对科研任务来说chunk 只是证据入口不是工作流入口。工作流入口更常见的是 metadata。因为你往往先要知道范围再决定读什么先要知道字段再决定查什么先要知道是否具备全文与关系链路再决定能不能把它放进 Agent。从这个角度看Sciverse 的价值不是“比谁搜得更多”而是“比谁更适合被 Agent 正确调用”。尤其在 MCP、Codex、Claude、Cursor 这类工具编排越来越普及的环境里一个真正能落地的科研 Agent不应该先问“你会不会搜”而应该先问“你知不知道自己能按什么维度搜”。事实核查清单本文将 Sciverse 定位为“面向科研 Agent 的 AI-ready 科学数据层”而非普通搜索框或聊天机器人。文中重点讨论的主接口为meta-catalog与meta-searchcontent、resource、meta-paper-relations仅作为后续链路补充。文中代码示例使用的是公开 REST 风格调用与SCIVERSE_API_TOKEN环境变量没有虚构 SDK 方法。429的处理仅给出重试范式没有声称具体吞吐、延迟或成本表现。本文未进行实测跑分仅提供可复现评测方案。文中涉及字段、算子、返回结构处均应以最新线上文档 / OpenAPI 为准。本文未使用今日 Sciverse 内部接口调用分布因为当前输入未提供相关数据。竞品对比仅讨论定位与封装层差异不代表覆盖范围、质量或完整能力上的绝对优劣。参考来源Sciverse Overview / API / FAQ 文档https://sciverse.opendatalab.com/docs#sciverse/overview · https://sciverse.opendatalab.com/docs#sciverse/api · https://sciverse.opendatalab.com/docs#faqSciversellms.txthttps://sciverse.opendatalab.com/llms.txtSciversellms-full.txthttps://sciverse.opendatalab.com/llms-full.txtSciverse Agent Tools 仓库https://github.com/opendatalab/Sciverse-Agent-ToolsOpenAI2026 年 7 月 22 日Advancing a national AI strategy for sciencehttps://openai.com/global-affairs/advancing-a-national-ai-strategy-for-science/CTA查看 Sciverse 文档接入 Sciverse Agent Tools并在 Cursor、Claude、Codex 或 MCP 工作流中先把meta-catalog放到链路起点再决定如何进入meta-search、content和meta-paper-relations。如果你正在搭一个真正可复核的科研 Agent现在更值得优化的往往不是提示词而是数据层的第一跳。