检索智能体需要处理多种数据类型，因为现实世界中的知识很少仅以文本形式存在。

大多数检索助手都假设，可以将上下文转换为文本块并存入向量数据库。现实世界的数据要杂乱得多：文档可能存放在 Markdown 文件或 PDF 中，业务运行数据存放在 SQL 表中，依赖关系存放在图中，流程存放在标准操作规程（SOP）中，而用户特定的决策则存放在持久记忆中。将所有这些内容扁平化为一种检索格式，会带来一些可预见的问题：表格失去其模式结构，变得难以筛选或聚合。关系变成孤立的文本片段，而不是可遍历的路径。操作流程与事实性知识混在一起。用户偏好和项目决策失去其适用范围。更新可能导致多种表示之间不同步。更好的方法是提供多个具有明确类型的数据访问层：KB 用于文档、笔记以及语义与关键词混合检索。DB 用于结构化记录、筛选、连接和聚合。Graph 用于实体、依赖关系和有界遍历。Skills 用于可复用的流程和操作指令。Memory 用于具有明确适用范围的事实、偏好和决策。在检索端，智能体应为每个请求选择足以完成任务的最小数据访问层集合。文档类问题交给 KB，数值类问题交给 DB，关系类问题交给 Graph，而复合任务则可以合并来自多个数据访问层的证据。存储路径应保持独立。存储智能体可以根据每项输入的结构和含义进行路由，保留来源元数据，并返回包含受影响的数据访问层、修订版本和写入结果的回执。同一来源可以被映射为多种表示，例如 KB 中可搜索的文档块和 Graph 中提取出的关系，而不必将所有数据访问层视为可以互换。目前，OpenDCAI/DataMind 已实现这一架构。不确定这类架构是否存在真实需求。