Agent 框架中的内存困境:现状与缺陷分析
TL;DR · AI 摘要
Agent 框架的内存管理是产品成败关键,当前主流方案各有缺陷,Mem0 提出需重构基础设施以支持持久化、可检索、跨会话记忆。
核心要点
- Claude Code 仅支持 200 行索引、每轮最多 5 个文件,无语义搜索
- Managed Agents 支持并发共享但受限于 100KB/存储且为工作区级设计
- Codex 采用双阶段写入机制,依赖本地 DB 和锁同步,效率低
结构提纲
按章节快速跳转。
内存管理是框架设计中最难的部分,不同系统采用不同策略。
工作内存(会话内)、外部内存(持久化)、参数内存(模型权重),三者失效模式不同。
Claude Code、Managed Agents、Codex 各自实现方式与核心缺陷。
现有系统均未解决语义检索、跨会话持久化和并发一致性问题。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- Agent Memory Infrastructure Review
- Memory Types
- Working Memory
- External Memory
- Parametric Memory
- Major Harnesses
- Claude Code
- Managed Agents
- Codex
- Design Gaps
- No Semantic Search
- Limited Storage
- Concurrency Issues
金句 / Highlights
值得收藏与分享的关键句。
工作内存会在会话结束时重置;外部内存会持久化;参数内存目前在生产中完全未使用。
Claude Code 使用基于文件名的选择,而非语义搜索——命名相关文件胜过内容相关文件。
Managed Agents 支持并发共享但受限于每个存储 100KB 且为工作区级设计。
Agent harnesses 是 AI 软件实际运行的地方。Cursor、Devin、Claude Code、Codex:这些环境负责上下文管理、工具编排、代理协调,以及越来越多地处理记忆功能。如今,交付软件的产品越来越倾向于“框架”而非“模型”。
记忆是框架设计中最难的部分。
它究竟在哪里?会话结束后什么内容得以保留?这是一个尚未完全解决的问题,每个主流框架都在以不同的方式应对。本文将逐一分析各框架所采用的记忆方案、其不足之处,并探讨这些差距揭示了记忆基础设施应具备哪些能力。
什么是 Agent 记忆
有三种不同形式的内容被称为“记忆”,区分它们很重要,因为每种都有不同的失效模式。
- 工作记忆存在于会话期间的上下文窗口内。每次会话结束时都会重置;当窗口填满时发生的压缩问题(哪些内容能留存)属于这一类。
- 外部记忆是指所有存储在模型权重之外的内容:向量数据库、知识图谱、文件等。它们会在会话结束后依然存在,权重本身不会改变。2026 年几乎所有生产级记忆都存放在这一层。
- 参数化记忆是通过梯度下降将知识编码进模型权重中,由框架提供的训练循环塑造而成。它通过应用规则而非检索示例来实现泛化。截至 2026 年,尚无任何生产部署使用此类记忆。
(认知科学中的语义/情景/程序性划分描述的是信息存储类型;上述三层则描述的是信息存储位置。)
论文《上下文化代理记忆是一种备忘录,而非真正的记忆》(arXiv:2604.27707)正式定义了上限:要实现与参数化记忆同等效果的检索,需要 Ω(k²) 的存储示例,而参数化记忆只需 O(d) 权重更新即可完成。所有低于此标准的系统均在其范围内运作。
主要框架已交付的功能概览
1.
: Claude Code
分为两个路径:
Auto-memory 是由 Claude 自动生成的笔记,来自后台提取代理,在 ~/.claude/projects/<repo>/memory/ 下存储,围绕一个名为 MEMORY.md 的索引文件,最多限制为 200 行 / 25KB,分为四类:用户、反馈、项目、参考。
检索机制决定了限制:每次 Claude Code 发起操作时,都会调用一个更小的模型,并传入包含文件名和描述的清单,该模型决定加载哪些文件。不支持嵌入,每轮最多加载五个文件,超出容量后静默截断(被丢弃的文件不会收到任何提示,因为它根本不会加载)。
不足之处:选择依据是文件名而非语义搜索,因此命名相关但内容无关的文件反而胜出。团队共享功能依赖 TEAMMEM 标志,但本质上仍是本地、仓库范围内的 Markdown 文件,没有语义索引。
了解更多请见:

