开源记忆框架 memU 深度解析：让 AI Agent 拥有真正的长期记忆能力

快速摘要
memU 是一款面向 7×24 小时持续运行的 AI Agent 设计的开源记忆框架，由 NevaMind-AI 团队开发，目前在 GitHub 上已获得近万颗星标。 它的核心思路是：把 AI 的"记忆"当作文件系统来组织——用文件夹（分类）、文件（记忆条目）、原始素材（资源层）三层结构，把对话、文档、图片等多模态信息自动提取并持久化为可查询的结构化记忆。与传统 RAG 系统最大的不同在于，memU 不做文档分块和向量检索的"拼凑式"回忆，而是让 AI 像人一样真正"记住"信息，同时把上下文窗口的 Token 开销大幅压缩。往下看，莫潇羽@无忆研习社 会为你从底层原理到实操部署做一次完整的拆解。

为什么 AI 需要"记忆框架"？

如果你经常跟各类 AI 对话工具打交道，一定遇到过这样的困扰：昨天刚告诉 AI 助手你的项目背景，今天打开新会话，它就把你忘得一干二净。哪怕你在同一轮对话里反复强调自己的偏好、习惯，一旦会话结束或上下文窗口溢出，一切都得从头来过。

这不是某一个产品的问题，而是当前大语言模型（LLM）的架构性局限。LLM 的"记忆"本质上依赖于上下文窗口（Context Window），也就是每次对话时一起发送给模型的那段文本。窗口有长度限制（即便是支持上百万 Token 的模型也不可能把所有历史对话塞进去），而且越长的上下文意味着越高的计算成本和越慢的响应速度。

目前业界解决这个问题主要有三种路径：

• 暴力堆上下文：把尽可能多的历史信息塞进上下文窗口。成本极高，且对话越长效果越差。
• 传统 RAG（检索增强生成）：把历史对话或文档切成小块，存到向量数据库里，每次对话时根据语义相似度检索出相关片段拼接到 Prompt 中。这是目前的主流方案，但它的本质是"文档搜索"而非"记忆"——它返回的是碎片化的文本块，而不是结构化的、经过理解和提炼的认知。
• 专用记忆框架：把 AI 与用户交互过程中产生的信息进行提炼、分类、关联，形成真正的"长期记忆"。memU 就是这条路径上的一个代表性开源项目。

理解了这个背景，你就能明白为什么开发者社区对 memU 这类记忆框架如此关注——它不是在做更好的搜索，而是在尝试给 AI 装上真正意义上的"大脑海马体"。

memU 项目概览

在正式进入技术细节之前，莫潇羽（无忆研习社 www.wuyi.wiki）先带大家快速了解一下 memU 的基本信息。

memU 由 NevaMind-AI 团队开发，是一个专门为长时间持续运行的 AI Agent 设计的记忆框架。它的开源仓库托管在 GitHub 上，地址是：

https://github.com/NevaMind-AI/memU

项目在 GitHub 上的星标数已接近一万，社区活跃度很高，近期持续有新版本发布。2026 年 2 月初发布的 v1.4.0 是目前的最新正式版本，增加了内联记忆引用、显著性感知记忆（Salience-Aware Memory）、工具类记忆等多项新特性。官方网站是 https://memu.pro ，PyPI 上的包名是 memu-py，要求 Python 3.13 及以上版本。

此外，NevaMind-AI 团队还提供了配套的后端服务（memU-server）和前端管理界面（memU-ui），分别托管在独立的 GitHub 仓库中，支持 Docker 一键部署。对于不想自己搭建环境的开发者，还有托管云服务 memu.so 可以直接体验。

memU 采用 AGPL-3.0 协议开源，这意味着你可以自由使用和修改它，但如果你基于它提供网络服务，需要将你的修改也开源出来。

理解 AI 记忆的技术背景

在深入 memU 之前，莫潇羽@无忆研习社觉得有必要先帮大家补一些关于"AI 记忆"的技术背景，这样后面理解 memU 的架构设计时会更加顺畅。

上下文窗口的先天局限

