Open Paper — 用 AI 重新定义论文阅读方式

你有没有过这样的经历：读一篇顶会论文，读到第三页就忘了第一页在说什么；导师丢给你 50 篇参考文献让你一个月内搞定文献综述，你盯着 PDF 标注软件发了半天呆；好不容易读完一篇想做个笔记，回头却找不到自己标注过的那句话在哪里。这类问题，几乎每个做科研的人都遇到过，但很长时间里，没有一个工具能真正把「读论文」这件事从头到尾管理好。

Open Paper（khoj-ai/openpaper）就是来解决这个问题的。它是一个开源的 AI 论文工作台，把 PDF 上传、AI 摘要生成、标注笔记、文献问答全部整合到一个 Web 应用里。作者 sabaimran 最初是为自己写的——读论文时总要在多个工具之间来回切换，让他不胜其烦，于是决定自己动手。

图1：AI Copilot 界面，实时问答并附带论文内引用来源

核心功能：五个模块，覆盖论文阅读全流程

Open Paper 的功能设计非常务实，围绕一个明确的用户旅程展开：上传 PDF → AI 生成摘要和问题引导 → 分屏阅读+标注 → AI 问答 → 知识库检索。

1. AI 摘要与引导问题

上传 PDF 后，系统会调用 Gemini（或其他大模型）自动生成论文摘要，并给出几个「starter questions」——帮助你快速定位论文的核心贡献。这解决了论文阅读的第一个痛点：面对一篇 15-20 页的 PDF，不知道从哪切入。在学术阅读中，有个「领读人」往往比直接自己啃要高效得多。

AI 生成的摘要会配上具体的引用位置标注，点击后直接跳转到原文中对应的段落，实现「摘要溯源」。这种设计在当前的 AI+PDF 工具中并不常见，大多数产品只给出泛泛的总结，无法对应到原文的具体位置。

2. 分屏阅读（Parallel View）

这是 Open Paper 最具差异化的功能。大多数 AI 论文阅读工具（如 ChatPDF）只提供一个对话框，让你在对话窗口里和文档聊天，但 Open Paper 保留了原文档的分屏视图——左边是 PDF 原文，右边是 AI 摘要/笔记/聊天窗口，可以同时看到文档内容和 AI 的解读。

这种设计理念很清晰：AI 是辅助理解工具，不是替代阅读。做科研的人不会因为有了 AI 就不读原文，而是需要 AI 帮助快速提炼、解释和关联。分屏设计让这个工作流变得自然。

3. 标注与笔记系统

选中 PDF 中的任意文字，可以弹出标注菜单：添加高亮、评论、笔记。所有标注都在上下文语境中保存，笔记支持 Markdown 格式，还可以通过顶部的 toggle 切换查看方式。这套标注系统与 Zotero（主流学术文献管理工具）打通，支持自动同步——这是面向真实学术工作流的实用功能。

4. AI 文献问答

基于上传的多篇论文构建知识库，可以跨文档提问。AI 会根据问题在各篇论文中检索相关段落，给出带引用的回答，并标注来源。引用格式可点击，直接跳转到对应论文的具体位置。这是文献综述场景的核心功能——当你需要快速了解「XX 方法和 YY 方法有什么异同」时，不需要逐一打开每篇 PDF，直接问 AI 就行。

5. 知识库检索

当你上传了大量论文后，可以用自然语言或关键词检索知识库，快速定位特定主题的论文、标注和笔记。这解决了「读完了，但回头找不到」的长期记忆问题。

图2：多论文问答架构流程图，AI Agent 通过搜索、读文件等工具在论文语料中检索证据

技术架构：微服务拆分，兼顾开发效率与可扩展性

Open Paper 采用了 三服务分离架构：

• Server（FastAPI）：核心 API 服务，处理认证、文件上传、数据库操作、LLM 调用。采用 Python 3.12 + FastAPI + SQLAlchemy + PostgreSQL，部署在 Gunicorn 上。
• Client（Next.js 15）：全栈 Web 前端，采用 Next.js 15 App Router + TypeScript + Tailwind CSS + shadcn/ui 组件库。前端 UI 非常现代，大量使用 Radix UI 的无障碍组件。
• Jobs（Celery）：异步任务处理服务，通过 Redis + RabbitMQ 消息队列驱动，负责 PDF 解析、OCR、元数据提取等重量级操作，HTTP Webhook 与 Server 通信。

三服务之间通过 REST API 和 Celery 消息队列协同：Server 接收上传请求后将任务入队，Jobs Worker 消费任务完成 PDF 处理后通过 Webhook 通知 Server，最终 Server 通知 Client 轮询状态。

AI 集成方式

Server 层同时支持多个 LLM Provider：Gemini（主力）、OpenAI GPT-4、Anthropic Claude，以及专门的搜索服务 Exa。这种多模型架构保证了不同场景下的灵活性——长上下文摘要用 Gemini，复杂推理用 Claude。

AI 问答的 Agent 架构设计值得参考：Multi-paper Agent 通过 search_file / read_file / read_abstract / search_all_files 等工具迭代式检索证据，当证据量过大时自动 compact，最终将压缩后的证据 + 问题发给 LLM 生成回答并解析引用格式。

存储与文件处理

PDF 文件和解析后的 assets 上传到 S3（支持 AWS S3 和 Cloudflare R2），元数据存 PostgreSQL，标注数据通过 Alembic 管理数据库迁移。PDF 渲染使用 react-pdf + react-pdf-highlighter-extended，实现了原文与标注的一体化展示。

图3：分屏阅读视图，左侧 PDF 原文，右侧笔记/AI 对话

部署评估

README 中作者明确写道：「Open Paper 是开源的，但没有针对自托管优化，我们的主要精力放在做最好的 AI 辅助研究工具上。」这句话是诚实的——部署确实有一定门槛：

• 需要同时启动 3 个服务（Server + Client + Jobs）
• 依赖 PostgreSQL + Redis + RabbitMQ（通过 Docker 部署）
• 需要申请 Google AI API Key（Gemini）
• 需要配置 S3/R2 存储桶
• 没有提供一键部署脚本，需要手动配置环境变量

好消息是 Server 层提供了 Dockerfile，基于 python:3.12-slim-bookworm，支持容器化部署。可以基于此 Dockerfile 自行编写 docker-compose.yml 整合三服务。

图4：标注系统，支持高亮、评论和笔记，笔记支持 Markdown 格式

局限与争议

• 自托管门槛高：无 docker-compose、无一键脚本，非 DevOps 用户部署困难。
• 纯付费模式：前端集成了 Stripe，支持 SaaS 订阅。开源版的核心功能与付费版可能存在差异（README 暗示了这一点）。
• AI 引用精度：基于字符串匹配的引用定位逻辑目前「不完美（imperfect）」，在复杂排版论文中可能出错。
• 仅支持 PDF：无法处理其他学术文献格式（如 LaTeX 源码、EPUB）。

行业意义

Open Paper 代表的趋势是 AI 原生的学术工作流工具。传统的文献管理器（Zotero、Mendeley）主要解决「收集和管理」问题，而 Open Paper 进一步解决了「理解和提炼」问题。当 AI 能够「阅读并理解」论文内容时，文献综述的效率将发生质变——从逐篇阅读到跨库问答，这是传统工具无法实现的工作方式。

项目由 Khoj AI 团队维护（khoj-ai 组织），在 GitHub 上有活跃的开发记录，支持 AGPL-3.0 协议。对于希望深度定制或研究 AI + PDF 技术栈的开发者，这个项目是很好的参考样本。