Agent Harness 中的记忆状态

@mem0ai
英语1个月前 · 2026年6月02日
194K
784
94
26
1.6K

TL;DR

深入分析 Claude Code 和 Codex 等 AI Agent 框架中的记忆架构,揭示为何当前基于本地和关键词的系统在扩展时会失效,并探讨 Mem0 如何提供一种可移植的替代方案。

Agent 的执行环境(harness)是 AI 软件实际运行的地方。Cursor、Devin、Claude Code、Codex 这些环境负责处理上下文、编排工具、协调 Agent,并且越来越多地管理记忆。真正交付软件产品的,是执行环境本身,而非模型本身。

而记忆,恰恰是执行环境设计中最棘手的部分。

记忆存放在哪里?会话结束后,哪些内容会保留?这基本上是一个尚未解决的问题,每个主流的执行环境都在以不同的方式解决它。

本文将介绍各个环境已推出的方案、各自的不足之处,以及这些差距揭示了记忆基础设施必须实现哪些功能。

Agent 记忆到底是什么

有三种不同的东西都被称为“记忆”,区分它们很重要,因为每种类型的失败模式都不同。

  1. 工作记忆:存在于会话期间上下文窗口中的内容。会话结束时重置;压缩问题(窗口满了之后哪些内容能幸存)属于这里。
  2. 外部记忆:存储在权重之外的任何内容:向量存储、知识图谱、文件。它跨会话持久存在;权重不会改变。2026 年,几乎所有生产环境中的记忆都属于这一类。
  3. 参数记忆:通过梯度下降编码到权重中的知识,由执行环境提供的训练循环塑造。它通过应用规则而不是检索示例来泛化。2026 年尚无任何生产部署。

(认知科学中的分类——语义/情景/程序——描述的是存储的信息类型;而上述三层描述的是存储位置。)

论文《上下文 Agent 记忆是备忘录,而非真正记忆》(arXiv:2604.27707)形式化地定义了天花板:检索需要 Ω(k²) 个存储示例才能匹配参数记忆通过 O(d) 次权重更新所能达到的效果。下面讨论的每个系统都局限在这个天花板内。

主流执行环境已推出的方案 [概述]

mem0 - inline image

1. @AnthropicAI:Claude Code

两条路径。CLAUDE.md 是人工编写的配置(约定、指令),在会话开始时读取。自动记忆 是由一个后台提取 Agent 用 Claude 撰写的笔记,存储在 ~/.claude/projects/<repo>/memory/ 目录下,围绕一个索引文件 MEMORY.md,大小上限为 200 行/25KB,分为四个类别:用户、反馈、项目、参考。

检索方式决定了其局限性:每次交互,Claude Code 会单独调用一个较小的模型,传入一个包含文件名和描述的清单,然后由模型决定加载哪些文件。没有嵌入(embedding),每轮最多加载五个文件,超过上限的文件会被静默截断(被丢弃的文件不会收到任何警告,因为它从未被加载)。

mem0 - inline image

局限性。 选择依据是文件名而非语义搜索,因此一个名字相关的文件会胜过一个内容相关的文件。团队共享功能隐藏在 TEAMMEM 标志后面,但本质上它只是本地、基于仓库范围的 Markdown,没有任何语义索引。

了解更多:

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 按照严格的模式提取信息,编辑掉敏感信息,并写入本地状态数据库(尚未写入记忆目录)。第二阶段,全局:在锁的保护下,一个合并子 Agent 进行合并、修补或丢弃操作,并写入差异内容。它有 bound(256 次 rollout),按时间老化(30 天),并感知速率限制。读取路径是非语义的:摘要被截断为固定的 5000 token 预算,其他内容通过对 MEMORY.md 进行 grep 查找。

mem0 - inline image

局限性。 5000 token 的摘要会静默截断;grep 仅支持子串匹配,因此改述后的事实无法被发现;六小时的空闲门槛意味着连续的会话可能永远不会被合并;状态仅限本地;并且在发布时,该功能在 EEA、英国和瑞士不可用。

了解更多:

4. @github Copilot

Copilot 的独特之处在于即时引用验证。记忆项是结构化对象(主题、事实内容、文件和行引用、推理),在引用之前,Agent 会验证引用与当前分支的一致性,如果代码现在与记忆矛盾,则会重写记忆。记忆还会在 28 天后自动过期。

这是唯一一个有已发布结果数据的老化机制:A/B 测试(p<0.00001),开启记忆后,PR 合并率从 83% 提升到 90%,代码审查精确度 +3%,召回率 +4%。这 7 个百分点的提升是编码 Agent 记忆中唯一已发布的真实世界生产指标;其他所有人报告的只是基准测试结果。

局限性。 引用模式无法干净地容纳无法落地或基于偏好的事实(“偏好最低限度的抽象”),并且它严格限定在仓库范围内。

5. @openclaw

OpenClaw 的原生记忆比看起来更强大:存储在 ~/.openclaw/workspace 中的 Markdown(一个精心组织的 MEMORY.md 加上带日期的日常日志),由每个 Agent 的 SQLite 索引支持,包含嵌入和混合检索(70% 向量,30% BM25)。因此它原生就具备语义搜索能力。

mem0 - inline image

问题在于哪些内容能幸存。当窗口填满时,OpenClaw 触发一个“静默内部交互”,要求模型在清空之前将重要内容写入磁盘。写入的内容完全由模型在那一次交互中决定,因此长期记忆具有选择性和不一致性。Mem0 插件(@mem0/openclaw-mem0)消除了这一依赖:自动召回 在每次交互前注入相关记忆,自动捕获 在每次交互后持久化每次交流的内容(新事实存储,旧事实更新,重复内容合并),按照会话的 run_id 和长期的 userId 进行范围划分。24.7 万星级的采用,很大程度上是由这一差距驱动的。

