Open Academic Paper Gen（GitHub开源）

📌 工具简介

Open Academic Paper Gen 是独立开发者“猫叔”（GitHub @mmlong818）于 2026 年 10 月在 GitHub 上开源的多智能体学术论文初稿生成流水线，采用 AGPL-3.0 协议。它要解决的是 AI 写论文中最隐蔽也最致命的问题：语言模型能写出流畅的段落，却会编造参考文献，或者给一条真实存在的文献安上它从未提出过的论断，而一篇看起来引用齐全的草稿，仍可能完全不能用。这个项目选择“不信任写作模型”：先检索真实文献（有开放获取版本时抓取全文），强制草稿中的每条引用都指向文献池中的某篇论文，再从 key 可解析、DOI 与元数据匹配真实记录、被引论文确实支撑该论断三个层面逐条核验，有全文时还会标注最匹配段落所在的 PDF 页码。它的产出是一份带有可核验参考文献列表的论文初稿，定位是研究者的起点而非成品。对于苦于 AI 引用幻觉、又愿意投入技术成本自行部署的学术写作者，这是一套目前少有的“可审计”方案。

⚡ 主要功能

• 多源检索与开放获取全文：同时检索 OpenAlex、Crossref、Semantic Scholar 与 arXiv，有开放获取版本时抓取 PDF 全文而不只是摘要，为后续的全文级核验提供基础
• LLM 筛选与引用链扩展：逐篇对照研究主题筛选相关性，并沿最强论文的引用链追溯领域经典，避免只依赖关键词搜索而遗漏关键文献
• 证据表：每篇文献一行，结构化提取任务、方法、数据、指标、主要发现和局限，只依据该文献自身的文本抽取，可导出 Markdown 或 CSV，方便横向对比和后续复用
• 创新点诊断：在问题、方法、数据、视角四个层面评估研究角度，列出文献池中最接近的已有工作，并指出审稿人最可能提出的反对意见，帮助在动笔前校准创新性表述
• 分节写作与 [cite:KEY] 标记：按章节起草正文，每条引用都使用文献池中的一个 key 作为标记，使引用可以被机械核验，而不是一段无法追溯的文字
• 每条引用三道检查：key 必须可解析；DOI 与元数据必须对得上真实记录；被引论文必须确实支撑引用它的那句话。有全文时给出最匹配段落所在的 PDF 页码，从机制上压制“真文献、假论点”
• 受约束修订与重新核验：未通过检查的句子在严格规则下改写，然后重新走一遍核验流程，而不是直接放过或简单删除引用
• 模拟三审稿人审稿：三位侧重点不同的审稿人独立通读终稿，每条意见必须逐字引用原文，提供接近真实同行评议的反馈视角
• 写作风格检查：标出机器腔表达，仅作建议，不自动改写正文，把最终的文字决定权留给作者
• 导出与引用格式：支持 Markdown 或 LaTeX 导出，参考文献支持 GB/T 7714、APA 7 和数字编号三种格式，另可导出 RIS 与 BibTeX，参考文献只列实际引用且可解析的论文
• 人工审批闸门与全自动模式：每个阶段都可以暂停供审阅修改（key_gates），也可以选择整个流程无人值守跑完（full_auto），在控制力和效率之间灵活切换
• 中英文写作与文献比例可调：可分别选择写作语言，以及中文文献在文献池中所占的比例，适配不同学科和发表场景的语言习惯

💰 价格信息

Open Academic Paper Gen 本身完全开源免费，采用 AGPL-3.0 协议，不收取软件授权费或订阅费。实际使用成本来自两个部分：一是运行前后端和数据库所需的本地或服务器资源；二是模型 API 调用费用。项目支持 OpenAI 和智谱 GLM 两种模型后端，但论断核验、无引用陈述检查和模拟审稿这几个核心环节仍然需要配置 OpenAI API Key，仅使用智谱 GLM 无法完整跑通全流程。因此，使用成本在很大程度上取决于 OpenAI API 的调用量，而调用量又与文献池规模、草稿篇幅和核验轮次直接相关，长篇论文或多轮修订的 Token 消耗会明显高于短篇测试。对于有技术能力自部署的用户，这是一套“软件免费、算力付费”的模式，边际成本可控且不被 SaaS 订阅锁定；对于不愿承担 API 费用或无法访问 OpenAI 服务的用户，项目的核心核验能力会受到实质性限制。

