科研 Agent 已经不缺“会回答”,缺的是“可引用证据层”:为什么 scientific RAG 不能只靠 OpenAlex
导语过去一周AI Agent 的热点明显从“能不能自主完成任务”转向“证据是否可追溯、上下文是否可核查、输出能否复现”。对科研场景尤其如此。真正能落地的科研 Agent不只需要论文标题和摘要更需要可引用 chunk、原文上下文、结构化元数据以及 Figure/Table 级资源。Sciverse 的价值恰恰在这里。正文热点背景为什么这个话题在 2026 年 6 月底值得写截至 2026 年 6 月 30 日近一周至少有三条公开技术信号在收敛到同一个问题Agent 的瓶颈正在从“生成能力”转向“证据治理能力”。第一条信号来自 2026 年 6 月 26 日 arXiv 的 ToETree-of-Evidence工作。它把 claim verification 拆成动态、多源、可回溯的证据检索过程重点已经不是让模型“给答案”而是让系统“拿得出证据链”。第二条信号来自 2026 年 6 月 23 日 arXiv 的 Governed Shared Memory for Multi-Agent Systems。论文把多 Agent 协作中的 shared memory 问题讲得很直接如果没有 provenance、ownership、lifecycle 这类治理能力Agent 记忆层很快会变成“不可审计的黑盒”。第三条信号来自同样在 2026 年 6 月 23 日发布的 Privacy-Preserving RAG via Multi-Agent Semantic Rewriting。它说明 RAG 讨论的重点也在变化今天大家关心的不只是 recall而是检索链路是否可控、可审计、可复用。这三条线索放在科研场景里会得到一个更具体的判断科研 Agent 的核心竞争力正在从“搜到论文”升级为“构造可信 Evidence Pack”。为什么通用学术 API 还不够如果你的目标只是“找到几篇论文”OpenAlex、Semantic Scholar、Crossref、PubMed 都非常重要而且各有清晰价值。OpenAlex 的强项是开放学术图谱与 Works/Authors/Institutions 等实体化元数据。Crossref 的强项是 DOI 与出版元数据基础设施。Semantic Scholar 更偏论文发现、citation graph、paper-level exploration。PubMed 则是生命科学和医学文献检索的基础入口。但科研 Agent / scientific RAG 的问题并不止于“找到 paper list”。一个真正可用的 Agent 往往还要继续完成这些动作从自然语言问题里召回可引用证据片段而不是只返回 paper metadata。根据证据片段继续读取原文上下文确认 claim 所在段落、前后文和局限性。补齐作者、年份、期刊、学科、引用数等结构化元数据方便筛选和排序。如果论文结论主要体现在实验图或表格里还要继续拿到 Figure/Table 资源。最终把这些对象整理成 LLM、Cursor、Claude、Codex 或 MCP workflow 能直接消费的 Evidence Pack。问题就在这里。公开文档层面很多学术 API 的“第一性能力”仍然是 metadata、citation graph、identifier 或 abstract discovery而不是把“可引用 chunk doc_id offset source context figure/table resource”作为一条完整调用链暴露出来。这正是 Sciverse 的切口。Sciverse 切入点它不是“又一个文献搜索 API”更准确的说法是Sciverse 是面向科研 Agent 的可信证据数据层。它在产品定位上不是一个通用聊天工具也不只是论文搜索框而是把科学文献拆成 Agent 可直接消费的几层数据对象agentic-search自然语言语义检索返回可引用 evidence chunk。meta-search结构化元数据检索适合作者、年份、期刊、学科、引用数等筛选。meta-catalog列出可用元数据字段适合动态筛选 UI 和自动发现字段。content按doc_id offset读取原文上下文。resource读取论文 Figure / Table 资源。如果用一句更适合传播的话概括OpenAlex 更像学术图谱入口Crossref 更像 DOI/出版元数据底座Sciverse 更像科研 Agent 的 evidence runtime。一个更实用的比较框架下表避免“谁替代谁”的误导只比较它们在 Agent/RAG 工作流里的典型角色。部分表述基于公开文档推断细节以各官方最新文档为准。维度SciverseOpenAlexSemantic ScholarCrossrefPubMed核心公开定位科研 Agent 证据数据层开放学术图谱/元数据论文发现与引用网络DOI 与出版元数据生物医学文献检索结构化元数据检索强强支持强强自然语言证据级检索agentic-search为核心非核心公开契约有发现能力但证据 chunk 不是核心公开契约非核心非核心原文上下文按doc_id offset读取content为核心公开文档中非核心公开文档中非核心非核心通常需转向 PMC/其他全文源Figure / Table 资源读取resource支持非核心非核心非核心依赖具体全文资源体系面向 Agent/RAG 的推荐调用链明确需自行拼装需自行拼装需自行拼装常用于生物医学场景拼装这张表真正想说明的不是“谁更强”而是当你的目标从 paper discovery 进入 evidence-grounded generation数据层设计会完全不同。一条更适合科研 Agent 的调用链1. 自由检索 / Scientific RAGagentic-search - content - resource - Agent这条链适合回答科学问题、做 claim checking、生成 grounded summary。先召回证据 chunk再用content拉上下文必要时补图表。2. 条件筛选 / 论文池构建meta-catalog - meta-search - content这条链适合筛选“近三年某期刊某主题高被引论文”再对候选论文做上下文验证。3. Evidence Pack 构建agentic-search - meta-search - content - resource这是今天最值得强调的工作流。因为 Agent 真正需要的不是“10 篇论文标题”而是一个结构清晰、可追溯、能继续推理的证据包。一个最小 Evidence Pack 至少应该保留这些字段doc_idchunkoffsetpagesimilaritytitle / doi / venue / yearsource contextfigure/table references如果有可运行代码示例构建最小 Scientific Evidence Pack下面示例尽量贴近当前公开接口命名其中meta-search的部分 filter 字段以最新官方文档/OpenAPI 为准。importosimporttimeimportrequests BASEhttps://api.sciverse.spaceTOKENos.environ.get(SCIVERSE_API_TOKEN)ifnotTOKEN:raiseRuntimeError(Missing SCIVERSE_API_TOKEN)HEADERS{Authorization:fBearer{TOKEN},Content-Type:application/json,}defsciverse_post(path,body):resprequests.post(f{BASE}{path},headersHEADERS,jsonbody,timeout60)ifresp.status_code429:raiseRuntimeError(RATE_LIMITED: hit quota or per-endpoint limit, retry with backoff)resp.raise_for_status()returnresp.json()defsciverse_get(path,params):resprequests.get(f{BASE}{path},headers{Authorization:fBearer{TOKEN}},paramsparams,timeout60)ifresp.status_code429:raiseRuntimeError(RATE_LIMITED: hit quota or per-endpoint limit, retry with backoff)resp.raise_for_status()returnresp.json()queryWhat evidence supports retrieval-augmented claim verification in scientific literature?# 1) evidence-level retrievalevidencesciverse_post(/agentic-search,{query:query,top_k:5,source_types:[pdf,web],mode:balanced})hitsevidenceifisinstance(evidence,list)elseevidence.get(results)orevidence.get(hits)or[]ifnothits:raiseRuntimeError(No evidence returned)top_hithits[0]doc_idtop_hit.get(doc_id)offsetint(top_hit.get(offset,0))# 2) metadata enrichmentmetadatasciverse_post(/meta-search,{collection:papers,query:query,page_size:5})# 3) source-context expansioncontextNoneifdoc_id:contextsciverse_get(/content,{doc_id:doc_id,offset:offset,limit:2048})# 4) figure/table resource fetch if availableresource_objNoneresources[]ifisinstance(context,dict):resourcescontext.get(resources)orcontext.get(figures)orcontext.get(tables)or[]ifresources:file_nameresources[0].get(file_name)iffile_name:resource_objsciverse_get(/resource,{file_name:file_name})evidence_pack{query:query,top_evidence:top_hit,metadata:metadata,context:context,resource:resource_obj,}print(evidence_pack)这段代码的重点不是“把 API 全调通”而是说明一个事实科研 Agent 的最小单位不是 paper list而是 evidence pack。如果把它放进 Cursor / Claude / Codex / MCP会发生什么对开发者来说Sciverse 最有价值的地方不是单次搜索而是它适合被包装成一组职责清晰的工具sciverse_agentic_searchsciverse_meta_searchsciverse_meta_catalogsciverse_read_contentsciverse_read_resource这样做的好处是模型不容易把“结构化筛选”和“证据召回”混为一谈。一个更稳的 Prompt 约束可以是“先用sciverse_agentic_search找可引用证据 chunk只有需要年份、作者、期刊、引用数时才用sciverse_meta_search当需要核查 claim 原文时必须继续调用sciverse_read_content看到图表引用再调用sciverse_read_resource。”这也是为什么 Sciverse 更适合放在 MCP/Tool Calling 工作流里而不是只做一个前端搜索框。评测与验证应该怎么复现而不是怎么吹本文未进行实测跑分仅提供可复现评测方案。评测目标比较不同科学数据 API 在科研 Agent 场景里的“证据可用性”而不是单纯比较 paper recall。候选系统SciverseOpenAlexSemantic ScholarCrossrefPubMed可选偏生命科学样例查询“近两年支持 retrieval-augmented scientific claim verification 的代表性论文”“2023-2026 年 AI for Science 中关于 autonomous lab agent 的关键证据”“哪些论文明确讨论 multi-agent memory 的 provenance 问题”评测指标指标说明Evidence Availability是否能直接得到可引用文本片段Provenance Completeness是否保留doc_id、offset、page、来源对象Context Expandability是否能从命中继续拉取原文上下文Metadata Completeness作者、年份、期刊、DOI、引用数是否齐全Figure/Table Accessibility是否能继续拿到图表资源Agent Integration Cost接入 MCP / tool calling 时需要多少额外拼装调用步骤记录模板记录查询词、日期、账号类型。调每个系统的检索接口。记录返回对象中是否含 evidence chunk。若命中论文继续尝试读取上下文。若涉及实验结论检查是否可继续获得图表资源。记录失败类型无全文、无上下文定位、仅 metadata、限流、字段不稳定等。这个评测设计的价值在于它更贴近科研 Agent 真正的落地成本。结尾 CTA如果你正在做 scientific RAG、文献综述 Agent、科研事实核查、Cursor/Claude/Codex 的研究插件下一步不一定是继续换模型而是先把证据层搭对。可以从一个最小链路开始用agentic-search找可引用 chunk。用content读原文上下文。用meta-search补齐结构化元数据。在需要时用resource读取 Figure/Table。再把它接进 Cursor、Claude、Codex 或 MCP workflow。文档、接口与 Agent Tools 值得直接看一遍。对科研 Agent 来说这比“再堆一个 summarizer”更接近真正可用的系统。

