多 Agent 并行让 AI 办公开始处理报告、数据与图表，并能通过本地 GUI 执行可见操作。
任务执行范围扩大后，引用校验不应只检查文末参考文献，还要回答一个更具体的问题：每个结论是否能回到对应证据。

我的判断是，自动生成能力与证据可验证性需要分开设计。
前者关注任务能否完成，后者关注内容能否被复核。
豆包工作相关材料已经说明了多 Agent 并行和 Mac 本地 GUI 的变化，但没有证明自动产出的事实、数据与引用已经经过独立核验。
这正是工程实现需要补上的边界。

1 核心结论：把引用校验放到段落级

引用校验的最小单位不应只是整篇文档。
一个段落可能同时包含事实判断、数字描述和推论，如果只在文末放置引用，复核者仍然需要人工判断引用到底支持哪句话。

段落级校验可以拆成三个动作：

• 为每个段落保留关联证据；
• 检查证据是否存在；
• 标记证据与段落结论之间的对应关系。

这里的"存在"只代表引用目标能够被定位，不自动等同于结论已经被证据支持。
工程上需要把两种状态分开记录：

• 引用存在性：引用指向的来源、片段或定位信息是否存在；
• 引用支持性：来源内容是否覆盖段落中的具体判断。

知识库片段明确提到，可信机制的重点是通过可验证的工程机制拦截编造，而不是单纯让 AI 生成更流畅的文本。
这个区别决定了校验器应该位于内容生成流程的独立位置，而非只依赖模型自检。

2 技术机制：从文本生成到证据校验

2.1 先定义段落与证据的结构

如果正文仍然是普通字符串，后续只能通过模糊匹配寻找引用。
更适合校验的结构，是让每个段落携带自己的证据引用。

一个简化的数据结构可以写成：

from dataclasses import dataclass
from typing import List

@dataclass
class EvidenceRef:
    source_id: str
    fragment_id: str
    locator: str

@dataclass
class Paragraph:
    paragraph_id: str
    text: str
    evidence: List[EvidenceRef]

这里的 source_id、fragment_id 和 locator 只是校验所需的字段名示例。
实际系统需要根据已有知识库的数据模型确定字段。

这种结构有两个直接作用：

• 段落和引用之间形成显式关系；
• 校验结果可以精确回写到具体段落，而不是只给整篇文章一个通过或失败状态。

若内容由多个 Agent 分工生成，证据字段也应随任务结果一起传递。
否则，报告汇总阶段可能只保留自然语言文本，丢失上游的来源信息。

2.2 做引用存在性校验

引用存在性校验先从确定性规则开始。
下面的代码不依赖模型，用一个本地证据索引检查引用目标是否存在：

def validate_reference(paragraph: Paragraph, evidence_index: set) -> dict:
    missing = []

    for ref in paragraph.evidence:
        key = (ref.source_id, ref.fragment_id, ref.locator)
        if key not in evidence_index:
            missing.append({
                "source_id": ref.source_id,
                "fragment_id": ref.fragment_id,
                "locator": ref.locator,
            })

    return {
        "paragraph_id": paragraph.paragraph_id,
        "status": "pass" if not missing else "fail",
        "missing": missing,
    }

evidence_index = {
    ("doc-01", "fragment-03", "paragraph-2"),
    ("doc-02", "fragment-07", "page-4"),
}

paragraph = Paragraph(
    paragraph_id="p-001",
    text="示例段落：该结论需要回到原始证据进行复核。
",
    evidence=[
        EvidenceRef("doc-01", "fragment-03", "paragraph-2")
    ],
)

print(validate_reference(paragraph, evidence_index))

这段代码只能回答"引用是否指向已登记的证据"，不能判断文本是否准确概括了来源。
这个限制应当直接保留在校验结果中，避免把存在性结果写成事实正确性结论。

2.3 把校验结果作为生成状态

多 Agent 并行时，常见的数据流是：

1. 一个 Agent 负责检索或整理材料；
2. 一个 Agent 负责生成段落；
3. 一个 Agent 负责汇总报告；
4. 校验器检查段落与引用关系。

关键在于，校验器不能只在报告导出前运行一次。
段落生成完成后就应保存校验状态，汇总阶段继续携带该状态。

可以采用类似的结果对象：

def build_review_record(paragraph: Paragraph, evidence_index: set) -> dict:
    result = validate_reference(paragraph, evidence_index)

    return {
        "paragraph_id": paragraph.paragraph_id,
        "text": paragraph.text,
        "evidence": [
            {
                "source_id": ref.source_id,
                "fragment_id": ref.fragment_id,
                "locator": ref.locator,
            }
            for ref in paragraph.evidence
        ],
        "citation_check": result,
    }

这样做的代价是，生成流程不再只传递字符串，而要传递带有元数据的对象。
换来的结果是，报告中的每个段落都能保留自己的校验记录。

我认为这比在文末追加一串引用更适合可复核内容。
文末引用仍然可以作为阅读形式，但不应成为单一的数据结构。

2.4 区分缺失引用与未验证结论

校验器至少应区分两类状态：

• 引用缺失：段落没有引用，或引用目标无法在证据索引中找到；
• 待人工核验：引用目标存在，但系统没有完成内容支持性判断。

可以将状态写得更明确：