大语言模型的"记忆"能力完全依赖于上下文窗口。你可以把上下文窗口想象成一个人的"工作台"——台面上摆着的东西它都能看到、都能用，但工作台的面积是有限的。当前主流模型的上下文窗口从几万 Token 到上百万 Token 不等，但即使是最大的窗口，面对持续数周甚至数月的交互历史，也远远不够用。

更关键的问题是，上下文窗口越大，推理成本越高。如果你的 Agent 需要 7×24 小时在线，每次对话都把所有历史记录塞进上下文，光是 Token 费用就会让预算迅速耗尽。这也正是 memU 要着力解决的核心痛点之一。

向量数据库：解决了一半的问题

向量数据库（如 Pinecone、Weaviate、Chroma 等）的出现部分缓解了这个问题。它们的工作原理大致是这样的：把文本通过嵌入模型（Embedding Model）转换成高维向量（通常是 1536 维或 3072 维的浮点数数组），存入专门的向量数据库。查询时，把用户的问题也转成向量，然后用余弦相似度或欧氏距离在库中找出最接近的条目。

这种方法速度快、成本低，但有两个本质缺陷。第一，它只能找到"看起来像"的内容，而不是"真正相关"的内容。 向量相似度衡量的是语义表面的接近程度。比如"用户在三月份表示想换工作"和"用户五月份提到对现在的工作很满意"，向量检索可能把它们都返回为"工作"相关的结果，但它无法识别出两者之间存在态度变化。第二，它把每条记忆当作孤立的个体处理。 向量数据库中的每条记录都是独立的，它们之间没有结构化的关联关系。你的 Agent 可能知道"用户喜欢咖啡"，但它不知道这个偏好是什么时候形成的、是在什么情境下提到的、跟用户的哪些其他习惯有关联。

记忆框架：从"搜索"到"理解"的跨越

memU 所代表的记忆框架，试图解决的就是向量数据库留下的这"另一半"问题。它不是要替代向量数据库——事实上 memU 自己也在底层使用了 pgvector 来做向量检索——而是在向量检索的基础上增加了一层结构化的理解和组织能力。

打个比方：如果说向量数据库是一个装满了便利贴的抽屉，每张便利贴上写着一个信息片段，你需要的时候去翻找；那么 memU 就是一个分门别类的笔记本系统，每个主题有自己的章节，信息不仅被记录下来，还被理解、归纳、关联，形成了有组织的知识结构。

核心设计理念：记忆即文件系统

memU 最让人眼前一亮的设计思想，是把 AI 的"记忆"类比为计算机的文件系统。这个类比不是停留在概念层面的，而是贯穿了整个架构的实际实现。

在传统的向量数据库方案中，AI 的"记忆"是一堆高维向量——人类无法直接阅读和理解它们，调试起来也很困难。你不知道 AI 到底"记住"了什么，也无法手动干预或修正它的记忆。

memU 换了一种完全不同的思路。在 memU 中，记忆最终以人类可读的 Markdown 文件形式存储。这意味着你可以像打开一个文件夹一样，直接浏览 AI 到底记住了什么，而且可以手动编辑、删除或迁移这些记忆文件。

这种"文件系统式"的设计具体体现为一个从底到上的三层结构：

memory/
├── preferences/                     ← 记忆分类（Category）
│   ├── communication_style.md       ← 具体记忆文件
│   └── topic_interests.md
├── relationships/
│   ├── contacts/
│   └── interaction_history/
├── knowledge/
│   ├── domain_expertise/
│   └── learned_skills/
└── context/
    ├── recent_conversations/
    └── pending_tasks/

在这个结构中，最外层的文件夹就是记忆分类（Memory Category），里面的每个 Markdown 文件就是一个聚合的记忆文件，而支撑这些文件的底层数据则是从原始对话、文档、图片等多模态输入中提取出来的离散记忆条目（Memory Item），以及原始资源本身（Resource）。

莫潇羽@无忆研习社在这里做一个更通俗的对比，帮大家建立直觉：

这种设计带来了几个非常实用的好处。

