为什么科研 Agent 不能只会搜论文，还必须会“追引用”

导语

这两周，Agent 生态讨论得最多的已经不是“能不能接工具”，而是“工具返回的证据能不能复核”。对科研场景来说，找到一篇论文只是入口，真正决定 Agent 是否可靠的，是它能不能继续回到原文、展开参考文献、查看谁引用了它，以及把这条证据链完整交给人复核。科研 Agent 缺的不是又一个搜索框，而是一套可进入工作流的科学数据接口。

正文

如果把 2026 年的 Agent 热点浓缩成一句话，大概就是：大家都在谈自治，但真正落地时，先撞上的往往是审计。

这件事在科研场景尤其明显。普通通用 Agent 可以在网页上抓几个结果，再组织一段看起来像答案的文本；科研 Agent 不行。因为科研问题不是“像对就行”，而是必须能回答三个追问：

第一，这个结论来自哪篇论文。
第二，原文上下文是什么。
第三，这篇论文的引用链条能不能继续展开。

这正是很多科研 RAG 和文献 Agent 现在的短板。系统通常能做到 chunk 级召回，也能返回一批看起来相关的片段，但一旦用户继续追问“这篇工作的前置研究是谁”“它引用了哪些基线论文”“后来有哪些论文反驳或延伸了它”，很多工作流就断了。因为 chunk 检索解决的是“找到一句话”，而科研判断需要的是“把一句话放回论文、把论文放回关系网络”。

换句话说，科研 Agent 的关键能力不是只会搜，而是会沿着证据继续走。

这也是为什么 OpenAlex、Semantic Scholar、Crossref、PubMed 这些系统和 Sciverse 的差异，不应该被简单理解成“谁更强”。它们的定位并不相同。

如果把 OpenAlex 这类系统比作学术图谱，Sciverse 更像科研 Agent 的调用层。前者更适合做全局知识地图，后者更适合把“找论文、看原文、追引用、取资源”串成一条可以复核的执行链。

今天这个问题值得单独拿出来讲，是因为 MCP、Skills、工具调用这些标准接口越来越成熟，Agent 接不接工具已经不是瓶颈。真正的瓶颈变成了：工具返回的数据是否天然适合继续推理。对科研来说，最典型的一步就是引用关系。

为什么引用关系这么关键？

因为一篇论文在科研工作流里从来不是孤立存在的。
做 literature review，你要从 seed paper 往外扩。
做 claim checking，你要判断某个结论是单篇论文观点，还是已经被后续工作吸收、质疑或修正。
做 benchmark 追踪，你要知道一个方法到底继承了哪些前作，又被哪些后续工作比较过。

这类任务，如果只有meta-search，你能先筛出候选论文池；如果再有agentic-search，你能找到与问题高度相关的 chunk；但如果没有关系接口，Agent 还是得自己在结果里拼 citation network。那不仅麻烦，而且很难稳定。

Sciverse 在这里切入的价值，不是替代所有学术数据库，而是把这一步变成标准化接口能力。

它的典型链路不是“只返回论文列表”，而是这样一条数据流：

这条链路背后对应的是一个更重要的架构判断：

科研 Agent 不是“检索层 + 大模型”两层结构，而至少应该拆成 metadata layer、relation layer、evidence layer、resource layer。

很多系统把 relation layer 省略了，于是 Agent 在第一轮回答里看起来很聪明，到了第二轮追问就开始失真。你让它回答“这篇工作在 related works 里的位置”，它只能继续在语义检索结果里猜；你让它判断“这是不是某条研究路线的关键节点”，它也没有稳定的展开路径。

而meta-paper-relations这种接口的价值，恰恰在于把“追引用”从启发式技巧变成正式能力。

下面给一个最小可复现流程。目标不是做完整综述，而是让 Agent 从一篇种子论文出发，先定位，再展开参考文献列表。以下字段以最新线上文档 / OpenAPI 为准。

