三大 AI Agent 记忆架构横评：mem0、Letta、PLUR 各有何取舍

mem0、Letta 和 PLUR：三种记忆架构，三种不同的赌注

简而言之：mem0 把记忆当作存储问题来解决——从对话中提取事实，用 LLM 去重，存入向量数据库。Letta 把记忆当作 Agent 操作系统问题来解决——构建一个运行时，让记忆在持久进程中天然地被管理。PLUR 把记忆当作交换问题来解决——让 engram 在 Agent 触及的每个工具之间可移植，淘汰过时的知识，并让 Agent 共享它们学到的东西。这三种架构并非在争夺同一批用户。它们在"约束在哪里"这个问题上做了不同的赌注。

记忆问题到底是什么

AI Agent 默认是无状态的。对话上下文在会话之间会重置。周一做的修正到了周二就消失了。在一个工具中建立的约定对另一个工具是不可见的。

每种记忆系统表面上对这个问题给出的答案都一样：附加持久化存储，存储学到的东西，下次取回来。真正的问题是架构层面的：存在哪里、什么格式、如何检索、以及当事实老化或冲突时会发生什么。

三个项目为这些问题构建了认真的答案。它们各自选择了不同的层来优化。

mem0：记忆即存储服务

mem0（融资 2400 万美元，截至 2026 年中 GitHub 星标 52,000 颗）把记忆定义为一个托管 API。Agent 调用 m.add() 和 m.search()。mem0 处理提取、去重和检索。内部架构遵循分层管道：

• 提取：LLM 一次处理从对话中识别"值得记忆"的内容（用户事实、偏好、声明的目标）
• 去重：第二次 LLM 处理将候选内容与已有记忆比对，解决冲突
• 存储：去重后的记忆落入向量数据库（支持 25+ 后端，包括 Qdrant、Pinecone、Weaviate、pgvector）
• 检索：相似性搜索返回给定查询的 Top-N 条记忆

这很干净。API 表面积极简。将它嵌入现有 Agent 需要不到十行代码。图记忆扩展（mem0 v0.2+）增加了关系存储："user likes Python" 成为属性图的一条边，支持更丰富的关联召回。

权衡所在：

LLM 提取步骤同时也是成本步骤。每个可能产生新记忆的对话轮次都会触发一次 LLM 调用来决定保留什么。在规模上，这会累积——而且提取质量取决于你路由到的模型。更便宜的模型会遗漏细微的修正。更强的模型每次提取成本很高。

mem0 中的记忆也不会衰减。十二个月前存储的偏好与昨天存储的偏好具有相同的检索权重。对于有几个月累积上下文的长期运行 Agent，这意味着检索噪声不断增加：Agent 会将不再适用的旧偏好与当前偏好一起呈现。去重步骤能捕捉直接矛盾（"user prefers Python" vs "user now prefers Go"），但无法捕捉过时。旧事实变得无关紧要却没有被明确反驳的渐进漂移，对它来说是不可见的。

mem0 是一个单 Agent 孤岛。你的 Claude Code 集成中积累的记忆不会传播到你的 Cursor 集成或 Slack 机器人。每个 Agent 实例都有自己的记忆存储。

Letta：记忆即 Agent 操作系统

Letta（融资 1000 万美元）采用了不同的方法。Letta 不是将记忆作为服务附加到 Agent 上，而是直接构建 Agent 运行时本身，让记忆在持久进程中原生管理。核心抽象是 MemGPT 架构（来自 Packer 等人 2023 年的论文，arXiv:2310.08560）：一种层级记忆系统，其中 LLM 管理自己的上下文窗口，显式地将信息在不同的记忆层之间调入和调出。

Letta 运行时维护四个记忆区域：

• 核心记忆：始终在上下文中，包括人格和用户事实（有界限，约 2K tokens）
• 召回记忆：可搜索的对话历史（向量存储，按需查询）
• 归档记忆：无界限的长期存储（通过显式函数调用查询）
• 工作上下文：当前任务状态

Agent 本身作为 Letta 服务器进程运行，自己决定何时搜索归档记忆、何时将内容调入核心记忆、何时写入新事实。记忆管理不是旁通道：它是 Agent 作为推理循环一部分来行使的一等能力。

权衡所在：

Letta 的优势是一致性。因为 Agent 控制自己的记忆，所以没有有损的提取步骤——Agent 自己决定什么重要。修正是显式的。矛盾在推理循环中解决，而不是在事后 LLM 去重步骤中解决。

