一篇发表于 2026 年 5 月 26 日的技术分析文章，把几类 Agent Memory 库拆开看了一遍。结论有点刺耳：很多产品借用了认知科学里的 episodic、semantic、procedural 等词，但工程上真正跑起来的，主要还是用户事实的长期管理。

这事有意思的地方，不是“记忆库有没有用”。当然有用。一个 Agent 能跨会话记住用户住在哪、偏好什么语言、项目推进到哪一步，产品体验会立刻变好。

问题在另一边：如果把这套能力说成完整“记忆系统”，工程判断就容易跑偏。开发者可能以为自己买到的是多种记忆，实际拿到的是一个带抽取器和检索器的用户事实库。

Agent Memory 的底层问题：它在记什么

认知科学里，episodic memory 和 semantic memory 的经典区分来自 Endel Tulving 在 1972 年提出的框架。前者指带时间、地点、经历感的事件记忆；后者指脱离场景后的事实知识。

到了 Agent 场景，这些词被 API 化了。字段叫 episodic，不代表系统真的保留了事件经验；标签叫 procedural，也不代表它学会了技能。

多数 Agent Memory 的基本结构，其实可以拆成三件事：extractor、store、retriever。

组件做什么真正影响能力的点
extractor从对话中抽取短事实是否丢掉时间、指代、条件和来源
store保存事实、标签、时间戳、来源新旧事实矛盾时是覆盖、追加，还是保留版本
retriever在下一次调用时召回事实是否会把过期事实重新塞回上下文

比如用户说：“我上周和团队聊完后，决定这个项目先用 TypeScript。”

进入记忆库后，它很可能被压缩成：“用户喜欢 TypeScript”或“该项目使用 TypeScript”。这当然有用，省 token，也方便检索。但事件感、时间点、决策条件都被削薄了。

这就是主线：很多所谓 episodic memory，在工程实现里被压成了 semantic memory。

对应用团队来说，这不是概念洁癖。它会影响产品承诺。你不能一边只保存压缩后的事实，一边向客户暗示系统理解了完整经历链条。名不正，则言不顺，架构也会跟着歪。

四类“记忆”对照：语义事实才是主体

把几类主流做法放到一起看，术语和实现的缝隙会更清楚。

记忆类型原本含义Agent 类库里的常见状态选型时该问什么
episodic特定时间、地点、事件的经历多数被抽取压缩成用户事实原始来源和时间还在不在
semantic脱离场景的事实知识当前主流实现的主体事实是否可更新、可审计
procedural如何做事的技能或习惯多数只是标签；LangMem 有相对独立机制行为变化是否真的影响执行策略
prospective未来条件出现时执行意图基本缺位条件再次出现时能否触发，而不只是定时提醒

这里要小心，不是所有库都一样。

LangMem 对 procedural memory 有独立机制，会从轨迹评分中演化系统提示词，让“记忆”影响行为倾向。Mem0 更多是把 procedural 做成标签，仍写进同一索引。Graphiti 不暴露 procedural memory，而是把内容放入双时间图结构。

这个差异会影响迁移成本。

如果团队只是做客服偏好、用户资料、项目状态，语义事实库已经够用。重点是权限、版本、召回质量和删除策略。

如果团队希望 Agent “越用越会做事”，就不能只看 memory 字段。要看它有没有把历史轨迹转成可执行策略，有没有评估回路，有没有办法回滚错误学习。

working memory 又是另一层。Agent 里的 working memory 通常就是上下文窗口，不该和长期记忆混在一起卖。

prospective memory 更容易被误解。它不是简单的“明天 9 点提醒我”。更难的是：“下次用户再问价格时，主动提新套餐。”这要求系统识别条件再次出现，并把旧意图接上当前任务。仅靠定时任务解决不了。

所以我更愿意把主流 Agent Memory 称为：替用户维护自传式语义记忆。它记录的是“关于这个用户的长期事实”，不是完整的人类记忆模型。

工程团队该怎么选：少看术语，多看三类脏活

最受影响的是两类人：做 Agent 应用的工程团队，以及正在采购 Agent 平台的技术负责人。

工程团队如果已经接入某个 memory library，不一定要立刻迁移。更现实的动作是补一轮评估：抽取是否可控，旧事实是否会污染新任务，系统能否解释“为什么当时这么认为”。

采购方则可以延后对“全套长期记忆”的承诺。先把 POC 问题收窄：它能不能稳定维护用户资料、项目状态和偏好变化。做不到这一点，谈多种记忆没有意义。

选型时，至少要盯住这三类脏活：

问题应该压测的场景不合格信号
压缩用户说法带时间、条件、指代抽取后只剩一句笼统偏好
矛盾用户搬家、换岗位、改技术栈新旧事实并存但没有版本和有效期
过期检索旧事实曾经正确，现在已作废retriever 仍把它注入上下文

审计也很关键。系统应该能回答：“这条事实来自哪段对话？”“何时被更新？”“为什么它现在仍然有效？”

这不是要求保存一切、永不删除。重点是非破坏性保留与可检索、可审计之间的平衡。旧材料可以降权，可以标记过期，也可以受权限控制；但不能在用户追问时完全说不清来龙去脉。

生物类比可以借，但要有边界。

consolidation 值得借鉴。离线整理、去重、合并矛盾，比每条消息都同步抽取更稳。Anthropic 提到的 Dreams、Letta 的 sleep-time compute，都指向这种跨会话整理思路。

emotional salience 就要谨慎。LLM 可以给“重要性”打分，但文本代理没有身体、情绪和生理反应。把“重要性评分”说成人类情绪记忆，容易把工程指标神秘化。

biological forgetting 也不该照搬。人脑会遗忘，Agent 不必模拟这种限制。更现实的目标是：旧事实可查，新事实优先，过期事实不乱入。

接下来该观察的，不是哪家公司把记忆讲得更像人。

要看四件事：冲突处理有没有版本模型，过期事实有没有过滤机制，来源追踪能不能被审计，离线整理是否会引入新的错误。能把这些做稳，才算 Agent Memory 从概念词走向工程能力。