先分清两种情况：一是助手根本没有发起检索，二是检索发起了但参数或数据源对不上。判断顺序建议固定为三步——用一次必然会触发检索的提问拿到基准返回，去助手侧查有没有调用记录，最后把请求里的检索参数和实际返回逐项对照。跳过其中任何一步，改配置就只能凭感觉。下面的做法都只依赖你能看到的配置、日志和返回体，不需要额外工具。

ScholarMuse 查不到论文时，不要先调检索参数。先用一条明确要求检索的提问确认助手是否真的发起了检索：回答里没有任何引用条目、助手侧也没有 tool 调用记录，问题在意图路由或工具注册，不在检索配置；有调用记录但返回为空或报错，才进入参数与数据源对照。每一步的判断都应以日志字段或返回体为准，不确定时先保留原配置并记录一次改动。

先构造一个一定会触发检索的问题

宽泛提问最容易造成假阴性。类似“帮我看看最近有什么好论文”这类输入，助手完全可以用自身知识回答，也可以判定为闲聊，不进入检索分支，于是你会误以为检索坏了。构造基准问题时要满足三个条件：明确出现“检索/查找论文”的动词，给出可判定的主题词，限定一个具体条件（年份区间、期刊或作者），并要求只依据检索结果作答。

请检索 2020 年以后关于“检索增强生成在学术问答中的应用”的论文，
列出标题、作者、年份和 DOI。只引用本次检索到的条目，
检索不到就明确说“检索无结果”，不要用记忆补充。

这条提示可以直接粘到助手对话框里执行，也可以作为接口调试的固定输入。最后那句“检索不到就明确说无结果”很关键：它把“没查到”和“编不出来”分开了，避免助手用记忆生成几条看起来像真的文献。

确认检索是否真的发生，看返回里有没有可核验的痕迹：回答正文是否带有条目化的标题、作者、年份、DOI 或链接；接口返回里是否有引用字段、来源列表、检索耗时；启用调试模式时是否出现检索步骤的中间输出。只有模型自己写的一段话、没有任何条目，通常说明检索没有发生，而不是检索结果为空。

看助手侧有没有留下调用记录

这一步只回答一个问题：请求有没有离开助手。调用记录通常出现在三个位置——助手服务端的应用日志（记录意图判定与工具调用）、工具或插件的执行日志（记录实际请求与响应状态）、以及浏览器开发者工具的网络面板（若前端直连检索接口）。日志路径各环境不同，建议先用关键字过滤，再定位文件。

grep -iE "tool_call|retriev|search|scholar" app.log | tail -n 50

需要关注的字段：request_id 或 trace_id（用于和前端请求对齐）、tool_name（是否为目标检索工具）、调用参数（查询词、时间范围、语言、条数）、返回状态码与耗时、返回条目数。缺其中任何一项，说明日志级别不够，先把该工具的调用日志开到能输出参数与返回状态的程度，再复现一次。

如果完整复现一次后，日志里连一条对应的 request_id 都没有，通常可以得出一个结论：请求没有到达检索环节。常见原因是工具没有注册到助手的可用工具列表、意图路由未命中检索分支、或前端请求打到了另一个实例。此时改检索参数没有意义，先修注册与路由。

把检索参数逐项和实际返回对照

有调用记录但结果为空，才轮到参数对照。逐个确认每个参数的实际发送值和它的含义：查询词是否被改写或截断、时间范围是闭区间还是开区间、语言过滤是否把中文文献排除、返回条数是否被设成极小值、数据源或索引名是否指向了空库、分页偏移是否超出了结果总量。

常见错配集中在三处：时间范围写成未来区间或倒序、语言字段填了数据源不支持的代码、返回条数被默认值压到 1 或 0。这些错误都不会报错，只会安静地返回空列表。

填这张表时用同一次请求的数据，不要混用多次调试结果。每一行只保留一个变量差异，改一项、复现一次、记录一次返回，否则无法判断是哪一项生效。

读一遍错误返回再决定改哪一项

错误返回决定改动方向，先分类再动手。鉴权失败通常表现为 401 或 403，返回体内提到 key 无效、过期或无该数据源权限；下一步动作是核对密钥的生效范围与数据源授权，而不是放宽查询条件。请求超时表现为超时异常或连接被中断，日志里耗时接近你设置的阈值；下一步动作是缩小时间范围、降低返回条数、确认出口网络可达，再考虑调高超时值。空结果则是 200 状态但条目为零，返回体结构完整；下一步动作是回到上一节的对照表，逐项排查过窄参数与数据源指向。

三类返回的改法互不通用：把鉴权失败当成空结果去放宽条数，只会继续报错；把空结果当成超时去加大超时，只会白等。建议每次只改一项，并在日志里记下改动前后的 request_id 与返回条目数，方便回退。改动范围确认收敛之前，不要同时调整路由、参数和数据源配置。