SimpleMem：给 LLM Agent 装一个会压缩的长期记忆，文本与多模态都管

Agent 记不住事，SimpleMem 想用压缩来解决

大语言模型 Agent 在长会话里经常忘事，尤其是跨天、跨项目的对话。把全部历史塞进上下文既贵又慢，简单截断又会丢掉关键信息。SimpleMem 的切入点不是做更大的上下文窗口，而是把记忆压缩成更小的语义单元再存起来。它的 README 明确写着“semantic lossless compression”，也就是用语义无损压缩来存储和检索长期记忆。目标用户是那些用 Claude Desktop、Cursor、LM Studio 这类 MCP 客户端的人，或者是直接用 Python 构建 Agent 的开发者。它不解决单次对话内的短期记忆，那是上下文窗口的事。它管的是会话结束之后，下次再见面时 Agent 还能想起你是谁、聊过什么、做过什么决定。

记忆的写入与读取：从原始文本到压缩单元的流程

从仓库结构和文档描述看，SimpleMem 的工作流大致是：先把原始对话或文档交给 LLM 做压缩，生成结构化的记忆单元，然后存进本地或远程的向量库。检索时，查询会被转成向量，召回相关记忆片段，再交给 LLM 判断哪些真正有用。这个“压缩”不是简单的摘要，而是提取实体、关系、事件，形成类似知识图谱的结构。v0.1.0 只支持文本，v0.2.0 加入图像、音频和视频，v0.3.0 把三个子项目合并成一个 unified 包。README 里提到，新的 unified 包通过第一个被调用的方法来自动选择文本或多模态后端，也就是说 SimpleMem 会根据输入类型自动路由到对应的处理管线。这个设计让上层 API 保持统一，但底层实际上是三套逻辑。

安装与接入：两条路，一条 MCP，一条 Python

安装很简单，README 给的命令是 pip install -e .，这是从源码安装的方式。PyPI 上也有 simplemem 包，所以也可以直接 pip install simplemem。接入方式分两种。文本记忆走 MCP，意味着任何支持 MCP 的客户端，比如 Claude Desktop、Cursor、Cherry Studio，都能通过标准协议连上 SimpleMem 的 MCP 服务器。文档里给出的公共端点是 mcp.simplemem.cloud，这是一个远程托管服务。完整的多模态功能则需要 Python 集成，因为 MCP 只支持文本。环境变量里最关键的是 OPENAI_BASE_URL，README 用 Atlas Cloud 作为示例，说明 SimpleMem 依赖一个 OpenAI 兼容的推理后端来执行压缩、检索和判断。也就是说，SimpleMem 本身不内置 LLM，它把模型调用外包给了外部服务，这既带来了灵活性，也引入了对第三方的依赖。

多模态记忆不是简单加个视觉编码器

v0.2.0 引入的多模态支持，覆盖文本、图像、音频和视频。README 声称在 LoCoMo 和 Mem-Gallery 两个基准上取得了新 SOTA，F1 分别达到 0.613 和 0.810，相对之前的最好结果提升了 47% 和 51%。这些数字来自项目方自己的报告，我没有跑过复现实验，所以只能当作参考。比较值得注意的是，多模态记忆的压缩方式应该和纯文本不同。图像不能像文本那样被“摘要”成几句话，音频里的语气和视频里的时序动作也很难用纯文本表达。SimpleMem 的做法很可能是把非文本模态先转成某种中间表示，比如字幕、描述、或向量特征，再与文本记忆统一存储。文档没有细说具体编码方式，但既然它宣称支持视频，那么处理长视频时的分段时间戳、关键帧提取、音频轨对齐，这些工程细节一定会影响实际效果。对于只想存几张图片的轻量用户，这套管线可能偏重。

EvolveMem：检索基础设施自己也会进化

v0.3.0 引入的 EvolveMem 是另一个思路。它不直接改进记忆压缩，而是让检索基础设施本身通过 LLM 驱动的闭环诊断来自我进化。README 给出的例子是，系统会发现原始设计中不存在的全新检索维度。这意味着 SimpleMem 的检索不是静态的，它会根据历史查询的失败模式，动态调整索引结构或召回策略。在 LoCoMo 上，EvolveMem 相对最强基线提升了 25.7%，在 MemBench 上提升 18.9%。这个机制听起来很有吸引力，但它有一个隐含成本：每一次自进化都需要调用 LLM 做诊断和重构，这会显著增加延迟和 token 消耗。对于一个需要低延迟响应的 Agent，这种后台进化可能会干扰正常服务。而且，自我进化的结果未必稳定，系统可能在一次诊断后把索引改成更差的结构，除非有严格的回滚机制。文档里没有提到这种保护措施，这是一个值得警惕的空白。

