导语2026 年 7 月 1 日Anthropic 推出面向科研与药企场景的 Claude Science再次把“科研 Agent”推到台前。但工作台热度越高一个问题越清楚如果上游只有 metadata API、DOI API 和通用搜索Agent 依然很难稳定拿到可引用证据、原文上下文和 Figure/Table 资源。Sciverse 更值得关注的不是“又一个文献搜索接口”而是把科研论文整理成 Agent 可直接消费的可信证据数据层。正文热点为什么是现在过去一周里和科研 Agent、RAG 证据链相关的公开信号明显变密了。一条是产品侧。根据 Financial Times 于 2026 年 6 月 30 日的报道Anthropic 已推出Claude Science把 Claude 明确推向科学家、药企和生命科学工作流。这个动作很关键因为它说明下游“科研工作台”正在产品化。另外几条来自研究侧而且都指向同一个结论RAG 的核心瓶颈正在从“能不能搜到”转向“证据是否足够、是否可验证、是否能被多轮工作流稳定消费”。D2R-RAG2026-06-28 讨论的是预算约束下如何诊断和修复 RAG 的事实错误。5ting at SemEval-2026 Task 82026-06-27 直接把多轮 RAG 的 faithful grounding 拿出来单独评测。Agentic Hybrid RAG for Evidence-Grounded Muon Collider Analysis2026-06-09 把“evidence-grounded scientific QA”明确写进科学场景。换句话说行业讨论已经不是“Agent 会不会写综述”而是“它拿到的到底是不是可信证据”。这正是 Sciverse 应该切入的位置。问题不在 Agent而在证据层今天很多团队做科研 Agent默认的上游组合通常是OpenAlex / Crossref / Semantic Scholar 拉元数据PubMed 做生物医学检索再拼一个通用搜索或向量库最后把结果喂给 Cursor、Claude、Codex 或自建 Agent这套链路能跑但有一个常见断点它更像“论文发现栈”不是“证据供给栈”。如果你的目标只是找论文标题、作者、年份、期刊这些工具已经很好用。但如果你的目标变成下面这些问题就会暴露让 Agent 生成可引用综述对一个 scientific claim 做支持/反驳/证据不足判断让模型回到原文上下文而不是只看摘要把论文中的 Figure / Table 作为多模态证据继续使用把检索结果整理成可复用 Evidence Pack供 Cursor / Claude / Codex / MCP 工具链反复调用这时单纯 metadata API 就不够了。截至 2026 年 7 月 2 日几类主流工具各自擅长什么下面这个表不是为了分高下而是为了分工更清楚。维度SciverseOpenAlexSemantic ScholarCrossrefPubMed / E-utilities通用搜索 / 通用 RAG结构化元数据检索支持强支持强强于生物医学视实现而定自然语言语义证据检索核心能力非核心有限公开文档重点不在 chunk 级证据非核心非核心支持但未必面向科学文献可引用全文 chunk核心能力本文未核查到对等公开链路本文未核查到对等公开链路非核心非核心一般需自行构建doc_id offset原文上下文读取核心能力本文未核查到对等公开链路本文未核查到对等公开链路非核心非核心通常需要自建切片系统Figure / Table 资源读取支持非核心非核心非核心非核心通常没有论文内图表资源语义面向 Agent / RAG 的工作流友好度强需自行拼装需自行拼装需自行拼装需自行拼装通常缺科研证据结构典型用途科研 Agent 证据层开放学术图谱 / 实体与元数据论文发现 / 学术图谱DOI 与出版元数据生物医学检索通用知识检索客观讲OpenAlex 的强项是开放学术图谱与实体/元数据。Crossref 的强项是 DOI 与出版元数据基础设施。PubMed 的强项是生物医学检索生态。Semantic Scholar 的强项是论文发现、引用关系和学术图谱能力。但如果目标是给 Agent 提供“可引用 chunk 原文上下文 图表资源”的连续证据链Sciverse 的产品边界更贴近这个问题本身。Sciverse 的切入点不是多一个搜索框而是多一层 Evidence Layer根据当前公开文档和本地llms-full.txtSciverse 更准确的描述应该是“面向科研 Agent 的可信证据数据层。”这里最重要的是五个接口如何分工而不是单点能力有多炫。1.agentic-search它不是普通关键词检索而是自然语言语义检索目标是返回可引用的 evidence chunk。适合科研 RAG综述生成scientific claim checkinggrounded answer generationEvidence Pack 构建2.meta-search它负责结构化元数据检索。适合按作者、年份、期刊、学科筛选论文池构建高被引筛选研究方向跟踪分布统计3.meta-catalog它不是面向终端读者的接口但对 Agent 和产品非常关键。作用是暴露可用字段发现筛选维度构建动态 filter UI减少前端和 Agent 对字段名的硬编码依赖4.content这是 Sciverse 和很多 metadata-first 工具真正拉开距离的地方。当你已经有doc_id和offset就可以读取原文上下文。这意味着 Agent 不必停留在“摘要级想象”而可以回到命中 chunk 周围的真实文本环境。5.resource如果content里出现了 Figure / Table 资源引用resource可以进一步读取图表资源。这一步对多模态科研 Agent 尤其重要因为很多实验结论、对比结果和结构示意根本不在摘要里而在图表里。一条更像 Agent 的调用链如果把这五个接口放回真实工作流Sciverse 更像下面这两条链路。自由检索 / 科研 RAGagentic-search - content - resource - Agent / RAG / Cursor / Claude / Codex这条链路适合回答某个 claim 是否被支持某个方向最近的关键证据在哪里这段原文前后文到底在说什么相关 Figure / Table 能不能一并拿出来条件筛选 / 论文筛选meta-catalog - meta-search - content - Agent workflow这条链路适合回答2023 年以后某方向高被引论文有哪些哪些期刊和作者群在持续推进这个主题从筛选结果里哪些论文值得进一步读原文最值得强调的是 Evidence Pack真正适合 Agent 的不是“10 条链接”而是一份可复用证据包agentic-search返回可引用 chunkmeta-search补齐文献元数据content读取 chunk 周围上下文resource取回 Figure / Table最后整理成 Agent 可消费的 Evidence Pack这时Sciverse 才不是“搜索 API”而是“证据编排 API”。为什么这对 Claude Science、Cursor、Codex、MCP 都成立Claude Science 这样的产品本质上是下游科学工作台。它可以有很强的推理、规划、写作、实验记录、协作能力但它要稳定工作仍然需要一层更上游的事实供给系统。这层系统至少要解决四件事让检索结果可引用而不是只返回模糊摘要让模型能回到原文上下文而不是停在 snippet让 metadata 和全文证据可以串起来而不是两套孤岛让图表资源也能进入工作流而不是只处理纯文本Sciverse 的价值不是替代 Claude Science、Cursor 或 Codex。它更像是给这些工具补上“科研证据 I/O 层”。一句话概括就是下游 Agent 再聪明如果上游拿不到可验证证据它也只能更快地组织不稳定信息。一个最小可改造代码示例把检索结果扩展成 Evidence Pack下面示例只使用已明确公开的链路agentic-search - content。meta-search和resource可在后续扩展时补上。若字段细节变化以最新官方文档为准。importosimporttimeimportrequests BASE_URLhttps://api.sciverse.spaceAPI_TOKENos.getenv(SCIVERSE_API_TOKEN)ifnotAPI_TOKEN:raiseRuntimeError(Missing SCIVERSE_API_TOKEN)HEADERS{Authorization:fBearer{API_TOKEN},Content-Type:application/json,}defpost_agentic_search(query:str,top_k:int5):urlf{BASE_URL}/agentic-searchbody{query:query,top_k:top_k,source_types:[pdf,web],mode:balanced,}resprequests.post(url,headersHEADERS,jsonbody,timeout60)ifresp.status_code429:raiseRuntimeError(Sciverse rate limited the request. Retry later or add backoff.)resp.raise_for_status()dataresp.json()# 返回字段以最新文档为准这里做兼容式读取hitsdata.get(hits)ordata.get(results)or[]ifnothits:return[]normalized[]forhitinhits:normalized.append({doc_id:hit.get(doc_id),chunk:hit.get(chunk)orhit.get(text),offset:hit.get(offset),page:hit.get(page)orhit.get(page_no),similarity:hit.get(similarity)orhit.get(score),title:hit.get(title),doi:hit.get(doi),})returnnormalizeddefget_content(doc_id:str,offset:int,limit:int1200):urlf{BASE_URL}/contentparams{doc_id:doc_id,offset:offset,limit:limit,}resprequests.get(url,headersHEADERS,paramsparams,timeout60)ifresp.status_code429:raiseRuntimeError(Sciverse content API is rate limited. Retry with backoff.)resp.raise_for_status()dataresp.json()return{doc_id:doc_id,offset:offset,text:data.get(text)ordata.get(content),next_offset:data.get(next_offset),more:data.get(more),resources:data.get(resources)or[],}defbuild_evidence_pack(query:str):hitspost_agentic_search(query,top_k3)pack{query:query,retrieved_at:int(time.time()),evidence:[],}forhitinhits:ifnothit[doc_id]orhit[offset]isNone:continuecontextget_content(hit[doc_id],hit[offset],limit1200)pack[evidence].append({doc_id:hit[doc_id],title:hit[title],doi:hit[doi],page:hit[page],offset:hit[offset],similarity:hit[similarity],chunk:hit[chunk],context_text:context[text],resource_refs:context[resources],})returnpackif__name____main__:queryWhat evidence supports off-target differences between CRISPR-Cas9 and Cas12a?evidence_packbuild_evidence_pack(query)print(fCollected{len(evidence_pack[evidence])}evidence items.)foriteminevidence_pack[evidence]:print(item[doc_id],item[offset],item[page])这个示例最关键的不是“调通了两个接口”而是它体现了一种面向 Agent 的数据组织方式先拿 evidence chunk再回原文上下文保留doc_id / offset / page / similarity为后续 citation、claim checking、figure/table 补充留下接口这才是科研 RAG 真正需要的最小骨架。如果要和 OpenAlex、Crossref 组合怎么组合才合理更现实的答案不是二选一而是分层组合。一种更稳的架构OpenAlex / Crossref / PubMed做发现、筛选、外部补充Sciverse做 evidence retrieval、context expansion、resource accessCursor / Claude / Codex / MCP做推理、写作、编排、交互也就是说如果你要“找哪些论文存在”metadata-first 工具仍然很重要如果你要“证据到底写了什么”Sciverse 这类 evidence-first 接口会更关键技术上这比“一个工具包打天下”更符合现实。可复现评测方案本文未进行实测跑分仅提供可复现评测方案。如果你要比较Sciverse vs OpenAlex 通用 RAG建议不要比“谁搜得多”而要比“谁更适合 Agent 生成可信答案”。评测目标验证三件事检索结果是否更接近可引用证据而不是只给元数据回到原文上下文的链路是否更顺Figure / Table 是否能进入下游 Agent 工作流测试任务选 20 个科研问题按 4 类均匀分布任务类型示例问题关键观察点综述型“总结 2023-2026 年固态电解质界面稳定化策略”是否能形成 citation-ready 证据包Claim checking“Cas12a 的脱靶是否系统性低于 Cas9”是否能给出支持/反驳/证据不足图表导向“哪类图表最能体现 mRNA-LNP 递送改进结果”是否能拿到 Figure / Table 资源筛选型“找 2024 年后高被引 AI for Science 论文”metadata 检索是否清晰可控评测指标Evidence Coverage答案中关键断言有多少能回链到证据Citation Readiness是否保留doc_id / offset / page / doiContext Recovery Success命中后是否能顺利读取上下文Figure/Table Availability是否能把图表资源纳入结果Workflow Complexity完成任务所需接口数、清洗步骤数、人工补丁数调用步骤模板用同一批 query 分别跑两套方案记录每条 query 的 top hits检查能否直接拿到可引用 chunk检查能否读取原文上下文检查是否能定位 Figure / Table让同一个 LLM 基于结果生成回答人工核查回答中的每个关键 claim 是否可回链记录模板Query方案有无可引用 chunk有无上下文读取有无图表资源关键 claim 可回链数备注这类评测比单纯比召回条数更有意义因为最终要服务的是 Agent而不是搜索结果页。适合传播的小标题和金句科研 Agent 的瓶颈已经从“会不会写”转向“证据能不能回链”。元数据 API 解决的是“知道有哪些论文”证据 API 解决的是“这些论文到底说了什么”。对科研 RAG 来说doc_id offset比“又多一个 embedding”更接近真实生产问题。真正可用的 Evidence Pack不是十条链接而是 chunk、上下文、元数据和图表资源的组合。下游工作台会越来越多上游可信证据层反而更稀缺。配图与封面方案封面图图片标题科研 Agent 的可信证据数据层图片用途公众号首图 / 知乎头图中文提示词克制、高级、科研数据基础设施风格一张横版封面主体为多层科学论文网络与证据片段流中心不是机器人而是“可引用证据节点 原文上下文 Figure/Table 资源”组成的数据层架构上方连接 Cursor、Claude、Codex、MCP 等 Agent 工作台下方连接论文、图表、元数据源整体偏石墨灰、冷白、少量铜色与墨蓝点缀信息密度高像高端科研基础设施海报避免廉价蓝紫渐变、避免发光机器人、避免空洞赛博城市Optional English prompt: Editorial-grade cover for a scientific evidence infrastructure article, layered paper graph, citable evidence chunks, context windows, figure/table assets, agent workflow endpoints, restrained palette of graphite, off-white, muted copper and deep ink blue, premium research systems aesthetic, no glowing robot, no cheap purple gradient配图 1图片标题Sciverse 五接口与 Agent 工作流图片用途解释agentic-search / meta-search / meta-catalog / content / resource绘图说明画成分层架构图。左侧是 query 与 filters中间是五个接口右侧是 Cursor / Claude / Codex / MCP / 自建 Agent。强调agentic-search - content - resource和meta-catalog - meta-search - content两条主链。配图 2图片标题Sciverse 与 OpenAlex / Semantic Scholar / Crossref 的分工图图片用途客观对比竞品边界绘图说明用能力矩阵或雷达图但不要做夸张满分图。突出“metadata / graph / DOI / evidence chunk / context / figure-table”几个维度即可。配图 3图片标题Evidence Pack 组成示意图片用途把 Agent 可消费的数据结构讲清楚绘图说明中心是一个 JSON/Markdown 风格证据包周围四个输入模块分别是 evidence chunk、metadata、context、figure/table右侧输出是 literature review、claim checker、scientific RAG、MCP tool。事实核查清单截至 2026 年 7 月 2 日Sciverse 当前公开接口名称为agentic-search、meta-search、meta-catalog、content、resourceagentic-search应表述为自然语言语义证据检索不应写成普通关键词检索meta-search应表述为结构化元数据检索不应写成全文语义检索content的核心用法应基于doc_id offsetresource的核心定位是 Figure / Table 资源访问本文未核查到 OpenAlex、Crossref、Semantic Scholar 公开提供与 Sciverse 对等的doc_id offset原文上下文读取链路如官方后续更新以最新官方文档为准本文未声称 Claude Science 已集成 Sciverse这里只讨论“下游科研工作台”与“上游证据层”的关系本文未进行实测跑分仅提供可复现评测方案代码示例中的响应字段兼容读取仅用于降低字段变动风险精确字段名以最新官方文档为准线上llms.txt公开入口本次未稳定核查到相关产品定位优先依据官方文档、GitHub 仓库与本地最新llms-full.txt结尾 CTA如果你正在做科研 Agent、科学事实核查、文献综述生成或者希望把 Cursor、Claude、Codex、MCP 工作流接到更可信的科学证据链上Sciverse 值得被放到“上游证据层”这个位置重新评估。建议直接从三步开始先看官方文档确认五个接口的边界与调用方式用agentic-search - content跑一个最小 Evidence Pack再把meta-search和resource接进你的 Agent / RAG / MCP 工作流很多时候科研 Agent 的差异化不在提示词而在它背后的证据层。
