Mem0 调查了 Claude Code、Codex、Copilot、OpenClaw、Hermes、Bedrock AgentCore、Windsurf 和 Devin 中的记忆实现，发现所有系统都存在相同的边界失效问题：本地存储有界、检索以关键词为主、作用域限于工具链、过期处理薄弱，以及 57-71% 的跨用户污染率。

Agent 工具链中的记忆现状

Agent 工具链是 AI 软件实际运行的地方。Cursor、Devin、Claude Code、Codex：这些环境处理上下文、编排工具、协调 Agent，并且越来越多地管理记忆。工具链本身（而非模型）正逐步成为交付软件的产品。而记忆，正是工具链设计中最困难的部分。它应该位于何处？会话结束后，哪些内容得以持久保存？这基本还是一个未解之谜，每个主流工具链都在用不同的方式解决。本文涵盖了每个工具链已发布的功能、各自的不足之处，以及这些差距揭示了记忆基础设施必须解决的问题。

Agent 记忆的真正含义

有三类不同的东西都被称为“记忆“，它们的区别很重要，因为每种都有不同的失效模式。

• 工作记忆：会话期间存在于上下文窗口中的内容。会话结束时重置；压缩问题（窗口填满时哪些内容幸存）属于此类。
• 外部记忆：持久化在模型权重之外的任何内容：向量数据库、知识图谱、文件。它跨会话持久保存；权重保持不变。2026 年几乎所有生产环境中的记忆都属于此类。
• 参数记忆：通过梯度下降编码到权重中的知识，由工具链提供的训练循环塑造。它通过应用规则而非检索示例来泛化。2026 年零生产部署。

（认知科学中的分类——语义/情景/程序——描述了存储的信息种类；而上述三个层级描述了信息存储的位置。）

论文《Contextual Agentic Memory is a Memo, Not True Memory》（arXiv:2604.27707）形式化了天花板：检索需要 Ω(k²) 个存储示例才能匹配参数记忆通过 O(d) 次权重更新所能做到的。下面讨论的每个系统都运行在这个上限之内。

主流工具链已发布的功能【概览】

1. @AnthropicAI：Claude Code
分为两条路径。CLAUDE.md 是人工编写的配置（约定、指令），在会话开始时读取。自动记忆是由后台提取代理生成的 Claude 笔记，存储在 ~/.claude/projects/<项目>/memory/ 目录下，使用一个容量上限为 200 行/25KB 的 MEMORY.md 索引，分为四类：用户、反馈、项目、参考。检索决定了其限制：每轮交互中，Claude Code 会单独调用一个较小模型，传入文件名和描述的清单，由模型决定加载哪些文件。不使用嵌入，每轮最多五个文件，超过上限时静默截断（被丢弃的文件不会收到任何警告，因为它从未加载）。

不足之处。 选择依据是文件名而非语义搜索，因此一个名字相关的文件会胜过一个内容相关的文件。团队共享功能在 TEAMMEM 标志后可用，但本质上仍是本地的、仓库作用域的 markdown，没有语义索引。
了解更多：
mem0@mem0ai·4月1日·文章
我阅读了 Claude Code 的记忆源代码。这个限制会悄无声息地删除你 Agent 的记忆。我通读了 Claude Code 的记忆源代码。200 行的索引上限、每轮 5 个文件、无嵌入。以下是当 Claude 说它记得你时实际发生的情况，以及如何修复。泄露…2511666497K

2. @AnthropicAI：Managed Agents
Managed Agents 是 Anthropic 托管的 Agent 运行时，不像 Claude Code 那样是本地产品。一个会话是一个只追加的事件日志，从不修改，因此回滚和审计是架构层面的，而非事后添加。记忆存储挂载在 /mnt/memory/ 路径下，作为文件系统（每个工作空间最多 8 个，每个约 100KB）；每次写入都是一个不可变版本，多个 Agent 可以并发共享同一个存储，并拥有可审计的历史记录而非冲突。

不足之处。 它专为工作空间规模的多 Agent 协调而设计，而非长期个人记忆。每个存储 100KB 的上限和工作空间作用域意味着跨会话的个人上下文需要在其上构建额外的模式。

