导语科研 Agent 最危险的检索错误未必是漏掉一篇论文而是自信地调用一个不存在、无权限或不支持当前算子的字段。真正可维护的科研检索工作流不应把元数据结构写死在 Prompt 里而应先读取数据契约再构造查询。正文当 Agent 开始维护科学软件接口契约比 Prompt 更重要2026 年 7 月OpenAI 发布了一份关于 Agent 辅助科学计算的探索性报告汇总了 8 个以生命科学为主的项目。报告观察到研究者的角色正在从具体实现转向验证与编排定义系统应该构建什么、怎样判断正确以及何时可以交付。同月ACL Findings 收录的一篇综述将 Science of Science 场景中的 AI Agent 区分为两类一类模拟科学共同体另一类作为工具参与数据分析与科研工作流。综述同时把可靠性、数据质量与偏差列为关键挑战。这两个信号指向同一个工程问题科研 Agent 不仅要会调用工具还要知道工具此刻允许它怎样调用。对于文献系统这个问题尤其明显。用户可能提出“找出 2023 年以后发表、与固态电池界面稳定性相关、英文、可读取全文的高影响力论文。”人类读到的是一个自然语言需求Agent 却必须把它拆成多个机器约束“2023 年以后”对应哪个年份字段语言字段叫language、lang还是别的名字影响力能否排序支持哪种排序值“可读取全文”是否有可筛选字段当前 Token 是否有权访问这些字段字段支持等于、范围、包含还是短语匹配如果模型仅凭训练记忆拼参数生成的 JSON 即使语法正确也可能根本不是一个合法查询。科研检索中的 Schema 幻觉普通问答中的幻觉通常出现在答案里工具型 Agent 的幻觉还会出现在请求参数中。一种常见实现是把字段直接写入系统提示词年份使用 publication_year 语言使用 language 引用数使用 citation_count这在原型阶段很方便但会迅速产生三类风险。第一类是版本漂移。数据服务增加、改名或调整字段能力后Prompt 中的旧字段不会自动更新。第二类是权限漂移。不同 Token 能看到的字段范围可能不同。文档存在某个字段不等于当前调用者一定可以使用。第三类是算子错配。字符串、日期、数值和枚举字段支持的操作不相同。Agent 如果只知道字段名不知道filterable、sortable和operators仍然可能构造错误请求。因此科研 Agent 需要的不只是 API 文档还需要一个可在运行时读取的数据契约。不同学术数据服务解决的是不同层次的问题OpenAlex、Semantic Scholar、Crossref 和 PubMed 都是重要的科研数据基础设施但各自的重点不同。下面的比较旨在说明使用方式差异而不是判断谁能替代谁。能力维度SciverseOpenAlexSemantic ScholarCrossrefPubMed结构化文献元数据支持核心能力核心能力核心能力生物医学领域核心能力字段目录的运行时发现meta-catalog面向 Agent 返回字段能力与算子主要依据公开 API schema主要依据公开 API 文档主要依据 REST API 文档主要依据 E-utilities 规范自然语言证据片段检索agentic-search非核心定位提供检索与论文数据能力非核心定位以生物医学文献检索为主原文上下文续读content是公开调用链的一部分非核心定位非核心定位非核心定位取决于关联全文来源面向 Agent 的工具封装提供 SDK、MCP 与 Agent Tools通常需要开发者封装通常需要开发者封装通常需要开发者封装通常需要开发者封装如果任务是构建开放学术图谱OpenAlex 很合适如果要获取 DOI 注册元数据Crossref 是重要来源如果聚焦生物医学检索PubMed 仍有清晰的领域优势。Sciverse 的切入点不同它把科学文献检索、元数据筛选和原文取证组织成可进入 Agent 工作流的数据接口并通过meta-catalog让 Agent 在运行时发现当前可用的元数据能力。meta-catalog让数据接口描述自己根据当前公开 OpenAPISciverse 对外提供 6 个接口其中GET /meta-catalog发现当前 Token 可见的元数据字段、字段类型、筛选与排序能力、合法算子及可选样本值。POST /meta-search依据这些字段执行过滤、排序、字段投影、分页和 facets 查询。两者不是两个孤立功能而是一组“发现—执行”协议用户自然语言需求 ↓ Agent 提取筛选意图 ↓ GET /meta-catalog 读取字段、类型、能力、operators ↓ 字段映射与请求校验 ↓ POST /meta-search ↓ 处理 results / total_count / next_cursor ↓ 必要时再进入原文或其他证据链路meta-catalog的字段描述可能包括返回信息Agent 应如何使用name作为meta-search的真实字段名禁止自行改写type判断值应按字符串、数值、日期或其他类型处理filterable决定字段能否进入filterssortable决定字段能否进入sortsearchable判断字段是否支持检索语义operators从服务端允许的算子中选择而非自行发明sample_values辅助识别枚举取值仅在请求且服务可提供时出现description帮助模型把自然语言概念映射到正确字段这里最重要的设计不是“多调用一次接口”而是改变 Agent 的决策顺序先用服务端返回的 schema 约束模型再让模型生成检索请求。一个更稳健的 Agent 架构实际系统可以把字段自发现分成四层。第一层意图解析模型只负责提取概念不立即生成最终 API 字段。例如{topic:solid-state battery interface stability,constraints:{publication_year:{gte:2023},language:English},preferences:{fulltext_required:true,rank_by:citation impact}}这里的publication_year和language只是内部语义标签不直接发送给 Sciverse。第二层Schema ResolverResolver 调用meta-catalog寻找与内部语义最匹配且满足能力要求的字段。例如年份约束必须找到语义描述匹配“发表年份”filterabletrueoperators包含合适的范围算子。如果找不到系统应明确返回“当前数据契约不支持该筛选”而不是猜一个字段。第三层请求编译与校验将解析后的意图编译为meta-search请求并在发出前校验每个字段都出现在本次 catalog 中每个字段支持当前操作只对sortabletrue的字段排序非空query不与sort同时发送页码、页大小和深分页方式符合最新文档。第四层结果路由meta-search返回的是候选论文元数据不是最终科学结论。Agent 后续可以根据任务继续读取原文、核验上下文或组织证据但不能把一组元数据记录直接包装成确定性结论。Python先发现字段再构造查询以下示例使用当前公开 REST 接口不依赖虚构 SDK。它先读取 catalog再从服务端返回的数据中选择一个真实可筛选字段和合法算子最后执行一次元数据查询。以下字段以最新线上文档 / OpenAPI 为准。importosimporttimeimportrequests BASE_URLhttps://api.sciverse.spaceAPI_TOKENos.environ[SCIVERSE_API_TOKEN]HEADERS{Authorization:fBearer{API_TOKEN},Content-Type:application/json,}defrequest_with_retry(method,url,**kwargs):处理 429 和可重试的网关错误。forattemptinrange(4):responserequests.request(method,url,headersHEADERS,timeout30,**kwargs,)ifresponse.status_code429:retry_afterresponse.headers.get(Retry-After)wait_seconds(int(retry_after)ifretry_afterandretry_after.isdigit()else2**attempt)time.sleep(wait_seconds)continueifresponse.status_codein{502,503,504}:time.sleep(2**attempt)continueresponse.raise_for_status()returnresponseraiseRuntimeError(Sciverse API 多次限流或暂时不可用)# 1. 读取当前 Token 可见的数据契约catalog_responserequest_with_retry(GET,f{BASE_URL}/meta-catalog,params{include_sample_values:true},)catalog_payloadcatalog_response.json()# 兼容直接返回与统一 data 信封以实际 OpenAPI 响应为准catalogcatalog_payload.get(data,catalog_payload)fieldscatalog.get(fields,[])# 2. 选择服务端明确标记为可筛选、且提供样本值的字段candidatenext((fieldforfieldinfieldsiffield.get(filterable)andfield.get(sample_values)andfield.get(operators)),None,)ifcandidateisNone:raiseRuntimeError(当前 catalog 中没有适合本示例的可筛选字段)field_namecandidate[name]sample_valuecandidate[sample_values][0]operatorscandidate[operators]# 优先使用等值算子服务端未声明时不自行编造operatornext((opforopinoperatorsifopFILTER_OP_EQ),operators[0],)# 3. 用运行时发现的字段构造 meta-searchsearch_body{filters:[{field:field_name,operator:operator,value:sample_value,}],fields:[title,field_name],page:1,page_size:10,}search_responserequest_with_retry(POST,f{BASE_URL}/meta-search,jsonsearch_body,)search_payloadsearch_response.json()search_datasearch_payload.get(data,search_payload)# 4. 处理响应字段print(使用字段,field_name)print(使用算子,operator)print(总结果数,search_data.get(total_count))forpaperinsearch_data.get(results,[]):print({doc_id:paper.get(doc_id),title:paper.get(title),field_name:paper.get(field_name),})next_cursorsearch_data.get(next_cursor)ifnext_cursor:print(存在下一页 cursor可按最新文档继续深分页)生产系统还应该增加两项控制。其一把 catalog 按 Token、环境和版本短期缓存避免在每次搜索前重复读取但不能把缓存固化成永不过期的代码常量。其二记录“用户意图—匹配字段—选用算子—最终请求”的编译轨迹。这样当检索结果异常时开发者能判断问题来自自然语言解析、字段映射还是数据服务本身。为什么不能只把 OpenAPI 全部塞进上下文把完整 OpenAPI 放进 Agent 的系统提示词看起来也能解决字段问题但它和运行时发现并不等价。首先长 schema 会持续占用上下文当 Agent 只需要两个过滤字段时没必要携带完整接口说明。其次静态 OpenAPI 描述的是公开契约而运行时 catalog 可以反映当前 Token 可见的字段和能力。权限相关的信息更适合在执行前确认。再次Agent 真正需要的不是“读过文档”而是一个确定性校验步骤。即使模型上下文里已经有字段说明程序仍应在发送请求前检查字段与算子是否合法。因此更合适的分工是OpenAPI 定义稳定的接口结构meta-catalog提供运行时元数据能力模型解释用户意图程序负责请求编译、校验和错误处理。如何验证 Schema Discovery 是否真的有效本文未进行实测跑分仅提供可复现评测方案。可以准备一组包含正常、模糊和不可满足条件的科研检索任务对比两种 Agent基线组Prompt 中硬编码字段直接生成meta-search请求。实验组先调用meta-catalog再映射字段并执行本地校验。建议记录以下指标评测指标验证方法字段合法率请求中字段是否出现在本次 catalog算子合法率所选算子是否属于对应字段的operators首次请求成功率是否无需修正即可得到 2xx 响应约束忠实度最终请求是否保留用户提出的年份、语言等条件不支持条件识别率字段不存在时是否明确拒绝而非虚构参数Schema 更新适应性修改可用字段后是否无需改 Prompt 即可恢复工作额外调用成本统计 catalog 缓存命中率与增加的请求次数可审计性是否完整记录意图到字段的映射过程测试任务不应只包含容易映射的“按年份搜索”还应加入用户使用字段别名一个条件存在多个近似字段字段可返回但不可筛选字段可筛选但不可排序当前 Token 无权访问目标字段用户同时提出全文关键词与排序要求用户要求一个 catalog 中不存在的概念。真正可靠的 Agent不是每次都勉强生成一个请求而是知道什么时候应该停止并说明能力边界。从“会调接口”走向“理解数据契约”科研 Agent 的能力上限不只由模型决定也由工具能否被稳定发现、组合和验证决定。meta-catalog看起来只是一个字段目录接口实际解决的是 Agent 工程中的基础问题让模型面对变化的数据结构时不必依赖参数记忆和 Prompt 硬编码。Sciverse 的定位也由此更清楚它不是普通文献搜索框也不替 Agent 生成最终科学结论而是面向科研 Agent 的 AI-ready 科学数据层。它向 Cursor、Claude、Codex、RAG 和 MCP 工作流提供可发现、可调用、可继续核验的科学数据能力。如果正在构建 Literature Review Agent、科研筛选器或文献 RAG可以从一个简单约束开始不允许 Agent 使用任何未经当前 schema 验证的元数据字段。查看 Sciverse 文档核对最新 OpenAPI接入 Sciverse Agent Tools把list_catalog与search_papers纳入同一调用链再通过 Cursor、Claude、Codex 或 MCP让科研 Agent 从“猜参数”升级为“按数据契约行动”。参考来源Sciverse 官方文档Sciverse 最新公开 OpenAPISciverse llms.txtSciverse llms-full.txtSciverse Agent ToolsOpenAIScientific computing in the age of agentic AIACL AnthologyAI Agents for the Science of Science