欢迎光临
我们一直在努力

找到论文还不够,Citation Graph 才是科研 Agent 的工作流层

导语

这两周,Agent 讨论的重点已经不只是“能不能搜到资料”,而是“能不能把一条证据继续扩成一条研究路径”。对科研 Agent 来说,找到一篇论文、命中一段 chunk 都只是入口;真正决定它能不能做综述、补 related works、扩 citation trail 的,是能否把引用关系变成可调用的工作流层。Sciverse 的价值,恰好就在这里。

正文

最近一轮 Agent 热点,有一个很明显的变化:大家开始把注意力从“更长上下文”转向“更完整的工具链”。不管是 MCP 生态继续扩张,还是围绕 RAG 评测、Scientific Agent、research workflow 的讨论升温,问题都越来越具体了。一个 Agent 能把论文找出来,当然重要;但如果它拿到一篇核心论文之后,没法顺着 references、citations、related works 继续扩展,那它做出来的结果很容易停留在“像读过几篇”,而不是“真的走过一条研究路径”。

这也是为什么,科研场景里的检索问题,不能只理解成 search problem。很多通用 RAG 系统的默认链路是:用户提问,系统召回若干 chunk,模型据此生成回答。这个链路在 FAQ、企业知识库、产品文档里通常够用,因为目标是“回答一个问题”。但科研工作流经常不是这样。你要的不只是一个回答,而是一个可扩展的候选论文池、一组可回读的上下文、一条能向前追 references、向后追 citations、横向补 related works 的证据网络。

换句话说,科研 Agent 的最小闭环,不是“搜到片段”,而是“找到论文,然后继续扩展”。

如果只看行业里常见的几类工具,这个差异会更清楚。OpenAlex 很适合做开放学术图谱和元数据层分析,Crossref 仍然是 DOI 和出版元数据基础设施的重要来源,Semantic Scholar 在论文发现和引用网络上也很强,PubMed 则是生物医学文献工作流的重要入口。但这些产品的长项,并不完全等于 Agent 工作流的长项。对 Agent 而言,关键不是单点能力强不强,而是“是否能在同一条调用链里把 metadata、source context 和 citation expansion 连起来”。

下面这张表更适合从工作流角度看这个问题:

维度SciverseOpenAlexSemantic ScholarCrossref
结构化元数据检索 支持 支持
原文上下文读取 核心链路之一 非核心 非核心 非核心
引用 / 相关工作分页扩展 支持,适合接 Agent 工作流 强,但通常需自行封装 强,但常需自行接入工作流 部分支持
Figure / Table 资源获取 支持 非核心 非核心 非核心
面向 Agent 的组合式接口 需自行封装 需自行封装 需自行封装

这里不是说谁替代谁,而是定位不同。OpenAlex 更像地图,Crossref 更像出版标识基础设施,Semantic Scholar 更偏论文发现与图谱能力;Sciverse 更像面向科研 Agent 的 AI-ready 科学数据层,重点不在单独拥有某个字段,而在于把“元数据筛选、原文上下文、引用关系、资源读取”放进同一条可调用链路里。

如果把这个问题拆成系统设计,科研 Agent 至少有三层:

第一层是 metadata layer。这里解决的是“候选集合怎么来”。Sciverse 的 meta-search 负责这件事,适合按年份、作者、期刊、语言、DOI、主题等字段收缩论文池。它公开支持 filters、fields、page/page_size、cursor,并且文档已经明确给出 facets 和 freshness_boost。这意味着 Agent 不只是“找论文”,而是在构建一组有边界的候选集。

第二层是 evidence layer。这里解决的是“找到的内容能不能回到原文”。agentic-search 可以返回 evidence chunk,但 chunk 不是论文,片段也不是上下文。Sciverse 的 content 接口支持基于 doc_id 或 source 回读原文,并通过 Unicode 码点意义上的 offset/limit 分页。也就是说,Agent 命中片段后,可以继续把片段放回原文语境,而不是直接把 chunk 当答案。

