Codex+Zotero文献管理自动化工作流配置教程

每天翻遍数据库找论文、下载PDF、导入文献管理工具，这套重复操作消耗了研究者大量时间。B站上有创作者分享了一套基于 Codex 和 Zotero 的自动化工作流，核心思路是让 AI 接管「检索—筛选—下载—入库」的完整链路。本文将拆解这套方案的原理、配置步骤和实际使用中的坑。

这套工作流到底做了什么

整个方案由三个部分组成：Skill（工作流定义）、Codex（任务发起端）、Zotero MCP 插件（实际执行端）。

据创作者介绍，你只需要告诉 AI 一个研究主题，它会自动组合关键词从外部学术数据库检索，根据标题和摘要信息筛选候选论文，核实 DOI 后去 Zotero 里查重——已有的论文和可获取的 PDF 尽量复用，没有的再下载添加。

这里有一个容易被忽略的细节：书目和附件是两回事。Zotero 里有了一条论文的标题、作者、发表信息，并不代表 PDF 已经下载好了。这套流程的目标是把两者都尽量整理到位。

MCP（Model Context Protocol）在其中扮演桥梁角色。Codex 负责发起任务，Zotero 插件提供查找文献、添加条目等工具接口，MCP 负责传递调用和结果。Skill 决定执行流程，插件提供实际能力——三者缺一不可。

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 于 2024 年底提出的一项开放标准，目的是为 AI 模型与外部工具、数据源之间提供统一的通信接口。在 MCP 出现之前，每接入一个外部服务（如数据库、文件系统、第三方应用）都需要单独编写适配代码，维护成本很高。MCP 把这些交互抽象为一套标准化协议：服务端声明自己能提供哪些「工具」（tools）、「资源」（resources）和「提示模板」（prompts），客户端（如 ChatGPT 桌面版、Claude Desktop 等）则通过统一格式发起调用。本方案中，Zotero MCP 插件就是服务端，它暴露了查找文献、添加条目、补下载附件等工具接口；Codex（这里指桌面版 ChatGPT 的智能体能力）作为客户端，根据 Skill 定义的流程决定何时调用哪个工具。理解这个分层结构，有助于排查问题时快速判断是连接层、权限层还是流程层的故障。

安装前的准备：两个文件，两个位置

需要准备两个安装包：一个是装进 Zotero 的 XPI 插件文件，另一个是交给 Codex 使用的 Skill 压缩包。两者安装位置完全不同，不要混淆。

创作者特别说明，演示使用的是适配本地 Skill 的修复版插件，而非官方 1.6.0 版本。这一点很关键，后面会解释原因。

Zotero 插件的安装方式：打开 Zotero 的插件管理页，选择「从文件安装」，选中 XPI 文件即可。如果之前装过相同插件 ID 的版本，Zotero 会提示替换。

实际测试时遇到的PDF下载问题

插件配置：三个关键开关

装好插件后需要确认已启用，然后进入插件设置。有三项配置直接决定工作流能否跑通：

第一，启用服务器。 让客户端能够连接进来，否则 Codex 无法与 Zotero 通信。

第二，启用写入操作。 如果不开这个选项，AI 只能查询文件，不能添加条目或附件。这是很多人配置后「只能查不能写」的根因。

第三，核对端口号。 创作者使用的是系统默认的 23120，这个端口号在后面配置 Codex 时必须保持一致。

另外还要去 Zotero 的常规设置里检查与 PDF 相关的选项是否勾选。走本机 MCP 插件这条路线的好处是——不需要去申请 Zotero 官网的 API Key，省去了一道繁琐的授权流程。

走本机MCP插件路线无需申请API Key

在 Codex 中接入 MCP 服务

打开桌面版 ChatGPT，进入设置，找到插件设置中的 MCP 管理，点击添加 MCP 服务器：

服务名填 Zotero
连接方式选择 Streamable HTTP
地址填入插件对应的地址（默认 23120，需与插件设置一致）

保存后重启即可。

Skill 的安装更简单——直接把压缩包拖进 Codex 的对话框，让它安装。要区分清楚：MCP 配置是建立连接，Skill 是定义工作流，两者不能互相替代。

配置完成后建议先做一次连通性测试，用提示词让 AI 实际调用一下 MCP 工具。这一步通过只能说明连接和能力已就绪，真正能否保存 PDF 还需要用实际论文验证。

