写在前面
长期做一个研究方向以后，我逐渐发现，文献检索真正耗费时间的地方并不一定是找不到论文，而是需要不断重复检索同一批内容。
刚进入一个领域时，Google Scholar、Web of Science、Scopus、Semantic Scholar 和知网已经足以完成大部分工作。输入关键词、沿着引用关系寻找经典论文，再查看近期研究，通常很快就能建立起对一个领域的基本认识。但随着研究方向逐渐稳定，情况会发生变化：常看的期刊越来越固定，关注的研究主题也趋于明确，文献检索开始从大范围探索转向长期追踪。
以管理学和金融领域为例，实际检索时可能只希望关注 ABS、FMS 或 UTD 中的一部分期刊，而不是每次都从整个数据库重新搜索。跨学科研究还可能同时涉及 CCF 计算机期刊、中文期刊以及不同学科分类。此时，反复配置期刊、年份、研究方向和关键词等筛选条件，本质上已经成为一种重复劳动。
LitRadar 最开始就是为了处理这个问题。我希望能够先维护一套真正关心的期刊集合，然后围绕这套集合完成后续的检索、更新和追踪。随着项目继续开发，需求也逐渐扩展到了 AI 文献筛选、征稿追踪、引用导出以及 API 和 MCP 接入，最终形成了现在的 LitRadar。
项目地址：QianFuv/LitRadar
0 - LitRadar 是什么？
LitRadar 是一个面向学术期刊的自托管文献检索与订阅平台。
和一般的在线学术搜索工具相比，LitRadar 更强调确定研究范围以后，对这一范围进行长期索引和持续追踪。它并不试图重新建立一个覆盖所有学术内容的大型数据库，而是允许用户先确定自己真正关心的期刊，再围绕这些期刊建立本地文献索引。
目前 LitRadar 的期刊元数据可以记录 UTD、ABS、FMS、FMSCN、CCF、学科领域、ISSN、eISSN、期刊名称以及别名等信息。因此，可以根据评级体系建立期刊集合，也可以直接维护自己长期关注的几十到几百本期刊。
在文章数据方面，英文期刊主要使用 Crossref、OpenAlex 和 Semantic Scholar 获取和补充元数据，中文期刊则提供 CNKI 数据流程。不同来源的数据会经过统一处理后存入 SQLite，并使用 FTS5 建立全文检索索引。
因此，LitRadar 的基本工作流程可以概括为：
期刊目录 → 多数据源索引 → SQLite 本地数据库 → 文献检索 → 增量更新 → 自动追踪。
这种设计和简单调用第三方搜索 API 有一个比较明显的区别：文章进入 LitRadar 后会形成自己的本地索引，因此后面的检索、收藏、追踪和 AI 筛选都可以围绕同一套数据继续进行。
1 - 期刊集合与文献索引
LitRadar 最核心的设计之一，是将期刊集合本身作为检索范围，而不仅仅是在搜索结果上增加一个期刊过滤条件。
传统数据库通常先从全部文章中搜索关键词，再通过期刊、年份和学科等条件不断缩小范围。对于临时检索来说这种方式非常方便，但如果研究者长期关注固定的一组期刊，每次重新设置相同的条件就没有太大必要。
因此，LitRadar 会先维护期刊目录。目前项目中的目录可以同时记录多种期刊评级，例如 ABS、FMS、FMSCN 和 UTD，并且支持 CCF 计算机期刊。这样可以直接按照已有的学术评价体系组织研究范围。
例如，一个管理学研究项目可以主要关注 ABS 3 星及以上期刊，同时补充 FMS 中的部分目标期刊；涉及机器学习方法时，又可以加入 CCF 目录中的相关期刊。对于不希望依赖评级体系的研究，也可以直接按照 ISSN 或期刊名称建立自定义集合。
期刊集合确定以后，LitRadar 会从对应的数据源获取文章信息。不同来源对于文章标题、作者、DOI、发布日期等字段的覆盖并不完全一致，因此 LitRadar 会先进行规范化处理，再写入本地数据库。
底层存储目前采用 SQLite。选择 SQLite 的一个重要原因是部署简单，并且对于 LitRadar 这种以读取、搜索和周期性更新为主的工作负载已经足够。文章搜索则基于 SQLite FTS5，因此不需要额外维护 Elasticsearch、OpenSearch 等独立搜索服务。
对于自托管科研工具而言，我比较倾向于这种设计：能够使用一个数据库文件解决的问题，就没有必要为了架构复杂度额外引入新的基础设施。
2 - 文献检索
完成索引以后，LitRadar 就可以直接在本地数据库中进行文献检索。
除了普通的关键词查询之外，搜索条件还可以结合期刊、学科、年份以及不同期刊评级使用。例如，在同一个查询中可以限定 ABS、FMS 或 UTD 等级，再进一步指定发表年份和领域。
因此，LitRadar 更适合固定研究范围下的重复检索。假设一个研究项目长期关注金融欺诈、表格数据和对抗鲁棒性，那么可以先固定期刊集合，以后所有关键词检索都在这个范围内完成，而不是每次重新从整个学术数据库开始搜索。
搜索底层使用 FTS5。普通模式下，LitRadar 会尽量把用户输入作为直接的文本查询处理，避免特殊字符意外改变查询逻辑；对于有更复杂需求的用户，也可以使用高级 FTS5 查询语法。
除了正文搜索，数据库还保留 DOI、PMID、期刊、年份、学科领域以及期刊评级等结构化字段。这些字段可以与全文搜索组合，因此整个检索过程并不是单纯依靠关键词匹配。
本地索引还有一个比较实际的优势，就是检索和上游数据源解耦。Crossref、OpenAlex 和 Semantic Scholar 负责提供元数据，但用户每次搜索时并不需要再次向这些服务发送请求。对于已经完成索引的数据，查询完全由本地 SQLite 完成。
这对于长期运行的科研服务来说也更加稳定。
3 - 增量更新与文献追踪
如果 LitRadar 只做到本地文献搜索，其实还没有解决最开始的问题。
真正麻烦的是，同一个研究方向需要被持续关注。研究者今天搜索了一次，一个星期以后仍然需要知道有没有新文章发表。如果继续依靠人工重新运行同样的搜索，那么本地索引只是把搜索速度提高了，并没有改变工作方式。
因此，LitRadar 对已经建立的期刊索引提供增量更新。
系统会记录已经成功完成的索引位置，后续更新时从远端最新内容开始扫描，并判断哪些文章是新增内容。相比每一次都重新扫描完整历史数据，这种方式可以显著降低日常更新成本。
对于需要检查历史回填或者重新核对完整数据的情况，也保留全量扫描模式。日常追踪和历史校验因此可以分开处理：前者重点关注新增内容，后者负责完整性检查。
增量更新产生的新文章还可以进入 LitRadar 的后续追踪流程。也就是说，文献检索不再完全依赖研究者主动发起，而是逐渐变成由系统持续维护研究范围中的变化。
我认为这也是 LitRadar 和普通搜索工具之间比较重要的区别。对于科研而言，一次搜索解决的是当前问题，而长期追踪解决的是信息更新问题。很多新论文并不是找不到，而是发表以后没有被及时发现。
4 - AI 文献推荐
自动更新以后又会出现另一个问题：如果关注的期刊很多，那么新增文章本身也可能形成新的信息负担。
因此 LitRadar 在增量更新之后增加了 AI 筛选。
用户可以配置关键词和研究方向，并接入兼容 OpenAI API 的模型服务。当新文章进入追踪流程以后，系统可以根据这些偏好进一步判断文章是否与当前研究相关。
关键词主要用于提供比较明确的主题信号，而研究方向则可以描述更加完整的研究背景。例如，同样包含 fraud 的论文可能涉及支付欺诈、保险欺诈、财务报告欺诈或者网络安全，单纯依靠关键词很难进一步区分。加入研究方向以后，模型可以结合更完整的上下文进行初步筛选。
筛选后的结果可以写入 LitRadar 中指定的追踪收藏夹，也可以通过 PushPlus 等方式进行外部通知。
这里 AI 的定位比较明确：它负责减少需要人工检查的候选文章数量，而不是替代文献阅读。论文是否具有研究价值、实验设计是否合理以及与当前工作究竟有什么关系，仍然需要研究者自己判断。
从工作流上来看，LitRadar 负责完成的是新增检测和初步筛选，而不是研究结论。
5 - Call for Papers 追踪
在长期维护期刊目录以后，我发现除了论文更新之外，还有一类信息非常适合一起追踪，那就是 Call for Papers。
很多期刊会发布 Special Issue、Special Section 和专题征稿，但这些信息通常分散在出版商页面、期刊官网、学会网站或者 PDF 中。少量期刊可以手动查看，但如果长期关注几十甚至几百本期刊，依靠人工逐个检查很难稳定执行。
因此 LitRadar 后来加入了 CFP Tracking。
CFP 追踪会围绕已有期刊目录获取对应的征稿来源，并对页面内容进行规范化处理。系统目前可以整理期刊、征稿主题、原始来源、开放状态、投稿截止日期以及相关要求等信息。
这样，原本的期刊追踪就从单纯关注已经发表的文章扩展到了两个方向：一方面查看这些期刊最近发表了什么，另一方面查看这些期刊接下来准备征集什么。
从科研使用角度来看，这两类信息其实具有一定互补性。新发表论文反映当前正在进行的研究，而 Special Issue 和 CFP 则能够提供期刊未来一段时间关注方向的参考。
因此，我现在更倾向于把 LitRadar 理解为一个围绕学术期刊构建的信息追踪平台，而不仅仅是一个论文搜索工具。
6 - 收藏、引用与外部接入
文献被搜索出来以后，通常还需要继续进入后续科研流程，因此 LitRadar 提供了收藏夹和引用导出功能。
用户可以按照研究方向、项目或者阅读状态建立不同收藏夹，再将文章分类保存。收藏内容可以导出为 BibTeX、RIS 和 EndNote 等常见引用格式，方便继续进入 Zotero、EndNote 或 LaTeX 等工作流。
这部分功能本身并不复杂，但可以减少从搜索结果到正式文献管理之间的重复操作。既然 LitRadar 已经保存了文章的 DOI、标题、作者和期刊等结构化信息，就没有必要再人工复制一次。
除此之外，LitRadar 还提供 REST API、OpenAPI、Swagger UI 和 Streamable HTTP MCP。
REST API 适合其他程序直接读取检索结果或者调用系统功能，OpenAPI 和 Swagger 用于描述和调试接口，而 MCP 则主要面向支持该协议的 AI 客户端和 Agent。
例如，AI 工具可以直接通过 LitRadar 检索特定期刊集合中的论文，再对返回结果进行摘要、分类或者进一步分析。与直接让 AI 在互联网中搜索相比，这种方式的一个优势是搜索范围已经由 LitRadar 明确限定，并且数据结构更加稳定。
因此，LitRadar 后续除了作为一个 Web 平台使用，也可以作为其他科研工具的数据入口。
7 - 部署 LitRadar
LitRadar 是一个自托管项目，目前推荐使用 Docker 部署。
首先创建用于存放部署密钥的目录，并生成一个 32 字节密钥：
1 | mkdir -p secrets |
随后拉取已经发布的镜像并启动服务：
1 | docker compose pull |
默认情况下，一个 LitRadar 实例会同时提供 Web、REST API、Swagger/OpenAPI、MCP 和任务调度能力。
项目后端主要使用 Rust 编写，前端使用 Next.js。构建时，Next.js 会生成静态资源，并最终由 Rust 服务统一提供。因此部署时并不需要单独长期运行一个 Node.js 前端服务。
LitRadar 最终主要发布一个 litradar 可执行程序，其中：
1 | litradar serve |
负责启动常驻服务，而索引、通知和其他管理操作则通过对应子命令执行。
这种设计主要是为了降低部署复杂度。LitRadar 本身已经涉及数据源获取、索引、认证、调度、Web、API 和 MCP，如果再要求用户额外维护多个微服务、消息队列和搜索集群，对于个人研究者和小型课题组来说反而会增加很多不必要的维护成本。
因此，项目内部可以保持模块化，但运行时尽量收敛成少量组件。
8 - LitRadar 适合什么？
LitRadar 并不适合替代 Google Scholar、Web of Science 或 Semantic Scholar。
如果刚开始进入一个完全陌生的研究方向，需要尽可能广泛地发现论文、作者和引用关系，那么大型学术数据库仍然是更加合适的工具。它们拥有更广泛的数据覆盖，也更加适合开放式探索。
LitRadar 更适合研究方向已经逐渐明确以后的阶段。当研究者已经知道自己关注哪些领域、哪些期刊以及哪些评级范围以后，就可以把这一研究空间固定下来，交给 LitRadar 长期维护。
从这个角度来看，大型学术搜索平台主要解决 Discovery，也就是帮助研究者发现未知信息；LitRadar 更偏向 Monitoring，负责持续观察已经确定的研究范围。
两者完全可以同时使用。前期利用大型数据库了解领域和筛选关键期刊，后期再通过 LitRadar 对这些期刊进行持续检索、更新和追踪，是我目前更倾向的使用方式。
9 - 结语
LitRadar 最开始只是一个很简单的想法：既然科研过程中经常只关注固定的一批期刊，那么为什么每次检索都要重新从整个数据库开始？
围绕这个问题，项目逐渐加入了期刊目录、本地全文索引和评级筛选；有了索引以后，又增加了增量更新；能够识别新增论文以后，进一步加入 AI 推荐；长期维护期刊以后，又顺势增加了 Call for Papers 追踪；最后再通过收藏、引用导出、REST API 和 MCP，把这些数据继续接入后面的科研工作流。
因此，LitRadar 现在真正想解决的并不是如何再造一个大型学术数据库，而是如何把已有的学术数据组织成一套更适合长期科研使用的工作流。
论文依然需要研究者自己阅读，研究方向也需要自己判断，但像期刊范围维护、新文章检测、初步筛选、征稿追踪以及文献信息整理等重复任务，本身非常适合交给程序自动完成。
如果 LitRadar 能够让这些工作少占用一些时间，把更多精力留给真正的文献阅读、实验和研究问题本身，那么这个项目的目的也就基本达到了。
GitHub：QianFuv/LitRadar