👥 适合人群

对 AI 引用幻觉有切肤之痛、希望初稿的每一条引用都能回溯到真实文献并确认论断支撑关系的研究生和科研人员；需要撰写文献综述或论文初稿、但不愿在引用准确性上妥协的学术写作者；有技术能力完成前后端部署、愿意为“可审计的 AI 写作流程”投入配置时间的开发者型研究者；以及希望研究多智能体学术写作、引用核验机制或证据驱动生成的技术爱好者和 AI 研究者。这套工具尤其适合“引用准确性优先于生成速度”的场景——当你宁愿花时间部署和配置，也要确保 AI 不会把一篇真实论文的结论安到它从未讨论过的论断上时，它的三道核验和全文级回溯能力是多数通用 AI 写作工具不具备的。如果核心需求是零部署、打开网页就能让 AI 快速写出一篇流畅的草稿，或者无法获取 OpenAI API Key、不具备基本的 Python 和数据库操作能力，这套方案的工程门槛和 API 依赖会构成实质障碍。

✅ 优点

• 从机制上压制“真文献、假论点”：不满足于检查文献是否存在，而是在有全文时定位支撑段落并标注 PDF 页码，判断被引论文是否确实支撑引用它的那句话，直接回应了 AI 学术写作中最隐蔽的失效模式
• 三道核验 + 受约束修订形成闭环：key 解析、DOI 元数据匹配、论断支撑检查逐层过滤，未通过的句子在严格规则下改写后重新核验，而不是简单标记后放过，核验不是装饰性步骤
• 全流程透明可审计：证据表、创新点诊断、模拟审稿意见和引用核验结果都以结构化形式呈现，每个阶段可暂停审阅，AI 的推理和判断有迹可循，符合同行评议和学术诚信对可追溯性的要求
• AGPL-3.0 开源且架构完整：前后端、LangGraph 流水线、PostgreSQL 持久化和可选的 Redis 进度推送，代码公开可审计、可修改、可自托管，不被单一 SaaS 供应商锁定，对于研究者和希望深度定制的团队价值明显
• 证据表和创新点诊断具有独立价值：即使不用于生成全文，证据表的结构化提取（任务/方法/数据/指标/发现/局限）和创新点诊断（最接近的已有工作 + 审稿人可能的反对意见）也可以作为文献调研和开题准备的辅助工具单独使用
• 人工审批闸门与全自动模式兼顾控制力和效率：默认在关键阶段暂停等待确认，避免 AI 在错误方向上越走越远；需要快速测试或批量处理时也可以选择全自动跑完，使用节奏由用户掌握
• 导出格式覆盖学术写作的实际需求：Markdown 和 LaTeX 输出、GB/T 7714/APA 7/数字编号三种引用格式，以及 RIS 和 BibTeX，参考文献只列实际引用且可解析的论文，减少了从初稿到投稿格式的转换摩擦

⚠️ 缺点

