有用户建立了literature review skill但“非OA论文太多、在文献检索和本地文献读取之间无法自动衔接、只能手动下载”，当Codex+Skills的自动链路在“付费墙”面前断开时，科研人到底该把Skill定位成“OA文献的自动化工具”、还是继续在“自动发现→手动获取→自动精读”的混合流程里拼？

目录

一、问题的重新定义：断点不在"下载"，而在"状态"

先把现象描述准确。用户所说的"无法自动衔接"，字面上是"检索结果拿不到 PDF"，但工程上真正导致链路失效的并不是文件缺失，而是状态丢失：检索阶段产出的候选集合、每条候选的元数据、已尝试过的获取渠道、失败原因、以及"这条记录现在处于流程的哪一步"，在人工介入之后没有被持久化，于是自动化恢复时无从判断该从哪里继续。文件只是状态的物化结果，状态才是链路的骨架。

这个区分决定了后续所有设计。如果问题被定义为"下载失败"，解法自然是"多找几个下载源"；如果问题被定义为"状态断裂"，解法就变成"设计一个能容纳人工节点的流程引擎"。本文评述：绝大多数关于 Skill 定位的争论，其实是在用第一种定义讨论第二种问题，因此永远谈不拢——一方说"再多接几个 OA 源就能自动"，另一方说"我的领域一半文献在 Elsevier 和 Wiley 后面，接多少源都没用"，两边都没错，但都没触及要害。

由此可以给出本文的分析主线：Skill 的价值不在于消除人工，而在于把人工动作从"流程外的手工劳动"转化为"流程内的显式节点"。沿着这条主线，后文依次回答四个问题：现有生态能自动到什么程度（第二节、第三节）、剩下的部分如何建模（第四节、第五节）、不同定位方案的实测取舍（第六节）、以及边界与失败模式（第七节）。

一句话概括本文立场：不要把 Skill 做成"OA 文献的自动化工具"，那是在给自己设天花板；也不要在混合流程里靠人肉拼，那是在放弃工程化。正确做法是把 Skill 做成带人工交接点的流程编排器，让 OA 部分全自动、非 OA 部分半自动、整条链路状态可恢复。

二、背景与概念澄清：Skill、Codex 与文献获取的既有格局

2.1 三个概念的精确定义

Skill（技能）：在 Codex 类智能体框架中，Skill 指一组以文件形式组织的指令、脚本与资源包，智能体在运行时按需加载，用于把某类重复性任务的操作知识固化下来。它不同于函数调用（function calling）——后者是单次、无状态的接口调用，而 Skill 通常包含多步骤流程、约定俗成的目录结构与可被智能体读取的说明文档。本文讨论的 literature review skill，本质上是"文献综述任务的操作知识封装"。

Codex：此处指具备代码执行与文件系统访问能力的智能体运行环境，其关键特征是可以在本地执行脚本、读写文件、调用外部命令。这一特征决定了 Skill 能做什么——凡是能写成脚本的动作都能自动，凡是需要浏览器会话、机构身份或人工判断的动作都难以完全自动。

OA（Open Access，开放获取）：按 BOAI（2002）的定义，指文献在公共互联网上可被免费阅读、下载、复制、分发、打印、检索、链接至全文、爬取用于索引、作为数据传递、用于软件处理，除访问互联网本身之外不受财务、法律或技术障碍限制。需要强调，OA 是一个法律状态而非技术状态：一份 PDF 能被下载，不等于它是 OA；反过来，某些 OA 文献因站点反爬而难以程序化获取。这个区分在后文的合规讨论中至关重要。

2.2 文献获取生态的既有分工

当前可程序化获取全文的渠道大致分为四类，各有明确的覆盖边界。第一类是出版商自身的 OA 内容，包括完全 OA 期刊（如 PLOS、eLife、MDPI 旗下刊物）与混合期刊中的 OA 文章；第二类是机构仓储与预印本平台，如 arXiv、bioRxiv、SSRN、各高校机构库；第三类是聚合型合法渠道，如 Unpaywall、OpenAlex、CORE、DOAJ、PubMed Central；第四类是作者自存档与学术社交网络，这一类的法律状态最复杂，需逐条判断。

与之相对，订阅制内容（Elsevier ScienceDirect、Wiley Online Library、Springer Nature Link、Taylor & Francis、IEEE Xplore、ACM DL 等）在无机构订阅的情况下，程序化获取会触发登录、验证码或直接返回 403。这不是技术缺陷，而是访问控制的设计意图。本文评述：把这一层当作"待攻克的技术难题"是方向性错误，它属于授权问题，任何绕过手段都会把工程问题转化为合规问题，得不偿失。