@mem0ai
我阅读了 Claude Code 的记忆源代码。这个限制会默默删除你的代理记忆
我通读了 Claude Code 的记忆源码。200 行索引上限、每轮最多 5 个文件、无嵌入。以下是当 Claude 声称“记得你”时到底发生了什么,以及如何修复它——那个漏洞……
2.
: Managed Agents
Managed Agents 是 Anthropic 提供的托管代理运行时,不同于本地产品如 Claude Code。一次会话是一个只追加、不可修改的事件日志,因此回滚和审计是架构层面的设计,而非附加功能。记忆存储挂载在 /mnt/memory/ 下作为文件系统(每个工作区最多 8 个存储,每个约 100KB);每一次写入都是不可变版本,多个代理可并发共享同一个存储,并带有可审计的历史记录,而非冲突。
不足之处:它专为工作区规模下的多代理协调而设计,而非长期个人记忆。每个存储 100KB 的上限和工作区作用域意味着跨会话的个人上下文需要额外构建模式才能实现。
3.
Codex
Codex 的记忆是一个 markdown 目录,位于 ~/.codex/memories/(无 SQLite,无嵌入):首先读取 memory_summary.md,按需 grep 搜索 MEMORY.md,再加上 raw_memories.md、skills/ 和 rollout_summaries/。默认关闭,需启用 features.memories 标志。
写入路径分两阶段:第一阶段(每轮结束后):若会话闲置六小时,则 Codex 根据严格模式提取数据、屏蔽敏感信息,并写入本地状态数据库(尚未写入记忆目录)。第二阶段(全局):在锁保护下,一个合并子代理负责合并、修补或丢弃并写入差异。它受限制(最多 256 轮)、按年龄清理(30 天),且具备速率限制感知能力。读取路径非语义化:摘要固定截断至 5,000 token,其余内容通过 grep 在 MEMORY.md 中查找。
不足之处:5,000 token 摘要静默截断;grep 仅支持子字符串匹配,因此改写后的事实将不可见;六小时空闲门限意味着连续会话可能永远不会合并;状态仅限本地;且在发布之初,该功能在欧洲经济区(EEA)、英国和瑞士不可用。
了解更多请见:

