OmniScholar提供43个工具、覆盖检索、Zotero读取、PDF解析、引用处理和绘图，但“工具多”本身在文献场景里意味着“模型要在一堆相近能力里选”，当检索Semantic Scholar和检索OpenAlex在Skill的描述里没有被清晰区分时，用户到底该接受“选哪个都差不多”，还是该为每个数据源单独写清楚适用场景？

目录

一、导语：工具数量的幻觉与选择成本的显性化

把43个工具塞进一个文献智能体，直觉上意味着能力边界的扩张：检索、Zotero读取、PDF解析、引用处理、绘图，几乎覆盖了从选题调研到成稿配图的全链路。但工程实践反复提示一个反直觉的现象——工具集合越大，端到端任务的成功率并不必然上升，甚至在某些评测中出现下降。原因不在工具本身，而在“选择”这一环节被低估了。当模型面对一组描述相近的Skill时，它并不是在做能力判断，而是在做语义消歧；而语义消歧的难度，与描述之间的信息重叠度正相关。

本文的核心主张可以一句话概括：在文献场景中，工具的价值不取决于它“能做什么”，而取决于它“相对于同类工具不可替代的那部分”是否被清晰表达。Semantic Scholar与OpenAlex的对比是这一主张最典型的试验场：两者都提供论文检索、都返回元数据、都支持按标题或关键词查询，若Skill描述停留在“检索学术论文”这一层，模型的选择就退化为近似随机，而随机选择在多源场景下会直接放大结果偏差。本文评述认为，这不是提示词微调能解决的问题，而是工具接口设计层面的语义工程问题。

为便于后续论证，先给出两个工作定义。其一，工具选择歧义度（TSA）：在给定任务上下文下，模型对两个及以上工具产生近似后验选择概率的程度，可用选择分布的归一化熵近似度量。其二，Skill语义边界：一个工具描述所覆盖的能力集合与其实际实现能力集合之间的吻合程度，边界越清晰，越不容易被误选。这两个概念将贯穿全文，作为分析工具而非装饰性术语。

提示：本文讨论的“工具”指以函数调用或Skill形式暴露给语言模型的可执行单元；“路由”指模型在推理阶段选择并参数化某个工具的过程。二者在工程实现上可能由不同模块承担，但分析视角一致。

二、背景与问题定义：从能力覆盖到能力区分

2.1 工具增强型智能体的基本范式

工具增强型语言模型的基本范式，可追溯到将外部能力以结构化接口暴露给模型的思路。ReAct将推理与行动交替组织，使模型能够在思考轨迹中插入工具调用；Toolformer则探索了模型自监督学习何时调用何种工具的可能性。这些工作共同确立了一个前提：工具调用的质量，取决于模型对“何时用、用哪个、怎么传参”三个问题的判断质量。本文评述认为，现有工程实践对第一个问题（何时用）投入较多，对第二个问题（用哪个）投入明显不足，而这恰恰是多工具文献系统的主要失效点。

在文献场景中，这一不足被进一步放大。文献工作流天然是多源的：预印本、期刊全文、引文网络、本地文献库、PDF原文，各自对应不同的数据源与访问方式。OmniScholar将检索、Zotero读取、PDF解析、引用处理、绘图等能力拆分为43个工具，本意是让模型按需组合；但当多个工具指向同一类数据源时，“按需”就要求模型具备区分能力，而区分能力来自描述，不来自工具数量。

2.2 问题定义：什么是“选哪个都差不多”

“选哪个都差不多”是一种常见的工程妥协，其隐含假设是：同类数据源的结果高度重叠，选错代价可忽略。这一假设在部分场景下成立，例如仅需确认某篇论文是否存在时，任一覆盖该论文的索引都能给出肯定答案。但在文献综述、系统性检索、引文追踪等任务中，该假设迅速失效：不同数据源的收录范围、更新延迟、元数据完整度、引用计数口径均存在系统性差异，选错会引入可观测的偏差。