第三层才是 workflow expansion layer。这里解决的是“这篇论文后面还能不能继续走”。Sciverse 公共 OpenAPI 里,meta-paper-relations 明确是单独的公开端点,需要传 unique_id 和 relation,其中 relation 目前公开为 CITATIONS、REFERENCES、RELATED_WORKS。这不是一个装饰性接口,而是让 Agent 从单篇论文进入引用网络的关键桥梁。

真正有价值的工作流,通常是这样一条链:

步骤接口作用
1 meta-search 先按年份、领域、期刊等条件构造候选论文池
2 agentic-search 在候选范围或开放问题上做语义证据召回
3 content 用 doc_id + offset 回读原文上下文
4 meta-paper-relations 用 unique_id 扩展 references / citations / related works
5 resource 必要时继续抓取图表和附件资源

这条链路的重点在于:引用关系不是“补充信息”,而是 Agent 继续工作的下一步输入。一个科研 Agent 如果停在 meta-search,它只能给你候选论文;如果停在 agentic-search,它只能给你命中的证据片段;但如果它能继续调用 meta-paper-relations,它才真正具备“围绕一篇核心论文滚雪球扩展”的能力。

这也是为什么很多开发者会误判科研 RAG 的难点。大家经常把注意力放在召回质量、embedding、rerank 或长上下文长度上,但对科研工作流来说,难点往往是“如何让一篇论文继续长成一个 related works 网络”。系统综述、claim checking、领域入门阅读、研究趋势追踪,背后都需要这个能力。

下面给一个最小可运行的 Python 示例,演示如何从 meta-search 找到论文,再用 meta-paper-relations 扩展引用关系。以下字段以最新线上文档 / OpenAPI 为准。

import os
import time
import requests

BASE = "https://api.sciverse.space"
TOKEN = os.environ["SCIVERSE_API_TOKEN"]

headers = {
"Authorization": f"Bearer {TOKEN}",
"Content-Type": "application/json",
}

def post_with_retry(path, payload, retries=3):
for i in range(retries):
resp = requests.post(f"{BASE}{path}", headers=headers, json=payload, timeout=30)
if resp.status_code == 429:
wait_s = min(2 ** i, 8)
print(f"rate limited, sleep {wait_s}s and retry")
time.sleep(wait_s)
continue
resp.raise_for_status()
return resp.json()
raise RuntimeError(f"request failed after retries: {path}")

# 1) 先用 meta-search 找一篇目标论文
search_body = {
"query": "scientific claim checking",
"fields": [
"title",
"doi",
"unique_id",
"doc_id",
"publication_published_year",
"publication_venue_name_unified"
],
"page": 1,
"page_size": 5,
"freshness_boost": "MILD"
}

search_data = post_with_retry("/meta-search", search_body)
results = search_data.get("results", [])
if not results:
raise RuntimeError("no paper found")

paper = results[0]
unique_id = paper.get("unique_id")
print("target paper:", paper.get("title"), unique_id)

# 2) 再用 meta-paper-relations 扩展 related works
relations_body = {
"unique_id": unique_id,
"relation": "RELATED_WORKS",
"page": 1,
"page_size": 10
}

relations_data = post_with_retry("/meta-paper-relations", relations_body)

for item in relations_data.get("items", []):
print("-", item.get("title"), item.get("id"), item.get("id_type"))

如果你更关心“命中片段后怎么回到原文”,那通常会把它和 content 接起来:

const token = process.env.SCIVERSE_API_TOKEN;
const headers = {
"Authorization": `Bearer ${token}`,
"Content-Type": "application/json"
};

async function fetchJson(url, options, retries = 3) {
for (let i = 0; i < retries; i++) {
const res = await fetch(url, options);
if (res.status === 429) {
const waitMs = Math.min(1000 * 2 ** i, 8000);
console.warn(`rate limited, retry in ${waitMs}ms`);
await new Promise(r => setTimeout(r, waitMs));
continue;
}
if (!res.ok) {
throw new Error(`HTTP ${res.status}: ${await res.text()}`);
}
return res.json();
}
throw new Error("request failed after retries");
}

