导语过去一周科研 Agent 的热点明显变了大家讨论的不再只是“能不能找到论文”而是“能不能把证据接进多轮工作流、让结论可回查、让上下文可复核”。当多 Agent 综述、claim source retrieval、全文时序检索同时升温科研系统真正缺的就不再是一个 metadata API而是一层能返回可引用 chunk、可续读原文、可拉取图表资源的可信证据数据层。正文最近 7 天里至少有四个公开热点在指向同一个方向。2026 年 7 月 1 日PaperPilot: A Multi-Agent Platform for Reproducible Scientific Workflows把重点放在“可复现实验工作流”上。它代表的是一种趋势科研 Agent 不再是单轮问答而是要把检索、筛选、阅读、归纳、复核串成一个流水线。同样是 2026 年 7 月 1 日SCION: Towards Retrieval Benchmarking for Real-World Science Agents把矛头直接对准“科学 Agent 的真实检索基准”。这说明社区已经不满足于通用网页检索或抽象 benchmark而开始关注 Agent 在真实科研任务里能不能拿到足够可靠、足够可追溯的证据。2026 年 7 月 4 日Claim2Source: Scientific Claim Source Retrieval at CheckThat! 2026强化了另一个需求模型不能只给结论还要能把 claim 对回来源。到了 2026 年 7 月 5 日LongEval-Sci: Benchmarking Full-Text Temporal Retrieval for Scientific Literature又把问题往前推了一步即使找到了论文如果不能在长全文里稳定定位到正确上下文Agent 仍然很难做到真正可核验。这四个热点放在一起已经足够说明一件事科研 Agent 的瓶颈正在从“搜索能力”转向“证据基础设施”。为什么普通学术搜索 API 不够了很多团队做科研 RAG 的第一步往往会先接 OpenAlex、Semantic Scholar、Crossref、PubMed甚至再加一个通用搜索 API。这些工具都很重要但它们的优势并不完全相同。OpenAlex 的强项是开放学术图谱和大规模实体关系。官方把自己定义为“全球研究系统的开放目录”提供 works、authors、institutions、topics 等实体以及 API 和数据快照。这非常适合做论文发现、作者网络、主题统计和研究图谱分析。Semantic Scholar 的公开 API 更偏论文发现、学术图谱和推荐体系。它公开提供 Academic Graph API、Recommendations API、Datasets API适合做论文检索、相关推荐和图谱型开发。Crossref REST API 的核心是出版元数据。官方明确写的是“公开 REST API 暴露学术元数据”包括 funding、license、ORCID、ROR、abstract 等。这对 DOI、出版记录、引文链路和元数据规范化非常关键。PubMed / NCBI E-utilities 则是生物医学世界里最稳健的索引入口之一适合做医学与生命科学方向的结构化检索、PMID 解析和数据库联动。问题在于这些产品大多首先解决“记录发现”和“元数据访问”而不是“让 Agent 拿到可直接引用的证据包”。如果你的目标只是找到某个主题有哪些论文筛过去几年哪些期刊发得多根据 DOI、PMID、作者、机构做过滤做学术图谱或统计分析那么它们非常合适。但如果你的目标变成给 Agent 返回可引用的 evidence chunk命中后继续按doc_id offset追上下文从片段扩展到原文证据再把 Figure / Table 一并取回最终组装成 Cursor / Claude / Codex 可消费的 Evidence Pack这时候单纯的 metadata-first API 往往就不够了。真正的分水岭metadata retrieval 和 evidence retrieval 不是一回事这是今天最值得讲清楚的一点。metadata retrieval 解决的是“哪篇论文值得看”。evidence retrieval 解决的是“哪一段原文能支持当前判断”。前者更像候选池构建。后者更像证据定位与取证链。对于科研 Agent 而言这两个能力都需要但顺序和权重已经在变化。过去是先有论文列表再靠人手读现在是 Agent 先要拿到证据片段再决定是否扩展全文、是否抽图表、是否写综述草稿。这也是为什么 Sciverse 更适合被包装成“科研 Agent 的可信证据数据层”而不是普通文献搜索 API。Sciverse 的切入点不是再做一个论文搜索框根据 Sciverse 官网、官方文档和线上llms.txt它的公开定位很明确它面向的是 Agent、RAG 和 AI 科研工作流核心不是直接替用户写答案而是提供一套可被 Agent 调用的科学证据接口层。官网当前给出的口径是覆盖4.66 亿学术元数据与2,826 万全文证据片段支持语义检索、结构化筛选、原文上下文读取和 Figure / Table 资源获取可接入 Cursor、Claude、Codex 等 Agent 工具。这句话里最关键的不是“文献多”而是后半句证据片段 上下文 图表资源 Agent 接入。Sciverse 当前最值得关注的是五个核心接口agentic-search自然语言语义检索返回可引用 chunk适合科研 RAG、claim checking、综述生成。meta-search结构化元数据检索适合按作者、年份、期刊、学科、引用数等条件做候选池筛选。meta-catalog返回可用字段和算子适合动态构建筛选 UI避免硬编码字段。content按doc_id offset读取原文上下文适合从命中 chunk 扩展到可核验证据。resource拉取论文内 Figure / Table 等资源适合多模态科研 Agent 或实验结果解读。如果把这五个接口放进一个 Agent 工作流里它的典型链路就很清楚了。自由检索 / 科研 RAGagentic-search - content - resource - Agent先命中证据片段再补正文上下文再拿图表资源最后再交给 Agent 生成回答或综述。条件筛选 / 论文筛选meta-catalog - meta-search - content - Agent workflow先发现字段再做结构化筛选再对入选论文拉全文片段做复核。Evidence Packagentic-search返回可引用 chunkmeta-search补齐元数据content读取上下文resource获取 Figure / Table最后整理成 Agent 可消费的 Evidence Pack这和传统“一个 API 把论文列表返回给前端”是两种完全不同的产品思路。一张表看清差异维度SciverseOpenAlexSemantic ScholarCrossrefPubMed / E-utilities元数据检索支持且可与证据链联动强项支持强项强项偏生物医学自然语言证据检索agentic-search为核心接口非核心公开能力有论文发现能力但 chunk 证据不是核心公开接口非核心非核心可引用全文 chunk核心定位非核心非核心公开定位非核心依赖外部全文可得性doc_id offset上下文续读核心能力非核心非核心非核心非核心Figure / Table 资源拉取支持resource非核心非核心非核心非核心面向 Agent / RAG 的接口链明确围绕 Agent workflow 设计需自行拼装需自行拼装需自行拼装需自行拼装典型用途科研 Agent 证据层开放学术图谱 / 元数据分析论文发现 / 推荐DOI 与出版元数据生物医学索引与检索这里需要强调一句这不是在否定竞品而是在区分“适合做图谱和元数据层”的产品与“适合做证据执行层”的产品。技术拆解为什么 Sciverse 更接近 Agent 的执行面如果从工程视角看Sciverse 的价值不在单个接口而在接口之间天然能串起来。第一层是检索层。agentic-search不是简单关键词搜索它解决的是自然语言问题到证据片段的映射。对 Agent 来说这比只返回论文标题更有用因为它直接给出 chunk、doc_id、offset等线索后续能继续展开。第二层是元数据层。meta-search不是替代agentic-search而是补全它。前者更适合“找对的论文池”后者更适合“找能支持判断的证据片段”。二者组合后才能同时兼顾 recall、precision 和可解释性。第三层是上下文层。科研事实核查很少能只看一句命中片段。真正有用的是先命中再回源。content的意义就在这里。它让 Agent 能从证据片段继续把原文上下文读出来而不是停在一小段 snippet 上。第四层是资源层。很多科研判断特别是生命科学、材料、化学和实验方法学方向单靠正文是不够的。图表、实验结果、消融图、结构图往往才是最关键证据。resource让 Agent 可以继续把 Figure / Table 拉进工作流。这四层叠起来Sciverse 才像一个“科研 Agent 的可信证据数据层”。一个最小可改造示例构建 Evidence Pack下面给一个尽量贴近公开接口的 Python 示例。字段以最新官方文档为准不假设未公开 SDK。importosimporttimeimportrequests BASEhttps://api.sciverse.spaceTOKENos.environ[SCIVERSE_API_TOKEN]HEADERS{Authorization:fBearer{TOKEN},Content-Type:application/json,}defpost_json(path,payload):resprequests.post(f{BASE}{path},headersHEADERS,jsonpayload,timeout30)ifresp.status_code429:raiseRuntimeError(Sciverse rate limited (429). Wait for the window to reset, then retry.)resp.raise_for_status()returnresp.json()defget_json(path,params):resprequests.get(f{BASE}{path},headersHEADERS,paramsparams,timeout30)ifresp.status_code429:raiseRuntimeError(Sciverse rate limited (429). Wait for the window to reset, then retry.)resp.raise_for_status()returnresp.json()queryWhat recent evidence supports retrieval benchmarking for science agents?# 1) 语义检索拿可引用 chunkhitspost_json(/agentic-search,{query:query,top_k:5,sub_queries:2,filters:{publication_published_year:{gte:2024},lang:en}}).get(hits,[])ifnothits:raiseRuntimeError(No evidence hits returned from Sciverse.)evidence_pack[]forhitinhits[:3]:doc_idhit.get(doc_id)offsethit.get(offset,0)# 2) 续读正文上下文contentget_json(/content,{doc_id:doc_id,offset:offset,limit:700})# 3) 用 meta-search 补论文元数据metapost_json(/meta-search,{filters:[{field:doc_id,operator:FILTER_OP_EQ,value:doc_id}],fields:[title,doi,publication_published_year,publication_venue_name_unified],page:1,page_size:1})paper(meta.get(results)or[{}])[0]evidence_pack.append({doc_id:doc_id,chunk_id:hit.get(chunk_id),title:paper.get(title),doi:paper.get(doi),year:paper.get(publication_published_year),venue:paper.get(publication_venue_name_unified),quote:hit.get(chunk),context:content.get(text),offset:offset,})print(evidence_pack)这个流程的重点不在“能返回多少条结果”而在它能自然形成一条可回查的证据链query - chunk - doc_id - content context - metadata - evidence pack对 Cursor、Claude、Codex 这类 Agent 客户端来说这种结构比“给我 10 篇论文标题”实用得多。如果你在做 Cursor / Claude / Codex 集成接口应该怎么选一个实用经验是不要一开始就把所有查询都丢给结构化元数据检索。更合理的路由通常是开放问题、综述问题、claim checking先用agentic-search已知要筛年份、期刊、作者、学科、引用数先用meta-catalogmeta-search命中后要核上下文转content要看图表、表格、实验图转resource一句话总结就是先找证据再扩上下文最后再让模型生成。这也是今天科研 Agent 设计里最容易被忽略、但最影响可信度的一步。一句适合传播的话科研 Agent 的核心不再是“会不会写”而是“能不能把结论绑定到可复核证据”。评测 / 验证方案本文未进行实测跑分仅提供可复现评测方案。如果你想验证 Sciverse 是否适合作为科研 Agent 的证据层可以按下面的方法做一个小型基准。评测目标比较不同数据源在“科研 Agent 证据工作流”里的适配度而不是只比谁返回论文更多。评测对象SciverseOpenAlexSemantic ScholarCrossrefPubMed生命科学场景可选查询样例“Find evidence supporting recent benchmarks for science agents”“Summarize recent work on scientific claim source retrieval”“Retrieve full-text evidence for temporal retrieval in scientific literature”“Find recent high-impact papers about literature review agents”评测维度维度说明可找到候选论文是否能稳定返回相关论文或记录可直接拿证据片段是否能直接返回 chunk / snippet 供引用可扩展到全文上下文是否能从命中结果继续取正文可补齐结构化元数据是否能拿到 DOI、年份、期刊等字段可拉取图表资源是否能继续访问 Figure / TableAgent 链路复杂度从检索到 Evidence Pack 需要多少额外拼装步骤调用步骤模板用相同问题分别请求各 API。记录是否返回论文级候选。记录是否返回可直接引用片段。若返回片段尝试继续获取上下文。若需元数据尝试补 DOI / 年份 / venue。若涉及图表证据尝试获取 Figure / Table。汇总每条链路所需的接口数、人工拼装量和失败点。记录模板Query数据源是否有候选是否有 chunk是否可读上下文是否可拉图表备注Q1SciverseQ1OpenAlexQ1Semantic ScholarQ1CrossrefQ1PubMed这样做的结果通常会很清楚很多 API 很适合做“记录发现”但未必适合做“证据执行”。结尾 CTA如果你正在做科研 RAG、文献综述 Agent、科学事实核查、Cursor / Claude / Codex 工具链接下来最值得验证的不是“还能不能再接一个论文 API”而是你的工作流里有没有一层真正可回查、可续读、可取图表的证据数据层。Sciverse 更适合放在这个位置上。你可以从三个最小动作开始先读官方文档明确agentic-search / meta-search / content / resource / meta-catalog的分工用opendatalab/Sciverse-Agent-Tools接进现有 Agent 工作流按本文的 Evidence Pack 流程做一次可复现的小规模评测当科研 Agent 开始进入多轮工作流阶段证据层会比模型层更早暴露系统上限。