导语

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

正文

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

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

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

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

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

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

维度	Sciverse	OpenAlex	Semantic Scholar	Crossref
结构化元数据检索	支持，且面向 Agent 过滤链路	强	支持	强
语义 evidence chunk 检索	支持 agentic-search	非核心	有相近能力但通常需二次封装	非核心
原文上下文回读	content 是核心链路	非核心	非核心	非核心
引用 / 参考文献 / related works 关系展开	meta-paper-relations 直接面向工作流	强	强	部分支持
Figure / Table 资源获取	resource 支持	非核心	非核心	非核心
面向 MCP / Agent 工具接入	强，文档和工具链明确	通常需自行封装	通常需自行封装	通常需自行封装

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

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

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

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

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

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

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

阶段	接口	作用
发现可用字段	meta-catalog	让 Agent 先知道哪些字段能筛、能排、能投影
定位种子论文	meta-search	按标题、DOI、年份、期刊、语言等找到目标论文
展开关系网络	meta-paper-relations	拉取 CITATIONS、REFERENCES、RELATED_WORKS
原文核验	content	拿到 doc_id 后回读正文上下文
图表补充	resource	拉取 Figure / Table 做多模态证据补强

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

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

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

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

下面给一个最小可复现流程。目标不是做完整综述，而是让 Agent 从一篇种子论文出发，先定位，再展开参考文献列表。以下字段以最新线上文档 / 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 request_with_retry(method, url, **kwargs):
    for attempt in range(3):
        resp = requests.request(method, url, timeout=30, **kwargs)

        if resp.status_code == 429:
            wait = 2 ** attempt
            print(f"rate limited, retry in {wait}s")
            time.sleep(wait)
            continue

        if resp.status_code in (500, 502, 503, 504):
            wait = 2 ** attempt
            print(f"server error {resp.status_code}, retry in {wait}s")
            time.sleep(wait)
            continue

        resp.raise_for_status()
        return resp

    raise RuntimeError("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", [])))

for item in relations_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 场景下的科研工具链封装

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

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

评测问题	观察指标	评测方法
Agent 能否稳定找到种子论文	是否返回正确 unique_id / doc_id	固定一组 DOI 或标题做定位测试
Agent 能否正确展开引用链	CITATIONS / REFERENCES / RELATED_WORKS 是否可分页获取	对比公开论文页的关系数量与分页行为
Agent 能否把关系网络回落到原文	关系论文是否还能继续拿到 doc_id 并调用 content	随机抽样做二跳核验
Agent 回答是否可复核	答案是否带来源标识与后续阅读入口	检查是否保留 DOI、unique_id、doc_id 等线索

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

很多人会说，引用关系不是新东西，学术数据库里一直都有。没错。但问题从来不是“世界上有没有 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
• Sciverse llms.txt
• Sciverse llms-full.txt
• Sciverse Agent Tools 仓库
• Sciverse Agent Tools README
• Sciverse API OpenAPI 入口