3. @OpenAI：Codex
Codex 的记忆是一个 markdown 目录：~/.codex/memories/（没有 SQLite，没有嵌入）：首先读取 memory_summary.md，按需 grep MEMORY.md，外加 raw_memories.md、skills/ 和 rollout_summaries/。默认关闭，需要 features.memories 标志。写入路径是两阶段的。阶段一（每轮 rollout）：会话闲置六小时后，Codex 按严格模式提取，清除秘密，写入本地状态数据库（尚未写入记忆目录）。阶段二（全局）：在锁下，合并子代理合并、修补或丢弃并写入差异。设有上限（256 个 rollout）、按时间裁剪（30 天），并感知速率限制。读取路径是非语义的：摘要被截断到固定的 5000 token 预算，其他内容通过 grep MEMORY.md 查找。

不足之处。 5000 token 的摘要会静默截断；grep 只能做子串匹配，因此改述后的事实不可见；六小时空闲门槛意味着连续会话可能永远不会合并；状态仅限本地；且该功能在发布时在 EEA、英国和瑞士不可用。
了解更多：
mem0@mem0ai·5月13日·文章
Codex CLI 中的记忆工作原理
Codex CLI 在 ~/.codex/memories/ 下提供了一个生成式的、异步总结的记忆存储。这是一个第一方功能：记录在 developers.openai.com/codex，并在 github.com/openai/codex 完全开源。…118164450K

4. @github：Copilot
Copilot 的独特之处在于即时引用验证。记忆项是结构化对象（主题、事实内容、文件及行引用、推理），在使用前，Agent 会根据当前分支验证引用，重写那些代码已矛盾的记忆。记忆还会在 28 天后自动过期。这是唯一一个已部署的过期机制，并公布了结果数据：A/B 测试（p<0.00001），开启记忆后 PR 合并率从 83% 提升至 90%，代码审查精确度 +3%，召回率 +4%。这个 7 个百分点的提升是唯一公布的关于编码 Agent 记忆的真实生产环境指标；其他人都只报告基准测试结果。

不足之处。 引用模式无法干净地容纳无根据或偏好型事实（例如“偏好最简抽象“），且严格限于仓库作用域。

5. @openclaw：OpenClaw
OpenClaw 的原生记忆比看上去更强大：~/.openclaw/workspace 下的 markdown（一个精炼的 MEMORY.md 加上带日期的每日日志），由每个 Agent 的 SQLite 索引支持，带有嵌入和混合检索（70% 向量，30% BM25）。因此它原生支持语义搜索。问题在于哪些内容会持久保存。当窗口填满时，OpenClaw 会触发一个“静默内部轮次“，要求模型在清除前将重要内容写入磁盘。写入的内容取决于模型在那一个轮次中决定的内容，因此长期记忆是选择性的且不一致。Mem0 插件（@mem0/openclaw-mem0）消除了这个依赖：自动召回在每轮交互前注入相关记忆，自动捕获在每轮交互后持久化每条交换（存储新事实、更新过时事实、合并重复项），作用域按会话 run_id 和长期 userId 划分。其 247,000 颗星的增长很大程度上正是由于这一缺口。
了解更多：https://mem0.ai/blog/openclaw-memory-management-live-data-compaction-and-best-practices

6. @NousResearch：Hermes Agent
Hermes（135,000 颗星，200+ 模型）提供了三个内置层外加八个可插拔提供者。第一层，工作记忆： MEMORY.md（2200 字符）和 USER.md（1375 字符），合计约 1300 token，用 § 分隔，带有利用率指示器，在 80% 容量时进行合并。写入落在磁盘上，但系统提示词中持有冻结的快照直到下一会话，以保留前缀缓存。第二层，技能： 在完成 5 个以上工具调用任务后生成的程序化文档，按计划精炼。第三层，会话搜索： 使用 SQLite FTS5 搜索所有会话，按需总结。

