2026 年 AI Agent 记忆工具盘点：Letta、Mem0、Zep 等 8 个项目怎么选

Last checked: 2026-07-16.

Agent memory 不是把所有聊天记录塞进向量库。一个能上线的记忆系统至少要回答五个问题：记什么、何时写入、何时取回、如何更新冲突事实、用户要求删除时能否真的删掉。Letta、Mem0、Zep/Graphiti、LangGraph、LlamaIndex、Haystack、Semantic Kernel 和自建 Postgres/向量检索分别解决不同层次的问题。个人助理、客服和长任务 agent 不应使用同一套记忆策略。

先看当前官方快照

先区分四种“记忆”

短期上下文是当前对话里仍可见的信息；线程状态是一次任务跨步骤保存的中间结果；长期用户记忆是跨会话保留的偏好与事实；知识库则是团队或产品文档。把四者混在一个向量库里，会让 agent 在错误场景召回错误内容。架构图上应把它们画成不同存储和不同生命周期。

Letta：适合把状态当作 agent 的一部分

Letta 的吸引力在于把记忆块、消息与 agent 状态放进同一个长期运行模型。它适合需要持续身份和工作上下文的助理。评估重点不是能不能记住名字，而是记忆块如何更新、容量如何控制、工具调用后状态是否一致，以及导出和删除是否可审查。

Mem0：适合从大量交互中提炼用户事实

Mem0 更接近一层可接入现有应用的记忆服务。客服、教育和个性化产品可以从对话抽取偏好，再在后续会话检索。真正难点是写入门槛：用户随口举例、否定句或过期地址都可能被错误保存。必须为高风险事实设置确认、来源和过期时间。

Zep/Graphiti：适合会随时间变化的关系

时间知识图谱适合“某人在某段时间属于某团队”“客户当前使用哪个套餐”这类变化事实。它比简单向量相似度更能表达时间与关系，但建图、实体合并和冲突处理成本更高。只有业务确实依赖关系变化时才值得引入。

框架内 memory：更接近工作流状态管理

LangGraph、LlamaIndex、Haystack 和 Semantic Kernel 都能组合存储与检索，但它们不会替产品自动决定什么值得永久保存。优势是与现有 agent pipeline 结合紧密；代价是团队必须自己定义 schema、权限、删除和评估。

什么时候自建反而更简单

如果只需要保存 20 个明确字段，例如语言、时区、已购买套餐和通知偏好，普通关系数据库往往比通用 memory 平台更可靠。每个字段有来源、更新时间和删除接口，审计也更清楚。不要为了“Agent memory”标签，把确定性数据变成不可解释的向量召回。

评测不能只问“它还记得吗”

至少包含记住、更新、遗忘、隔离和拒绝五类测试。一个系统记住旧地址却不接受新地址，不是记忆好；把 A 用户偏好召回给 B 用户是严重故障；用户删除后仍能从摘要或缓存找回，也不算删除。

8 条路线到底提供了什么

Letta：长期运行的 stateful agent，不只是 memory API

Letta 旧 letta 仓库当前明确标注为 legacy server；活跃开发已经转到 Letta Agent/letta-code。CLI 要求 Node.js 22.19+，安装命令是 npm install -g @letta-ai/letta-code。新的 TypeScript Agent SDK 包名为 @letta-ai/letta-agent-sdk，可连接 Letta Constellation cloud、在本机拉起 Letta Code，或连接自托管 App Server。它适合把 persona、human memory、技能、subagent 和执行状态放进一个长期 agent，而不是给任意现有聊天应用加一层简单检索。

Mem0：可插入现有应用的独立记忆层

Mem0 同时提供 Python/Node library、自托管 server、cloud platform 和 CLI。Python 安装为 pip install mem0ai；需要 BM25 与实体抽取时可用 mem0ai[nlp]。自托管 server 提供 Docker Compose、dashboard、auth 和 API key；当前 README 明确写着 self-hosted auth 默认开启，旧版本升级时不要随手用 AUTH_DISABLED=true 进入生产。它的优势是能给现有客服或助手按 user_id 写入、搜索记忆；要自己验证的则是抽取错误、删除传播和 cloud/OSS 功能差异。

