Agentic Publication Protocol: 科学出版现代化的尝试

# 代理出版协议：科学出版现代化的一次尝试  
来源：https://arxiv.org/html/2606.27386  

陆思锐¹² 和 祁晓亮³,∗  

¹马克斯·普朗克量子光学研究所，加兴，德国  
²慕尼黑量子科学与技术中心 (MCQST)，Schellingstrasse 4, D-80799 慕尼黑，德国  
³莱因韦伯理论物理研究所，斯坦福大学，斯坦福，加利福尼亚州，美国  

∗[email protected]  

###### 摘要  

科学出版仍主要围绕静态手稿组织，尽管大部分科学进步依赖于隐性操作知识：如何运行代码、复现图表、解释边界情况、选择有用的后续方向以及避免失败路径。大语言模型智能体创造了一个机会，不仅可以发布知识，还能以未来读者和研究者可直接使用的形式发布操作专有技术。本文概述了代理出版协议（Agentic Publication Protocol, APP），这是一种轻量级仓库格式，用于将论文与代码、数据、环境信息、可复现性说明以及面向智能体的指令文件打包在一起。APP 将版本控制的仓库视为出版物对象，并使用 `AGENTS.md` 和可选的技能来定义一个论文智能体，该智能体能够解释工作、尽可能复现关键结果，并支持后续研究。我们描述了协议的设计原则和细节，以及用于在该协议下发布论文的智能体技能。我们还介绍了用于评估和改进协议及相关智能体技能的工具。最后，我们对智能体时代科学研究的未来进行了更广泛的讨论。  

## 1 引言  

科学研究是一个长期的、涉及整个研究社区的协作过程。在当前研究范式下，科学论文是分享发现的主要媒介。此外，它们还扮演着另外两个重要角色。发布和发表论文是确立优先权和功劳的主要方式。论文影响力是评价和奖励研究者的主要指标之一。同行评审、期刊出版和引用都围绕论文作为中心学术对象而构建。然而，静态的论文格式长期以来因其诸多局限性而在不同领域受到批评。具体来说，它存在以下问题，给研究过程带来摩擦和负担：  