• 部署门槛较高，不是开箱即用的在线工具：需要 Python 3.12+、Node.js 20+、pnpm 和 PostgreSQL 16，要分别安装后端依赖和前端依赖、配置 .env 环境变量、准备数据库，README 虽然提供了步骤但完整部署命令和环境变量说明仍需结合实际源码排查，对不熟悉全栈部署的研究者来说首次跑通需要投入可观的时间
• 核心核验环节强依赖 OpenAI API Key：论断核验、无引用陈述检查和模拟审稿必须配置 OpenAI API Key，智谱 GLM 只能覆盖部分环节。无法稳定访问 OpenAI 服务或不愿承担 API 费用的用户，项目的核心差异化能力无法完整使用，这在一定程度上削弱了“开源免费”的实际可及性
• 产出是“可核验的初稿”，不是可直接提交的论文：项目自身在 README 中明确将其定位为研究者的起点而非成品。论证的深度、学科领域知识的准确性、研究贡献的实质性判断，仍然需要作者本人完成，三道核验保证的是引用关系可追溯，不等于论文的学术质量达标
• 文献池的覆盖范围受开放获取和检索源限制：工具依赖 OpenAlex、Crossref、Semantic Scholar 和 arXiv 的开放获取全文，对于付费墙后没有开放版本的文献，只能基于摘要或元数据做有限核验，无法进行全文级论断支撑检查。在人文社科或某些依赖非开放获取期刊的领域，核验的深度会打折扣
• 项目处于早期公开阶段，部署文档和稳定性仍在迭代：README 提供了中文说明和安装指引，但完整的环境变量清单、模型提供商配置细节和容器化方案需要用户自行阅读源码和 NOTICE 文件确认，社区支持和长期维护的稳定性无法与成熟商业产品相比
• AGPL-3.0 协议对商业化和网络服务有传染性要求：如果修改后作为网络服务运行，必须向用户提供源代码。对于希望基于此构建闭源商业产品的团队，需要在合规层面做额外评估，不能简单当作 MIT 类宽松协议使用

💡 使用技巧

• 先用一个范围很窄的主题跑通最小闭环，不要一上来就处理宽泛的研究领域。选择一个你有基本判断力、文献量可控的具体问题，走完“检索→证据表→提纲→写作→核验”的完整流程，观察证据表的质量、创新点诊断的合理性以及核验标注的准确度，确认工具在你的学科场景中行为符合预期后，再逐步扩大主题范围或增加文献量
• 部署时严格对照 README 和 .env.example 逐项配置，不要跳过环境变量检查。克隆仓库后先分别执行后端 `pip install -e .` 和前端 `pnpm install`，将 .env.example 复制为 .env 并填写 OpenAI API Key 和数据库连接串。PostgreSQL 可以用 Docker 一键启动，也可以本地安装，Redis 不装也不影响单机使用，后端连不上时会自动改用内存推送进度
• 充分利用“人工审批闸门”而不是直接开全自动模式。在 Scoping、证据表生成、提纲确认和核验结果这几个关键节点暂停审阅，比让 AI 跑完再从头修改更省时间也更省 API 费用。尤其是创新点诊断环节，AI 指出的“最接近的已有工作”和“审稿人可能的反对意见”值得认真读，如果你发现它遗漏了领域内的重要工作，说明文献池的检索范围需要调整
• 把证据表当作独立的文献调研工具来用：即使你对生成全文兴趣不大，也可以单独运行到证据表阶段，导出 Markdown 或 CSV，用于自己的文献梳理和开题准备。证据表的结构化字段（任务、方法、数据、指标、发现、局限）本身就是一套不错的文献阅读模板，能帮助你快速横向对比多篇论文的研究设计
• 关注核验结果中的“未通过”标注，而不是只看最终稿。被标记的句子通常意味着引用关系存在问题——可能是 key 无法解析、DOI 与元数据不匹配，或者被引论文并不支撑那句话。逐条查看这些标注，理解 AI 在哪个环节判断失误，比直接接受修订后的结果更有助于你判断整份草稿的可信度
• 对 OpenAI API 费用有顾虑时，先用短篇主题和较小的文献池测试消耗节奏。论断核验和模拟审稿的 Token 消耗与草稿篇幅、引用数量和核验轮次直接相关，跑通一次完整流程并记录实际费用后，再决定是否将其用于长篇论文或批量任务。如果只是探索性使用，可以考虑在核验阶段之外先用智谱 GLM 完成检索和写作部分，但要对核验环节的缺失有清醒认识
• 导出 LaTeX 时优先检查参考文献格式是否符合目标期刊或学位论文的要求。工具支持 GB/T 7714、APA 7 和数字编号三种格式，但不同机构的具体排版细则可能存在差异，参考文献列表只列实际引用且可解析的论文，导出后仍需按投稿规范做一轮格式校对，不能默认“可核验”等于“格式即用”