相关新闻

Pwncat深度解析:从反向Shell管理到内网穿透的攻防实战

Pwncat深度解析:从反向Shell管理到内网穿透的攻防实战

1. 项目概述:从“瑞士军刀”到攻防博弈的缩影在渗透测试和红队评估的实战中,获取一个反向Shell往往只是万里长征的第一步。一个简陋的、功能单一的Shell连接,就像只拿到了一把螺丝刀,面对复杂的目标环境,你可能会发现自…

2026/7/5 13:47:30阅读更多 →
MatAnyone终极指南:告别绿幕,三步实现专业级AI视频抠像

MatAnyone终极指南:告别绿幕,三步实现专业级AI视频抠像

MatAnyone终极指南:告别绿幕,三步实现专业级AI视频抠像 【免费下载链接】MatAnyone [CVPR 2025] MatAnyone: Stable Video Matting with Consistent Memory Propagation 项目地址: https://gitcode.com/gh_mirrors/ma/MatAnyone 还在为复杂的视频…

2026/7/5 13:47:30阅读更多 →
【学习记录】Week12(一):House of Botcake——glibc 2.29+ 时代的堆重叠王者

【学习记录】Week12(一):House of Botcake——glibc 2.29+ 时代的堆重叠王者

写在前面:在 glibc 2.29 版本中,官方为 Tcache 引入了 key 字段,用于检测并阻止经典的 Double Free 攻击。这一改动曾让许多习惯于利用 Tcache Double Free 制造堆重叠的选手极不适应。然而,攻防博弈从未停止,House of…