了解更多:https://mem0.ai/blog/openclaw-memory-management-live-data-compaction-and-best-practices

6. @NousResearch:Hermes Agent

Hermes(13.5 万星,200+ 模型)提供了三个内置层加上八个可插拔的提供者。第一层,工作记忆: MEMORY.md(2200 字符)和 USER.md(1375 字符),总共约 1300 token,用 § 分隔,带有利用率指示器,并在容量达到 80% 时进行合并。写入内容会落到磁盘上,但系统提示中会保存一个冻结的快照直到下一次会话,以保留前缀缓存。第二层,技能: 在完成 5 个以上的工具调用任务后编写的程序性文档,按计划进行整理。第三层,会话搜索: 使用 SQLite FTS5 对所有会话进行搜索,按需汇总。

mem0 - inline image

局限性。 容量非常小(约 800 token 的持久记忆),FTS5 仅支持关键词(“429 errors” 无法匹配 “rate limiting”),并且是本地存储。这就是为什么 Hermes 提供了一个提供者插槽:有了 Mem0,容量限制消失,检索变成语义式,提取在服务端运行,写入按 MEM0_USER_ID 进行范围划分,并且一个断路器确保在服务宕机时内置层仍能正常工作。

了解更多:

7. @awscloud Bedrock AgentCore

AgentCore 是 AWS 的托管 Agent 平台:其 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 生成和管理,没有开发人员工作流程:本地、工作区范围的文件存储在 ~/.codeium/windsurf/memories/,用于捕获代码库模式和约定。

局限性。 捕获的内容是由 Cascade 决定的,而不是开发者;记忆是工作区范围的(跨项目不可见),并且是本地存储(没有跨设备或团队共享)。

9. Cognition Devin

Devin 将记忆分为两部分。Knowledge 是人工整理的触发器-内容事实(没有自动捕获);DeepWiki 是参考文档(30 页,100 条笔记,每条 10,000 字符)。Devin 会在会话后建议 Knowledge,但需要人工批准后才能存储任何内容。

局限性。 批准门槛保证了质量,但带来了摩擦:不进行审查的团队什么也积累不了。限制适中,且 Knowledge 是为 Devin 整理的,因此无法转移到其他工具。

记忆基准测试是薄弱环节

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

LoCoMo 是常见基准中最差的。 十轮对话使得比较不可靠,许多问题不需要记忆(一个简单的 grep 基线得分约为 74%),对抗性问题与目标有表面相似性,因此模型通过模式匹配获胜。LongMemEval 还算可以: 500 个精心设计的问题,涵盖五种能力(信息提取、多会话推理、时间推理、知识更新、弃权),规模扩展至 150 万 token;仍然以 recall 为中心,但确实是一个真正的测试。

更深层的问题是它们都没有衡量的东西。MemoryArena(arXiv:2602.16313)测试的是必须指导行动的记忆,而接近饱和 LoCoMo 和 LongMemEval 的系统在其中失败;《Agent 记忆的剖析》(arXiv:2602.19320)形式化地提出了批评(接近饱和,衡量的是相似性而非任务效用)。

而且没有基准测试是在生产规模下进行的:标准基准测试上限约为 150 万 token,而生产 Agent 会达到 1000 万 token 以上。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 2200 字符,Codex 5000 token 加载)。检索大多是关键词驱动的(Claude Code 按文件名,Codex 按 grep,Hermes 按 FTS5);两个进行语义搜索的要么是本地且受限于压缩(OpenClaw),要么是云锁定(AgentCore)。记忆是执行环境范围内的,因此 Claude Code 的记忆对 Codex 毫无意义。过时处理几乎不存在(Copilot 除外)。而隔离是事后才想到的,因此出现了污染数字。这些都是执行环境边界的限制。

Mem0

Mem0 正是针对执行环境边界并非问题终点的情况而构建的。其架构是混合的:向量存储用于语义检索,知识图谱用于关系推理,键值存储用于快速元数据。

v3 算法(2026 年 4 月)转向了单次 ADD 仅提取、多信号检索(单次通过中完成语义 + BM25 + 实体链接),并在向量存储内部进行实体链接,放弃了 v2 的外部图谱数据库。

mem0 - inline image

它实现了每次查询约 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 量级的记忆。

In Context #11

本文是 In Context 系列的一部分,这是一个由 @mem0ai 撰写的博客系列,涵盖 AI Agent 记忆和上下文工程。

Mem0 是一个智能的开源记忆层,专为 LLM 和 AI Agent 设计,用于在会话间提供长期、个性化且上下文感知的交互。

参考文献

https://x.com/mem0ai/status/2039041449854124229

https://x.com/mem0ai/status/2054580022049198513

https://x.com/mem0ai/status/2040149098364580026

一键保存

使用 YouMind AI 深度阅读爆款文章

保存原文、追问细节、总结观点,并在一个 AI 工作空间里把爆款文章沉淀成可复用笔记。

了解 YouMind
写给创作者

把你的 Markdown 变成干净的 𝕏 文章

图片上传、表格、代码块,往 𝕏 上手动重排太痛苦。YouMind 把整篇 Markdown 一键转成干净、可直接发布的 𝕏 文章草稿。

试试 Markdown 转 𝕏

更多可拆解样本

近期爆款文章

探索更多爆款文章