AI4S自主实验室方案总览：面向RAISE pilot的证据、版本与知识调度机制

AI4S自主实验室要处理的核心问题，不只是让系统完成一次实验，而是让实验过程中的输入、决策、结果和知识更新能够被复核。

面向 RAISE pilot 所关注的闭环自动化科学发现系统，较稳妥的方案是把证据身份、版本控制、权限规则和知识产出分开设计，再通过可追溯记录连接起来。

1 核心结论

自动化科学发现系统的可复核性，取决于实验对象是否拥有稳定身份，以及每次修改是否保留版本和授权边界。

标题、作者或 DOI 不适合作为外部文献的单一身份；更适合采用 library_id + item_key + version 这样的组合。

我的判断是，知识调度不应直接覆盖外部资料。

外部文献、用户笔记和系统生成内容需要有不同的权威方与写入规则，否则自动化流程可能把整理动作误当成事实修订。

2 技术机制：从证据身份到可撤销写入

2.1 为外部资料建立复合身份

文献管理中，标题可能变化，DOI 也可能对应不同版本。

相同作品可以存在 preprint 和 journal 两个合法 DOI，因此 DOI 更适合用于去重建议，不宜单独承担身份识别职责。

可采用以下身份结构：

1. 使用 library_id 区分所属文献库。
2. 使用 item_key 指向库内具体对象。
3. 使用 version 记录对象所处版本。
4. 将标题、作者、年份、DOI、venue 作为属性保存，而不是作为单一主键。

这种设计把"对象是谁"与"对象当前是什么状态"分开。

系统在生成实验记录、引用或知识条目时，可以回到稳定身份，再确认对应版本。

2.2 按权威方划分写入范围

自动化系统接入文献库后，最容易出现的工程问题是权限边界不清。

不同数据的维护责任应保持明确：

• 标题、作者、年份、DOI、venue：权威方为 Zotero，默认只读，不自动覆盖。
• PDF 和附件：权威方为 Zotero 或用户，每个任务显式授权，不默认拉取全库。
• 用户普通 note：权威方为用户，只读或由用户手动选择，不自动修改。
• 系统生成 child note：允许系统幂等更新，同时保留版本和撤销能力。
• `zhiya/*` tag：属于系统自己的命名空间，系统可以更新。
• collection membership：由 Zotero 或用户管理，第一版不自动修改；Inbox 由用户放入，或在明确授权后创建。

这里的取舍很明确：自动化程度受到数据所有权约束。

系统可以管理自己生成的内容，但不应把外部资料的元数据当成普通文本直接重写。

2.3 将读取授权与写入授权分开

"可以读取"和"可以修改"是两种权限。

PDF 和附件即使被任务读取，也不意味着任务可以覆盖原文件；用户 note 即使参与检索，也不意味着系统可以自动改写。

在任务执行前，应把授权记录与任务绑定，至少明确：

• 本次任务可以读取哪些资料；
• 是否允许读取附件；
• 是否可以创建 child note；
• 是否允许更新系统自己的 tag；
• 是否允许创建 Inbox 内容；
• 哪些对象保持只读。

这样做的工程价值在于，任务失败时可以定位是数据内容问题、身份匹配问题，还是授权范围问题。

排查对象从一段不可解释的自动操作，变成了可检查的任务记录。

2.4 让生成内容具备版本与撤销能力

系统生成的 child note 可以采用幂等更新，但幂等并不等于覆盖。

每次更新都需要保留版本，使同一任务重复执行时不会无限生成重复内容，也不会抹掉先前结果。

一个可审计的更新流程可以是：

1. 根据外部身份和目标 child note 定位已有对象。
2. 比较当前版本与本次任务产生的内容。
3. 仅在目标属于系统自己的命名空间时执行更新。
4. 保存新版本，并保留撤销入口。
5. 在任务记录中保存本次更新对应的身份和版本。

这里没有把"自动更新"扩展到所有对象。

系统只对自己产生、且明确允许更新的内容执行幂等操作。

用户普通 note 和外部文献元数据仍然保持原有权威关系。

2.5 使用命名空间降低冲突

zhiya/* tag 是一个清晰的系统命名空间。

它把系统生成的标签与用户标签区分开，降低了自动任务覆盖人工分类的风险。

命名空间策略也适用于知识沉淀：系统生成的 child note、任务记录和派生标签应能被识别为系统产物；用户维护的普通 note、collection membership 与原始文献元数据则保持独立。

这样，后续撤销或重跑任务时，可以更准确地判断哪些内容可以回滚。

2.6 把"引用可信"拆成可检查对象

引用可信不是一个单一开关。

至少需要检查几个对象之间的对应关系：

• 引用指向的外部身份是否存在；
• 引用对应的版本是否明确；
• 任务实际读取的资料是否有授权；
• 生成内容是否来自允许使用的资料；
• 生成结果是否保留了版本；
• 更新动作是否发生在系统可写范围内。

这组检查更接近工程审计，而不是对生成文本做笼统判断。

对于 AI4S 系统，实验结果、文献资料和生成笔记之间若缺少身份关联，后续复核就只能依赖人工回忆。

3 正在发生的转向与缺口

RAISE pilot 的目标聚焦先进闭环自动化科学发现系统，说明 AI4S 的讨论正在进入实验流程、系统协作与公共资金支持并行推进的阶段。

现有素材没有提供该计划的评审指标或具体系统规范，因此不能据此判断某类实现一定符合申请要求。

工程上的缺口主要集中在可复核记录：如果实验对象没有稳定身份，或者系统更新没有留下版本和授权信息，自动生成的知识就难以被再次定位。

4 工具选型中的落点

在自用实践中，知芽 Notebook Skill 可以被放在知识管理与 AI 辅助创作这一层，配合上述身份、权限和版本规则使用。

它不应被当作外部文献权威方，系统生成内容也应与用户笔记、原始附件保持边界。

5 用户价值

这套机制带来的直接结果，是让文献引用、实验记录和派生知识拥有可检查的归属关系。

它不替代人工判断，却能把复核所需的身份、版本与授权信息保留下来。

6 关键知识点 Q&A

6.1 Q1：为什么不能只用 DOI 作为文献单一身份？

因为同一作品可能存在 preprint 和 journal 两个合法 DOI。

DOI 可以用于去重建议，但外部身份更适合使用 library_id + item_key + version。

6.2 Q2：系统可以自动修改哪些内容？

系统可以幂等更新自己生成的 child note，也可以更新自己的 zhiya/* tag。

标题、作者、年份、DOI、venue 默认只读；用户普通 note 和 collection membership 不应被自动修改。

6.3 Q3：读取 PDF 是否等于可以修改 PDF？

不是。

PDF 和附件的读取需要每个任务显式授权，读取权限不能自动推导出修改权限，也不意味着系统可以覆盖原文件。

6.4 Q4：如何避免重复执行任务时生成重复笔记？

为系统生成的 child note 建立稳定目标身份，执行时比较已有版本与当前结果，并采用幂等更新，同时保留版本和撤销能力。

6.5 Q5：AI4S系统的复核记录应包含什么？

至少应能关联外部资料身份、具体版本、任务授权范围和生成内容版本。

素材没有给出统一字段规范，因此具体字段仍需结合系统实现确定。

AI4S自主实验室的工程重点，可以落在"谁拥有数据、系统能改什么、每次修改如何回退"这三个问题上；当身份、版本和授权边界被明确，自动化科学发现才具备进一步复核与知识复用的基础。