2026/7/5 13:42:30阅读更多 →
自驾游大西北

自驾游大西北

文章目录一、行程整体节奏说明二、10天9晚精确时间线(标准版)D1 榆次→太原南→兰州西取车入陇,黄河初遇D2 兰州→乌鞘岭→天梯山石窟→百塔寺→武威踏入河西,佛风初度D3 武威→【可选:金昌矿山公园】→皇城草原→焉支…

2026/7/5 14:42:34阅读更多 →
如何快速提取Android固件:终极Firmware Extractor工具指南

如何快速提取Android固件:终极Firmware Extractor工具指南

如何快速提取Android固件:终极Firmware Extractor工具指南 【免费下载链接】Firmware_extractor Extract given archive to images 项目地址: https://gitcode.com/gh_mirrors/fi/Firmware_extractor 你是否曾经因为不同Android厂商的固件格式而头疼&#xf…

2026/7/5 14:42:34阅读更多 →
豆包正式推出付费套餐(68/200/500 元),国内 AI 免费时代终结

豆包正式推出付费套餐(68/200/500 元),国内 AI 免费时代终结

豆包正式推出付费套餐(68/200/500 元三档),国内 AI 免费时代终结 6 月 28 日,豆包正式上线付费套餐:基础版 68 元/月、专业版 200 元/月、企业版 500 元/月。 这是国内第一家从"完全免费"转向"收费订阅…