importosimporttimeimportrequests BASE="https://api.sciverse.space"TOKEN=os.environ["SCIVERSE_API_TOKEN"]headers={"Authorization":f"Bearer{TOKEN}","Content-Type":"application/json",}defrequest_with_retry(method,url,**kwargs):forattemptinrange(3):resp=requests.request(method,url,timeout=30,**kwargs)ifresp.status_code==429:wait=2**attemptprint(f"rate limited, retry in{wait}s")time.sleep(wait)continueifresp.status_codein(500,502,503,504):wait=2**attemptprint(f"server error{resp.status_code}, retry in{wait}s")time.sleep(wait)continueresp.raise_for_status()returnrespraiseRuntimeError("Sciverse request failed after retries")# 1) 先读取 meta-catalog，避免硬编码字段catalog=request_with_retry("GET",f"{BASE}/meta-catalog",headers=headers,params={"include_sample_values":"true"},).json()# 2) 用 meta-search 定位种子论文search_body={"query":"evidence grounded scientific agent","fields":["title","doi","unique_id","doc_id","publication_published_year","publication_venue_name_unified"],"page":1,"page_size":1}search_resp=request_with_retry("POST",f"{BASE}/meta-search",headers=headers,json=search_body,).json()paper=search_resp["results"][0]unique_id=paper["unique_id"]# 3) 展开参考文献或被引网络relations_body={"unique_id":unique_id,"relation":"REFERENCES","page":1,"page_size":10}relations_resp=request_with_retry("POST",f"{BASE}/meta-paper-relations",headers=headers,json=relations_body,).json()print("seed paper:",paper["title"])print("year:",paper.get("publication_published_year"))print("doi:",paper.get("doi"))print("reference count on this page:",len(relations_resp.get("items",[])))foriteminrelations_resp.get("items",[])[:5]:print("-",item.get("title"),item.get("id"),item.get("id_type"))

这段代码的重点不在“查到 10 条 references”，而在它展示了一个更适合科研 Agent 的思路：

先让 Agent 理解 schema，再定位 paper，再展开 relation，最后才决定要不要继续读原文。

这和通用 RAG 的工作流差异很大。通用 RAG 常见做法是“召回一批 chunk，拼上下文，直接回答”。科研 Agent 如果也这么做，第一轮也许还能过得去，第二轮一旦问到“它依赖谁”“谁在后来引用了它”“有没有一条更相关的 related works 分支”，系统就会暴露出结构层缺失的问题。

从这个角度看，meta-paper-relations不是一个可有可无的附加接口，而是科研 Agent 进入“可审计”阶段的基础设施。

这也是为什么我更倾向于把 Sciverse 定义成“面向科研 Agent 的 AI-ready 科学数据层”，而不是文献搜索 API。因为搜索只能解决入口问题，数据层才解决工作流问题。

当一个系统同时提供：

• meta-search的结构化筛选
• meta-paper-relations的关系展开
• content的原文回读
• resource的 Figure / Table 获取

它服务的就不再只是“帮人找到论文”，而是“帮 Agent 形成一条可验证、可追踪、可复用的科研证据链”。

如果你今天在做的是下面这些任务，这种能力会尤其重要：

• systematic review 的种子论文扩展
• scientific claim checker 的来源核验
• benchmark lineage 的方法脉络追踪
• 多模态科研 Agent 的图表证据补全
• MCP / Cursor / Claude / Codex 场景下的科研工具链封装

需要强调的是，本文未进行实测跑分，仅提供可复现评测方案。

如果你要验证这条链路是否真的有效，可以这样设计评测：

这套评测的价值，不是测一个模型“答得多像人”，而是测它有没有把科研工作流真正走通。

很多人会说，引用关系不是新东西，学术数据库里一直都有。没错。但问题从来不是“世界上有没有 citation data”，而是“Agent 能不能用统一接口把 citation data 调起来”。这正是科研 Agent 基础设施和传统学术搜索系统的分界线。

接下来如果你要把这件事落到实际工程里，建议直接从这四步开始：

1. 先读 Sciverse 文档，确认最新字段、限流和关系接口行为。
2. 在 Agent 侧把meta-catalog作为运行期 schema 入口，而不是把字段写死。
3. 用 Sciverse Agent Tools 或 MCP 把meta-search、meta-paper-relations、content串成最小工作流。
4. 再把这条链路接进 Cursor、Claude、Codex 或你自己的科研 RAG 系统。

对科研 Agent 来说，找到论文当然重要。
但真正让系统变得可信的，从来不是“搜到了”，而是“还能继续追下去”。

参考来源

• Sciverse 开发者文档总览
• Sciverse API 文档
• Sciverse FAQ
• Sciversellms.txt
• Sciversellms-full.txt
• Sciverse Agent Tools 仓库
• Sciverse Agent Tools README
• Sciverse API OpenAPI 入口