代价是基础设施。运行 Letta 意味着运行一个持久的 Agent 服务器。有状态进程模型使 Letta 非常适合长期运行的自主 Agent，但不太适合那些希望记忆跟随用户跨越不同界面的工具。在 Letta Agent 中做的修正不会延续到你的 IDE 代码助手、邮件客户端的 AI 助手或 Letta 运行时之外的任何其他工具。

和 mem0 一样，Letta 也没有实现置信度衰减。记忆由 Agent 的推理管理，而不是由时间加权检索系统管理。六个月没有被问到某个话题的 Agent 没有机制让该知识老化。它以全检索权重留在归档记忆中。

PLUR：记忆即交换层

PLUR 采取了结构上不同的立场。PLUR 不是构建更好的存储服务或更智能的 Agent 运行时，而是构建使记忆可在工具之间可移植和可交易的那一层。

核心单元是 engram——一个原子的、带类型的断言，存储为 ~/.plur/ 中人类可读的 YAML 文件。一个 engram 如下所示：

id: ENG-2026-0412-001
statement: "Deploy target for the trading module is nightshift.internal:8080 — use rsync, not scp"
type: procedural
domain: infrastructure.deploy
confidence: 0.85
created: 2026-04-12
last_verified: 2026-07-01

每个 engram 都携带一个置信度分数。检索系统是反馈训练的：当注入的 engram 有帮助时，它的分数上升。当它没有 surfaced 任何有用的东西时，它会衰减。长时间未被确认有用的 engram 是退役的候选者——系统会遗忘它们，正如人类长期记忆会淘汰未被强化的信息一样。激活模型衍生自 ACT-R（Anderson 等人，《心理整合理论》，《Psychological Review》，2004），其中记忆强度是近因和使用频率的函数。

检索：三种模式，一个本地栈

PLUR 的检索栈完全是本地的——不需要 API 调用：

• 仅 BM25：15ms 同步，零依赖。在延迟重要的热路径中使用
• 混合 BM25 + embeddings：首次运行约 2 秒，缓存后约 200ms，通过 @huggingface/transformers 使用 all-MiniLM-L6-v2。与仅 BM25 相比，Hit@K 检索准确率翻倍
• Agentic 搜索：约 1 秒异步，LLM 辅助的多步检索，用于复杂查询

合并使用 Reciprocal Rank Fusion（RRF），它组合来自稀疏和密集搜索的排名列表，无需分数归一化。在 LoCoMo 基准测试（Maharana 等人，2024——一个 300 对话的数据集，测试长期对话记忆）上，agentic PLUR 在 100% 检索率下达到 60% 准确率和 1.0 MRR。单跳事实召回在 agentic 模式下是 100%。已知弱点是多跳推理（33%），即系统需要链接多个 engram 来回答问题——这正通过 meta-engram 聚合来解决。

关于基准测试格局的背景：Zep 使用 GPT-4o 在 LongMemEval 上达到 71.2%。Supermemory 声称使用 8 变体集成和多数投票回答达到 98.6%。这些数字是在不同的基准测试和不同的设置上——不能直接比较——但它们将 PLUR 的检索准确率定位在：它在直接召回上表现良好，在多跳边缘上落后。

交换层使能了什么

mem0 和 Letta 未解决的架构差异是跨工具可移植性。因为 engram 是磁盘上标准路径（~/.plur/）中的文件，每个集成了 PLUR MCP 服务器的工具都读写相同的 engram。在 Claude Code 中做的修正立即在 Cursor、Hermes 和 OpenClaw 中可用——无需同步步骤，无需 API 调用，无需数据导出。~/.plur/ 目录就是记忆。

这是改变分析单位的"还有一件事"。问题不再是"这个 Agent 有记忆吗？"而是变成了"记忆跟随用户，还是被困在一个工具的孤岛中？"

跨设备同步通过与任何文件同步相同的方式处理——git、Syncthing、Dropbox——因为 engram 就是文件。不需要专有的同步协议。

知识包：记忆即一等数据产品

mem0 和 Letta 没有实现的第二个能力是交换本身。PLUR 发货知识包——策划好的、带版本的 engram 捆绑包，发布到 PLUR 注册表。一个包可能编码项目的部署约定、公司的 API 怪癖或来之不易的调试工作流。安装包的 Agent 立即获得知识，无需从零开始学习 token 成本。

