如果你常用 Claude Code、Codex 这类编程智能体，大概率经历过这样的场景：
你花了两个小时让它熟悉项目结构、代码规范和那些没写在文档里的坑，配合刚刚顺手，系统提示上下文过长，自动压缩。下一轮对话，刚才还默契十足的 AI 瞬间回到“你是谁、项目是什么”的状态。重新喂一遍背景，重新烧一遍 Token，两个小时的默契全盘崩坏。
这不是个别错觉。AI 编程工具的用户社区里，对“压缩引发信息损伤”的抱怨一直是最常见的一类。知乎而“智能体失忆”这个话题，恰好在这周集中爆发：
8 月 12 日，牛津大学、清华大学、北京大学等近 30 家机构的学术团队联合发起的智能体记忆榜单（AML）揭晓首期榜单，136 支队伍参赛，官网点击量突破 20 万。知乎
8 月 13 日，一个叫 MCPMemory 的开源项目登上 Hacker News，思路很朴素：用本地 SQLite 给 AI 装一个可检索的长期记忆。知乎
同样在 8 月 13 日，DeepSeek 发布首款 Agent 产品 DeepSeek Harness，“上下文管理”被明确列为核心能力之一。微博
记忆赛道从没这么热闹过。几乎每周都有新的智能体记忆产品出现，卖点都是让智能体拥有持久上下文。知乎但在你动手给 Agent 找记忆组件之前，我想先泼一盆冷水：大多数记忆产品，解决的是问题里错误的那一半。
一、窗口越大反而越难用：智能体为什么会“失忆”
上下文窗口已经到了数百万 Token 的量级，直觉上容量越大越能记住，实际正好相反：把海量信息喂给模型后，它更容易在冗长且充满噪声的内容里产生幻觉，忘掉你的指令，反复踩同一个坑。多标签页切换、跨会话恢复也是同样的问题——窗口大了，反而不好用了。
记忆已经不是锦上添花。《麻省理工科技评论》2026 年“十大突破性技术”里，“AI 陪伴”和“生成式编码”各占一席：前者要求 AI 在无数次互动中稳定记住你的偏好和习惯，后者要求它在数天甚至数月的项目周期里，持续跟踪项目架构和代码风格。而据 DeepTech 援引的行业调研，上下文丢失这类记忆缺陷，也是企业 AI 应用没能规模化落地的主因之一。知乎要让 AI 真正有长期记忆，本质上得在底层想清楚三件事：哪些应该记、哪些可以忘、什么时候调用哪一段。
二、榜单开了，战场却还没收敛
先看 AML 首期榜单，结果相当有戏剧性：最受关注的商业产品文本赛道，综合第一是 MemoraX AI——一家成立仅五个月的深圳公司，总分 58.0，在事实召回、多跳组合、时间与事件、记忆治理、个性化、规则执行、安全与隐私全部七个能力维度都排第一。知乎
对照来看，在海外开发者社区热度很高的开源项目 Mem0 只排在第 8 名，MemPalace 第 9，Supermemory 第 14；而从头部系统的能力维度对比看，MemoraX 与身后的 MemOS、网易 NTES-MEMORY-SMART 之间拉开的差距并不小。
但这里有两点必须说清楚：
其一，榜单把参评动作限定在“写入”和“检索”，回答和评分由平台统一完成。榜单覆盖的维度再全面，也只能衡量记忆系统在特定数据集与评测规则下的能力切片，不等于生产环境里成本、延迟、隐私全都要算进去的真实表现。知乎而且榜单相关的报道里，第一名公司的出镜率相当高，从技术细节到融资进展一路覆盖，看的时候当参考，别当采购依据。
其二，记忆这条赛道本身还在战国时代。有人把现在的记忆方案归纳成八种范式：向量检索增强、知识图谱、渐进式压缩、多索引混合检索、LLM 检索器、轨迹记忆、Karpathy 式 Markdown Wiki、文件系统存储。几乎所有项目都是从向量检索起步，再一路打补丁加能力；有的范式之间还天然打架——轨迹记忆要求完整保留执行历史，渐进式压缩却要求淘汰冗余原文。知乎结论很直白：目前没有最终解，大多数团队只能选一种范式为主、另一种为辅。
大厂倒是已经把记忆做成基础设施了。AWS 的 Bedrock AgentCore 把支持短期会话与跨会话长期记忆的 Memory 列为核心组件，微软 Azure 也开放了 AI Foundry Memory 模块。知乎主打记忆的开源项目 Mem0，GitHub 星标也已突破六万，是过去一年增长最快的 AI 底层开源项目之一。
三、冷水本体：记忆产品解决的，是错误的一半问题
这是最近 deephub 翻译的一篇文章里，我最想转述的判断：记忆本身不会让智能体变聪明。它只是整套系统里的一个环节——检索层负责让智能体真正拿到信息，捕获（Capture）记录发生过什么，整合（Consolidation）把记录变成下一次会话可用的内容。少了任何一环，都算不上学习，只是在记笔记。知乎
更扎心的是：一个埋在自己笔记里的智能体，可能比没有笔记更糟——它行动前还得先把笔记全部翻一遍。知乎
一条相对完整的记忆链路长什么样？看一款市售记忆产品公开的架构图：从对话输入，到记忆条目生成、沉淀、召回，再到输出，每个环节各司一段。
这三条链路对记忆系统的要求几乎相反：
捕获必须被动、确定性地执行，每个会话都要跑，不能指望智能体自己想起来“该记一下”——捕获靠自觉，最关键的几轮反而最容易漏；
召回要按需触发，由智能体自己决定——执行到一半缺什么，只有它自己知道；
整合可以很慢，最好完全离开关键路径——把大量原始事件压缩成少量持久、互不矛盾的经验，本来就是反思性工作。
把这三件事塞进同一个机制，至少要牺牲两件。最典型的失败模式就是“单存储、单路径”的记忆系统：为了捕获做得过于积极，路径太重，召回延迟又崩了。知乎
企业用户还有一层更隐蔽的缺口：智能体缺的往往不是用户偏好，而是“组织意图”——折扣政策、“活跃账户”的定义、上季度为什么做了某个决定。这些内部常识几乎永远不会写进 Prompt，却决定了智能体给出的是教科书答案，还是“你们公司的答案”。知乎
四、三类人三条路，别急着装记忆组件
1）只用编程智能体的个人开发者（Claude Code、Codex、DeepSeek Harness 们）：先别装外部记忆组件，把已经在手里的“Markdown Wiki 范式”用满。项目规范、偏好、踩过的坑，写进 CLAUDE.md / AGENTS.md；会话文件本身就是明文 JSONL，社区已经出现专门做会话搜索和导出的工具，新会话让工具自己去翻历史记录。这就是 Karpathy 四月提出“LLM Wiki”构想的零成本版本。知乎
2）用 LangChain 这类框架自建智能体应用的开发者：接 Mem0、MCPMemory 这类组件之前，先回答三个问题——谁决定召回？延迟预算多少？捕获之后谁来做整合？三个答案如果都是“模型自己看着办”，基本可以预见失败模式。再看一眼市面上典型记忆组件的内部能力分层——输入、上下文处理、策略提炼、存储治理、检索召回——你会发现这三个问题正好对应组件内部的责任划分。
另外记住八范式的教训：先想清楚业务需要时间查询、关系查询还是多跳推理，再选组件，别看谁 star 多就先接谁。
3）企业团队：别从“把所有数据集中到一个记忆库”开始，那是一场没有尽头的迁移项目的开端。更合理的路径是“数据留在原地，移动的是上下文”——只保存指针、语义层和元数据，智能体需要什么上下文就取什么。再加一道人工审核闸门：完全放任系统自我学习，它会把成功经验和错误一起整合进去，出现频率不代表正确性，持久记忆的“晋升”必须是一次判断，而不是自动写入。知乎
五、接下来值得盯的几个信号
AML 这类榜单的更新频率，以及多模态记忆评测能不能跟上——智能眼镜、耳机、家庭机器人最需要长期记忆，文本评测覆盖不了它们；
Claude Code、DeepSeek Harness 这些主流 harness 会不会开放更多记忆接口——harness 层决定了记忆能插在哪；
记忆组件的定价、记忆保留时长和隐私条款——记忆存得越久，信任越是前提。
推理竞赛已经白热化，但一个记不住上下文的 AI，终究只是个“聪明的陌生人”。对大多数开发者来说，眼下性价比最高的记忆方案，可能不是那个六万 star 的开源组件，而是你一直没认真写的那份 CLAUDE.md。