不足之处。 容量很小（约 800 token 的持久记忆），FTS5 仅支持关键词（“429 错误“不会匹配“速率限制”），且是本地化的。正因如此，Hermes 提供了一个提供者插槽：使用 Mem0 后，容量限制消失，检索变为语义化，提取在服务端运行，写入按 MEM0_USER_ID 作用域划分，并且设有断路器，当服务不可用时内置层仍能工作。
了解更多：
mem0@mem0ai·4月4日·文章
如何为你的 Hermes Agent 添加记忆
Hermes Agent 刚刚增加了 6 个记忆提供者。Mem0 是其中之一。设置只需一条命令。任何失败都有断路器。记忆系统处理跨会话的存储、检索和上下文。…35648136K

7. @awscloud：Bedrock AgentCore
AgentCore 是 AWS 托管的 Agent 平台：其运行时是工具链层（AWS 对 Managed Agents 的类比），而记忆是其托管服务。记忆运行三种异步提取策略（语义事实、偏好、叙事总结），提取耗时约 20-40 秒，检索约 200ms；变更的事实被标记为 INVALID 而非删除，保留谱系。已发布：LoCoMo 70.58，PrefEval 79，PolyBench-QA 83.02。

不足之处。 它是 AWS 特有的（生态系统锁定），且其发布的 LoCoMo 得分远低于领先的记忆系统。

8. @windsurf：Windsurf
Windsurf 的记忆由其引擎 Cascade 生成和管理，没有开发者工作流：本地、工作空间作用域的文件位于 ~/.codeium/windsurf/memories/，捕获代码库模式与约定。

不足之处。 捕获的内容由 Cascade 决定，而非开发者；记忆是工作空间作用域的（跨项目不可见）且是本地的（无跨设备或团队共享）。

9. Cognition：Devin
Devin 将记忆分为两部分。知识是人工整理的触发器-内容事实（无自动捕获）；DeepWiki 是参考文档（30 页、100 条笔记、每条最多 10000 字符）。Devin 在会话结束后建议知识，但任何内容存储前需要人类审批。

不足之处。 审批门槛保证了质量但带来了摩擦：不审查的团队将不会积累任何内容。限制适中，且知识是为 Devin 整理的，因此无法转移到其他工具。

记忆基准测试是薄弱环节

该领域用来衡量记忆的基准测试大部分都不好。它们测试从过去对话中回忆事实的能力，接近饱和，高分并不能预测更好的决策能力。

LoCoMo 是最差的一个。 十个对话使得比较不可靠，许多问题不需要记忆（简单的 grep 基线得分约 74%），对抗性问题与目标存在表面相似性，因此模型可以通过模式匹配获胜。

LongMemEval 还算可以： 500 个精心设计的问题，涵盖五种能力（信息提取、多会话推理、时间推理、知识更新、弃权），规模向 150 万 token 扩展；仍然以回忆为中心，但算是一个真正的测试。

更深层的问题在于，这些基准测试没有衡量到的内容。MemoryArena（arXiv:2602.16313）测试的是必须指导行动的记忆，那些在 LoCoMo 和 LongMemEval 上接近饱和的系统在此失败；《Anatomy of Agentic Memory》（arXiv:2602.19320）对此进行了形式化批评（接近饱和，衡量相似性而非任务实用性）。并且没有基准测试在生产规模下进行：标准基准测试上限接近 150 万 token，而生产环境中的 Agent 可达 1000 万以上。BEAM（ICLR 2026）是唯一为此范围构建的基准测试。

诚实的结论是：该领域需要一个全新的记忆基准测试，对于排行榜上的得分，包括下面的那些，都应该持怀疑态度。

研究显示仍然存在的问题

稳定性-可塑性困境的迁移。 转向外部记忆并没有终结灾难性遗忘。《When Continual Learning Moves to Memory》（arXiv:2604.27003）显示，新旧记忆会竞争检索槽位，正如它们曾经竞争权重一样；来自简单任务的原始轨迹会损害较难任务（前向迁移降低 9.5%）。

选择性遗忘尚未解决。 MemoryAgentBench（arXiv:2507.05257）指出了四种能力；系统能处理检索，但无法处理选择性遗忘（在保持周围结构的同时遗忘过时事实）。

