长期记忆是让Agent跨会话保留上下文,提供连续、个性化服务,防止新会话后状态丢失、记忆断片,从而大幅改善交互体验。记忆张量是大语言模型记忆领域的国内独角兽,主攻记忆管理操作系统MemOS(Memory Operating System),为 AI Agent提供标准化、模块化的记忆基础设施。MemOS选型PolarDB PostgreSQL兼容版(以下简称PolarDB-PG)作为其最核心的记忆库平台,已完成深度对接并生产化应用。近日,MemOS 在 LoCoMo、LongMemEval 等记忆算法 benchmark 以及工业级性能压测中,对比 Mem0、Zep、Supermemory 等多款竞品进行了横向对比,在综合评分中全面领先。本文揭秘PolarDB-PG助力MemOS建立Agent Memory工业级稳定、性能、成本优势的背后力量。记忆张量应用算法负责人 唐波
在2026 PolarDB开发者大会分享《PolarDB多模融合:构建MemOS记忆管理操作系统》
强大的记忆系统类似人体的大脑,需要高效存储和检索各类记忆相关信息。底层记忆的存储和检索效率直接影响用户体验。MemOS采用分层记忆管理策略,其最核心的明文记忆包含两大类,即基于向量为核心的通用明文记忆和基于图为核心的树形明文记忆,而后者是其记忆系统主推形态。在系统运行之初,MemOS选型过国内外多款数据库平台,经过对比试运行,提出了以下三个方面的核心述求:- 树型明文记忆以图(Graph)为核心,每一个图的节点(vertex)负责存储一个记忆片段,需要在节点内统一存储该记忆片段对应的标量、向量、全文等跨模态属性。
- 要求记忆的属性字段支持schemaless的定义方式,并满足长记录的写入效率。
- 多种数据库系统组合存储方式容易出现数据写入不一致问题,比如图数据插入成功,但向量数据写入失败导致数据不一致;不同类型数据考虑需要按时间点统一备份恢复等。
- MemOS有图+向量+全文+标量的融合检索需求;多数据库产品组合方案在记忆召回时需分别访问图库、向量库、关系库等,再在应用层融合结果,增加延迟与复杂度,且难以实现语义级联合排序。
- 多图管理:长记忆个性化服务特点以及多租的运营模式,要求数据库支持良好的多图管理能力,单数据库实例单图模式限制较大,成本高昂。
- 弹性扩展:当并发访问的用户量增加时,需要通过横向扩展支撑高并发;当数据体量增大时,需要弹性扩容能力。
- 综合成本:非一站式方案需维护多套数据库集群,涉及多份许可、多份资源、多份监控,显著推高 TCO(总拥有成本)。
为满足MemOS对记忆存储、检索和运维的企业级需求,PolarDB-PG提供了一站式记忆库能力。如图所示,整体记忆系统从上到下包含三层架构:API 与应用接口层:MemOS 提供了标准化的 Memory API,开发者可以通过简单的接口实现记忆创建、删除、更新等操作,让大模型具备易于调用和扩展的持久记忆能力,支持多轮对话、长期任务和跨会话个性化等复杂应用场景。记忆调度与管理层:MemOS 提出了记忆调度(Memory Scheduling)的全新范式,支持基于上下文的 “下一场景预测”(Next-Scene Prediction),支持明文记忆、激活记忆、参数记忆的动态转化。其中,明文记忆是交互的核心,包含文本、文档、图节点或向量块等;激活记忆为短期 KV Cache 和隐藏状态,而参数化记忆支持将知识提炼到模型权重中实现进一步固化。记忆治理也是记忆调度和管理的一部分。记忆存储与基础设施层:MemOS 通过标准化的 MemCube 封装,将明文记忆、激活记忆和参数记忆三种形态有机整合,支持多种持久化存储方式,包括 Graph 数据库、向量数据库等。MemOS在本层次中与PolarDB-PG进行了深度对接,借助PolarDB-PG实现了一站式记忆库能力,即:图+向量+全文+标量的多模同库、多模同表统一存储、一致性事务处理以及高效超融合检索方案,加持多图管理和云原生弹性扩展能力,大幅降低TCO成本。一个“好”的记忆系统,必须在“算法”和“系统”两个维度上同时交出答卷。算法决定了它能否“记得准、懂你心”,系统决定了它能否在真实压力下“扛得住、响应快”。根据MemOS给出的竞品对比统一压测报告,结果显示,MemOS 在高并发下全程保持 100% 成功率,展现了真正的工业级稳定性,并在延迟指标上全面领先,在 40 QPS 压力下,Add 接口平均时延仅 192ms,平均检索时延为 440.5ms,实现真正的“即写即查”。MemOS 在 40 QPS 甚至 100 QPS 下的“零失误”表现,根据记忆张量的分析,源于其为高并发、低延迟场景量身定制的工业级架构:一个是“L1向量 -> L2图谱 -> L3精炼”读写异步解耦的“渐进式”处理架构,其二是采用了AI原生的以图存储与计算为核心的记忆系统。MemOS的记忆的本质是图,而非传统数据库擅长的“表”或“文档”。传统方案在应用层“模拟”图关系,导致 I/O 效率低下,无法支持复杂的图计算。记忆张量反馈:MemOS联合阿里云PolarDB团队,在存储层即提供了高效的图存储及多模融合计算能力,使系统的类脑图检索增强算法得以“贴地飞行”。- 偏好记忆,存储用户画像与偏好,又叫用户记忆(UserMemory);
- 事实记忆:存储客观事实类记忆,又叫长期记忆(LongTermMemory);
- 工作记忆:存储用户当前所关心的内容,即WorkingMemory。
User: 我暑假定好去广州旅游,住宿的话有哪些连锁酒店可选?
Assistant: 您可以考虑【七天、全季、希尔顿】等等
User: 我选七天
Assistant: 好的,有其他问题再问我。
事实记忆: 用户计划在暑假期间前往广州旅游,并选择了七天连锁酒店作为住宿选项。
偏好记忆: 用户可能偏好性价比较高的酒店选择
Reasoning: 七天酒店通常以经济实惠著称,而用户选择七天酒店可能表明其在住宿方面倾向于选择性价比较高的选项。虽然用户没有明确提到预算限制或具体酒店偏好,但在提供的选项中选择七天可能反映了对价格和实用性的重视。
以MemOS主推的树形明文记忆为例,所有记忆由图结构串联,每类记忆内部进行记忆节点组织。节点:记忆最小组织单元,记录一个较为完整的记忆片段,如“小明在2025年9月7日表达了对冰淇淋蛋糕的喜爱”。节点内同时也存储了丰富的元数据,如“记忆的创建时间”、“记忆的更新时间”、“记忆的归属用户”、“记忆标签”、“记忆来源”等等,以及该记忆片段的向量表示,方便多通路的检索以及更好的推理节点的生成。注意,每个节点对应的是一段“记忆”,和对话不是一一对应关系;一轮对话可能被抽出一个节点、也可能多个;多轮对话也可能只抽出一个节点。边:边用于描述记忆节点之间的关系,比如:[PARENT]父子、[UPDATE]更新、[MERGE]归并、[RELATE]相关、[INFERS]推理、[FOLLOWS]时序、[AGGREGATE_TO]主题聚合、[CAUSE]因果、[CONDITION]条件、[CONFLICT]冲突,等。PolarDB-PG采用了“多模同表”的方式实现了高效集约化存储和统一、高效事务处理。其中,图的节点表每一行对应存储一个记忆片段(以下四行记录代表四个记忆片段),分解存储为标量、向量和全文等多模类型字段,表上支持构建标量索引、向量索引和全文索引。搜索的时候,无论是向量搜索还是图检索,都可以指定过滤条件,比如,过滤user_name就能指定用户、过滤user_name\memory_type就能指定用户的特定记忆类型;库内数据支持事务一致性增删改查,统一按时间点备份还原等数据基础能力保障,大幅简化应用开发。node_id = 1001, user_name = 'alice', memory = '我是alice的记忆',memory_type = 'UserMemory', tags = 'travel‘, embedding='xxxxxx'
node_id = 1002, user_name = 'alice', memory = '我是alice的记忆2',memory_type = 'UserMemory', tags = 'travel‘, embedding='xxxxxx'
node_id = 1003, user_name = 'alice', memory = '我是alice的记忆3',memory_type = 'WorkingMemory', tags = 'travel‘, embedding='xxxxxx'
node_id = 1004, user_name = 'bob', memory = '我是bob的记忆',memory_type = 'UserMemory', tags = 'diet‘, embedding='xxxxxx'
edge_id = 1, start_id = 1001, end_id = 1002, relaion = 'Parent'
edge_id = 2, start_id = 1002, end_id = 1003, relaion = 'Cause'
MemOS希望记忆的属性字段支持schemaless的方式进行定义,从而灵活增减字段,并方便不同记忆用户实现字段的自定义扩展。 同时,也希望支持属性的多层次结构定义,支持对象嵌套组织管理模式。PolarDB-PG在图中引入类Jsonb的格式来组织和存储记忆的相关各类属性信息。以下是MemOS图节点上的properties字段,采用类似JSON的二进制结构:{
"id": "...",
"tags": [],
"memory" : {
},
"user_data" : {
"comment": {
"content" : "xxxx",
"updated_at": "2025-11-01"
}
}
}
可以在以上properties字段上构建字段级的全文索引或Key-Value级的函数索引以加快属性检索;此外,支持Json的多级嵌套,如user_data对象,其中的comment对象完全是MemOS用户自己定义的结果,无法系统层面预先进行定义。以上分析可见,记忆的核心内容主要存储在图的节点表中,每个节点对应一个记忆片段,打包该记忆片段的所有内容,包含记忆内容、记忆元数据、各类标签、以及长达1024维向量等。这种一条记录覆盖记忆核心内容的方式极大简化了业务操作,但也带来单行记录可能长达几MB,对数据库写入性能提出了高要求。PolarDB-PG通过在图中引入LZ4高效压缩算法,加持PolarStore PSL5(PolarStore Level 5)分布式高性能存储底座,数据库侧的单条记忆写入时间从140ms压缩到约50ms,为记忆内容的Add操作实现端到端低延迟创造了必要条件。首先,根据用户问题查找相关记忆片段,翻译为记忆库的操作即:找出与给定向量在一定距离内且符合属性条件的TOP K个图节点。这是一个典型的在图的节点表中用向量+标量联合检索的例子,PolarDB-PG用一个Cypher+Subquery的表达式SQL做到一键查询,此类查询延迟均可做到50毫秒内响应:SELECT id, SCOPE
FROM
(SELECT *
FROM cypher('graph_name', $$
MATCH (m:Memory)
WHERE m.status = 'activated'
AND m.user_name = 'user1'
RETURN id(m),
(1 - (_column(m, 'embedding') OPERATOR (`<=>`) [0.0107725775,……,0.034227762]::vector)) as scope
$$) AS (id graphid,
SCOPE float8)) t
ORDER BY SCOPE DESC
WHERE SCOPE > 0.1
LIMIT 10;
以下是更为复杂的关联记忆搜索,场景假设已知A记忆为“Tom喜欢狗”,要求查找与A记忆有【CAUSE】因果关系的B记忆片段,要求B记忆片段的内容与“和动物玩耍”(需要转为向量表示)最相关,搜索出来的B记忆片段为“Tom与猫玩的过程中被猫抓了”(也就是Tom现在喜欢狗,是因为曾经被猫抓过)。该场景翻译为记忆库的操作同样用一个Cypher的表达式SQL做到一键查询,即:借助图的Cypher查询和向量相似度检索混搭:SELECT * FROM cypher('graph', $$
MATCH (center:Memory)-[:CAUSE]->(neighbor:Memory)
WHERE center.id = '08f2511d-90a4-45e7-aab0-a0713514a10e'
AND center.status = 'activated'
AND center.user_name = 'Tom'
RETURN neighbor.Memory,
(1 - (_column(neighbor, 'embedding') OPERATOR (`<=>`) [0.0107725775,……,0.034227762]::vector)) as score
ORDER BY score DESC
LIMIT 10
$$) AS (memory agtype, score float8);
记忆跳转搜索,要求从一个记忆片段跳转到「多度」相关联的所有记忆片段。翻译为记忆库的操作需要借助图的VLE查询能力。在图的检索中,VLE(Variable-Length Edge,变长边)查询因为涉及到变长的跳数以及开放子图搜索,对检索的内存资源消耗大,且RT衰减严重。以下是一个记忆跳转搜索对应到PolarDB-PG的VLE查询的示例,检索指定记忆节点1-2跳范围内的所有记忆节点和边:SELECT * FROM cypher('graph',
$$ MATCH(center: Memory)-[r * 1..2]->(neighbor:Memory)
WHERE center.id = '08f2511d-90a4-45e7-aab0-a0713514a10e'
AND center.status = 'activated'
AND center.user_name = 'user1'
RETURN collect(DISTINCT center), collect(DISTINCT neighbor), collect(DISTINCT r) $$ ) AS (centers agtype, neighbors agtype, rels agtype);
PolarDB-PG的图引擎针对VLE查询实现了三重优化,即并行查询、锁优化、LRU多图队列缓存,提高并发度的同时降低了内存使用率,此类图查询延迟可以做到百毫秒级响应。PolarDB-PG基于图的多模融合检索能力和LLM结合,助力MemOS推进记忆关系推理研究,包括多跳推理、时间推断等新形态“记忆理解”能力。以下记忆推理均为检索叠加写入过程,高度依赖记忆库的并发读写能力。- 对每个候选节点,使用LLM判定关系类型并创建节点连接关系:CAUSE、CONDITION、RELATE_TO、CONFLICT、NONE。
- 遍历上一步的因果/条件关系,当存在CAUSE或CONDITION时,创建推理节点。
- 如果节点含有timestamp信息,则检索时间接近的全局事件节点;
- 比较时间先后,自动建立FOLLOWS边(from_id->to_id)用于构建时间链,支持回溯上下文。
- 当存在足够多(如>=3)高重合标签的节点时,判定节点间关联,在必要时独立触发任务创建主题概念节点,归纳该主题下的记忆;比如“用户面对XX事件的心路历程”、“用户的旅行经历合集”等。
MemOS会对以上关系推理建立独立的触发机制,可以定制触发规则,比如有足够的新memory被add、也可以search满足要求的某些已有节点做处理(比如tag重合、所连边少的节点)。多图管理:支持记忆系统按记忆项目、用户等业务逻辑实现数据库集群内“多图”管理。PolarDB-PG采用instance-database-schema-table的四级管理体系,一个schema对应存储一张图,一个数据库实例所管理的图数量理论上不受限制,能良好支撑记忆张量未来千万级客户规模下,租户分图管理方案的演进。弹性扩展:图和向量均支持从百万级到百亿级记录规模的弹性扩展,因存储和计算分离,资源可以做到更精细的控制;随着记忆服务规模的扩大,QPS支持横向多节点扩展。综合成本:符合记忆系统要求的一站式多模能力,大幅降低记忆系统构建成本;系统按需弹性扩展,避免一次性高费用的支出;内置 TTL(Time-To-Live)策略,支持按规则自动清理过期记忆(如 90 天未活跃用户数据),降低存储成本。MemOS 不仅是一个记忆层的操作系统,更是 AI 应用从“对话机器人”迈向“可持续、可进化智能伙伴”的关键基础设施。PolarDB-PG为MemOS构建先进记忆操作系统解决了记忆库的存储、检索、运维/成本三大核心问题:- 多模统一存储与一致性事务处理,做到记忆同库、多模同表、schemaless的超融合方案;
- 标量+图+向量+全文的基于统一SQL的多模融合检索,记忆搜索查询延迟在50毫秒内,变长记忆跳转等复杂查询控制在100毫秒级响应;
- 多图管理,弹性扩容,TTL,加持一站式方案,大幅降低记忆库TCO成本。
MemOS和PolarDB PostgreSQL版的深度整合,让每一位开发者都能轻松构建真正“记得住、懂你心、扛得住、响应快”的记忆系统。