论文命中不是终点，Related Works 才是科研 Agent 的第二跳

导语

最近一周，围绕 Agentic RAG 的讨论又回到一个老问题： Agent 能不能给出看起来合理的答案，其实已经不是重点，重点是它能不能把检索、扩展、核验这条链路做成可复核流程。放到科研场景里，这个问题更尖锐。科研 Agent 找到一篇论文只是第一步，真正决定它能不能做综述、做 related works、做证据核查的，是它能不能沿着引用网络继续走第二跳。

正文

热点背景：Agent 开始从"会答"走向"可审计"

这两年大家谈 Agent，经常把注意力放在工具调用次数、长上下文长度和自动化闭环上。但最近一波更有价值的讨论，其实是透明性和可审计性。原因很简单：当 Agent 从"帮你写一段话"升级为"替你做一轮研究流程"，单次命中已经不够，证据路径才重要。

科研工作流尤其如此。一个综述型问题很少在第一条命中里结束。你需要先找到种子论文，再看它引用了谁、又被谁引用、有哪些 related works，最后再回到原文上下文核对。也就是说，科研 Agent 的真正能力，不是"搜到一段话"，而是"把一篇论文放进关系网络里继续展开"。

这正是今天值得重新讨论科研数据接口的原因。

技术问题：为什么 chunk 命中不等于综述能力

很多通用 RAG 流程到这里就停了：

1. 用户提问
2. 系统召回若干 chunk
3. 模型基于 chunk 组织回答

这套流程在 FAQ、企业知识库、产品文档里往往已经够用，但在科研场景里有三个明显缺口。

第一，chunk 解决的是"命中片段"，不是"定位论文族谱"。

一段结论性文字可能来自一篇高被引综述，也可能来自一个边缘实验结果。只看片段，Agent 很难判断这篇论文在整个研究脉络里的位置。

第二，metadata 解决的是"筛论文"，不是"扩关系"。

按年份、期刊、作者、主题筛出候选论文池很重要，但系统综述、related works、citation grounding 往往都需要继续沿引用关系走下去。

第三，论文级结果和 chunk 级结果不是一回事。

默认返回 10 条 chunk，不等于返回 10 篇论文。对科研 Agent 来说，"这 10 条证据分别来自哪些文献、它们之间有没有引用关系"，往往比片段本身更关键。

所以，科研 Agent 缺的不是又一个搜索框，而是一个能把"检索结果"接到"引用网络"和"原文核验"的数据层。

行业对比：图谱、元数据、检索各有强项，但第二跳能力决定工作流形态

维度	Sciverse	OpenAlex	Semantic Scholar	Crossref	PubMed
结构化元数据检索	支持	强	支持	强	强
自然语言证据片段检索	支持 agentic-search	非核心	部分场景强	非核心	非核心
原文上下文回读	支持 content	需自行补	非核心	非核心	依数据范围而定
引用/参考文献/相关工作扩展	支持 meta-paper-relations	强	强	部分支持	依场景而定
Figure / Table 资源获取	支持 resource	非核心	非核心	非核心	非核心
面向 Agent 工作流的统一接口链路	强	需自行封装	需自行封装	需自行封装	需自行封装

这里不是谁替代谁的问题，而是定位差异。

OpenAlex 很适合做开放学术图谱和大规模元数据分析。Crossref 在 DOI 和出版元数据基础设施上仍然非常重要。Semantic Scholar 在论文发现和引用图谱上也很成熟。PubMed 则是生命科学和医学检索中的基础入口。

Sciverse 的不同点在于，它不是只停留在论文列表层，而是更强调 Agent 真正会用到的统一调用链：先用 meta-search 或 agentic-search 找入口，再用 meta-paper-relations 扩 citation network，再用 content 回到原文，必要时再取 resource 里的 Figure 和 Table。

一句话说，很多系统擅长告诉你"有哪些论文"，Sciverse 更强调让 Agent 继续把论文"读下去、连起来、核下去"。

Sciverse 的切入点：把"第二跳检索"做成标准接口

如果把科研 Agent 的工作流拆开看，可以分成三层：

层级	解决的问题	更适合的接口
Candidate Layer	先找到一批可能相关的论文	meta-search / agentic-search
Relation Layer	让 Agent 沿引用、参考文献、related works 继续扩展	meta-paper-relations
Evidence Layer	回到原文上下文核对具体结论	content

这三层里，最容易被忽视的是中间的 Relation Layer 。

很多团队会花很多时间优化第一层召回，却把第二层交给模型"自己理解"。结果就是：Agent 能找到一篇论文，却很难稳定地构造 related works；能命中一个 claim，却不容易把它放回整条研究链路里；能给你一个答案，却未必能给你一条可靠的证据路径。

Sciverse 在这里的价值，不是替模型写综述，而是把第二跳所需的数据接口标准化。根据官方文档和最新 Agent Tools README，当前公开能力已经可以围绕以下链路展开：

• meta-search 用结构化字段定位种子论文，并拿到 unique_id
• meta-paper-relations 按 CITATIONS、REFERENCES、RELATED_WORKS 分页扩展关系网络
• content 根据 doc_id 回读原文上下文
• resource 在需要多模态证据时继续拉取 Figure / Table

这比"把一堆 chunk 直接丢给模型"更接近真实科研流程。

技术拆解：一个最小的 related works Agent 应该怎么走

