如果你觉得换个更好的模型就能解决 Agent 忘事的问题，这篇文章会改变你的认知。arxiv 2603.07670 论文的实证结论令人意外：有记忆和没记忆之间的性能差距，往往大于不同 LLM backbone 之间的差距。换模型可能不如先把记忆系统做好。今天深度拆解 AI Agent 记忆系统的核心原理、四种记忆类型、常见失败模式，以及主流框架的选型思路。
LLM 天生无记忆：从本质理解问题
大语言模型在本质上是无状态（stateless）的。每次 API 调用都是独立的，模型不会”记住”昨天你问了什么，上次对话的结论是什么。它只能看到你当次传入的 context window 里的内容。
这意味着 Agent 所有的”记忆”都不是模型自带的——而是你通过工程手段主动注入到上下文里的。记住这句话：Memory is not a feature of the model — it is a feature you build.
这个认知很关键。因为它告诉我们，记忆系统的质量完全取决于你如何设计信息的存储、管理和检索。模型换不换，其实是次要问题。
上下文窗口的限制让问题更复杂：即便现在有 200K token 的超长上下文，长 context 里的信息也会出现”注意力稀释”——模型技术上”看到”了所有内容，但关键信息可能被淹没在噪音里，影响输出质量。
四种记忆类型：对应人类认知结构
认知科学对记忆的分类，意外地很适合用来理解 AI Agent 的记忆架构。现代记忆系统通常分四个层次：
工作记忆（Working Memory），也就是当前的 context window。高带宽、高速度，但转瞬即逝。每次对话结束，这层记忆就归零。失败模式是”注意力稀释”——context 太长时，Agent 行为会以难以调试的方式退化，因为模型在技术上”拥有”信息，但没在用。
情节记忆（Episodic Memory），记录具体发生了什么事、什么时候、什么顺序。类比人类”我记得上周五我们开了个会，决定了 A 方案”。对 Agent 来说，这可以是带时间戳的任务日志、对话摘要、决策记录。价值极大：Agent 可以回顾昨天的工作，发现规律，避免重复犯错。
语义记忆（Semantic Memory），抽象的知识、事实、启发式规则。不是”发生了什么”，而是”什么是真的”。比如用户偏好、领域知识、总结出来的最佳实践。这层记忆需要主动策展——不是所有情节都值得提炼成语义记忆，否则就变成了杂物间。
程序记忆（Procedural Memory），编码行为模式的”技能记忆”。对 Agent 来说，通常体现为 system prompt 里的角色设定、行为约束、工具使用规范。很多团队会精心调优一个 prompt，但几乎没有机制把用户反馈自动转化为更新后的程序记忆——这是被严重忽视的一层。
划重点：这四层记忆不是选择题，而是层次结构，各有分工，缺一不可。
Write-Manage-Read：记忆的核心循环
大多数记忆系统实现了”写”和”读”，然后就停了。但真正让记忆系统失败的，往往是被忽略的第二步——管理（Manage）。
完整的记忆循环是这样的：
- Write：新信息进入记忆（观察结果、工具返回值、反思）
- Manage：记忆的维护、修剪、压缩、合并去重
- Read：按需检索相关记忆，注入当前上下文
不管理记忆会怎样？噪音累积、前后矛盾、context 越来越臃肿，最终 Agent 行为持续退化。你见过 Claude Code 开很久之后回答质量越来越差的情况吗？本质上就是记忆管理缺失的体现——通常最好的办法是开一个新对话。
有意思的是，管理也是最难做好的部分。什么该保留？什么该压缩？什么该丢弃？何时把情节记忆提炼为语义记忆？这些都需要显式设计，不能靠”积累就好了”的心态。
长期记忆的实现：向量数据库是主流，但不是唯一
跨 session 的长期记忆，目前最主流的实现是向量数据库 + 语义检索。
基本流程：将需要长期保存的信息 embedding 成向量，存入 Pinecone、ChromaDB、pgvector 等向量数据库；查询时把当前 query 也向量化，做相似度搜索（Top-K），把最相关的记忆片段注入 prompt。
优势明显：能跨越词汇差异找到语义相关内容，适合开放域的模糊检索。
但向量数据库也有局限：对因果关系理解很差。”这两件事语义相似”和”这件事是那件事的原因”，对向量检索来说是一回事，但对 Agent 决策来说完全不同。这就是为什么生产环境中，越来越多系统在往向量+图数据库混合存储迁移。
还有个有趣的现象：Reddit 上出现了”我们试了向量数据库和图数据库做 Agent 记忆，最后还是回到了 SQL”的声音。结构化查询在精确事实存储、精准条件过滤上，仍然有不可替代的优势。
工具不是目的，适合场景才是。
主流框架选型参考
目前 Agent 记忆领域有几个值得关注的框架：
Mem0：开源，专为 Agent 设计的记忆管理框架。核心是双 LLM 架构——一次调用负责信息提取，一次调用负责决策（新增/更新/删除），实现智能去重和冲突解决。支持向量存储+图存储的混合方案，可与 Amazon Bedrock、Aurora、OpenSearch 集成。
Letta（原 MemGPT）：把 Agent 记忆类比为操作系统的虚拟内存——context window 是 RAM，长期存储是磁盘，Agent 可以自主决定什么时候”翻页”。理念很优雅，但维护成本较高，生产环境落地案例不多。
LangMem：LangChain 出品，对语义记忆（Semantic）、情节记忆（Episodic）、程序记忆（Procedural）三种类型都有原生支持，与 LangGraph 无缝集成。适合已经在 LangChain 生态的团队。
Amazon Bedrock AgentCore Memory：完全托管，开箱即用，无需自建向量数据库。内置多种记忆策略（语义提取、会话摘要、用户偏好），以 Tool 的形式让 Agent 自主决定何时读写记忆，还支持 MCP 协议。适合希望快速上线、不想运维底层资源的团队。
不同框架解决同一个问题，选哪个看你的技术栈和运维成本接受度。
真实失败案例：这些坑你可能也踩过
摘要漂移（Summarization Drift）：反复压缩历史 context 来省 token，每次压缩都丢失细节，最终保留下来的”记忆”和真实发生的事情偏差越来越大。就像传话游戏，到第十个人嘴里已经面目全非。
自强化错误（Self-Reinforcing Errors）：Agent 写入了一条错误记忆，之后每次决策都以此为真，越来越确信它是对的。有个真实案例：Agent 误判了某个集成有故障，把这个结论写入记忆，之后所有来自该集成的数据都被当作不可信数据忽略——实际原因只是电池没电。人工干预才能纠正。
记忆盲区（Memory Blindness）：重要信息确实存在于记忆库里，但检索时因为向量相似度不够高，排在 Top-K 之外，Agent 永远看不到它。明明记了，还是”忘了”。
这些失败不是小概率事件，而是系统性风险。做好记忆系统，不只是会存会取，还要提前想清楚这些边界情况怎么处理。
实战建议：按需渐进，不要一次上所有层
不要在第一天就把四层记忆全部实现——过度设计是工程师最常犯的错误。
第一步：先从情节记忆开始。在每次对话结束时，让 Agent 把关键事件、决策、结果写成结构化日志，存到文件或数据库里。下次对话开始时读取最近几条。成本低，效果立竿见影。
第二步：加入语义记忆的策展机制。不是所有情节都值得长期保留，设计一个规则或让 Agent 自己判断”这条值得记住吗”。建立用户偏好档案、项目上下文知识库。
第三步：当系统复杂度上升，再考虑向量数据库和框架选型。这时候你已经知道自己真正需要什么，不会被框架的功能清单牵着走。
记住 Write-Manage-Read 循环，重点投入在管理层。明确写入策略（什么值得记忆）、管理策略（何时压缩/修剪/过期）、读取策略（用什么方式检索什么内容）。把程序记忆当作代码来对待——纳入版本控制，跟踪变更，定期审查。
写在最后
AI Agent 的核心差距不在模型，在记忆。这个结论反直觉，但越深入看越会发现它是真的。记忆系统决定了 Agent 能不能真正从经验中学习、跨 session 保持上下文连贯、随时间积累领域知识。
从今天开始，在下次选型或架构设计时，先问自己：记忆系统怎么做？写入什么？怎么管理？怎么检索？把这三个问题想清楚，比换模型重要得多。
如果这篇文章对你有帮助，欢迎留言讨论——你在构建 Agent 时踩过哪些记忆相关的坑？
如果这篇文章对你有帮助，欢迎留言讨论。