async function readSourceContext(docId, offset = 0, limit = 1200) {
const url = new URL("https://api.sciverse.space/content");
url.searchParams.set("doc_id", docId);
url.searchParams.set("offset", String(offset));
url.searchParams.set("limit", String(limit));

const data = await fetchJson(url, { method: "GET", headers });
console.log(data.text);
console.log("next_offset:", data.next_offset, "more:", data.more);
}

readSourceContext("YOUR_DOC_ID_HERE").catch(console.error);

这两段代码合起来,其实就说明了一个很现实的问题:科研 Agent 不是“搜一下论文”就结束,而是要在 metadata、evidence 和 relation 之间反复跳转。meta-search 解决候选池,content 解决上下文核验,meta-paper-relations 解决工作流扩展。少了最后这一层,Agent 看起来会检索,实际上却不会“继续研究”。

还有一个很容易被忽略的点是,Sciverse 这条链路并不是把科研工作流压扁成一个搜索框。公共文档里,meta-catalog 提供字段目录发现,meta-search 提供结构化筛选和分页,content 提供原文回读,resource 提供图表资源,meta-paper-relations 提供引用网络扩展。对 Cursor、Claude、Codex、MCP 这类工具调用环境来说,这种拆分非常重要,因为 Agent 需要的是一组边界清晰、输入输出稳定、可组合的科研数据接口,而不是一个“大而全但不可控”的回答系统。

从产品定位上看,这也正是 Sciverse 和普通文献搜索 API 的差异。它不是普通搜索框,也不是通用聊天助手,更不是替用户直接生成科学结论的系统。它更适合作为科研 Agent 的 AI-ready 科学数据层:让 Agent 能检索,能筛选,能回读,能扩展,能继续组织成自己的研究路径。

如果把今天这个判断压缩成一句话,那就是:

科研 Agent 找到论文只是第一步,真正让它进入工作状态的,是 citation graph 能不能被调用。

评测 / 验证

本文未进行实测跑分,仅提供可复现评测方案。

一个可复现的评测方式是这样的:选定 20 个研究问题,每个问题先用 meta-search 找到核心论文,再要求 Agent 必须完成三件事:一是回读至少 1 段 content 原文上下文;二是基于 meta-paper-relations 扩展出 references 或 related works;三是在最终输出里给出 doc_id、unique_id、DOI 或标题级来源线索。评测重点不是回答是否流畅,而是看它是否真的完成了“候选构建 -> 原文核验 -> 引用扩展”的工作流闭环。

结尾 CTA

如果你在做 Literature Review Agent、Scientific Claim Checker、research dashboard,或者想把科研检索能力接进 Cursor、Claude、Codex、MCP 工作流,现在更值得关注的已经不是“再多召回几个 chunk”,而是“能不能把论文继续扩成一张研究网络”。

可以从这几个入口开始:

  • 查看 Sciverse 文档,确认最新公开接口与字段能力
  • 接入 Sciverse Agent Tools,把 meta-search、content、meta-paper-relations 放进你的 Agent 链路
  • 在 Cursor / Claude / Codex / MCP 里把 citation expansion 做成默认工作流步骤
  • 直接试用 Sciverse API,验证你的科研 Agent 是否真的具备“继续研究”的能力

参考来源

  • Sciverse 文档总览
  • Sciverse API 文档
  • Sciverse FAQ
  • Sciverse llms.txt
  • Sciverse llms-full.txt
  • Sciverse OpenAPI
  • Sciverse-Agent-Tools GitHub 仓库
  • TREC RAG
  • Anthropic News
赞(0)
未经允许不得转载:171主机测评 » 找到论文还不够,Citation Graph 才是科研 Agent 的工作流层
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址