三、OA 覆盖度的真实数据：自动化上限在哪里

要判断"OA 自动化工具"这一定位是否可行，必须先量化 OA 覆盖率。这里引用公开可查的统计，并明确标注口径，避免把不同定义的数字混用。

上表的关键含义是：即便把 Unpaywall、OpenAlex、CORE、PMC 全部接上，仍有相当比例的目标文献无法程序化获取，且这一比例在订阅主导的学科里更高。这意味着"OA 自动化工具"这一定位在数学上就存在天花板——它不是一个可以靠工程优化逼近 100% 的目标，而是一个结构性的覆盖率约束。笔者认为，任何声称"接满 OA 源就能全自动"的方案，都隐含了一个未经检验的假设：用户的文献集合以 OA 为主。这个假设在人文学科、部分社会科学与预印本文化浓厚的领域（如 ML、物理）可能近似成立，但在生物医学、材料、工程等领域大概率不成立。

更细致的一层是"OA 但不可程序化获取"的情况：部分 OA 期刊站点部署了 Cloudflare 等反爬机制，程序化请求会被拦截；部分机构仓储要求 JavaScript 渲染；部分 PDF 链接是动态生成的临时地址。这些情况在技术上属于"可获取但难自动化"，与"法律上不可获取"是两回事，处理策略也应不同——前者可以尝试官方 API 或元数据中的直链，后者只能走人工或授权渠道。

四、技术路线：把人工动作建模为可编排节点

4.1 链路拆解：七个可独立寻址的阶段

把文献综述流程拆成可独立寻址、可独立重试的阶段，是让状态可恢复的前提。笔者建议的最小拆解如下：

P1 查询构造   query → 检索式（含同义词、字段限定、时间窗）
P2 检索执行   query → 候选集（DOI/标题/年份/来源）
P3 去重归一   DOI 归一化、标题模糊匹配、版本合并
P4 相关性筛选 标题+摘要打分 → 保留/剔除/待定
P5 全文获取   DOI → OA 直链 → 下载 → 校验（PDF 魔数、页数）
P6 精读抽取   结构化抽取（问题/方法/数据/结论/局限）
P7 综述合成   证据表 → 主题聚类 → 矛盾点识别 → 成文

这七个阶段里，P1–P4 与 P6–P7 可以完全自动化（P4 的"待定"需要人工复核，但可批量处理），P5 是唯一必然出现人工介入的阶段。本文评述：把 P5 单独拎出来，是整个设计的关键一步——它把"整条链路断掉"转化为"一个阶段需要人工"，前者是流程失败，后者是流程特性。这一转化看似只是表述差异，实则决定了后续所有工程决策：如果 P5 是流程特性，那么它就应该有输入输出契约、有超时与重试策略、有失败原因分类，而不是一个"用户自己想办法"的黑洞。

4.2 状态机设计：让每条文献记录自带"当前位置"

每条候选文献在流程中应携带一个显式状态，状态之间允许的迁移是有限的、可枚举的。这是把人工动作纳入自动链路的载体。

这个状态机的设计要点有三。其一，NEEDS_MANUAL 与 MANUAL_PENDING 必须分开：前者是"系统判定需要人工"，后者是"人工任务已发出、等待回执"，两者混用会导致重跑时重复生成任务单。其二，SKIPPED 是合法终态而非失败：综述写作中主动排除某些文献是正常操作，必须能记录排除理由，否则后续无法复现筛选逻辑。其三，所有状态迁移都要落盘，且以 DOI 为幂等键，这样中断后重跑不会产生重复记录。

4.3 人机交接点：任务单与回执

把人工动作纳入流程的具体形式，是"任务单（ticket）+ 回执（receipt）"。系统在 NEEDS_MANUAL 状态下生成一份结构化任务单，包含 DOI、标题、作者、期刊、年份、已尝试的渠道与失败原因、以及建议的获取途径（机构订阅、馆际互借、作者主页、ResearchGate 询问等）。人工完成获取后，把 PDF 放入约定目录，或填写回执文件，系统扫描到回执后把状态推进到 FETCHED。

这个机制的工程价值在于：它把"人工"从不可观测的黑盒变成了可观测的节点。任务单的生成数量、平均回执时延、按渠道统计的成功率，都成为可优化的指标。本文评述：很多团队抱怨"混合流程拼不起来"，根因往往不是自动化不够，而是人工环节没有留下任何结构化痕迹，导致每次重跑都要从头判断"哪些已经下过了"。任务单机制的成本很低——一个 CSV 或 JSON 文件即可——但收益是让整条链路具备可恢复性。

五、工程实现：状态机、队列与回执的具体写法

5.1 目录结构与 Skill 组织

