📌 项目地址NevaMind-AI/memU | ⭐ 13,733 颗星 | 🔧 Python | 📜 NOASSERTION

痛点和方案

AI Agent的长期记忆一直是个烧钱坑。OpenAI的Assistant API里,单条对话越长,成本指数级增长。embedding-based记忆方案更糟——对话量上去后,每次检索都要计算相似度,token消耗大,召回还不保证精准。memU的README第一句话就划清了界限:它是memory harness,不是vector store。你把原始数据——对话记录、PDF、图片、URL——丢进去,它自动给你吐出一套结构化的记忆目录。Agent用的时候,按路径精确查找,不做向量相似度搜索。13733个star说明这事确实让不少人头疼过。

工作流程

memU的流水线分6步:

  1. Ingest —— 把每个来源存为Resource,附带模态类型和位置
  2. Preprocess —— 解析文本,给图片/视频加描述,转录音频,归一化输入
  3. Extract —— 把原始内容变成带类型的MemoryItem:profile、event、knowledge、behavior、skill、tool
  4. Organize —— 分类、交叉链接、嵌入、总结,形成可浏览的结构
  5. Write —— 输出紧凑的Markdown入口(index.mdmemory.mdskill.md)和子文档
  6. Retrieve —— 只返回当前用户/Agent/会话/任务相关的上下文

整个过程不保留原始对话,只写摘要进.md文件。查询时沿着目录树找到目标文件,读几行Markdown,不读原始数据。

文件系统结构

memU的输出是一个文件系统状的记忆包。顶层文件是紧凑的入口,对应的目录放更深的子文档,Agent需要时才打开。

.memu/
├── index.md
├── memory.md
├── skill.md
├── index/
│   ├── architecture.md
│   ├── api.md
│   └── files.md
├── memory/
│   ├── decisions.md
│   ├── product_context.md
│   └── open_questions.md
└── skill/
    ├── testing.md
    ├── release.md
    └── coding_style.md
入口 作用 子文档
index.md 工作区地图:有什么、在哪、怎么查 index/下的详细索引
memory.md 用户/Agent的核心记忆摘要(事实、偏好、事件) memory/下的明细
skill.md Agent学会的一切技能(工具使用、编码风格、测试流程) skill/下的具体技能

每个.md文件就是一条记忆,路径就是索引。你可以直接打开memory/文件夹看清Agent记住了什么。用cp -r备份,用git做版本管理。想删除某条记忆?删文件就行。想回滚?git revert

挂载点:将外部数据源变成目录

挂载点是一个有意思的设计。README里提到“mount points as resources for conversations, documents, images”。你可以把SQL查询结果或REST API响应挂载成一个目录,Agent就能按路径检索。这意味着不需要迁移数据,只在目录结构上建一个视图。比如你已有日志系统,挂载后Agent可以直接读取/logs/recent/下的摘要。

确定路径vs模糊搜索

向量检索靠embedding相似度,返回top-k,你永远不知道它漏了什么。memU是精确路径定位:问“Python技能”→直接读skill/coding_style.mdknowledge/domain_expertise/Python.md。代价是没了语义灵活性。用户问“你们用什么语言”,但文件名可能是lang_python.md,可能会匹配不上。memU通过交叉引用和挂载点来缓解——你可以在文件名预设别名,或者把不同格式的资源映射进目录树。

Token节省的真实代价

README写“reduce token cost by up to 10x”。不是炒作,算法很简单:

  1. 持续从原始对话中提取事实、偏好、技能,只写摘要进.md文件,不保留原对话。
  2. 查询时,沿着目录树找到目标文件,读文件内容(通常几行Markdown),不读原始数据。
  3. 交叉引用会拉进相关文件,但总量可控。

举例:一周20万字聊天记录,memU可能只提取出200行关键记忆。Agent被问到“通信风格”时,读preferences/communication_style.md,只有5行。从20万字到5行,差了4个数量级,10倍算保守。

前提是提取准确。README没说用什么模型做提取,也没给精度指标。我没实测过,这是你需要验证的点。

文档缺失与上手路径

memU的README有一个硬伤:没有给出任何命令行或API调用示例。PyPI badge指向memu-py包名,但正文里没有pip install,没有import memu,没有ingest()retrieve()的用法。开发者没法直接上手。

最直接的参考是看memUBot。README说它是“enterprise-ready proactive AI assistant”,安装不超过3分钟。官网memu.bot可以试用。如果你想少写代码,直接跑起Bot就能看到文件系统记忆在实际对话里怎么工作。

memUBot的主动记忆

Bot的特点是“proactive”(主动)。它可以根据记忆中提取的模式,在没有明确指令时自发推送信息。比如你每周五问天气,到周五它可能自己推过来。这不是if-then规则,而是基于记忆文件中提取的时间戳和重复行为统计——因为文件分类和交叉引用,Agent可以识别出周期性模式。

总结

memU切的痛点很准——长期记忆的高Token成本问题。用文件系统思路避开向量数据库的模糊性和膨胀体积,13733个star说明需求真实。但“memory harness”这个定位和缺乏API文档,让它在开箱即用上弱于成熟的RAG框架。

如果你在搭建需要持久化记忆的AI Agent,花半小时读memU的设计文档和memUBot源码,比从零造一个向量存储更高效。文件系统记忆的思路本身有价值,memU是第一个把这想法产品化的知名项目。我还没看到它在大规模生产环境的数据(如并发性能、内存占用),如果有跑过的朋友欢迎交流。

这篇文章对你有帮助吗?

发表回复