第一，可读性极强。 记忆以 Markdown 文件的形式存在，你随时可以打开来查看 AI 到底记住了什么。对于调试和审计来说，这比盯着一堆浮点数组成的向量要友好太多了。

第二，可操作性极强。 你可以像管理文件一样管理 AI 的记忆：导出备份、跨实例迁移、手动编辑修正错误记忆，甚至可以给不同的 AI Agent 挂载不同的记忆"分区"。

第三，支持跨维度关联。 不同分类下的记忆文件可以引用和共享同一个记忆条目。比如，用户在某次对话中提到"我喜欢在周末早上喝手冲咖啡"，这个事实既可以出现在"饮食偏好"分类中，也可以被"作息时间"分类引用。这种网状的关联结构比扁平的向量存储能更准确地反映真实世界的知识关系。

值得一提的是，这个"记忆存储为可读文件"的设计理念，跟一些大厂（如 Anthropic）在他们的 AI 产品中采用的 Skills 设计思路不谋而合——都是通过文件化的方式让 AI 建立结构化的认知基础，而非单纯依赖向量检索。

三层架构详解：从原始数据到可用记忆

上面我们已经了解了 memU 的文件系统隐喻。接下来，莫潇羽@无忆研习社带大家更深入地看看这三层架构各自的职责和工作方式。

第一层：资源层（Resource Layer）

这是 memU 的数据入口。所有输入——无论是文本对话、JSON 格式的聊天记录、上传的文档、图片乃至视频和音频——都首先以原始形式存储在资源层中。资源层不做任何加工处理，它的职责就是忠实地保存原始数据，确保后续的任何记忆提取都能追溯到源头。

这种"先存原始数据再处理"的设计是有讲究的。在实际的 AI 应用中，你的需求和理解能力是会随时间变化的。今天你可能只关心对话中的用户偏好，但三个月后你可能需要回溯分析对话中的情感变化趋势。如果在入口处就丢弃了原始数据，后续的分析就无从谈起。

memU 的资源层支持多种模态的输入：

• 文本 / 对话：最常见的场景，用户与 AI 的聊天记录
• 文档：PDF、Word、Markdown 等格式的文件
• 图片：通过视觉模型（Vision Model）提取视觉概念和描述
• 视频 / 音频：提取关键帧或转写文本后进入处理流程

所有这些不同模态的数据，在资源层统一为可处理的格式后，就进入了下一层的提取流程。

第二层：记忆条目层（Memory Item Layer）

这一层是 memU 的"加工车间"。系统会从资源层的原始数据中，自动提取出离散的、有明确语义的记忆条目。

举个例子，假设用户在一段对话中说了这样一句话：

"我每天早上八点开始工作，中午一般不吃饭，下午四点左右会犯困，所以那个时候别给我安排重要会议。"

memU 的记忆提取引擎会从这段话中识别出多个独立的记忆条目：

• 用户的工作开始时间是早上八点
• 用户中午通常不吃饭
• 用户下午四点左右精力下降
• 用户不希望在下午四点左右安排重要会议

每个记忆条目都是独立的、原子化的事实单元，可以被单独索引、检索和引用。这跟 RAG 系统中简单地"把文本切成 512 个 Token 一块"有本质区别——RAG 切的是物理上的文本块，memU 提取的是语义上的知识点。

在 v1.4.0 版本中，memU 还引入了"显著性感知记忆"（Salience-Aware Memory），通过强化追踪（Reinforcement Tracking）机制来动态评估每条记忆的重要程度。如果某条记忆被反复提及或频繁被检索命中，它的显著性权重就会自动提升；反之，长期未被引用的记忆则会逐渐降低优先级。这种机制模拟了人类大脑中记忆随时间和使用频率而强化或衰减的自然规律。

第三层：记忆分类层（Memory Category Layer）

这是 memU 三层架构中最接近人类认知方式的一层。记忆分类层负责将底层的离散记忆条目聚合成有组织的知识文件——也就是前面提到的 Markdown 文件。

这个聚合过程是自动完成的。当新的记忆条目被提取出来后，memU 的分类引擎会：

