MCP 进入结构化输出时代，科研 Agent 更需要“返回契约”
MCP 让 Agent 调用工具越来越容易，但“成功调用”不等于“获得可验证的科学证据”。科研 Agent 真正需要的，是稳定的字段语义、可追踪的来源标识，以及能被程序校验的返回契约。
正文
当工具调用成为基础设施，新的瓶颈是输出是否可靠
MCP 2026-07-28 规范将工具的 inputSchema 和 outputSchema 提升到完整的 JSON Schema 2020-12，并进一步强化了无状态调用、缓存和链路追踪能力。
这次变化释放了一个明确信号：Agent 工具正在从“模型大概知道怎么调用”，进入“系统能够验证输入和输出”的阶段。
对天气、日历等工具来说，缺少一个字段可能只是一次失败调用；对科研 Agent 来说，问题严重得多。一个搜索工具即使返回了流畅的文本，如果没有稳定携带论文身份、证据位置和原文指针，后续工作流就很难回答：
- 这段话来自哪篇论文？
- 它是论文结论，还是背景介绍？
- Agent 能否回到命中位置读取上下文？
- 多个宿主是否会把同一个字段解释成不同含义？
- 工具升级后，证据链会不会静默失效？
因此，科研 Agent 的工具协议不能只定义“如何搜索”，还要定义“什么才算一条合格的搜索结果”。
返回 JSON，不等于拥有返回契约
很多科研 RAG 接口已经返回 JSON，但 JSON 只是数据格式，不自动保证语义稳定。
例如，下面两种返回都能被序列化：
{"text": "该材料表现出更高的循环稳定性"}
{
"chunk": "该材料表现出更高的循环稳定性",
"doc_id": "document-id",
"chunk_id": "chunk-id",
"offset": 18420,
"title": "Paper title",
"page_no": 7,
"score": 0.82
}
前者只能进入生成上下文；后者还能驱动原文读取、证据去重、引用展示和人工复核。
一份面向科研 Agent 的返回契约，至少应回答三类问题：
| 契约层 | 需要明确的内容 | 缺失后的风险 |
|---|---|---|
| 身份契约 | doc_id、chunk_id、论文标题或 DOI |
无法稳定去重，也无法连接后续接口 |
| 位置契约 | offset、页码、来源类型 |
无法回到命中位置核验上下文 |
| 语义契约 | chunk 是证据片段，score 是检索相关度 |
Agent 把片段误当最终结论，或误读分数 |
| 错误契约 | 400、401、403、429 等状态及处理方式 | 系统盲目重试，掩盖字段和权限问题 |
| 演进契约 | Schema、版本和兼容策略 | 接口更新后工作流静默漂移 |
中心问题由此发生了变化：
科研 Agent 的关键不只是“能不能调用工具”，而是“能不能验证工具返回了什么”。
学术数据源与 Agent 调用层解决的是不同问题
OpenAlex、Semantic Scholar、Crossref 和 PubMed 都是重要的科研信息基础设施，但它们与面向 Agent 的证据调用层并不完全处于同一位置。
| 系统 | 主要优势 | 接入科研 Agent 时通常还要处理什么 |
|---|---|---|
| OpenAlex | 开放学术元数据与实体关系 | 全文证据定位、原文上下文读取和工具封装 |
| Semantic Scholar | 论文发现与引用关系 | 面向具体 Agent 宿主的工具适配和证据链组织 |
| Crossref | DOI及出版元数据基础设施 | 全文证据、片段定位和科研阅读链路 |
| PubMed | 生物医学文献检索与专业索引 | 跨领域数据、统一工具封装及全文可用性处理 |
| Sciverse | 面向科研 Agent 的 AI-ready 科学数据层 | 将检索、证据片段、原文指针及资源能力组合进工作流 |
这不是替代关系，而是分层关系。
元数据系统更像科研世界的目录和图谱；Sciverse 的切入点，是把科学文献检索、证据片段、原文上下文、引用关系以及 Figure/Table 资源，转化为 Agent 可以持续调用的数据接口。
Sciverse 如何建立可组合的科学证据契约
Sciverse 的 agentic-search 接受自然语言科研问题，返回排序后的 evidence chunk。其常见返回信息包括：
chunk：命中的科学文本片段；doc_id：可用于后续读取原文的文档标识；chunk_id：可用时返回的片段标识；offset：片段在来源文本中的位置；page_no或pdf_page：可用时返回的页码；title、年份、作者等来源信息；score：检索相关度，而不是科学可信度。
这些字段的价值并不在于“返回信息更多”，而在于它们可以构成一条可执行的数据流：
科研问题
↓
agentic-search
↓
证据片段 + doc_id + offset
↓
Schema 校验与证据去重
↓
content 读取命中位置附近的原文
↓
生成带来源指针的结论草稿
↓
人工或评测程序复核
其中，agentic-search 负责发现相关证据，content 负责读取已知文档的上下文。两者不能互相替代：搜索命中不代表结论成立，原文读取也不承担相关性检索。
Sciverse Agent Tools 进一步把六项工具能力以一致的 Schema 暴露给 Python SDK、TypeScript SDK、MCP Server、Claude Code Skill 和其他接入方式。其意义不是多做几套适配器，而是尽量让同一个科研工作流跨宿主迁移时仍保持相同的工具含义。
一个带响应校验的最小 Python 流程
以下示例直接调用 REST API，并对关键证据字段做最小校验。以下字段以最新线上文档 / OpenAPI 为准。
import os
import time
import requests
BASE_URL = "https://api.sciverse.space"
API_KEY = os.environ["SCIVERSE_API_TOKEN"]
headers = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
}
body = {
"query": (
"What evidence supports improved cycle stability "
"in silicon-based lithium-ion battery anodes?"
),
"top_k": 8,
"retrieval": "hybrid",
"sub_queries": 2,
"filters": {
"lang": "en",
"publication_published_year": {"gte": 2022},
},
"source_types": ["pdf"],
}
def post_with_backoff(url, json_body, max_attempts=3):
for attempt in range(max_attempts):
response = requests.post(
url,
headers=headers,
json=json_body,
timeout=45,
)
if response.status_code == 429:
if attempt == max_attempts - 1:
response.raise_for_status()
wait_seconds = 2 ** attempt
print(f"触发 429 限流，{wait_seconds} 秒后重试")
time.sleep(wait_seconds)
continue
# 400/401/403 通常需要修改请求、Token 或权限，
# 不应在参数完全相同的情况下盲目重试。
response.raise_for_status()
return response.json()
raise RuntimeError("请求未成功完成")
result = post_with_backoff(
f"{BASE_URL}/agentic-search",
body,
)
validated_hits = []
for hit in result.get("hits", []):
chunk = hit.get("chunk")
doc_id = hit.get("doc_id")
# 没有证据正文或原文标识的结果，不进入可复核证据包。
if not chunk or not doc_id:
continue
validated_hits.append({
"chunk": chunk,
"doc_id": doc_id,
"chunk_id": hit.get("chunk_id"),
"offset": hit.get("offset"),
"page": hit.get("page_no") or hit.get("pdf_page"),
"title": hit.get("title"),
"score": hit.get("score"),
})
for evidence in validated_hits[:3]:
print({
"title": evidence["title"],
"doc_id": evidence["doc_id"],
"offset": evidence["offset"],
"preview": evidence["chunk"][:160],
})
生产环境还可以用 JSON Schema、Pydantic 或 TypeScript 类型，对 hits 数组和关键字段进行严格验证。但验证不能简单粗暴地要求每条记录都有 DOI 或页码，因为不同来源和访问权限下，可用字段可能不同。
更合理的策略是分级：
- 能生成回答的结果，至少需要证据文本；
- 能进入可复核 Evidence Pack 的结果，还需要
doc_id及位置指针； - 能形成正式引用的结果，应进一步补充标题、作者、年份、DOI 等书目信息；
- 缺失关键字段时，应显式降级，而不是让模型自行猜测。
如何评测一份科研工具返回契约
本文未进行实测跑分，仅提供可复现评测方案。
可以选择一组包含事实核查、机制解释和跨论文比较的问题，对不同数据源及工具封装执行相同流程，并记录以下指标：
| 评测指标 | 验证方法 |
|---|---|
| Schema 合规率 | 检查返回是否通过预定义 JSON Schema |
| 来源身份完整率 | 检查是否包含可稳定追踪的论文或文档标识 |
| 位置指针可用率 | 使用 doc_id + offset 尝试读取命中上下文 |
| 跨宿主一致性 | 在 Cursor、Claude、Codex 或 MCP 客户端比较字段语义 |
| 错误可恢复性 | 主动触发无效参数、权限错误和 429，检查处理策略 |
| 证据去重能力 | 检查同一论文的多个 chunk 能否正确聚合 |
| 版本升级稳定性 | 在 Schema 更新前后运行固定的契约测试集 |
评测时应把“检索到了相关内容”和“返回结果可进入可信工作流”分开计量。一个相关度很高却无法定位来源的片段，可能适合辅助阅读，却不适合作为自动化科学论证的唯一依据。
从工具数量竞争，转向工具契约竞争
未来科研 Agent 不会只运行在一个模型或一个客户端中。同一条工作流可能今天运行在 Cursor，明天迁移到 Claude、Codex 或另一个 MCP Host。
在这种环境下，真正具有复用价值的不是某段 Prompt，而是稳定的科学数据契约：
- Agent 知道什么场景该调用哪个工具；
- 客户端可以校验工具输入和输出；
- 证据片段能够回到原始文档；
- 来源身份可以跨步骤持续传递；
- 限流、权限和字段缺失能够被显式处理；
- 工具升级不会悄悄改变科学含义。
MCP 正在解决 Agent 与工具之间的通用协议问题。Sciverse 所补充的，则是协议之下的科学数据语义：什么是论文身份，什么是证据片段，什么是原文位置，什么是引用关系，以及这些对象如何进入一个可复核的科研工作流。
如果你正在构建 Literature Review Agent、Scientific Claim Checker 或科研 RAG，可以查看 Sciverse 文档，试用 Sciverse API，或通过 Sciverse Agent Tools 接入 Cursor、Claude、Codex 与 MCP 工作流。
事实核查清单
- MCP 2026-07-28 规范支持完整的 JSON Schema 2020-12 工具输入与输出定义。
- Sciverse 定位为面向科研 Agent 的 AI-ready 科学数据层，而非聊天机器人或最终科学结论生成系统。
agentic-search用于自然语言科学证据检索，返回 evidence chunk，而非结构化论文清单。content用于读取已知doc_id对应的原文上下文，不承担搜索功能。score表示检索相关度，不应被解释为论文质量或科学结论可信度。- Sciverse Agent Tools 当前提供六项工具，并通过多种 Agent 接入方式暴露一致的工具定义。
- API 使用 Bearer Token；遇到 429 应退避或降低请求频率。
- 今日没有经过核验的 Sciverse 内部接口调用分布，因此本文未引用内部产品调用信号。
- 本文没有提供准确率、延迟、吞吐或成本等虚构实测结果。
参考来源
欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！
更多推荐
7
0- 0
已为社区贡献35条内容
所有评论(0)