在实际生产环境中，AI 记忆并不是一份静态的聊天记录。它需要同时支撑高并发访问、海量数据增长、多租户隔离、故障恢复和动态扩缩容，还要完成信息提取、结构化存储、精准检索、持续更新与生命周期治理。只有将记忆管理与云原生的数据基础设施结合，长期记忆才能从单点功能升级为可规模化运行的 AI 基础能力。

阿里云 PolarDB 云原生数据库 与 记忆张量 MemTensor 提供了一条分层协同的工程化路径：PolarDB PostgreSQL 版（PolarDB-PG）为 AI 应用提供统一、稳定的记忆数据底座，MemOS 则作为面向 LLM 与 Agent 的记忆操作系统，通过云+开源部署方式，结合统一 Memory API、记忆模型与 MemCube 记忆容器，对记忆进行持续调度和管理。

PolarDB-PG 负责记忆的“稳”，MemOS 负责记忆的“活”。 二者分别承担数据基础设施层与记忆系统层的职责，共同形成一条从云原生存储、记忆管理到 Agent 调用的完整交付链路。

进入真实业务后，记忆系统往往还需要同时处理三类数据：

• 结构化信息。 例如用户编号、创建时间、业务标签、记忆来源和权限范围，需要关系型数据库完成精确过滤和一致性管理。
• 语义信息。 例如“喜欢低饱和度颜色”和“偏好莫兰迪色系”表达不同，但语义接近，需要向量检索进行召回。
• 关系信息。 例如用户、商品、订单和偏好之间的关联，或某条记忆由另一条记忆更新而来，需要图结构表达实体关系和多跳路径。

传统方案通常需要分别部署关系库、向量库和图库，再由应用层维护数据同步、连接配置和异常处理。

其中，优化版 PGVector 负责语义检索，一条 SQL 即可完成相似度计算与属性过滤；PolarAGE图引擎负责图查询，采用了原生图数据库的遍历算法，在百亿级节点规模下可实现万级 QPS、百毫秒内响应，支撑多跳遍历与因果链推理；PostgreSQL 原生的关系型能力——全文索引、事务一致性、备份恢复——开箱即用。

三类能力由同一数据库体系统一承载，可以减少关系数据、向量数据与图数据在多套系统之间的同步与维护。配合存算分离、只读节点扩展和弹性伸缩能力，PolarDB-PG 可以根据记忆数据规模和访问负载进行扩展。

双方分别承担记忆管理层与数据库底座的职责：

• MemOS 作为面向 LLM 与 Agent 的记忆管理层，负责记忆的写入、提取、组织、检索、更新与生命周期管理，并通过统一 Memory API 和 MemCube 记忆容器向应用提供能力；
• PolarDB-PG 负责记忆数据的持久化，以及关系查询、向量检索、图关系处理，并提供事务、权限、备份恢复和弹性扩展等数据库能力。

两者共同形成从记忆写入、持久化存储、组合检索到持续更新的完整链路。

MemOS Cloud 已使用 PolarDB 支撑记忆数据的存储与查询。双方在同等机器配置、同等数据集和同等负载条件下，使用 MemOS Cloud 对 PolarDB-PG 与某主流图数据库进行了 Search P99 延迟对比测试。

同等机器配置、同等数据集下 Search P99延迟对比（单位：ms，越小越好）

• P99 性能提升 1.79—9.27 倍，中位数为 2.71 倍，5 个负载点平均提升 3.96 倍；
• 在 40 QPS 下，PolarDB-PG 的 P99 延迟为 1404ms，对照数据库为 13020ms，性能提升 9.27 倍，P99 延迟降低 89.2%。

PolarDB 提供三类模型算子：

• LLM 算子： 提取长期事实、用户偏好和实体三元组，并辅助处理新旧记忆的融合；
• Embedding 算子： 将记忆内容转化为向量表示，用于语义检索；
• Rerank 算子： 对召回结果进行精排序，减少无关内容进入大模型上下文。

方案支持数据库模型算子和百炼等模型服务。模型调用可优先使用百炼，高负载时切换至数据库模型算子作为备用通道，提升流量波动下的稳定性和服务连续性。

开发者则可以通过 MemOS 开源 SDK、Memory API 和示例项目，将长期记忆接入现有 LLM 与 Agent 应用。平台管理员负责配置和治理底层能力，应用开发者负责将 MemOS 接入具体业务。

