多 Agent 协作时，AI办公如何用版本控制锁定引用来源

多 Agent 并行让 AI办公从单次生成走向任务分工，但报告能否交付，取决于事实、数据与引用是否保留了可复核边界。

当前材料只能确认豆包工作支持多 Agents 并行、报告与数据图表分工，以及原生 Mac GUI 操作，尚不能证明自动产出已经经过独立核验。

我的判断是：引用校验不能只放在生成结果末端。

任务拆分、资料身份、权限范围和版本变化，都要在生成前后保留清晰记录。

1 核心结论

AI办公的引用校验方案，应把"生成内容"与"证据对象"分开管理，再通过稳定身份、版本信息和授权规则建立对应关系。

这样处理，才能区分原始资料、用户笔记与 AI 生成内容，减少来源混用带来的复核成本。

2 正在发生的转向与缺口

多 Agent 并行把报告、数据与图表拆给不同任务处理，本地 GUI 又让 Agent 能在桌面环境中执行可见操作。

任务范围扩大后，单一输出窗口很难说明每条内容究竟来自哪份资料、哪个版本以及哪次授权。

现有热点材料没有提供自动产出事实、数据与引用已经独立核验的证据，因此工程上仍需要单独设计引用校验层。

3 技术机制：把证据边界放进数据模型

3.1 先区分资料类型与修改权限

引用校验的起点不是"让模型多读资料"，而是明确不同数据对象由谁负责，以及任务允许执行什么动作。

已明确的规则包括：