1. **信息的有限、静态呈现**。论文格式僵化且静态。它只能针对特定读者群体。例如，发表在专业期刊上的论文可能对子领域之外的读者难以理解，而发表在综合期刊上的论文可能强调对更广泛受众有吸引力的总体思路，但相应地牺牲了技术精确性和详细信息。  
2. **无法更新**。一旦发表或发布，论文便难以更新。对读者有用的改进或更正只有在足够重要时才能通过新版本进行。来自读者的改进建议只能由作者手动采纳。在当前系统中，作者往往缺乏足够的动力去更新论文。尤其是论文在期刊上发表后，除发布勘误或新的后续论文外，无法进行此类更新。相比之下，GitHub 上的开源项目可以由作者轻松更新，并通过整个社区的贡献得到改进。  
3. **缺乏可复现性**。许多论文未提供足够的信息来复现关键结果，例如代码、数据、环境细节或说明[4 (https://arxiv.org/html/2606.27386#bib.bib22),39 (https://arxiv.org/html/2606.27386#bib.bib23)]。这使得读者难以验证其主张、在此基础上开展工作或学习方法。即使在期刊数据共享政策下，一项对《科学》论文的研究中，仅能获取 44% 论文的工件，且仅能复现 26% 的主要发现[49 (https://arxiv.org/html/2606.27386#bib.bib24)]。即使对于附带代码和数据的论文，复现过程也可能相当繁琐，需要读者花费大量时间和精力去理解代码、搭建环境并运行脚本。这为后续研究设置了高门槛，减缓了科学进步。  
4. **缺失操作专有技术**。论文可能描述项目的最终结论，但往往省略了在此基础上开展工作所需的操作知识：哪些脚本实际生成哪些图表，哪些数值设置至关重要，哪些推导过程脆弱，哪些数据文件是权威的，以及哪些尝试的方向失败了。这在波兰尼的意义上大部分是隐性知识：我们知道的多于我们能表达的[43 (https://arxiv.org/html/2606.27386#bib.bib21)]。这种专有技术通常只能通过与作者直接交流或读者反复试错来传递。  

近年来，随着大语言模型 (LLMs) 的快速发展，LLM 智能体在科学研究中发挥着越来越重要的作用[53 (https://arxiv.org/html/2606.27386#bib.bib1),45 (https://arxiv.org/html/2606.27386#bib.bib2),12 (https://arxiv.org/html/2606.27386#bib.bib45),33 (https://arxiv.org/html/2606.27386#bib.bib51)]。智能体已能规划并执行实验或模拟[9 (https://arxiv.org/html/2606.27386#bib.bib28),10 (https://arxiv.org/html/2606.27386#bib.bib46),30 (https://arxiv.org/html/2606.27386#bib.bib53)]，贡献于理论和数学发现[17 (https://arxiv.org/html/2606.27386#bib.bib29),26 (https://arxiv.org/html/2606.27386#bib.bib48),11 (https://arxiv.org/html/2606.27386#bib.bib55),18 (https://arxiv.org/html/2606.27386#bib.bib56),16 (https://arxiv.org/html/2606.27386#bib.bib57),56 (https://arxiv.org/html/2606.27386#bib.bib58),51 (https://arxiv.org/html/2606.27386#bib.bib59),38 (https://arxiv.org/html/2606.27386#bib.bib60),1 (https://arxiv.org/html/2606.27386#bib.bib61)]，并支持从文献综述、实现到实验和报告写作的端到端研究工作流程[32 (https://arxiv.org/html/2606.27386#bib.bib4),55 (https://arxiv.org/html/2606.27386#bib.bib30),46 (https://arxiv.org/html/2606.27386#bib.bib49),57 (https://arxiv.org/html/2606.27386#bib.bib52),14 (https://arxiv.org/html/2606.27386#bib.bib54)]。在我们其中一位作者最近的文章中[45 (https://arxiv.org/html/2606.27386#bib.bib2)]，我们将这一过程称为科学研究的智能体化，预计这将显著改变许多领域的研究实践。  
这一重大变化是一把双刃剑。一方面，它给陈旧的科学论文体系带来了更多挑战。加速的研究过程使得革新当前论文格式以及同行评审和出版程序的需求更加迫切。另一方面，它也创造了现代化科学出版的新机遇。借助 LLM 智能体，我们可以尝试克服上述出版系统的问题。这是提出代理出版协议 (APP) (https://github.com/LionSR/AgenticPublicationProtocol)¹¹¹https://github.com/LionSR/AgenticPublicationProtocol 的动机。APP 是一项提议，旨在以更动态、更可复现的新格式发布科学工作，不仅保留科学工作的知识，还保留其操作专有技术。通过遵循 APP 协议，论文信息以更模块化的方式组织，并提供了增强论文关键结果可复现性的额外信息。通过包含详细指令，论文变得更适合借助 LLM 智能体进行阅读和复现。目标是让智能体与论文内容一同交付给读者，从而读者可以与作者的代表进行交互，以理解并复现论文，进而将精力集中于更创造性的任务，例如开展相关研究项目。每个论文拥有一个代表智能体还可能催生新的科学合作形式，例如通过论文智能体之间的交互提出新想法和后续方向。  

APP git 仓库²²²本文全程使用标准版本控制术语。*（git）仓库*或*repo* 是一个文件夹，其全部变更历史被记录；*commit* 是该文件夹的一个记录快照；*tag*/*release* 将特定 commit 标记为命名的、可引用的版本；*manifest* 是一个小型机器可读文件，记录哪个快照被声明为出版物。包含两部分：协议本身（由 `PROTOCOL.md` 定义）和一组辅助作者准备 APP 出版物的智能体技能。技能 `publish-paper` 在每一步中使用若干其他技能，引导作者将论文组织成符合 APP 规范的格式，并作为 GitHub 仓库的发布版本发布。然而，使用我们提供的技能是可选的。该协议与技能独立定义，符合协议规范的论文也可以通过其他方式构建，无论是手动还是借助其他智能体。  

科学出版的智能体化是一项非常新的发展，我们邀请研究社区与我们一同改进协议本身以及实现协议的技能。不同领域的研究者可能有不同的侧重点或领域专有技术，这些对于论文智能体至关重要。可能不需要通用的 `publish-paper` 技能，而是开发领域特定的智能体技能。为了为 APP 的进一步发展提供起点，我们分享了一个开发仓库 (https://github.com/XiaoliangQi/agentic-publication-protocol-dev.app)，其中包含用于评估和改进协议及相关技能的智能体技能和工具。  

本文其余部分组织如下。在第二节 (https://arxiv.org/html/2606.27386#S2) 中，我们详细概述了协议，包括设计原则、APP 出版物的一般结构、发布工作流程以及相应的技能。在第三节 (https://arxiv.org/html/2606.27386#S3) 中，我们讨论了用于改进 APP 协议的开发工具，并在示例论文上评估了生成的论文智能体。在第四节 (https://arxiv.org/html/2606.27386#S4) 中，我们讨论了与代理出版相关的其他工作。最后，在第五节 (https://arxiv.org/html/2606.27386#S5) 中，我们进行总结并进一步讨论智能体时代科学研究的未来。  

## 2 协议概述  

### 2.1 设计原则  

为了解决第一节 (https://arxiv.org/html/2606.27386#S1) 中讨论的问题，我们希望 APP 协议满足以下原则：  

1. **信息组织有序**。出版物中的信息应以模块化方式组织，以最小化歧义并最大化可用性。仓库结构应足够模块化，使得人类和智能体都能快速定位相关材料。工作的“基本事实”与可选辅助材料之间的区别应清晰。  
2. **增强可复现性**。出版物应使读者或智能体尽可能容易地复现关键结果。在可能的情况下，出版物应包括重现论文中必要结果（包括图表、表格和分析推导）所需的命令、脚本、数据和环境。  
3. **版本控制与时间戳**。出版物应是一个版本控制的对象，具有唯一标识符。git commit、发布标签和 manifest 可以确定被声明为出版物的确切文件树，从而减少关于优先权和来源的歧义。  
4. **操作专有技术共享**。出版物应包含教导智能体如何表示和使用该工作的指令。除了代表工作本身的关键结果外，如果作者决定以智能体技能的形式分享更广泛的专有技术，智能体也可以代表这些。  

### 2.2 协议更多细节  

APP 协议由 `PROTOCOL.md` (https://github.com/LionSR/AgenticPublicationProtocol/blob/main/PROTOCOL.md) 定义。它规定了所需的仓库结构、元数据、验证期望和出版物对象。该协议设计为轻量级且灵活，允许作者选择包含多少信息以及如何组织，只要存在所需的文件和结构。  

在 APP 协议中，出版物被定义为一个公共 git 仓库以及特定的发布版本。该仓库不仅是存储论文源码的地方，它本身就是出版物对象。协议规定了应包含哪些文件、哪些文件是权威的、智能体应如何读取仓库，以及读者如何验证哪个快照被声明为已发表的工作。它不规定仓库必须如何创建。用于准备、检查或发布 APP 出版物的技能是有用的工具，但它们与协议本身是分开的。  

一个完整的 APP 出版物包含三个层次。第一层是人类出版物层，包括手稿、README、许可证、代码、数据和环境信息。第二层是面向智能体的层，以 `AGENTS.md` 为中心，它告诉智能体如何忠实地代表论文以及如何导航仓库。第三层是发布与验证层，将仓库绑定到标签、commit、manifest 和作者批准。这些层次共同使出版物可被人类阅读、被智能体使用，并作为一个稳定的学术对象被识别。  

典型的 APP 仓库具有以下结构（见图 1 (https://arxiv.org/html/2606.27386#S2.F1)）：每个 APP 出版物都需要 `AGENTS.md`、`README.md`、`LICENSE` 和 `paper/`。其他目录在与工作相关时包含。例如，没有代码或数据的理论论文可以省略 `code/` 和 `data/`，而数值或实验论文应包含复现所需的脚本、数据描述和环境信息。  

参考图说明  

图 1：APP 出版物的仓库结构。仓库包含论文、面向人类的文档、面向智能体的指令，以及使论文成为智能体可读的出版物对象所需的可选代码、数据、环境、补充材料和技能。  

`paper/` 目录包含规范论文。这可能包括手稿源码、编译后的 PDF、图表和参考文献。应仅有一个文档被标识为规范论文，其格式和路径应在 `AGENTS.md` 中声明。`code/` 目录包含属于出版物的源码和脚本。当图表或表格由计算生成时，协议要求一个图表/表格复现区域，通常为 `code/figure-reproduction/`，并附带一个 `README.md`，将每个论文图表或表格映射到相应的脚本、输入、生成的输出、状态和任何阻碍因素。`data/` 目录包含本地数据集，前提是它们足够小可以随仓库一起提供。如果数据是外部的，`data/README.md` 应描述来源、如何获取以及哪些脚本或图表使用它们。`environment/` 目录记录如何重建计算环境。它可能包含诸如 `requirements.txt`、`environment.yml`、锁定文件、Dockerfile 或其他依赖规范等文件。如果需要代码或非平凡的构建工具，协议要求提供 `environment/README.md`。