“平时穿 M 码”、“喜欢莫兰迪色系”、“上个月买过一条阔腿裤”。

每个节点可以包含创建时间、更新时间、归属用户、标签、来源和向量表示等元数据；节点之间还可以通过关系边建立关联，形成可追踪、可查询和可推理的记忆网络。

在 MemOS 组织的记忆写入流程中，PolarDB 的 LLM 算子负责事实与实体关系抽取，Embedding 算子负责生成向量表示，处理后的结构化信息、向量数据和图关系统一写入 PolarDB-PG。

记忆召回分为三个环节：

• L1 向量初筛 ： 通过向量相似度计算、属性过滤和标签匹配，召回与“婚礼穿搭”相关的候选记忆，典型延迟小于 50ms；
• L2 图谱扩展： 利用 PolarDB-PG 图引擎进行多跳查询，从候选节点扩展至尺码、色系偏好和购买历史等关联记忆。配合并行执行与 LRU 多图队列优化，核心路径 P95 响应稳定在 10ms 级；
• L3 精排与推理精炼： Rerank 对候选记忆进行相关性排序，LLM 判断记忆之间的因果、冲突和条件关系，过滤重复或无关内容。

最终传递给大模型的记忆可以被整理为：该用户平时穿 M 码，偏好莫兰迪色系，上个月购买过一条阔腿裤。大模型据此生成更符合用户偏好和历史行为的穿搭建议。

MemOS 的 Memory Scheduling 机制用于组织记忆的生成、调用、更新和生命周期管理。当新的信息与已有记忆存在差异时，可以根据应用配置和业务策略进行融合或更新；当用户主动纠正信息时，可以通过反馈机制修改相关记忆；对于不再适用的内容，也可以进行删除或归档。

因此，记忆系统管理的不是一个不断累积的静态片段集合，而是一组可以持续更新和治理的长期信息。

MemOS 使用 MemCube 管理不同记忆空间，PolarDB-PG 则通过集群、Database、Schema、表、图和用户标识落实数据隔离：

在单个 MemCube 内部，PolarDB 按 UserID 自动划分子图。同等记忆规模下，召回效率提升 50% 以上，支持 千万级用户规模 的独立记忆空间。

对于产品规格、合规条款和行业知识等公共记忆，MemOS 可以组织跨项目、跨 Agent 的共享范围，PolarDB-PG 则通过 Schema、表、视图和权限体系控制读写边界，在实现记忆复用的同时保证数据可控。

采用 PolarDB-PG 与 MemOS 协同的架构，企业可以在同一套数据底座上完成关系、向量与图检索，减少多套数据库之间的数据同步、系统联调与运维成本。

• 接入效率高。 开发者仅需对接单一系统，即可同时获得图、向量、关系三种检索能力；集成周期从“周级”缩短至“天级”。
• 成本可控。 存储的是提炼后的记忆节点而非原始对话全文，传递给大模型的 Token 量显著减少；配合存算分离与弹性扩缩容，底层资源费用随实际用量变化，无需提前预留冗余。
• 可靠性强。 MemCube 级别的空间隔离配合数据库层面的多租户管控、备份审计与资源管理，使记忆可追溯、可修正、可删除——SLA 具备写入合同的保障力。
• 人力投入降低。 传统方案中向量库、图库与记忆抽取逻辑各需专人维护；在新架构下，MemOS 负责记忆策略与调度，PolarDB-PG 负责数据库运维与弹性扩缩——技术团队可将精力集中于业务本身。

当系统逐步进入多 Agent 协作、用户记忆持续更新、技能经验沉淀和团队知识共享阶段，企业需要管理的便不再只是记忆的写入与召回，而是记忆在不同用户、任务和 Agent 之间的完整生命周期。

通过 MemOS 与 PolarDB-PG 的分层协同，企业可以在保持底层数据稳定可靠的同时，让记忆持续更新、按需调用，并随着业务规模扩展。

• PolarDB 控制台： 全面图形化配置，记忆引擎、模型服务、提取策略均支持白屏化管理；
• 极简 API： 提供 REST API 与客户端 SDK，自动完成记忆提取、融合与搜索；
• 生态兼容： 阿里云 PolarDB Agent Express/AgentRun/AgentScope 一体化整合。

一套 PolarDB，一个 MemOS，为 AI 应用提供持续可用的记忆能力。