一个研究系统输出了市场分析报告：“AI 市场预计 2025 年将达到 5000 亿美元。“审阅者问：这个数字从哪来的？报告里没有来源标注。研究子代理其实有数据——其中一个返回了 {claim: "AI market projected at $500B by 2025", source_url: "...", document: "2024 AI Market Forecast"}。但协调器在综合时丢掉了归属信息，把结构化的声明-来源映射转成了纯文本。
这个数字可能是对的。但没有溯源，没人能验证它，没人能检查来源是否过时，如果它错了，也没人能追溯到错误的源头。
什么是声明-来源映射
声明-来源映射把每条事实性断言与支持它的具体来源配对：
{
"claim": "Returns accepted within 30 days of purchase",
"source_document": "return_policy_v3.pdf",
"source_excerpt": "Section 4.2: All products may be returned within thirty (30) calendar days...",
"last_updated": "2025-01-15",
"page": 12
}这不是参考文献列表。参考文献列表把来源放在文档末尾。声明-来源映射把每一条声明链接到它的具体来源——逐条对应，不是逐篇对应。
这个区别在协调器综合来自 3 个子代理、查询不同知识库的信息时尤为重要。文档级的”来源”部分列出三个数据库，不能告诉读者哪个数据库支持退货政策声明、哪个支持延保声明。声明-来源索引可以。
归属信息在哪里丢失
归属丢失几乎总是综合阶段的问题，不是检索阶段的问题。子代理通常返回的是带有来源元数据的结构化数据。出问题的地方是协调器。
三种失败模式：
叙述合并。 协调器把多个来源的发现融合成一段文字，不追踪哪条声明来自哪个来源。一旦合并，溯源就不可恢复了。
自然语言引用。 子代理把引用嵌入文本中（“according to the API docs…”）。协调器在综合时改写或合并，嵌入的引用就断了或消失了。
文档级归属。 协调器把声明链接到了正确的文档，但没有链接到具体摘录。当声明与来源矛盾时（“covers accidental damage” vs 文档的 “manufacturer defects only”），需要 4 小时的调查才能确定错误出在提取、综合还是来源本身。摘录级映射能让差异在几分钟内就显现出来。
审计数据：38% 不可验证
一个团队审计了其研究系统的归属质量：
| 归属质量 | 比例 |
|---|---|
| 正确、可验证的来源 | 62% |
| 来源已列出但 URL 失效/文档找不到 | 18% |
| 泛化归属（“studies show”、“research suggests”） | 15% |
| 完全没有归属 | 5% |
38% 的声明无法验证。修复需要同时处理三种失败类型：在提取时验证 URL（18% 的失效链接），要求结构化的声明-来源映射而非泛化短语（15% 的泛化归属），确保每条声明都有归属（5% 的缺失）。
泛化归属——“studies show”、“research suggests”、“according to experts”——在一个声称提供可追溯信息的系统中绝不可接受。这些短语听起来权威，但无法验证。应当视同归属缺失。
端到端溯源
在多阶段流水线（分析 → 综合 → 评分 → 报告）中，归属必须在每个阶段存活。任何一个阶段丢掉溯源，下游阶段就无法恢复。
反模式： 只在最终报告阶段添加归属，让报告生成器回头查找来源。到生成报告时，声明已经经过综合和评分阶段的改写、合并和重组。把它们匹配回原始来源是不可靠的。
正确做法： 每个流水线阶段传递并保留上一阶段的声明-来源映射。溯源从初始提取一直累积到最终输出。报告从每个上游阶段继承完整的可追溯性。
对多代理系统而言，这意味着：
- 子代理返回结构化的声明-来源映射（不是纯文本，不是代理名称作为来源）
- 协调器在综合过程中维护溯源索引，为每条声明分配唯一 ID 并链接到其来源
- 最终输出包含逐条归属，将每条事实性陈述链接到其具体来源
来源元数据必须随数据一起传递
一位开发者提议从提取输出中移除来源页码和章节引用以节省存储。当前输出：{value: "$2.3B", source_page: 47, section: "Revenue Summary", document: "2024_annual_report.pdf"}。提议输出：{value: "$2.3B"}。
对于财务数据，这不可接受。没有溯源，错误的 $2.3B 数字无法追溯到源文档进行更正。审计人员无法将提取结果与原始文档核对。相比验证成本，存储节省可以忽略不计。
单独存储元数据（放在查找表中）制造了一个脆弱的依赖。如果表丢失、损坏或不同步，所有溯源就全没了。来源元数据应该作为一个整体和提取的值一起传递。
溯源支撑错误追踪
一个客服系统告诉客户：“延保覆盖意外损坏。“来源文档（warranty_policy_v3.pdf）实际写的是：“延保仅覆盖制造缺陷。“调查花了 4 小时——团队需要确定错误出在来源文档、提取还是综合环节。
有了摘录级归属，差异会立即可见：
{
"claim": "Extended warranty covers accidental damage",
"source_excerpt": "Extended warranty covers manufacturer defects only",
"source": "warranty_policy_v3.pdf, Section 7, page 4"
}声明与摘录矛盾。错误在综合环节。调查时间：几分钟，不是几小时。
这就是声明-来源映射的运营价值：不只是给读者看的归属，更是给团队用的错误追踪。生产环境中一定会出问题——溯源决定了你是花 4 小时调查还是 4 分钟修复。
一句话总结： 在提取时将每条声明链接到其具体来源（文档、页码、摘录），并在每个流水线阶段保留这个链接——没有溯源的事实无法验证。