Streamable HTTP 是 MCP 协议支持的一种传输方式，适合与本地或远程的常驻服务通信。它相比早期的 SSE（Server-Sent Events）方案，在连接建立、断线重连和双向消息传递上更简洁，也是目前 MCP 客户端配置本地服务时的常见选项。当你在 Codex 中选择 Streamable HTTP 并填入 http://127.0.0.1:23120 这类地址时，客户端实际上是在向本机这个端口发起 HTTP 请求，由 Zotero 插件中的 MCP 服务端响应。因此端口号必须与插件设置中的完全一致，否则会出现连接超时或拒绝连接。如果本机有防火墙或安全软件，也需确认没有拦截该端口的本地回环通信。

真实任务测试：边界条件比提示词长度更重要

创作者用「视觉检测」作为主题跑了一次完整测试，重点关注目标检测和图像分类方向，时间范围设定从 2022 年至今，上限 10 篇，Zotero 分类指定为「视觉检测文章」。

测试任务设置：目标检测与图像分类方向

这段提示词的要点不在字数多，而在把边界条件说清楚：

从外部重新检索，不要从已有 Zotero 库中挑几篇充当新结果
优先正式发表的论文
PDF 保存失败要如实报告，不要掩盖
首次运行先验证一篇，确认下载环节正常后再继续

执行流程是：先搜索筛选候选文章，确定后核实标识符并查重，然后 Zotero 按标识符添加条目并尝试获取 PDF 附件。如果已有书目但缺 PDF，就通过补下载接口用官方地址补存。

结果核验：AI 报告不能只看一句话

测试结果是 10 篇文章全部下载完成。但创作者强调，进入 Zotero 后要检查四块内容：

论文是否进入了指定分类
标题、作者、年份、DOI 信息是否完整
附件 PDF 能否正常打开
打开的 PDF 是否是需要的内容，而非缺页版

核验PDF是否为全文内容

AI 的报告也应该给出它具体检查了哪些内容。创作者展示的报告中包含了书目新增数量、实际保存的 PDF 数量、以及哪些仍待处理——这几个数据要分别看，不能只看到一句「下载成功」就放心。

原版插件的一个缺陷与修复

实际测试中创作者遇到了一个典型问题：DOI 导入成功，论文标题已进库，但 PDF 没有下载。排查后发现是 Zotero 的查询没有返回全文地址。

根因在于原先的 MCP 插件没有提供「给已有条目补下载」的工具。所以创作者在开源的 Zotero MCP 插件基础上加了一个接口——AI 核实官方 PDF 地址后，可以让 Zotero 直接给原条目补存附件。这也是为什么前面提到要使用修复版插件而非官方版本。

DOI（Digital Object Identifier，数字对象唯一标识符）是学术出版领域用于永久标识一篇文献的字符串，形如 10.xxxx/xxxxx。通过 DOI，Zotero 可以向 CrossRef 等内容注册机构查询到该文献的标题、作者、期刊、年份等元数据，并据此自动创建条目——这正是「DOI 导入成功」的含义。但元数据与全文 PDF 是两条独立的获取路径：元数据查询返回的是书目信息，而 PDF 全文地址往往需要额外的解析步骤（如通过 Unpaywall、出版社开放接口或页面抓取）。原版插件只实现了前者，所以在仅有书目信息时无法自动补全附件。修复版新增的「补下载」工具，本质上是让 AI 先定位到合法的开放获取 PDF 地址，再调用 Zotero 的附件保存接口，把文件挂到已有条目下，从而打通了从书目到全文的最后一环。

常见问题排查指南

如果你配置后遇到问题，可以按以下思路定位：

连不上：检查 Zotero 是否开着、服务端口是否一致、两端读写权限是否打开
只有书目没有 PDF：检查补下载能力是否正常，看具体错误信息
写入失败：确认插件设置中的「启用写入操作」是否已打开

创作者也明确了一个限制：不能绕过访问限制，只能下载开源文献。这套工具的目标是减少重复操作，而非替代学术数据库的合法访问。

「只能下载开源文献」这一限制背后涉及学术出版的两类获取模式：开放获取（Open Access，OA）文献经作者或机构付费后允许公众免费下载，常见于 arXiv、PubMed Central、DOAJ 收录期刊等；而订阅制文献则由出版社通过 IP 识别、机构登录或付费墙控制访问。这套自动化工具只能访问前者公开可得的 PDF 地址，遇到付费墙时无法绕过——这既是技术边界，也是合规边界。对于订阅制文献，研究者仍需通过所在机构的图书馆订阅、馆际互借或直接联系作者获取。把工具定位为「减少重复操作」而非「替代合法访问渠道」，才能在日常科研中安全、可持续地使用。

小结

这套 Codex + Zotero 工作流的价值在于把文献检索、筛选、入库和核验串成一条自动化链路。配置本身不复杂，但几个关键点——端口一致性、写入权限、修复版插件的补下载能力——决定了它能否真正跑通。建议先用一个小任务验证全流程，再扩展到自己的研究主题。