mem0
@mem0ai
Codex CLI 中的记忆机制如何运作
Codex CLI 配备了一个生成的、异步摘要的记忆存储,位于 ~/.codex/memories/。这是其官方功能:文档见 developers.openai.com/codex,并且已完全开源于 github.com/openai/codex。
4.
Copilot
Copilot 的独特之处在于即时引用验证。记忆项是结构化对象(主题、事实内容、文件与行号引用、推理),在使用前代理会验证引用是否与当前分支一致,若代码存在矛盾则重写该记忆。记忆项在 28 天后也会自动过期。
这是目前唯一带有公开结果数据的“过时”机制:经过 A/B 测试(p<0.00001),启用记忆后 PR 合并率从 83% 提升至 90%,代码审查精度提高 +3%,召回率提高 +4%。这 7 个百分点的提升是目前唯一公开的真实生产环境中关于编码代理记忆系统的指标;其他人仅报告基准测试数据。
不足之处。引用模式无法干净地容纳不可验证或基于偏好的事实(如“偏好最小抽象”),且严格限定于仓库范围。
5.
OpenClaw 的原生记忆比表面看起来更强大:位于 ~/.openclaw/workspace 的 Markdown 文件(包含精选的 MEMORY.md 及带日期的日志)由每个代理的 SQLite 索引支持,包含嵌入和混合检索(70% 向量,30% BM25)。因此它原生支持语义搜索。
问题在于什么能留存下来。当窗口填满时,OpenClaw 会触发一次“静默内部轮次”,要求模型在清除前将重要内容写入磁盘。写入的内容取决于模型在那一轮中的决定,因此长期记忆具有选择性和不一致性。Mem0 插件()消除了这种依赖:Auto-Recall 在每一轮之前注入相关记忆,Auto-Capture 在每次交互后持久化记录(新事实存储,过期事实更新,重复项合并),按会话 run_id 和长期 userId 范围管理。这一差距推动了其 24.7 万星标的广泛采用。
了解更多请访问:
6.
Hermes Agent
Hermes(13.5 万星标,200+ 模型)自带三层架构,外加八个可插拔服务提供者。第一层为工作记忆:MEMORY.md(2,200 字符)和 USER.md(1,375 字符),合计约 1,300 个 token,§ 分隔符标记,附带利用率计数器并在 80% 容量时进行整合。写入内容保存于磁盘,但系统提示词保留冻结快照直至下一次会话,以维持前缀缓存。第二层为技能:在完成 5+ 工具调用任务后自动生成程序文档,并按计划整理。第三层为会话搜索:SQLite FTS5 覆盖所有会话,按需汇总。
不足之处。容量极小(约 800 个 token 的持久记忆),FTS5 仅支持关键词匹配(“429 错误”无法匹配“速率限制”),且为本地化。因此 Hermes 提供了插件槽位:配合 Mem0,容量不再受限,检索具备语义能力,提取过程在服务器端运行,写入按 MEM0_USER_ID 范围管理,且断路器确保即使服务宕机,内置层仍可正常运作。
了解更多请访问:

mem0
@mem0ai
如何为你的 Hermes Agent 添加记忆
Hermes Agent 最近新增了 6 种记忆提供者。Mem0 就是其中之一。设置只需一条命令。若任何环节失败,则启用断路器。记忆系统负责跨会话的存储、检索和上下文管理……
7.
Bedrock AgentCore
AgentCore 是 AWS 的托管代理平台:其 Runtime 是承载层(AWS 对应 Managed Agents 的类比),Memory 是其托管服务。Memory 运行三种异步提取策略(语义事实、偏好、叙事摘要),提取耗时约 20–40 秒,检索耗时约 200 毫秒;变更的事实标记为 INVALID 而非删除,以保留溯源性。已发布:LoCoMo 70.58,PrefEval 79,PolyBench-QA 83.02。
不足之处。它是 AWS 特定方案(生态锁定),其发布的 LoCoMo 表现远低于主流记忆系统。
8.
Windsurf 的记忆由其引擎 Cascade 自动生成和管理,无需开发者工作流:位于 ~/.codeium/windsurf/memories 的本地、工作区范围内的文件,用于捕捉代码库模式和约定。
不足之处。所捕获的是 Cascade 的调用内容,而非开发者意图;记忆局限于工作区范围(项目间不可见)且本地化(无跨设备或团队共享)。
- Cognition Devin
Devin 将记忆分为两类。知识是人工精选的触发式事实(无自动捕获);DeepWiki 是参考文档(30 页,100 条注释,每条 10,000 字符)。Devin 在会话结束后建议知识,但需人工审批后才存储。
不足之处。审批关卡虽保证质量,但也带来摩擦:不审查的团队积累不到任何内容。限制较为温和,且知识专为 Devin 精选,无法迁移到其他工具。
记忆基准测试是薄弱环节
业内用于衡量记忆性能的基准测试大多不佳。它们主要测试过往对话中事实的召回能力,接近饱和状态,高分并不能预测更好的决策能力。
LoCoMo 是最差的常见基准之一。十次对话使比较不可靠,许多问题无需记忆(一个简单的 grep 基线得分约 74%),而对抗性问题表面相似度高,导致模型通过模式匹配获胜。LongMemEval 仍属尚可:涵盖五种能力(信息提取、多会话推理、时间推理、知识更新、回避)的 500 个精选问题,扩展至 1.5M token;仍以召回为中心,但是一次真实测试。
更深层次的问题在于,现有方法均未测量这一点。MemoryArena(arXiv:2602.16313)测试的是必须指导行动的记忆,而接近饱和LoCoMo和LongMemEval的系统在这一能力上表现失败;Anatomy of Agentic Memory(arXiv:2602.19320)则将这一批判形式化(接近饱和、仅测量相似性而非任务效用)。
且无一测试生产级规模:标准基准测试上限约为150万tokens,而实际生产级代理可达1000万+。BEAM(ICLR 2026)是唯一为此范围设计的基准。诚实的结论是:该领域亟需一个新的记忆基准,且排行榜分数应持怀疑态度,包括以下提到的那些。
研究显示仍存在缺陷
稳定性-可塑性困境并未因转向外部记忆而终结。“当持续学习转向记忆”(arXiv:2604.27003)表明,新旧记忆仍如过去争夺权重一样竞争检索槽位;来自简单任务的原始轨迹会损害更难的任务(前向迁移下降9.5%)。
选择性遗忘仍未解决。MemoryAgentBench(arXiv:2507.05257)列出了四项能力;系统能处理检索,但无法实现选择性遗忘(即在删除过时事实的同时保留其结构)。
记忆本身是一个攻击面。“无需攻击者”(arXiv:2604.01350)在正常使用下测得57–71%的跨用户污染;投毒攻击成功率高达6–38%(arXiv:2601.05504)。
缺陷中的模式
同样的差距反复出现。存储受限且本地化(Claude Code 25KB,Hermes 2,200字符,Codex的5,000-token负载)。检索主要依赖关键词(Claude Code按文件名,Codex通过grep,Hermes通过FTS5);仅有两个支持语义检索的系统受限于本地存储与压缩(OpenClaw)或锁定云端(AgentCore)。记忆受框架边界限制,因此Claude Code的记忆对Codex毫无意义。过时处理几乎不存在(Copilot除外)。隔离只是事后考虑,因此才出现污染数据。这些正是框架边界所设限之处。
Mem0
Mem0旨在应对框架边界并非问题终点的情形。其架构为混合型:向量存储用于语义检索,知识图谱用于关系推理,键值存储用于快速元数据访问。
v3算法(2026年4月)采用单次遍历ADD-only提取、多信号检索(一次遍历完成语义+BM25+实体链接),并在向量存储内完成实体链接,摒弃了v2版本的外部图数据库。
它以约6,900 tokens和1.44秒/查询的速度运行,相较完整上下文检索所需的约26,000 tokens和17.12秒显著提升。
针对上述缺陷:一个无容量上限的外部存储;即使措辞不同也能检索到上个月关于认证端点讨论的多信号检索;身份隔离的记忆——某用户的命名空间不会泄露至其他用户,目标直指57–71%的污染率。更重要的是,这并非理论构想:Mem0已面向所有主流框架发布,包括Claude Code插件、Codex MCP服务器、首批Hermes和OpenClaw提供商、原生AWS Strands集成,覆盖21种框架及20种向量存储。记忆由此成为基础设施,而非各框架专属功能。
现状如何
记忆如今已成为基础设施:每个主流框架均已部署,因为一个在会话内具备能力却在会话间失忆的代理本质上是有限制的。
框架原生实现取得了实质性进展,但它们同样受限于同一边界:本地存储受限、关键词检索为主、框架边界限定、弱过时处理能力、隔离缺失。
本应衡量上述所有问题的基准测试本身也较弱,而唯一测试生产级规模的BEAM,却是大多数系统不报告的结果。
总体而言,这些正是Mem0正努力填补的空白:可移植、语义可检索、跨代理、并能扩展至生产级代理累积token量的记忆。
In Context #11
本文属于“In Context”系列博客的一部分,该系列聚焦AI代理的记忆与上下文工程。
Mem0是一款智能、开源的记忆层,专为大语言模型和AI代理设计,旨在提供跨会话的长期、个性化、情境感知交互。
- 获取免费API密钥:
- 或从我们的官网自托管Mem0:
参考文献