因此，问题应被重新定义为：在何种任务条件下，多源检索工具的差异可被忽略；在何种条件下，差异必须被显式建模并写入Skill描述。这不是一个二选一的态度问题，而是一个需要边界条件的工程判断问题。下文将分别从机制、数据与工程三个层面给出回答。

表1 任务类型与多源差异敏感度的对应关系（本文归纳，基于公开数据源文档与工程实践整理）

三、原理与技术路线：工具路由的失效机制与语义边界

3.1 路由失效的三种机制

工具路由失效并非单一原因，至少可分解为三种机制。第一种是描述同质化：两个Skill的描述在语义空间中距离过近，模型无法从文本中提取区分信号。第二种是参数不可比：即便描述有差异，若参数命名与语义不一致（例如一个用query，另一个用search_terms），模型在参数化阶段仍可能混淆。第三种是反馈缺失：调用结果没有携带足够信息让模型判断选择是否正确，导致错误无法在后续轮次被纠正。

本文评述认为，三种机制中描述同质化最易被忽视，因为它不产生显式报错。模型不会说“我选错了”，它只会安静地返回一个看似合理的结果。这种静默失效在文献场景中尤其危险，因为用户往往缺乏独立核验多源差异的成本。相较之下，参数不可比和反馈缺失至少能在日志中留下痕迹。

3.2 语义边界的刻画：从“能做什么”到“只做什么”

清晰的Skill描述应遵循“正向能力+负向边界+适用条件”的三段式结构。正向能力回答“能做什么”，负向边界回答“不做什么或不应优先做什么”，适用条件回答“在什么输入特征下应被优先选择”。以检索工具为例，仅写“检索学术论文”属于单段式，信息量不足以支撑区分；补充“覆盖预印本与部分期刊、更新频率较高、引用计数口径为跨源聚合”则进入三段式的雏形。

需要强调的是，负向边界不是自我贬损，而是路由信号。一个明确声明“不适用于专利检索”的工具，反而更容易在专利任务中被正确排除。笔者认为，这一思路与软件工程中的接口契约（interface contract）同构：契约的价值不仅在于声明提供什么，更在于声明不保证什么。将契约思维引入Skill描述，是把提示词工程推向接口工程的必要一步。

# Skill 描述三段式模板（示意）
name: search_openalex
capability: 检索开放学术图谱中的作品、作者与机构实体
coverage: 覆盖多学科开放元数据，含部分预印本与期刊
negative: 不提供出版商全文；引用计数口径与商业索引不同
prefer_when: 需要作者/机构实体消歧、需要开放许可元数据时优先
fallback: 若目标为最新预印本，优先 search_semantic_scholar

3.3 可解释路由：让选择留下痕迹

可解释路由的目标不是让模型解释每一个选择，而是让选择过程可被审计。一种低成本做法是要求模型在调用前输出一行选择理由，格式固定为“选择X而非Y，因为Z”。这行理由不进入最终答案，只进入日志，用于后续分析TSA。另一种做法是在工具返回结果中附带源标识与覆盖提示，使模型在下一轮能够基于反馈修正选择。

本文评述认为，可解释路由的真正价值在于把隐式的语义消歧转化为显式的可比较信号。当选择理由被结构化记录后，工程团队可以统计“哪些工具对最常被混淆”“混淆在何种查询特征下高发”，从而有针对性地重写描述，而不是凭直觉反复调整提示词。这一闭环是本文后续工程章节的基础。

四、关键数据与案例：两个检索源的实测差异

4.1 数据源差异的公开事实

Semantic Scholar与OpenAlex均为公开学术数据服务，但定位不同。Semantic Scholar由Allen Institute for AI维护，强调语义理解与引文上下文，提供论文、作者、引用关系等接口；OpenAlex由OurResearch维护，定位为开放学术知识图谱，强调实体（作品、作者、机构、来源、概念）的开放元数据与稳定标识。两者的收录范围、更新节奏与字段完整度存在可观测差异，这些差异在官方文档中均有说明，属于可核验的公开信息，而非本文推测。

