智能体运行框架中的记忆现状

智能体运行框架中的记忆现状 智能体运行框架中的记忆现状 Modified June 4 Copilot 最有辨识度的做法是即时引用验证。记忆条目是结构化对象，包括主题、事实内容、文件和行号引用、推理过程。使用前，智能体会根据当前分支验证引用；如果当前代码已经与记忆相矛盾，就会重写这条记忆。记忆也会在 28 天后自动过期。 这是唯一一个已部署、并公布结果数据的过时处理机制：A/B 测试结果显示（p<0.00001），启用记忆后 PR 合并率从 83% 上升到 90%，代码评审 precision 提升 3%，recall 提升 4%。这 7 个百分点提升，是目前编码智能体记忆中唯一公开的真实生产指标；其他系统报告的多是基准测试。 短板：引用 schema 很难干净承载无法落到代码证据上或偏好型的事实，例如“偏好最少抽象”；而且它严格限定在仓库范围内。 5. @openclaw OpenClaw 的原生记忆比表面看起来更强： /.openclaw/workspace 下的 Markdown，包括一份经整理的 MEMORY.md 和按日期记录的每日日志，背后有每个智能体自己的 SQLite 索引，带 embedding 和混合检索，比例为 70% 向量、30% BM25。因此，它原生具备语义搜索。 问题在于哪些内容能留下来。当窗口填满时，OpenClaw 会触发一次“静默内部轮次”，要求模型在清空前把重要内容写到磁盘。写下来的内容完全取决于模型在那一轮中的判断，因此长期记忆是选择性的，也不稳定。Mem0 插件（@mem0/openclaw mem0）消除了这种依赖：Auto Recall 会在每轮之前注入相关记忆，Auto Capture 会在每次交流后持久化内容，新事实被存储，过时事实被更新，重复内容被合并；作用域由会话 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+ 模型）内置三层记忆，并支持八个可插拔 provider。第一层，工作记忆： MEMORY.md（2,200 字符）和 USER.md（1,375 字符），合计约 1,300 tokens，以 § 分隔，带利用率仪表，并在容量达到 80% 时合并。写入会落到磁盘，但为了保留 prefix cache，system prompt 中会持有一个冻结快照，直到下一次会话。第二层，skills： 在 5 次以上工具调用任务之后写入程序性文档，并按计划整理。第三层，会话搜索： 对所有会话建立 SQLite FTS5 索引，并按需生成概要。 短板：上限很小，大约只有 800 tokens 的持久记忆；FTS5 只是关键词检索，429 errors 不会匹配 rate limiting；并且它是本地的。这也是 Hermes 提供 provider 插槽的原因：接入 Mem0 后，上限消失，检索变为语义式，提取在服务端运行，写入按 MEM0 USER ID 设定作用域，并且有断路器保证服务不可用时内置层仍能工作。 7. @awscloud：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 Windsurf 的记忆由它的引擎 Cascade 生成和管理，没有开发者工作流：本地、workspace 作用域的文件位于 /.codeium/windsurf/memories/，捕获代码库模式和约定。 短板：捕获什么由 Cascade 决定，而不是由开发者决定；记忆限定在 workspace 范围内，跨项目不可见；并且是本地的，没有跨设备或团队共享。 9. Cognition Devin Devin 把记忆分成两部分。Knowledge 是由人类整理的触发器 内容事实，不自动捕获；DeepWiki 是参考文档，限制为 30 页、100 条笔记、每条 10,000 字符。Devin 会在会话后建议 Knowledge，但任何内容存储前都需要人类批准。 短板：批准门槛保证了质量，但也带来摩擦：不评审的团队什么也积累不下来。限制也不大，而且 Knowledge 是为 Devin 整理的，不能迁移到其他工具。 记忆基准测试是薄弱环节 这个领域用来衡量记忆的基准测试大多不好。它们测试的是从过去对话中回忆事实，已经接近饱和，而且高分并不能预测更好的决策。 LoCoMo 是常见基准中最差的一个。 只有 10 段对话，使比较不可靠；很多问题根本不需要记忆，一个简单的 grep 基线就能拿到约 74%；而且对抗性问题与目标问题在表面上高度相似，所以模型可以靠模式匹配获胜。LongMemEval 仍然还可以： 500 个精心整理的问题，覆盖五种能力：信息抽取、多会话推理、时间推理、知识更新、拒答；规模扩展到约 1.5M tokens。它仍然偏重回忆，但至少是一个真实测试。 更深层的问题是，它们没有衡量真正关键的东西。MemoryArena（arXiv:2602.16313）测试的是必须指导行动的记忆，而那些在 LoCoMo 和 LongMemEval 上接近饱和的系统，在这里会失败；Anatomy of Agentic Memory（arXiv:2602.19320）把这个批评形式化了：这些基准接近饱和，测的是相似度，不是任务效用。 而且，没有任何一个在生产规模上测试。标准基准通常卡在约 1.5M tokens，而生产智能体会达到 10M+。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 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 秒。 对应上面的缺口：外部存储没有上限；多信号检索可以找到上个月关于 auth endpoint 的讨论，即使用词不同；按身份设定作用域的记忆让一个用户的 namespace 不会泄漏到另一个用户那里，目标正是 57 71% 的污染率。它也不是理论：Mem0 已经支持上面所有运行框架，包括 Claude Code 插件、Codex MCP server、Hermes 和 OpenClaw 的一等 provider、AWS Strands 原生集成，覆盖 21 个框架和 20 个向量库。记忆变成基础设施，而不是某个运行框架里的功能。 现在处于什么位置 记忆现在已经是基础设施：每个主要运行框架都发布了它，因为一个智能体如果只在单次会话内有能力、跨会话却失忆，本质上会受到限制。 运行框架原生实现取得了真实进展，但它们在同一个边界上失效：有边界的本地存储、关键词检索、运行框架作用域、薄弱的过时处理，以及隔离缺口。 用于衡量这些能力的基准本身也很弱，而唯一测试生产规模的 BEAM，正是大多数系统没有报告的基准。 整体来看，这些正是 Mem0 正在努力填补的缺口：可迁移、可语义搜索、跨智能体，并且能扩展到生产智能体所累积 token 规模的记忆。 In Context 11 这篇博客是 In Context 的一部分。In Context 是 @mem0ai 的博客系列，关注 AI Agent 记忆 和上下文工程。 Mem0 是一个智能、开源的记忆层，专为 LLM 和 AI agents 设计，用于在跨会话交互中提供长期、个性化且感知上下文的体验。 • 在这里获取免费 API Key：app.mem0.ai • 或者从我们的开源 GitHub 仓库自托管 mem0 参考文献 • Contextual Agentic Memory is a Memo, Not True Memory (April 2026) • MemoryArena (February 2026, Stanford/UCSD/Princeton) • Anatomy of Agentic Memory (February 2026) • When Continual Learning Moves to Memory (April 2026) • MemoryAgentBench, ICLR 2026 • No Attacker Needed: Cross User Contamination (April 2026) • Memory Poisoning Attack and Defense (January 2025) • Anthropic Engineering: Scaling Managed Agents (April 2026) • OpenAI: Codex memories documentation • AWS: Amazon Bedrock AgentCore Memory • NousResearch: Hermes Agent • Mem0: Token Efficient Memory Algorithm (April 2026) • 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 app.mem0.ai 开源 GitHub 仓库 Contextual Agentic Memory is a Memo, Not True Memory (April 2026) MemoryArena (February 2026, Stanford/UCSD/Princeton) Anatomy of Agentic Memory (February 2026) When Continual Learning Moves to Memory (April 2026) MemoryAgentBench, ICLR 2026 No Attacker Needed: Cross User Contamination (April 2026) Memory Poisoning Attack and Defense (January 2025) Anthropic Engineering: Scaling Managed Agents (April 2026) OpenAI: Codex memories documentation AWS: Amazon Bedrock AgentCore Memory NousResearch: Hermes Agent Mem0: Token Efficient Memory Algorithm (April 2026) 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 Copilot 最有辨识度的做法是即时引用验证。记忆条目是结构化对象，包括主题、事实内容、文件和行号引用、推理过程。使用前，智能体会根据当前分支验证引用；如果当前代码已经与记忆相矛盾，就会重写这条记忆。记忆也会在 28 天后自动过期。 这是唯一一个已部署、并公布结果数据的过时处理机制：A/B 测试结果显示（p<0.00001），启用记忆后 PR 合并率从 83% 上升到 90%，代码评审 precision 提升 3%，recall 提升 4%。这 7 个百分点提升，是目前编码智能体记忆中唯一公开的真实生产指标；其他系统报告的多是基准测试。 短板：引用 schema 很难干净承载无法落到代码证据上或偏好型的事实，例如“偏好最少抽象”；而且它严格限定在仓库范围内。 5. @openclaw OpenClaw 的原生记忆比表面看起来更强： /.openclaw/workspace 下的 Markdown，包括一份经整理的 MEMORY.md 和按日期记录的每日日志，背后有每个智能体自己的 SQLite 索引，带 embedding 和混合检索，比例为 70% 向量、30% BM25。因此，它原生具备语义搜索。 问题在于哪些内容能留下来。当窗口填满时，OpenClaw 会触发一次“静默内部轮次”，要求模型在清空前把重要内容写到磁盘。写下来的内容完全取决于模型在那一轮中的判断，因此长期记忆是选择性的，也不稳定。Mem0 插件（@mem0/openclaw mem0）消除了这种依赖：Auto Recall 会在每轮之前注入相关记忆，Auto Capture 会在每次交流后持久化内容，新事实被存储，过时事实被更新，重复内容被合并；作用域由会话 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+ 模型）内置三层记忆，并支持八个可插拔 provider。第一层，工作记忆： MEMORY.md（2,200 字符）和 USER.md（1,375 字符），合计约 1,300 tokens，以 § 分隔，带利用率仪表，并在容量达到 80% 时合并。写入会落到磁盘，但为了保留 prefix cache，system prompt 中会持有一个冻结快照，直到下一次会话。第二层，skills： 在 5 次以上工具调用任务之后写入程序性文档，并按计划整理。第三层，会话搜索： 对所有会话建立 SQLite FTS5 索引，并按需生成概要。 短板：上限很小，大约只有 800 tokens 的持久记忆；FTS5 只是关键词检索，429 errors 不会匹配 rate limiting；并且它是本地的。这也是 Hermes 提供 provider 插槽的原因：接入 Mem0 后，上限消失，检索变为语义式，提取在服务端运行，写入按 MEM0 USER ID 设定作用域，并且有断路器保证服务不可用时内置层仍能工作。 7. @awscloud：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 Windsurf 的记忆由它的引擎 Cascade 生成和管理，没有开发者工作流：本地、workspace 作用域的文件位于 /.codeium/windsurf/memories/，捕获代码库模式和约定。 短板：捕获什么由 Cascade 决定，而不是由开发者决定；记忆限定在 workspace 范围内，跨项目不可见；并且是本地的，没有跨设备或团队共享。 9. Cognition Devin Devin 把记忆分成两部分。Knowledge 是由人类整理的触发器 内容事实，不自动捕获；DeepWiki 是参考文档，限制为 30 页、100 条笔记、每条 10,000 字符。Devin 会在会话后建议 Knowledge，但任何内容存储前都需要人类批准。 短板：批准门槛保证了质量，但也带来摩擦：不评审的团队什么也积累不下来。限制也不大，而且 Knowledge 是为 Devin 整理的，不能迁移到其他工具。 记忆基准测试是薄弱环节 这个领域用来衡量记忆的基准测试大多不好。它们测试的是从过去对话中回忆事实，已经接近饱和，而且高分并不能预测更好的决策。 LoCoMo 是常见基准中最差的一个。 只有 10 段对话，使比较不可靠；很多问题根本不需要记忆，一个简单的 grep 基线就能拿到约 74%；而且对抗性问题与目标问题在表面上高度相似，所以模型可以靠模式匹配获胜。LongMemEval 仍然还可以： 500 个精心整理的问题，覆盖五种能力：信息抽取、多会话推理、时间推理、知识更新、拒答；规模扩展到约 1.5M tokens。它仍然偏重回忆，但至少是一个真实测试。 更深层的问题是，它们没有衡量真正关键的东西。MemoryArena（arXiv:2602.16313）测试的是必须指导行动的记忆，而那些在 LoCoMo 和 LongMemEval 上接近饱和的系统，在这里会失败；Anatomy of Agentic Memory（arXiv:2602.19320）把这个批评形式化了：这些基准接近饱和，测的是相似度，不是任务效用。 而且，没有任何一个在生产规模上测试。标准基准通常卡在约 1.5M tokens，而生产智能体会达到 10M+。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 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 秒。 对应上面的缺口：外部存储没有上限；多信号检索可以找到上个月关于 auth endpoint 的讨论，即使用词不同；按身份设定作用域的记忆让一个用户的 namespace 不会泄漏到另一个用户那里，目标正是 57 71% 的污染率。它也不是理论：Mem0 已经支持上面所有运行框架，包括 Claude Code 插件、Codex MCP server、Hermes 和 OpenClaw 的一等 provider、AWS Strands 原生集成，覆盖 21 个框架和 20 个向量库。记忆变成基础设施，而不是某个运行框架里的功能。 现在处于什么位置 记忆现在已经是基础设施：每个主要运行框架都发布了它，因为一个智能体如果只在单次会话内有能力、跨会话却失忆，本质上会受到限制。 运行框架原生实现取得了真实进展，但它们在同一个边界上失效：有边界的本地存储、关键词检索、运行框架作用域、薄弱的过时处理，以及隔离缺口。 用于衡量这些能力的基准本身也很弱，而唯一测试生产规模的 BEAM，正是大多数系统没有报告的基准。 整体来看，这些正是 Mem0 正在努力填补的缺口：可迁移、可语义搜索、跨智能体，并且能扩展到生产智能体所累积 token 规模的记忆。 In Context 11 这篇博客是 In Context 的一部分。In Context 是 @mem0ai 的博客系列，关注 AI Agent 记忆 和上下文工程。 Mem0 是一个智能、开源的记忆层，专为 LLM 和 AI agents 设计，用于在跨会话交互中提供长期、个性化且感知上下文的体验。 • 在这里获取免费 API Key：app.mem0.ai app.mem0.ai • 或者从我们的开源 GitHub 仓库自托管 mem0 开源 GitHub 仓库 参考文献 • Contextual Agentic Memory is a Memo, Not True Memory (April 2026) Contextual Agentic Memory is a Memo, Not True Memory (April 2026) • MemoryArena (February 2026, Stanford/UCSD/Princeton) MemoryArena (February 2026, Stanford/UCSD/Princeton) • Anatomy of Agentic Memory (February 2026) Anatomy of Agentic Memory (February 2026) • When Continual Learning Moves to Memory (April 2026) When Continual Learning Moves to Memory (April 2026) • MemoryAgentBench, ICLR 2026 MemoryAgentBench, ICLR 2026 • No Attacker Needed: Cross User Contamination (April 2026) No Attacker Needed: Cross User Contamination (April 2026) • Memory Poisoning Attack and Defense (January 2025) Memory Poisoning Attack and Defense (January 2025) • Anthropic Engineering: Scaling Managed Agents (April 2026) Anthropic Engineering: Scaling Managed Agents (April 2026) • OpenAI: Codex memories documentation OpenAI: Codex memories documentation • AWS: Amazon Bedrock AgentCore Memory AWS: Amazon Bedrock AgentCore Memory • NousResearch: Hermes Agent NousResearch: Hermes Agent • Mem0: Token Efficient Memory Algorithm (April 2026) Mem0: Token Efficient Memory Algorithm (April 2026) • Mem0: BEAM Benchmark Mem0: BEAM Benchmark • Mem0: How Memory Works in Claude Code Mem0: How Memory Works in Claude Code • Mem0: Codex CLI Memory Mem0: Codex CLI Memory • Mem0: How Memory Works in Hermes Agent Mem0: How Memory Works in Hermes Agent) • Mem0: OpenClaw Memory System Mem0: OpenClaw Memory System • AWS and Mem0 Partner to Bring Persistent Memory to Strands AWS and Mem0 Partner to Bring Persistent Memory to Strands 原帖链接：https://x.com/mem0ai/status/20618