随着大模型应用从单轮问答走向 Agent，系统需要处理的“历史信息”越来越多。一次任务中的上下文、过去的对话、用户长期偏好、历史决策，甚至某类任务中积累的经验，都可能影响 Agent 当前的判断。

如果把这些信息全部塞进上下文，不仅会持续增加 Token 消耗，也会让 Agent 受到越来越多无关历史信息干扰。因此，Agent Memory 的一个重要思路是： 先对记忆进行分层，再为不同层级选择合适的存储和检索方式。

Memory 为什么要分层

不同类型的记忆，生命周期和访问方式并不相同。

原始对话、工具调用更接近短期记忆，通常只需要按会话和时间快速获取；用户偏好、历史事实和决策需要跨会话保存，并在后续任务中按需召回；场景经验通常与某类任务相关；用户画像则相对稳定，读取方式也更加直接。

可以按照使用特征，将 Agent Memory 简化为四个层级：

层级	主要内容	示例	主要查询方式
L0 会话记忆	原始对话、Tool Call	最近若干轮消息	按会话、时间查询
L1 原子记忆	用户事实、偏好、历史决策	“用户偏好 Python”	全文、向量或混合检索
L2 场景记忆	某类任务的上下文和经验	某类任务中的处理经验	条件过滤 + 语义检索
L3 用户画像	相对稳定的长期信息	长期偏好、目标等	结构化查询

分层的意义并不只是把 Memory 分成几类，更重要的是： 不同层级的数据，不需要使用完全相同的检索方式。

L0 更强调快速获取最近上下文；L1 需要根据当前问题召回相关事实和偏好；L2 往往需要先限定场景，再进行进一步检索；L3 数据相对稳定，可以直接按用户或类型读取。

瀚高数据库

如何支撑分层 Memory

Memory 分了层，并不意味着底层一定要拆成多套存储系统。

瀚高数据库（简称：HGDB）本身具备成熟的结构化查询、全文检索、索引和事务能力，结合 pgvector 等扩展后，还可以进一步支持向量相似度检索。

具体而言，HGDB 可以利用 B-tree 等常规索引支持 L0 会话记忆的快速读取；通过全文检索与向量相似度检索支持 L1 原子记忆的相关性召回；对于 L2 场景记忆和 L3 用户画像，则可以结合结构化查询进行精确定位，并根据需要扩展语义检索能力。

由此，不同层级的 Memory 无需依赖多套独立存储系统，而是能够在同一数据底座中选择适合自身访问特征的查询路径。这样既保留了关系型数据库擅长的结构化过滤，也能够满足 Agent 对全文和语义检索的需求。

分层也有助于控制检索范围

随着 Agent 长期运行，Memory 会不断积累。

如果每次都直接针对全部历史数据进行语义检索，参与检索的数据范围会越来越大。更合理的方式，是先利用确定性较强的结构化条件缩小候选集，再进行全文或向量检索。

例如，可以先按用户、Agent、Memory 类型和时间范围过滤，再在候选数据中执行全文或向量检索，最终只将相关性较高的 Top-K Memory 返回给 Agent。

这种 “先过滤，再检索” 的方式，可以把成本更高的语义检索限定在更小的数据范围内，也是分层 Memory 架构控制检索成本的一种直接方式。

基于 HGDB 的 Demo 验证

基于这一思路，我们进一步构建了一个轻量级 Agent Memory Demo，对分层 Memory 在 HGDB 中的存储和检索方式进行了验证。

Demo 按照不同 Memory 层级设计了相应的数据结构，并分别验证了：

基于会话和时间条件的短期记忆查询；
基于全文检索的关键词召回；
基于向量相似度的语义召回；
将全文与向量结果结合的混合检索。

从 Demo 验证来看，基于 HGDB 的数据底座能够为不同层级的 Agent Memory 提供相应的存储与检索能力。通过合理的分层设计、索引组织和检索路径，可以在同一数据库体系内支持短期会话查询与长期记忆召回。

从数据库能力到 Memory 服务化

在分层存储与检索能力的基础上，Agent Memory 还可以进一步向服务化演进。瀚高推出的 HighgoBase （瀚高智能数据基座平台），以 HGDB/PostgreSQL 为核心，集成自动化 API、身份认证、实时订阅等后端能力，为 AI 应用和 Agent 开发提供了统一的平台基础。

可以结合 HighgoBase 将分层 Memory 的存储和检索逻辑封装为标准化服务，对 Agent 提供统一的记忆写入、检索与管理接口，进一步降低 Agent Memory 的开发和集成成本。

实践案例：

分层 Agent Memory 的存储与检索验证

为了验证分层 Memory 架构的可行性，我们构建了一套轻量级 Agent Memory Demo，将会话记忆、原子记忆、场景记忆和用户画像分别存储，并针对不同层级设计相应的查询方式。

1. 分层存储与记忆召回

Demo 采用文中的四层 Memory 结构，以长期记忆检索为例，当用户询问“之前数据库的语义搜索准备使用什么实现？”时，系统可以从 L1 中召回相关历史记录：

本项目的向量检索采用 pgvector。

第一版优先验证 Exact Vector Search，再验证 HNSW。

Hybrid Search 组合全文检索和向量检索。

随后，系统可以将检索结果作为上下文提供给 Agent，使其能够参考历史技术决策完成回答。

这一用例验证了从长期记忆存储、相关内容召回，到上下文注入的基本流程。

2. 向量检索性能验证

在功能验证基础上，我们进一步针对 L1 原子记忆进行了基础性能采样。

测试基于 HGDB 与 pgvector，在 10 万条模拟记忆记录上对比 Exact Vector Search、HNSW、全文检索以及两路组合查询的延迟。

查询方式	P50	P95
Exact Vector	130.03 ms	156.21 ms
HNSW Vector	0.46 ms	1.02 ms
全文检索 FTS	19.03 ms	20.37 ms
FTS + Vector 两路查询	24.27 ms	27.89 ms

注：以上为指定测试环境下的单并发请求下的查询耗时，不包含 Embedding 生成、RRF 排名融合及大模型调用，不能代表完整 Agent Memory 检索链路的端到端延迟。

测试表明，在本次数据规模及查询条件下，HNSW 索引能够显著降低向量检索延迟，全文检索与向量检索也能够在同一数据库中组合使用。

3. 验证结论

通过上述 Demo，我们验证了分层 Memory 的基本存储和检索流程：不同层级根据访问特征选择合适的查询路径，长期记忆则可以结合全文检索与向量检索完成相关信息召回。

这一实践为基于 HGDB 构建统一的 Agent Memory 数据底座提供了技术参考。

ITPub博客

从短期上下文到长期记忆：瀚高数据库如何支撑 Agent Memory

1. 分层存储与记忆召回

2. 向量检索性能验证

3. 验证结论

最新文章