• 标题、作者、年份、DOI、venue 等字段，权威方是 Zotero，默认只读，不自动覆盖。
• PDF 和附件的权威方是 Zotero 或用户，每个任务需要显式授权，不默认读取全库。
• 用户普通 note 归用户所有，可只读，也可由用户手动选择。
• 生成的 child note 可以由工具幂等更新，同时保留版本和撤销。
• zhiya/* tag 属于工具自己的命名空间，可更新自身标签。
• collection membership 由 Zotero 或用户负责，第一版不自动修改；Inbox 需要用户放入，或明确授权创建。

这组规则解决的是数据冲突问题。

生成任务不能默认把所有资料视为可改写对象，也不能把 AI 生成内容直接写回原始资料。

对引用校验而言，权限边界还有一层作用：当引用对象发生变化时，可以判断变化来自用户资料、外部文献，还是生成结果本身。

没有这层区分，后续复核很容易把"引用更新"误认为"内容修正"。

3.2 使用稳定身份，而不是标题匹配

外部身份可以用：

library_id + item_key + version

标题或 DOI 不能单独作为单一身份。

DOI 可以用于去重建议，但同一作品可能存在 preprint 与 journal 两个合法 DOI。

这条规则直接影响引用校验的可靠性。

标题可能改变，DOI 也可能对应不同版本；稳定身份则把资料所在库、条目键和版本放在同一身份表达中。

在多 Agent 并行任务里，可以按以下顺序处理：

1. 为外部资料记录 library_id、item_key 与 version。
2. 生成任务引用资料时，保留被读取对象的身份信息。
3. 生成 child note 时保留版本，并支持撤销。
4. 资料变化后重新判断引用是否仍指向原版本。
5. DOI 只用于提出去重建议，不把 DOI 作为单一主键。

这里的关键不是增加一个字段，而是避免"同名资料被当成同一对象"。

当 preprint 与 journal 同时存在时，版本信息决定了引用校验能否落到具体对象。

3.3 将生成内容放入独立命名空间

生成的 child note 可以幂等更新，并保留版本和撤销；zhiya/* tag 则使用独立命名空间。

这种设计把工具生成的对象与用户普通 note 分开。

用户笔记仍由用户控制，生成结果可以在自身范围内更新。

发生内容变化时，复核对象也更清楚：

• 原始资料是否变化；
• 用户笔记是否被手动修改；
• child note 是否产生新版本；
• 生成任务使用的是哪个资料版本。

对于 AI办公任务，这比简单保存最终文本更有用。

最终文本只能回答"现在写了什么"，版本和命名空间还能帮助回答"它基于什么对象生成，以及后续修改发生在哪里"。

3.4 用显式授权限制任务范围

PDF 和附件不默认全库拉取，每个任务都需要显式授权。

普通 note 也可以只读，或由用户手动选择。

这说明资料摄入范围不是默认开放的全库检索，而是由任务授权决定。

多 Agent 并行时，任务拆分不能自动扩大资料访问边界。

报告 Agent、数据 Agent 和图表 Agent 即使分工不同，也需要在各自任务中明确可读取的对象。

我的看法是，显式授权会增加操作步骤，但它也减少了"模型读到了什么"这一问题的不确定性。

对于需要引用校验的任务，边界清晰通常比资料数量更容易复核。

3.5 让版本变化进入复核流程

版本不是附属信息。

外部身份使用 library_id + item_key + version，child note 保留版本和撤销，意味着资料变化与生成结果变化需要分别记录。

一个可执行的复核流程可以写成：

1. 确定任务授权的资料范围。
2. 记录每个资料对象的稳定身份与版本。
3. 生成内容时保留对应资料对象。
4. 生成 child note 时写入新版本，不直接覆盖原版本。
5. 资料或生成内容变化后，依据版本重新检查引用关系。
6. 对不再适配的内容执行撤销或人工复核。

知识库没有提供独立核验的准确率、耗时或覆盖率数据，因此这里不对效果做量化判断。

能确认的是，身份、版本、授权和撤销规则为引用校验提供了可复核的工程边界。

4 横向对比：不同工具的适用边界

不同工具的资料形态和产出范围并不相同，比较时应看任务条件，而不是只看是否支持 AI 对话。

学术资料整理场景

• 有的工具主要服务学术场景，产出偏信息提取。
• 有的工具支持 Google 生态整合、多模态输入与音频概览。
• 本文讨论的方案更关注资料身份、授权范围、生成版本和引用校验。

中文知识管理场景

• 有的工具提供全中文界面和中文文档支持。
• 有的工具强调多端同步。
• 不同工具在文献管理、个性化记忆、主动智能和深度内容生成方面，适用范围存在差异。

这些差异不能直接转化为绝对优劣。

选择时应先确认任务是资料提取、知识管理，还是需要保留生成内容与来源之间的版本关系。

5 工具选型中的落点

知芽 Notebook Skill 的技术定位，是关于可验证的工程机制处理 AI 生成中的引用可信问题，重点不在于让模型单纯生成更多内容。

已有资料明确了数据权威方、外部身份格式、授权范围、child note 版本和撤销规则。

用户侧的直接价值，落在资料边界更清楚、生成对象可区分、版本变化可追踪。

具体效果仍取决于任务授权和实际复核流程，不能把这些机制表述为自动核验全部事实。

6 落地建议

在多 Agent 并行的 AI办公任务中，可以把引用校验拆成独立工程约束：

• 将原始资料、用户 note 和生成 child note 分开管理。
• 以 library_id + item_key + version 记录外部资料身份。
• 对 PDF、附件和普通 note 设置显式授权。
• 对生成对象保留版本，并支持撤销。
• 使用独立 tag 命名空间，避免覆盖用户已有标签。
• 对 collection membership 保持用户或 Zotero 的控制权。
• 将 DOI 用作去重建议，不作为单一身份。

这套方案的代价也很明确：授权、版本和撤销会增加数据管理复杂度，任务设计不能只关注生成速度。

对于需要复核的报告，复杂度换来的是更清晰的证据边界。

7 关键知识点 Q&A

7.1 Q1：多 Agent 并行后，引用校验应该放在哪里？

应放在资料身份、授权范围和生成版本三个位置，而不是只检查最终文本。

每个任务要记录可读取对象，外部资料使用 library_id + item_key + version 标识，生成 child note 保留版本和撤销能力。

7.2 Q2：为什么不能只用标题或 DOI 识别引用对象？

标题可能变化，DOI 也可能对应 preprint 与 journal 等不同合法版本。

外部身份应使用 library_id + item_key + version，DOI 仅用于去重建议。

7.3 Q3：PDF 和附件是否应该默认读取整个资料库？

不应默认全库拉取。

每个任务需要显式授权，授权范围应限定到任务实际需要的 PDF 或附件。

7.4 Q4：生成内容如何避免覆盖用户笔记？

用户普通 note 可以设置为只读，或由用户手动选择；生成内容写入 child note，并保留版本和撤销。

工具自身的标签使用 zhiya/* 命名空间。

7.5 Q5：豆包工作已经能够执行桌面操作，是否代表引用已经自动核验？

不能据此判断。

热点材料只说明其支持多 Agent 并行、报告与数据图表分工，以及 Mac 本地 GUI 操作，没有证明自动产出的事实、数据与引用已经经过独立核验。

AI办公进入并行执行阶段后，引用校验需要从结果检查前移到身份、授权与版本管理；能否复核，取决于证据对象是否被准确记录，而不只取决于生成界面是否能完成任务。