Skill 的目录结构应体现"指令与状态分离"的原则：指令（SKILL.md 及脚本）是可版本管理的静态资产，状态（队列、回执、抽取结果）是运行时产物，两者不应混在同一目录。一个可用的组织方式如下：

lit-review-skill/
├── SKILL.md              # 智能体读取的操作说明与约束
├── scripts/
│   ├── search.py         # P1-P2 检索执行
│   ├── dedupe.py         # P3 去重归一
│   ├── screen.py         # P4 相关性筛选
│   ├── fetch_oa.py       # P5 OA 渠道尝试
│   ├── make_tickets.py   # P5 生成人工任务单
│   ├── ingest.py         # P5 扫描回执并推进状态
│   └── extract.py        # P6 结构化抽取
├── state/
│   ├── records.jsonl     # 每条文献一行，含状态与历史
│   ├── tickets/          # 待人工处理的任务单
│   └── receipts/         # 人工回执
└── corpus/               # 本地 PDF，按 DOI 命名

SKILL.md 里应写清楚三件事：每个脚本的输入输出契约、状态迁移的允许规则、以及"遇到付费墙时不得尝试绕过"的硬约束。第三条尤其重要——它既是合规要求，也是防止智能体在失败时"自作聪明"乱试的护栏。

5.2 OA 获取的渠道级联

P5 的自动化部分应实现为渠道级联：按成本从低到高依次尝试，任一渠道成功即停止。一个务实的顺序是：本地缓存 → Unpaywall（按 DOI 查 best_oa_location）→ OpenAlex（OA 字段）→ PMC（生物医学）→ arXiv/bioRxiv（预印本）→ CORE（聚合仓储）。每一级都要记录尝试结果，失败原因分类为"无 OA 记录""有记录但链接失效""有链接但被反爬拦截""需登录"等，这些分类直接决定任务单里给人工的建议。

# 渠道级联的伪代码（示意，非可直接运行）
def fetch_oa(doi):
    for ch in [cache, unpaywall, openalex, pmc, preprint, core]:
        r = ch.lookup(doi)
        if r.url and safe_download(r.url, verify_pdf=True):
            return OK(ch.name, r.url)
        log(doi, ch.name, r.reason)   # 记录失败原因
    return NEEDS_MANUAL(reasons=log_of(doi))

这里有一个容易被忽略的细节：下载后的校验。不少"成功下载"其实是 HTML 登录页或错误页被存成了 .pdf，后续精读阶段才发现无法解析。校验至少应包含 PDF 魔数（%PDF-）、可解析页数、以及文本层是否为空（扫描版需 OCR）。本文评述：校验环节的成本极低，但能避免大量"看起来成功、实际失败"的隐性错误，是混合流程可靠性的重要一环。

5.3 回执扫描与幂等推进

ingest 脚本的职责是扫描 receipts 目录，把回执与任务单匹配，推进状态。幂等性的实现方式是：以 DOI 为键，若记录已处于 FETCHED 及之后的状态则跳过；若回执中的 DOI 在 records 中不存在则报警而非静默丢弃。回执格式建议用最简的键值对，降低人工填写负担：

doi: 10.1000/xyz123
status: fetched          # fetched | skipped
file: corpus/10.1000_xyz123.pdf
channel: institution      # institution | ill | author | other
note: 通过校图书馆订阅获取

回执机制的另一个用途是统计与优化：按 channel 聚合可以算出"机构订阅覆盖了多少、馆际互借平均耗时多少、作者主页成功率多少"，这些数字反过来指导检索策略——比如某个主题的文献大量需要馆际互借，就应在检索阶段提前放宽 OA 过滤，避免把时间浪费在注定要人工的条目上。

5.4 精读阶段的批处理与证据表

P6 的结构化抽取应输出统一的证据表，字段至少包括：研究问题、方法类型、样本/数据来源、主要结论、局限性、与本文主题的关系。批处理时按 token 预算分批，每批完成后落盘，避免长任务中断导致全部重来。抽取结果与原文页码的对应关系应保留，便于后续核查——这是综述可复现性的基础，也是防止模型幻觉的一道检查。

六、关键案例与对比：三种定位方案的实测取舍

围绕"Skill 该定位成什么"，实践中存在三种典型方案。为避免空谈，下面用一组可复现的模拟数据做对比——数据来源标注为模拟，仅用于说明量级关系，不作为实证结论。

方案 A 的问题在第三节已经论证：覆盖率天花板决定了它无法服务订阅主导领域的用户。方案 B 的问题不在技术而在合规：绕过访问控制违反出版商服务条款，且在实际运行中极不稳定——验证码、IP 封禁、会话过期会让"自动化"变成"反复调试"。方案 C 的代价是设计复杂度，但收益是链路可恢复、人工可预估、合规边界清晰。