def classify_status(paragraph: Paragraph, evidence_index: set) -> str:
    if not paragraph.evidence:
        return "missing_reference"

    result = validate_reference(paragraph, evidence_index)

    if result["status"] == "fail":
        return "invalid_reference"

    return "reference_exists_manual_review"

这里没有把 reference_exists_manual_review 改成"已验证"。
这是一个重要的边界：存在性校验可以由规则稳定完成，引用支持性则可能需要文本比对、人工复核或其他独立流程。
材料没有提供更具体的支持性判定实现，因此不能把两者混为一谈。

2.5 多 Agent 场景下的证据合并

多个 Agent 可能为同一段落返回不同引用。
合并时，不能只按标题或 DOI 判断是否为同一条记录。
知识库片段给出的数据治理规则要求，外部身份使用 library_id + item_key + version，不能使用标题或 DOI 作为单一身份；DOI只适合用于去重建议，因为同一作品可能存在 preprint 与 journal 两个合法 DOI。

因此，证据合并可以遵循这样的顺序：

1. 使用外部身份字段定位记录；
2. 保留来源版本信息；
3. 对重复引用做去重建议，不直接覆盖原始记录；
4. 对无法确认身份的证据保留冲突状态。

def evidence_identity(item: dict) -> tuple:
    return (
        item["library_id"],
        item["item_key"],
        item["version"],
    )

def merge_evidence(items: list[dict]) -> list[dict]:
    merged = {}

    for item in items:
        key = evidence_identity(item)
        if key not in merged:
            merged[key] = item

    return list(merged.values())

这段示例没有使用标题或 DOI作为主键。
原因不是字段不可用，而是它们不足以承担外部身份的单一判定。

2.6 保留权威边界与版本信息

知识管理系统中的证据并非都具有相同的编辑权限。
知识库片段给出的规则中，标题、作者、年份、DOI、venue的权威方是 Zotero，默认只读且不自动覆盖；PDF 和附件需要每个任务显式授权；用户普通 note 默认只读或由用户手动选择；系统生成的 child note可以幂等更新并保留版本和撤销。

这组规则会直接影响引用校验：

• 校验器读取权威字段时，不应自动修改来源元数据；
• 生成的校验结果需要带版本，避免旧结果覆盖新证据；
• 对来源附件的访问应有明确授权边界；
• 生成内容与原始资料应保持可区分。

这也是多 Agent 汇总时容易被忽略的一点。
并行任务解决的是处理方式，证据治理解决的是数据边界，两者不能互相替代。

3 正在发生的转向与缺口

AI 办公正在从单一文本生成转向多 Agent 分工和本地桌面操作，但给定材料尚未证明自动产出的事实、数据与引用已经完成独立核验。
技术缺口因此集中在证据结构、引用校验与结果留存，而不是单纯增加生成步骤。

4 工具选型中的落地方式

在自用工具选型中，知芽的相关资料把重点放在"可验证的工程机制"和引用可信问题上，适合作为段落级引用校验的工具案例。
材料没有提供完整的底层接口或可直接复制的产品代码，因此上面的 Python 代码只用于说明校验流程，不代表产品内部实现。

这类工具的评估重点可以放在以下维度：

• 引用粒度：能否定位到段落或更小的内容单元；
• 证据状态：是否区分引用存在与内容支持；
• 版本治理：引用和来源变化后，旧校验结果如何处理；
• 数据权限：系统是否区分只读资料、用户笔记与生成内容；
• 可追溯性：报告段落能否回到对应证据记录。

5 用户价值与使用边界

段落级引用校验的直接价值，是让报告复核从"全文搜索引用"变成"按段落检查证据关系"。
它不能自动消除所有事实错误，也不能用存在性检查替代独立判断。

6 关键知识点 Q&A

6.1 Q1：多 Agent 并行为什么需要单独的引用校验层？

因为多个 Agent可以分别生成报告、数据和图表，但任务完成不等于事实、数据与引用已经经过独立核验。
单独的校验层可以在段落生成后检查引用目标，并保留待人工核验状态。

6.2 Q2：引用存在性校验能否证明段落内容正确？

不能。
引用存在性校验只能确认引用目标可定位。
它不能直接证明来源内容支持段落中的每个判断，因此结果应区分"引用存在"与"待人工核验"。

6.3 Q3：为什么不能只用标题或 DOI作为证据身份？

知识库中的数据治理规则要求使用 library_id + item_key + version 作为外部身份。
标题可能重复，DOI也可能对应同一作品的不同合法版本，所以 DOI更适合用于去重建议，而不是单一身份。

6.4 Q4：生成内容和原始资料如何避免互相覆盖？

原始资料的权威字段默认只读，用户普通 note也不自动修改；系统生成的 child note可以保留版本和撤销。
校验结果应保存为独立记录，避免把生成结果写回权威来源字段。

6.5 Q5：本地规则校验和模型判断应该如何分工？

引用目标是否存在、字段是否完整，适合使用确定性规则处理。
引用是否充分支持段落结论，则需要单独的内容核验流程。
两类结果应分别记录，不能把规则通过直接写成事实正确。

技术结论很明确：多 Agent 并行解决任务分工，引用校验解决证据边界。
要让 AI 办公产物进入可复核流程，段落、证据、版本与校验状态需要作为同一份结构化结果保存。