Zep 与 Graphiti：托管上下文平台和开源时间图不是同一个东西

Graphiti 是开源 temporal context graph engine，Zep 是基于 context graph 的托管生产基础设施。Graphiti 把 entities、带有效时间窗口的 facts/relationships、原始 episodes 和自定义 ontology 分开保存；检索结合语义、BM25 与图遍历。当前官方仓库要求 Python 3.10+，图后端可选 Neo4j 5.26、FalkorDB 1.1.2、Amazon Neptune 等，默认还需要 LLM 与 embedding 服务。Zep 则增加用户、线程、消息、dashboard、日志、SDK、治理和 SLA。只想“记住用户喜欢深色模式”的产品，没有必要先上时间图。

LangGraph：checkpoint、thread memory 与跨线程 store

LangGraph 的核心定位是 long-running stateful workflow。短期 memory 通常跟 thread/checkpoint 绑定，用于失败后恢复和同一任务续跑；长期 memory 写入 store，在不同 thread 间按 namespace 检索。它还提供 durable execution、interrupt/human-in-the-loop，并能配合 LangSmith 调试。它不会自动替你判断哪句对话值得永久保存，也不会自动提供完整的用户删除产品流程。

LlamaIndex、Haystack 与 Semantic Kernel

LlamaIndex 的强项是数据 connector、index、retriever 和 agent 组合，适合“文档和会话如何一起进入上下文”的产品；Haystack 更偏显式 pipeline、document store、retriever 和 component 组合，适合企业检索流程；Semantic Kernel 适合 .NET/Java/Python 与微软生态中的 agent、plugin 和 memory 组合。这三者都是应用框架，不是开箱即用的跨产品用户记忆 SaaS。团队仍要选择实际存储、embedding、namespace、TTL 和删除机制。

自建 Postgres/Redis/向量库

如果数据是语言、时区、套餐、通知偏好、最近工单等明确字段，Postgres 表通常最可靠。短期会话状态可放 Redis，模糊语义召回再单独进入 pgvector、Qdrant、Weaviate 等向量层。确定事实用 schema 和唯一键，非结构化片段才做 embedding；不要把所有东西都向量化。

横向能力表

写入、更新、删除分别怎么做

记忆写入有三种常见方式。显式写入由用户或业务事件直接保存，最适合地址、偏好、套餐；自动抽取由 LLM 从对话提炼事实，适合大量低风险偏好，但必须带来源；后台 consolidation 会把多轮历史压成摘要，适合控制上下文，却最容易把错误固化。更新时不要简单追加“新地址”，要让新值取代当前值，同时保留审计历史。删除必须覆盖原始 message、抽取 memory、summary、embedding、图节点/边、缓存与备份策略说明。

检索阶段需要的五个参数

第一是 namespace，至少隔离 tenant、user、agent 和环境；第二是 top-k，过大会把无关旧记忆塞回提示；第三是时间衰减或 TTL；第四是 metadata filter，例如只查当前产品或项目；第五是 rerank/阈值。没有 namespace 的向量检索是跨用户泄漏事故的直接来源。对于高风险字段，应该按 key 精确读取，而不是相似度搜索。

选型结论

从零构建长期 agent、希望 memory 与 agent state 一体化，先看 Letta；已有客服/教育/个性化产品，只想插入独立 memory layer，先看 Mem0；事实和关系频繁变化、需要“当前与历史”同时查询，比较 Zep/Graphiti；已经在 LangGraph 上做长任务，先用 checkpoint + store，不必再引入一套平台；字段明确且合规要求高，优先 Postgres，向量检索只处理非结构化补充信息。

官方与一手来源

• Letta docs：stateful agent
• Mem0 docs：memory layer
• Zep docs：temporal knowledge graph
• LangGraph memory：thread and store

延伸阅读

• Agent memory systems 追踪入口
• Agent skill system design