• 自动判断这条记忆应该归属到哪个已有分类：比如"用户喜欢喝手冲咖啡"应该归入"饮食偏好"分类。
• 如果没有合适的分类，则自动创建新分类：比如第一次出现与用户宠物相关的记忆时，系统会自动新建一个"宠物信息"分类。
• 跨分类引用：同一条记忆可以被多个分类文件引用。前面提到的"周末早上喝手冲咖啡"就可以同时出现在"饮食偏好"和"周末习惯"两个分类中。

在记忆分类层，每个分类文件本质上是一份持续更新的 Markdown 摘要，汇总了该主题下所有相关的记忆条目，并标注了引用来源。当 AI Agent 需要理解用户时，它不需要逐条翻阅底层的记忆条目，只需要阅读对应主题的分类文件就能快速获得全局认知。

三层之间形成了一个完整的反馈闭环。 新信息进入系统后，先在资源层保存原始形态，然后逐步提炼为有明确含义的记忆条目，再被组织到合适的分类文件中。随着记忆在层级间向上流动，含义越来越清晰，结构越来越稳定。而当 AI Agent 执行任务需要查询记忆时，检索则是从顶层向下进行——先在记忆分类层定位相关主题，再根据需要深入到具体的记忆条目，必要时还可以回溯到原始资源。

记忆的完整生命周期

了解了三层架构之后，我们来看 memU 中一条记忆从诞生到被使用的完整生命周期。莫潇羽@无忆研习社把它梳理成以下几个阶段：

阶段一：输入处理

无论是一段用户对话、一份上传的文档还是一张图片，进入 memU 的第一步都是标准化处理。系统会识别输入的类型（对话、文档、图片等），提取核心内容，并转换成统一的内部格式。对于图片，会通过视觉模型提取视觉描述；对于音视频，会先进行转写或关键帧提取。

阶段二：记忆提取与分层存储

标准化后的内容会经过记忆提取引擎（由 LLM 驱动）的处理，自动识别并提取出独立的事实、偏好、事件等记忆条目。这些条目会被打上时间戳和来源标记，然后按照"档案 / 事件 / 知识 / 行为"等维度进行分类，分别存入对应的记忆分类文件中。底层使用向量数据库（如 PostgreSQL + pgvector）或内存存储实现持久化。

阶段三：智能管理

记忆入库之后并不是一劳永逸的。memU 有一套持续运行的智能管理机制：

• 自动归类：新产生的记忆会被自动归入已有的主题分类，或者触发新分类的创建。
• 过期清理：对于时效性明确的记忆（比如"用户下周有一个会议"），在时间过去之后会被标记为过期。
• 重要度标签：系统会根据记忆被引用的频率和上下文中的重要程度，动态调整每条记忆的权重。
• 重复合并：当多条记忆表达的是同一个事实时（比如用户在不同对话中多次提到自己的职业），系统会将它们合并为一条，避免冗余。

阶段四：检索使用

这是记忆真正发挥价值的环节。当 AI Agent 需要回忆某个信息时，memU 提供了两种检索模式（后面会详细展开），能够快速、准确地找到相关记忆并注入到 Agent 的上下文中。

阶段五：迭代优化

memU 还内置了一个自我进化的机制。随着使用时间的增长，系统会：

• 定期检查记忆结构是否合理，必要时调整分类体系
• 根据检索命中率调优检索参数
• 分析记忆的使用模式，优化存储策略

这种"记忆会自我进化"的设计，是 memU 区别于简单的向量数据库方案的关键特征之一。它让 AI Agent 不只是在被动地存储信息，而是在主动地理解、组织和优化自己的知识体系。

双模式检索机制：RAG 与 LLM 的互补

记忆存进去了，怎么取出来用？这是所有记忆框架都要面对的核心问题。memU 在这里的设计非常务实——它提供了两种可以按需选择的检索模式。

RAG 模式（基于向量嵌入的快速检索）

这是默认的检索方式。memU 会为每条记忆条目生成向量嵌入（Embedding），存储在向量数据库中。查询时，将用户的提问或当前上下文转换为向量，通过余弦相似度找到最相关的记忆。

这种方式的优点很明显：