局限与失败模式：压缩是黑盒，依赖是明牌

SimpleMem 最大的局限在于它把记忆质量押注在外部 LLM 的压缩能力上。如果 LLM 在压缩时漏掉了某个关键细节，或者把两个相似事件合并错了，那么后续检索再准也找不回丢失的信息。README 宣传的是“语义无损”，但实际工程中，无损压缩只有在 LLM 对上下文理解完全正确时才成立，而 LLM 本身会幻觉。另一个问题是成本。每次写入记忆都要调用一次 LLM 做压缩，每次检索可能还要调用一次做判断，对于高频对话的 Agent，这会累积成不小的 API 费用。仓库没有提供离线运行的模式，所有核心功能都依赖网络和外部模型服务。如果你的 Agent 运行在隔离网络环境，或者你不想把对话数据发送给第三方推理服务，SimpleMem 就不适合。它也不是一个通用的记忆数据库，你不能把它当成向量数据库来用，因为它没有暴露底层的原始存储接口。

替代方案：Mem0 与直接的向量检索

同类项目里，Mem0 是一个常见的替代品。Mem0 也做 Agent 长期记忆，但它更强调提取实体和关系，并提供一个独立的记忆层，支持多种向量数据库后端。与 SimpleMem 相比，Mem0 的检索逻辑更偏向传统的 RAG，而 SimpleMem 的核心卖点是压缩和自进化检索。另一个更朴素的替代方案是直接使用向量数据库，比如 Chroma 或 FAISS，把每轮对话原文切块后存入，检索时用 embedding 相似度召回。这个方案没有压缩，但胜在透明，你能看到存进去的每条原始记录，不会出现 LLM 压缩导致的信息丢失。代价是存储和检索成本随对话量线性增长。SimpleMem 用压缩换取了存储效率，但它把语义完整性交给了模型判断，而直接向量检索把完整性交给了原始文本，各有取舍。对于敏感数据，后者更容易审计。

维护与升级成本：版本演进快，但路径清晰

SimpleMem 从 2026 年 3 月的 v0.1.0 到 5 月的 v0.3.0，两个月内发布了三个大版本，迭代速度很快。v0.3.0 把三个子项目合并成一个 unified 包，这意味着早期用户需要调整导入路径和 API 调用方式。仓库的 main 分支还在活跃更新，最近一次推送是 2026 年 7 月。许可证是 MIT，允许商用和修改，但如果你 fork 后自己维护，需要跟上上游的 API 变化。由于项目依赖外部 LLM 服务，升级时还要考虑后端兼容性，比如 OPENAI_BASE_URL 指向的服务是否支持新版本所需的模型能力。文档提供了中文、日文等多语言版本，但核心细节仍然集中在英文 README 里。对于生产环境，你需要自己盯住依赖的 LLM API 的定价变化和限流策略，因为 SimpleMem 的压缩和检索频率会直接放大这些成本。

编辑结论

SimpleMem 适合那些需要跨会话长期记忆、且愿意把记忆压缩逻辑交给 LLM 判断的 Agent 开发者，尤其是已经使用 MCP 兼容客户端的用户，或需要同时处理文本、图像、音频、视频记忆的多模态场景。它不适合对每次检索延迟有严格上限、或希望记忆行为完全可解释、可审计的生产环境，因为压缩与检索都依赖外部 LLM 的推理，失败模式和成本都难以精确预估。在采用前，先验证三件事：一是你使用的后端是否兼容 OpenAI 接口，并确认 OPENAI_BASE_URL 指向的服务能稳定处理大批量压缩请求；二是用你的真实对话数据跑一遍 LoCoMo 或 MemBench 风格的长对话任务，对比原始文本直接检索的准确率，确认压缩没有引入语义失真；三是检查 MCP 服务器在断网或弱网下的降级行为，因为记忆写入如果依赖远程推理，网络抖动会直接影响 Agent 的响应质量。SimpleMem 的定位是高效压缩而非绝对完整，它用有损压缩换存储与检索效率，这个交换是否划算，只能由你的任务来回答。

官方来源

1. aiming-lab/SimpleMem on GitHub
2. Issues
3. License: MIT
4. README
5. Releases