对文献智能体而言，这些差异直接转化为选择依据。若任务需要引文上下文或语义相似论文，Semantic Scholar的接口更贴合；若任务需要作者与机构的实体消歧、或需要开放许可与来源层级的元数据，OpenAlex的图谱结构更合适。问题在于，这些差异若未被写入Skill描述，模型无从知晓，只能依据“检索学术论文”这一共同标签做近似随机选择。

4.2 一个可复现的对照实验设计

为量化描述清晰度对选择的影响，可设计如下对照实验（本文给出方法，数据为模拟示例，标注为模拟数据）。构造两组Skill描述：A组为单段式（仅写“检索学术论文”），B组为三段式（含覆盖范围、负向边界与优先条件）。选取若干查询类型（最新预印本、引文追踪、作者消歧、元数据补全），记录模型的选择分布与任务成功率。模拟结果显示，B组在作者消歧与引文追踪两类任务上的选择一致性明显高于A组，而在存在性确认任务上两组差异不显著。

表2 描述清晰度对选择一致性的影响（模拟数据，用于说明方法，不代表真实系统指标）

这组模拟数据的意义不在于具体数值，而在于揭示一个结构性结论：描述清晰度的收益随任务对多源差异的敏感度上升而上升。对差异不敏感的任务，投入描述工程的边际收益有限；对差异敏感的任务，描述工程是必要投入。本文评述认为，这为“要不要为每个数据源单独写清楚适用场景”提供了可操作的判断依据——不是一律要写，而是按任务敏感度分层写。

4.3 拓展资源

读者可结合官方文档与公开教程进一步核验数据源差异。Semantic Scholar API文档与OpenAlex API文档均提供字段说明与速率限制说明，建议在实现前通读。此外，可参考以下公开资源进行拓展学习：Semantic Scholar API 文档、OpenAlex API 文档、Zotero Web API 教程。视频类资源可参考各平台公开的技术分享，注意核对发布时间与接口版本。

五、对比与局限：多源并置的收益、代价与边界条件

5.1 收益：覆盖度与鲁棒性

多源并置的首要收益是覆盖度。单一数据源无论规模多大，都存在收录盲区，多源并行可降低漏检概率。其次是鲁棒性：当某一数据源出现限流或故障时，路由可切换至备用源，任务不至于中断。这两点收益在工程上是实打实的，也是多源设计的主要动机。

但收益并非无条件。覆盖度的提升依赖于“源之间确实存在互补”，若两个源高度同质，并置只增加选择成本而不增加覆盖。鲁棒性的提升依赖于“切换逻辑可靠”，若切换本身依赖模糊描述，故障时反而可能切到不合适的源。本文评述认为，多源设计的收益必须与选择成本一并核算，否则容易陷入“工具越多越好”的线性思维。

5.2 代价：选择成本与评测复杂度

选择成本体现在两个层面。其一是模型侧的推理成本：候选工具越多，模型在路由阶段的注意力分配越分散，长上下文下尤为明显。其二是工程侧的维护成本：每新增一个同类工具，都需要更新描述、补充评测用例、校准路由阈值，否则新工具会成为新的歧义源。评测复杂度同样上升：多源系统的端到端评测需要区分“选错源”与“源本身无结果”，二者在指标上应分开统计。

笔者认为，这一代价结构解释了为何许多多工具系统在演示阶段表现良好、在生产阶段问题频出：演示往往只覆盖少数高频路径，而生产环境的长尾查询会持续触发路由歧义。要缓解这一问题，必须把评测从“端到端成功率”细化为“路由准确率+单源召回率”的组合指标。

5.3 边界条件：何时可以接受“差不多”

综合前文，可给出三条边界条件。第一，当任务仅需存在性确认或单篇定位时，多源差异可忽略，接受“差不多”是合理的。第二，当任务涉及系统性检索、引文追踪、实体消歧或元数据口径比较时，必须显式区分，描述工程不可省略。第三，当系统处于快速迭代期、数据源频繁变动时，应优先保证路由的可解释性与可回滚性，而非追求描述的最优化。这三条边界条件构成了后文工程方案的设计约束。