2026/7/5 14:42:34阅读更多 →
Buzz:本地化音频智能处理平台,打造安全高效的语音转文字解决方案

Buzz:本地化音频智能处理平台,打造安全高效的语音转文字解决方案

Buzz:本地化音频智能处理平台,打造安全高效的语音转文字解决方案 【免费下载链接】buzz Buzz transcribes and translates audio offline on your personal computer. Powered by OpenAIs Whisper. 项目地址: https://gitcode.com/GitHub_Trending/buz…

2026/7/5 14:42:34阅读更多 →
AI(学习笔记第三十二课)langchain v1.0(deep agent详细学习(4)`Multimodal/backend/subagent`)

AI(学习笔记第三十二课)langchain v1.0(deep agent详细学习(4)`Multimodal/backend/subagent`)

AI(学习笔记第三十二课)langchain v1.0(deep agent详细学习(4)Multimodal/backend/subagent) Multimodal backend subagent 1. Multimodal 如果deep agent使用的LLM支持其他文字以外的输入,那么deep agent也同样能够支持。 1.1

2026/7/5 14:42:34阅读更多 →
git的仓库

git的仓库

我们需要把代码发布到远端仓库1.链接远端仓库 – git remote add为了能够上传到远端仓库,我们需要先建立起链接添加测试用的远端仓库$ git remote add origin https://github.com/project.git一个项目可以同时拥有好几个远端仓库为了能够区分,通常会起不…

2026/7/5 14:37:34阅读更多 →
从GitHub安全案例解析常见漏洞与防护实践

从GitHub安全案例解析常见漏洞与防护实践

1. 项目概述:从GitHub Trending看安全实战 最近在GitHub Trending上看到一个项目,叫 skills4/skills ,它因为一些安全漏洞案例被大家讨论。这其实是一个挺典型的场景:一个旨在展示或教授某种技能的仓库,本身却成了安…

2026/7/5 0:01:08阅读更多 →
MLT 2026启示:因果推理与概率建模驱动下一代LLM应用