• 速度极快：向量相似度计算可以在毫秒级完成
• 成本极低：检索过程不需要调用 LLM，没有额外的 Token 消耗
• 适合后台监控：因为不消耗 LLM 资源，可以持续运行实时匹配，非常适合需要 7×24 小时运行的 Agent

当你调用 memU 的 retrieve() 方法并指定 method="rag" 时，系统会用向量相似度从记忆库中找出最相关的条目，并自动按相关性排序返回。

LLM 模式（基于大语言模型的深度推理）

对于一些复杂的查询，单纯的向量相似度匹配可能不够用。比如用户问："根据我过去三个月的项目讨论，我接下来最应该关注什么？"——这种需要跨时间、跨主题综合推理的查询，简单的向量相似度很难给出好的答案。

在 LLM 模式下，memU 会让大语言模型直接"阅读"记忆分类文件和原始资源，进行深层的语义理解和推理。这种方式的特点包括：

• 意图预测：LLM 可以在用户明确提问之前，就推断出用户可能需要的信息
• 查询演化：随着上下文的发展，LLM 会自动优化检索策略
• 提前终止：当收集到足够的上下文信息时，自动停止检索以节省资源

两种模式各有所长，莫潇羽@无忆研习社建议的使用策略是：日常运行时用 RAG 模式保持低成本的实时感知，遇到复杂推理需求时切换到 LLM 模式获取深度理解。

用表格来对比一下两种模式：

在实际的代码层面，两种模式的切换非常简单，只需要在调用 retrieve() 时更改 method 参数即可。

核心 API 详解与代码实战

了解了原理之后，我们来看看 memU 的核心 API 到底怎么用。memU 的 API 设计非常简洁——核心就两个方法：memorize() 和 retrieve()，分别对应"存"和"取"。

memorize() — 持续学习管道

memorize() 是 memU 的数据入口。你把需要让 AI"记住"的内容通过这个方法传入，系统会自动完成提取、分类、存储的全流程。

from memu import MemoryService

# 初始化记忆服务
service = MemoryService(
    llm_profiles={
        "default": {
            "provider": "openai",          # 也支持 openrouter 等其他提供商
            "api_key": "your_api_key",
            "chat_model": "gpt-4o-mini",
            "embed_model": "text-embedding-3-small",
        },
    },
    database_config={
        "metadata_store": {"provider": "inmemory"},  # 也可以用 postgres
    },
)

# 让 AI 记住一段对话
result = await service.memorize(
    resource_url="path/to/conversation.json",  # 文件路径或 URL
    modality="conversation",                    # 支持: conversation | document | image | video | audio
    user={"user_id": "user_123"}                # 可选：限定到特定用户
)

# 返回结果
print(result)
# {
#     "resource": {...},      # 存储的资源元数据
#     "items": [...],         # 提取出的记忆条目（即时可用）
#     "categories": [...]     # 自动更新的分类结构
# }

这个方法有几个值得注意的细节：

• 零延迟处理：调用 memorize() 后，提取出的记忆条目立即可用于检索，不需要等待异步处理完成。
• 自动分类：你不需要手动给记忆打标签或指定分类，系统会自动判断。
• 交叉引用检测：新记忆会自动与已有记忆进行交叉比对，识别模式和关联关系。
• 多模态支持：通过 modality 参数指定输入类型，系统会调用对应的处理管线。

retrieve() — 双模式智能检索

retrieve() 是从记忆库中取回信息的入口。它支持传入多条查询，并可以通过 where 参数做精确的范围过滤。

# RAG 模式 —— 快速检索
result = await service.retrieve(
    queries=[
        {"role": "user", "content": {"text": "他们的偏好是什么？"}},
        {"role": "user", "content": {"text": "告诉我工作习惯"}}
    ],
    where={"user_id": "user_123"},  # 可选：范围过滤
    method="rag"                     # 快速向量检索
)

# LLM 模式 —— 深度推理
result = await service.retrieve(
    queries=[
        {"role": "user", "content": {"text": "根据已有信息，这个用户最可能的下一步行动是什么？"}}
    ],
    where={"user_id": "user_123"},
    method="llm"                     # 深度语义推理
)

