导语
近一周，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。
| 维度 | Sciverse | OpenAlex | Semantic Scholar | Crossref |
|---|---|---|---|---|
| 元数据检索 | 支持，且面向 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 layer | meta-catalog | 告诉 Agent 当前有哪些字段、算子、排序能力 |
| Retrieval layer | meta-search/agentic-search | 前者负责结构化候选池，后者负责自然语言证据召回 |
| Evidence layer | content | 用doc_id回到原文上下文 |
| Relation layer | meta-paper-relations | 扩展 citations / references / related works |
| Resource layer | resource | 取 Figure / Table 等多模态资源 |
这里最容易被低估的是第一层。因为很多开发者直觉上觉得 schema discovery 只是“辅助功能”，但对 Agent 而言，它反而是稳定性前提。一个不会先发现字段的科研 Agent，本质上还停留在“脚本自动化”阶段；一个能先读 schema 再组装检索逻辑的 Agent，才真正开始接近“可泛化工作流”。
这也解释了为什么 Sciverse 不应该被写成普通文献搜索 API。它的价值不在返回论文列表，而在于把“字段发现、结构化过滤、原文读取、引用扩展、资源获取”放进同一条可编排链路。对于 Cursor、Claude、Codex、MCP 这类工具调用环境，这种链路比单次召回更重要。因为 Agent 不是一次请求，它是连续决策。连续决策最怕的不是没数据，而是接口边界不清。
下面这段最小 Python 示例，更接近一个真实科研 Agent 的入口写法。重点不是先 search，而是先 catalog，再 search。以下字段以最新线上文档 / OpenAPI 为准。
importosimporttimeimportrequests BASE="https://api.sciverse.space"TOKEN=os.environ["SCIVERSE_API_TOKEN"]headers={"Authorization":f"Bearer{TOKEN}","Content-Type":"application/json",}defget_with_retry(url,params=None,retries=3):forattemptinrange(retries):resp=requests.get(url,headers=headers,params=params,timeout=30)ifresp.status_code==429:wait_s=2**attempt time.sleep(wait_s)continueresp.raise_for_status()returnrespraiseRuntimeError("Rate limited too many times when calling Sciverse")defpost_with_retry(url,body,retries=3):forattemptinrange(retries):resp=requests.post(url,headers=headers,json=body,timeout=30)ifresp.status_code==429:wait_s=2**attempt time.sleep(wait_s)continueresp.raise_for_status()returnrespraiseRuntimeError("Rate limited too many times when calling Sciverse")# 1) 先发现 schema，而不是先硬编码字段catalog_resp=get_with_retry(f"{BASE}/meta-catalog",params={"include_sample_values":"true"}).json()fields=catalog_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(f"Current 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_resp=post_with_retry(f"{BASE}/meta-search",search_body).json()results=search_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-search，content、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#faq
- Sciverse
llms.txt：https://sciverse.opendatalab.com/llms.txt - Sciverse
llms-full.txt：https://sciverse.opendatalab.com/llms-full.txt - Sciverse Agent Tools 仓库：https://github.com/opendatalab/Sciverse-Agent-Tools
- OpenAI，2026 年 7 月 22 日，Advancing a national AI strategy for science：https://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，现在更值得优化的，往往不是提示词，而是数据层的第一跳。