一个更合理的调用流程，不是"问一次、答一次"，而是下面这条链：

1. 用 meta-search 按主题、年份、期刊、语言等条件先找种子论文。
2. 从结果里取 unique_id，再调用 meta-paper-relations 获取 REFERENCES 或 RELATED_WORKS。
3. 对关系网络里真正重要的节点，回到 meta-search 或直接读取已有 doc_id。
4. 用 content 回读上下文，而不是只相信首轮命中的摘要或 chunk。
5. 如果论文正文中出现关键图表，再通过 resource 拉取 Figure / Table，构建更完整的 Evidence Pack。

这条链的意义在于，它把"论文发现""关系扩展""原文核验"拆开了。Agent 不需要在一次提示词里同时完成所有判断，而是可以按接口边界逐步推进。

下面是一段贴近真实接口的 Python 示例。以下字段与切片语义以最新线上文档 / 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_s = min(2 ** attempt, 8)
            print(f"Rate limited: waiting {wait_s}s before retry")
            time.sleep(wait_s)
            continue

        resp.raise_for_status()
        return resp

    raise RuntimeError("Sciverse API rate limit persisted after retries")

# 1) 先用结构化检索拿到种子论文
seed_resp = request_with_retry(
    "POST",
    f"{BASE}/meta-search",
    headers=HEADERS,
    json={
        "query": "scientific claim verification",
        "fields": ["title", "unique_id", "doc_id", "doi", "publication_published_year"],
        "page": 1,
        "page_size": 5
    }
).json()

seed = seed_resp["results"][0]
unique_id = seed["unique_id"]

# 2) 沿 related works 做第二跳扩展
rel_resp = request_with_retry(
    "POST",
    f"{BASE}/meta-paper-relations",
    headers=HEADERS,
    json={
        "unique_id": unique_id,
        "relation": "RELATED_WORKS",
        "page": 1,
        "page_size": 10
    }
).json()

related_items = rel_resp.get("items", [])
print("Seed paper:", seed.get("title"))
print("Related works count on this page:", len(related_items))

# 3) 如果种子论文可读，再回到原文上下文
doc_id = seed.get("doc_id")
if doc_id:
    content_resp = request_with_retry(
        "GET",
        f"{BASE}/content",
        headers=HEADERS,
        params={
            "doc_id": doc_id,
            "offset": 0,
            "limit": 1200
        }
    ).json()

    snippet = content_resp.get("text", "")[:400]
    print("Context preview:", snippet)
else:
    print("This record does not expose a readable doc_id in current results.")

这段代码背后的思路很直接：

• meta-search 负责把"问题"变成"种子论文"
• meta-paper-relations 负责把"种子论文"变成"研究邻域"
• content 负责把"研究邻域里的节点"重新落回原文证据

这就是为什么说，科研 Agent 找到论文只是第一步，真正的工作从第二跳才开始。

评测 / 验证章节

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

如果要评测一个 related works Agent 是否真的有用，我更建议看下面这几项，而不是只看首轮检索命中率：

评测维度	验证问题	可复现做法
种子定位能力	能否稳定找到该方向的代表性起点论文	用固定问题集比对 meta-search 首屏结果
第二跳扩展质量	RELATED_WORKS / REFERENCES 是否能覆盖人工整理的核心文献	选 20 个主题做人工对照
原文核验能力	Agent 是否会把关键 claim 回读到 content	记录调用链，看是否真的回源
可引用性	最终输出是否带 doc_id、doi、关系来源	检查回答里的 provenance 字段
多模态扩展潜力	是否能在需要时继续拿到图表证据	从正文引用中追到 resource

如果一个系统首轮命中很好，但第二跳关系扩展弱、原文核验弱，它更像是"会找片段的助手"，还不是"能做科研工作流的 Agent"。

结尾

科研 RAG 的分水岭，不在于能不能召回一段话，而在于能不能把这段话重新放回论文、放回引用网络、放回研究脉络里。对科研 Agent 来说，命中片段只是入口，related works、references、citations 才是让它真正进入研究流程的第二跳。

如果你正在做 Literature Review Agent、Scientific Claim Checker、Evidence Pack、 MCP 科研工具链，值得重点看一下 Sciverse 这类面向 Agent 的科学数据接口组合，尤其是 meta-search、meta-paper-relations、content 这条链路。

可以从这里继续：

• Sciverse 文档：sciverse.space/docs
• API 说明：sciverse.space/docs/sciver...
• 论文关系接口：sciverse.space/docs/sciver...
• Sciverse Agent Tools：github.com/opendatalab...
• 用 Cursor / Claude / Codex / MCP 接入：可从仓库 README 的 SDK、MCP、Skills CLI 路径直接开始

事实核查清单

• Sciverse 在本文中被表述为"面向科研 Agent 的 AI-ready 科学数据层"，而不是聊天机器人或通用搜索框。
• 文中接口职责区分为：meta-search 做结构化检索，meta-paper-relations 做引用/参考文献/相关工作扩展，content 做原文上下文读取。
• 文中未声称 Sciverse 直接生成科学结论，也未声称每篇论文都一定有全文或图表资源。
• 文中关于 Agent Tools 的说法基于最新公开 README，其中已列出 list_paper_relations 等六个工具。
• 文中未使用内部调用分布数据，因为本轮没有拿到今日 Sciverse 内部接口调用数据。
• 本文未进行实测跑分，仅提供可复现评测方案。

参考来源