# 返回结构
# {
#     "categories": [...],         # 相关的记忆分类（按优先级排序）
#     "items": [...],              # 具体的记忆条目
#     "resources": [...],          # 原始来源（可追溯）
#     "next_step_query": "..."     # 预测的后续查询（用于主动推荐）
# }

where 参数的过滤能力很灵活：

• where={"user_id": "123"} — 只检索特定用户的记忆
• where={"agent_id__in": ["1", "2"]} — 多个 Agent 之间的记忆协调
• 省略 where — 全局记忆检索

返回结果中的 next_step_query 字段特别值得关注——它是系统根据当前查询上下文，预测的用户可能的后续问题。在构建主动式 AI Agent 时，这个字段可以用来提前准备好下一轮对话需要的上下文。

自定义 LLM 提供商

memU 并不绑定 OpenAI。在 v1.4.0 中，你可以通过 llm_profiles 配置使用任意支持 OpenAI 格式 API 的服务商，包括通过 OpenRouter 接入各种模型：

service = MemoryService(
    llm_profiles={
        "default": {
            "provider": "openrouter",
            "client_backend": "httpx",
            "base_url": "https://openrouter.ai",
            "api_key": "your_openrouter_api_key",
            "chat_model": "anthropic/claude-3.5-sonnet",
            "embed_model": "openai/text-embedding-3-small",
        },
    },
    database_config={
        "metadata_store": {"provider": "inmemory"},
    },
)

这种灵活的配置方式意味着你可以根据自己的场景和预算，自由选择最合适的模型组合。

从零开始的部署指南

理论讲完了，接下来是大家最关心的实操环节。莫潇羽@无忆研习社按照从简单到复杂的顺序，分别介绍三种部署方式。

方式一：内存模式（最快上手）

如果你只是想先试试 memU 的效果，内存模式是最快的起步方式。所有数据存在内存中，不需要额外的数据库服务，但程序退出后数据会丢失。

环境要求：

• Python 3.13 或更高版本
• 一个 OpenAI API 密钥（或者支持兼容格式的其他 API 密钥）

安装步骤：

# 克隆仓库
git clone https://github.com/NevaMind-AI/memU.git
cd memU

# 安装项目（开发模式）
pip install -e .

# 设置 API 密钥
export OPENAI_API_KEY=your_api_key

# 运行内存模式测试
cd tests
python test_inmemory.py

运行测试脚本后，你会看到 memU 完整的主动记忆工作流程：从摄入多个对话文件，到自动提取记忆，再到基于上下文的智能检索。

方式二：PostgreSQL 持久化模式（推荐用于开发）

对于正式的开发和测试环境，建议使用 PostgreSQL + pgvector 作为持久化后端。这种方式下数据不会因为程序重启而丢失。

第一步，启动带 pgvector 扩展的 PostgreSQL：

docker run -d \
  --name memu-postgres \
  -e POSTGRES_USER=postgres \
  -e POSTGRES_PASSWORD=postgres \
  -e POSTGRES_DB=memu \
  -p 5432:5432 \
  pgvector/pgvector:pg16

这条命令做了几件事：使用 pgvector/pgvector:pg16 这个预装了 pgvector 扩展的 PostgreSQL 16 镜像，创建一个名为 memu 的数据库，并把端口映射到本地的 5432。

什么是 pgvector？ pgvector 是 PostgreSQL 的一个开源扩展，它为 PostgreSQL 添加了向量数据类型和向量相似度搜索的能力。有了 pgvector，你就可以在一个数据库里同时存储结构化数据和向量数据，而不需要单独维护一个向量数据库。memU 利用 pgvector 来存储记忆条目的向量嵌入，实现 RAG 模式下的快速相似度检索。

第二步，运行持久化存储测试：

export OPENAI_API_KEY=your_api_key
cd tests
python test_postgres.py

第三步（可选），验证数据确实持久化了：

# 连接到 PostgreSQL 查看数据
docker exec -it memu-postgres psql -U postgres -d memu