单位经济学遵循一个简单测试：包的价格是否小于每个新 Agent 实例从头重新学习相同知识的 token 成本？对于一个团队运行十个针对同一代码库的 Agent 实例，学习成本乘以十。包一次性支付这笔费用。

这与模型权重不同。知识包是可审查的：每个 engram 都是可读的、可修正的、可删除的。你可以审计已安装的包知道什么。你无法对微调做这件事。

比较这些架构

Token 经济问题

注入记忆是有成本的。问题是选择性注入是否比完整上下文转储更便宜——以及便宜多少。

一个团队在每次轮次发送 3,000 token 的 CLAUDE.md 系统提示，以每百万 token 15 美元（2026 年中 Opus 定价）计算，每次轮次上下文费用为 0.045 美元。以每个开发者每天 200 轮次、五人团队计算，每天 45 美元用于大多数轮次不使用的后台上下文。

PLUR 的混合检索每次轮次注入 5–10 个 engram——通常 200–400 token 的目标记忆。以相同定价，每次轮次 0.003–0.006 美元，比每次轮次减少 87–93%，还未计入更小上下文也意味着更短推理这一事实。在 Datacore 基准测试（内部，n=218 任务）上，带 PLUR 注入的 Haiku 在导航和可发现性任务上优于不带记忆的 Opus。较弱的模型从目标注入中受益最大，因为它们缺乏从大型无差异化上下文块中过滤噪声的能力。

mem0 在存储成本之上增加了 LLM 提取成本。每个可能产生新记忆的轮次都会触发一次 LLM 调用进行提取，可能还有第二次调用进行去重。Letta 将记忆管理成本折叠到 Agent 的推理预算中——它用模型 token 而不是 API 调用来支付记忆，这使其更难隔离但也不会更便宜。

在它们之间选择

mem0 适合需要记忆但集成工作最少的 Agent，不需要跨工具共享。如果你有一个 Agent、一个集成，想在不构建基础设施的情况下加入记忆，mem0 是最快路径。代价是提取开销和缺失衰减——随着记忆存储老化，这些权衡变得更加重要。

Letta 适合记忆一致性至关重要且 Agent 控制自己上下文的长期运行自主 Agent。如果你正在构建一个运行数周的持久 Agent，需要推理自己知道什么，MemGPT 架构给你那个能力。代价是有状态服务器要求和无法在不同 Agent 界面之间共享记忆。

PLUR 适合在多个工具中运行 Agent 的团队或用户，相同知识需要跟随 Agent 到达的任何地方。如果你的工作流涉及 Claude Code 和 Cursor 以及自定义 Agent，希望修正无需手动重新输入就能传播，PLUR 的基于文件的可移植性是架构答案。代价是一种不同类型的基础设施假设：engram 存储在最佳状态下需要维护（审查、修剪）——就像任何积累的知识库一样。

架构赌注

三种架构在"约束在哪里"这个问题上做了不同的赌注。

mem0 赌的是集成摩擦：开发者如果记忆难以添加，就不会构建它。API 表面是答案。Letta 赌的是一致性：没有推理器管理的记忆会退化。有状态运行时是答案。PLUR 赌的是可移植性：困在一个工具孤岛中的记忆不会跟随用户。开放的的文件格式和交换是答案。

一个团队可以同时使用全部三个。mem0 用于孤立的服务 Agent，Letta 用于长期运行的自主规划器，PLUR 作为跨工具记忆层，连接用户的知识贯穿两者。架构是组合的而不是竞争的。

不能组合的是交换。只能被产生它的系统消费的记忆无法共享、策划或定价。高级工程师通过六个月 Agent 修正积累的知识被困在他的实例中——对同事无用，对新员工不可见，当工具变更时消失。

engram 格式是开放的。包是可以发布的。~/.plur/ 目录属于用户，而不是工具供应商。不是你的文件，就不是你的记忆。

基准测试：plur.ai/benchmark · Engram 规范：plur.ai/spec · 安装：npx @plur-ai/mcp init

你的 Agent 技术栈是什么样的？如果你正在多个工具中运行 Agent，我们想知道你今天如何处理记忆——开一个 issue 或在 GitHub 上找我们。

GTD Content Writer - Created: 2026-07-06 Status: DRAFT - Requires human review before publication