导语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 的差异化不在提示词而在它背后的证据层。
为什么科研 RAG 不能只靠 OpenAlex 和通用搜索：Sciverse 的证据层思路
发布时间：2026/7/4 3:38:12
导语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 的差异化不在提示词而在它背后的证据层。
相关文章
Docker集群及docker-compsoe
一、问题引入 在我们日常学习或开发过程中，如果我们的服务均采用docker容器的方式运行，比如提供后端接口服务的容器containerA和提供数据存取服务的容器containerB，如下图所示，不同的docker 容器拥有各自的ip地址和端口号。 1. 多…
把设计规范写成代码格式，是所有 AI 工具的上游约束方法论
当 AI 生成界面时，设计意图在偏离。不是 AI 故意做错，而是系统缺少一层"语义约束"。 本文提出 Schema-As-Code：一套让设计师用 YAML 契约锁住设计意图的三阶段流水线。不是替代任何工具，是所有 AI 工具的上游约束。 是 …
Opus音频编码器与GLM大语言模型的本质区别与工程实践
我注意到这个标题存在严重的信息混淆和事实偏差——Opus 是由 Xiph.Org 基金会维护的开源音频编解码器（如 Opus 1.4 发布于 2023 年），而 GLM 系列是智谱 AI 推出的开源大语言模型（GLM-4 发布于 2024 年 5 月，GLM-5 尚未…
数据库同步工具PanguSync图文教程
数据库同步工具下载https://gitee.com/AaronE_2890620459/pangu-sync 1.添加任务 点击后，会弹出一个窗口，在该窗口中依次填写任务名称、同步周期、源连接信息，目标连接信息，点击源和目标的后，会获取到所有数据库&…
攻击树分析内行指南：策略、技巧与诀窍
随着网络安全威胁变得越来越复杂，组织需要强大的工具和方法来预测和缓解潜在的攻击。攻击树分析（ATA）就是这样一种方法，它使专业人员能够系统地可视化和分析潜在的攻击场景。 ATA在汽车网络安全等领域尤为关键，在这些…
Linux管道与重定向实战技巧及Vim高效用法
1. Linux管道与重定向核心操作在Linux系统中，管道和重定向是日常操作中最常用的功能之一。它们就像数据处理的传送带，能够将命令的输出高效地传递给下一个处理环节。我们先从最基础的输出重定向开始，逐步深入到复杂的管道组合应用。1.1 输出重…
Kotlin安卓app版本自动升级设计实现
序： app项目上线后需要持续发版迭代，通过版本控制自动升级（或者说当app启动时，自动检测有最新版本，自动安装升级）就显得尤为重要，那么接下来设计具体如何落地，可以加我底部wx交流ga…
[DeepAgents:LangChain的Harness-04]TodoListMiddleware的任务拆解与状态流转
TodoListMiddleware赋予Agent显式的规划和任务跟踪能力。它强制Agent将复杂的多步骤目标分解为一组结构化的可执行项，从而将被动型Agent转变为主动型Agent。它通过拦截Agent的推理循环来注入规划逻辑和工具： 规划工具：它为Agent提供了write_t…
Windows平台Appium 2.0自动化测试环境搭建与真机连接实战指南
1. 项目概述与核心价值如果你是一名移动端测试工程师、自动化开发或者对手机应用自动化感兴趣的技术爱好者，那么“在Windows上搭建一套完整的Appium 2.0 Android SDK环境，并成功连接真机”这件事，大概率是你职业生涯中绕不开的“第一道坎”。…
Playwright自动化测试实战：从零搭建现代Web测试框架
1. 项目概述：为什么是 Playwright？如果你正在为现代 Web 应用的自动化测试头疼，尤其是面对那些充斥着动态加载、复杂交互的单页应用（SPA），那么 Playwright 的出现，很可能就是你的解药。我接触过…
SSRF漏洞攻防实战：从原理到绕过技巧与防御策略
1. 项目概述：从“内部请求”到“内网漫游”的SSRF攻防实战 在渗透测试和红队评估的实战中，我们常常会遇到一种看似“温和”实则威力巨大的漏洞：服务器端请求伪造。它不像SQL注入那样直接操作数据库，也不像命令注入那样能瞬间拿到S…
本地部署SAM Audio音频语义分割模型完整指南
1. 项目概述：为什么要在本地跑 SAM Audio？这不只是“能用”，而是“必须用”SAM Audio——全称是 Segment Anything Model for Audio，不是 Meta 那个视觉领域的 SAM（Segment Anything Model）的简单移植&…
AI Coding 六个月真实ROI账本：产品经理的血泪教训，研发的冷静忠告
6个月前的2025年12月，Boris Cherny 公开宣布自己卸载了 IDE。一时间，Vibe Coding 成了全行业最热的话题。6个月后，当我们回过头来拉一份真实账本，发现事情远没有"一句话生成一个App"那么浪漫。本文从产品经理和研发两个…
华为OD机试2025C卷-字符统计及重排[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
华为OD机试2025C卷-寻找相同子串[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
FAE放射组学分析工具：医学影像特征探索的完整解决方案
FAE放射组学分析工具：医学影像特征探索的完整解决方案 【免费下载链接】FAE FeAture Explorer 项目地址: https://gitcode.com/gh_mirrors/fae/FAE 你是否曾经面对海量医学影像数据感到无从下手？想要从CT、MRI等影像中提取有价值的定量特征&#…
0.69B参数实现中文多模态AI：揭秘Qwen3-SmVL模型融合技术的完整实战指南
0.69B参数实现中文多模态AI：揭秘Qwen3-SmVL模型融合技术的完整实战指南 【免费下载链接】happy-llm 📚 从零开始构建大模型 项目地址: https://gitcode.com/GitHub_Trending/ha/happy-llm 还在为大型多模态模型动辄数十亿参数、显存占用高而烦恼&…
解锁AMD Ryzen处理器性能潜力的SMU调试神器：从新手到专家的完整指南
解锁AMD Ryzen处理器性能潜力的SMU调试神器：从新手到专家的完整指南 【免费下载链接】SMUDebugTool A dedicated tool to help write/read various parameters of Ryzen-based systems, such as manual overclock, SMU, PCI, CPUID, MSR and Power Table. 项目地址…