# 在 psql 中查看表结构
\dt

# 查看已存储的记忆条目
SELECT * FROM memory_items LIMIT 5;

方式三：Docker 容器化部署（推荐用于生产环境）

对于生产环境，NevaMind-AI 提供了 memU-server 和 memU-ui 的 Docker 镜像，支持一键部署完整的记忆管理服务。

# 拉取并启动 memU-server
docker pull nevamindai/memu-server:latest

export OPENAI_API_KEY=your_api_key

docker run --rm -p 8000:8000 \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  nevamindai/memu-server:latest

启动后，你可以通过 HTTP API 与 memU 交互：

# 存储一段对话记忆
curl -X POST http://127.0.0.1:8000/memorize \
  -H "Content-Type: application/json" \
  -d '{
    "content": [
      {"role": "user", "content": {"text": "我喜欢在安静的环境中工作"}, "created_at": "2026-02-20 10:00:00"},
      {"role": "assistant", "content": {"text": "好的，我记住了您偏好安静的工作环境"}, "created_at": "2026-02-20 10:00:05"}
    ]
  }'

# 检索记忆
curl -X POST http://127.0.0.1:8000/retrieve \
  -H "Content-Type: application/json" \
  -d '{"query": "用户的工作偏好"}'

memU-ui 前端则需要配合 memU-server 运行：

# 确保 memU-server 已启动，然后启动前端
git clone https://github.com/NevaMind-AI/memU-ui.git
cd memU-ui
npm i
npm run dev

启动后你会得到一个可视化的记忆管理面板，可以直观地浏览、查询和管理 AI Agent 的所有记忆数据。

部署避坑提示

在实际部署中，莫潇羽@无忆研习社根据社区反馈整理了一些常见问题：

• Python 版本要求：memU 明确要求 Python 3.13+，低版本会报各种兼容性错误。如果你的环境中 Python 版本较低，建议使用 pyenv 或 Docker 来管理。
• pgvector 扩展激活：启动 PostgreSQL 容器后，如果你是手动建库而非使用默认的 memu 数据库，别忘了在对应数据库中执行 CREATE EXTENSION IF NOT EXISTS vector; 来激活 pgvector 扩展。
• API 密钥安全：在生产环境中，切勿在命令行或代码中硬编码 API 密钥。建议使用环境变量、密钥管理服务或 .env 文件（并确保 .env 在 .gitignore 中）。
• 数据持久化：如果使用 Docker 部署 PostgreSQL，记得挂载数据卷（-v /your/data/path:/var/lib/postgresql/data），否则容器删除后数据会全部丢失。

深入理解 pgvector：memU 的存储引擎

pgvector 是 memU 在持久化模式下的核心存储组件，理解它的工作方式有助于你更好地优化 memU 的性能。这里莫潇羽@无忆研习社多花一些篇幅来介绍。

pgvector 是 PostgreSQL 的一个开源扩展，由 Ankane 团队开发维护。它为 PostgreSQL 增加了一个 vector 数据类型，以及配套的向量距离计算操作符和高效的索引结构。在 memU 中，每条记忆条目的文本内容会被嵌入模型转换成向量后存入 pgvector，用于支持 RAG 模式下的快速相似度检索。

pgvector 支持几种常用的距离度量方式：

• <->：L2 距离（欧氏距离），计算两个向量之间的直线距离
• <=>：余弦距离（1 - 余弦相似度），衡量两个向量方向上的差异，跟向量长度无关
• <#>：内积（Inner Product），与余弦相似度密切相关

在 memU 的场景中，余弦距离是最常用的，因为我们关心的是语义方向上的相似性，而不是向量的绝对大小。

pgvector 提供了两种索引类型来加速大规模数据的检索：

IVFFlat 索引：把向量数据用 k-means 算法聚成多个簇，查询时只在最接近的几个簇里搜索，大幅减少计算量。适合数据量已经稳定、需要极高查询速度的场景。需要注意的是，创建 IVFFlat 索引之前必须先有足够的数据（建议至少几千条），否则索引效果会很差。

-- 创建 IVFFlat 索引的示例
C