MLT 2026启示:因果推理与概率建模驱动下一代LLM应用

# MLT 2026启示:因果推理与概率建模驱动下一代LLM应用## 一、背景与挑战:从“黑箱预测”到“可信推理”2026年6月,第7届机器学习与趋势国际会议(MLT 2026)将在悉尼召开。会议议程中,“因果与可解释机器学习…

2026/7/5 0:01:08阅读更多 →
通达OA SQL注入漏洞深度剖析:从手工注入到自动化利用与防御

通达OA SQL注入漏洞深度剖析:从手工注入到自动化利用与防御

1. 项目概述与漏洞背景最近在梳理一些历史OA系统的安全风险时,通达OA v11.6版本中的一个老漏洞又进入了我的视线。这个漏洞位于/general/bi_design/appcenter/report_bi.func.php文件中,是一个典型的SQL注入点。虽然这个漏洞的利用方式看起来并不复杂&am…

2026/7/5 0:01:08阅读更多 →
从GitHub安全案例解析常见漏洞与防护实践

从GitHub安全案例解析常见漏洞与防护实践

1. 项目概述:从GitHub Trending看安全实战 最近在GitHub Trending上看到一个项目,叫 skills4/skills ,它因为一些安全漏洞案例被大家讨论。这其实是一个挺典型的场景:一个旨在展示或教授某种技能的仓库,本身却成了安…

2026/7/5 0:01:08阅读更多 →
MLT 2026启示:因果推理与概率建模驱动下一代LLM应用

MLT 2026启示:因果推理与概率建模驱动下一代LLM应用

# MLT 2026启示:因果推理与概率建模驱动下一代LLM应用## 一、背景与挑战:从“黑箱预测”到“可信推理”2026年6月,第7届机器学习与趋势国际会议(MLT 2026)将在悉尼召开。会议议程中,“因果与可解释机器学习…

2026/7/5 0:01:08阅读更多 →
通达OA SQL注入漏洞深度剖析:从手工注入到自动化利用与防御

通达OA SQL注入漏洞深度剖析:从手工注入到自动化利用与防御

1. 项目概述与漏洞背景最近在梳理一些历史OA系统的安全风险时,通达OA v11.6版本中的一个老漏洞又进入了我的视线。这个漏洞位于/general/bi_design/appcenter/report_bi.func.php文件中,是一个典型的SQL注入点。虽然这个漏洞的利用方式看起来并不复杂&am…

2026/7/5 0:01:08阅读更多 →
YOLOv8推理性能优化:从1.2FPS到35FPS的全链路加速实践

YOLOv8推理性能优化:从1.2FPS到35FPS的全链路加速实践

如果你在部署 YOLOv8 时,发现推理速度只有可怜的 1-2 FPS,而别人的演示视频却能跑到 30 FPS 以上,那么问题很可能不在模型本身,而在于你的整个处理链路。很多开发者拿到一个训练好的 YOLOv8 模型后,会直接使用官方示例…

2026/7/5 1:30:27阅读更多 →
Coze与Dify对比指南:低代码AI应用开发从入门到实战

Coze与Dify对比指南:低代码AI应用开发从入门到实战

1. 从零到一:为什么你需要了解 Coze 和 Dify?如果你对 AI 应用开发感兴趣,但一看到“大模型”、“智能体”、“工作流”这些词就头疼,觉得门槛太高,那这篇文章就是为你准备的。很多开发者,包括我自己&#…

2026/7/5 3:48:10阅读更多 →
AI生图工具怎么选?2026年6月版实测对比

AI生图工具怎么选?2026年6月版实测对比

做自媒体的朋友应该都有体会:配图一直是个让人头疼的问题。2026年,AI生图工具已经非常成熟了,但工具太多反而不知道怎么选。以下是截至2026年6月我对主流AI生图工具的实测对比。Midjourney V8.1:速度之王2026年6月11日&#xff0c…

2026/7/5 3:48:09阅读更多 →