记忆是一个攻击面。 《No Attacker Needed》（arXiv:2604.01350）在正常使用下测量到 57-71% 的跨用户污染；投毒攻击成功率在 6-38% 之间（arXiv:2601.05504）。

不足之处中的模式

相同的差距反复出现。存储是有界且本地的（Claude Code 25KB，Hermes 2200 字符，Codex 5000 token 加载）。检索主要依赖关键词（Claude Code 按文件名，Codex 按 grep，Hermes 按 FTS5）；两个支持语义搜索的系统要么是本地且受限于压缩（OpenClaw），要么是云锁定（AgentCore）。记忆是工具链作用域的，因此 Claude Code 的记忆对 Codex 毫无意义。过期处理几乎不存在（Copilot 除外）。隔离性是事后才考虑的问题，因此才有了污染率数据。

这些都是工具链边界的限制。

Mem0

Mem0 专为解决工具链边界并非问题终点的情况而构建。其架构是混合型的：向量存储用于语义检索，知识图谱用于关系推理，键值存储用于快速元数据。v3 算法（2026 年 4 月）转向了单遍 ADD-only 提取、多信号检索（语义 + BM25 + 实体链接一次完成），以及向量存储内部的实体链接，去除了 v2 的外部图数据库。这在大约 6900 token 和 1.44 秒每次查询的条件下实现，而全上下文检索需要约 26000 token 和 17.12 秒。

针对上述差距：一个无上限的外部存储；多信号检索能在措辞不同的情况下找到上个月的认证端点讨论；按身份作用域的记忆使得一个用户的命名空间不会泄露到另一个用户，目标是解决 57-71% 的污染率。而且这不是理论性的：Mem0 为上述每个工具链提供支持——一个 Claude Code 插件、一个 Codex MCP 服务器、一流的 Hermes 和 OpenClaw 提供者、原生 AWS Strands 集成——覆盖 21 个框架和 20 个向量存储。记忆变成了基础设施，而非每个工具链的功能特性。

现状

记忆现在已是基础设施：每个主流工具链都已推出相关功能，因为一个在会话内能力强大但跨会话失忆的 Agent 根本上是受限的。工具链原生的记忆实现取得了切实进展，但它们在相同的边界上崩溃：有界本地存储、关键词检索、工具链作用域、过期处理薄弱、隔离缺口。用于衡量这一切的基准测试本身也很薄弱，而唯一测试生产规模的基准测试（BEAM）是大多数系统不报告的。

总的来说，这些都是 Mem0 正在努力填补的空白：可移植、可语义搜索、跨 Agent、并能扩展到生产环境 Agent 积累的 token 量的记忆。

上下文之内的第 11 期

本博客是 @mem0ai 博客系列《上下文之内》的一部分，涵盖 AI Agent 记忆和上下文工程。Mem0 是一个智能的开源记忆层，专为 LLM 和 AI Agent 设计，提供跨会话的长期、个性化和上下文感知的交互。

• 在此获取免费 API 密钥：app.mem0.ai
• 或从我们的开源 GitHub 仓库自托管 mem0

参考文献

• Contextual Agentic Memory is a Memo, Not True Memory (2026 年 4 月)
• MemoryArena (2026 年 2 月，Stanford/UCSD/Princeton)
• Anatomy of Agentic Memory (2026 年 2 月)
• When Continual Learning Moves to Memory (2026 年 4 月)
• MemoryAgentBench, ICLR 2026
• No Attacker Needed: Cross-User Contamination (2026 年 4 月)
• Memory Poisoning Attack and Defense (2025 年 1 月)
• Anthropic Engineering: Scaling Managed Agents (2026 年 4 月)
• OpenAI: Codex memories documentation
• AWS: Amazon Bedrock AgentCore Memory
• NousResearch: Hermes Agent
• Mem0: Token-Efficient Memory Algorithm (2026 年 4 月)
• Mem0: BEAM Benchmark
• Mem0: How Memory Works in Claude Code
• Mem0: Codex CLI Memory
• Mem0: How Memory Works in Hermes Agent
• Mem0: OpenClaw Memory System
• AWS and Mem0 Partner to Bring Persistent Memory to Strands