六、工程落地：Skill描述规范与路由评测闭环

6.1 描述规范：五字段最小集

建议为每个文献类Skill定义五字段最小集：能力声明、覆盖范围、负向边界、优先条件、降级策略。能力声明用一句话说清核心动作；覆盖范围说明数据源类型与更新特征；负向边界列出不适用场景；优先条件给出可判定的触发特征；降级策略指明失败时的替代工具。五字段不必冗长，但必须可判定，避免“适用于大多数场景”这类不可验证表述。

本文评述认为，五字段最小集的关键在于“可判定”。描述中的每一条都应能被转化为一个可检查的条件，否则它对路由没有实际约束力。例如“更新频率较高”应细化为“以日或更短周期更新”，这样模型才能结合查询的时间敏感性做出判断。

6.2 路由约束：从自由选择到受控选择

在工程实现上，可通过三类约束降低TSA。第一类是互斥约束：对高度同质的工具，规定同一任务上下文中只能选其一，避免并行调用造成结果冲突。第二类是优先级约束：为同类工具设定默认优先级，仅在默认工具不满足条件时才启用备选。第三类是参数归一：统一同类工具的参数命名与语义，减少参数化阶段的混淆。

# 路由约束配置示意（伪代码）
route_policy:
  retrieval:
    default: search_semantic_scholar
    fallback: search_openalex
    exclusive: true          # 同一轮不并行调用
    switch_when:
      - query.intent == "author_disambiguation"
      - query.needs_open_license == true
  param_alias:
    query: [q, search_terms, keyword]   # 统一映射

6.3 评测闭环：指标、用例与回归

评测闭环建议包含三层。第一层是路由准确率：给定标注了“期望源”的查询集，统计模型选择与期望的一致率。第二层是单源召回率：在选定源下，统计目标文献被召回的比例，用于区分“选错源”与“源无结果”。第三层是端到端任务成功率：在完整工作流中统计任务完成质量。三层指标应分开报告，避免端到端指标掩盖路由问题。

用例集的构建应覆盖前文表1中的任务类型，并按敏感度分层。回归测试应在每次Skill描述变更后运行，记录路由准确率的变化。本文评述认为，这一闭环的工程价值在于把“描述写得好不好”从主观判断转为可观测指标，使描述优化成为可持续的工程活动，而非一次性调参。

表3 三层评测指标的分工（本文整理）

6.4 操作路径：从现状到闭环的六步

第一步，盘点同类工具，按数据源与动作聚类，识别高TSA工具对。第二步，为每对工具编写三段式或五字段描述，确保负向边界可判定。第三步，配置互斥与优先级约束，统一参数命名。第四步，构建分层用例集，标注期望源。第五步，运行基线评测，记录路由准确率与单源召回率。第六步，迭代描述与约束，每次变更后回归，直至指标稳定。六步不必严格串行，但评测闭环应在描述大规模改动前建立，否则优化缺乏依据。

七、结论与展望

回到文章开头的问题：用户到底该接受“选哪个都差不多”，还是该为每个数据源单独写清楚适用场景？本文的结论是分层的。对差异不敏感的任务，接受“差不多”是合理的工程妥协；对差异敏感的任务，显式区分不是可选项，而是必要投入。判断依据不是工具数量，而是任务对多源差异的敏感度，以及描述是否具备可判定的边界。

展望后续，文献智能体的工具设计将沿着两条路径演进。一条是描述工程化：Skill描述从自由文本走向结构化契约，配合路由约束与评测闭环，形成可维护的接口体系。另一条是路由自适应：系统基于历史选择与反馈，动态调整工具优先级，减少对静态描述的依赖。本文评述认为，两条路径并不互斥，描述工程化是自适应路由的前提——没有清晰的初始边界，自适应只会放大噪声。对OmniScholar这类多工具系统而言，43这个数字本身不构成优势，真正构成优势的是这43个工具之间是否被清晰地划出了不可替代的边界。

主要参考文献