本文评述：三种方案的差异本质上是对"人工"的态度。A 把人工排除在系统之外，B 试图消灭人工，C 把人工纳入系统。从软件工程史看，凡是把必要的人工环节排除在系统外的设计，最终都会在运维阶段付出更大代价——因为人工不会消失，只会退化为不可观测的例外处理。文献获取正是这样一个环节：付费墙是结构性的，人工是必要的，把它建模进流程是唯一可持续的选择。

还有一个常被忽略的维度是时间成本分布。在方案 A 下，用户的时间花在"发现哪些没下到、逐个去找"上，这部分时间不可预估、不可批量；在方案 C 下，用户的时间花在"集中处理一批任务单"上，可以批量、可以预估、可以委托。两者的总时长可能相近，但后者对科研工作者的认知负担显著更低——这一点在长周期综述项目中尤为关键。

七、局限、合规边界与失败模式

7.1 合规边界

必须明确：Skill 不得实现或鼓励绕过付费墙、破解 DRM、使用未授权账号批量下载。这些行为违反出版商服务条款，在多数司法辖区还可能触及著作权法中的技术措施保护条款。合规的做法只有三条：使用机构订阅（通过正常登录）、使用馆际互借、联系作者索取。Skill 能做的是把这三条路径的建议生成到任务单里，而不是替用户执行。

另一条边界是元数据与全文的区分。检索、去重、筛选所依赖的元数据（标题、摘要、作者、DOI）通常可以合法获取与缓存；全文的批量下载与本地存储则受各来源条款约束。Skill 在设计上应把元数据层与全文层分开处理，前者可自由缓存，后者按来源分别遵守条款。

7.2 典型失败模式

第一类是幂等性缺失：重跑时重复生成任务单、重复下载、状态回退。根因是状态未落盘或以非稳定键索引。第二类是假成功：下载到登录页、错误页、空 PDF，直到精读阶段才暴露。根因是缺少下载后校验。第三类是渠道级联无终止：某个渠道超时未设上限，拖垮整批任务。根因是缺少超时与并发控制。第四类是抽取幻觉：模型在全文缺失或截断时编造结论。根因是未强制要求页码溯源与"无依据则标注未知"。

这四类失败模式的共同点是：它们都不是模型能力问题，而是流程设计问题。本文评述：把文献综述 Skill 的可靠性寄希望于"模型更强"，是方向性误判；真正决定可靠性的是状态管理、校验与边界约束这些"不性感"的工程细节。

7.3 适用边界

混合编排方案并非万能。对于文献量极小（十余篇）的快速调研，搭建状态机的成本高于收益，直接手工更快；对于 OA 文化浓厚的领域（如高能物理、机器学习），方案 A 的覆盖率已足够高，额外复杂度未必值得；对于需要严格系统综述方法学（如 PRISMA 流程）的项目，人工筛选与双人复核是方法学要求，不能由自动化替代，Skill 只能承担记录与流程管理的角色。这些边界条件应在 Skill 的说明文档中明确写出，避免用户误用。

八、结论与展望

回到最初的问题：Skill 该定位成"OA 文献的自动化工具"，还是继续在混合流程里拼？本文的答案是：两者都不是，而应定位为"OA 自动化 + 混合流程编排器"的双层结构。OA 层追求尽可能高的自动化率，混合层把不可自动化的人工动作显式建模为带契约的节点。这个定位既承认了付费墙的结构性存在，又没有放弃工程化——它把"断链"从失败转化为特性，把人工从黑洞转化为可观测、可批量、可优化的环节。

从更长的视角看，这一思路与科研工作流工具的发展方向一致：Zotero、PRISMA 流程图工具、系统综述管理平台，走的都是"把方法学步骤显式化、把人工判断留痕"的路线，而非追求全自动。文献综述的本质是判断密集型工作，自动化能承担的是检索、去重、抽取、汇总这些机械环节，判断环节必须留给人，但可以被人机交接机制高效地组织起来。

展望未来，有两个方向值得关注。其一是OA 覆盖率的持续变化：S 计划、Plan S 及各国开放科学政策的推进，正在改变各学科的 OA 比例，Skill 的渠道级联应保持可配置，以便随覆盖率变化调整策略。其二是智能体对长流程的原生支持：若运行环境开始原生提供持久化任务队列与人工审批节点，本文所述的不少工程细节可以下沉到框架层，Skill 只需声明流程与契约。在那之前，自己实现一套轻量的状态机与回执机制，是成本最低、收益最直接的选择。

主要参考文献