大模型智能体在大规模文档集合上答题或完成任务，常常需要把分散在多份文件中的证据连起来：项目审批记在一份文档，需求在另一份，最新状态又在第三份。近期做法是让智能体迭代检索整个语料，而不是只读固定的一批高排名文档。可当语料只以扁平文件集合暴露时，一份相关文档并不会提示它与其他文档如何关联，智能体只好对每个查询重新发现这些关系，既容易漏掉互补证据，又会额外消耗大量 token。

关系不能复用，是扁平语料的结构性缺陷

问题不在智能体「会不会搜」，而在搜索对象没有导航。命中一篇文件，并不指向下一篇该看什么。文档之间的互补关系变成每次推理时的现场拼图，既费 token，也容易漏看。作者因此把目标放在一层可遍历的语料导航，而不是再加一轮盲目检索。

按反复出现的实体建图，链接离线共享

CorpusMap 围绕语料中反复出现、可从文档本身识别的实体来组织。每个这类实体对应一个 Entity Page：聚合关于该实体的信息，并链向所有提及它的文档，形成实体与文档之间的图。智能体可以沿图收集原本断开的证据；一份文档也能经由实体连到许多来源中的其他文档。

图在离线阶段完成：跨文档解析同一实体的提及，链接在查询之间共享，不必在推理时反复发现。作者用 7 种模型和 3 个基准数据集评估，称其能同时改善证据方面的表现。给定摘要在此处截断，未见具体指标与幅度。

我的判断

这条工作的价值很具体：把「文档如何互相关联」从每次查询的搜索成本，变成一次离线、多次复用的结构。对实体密集、来源分散的知识库，方向对症。适用边界同样清楚——实体必须稳定可对齐；消歧一旦出错，图会把无关文档绑在一起，导航可能帮倒忙。材料没有说明实体如何抽取与消歧、构建与维护成本、以及相对强检索基线的定量差距，实验结论目前只能记作「作者声称有改善」。值得当成智能体检索的架构假设来看，但还不宜写成已经验证的通用增益。