Mem0 论文在 LOCOMO 上跑出的最高分不属于任何记忆系统,而属于"把整段对话原样塞进上下文"这个基线:72.90,高于表现最好的记忆系统 Mem0-g 的 68.44。也就是说,你辛苦搭的记忆层大概率不会让 agent 更准,它让 agent 更快更便宜——同一张表里,Mem0 把总延迟 p95 从 17.117s 压到 1.440s、每对话 token 从约 26,000 压到约 7,000。所以这篇文章的第一条建议是:在决定上哪种记忆之前,先把"全塞进去"跑一遍,它既是你的准确率上限,也是你唯一诚实的对照组。
先别急着上图谱:agent 记忆卖的是效率,不是准确率
阅读正文 ↗点击知识块看内容，点击连线看依据。没有关系的块也保留。
正在读取关系，知识块已可查看。
先看完整的 LOCOMO 结果(LLM-as-judge 分,越高越好,数据来自 Mem0 论文 arXiv:2504.19413):
| 题型 | full-context | Mem0 | Mem0-g | Zep | LangMem | OpenAI Memory | A-Mem |
|---|---|---|---|---|---|---|---|
| single-hop | — | 67.13 | 65.71 | 61.70 | 62.23 | 63.79 | 39.79 |
| multi-hop | — | 51.15 | 47.19 | 41.35 | 47.92 | 42.92 | 18.85 |
| open-domain | — | 72.93 | 75.71 | 76.60 | 71.12 | 62.29 | 54.05 |
| temporal | — | 55.51 | 58.13 | 49.31 | 23.43 | 21.71 | 49.91 |
| 总分 | 72.90 | 66.88 | 68.44 | 65.99 | 58.10 | 52.90 | 48.38 |
这张表最该被引用的一行是最左边那列。没有一个记忆系统追平"全塞进去",最好的 Mem0-g 还差 4.46 分。而它换回来的是:总延迟 p95 从 17.117s → 2.590s,每对话 token 从约 26,000 → 约 14,000;纯向量的 Mem0 更极端,搜索延迟 p50 只有 0.148s、p95 0.200s。
这个结论的可信度在于它是被两篇互为竞品的论文同时给出的。Zep 在 DMR 基准上报 94.8%(gpt-4-turbo),比 MemGPT 的 93.4% 高——但同一张表里"全量对话"基线是 94.4%,只差 0.4 个点。一个记忆系统的作者,主动公布了对自己不利的基线,这种数字比宣传材料里的相对提升可信得多。
由此推出三条必须刻在脑子里的引用纪律:
- "MemGPT 把 DMR 从 32.1% 提到 92.5%"不能用来论证记忆优于长上下文。 那个 32.1% 是不给任何记忆的裸模型,不是塞满上下文的模型;后者在 DMR 上是 94.4%。
- "Mem0 提升 26%"和"省 90% token"不是同一次比较。 26% 是相对 OpenAI Memory 的准确率提升(52.90 → 66.88),90%+ 的 token 节省和 91% 的 p95 延迟下降都是相对 full-context。三个数字三个基线。
- RAG 基线的方差比记忆层之间的差距还大。 同一批数据上,RAG 的 F1 随 chunk 大小与 k 值在 5.00–49.56 之间剧烈波动。你如果拿一个没调过的 RAG 当对照组,几乎可以"证明"任何结论。
那记忆层什么时候真的能提准确率?当全量塞不下,或者塞得下但已经长到伤害模型的时候。 Zep 在 LongMemEval(平均 115k token 的长会话)上把送进模型的上下文压到平均 1.6k token,gpt-4o 准确率反而从 60.2% 升到 71.2%(+18.5%),延迟从 28.9s 降到 2.58s。同一套机制,在 26k token 的 LOCOMO 上是净亏,在 115k token 的 LongMemEval 上是净赚。
所以真正的判据不是"要不要记忆",而是"你的会话长度落在哪一侧"。 全量上下文能装下且延迟成本可接受 → 别建记忆层,你在给自己找准确率损失。装不下,或者 p95 延迟/单次成本已经超标 → 记忆层是效率工程,按效率指标验收,别指望它顺手把准确率也提上去。
决定要上记忆之后,第一件事不是选数据库,是分类。CoALA(arXiv:2309.02427)给出的四分法在 MemGPT、Letta、Claude Code 三个独立实现上都能对上槽位:
| 类别 | 是什么 | 工程落点 | 写入时机 | 典型失效 |
|---|---|---|---|---|
| 工作记忆 | 当前决策周期的活跃变量 | context window 本身 | 每 token 都在变 | 被挤爆 / 中段失焦 |
| 情景记忆 | 发生过什么(轨迹、消息、观察) | append + 时间戳的消息库 | 事件发生即 append | 无界膨胀 |
| 语义记忆 | 是什么(蒸馏出的断言) | 事实条目 / memory block / MEMORY.md | 需要一次抽取或巩固动作 | 陈旧、被投毒 |
| 程序记忆 | 怎么做(约定、流程、禁令) | 代码、提示词、CLAUDE.md | 规则被违反或被纠正时才改 | 膨胀稀释遵从度 |
四分法的价值不在于建四个数据库——真实系统里情景与语义常共用一个向量库,只靠 metadata 区分;强行拆库会让"从情景蒸馏语义"变成跨库事务。它的价值在于:四类的写入时机和 TTL 必须分别定义。用同一套 write policy 管四类,就是把"今天调试用了 grep"和"本项目禁止直接 push"扔进同一个池子——前者三天后就是垃圾,后者半年内都得逐字生效。
程序记忆是最容易被误分类的一类。"提交前跑 npm test"不是语义事实,是程序记忆;它的正确写入时机是"规则被违反了"或"你把上次打过的纠正又打了一遍",而不是"这次会话提到了它"。
写入闸的三种形态
形态一:事件驱动的显式写(最省)。 只在状态真的变了的时候写。Claude Code 的 auto memory 就是这个立场——它不是每次会话都存,而是判断这条信息在未来某次对话里是否用得上。官方给的四条触发条件其实是"重获成本高"的操作化定义:Claude 第二次犯同一个错、code review 抓到本该知道的事、你把上次打过的纠正又打一遍、新同事需要同样的上下文。
形态二:LLM 决策的四操作写(Mem0 路线)。 把写入建模成对现有记忆集合的编辑而不是追加:候选事实先用向量检索取 top-s(s=10)条最相似的已有记忆,再让 LLM 通过 tool call 选 ADD / UPDATE / DELETE / NOOP。关键设计是不用独立分类器,写入与冲突消解合并成一步。纯 append 的库必然线性膨胀,这一步是它唯一的刹车。
形态三:异步后台写(sleep-time)。 Letta 的 sleep-time agent 与主 agent 共享 memory block,在后台从对话历史生成 learned context 并异步改写。主循环延迟不受影响,代价是记忆滞后于当前会话。
决定成本的是粒度,不是数据库
这是本节最反直觉的一条:同一份对话,Zep 平均每对话 token 开销超过 600,000,Mem0 约 7,000,差了近两个数量级。 Mem0 论文对此的归因是"在每个节点缓存 abstractive summary、又在边上存事实",造成大量冗余。
请注意这不是信息量的差距——两个系统消费的是同一批对话。膨胀来自表示冗余。 Mem0 之所以能压到 7,000,是因为它的抽取阶段根本不喂全量历史,只喂"会话摘要 S + 最近 m=10 条消息 + 当前消息对",让上下文长度与会话总长解耦。
所以选型时问的第一个问题不该是"用向量库还是图库",而该是"一次交互产生几条记忆、每条多长"。这个数乘以你的会话量,直接决定运营成本。
纪律必须由 harness 强制
三处独立实现给出同一个信念:写在提示词里的"请精简"不管用。
- Claude Code 对
MEMORY.md设 200 行 / 25KB 硬上限,接近上限时提示精简,超限时写入仍成功但返回错误要求重写索引——因为超出部分下次加载会被直接丢掉,你以为记住了其实没有; - Letta 给 memory block 设 2000 字符默认上限,并把当前用量/上限渲染进 prompt,让模型看得见自己的"内存水位";
- MemGPT 在上下文占用 70% 时注入内存压力警告,100% 时冲刷队列、一次驱逐约 50% 并递归摘要。
流行叙事是这样的:向量记忆只能一次召回,多跳关联需要显式的边,所以复杂推理要上知识图谱。同一张 LOCOMO 表直接反驳了它。
- multi-hop:向量记忆 Mem0 拿 51.15,图变体 Mem0-g 只有 47.19,Zep 更低,41.35。
- single-hop:Mem0 67.13 > Mem0-g 65.71 > Zep 61.70。
- 图唯一稳赢的是 temporal:Mem0-g 58.13 vs Mem0 55.51;而完全不建时序模型的 OpenAI Memory 只有 21.71、LangMem 23.43——两倍多的差距。
为什么多跳反而输?因为多跳失败的主因通常不是"缺少显式的边",而是抽取时把事实丢了。图的抽取管线更长(entity extractor → relationship generator 两次 LLM 调用),丢失概率更高;而且实体消解错一次会污染整个邻域的多跳结果,文本条目抽错只影响一条召回。图的爆炸半径比向量大。
代价那边同样清楚:Mem0-g 相对 Mem0 总分 +1.56,换来的是 token 约 2 倍(7,000 → 14,000)、搜索延迟 p50 约 3.2 倍(0.148s → 0.476s)。
那图什么时候值得上?只有三个信号,缺一不可地问自己:
- 你的查询里有大量"什么时候变的 / 那时候是什么状态"。 时序是图唯一有稳定量化收益的高级特性,靠的是双时间轴——每条边同时挂事件时间轴的
t_valid/t_invalid(现实世界何时开始/停止为真)和事务时间轴的t'_created/t'_expired(何时进入/退出系统)。 - 你需要审计不可删的事实变更史。 向量记忆用 DELETE 抹掉旧条目,历史就没了;图把冲突边的
t_invalid置为新边的t_valid,旧边留在图上退出默认召回,"这条在哪段时间为真"仍可查询。合规场景只有图给得起这个语义。 - 实体间的关系本身就是业务对象(组织架构、供应链、病历时间线),而不只是检索的辅助结构。
如果你说不清哪个题型会因为上图变好,+1.56 分换 2 倍 token 和 3 倍延迟就是净亏。可行的中间路线是混合:非损耗原始记录 + 抽取事实走向量,只把关系与有效期这一小部分建图,避开 Zep 式的全量摘要冗余。
顺带说一句,写侧和读侧的瓶颈要分开看。Zep 那组 LongMemEval 数据(115k → 1.6k、准确率 +18.5%、延迟 −90%)是真的,和它每对话 60 万 token 的开销也不矛盾:图的构建很贵,构建完之后的检索上下文很省。 你的瓶颈在写侧还是读侧,决定这笔账划不划算。
没有遗忘机制的记忆库,召回质量随时间单调下降。工程上有四种可组合的实现,按可逆性从高到低:
1. 检索期软衰减。 不删数据,只在打分时乘一个随时间下降的因子。Generative Agents(arXiv:2304.03442)的三因子打分是这一路的范式:
score = α_recency · recency + α_importance · importance + α_relevance · relevance论文实现里三个 α 全取 1,三项各自 min-max 归一化。recency 用衰减因子 0.995,自变量是"距上次被检索以来的沙盒小时数"——注意基准是上次访问而非创建时间,所以被反复用到的记忆自动保鲜。importance 是写入时 LLM 打的 1–10 分,relevance 是余弦相似度。
这条对工程的直接启示是:只用余弦相似度检索记忆,是记忆系统最常见的设计缺陷,因为它同时丢掉了时间维度和分量维度。
2. 艾宾浩斯式强度模型。 MemoryBank(arXiv:2305.10250)把心理学遗忘曲线直接搬进来:
R = e^(−t / S)R 是保持率,t 是距上次学习的时间,S 是记忆强度。更新规则很朴素:S 是离散值,首次被提及时初始化为 1,每被回忆一次 S 加 1 且 t 重置为 0。
但这里必须标注一条边界:作者自己写明这是"an exploratory and highly simplified memory updating model"。 不同类型的记忆该用什么衰减率、能不能学出来,至今没有系统研究——Generative Agents 用 0.995,MemoryBank 用 R=e^(−t/S),两者之间没有任何可比性。照抄公式可以,但别以为你抄到了最优参数。 MemoryBank 自己的评估规模也很小:15 个虚拟用户、10 个模拟日、194 道探针题,检索准确率英文 0.763 / 中文 0.711——约四分之一的探针召回失败。
3. 事实级失效而非删除。 就是上一节的 t_invalid。高风险域应默认走失效标记,因为误删一条正确事实的代价,通常远高于多留一条陈旧事实。
4. 硬性容量淘汰。 200 行 / 25KB、2000 字符——把遗忘从"模型自觉"变成物理约束。
两条实操边界:
- 不要在没有访问统计的系统里上软衰减。 它依赖"上次被检索时间";记忆层如果没记录访问事件,衰减就退化成"按创建时间惩罚旧记忆",会精确误杀最稳定的那批事实(用户身份、项目约定)。
- 衰减太快会吃掉近场信息。 Zep 在 LongMemEval 上分题型收益从 single-session-preference +184% 横跨到 single-session-assistant −17.7%,后者就是被压缩掉的近期细节恰恰是那类题需要的。给稳定事实关掉衰减,给临时决定加快衰减,不能一刀切。
这三种失效看起来是三件事,其实都始于同一句话:某条内容不该以这个形式进入持久层。
记忆过期比没有记忆更危险
这不是修辞。没有记忆的 agent 面对不确定会去查;持有过期记忆的 agent 会自信地不查,并且用那条陈旧记忆反驳你当场给的正确信息——因为记忆条目读回来时的确定性,和刚写下时一模一样,没有置信度衰减。
四条一眼可认的指纹:
- 错误内容恰好是"某个时刻的快照":版本号、路径、端口、"当前有 3 个服务"这类可计数事实;而且错误方向永远是"落后于现实",不是随机幻觉。
- 同一错误跨会话稳定复现。清空对话重开还错 → 来自持久层。这是与普通幻觉最快的区分手段。
- grep 记忆库能搜到原文,且写入时它是对的。
- 条目没有时间戳,或时间戳远早于相关代码的最后修改时间(对比
git log -1 --format=%cI -- <path>)。
根治手段只有一个,而且在写入侧:记方法不记快照。写"用 git log -1 查最后修改时间",不写"最后修改是 3 月 12 日"。配套动作是给快照类事实强制带时间戳(Claude Code 在写带 YAML frontmatter 的记忆文件时自动记 modified ISO 8601 字段),以及按类型配 TTL:身份/约定类近乎永久,配置/拓扑类以周计,数值指标类以小时计。
读取侧的纪律同样简单:记忆只用来决定"去哪儿查",不直接当事实用。 记忆里存轻量指针,关键决策前现场用工具取回真值。
要特别注意:纯文本记忆没有自动冲突消解。Claude Code 官方文档说得很直白——如果两条规则互相矛盾,Claude 可能任意挑一条。而 embedding 也判不出矛盾:"服务在 A"和"服务在 B"余弦相似度很高,靠相似度去重永远发现不了它们互斥。这就是 Mem0 用 LLM 而不是阈值做裁决的原因。
膨胀:加记忆反而让 agent 变笨
诊断指纹里最有用的一条是启动上下文占比:会话还没开始干活,记忆/指令文件已经吃掉相当比例的窗口。另一条容易被忽略的是误以为拆文件能省 context——@path 导入只帮助组织,被导入文件在启动时一样全量加载,最多递归 4 跳。正确解法是分层:索引常驻 + 细节按需读,把检索退化成"读索引 + 按需 open"。
投毒:攻击者只需要当一个普通用户
这是记忆层引入的新攻击面,和普通提示注入的区别在于:注入随会话结束消失,投毒跨会话持续生效,并对所有共享该记忆的用户生效。
- AgentPoison(NeurIPS 2024,arXiv:2407.12784):在投毒率 <0.1%** 的情况下攻击成功率 **>80%,无需任何模型再训练;而且不含 trigger 的正常指令性能几乎不受影响(benign 影响 <1%)。这意味着整体指标监控看不出来,用"库里坏数据比例很低"自我安慰是无效的。
- MINJA(arXiv:2503.03704):威胁模型里攻击者只是一个无法直接操纵 agent 任何部分的普通用户——不能改受害者的查询,也不能访问记忆库,只能发正常查询看输出,却达到约 98% 的注入成功率,并且明确绕过了基于检测的输入与输出审核。它靠三步把恶意推理骗进记忆:bridging steps(把受害查询连到恶意推理路径)、indication prompt(诱导 agent 自己生成同类桥接步骤)、progressive shortening(逐步撤掉诱导,让恶意记录仍可被检索)。
根因是写入路径没有信任边界:工具返回值、网页内容、他人上传的文档一旦被当作"经历"写进记忆,间接提示注入就拿到了持久化通道。检索又只看相似度不看来源可信度,没有任何机制问"这条是谁写的、依据是什么"。
按防御深度排序的处置:
- 区分"观察"与"断言"。工具输出、网页内容只能作为带来源标记的观察落到情景层,升格成语义/程序记忆必须经过一次独立判定。
- 写入期校验与净化:过滤、异常检测、来源允许/拒绝列表(OWASP 列为 Memory Poisoning 首要缓解项)。
- 会话/租户隔离:处理不可信内容的子 agent 用一次性记忆,主 agent 的持久记忆不对它开放写权限。
- 可溯源:每条记忆挂证据指针(哪次会话、哪个工具调用、哪个 commit),中毒后可批量回溯作废。
- 绝不把安全约束存在 agent 可写的记忆里。 CLAUDE.md 是上下文而非强制配置,没有严格遵从保证;必须硬性阻止的动作要用 PreToolUse hook。记忆层的规则永远只是建议。
记忆域最反直觉的一条经验事实是:最成功的工业实现最不像"记忆系统"。
Claude Code 的做法是目录 + markdown + 已有的文件读写工具,没有向量库、没有图。结构极简:每个项目一个记忆目录(按 git 仓库派生,同仓库的所有 worktree 共享),里面一个 MEMORY.md 当索引,加任意多个主题文件;每次会话开头只加载索引的前 200 行 / 25KB,主题文件不在启动时加载,由模型需要时用标准文件工具按需读取。
它的赌注是:对编码/运维类 agent,文件路径是比 embedding 更强的检索线索。 这个赌注有官方数字支撑——memory tool 与 context editing 合用相对基线提升 39%(单用 context editing 是 29%),100 轮网页搜索评测里 token 消耗降低 84%。Anthropic 工程博客把这套做法叫 structured note-taking,举的例子是 Claude 玩 Pokémon:agent 自己维护"过去 1,234 步我一直在 Route 1 练级,皮卡丘已升 8 级,目标 10 级"这样的记录,上下文重置后靠读自己的笔记续上数小时的行动序列。
甜区:条目数量在几十到几百、且有天然命名法的知识——项目约定、踩过的坑、构建命令、接口规范。
离开甜区就别用:
- 高基数非结构化个人事实(比如"用户提过的 3000 条偏好")用文件系统检索会退化成 grep,该走向量;
- 多 agent 并发写:文件没有事务,两个子 agent 同时改同一份笔记就是写冲突;
- 它不是配置:文件型记忆是投递进上下文的建议,不是强制约束。
再补一条裁剪标准,它本身就是"哪些内容会过期"的经验结论:删掉能从代码库推导出来的内容(目录结构、依赖清单、架构概览),保留 pitfall、rationale 和与工具默认值不同的约定。能被 ls 或 grep 一秒查出来的东西写进记忆,只是负债。程序记忆也不是越多越好——单个指令文件建议控制在 200 行以内,因为更长的文件消耗更多上下文并降低遵从度。
读到这里,决策链其实只有三问:
问一:全量上下文装得下吗? 装得下且 p95 延迟、单次成本都可接受 → 不建记忆层,你只会损失准确率。装不下,或者延迟/成本超标 → 进入问二。
问二:你的条目是几百级还是几千级以上? 几百级且有命名法 → 文件系统即记忆,索引常驻 + 主题文件按需读,不要引入中间件。几千级以上、或高基数个人事实 → 向量记忆起步。
问三:你有多少"什么时候变的"类查询? 少 → 到此为止,别上图。多,或者需要审计不可删的变更史 → 只给关系和有效期这部分建图,别整库上。
上线后要盯的七个数,前四个是准入,后三个是运行:
- full-context 对照分。跑一遍全塞进去的准确率,这是你的上限;记忆层的验收标准是"接近它",不是"超过它"。
- p95 总延迟与 p95 搜索延迟。分开量。参考量级:向量记忆搜索 p50 0.148s / p95 0.200s 是可达的;而 LangMem 的搜索 p50 高达 17.99s、p95 59.82s——如果把每次写入都做成同步 LLM 调用,延迟会直接失控。
- 每会话记忆 token 开销。参考:约 7,000(向量)/ 约 14,000(轻量图)/ 约 26,000(全量对话)/ 超过 600,000(重摘要图)。超出你预期一个数量级,几乎一定是表示冗余。
- 构建/写入延迟。"刚说过的事马上问能不能查到"。异步构建要数小时才可检索的方案,在客服和编码 agent 里是硬伤。
- 启动上下文占比。记忆文件在干活之前吃掉了窗口的百分之几。这个数只会涨,要设阈值报警。
- 分题型准确率,时序题单独拆出来。总分会掩盖一切:图记忆在 temporal 上 +2.6、在 multi-hop 上 −3.96,只看总分你会做出错误的选型。
- 陈旧率。定期抽样 N 条快照类记忆做真值校验,统计"写入时对、现在错"的比例。这是唯一能量化"记忆过期"的指标,没有它你永远不知道库烂到什么程度。
配套的两条工程动作:给硬上限(并让上限反馈给模型,超限报错而不是静默截断),给每条记忆挂时间戳和来源指针。这两件事成本极低,但没有它们,后面所有诊断都做不了。
- "全塞进去最准"依赖于它塞得下。 LOCOMO 的对话规模在 26k token 量级,现代窗口轻松容纳。如果你的场景是跨年的、几百万 token 的历史,full-context 根本不是一个选项,这条基线就退化成理论参考——此时对照组应该换成"最近 N 轮 + 摘要"。
- 记忆域没有公认的基准。 DMR 已接近饱和(全量对话基线 94.4%),LOCOMO 的 full-context 基线高于所有记忆系统,LongMemEval 上 Zep 的分题型收益从 +184% 横跨到 −17.7%。目前无法回答"记忆系统 A 是否普遍优于 B",本文所有排序只在这几个基准的口径内成立。
- 1–5 分的差距不要当成结论。 LLM-as-judge 打分有噪声,Mem0-g 对 Mem0 的 +1.56 分本身就在可疑区间;本文敢下判断的地方,都是倍数级差距(temporal 58.13 vs 21.71、token 7,000 vs 600,000、延迟 0.2s vs 59.82s)。
- 数字有保质期。 这些结果来自 2025 年的模型、价格和窗口大小。长上下文变便宜或变准,判据一号的分界线就会移动。结论会过期,方法不会——所以最重要的动作是自己重跑那个基线,而不是引用本文的数字。(这条本身就是"记方法不记快照"的应用。)
- 单 agent 假设。 多 agent 共享记忆目前没有一致性模型:共享 memory block 让多个 agent 写同一块,但没有事务、没有版本、没有冲突合并语义。本文关于写入闸的所有建议在并发写场景下都需要额外的协调层。
- 合规与审计场景要反过来。 本文推荐的"抽取式记忆 + DELETE"路线在需要非损耗留痕的地方直接违规;那里只能做"原始流 + 摘要索引",且必须用失效标记而非物理删除。
- 弱模型上自编辑记忆是负资产。 MemGPT 的 DMR 在 GPT-3.5 上只有 66.9%,在 GPT-4 上是 92.5%——基线只差 6.6 个点,加了同一套记忆循环后差距扩大到 25 个点以上。记忆架构的收益随模型能力放大,反过来说,让能力不足的模型自己决定改哪块记忆,等于给它一把会污染未来所有会话的枪。
- Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory — https://arxiv.org/abs/2504.19413 (完整结果表:https://arxiv.org/html/2504.19413v1)
- Zep: A Temporal Knowledge Graph Architecture for Agent Memory — https://arxiv.org/abs/2501.13956
- MemGPT: Towards LLMs as Operating Systems — https://arxiv.org/abs/2310.08560
- CoALA: Cognitive Architectures for Language Agents — https://arxiv.org/abs/2309.02427
- Generative Agents: Interactive Simulacra of Human Behavior — https://arxiv.org/abs/2304.03442
- MemoryBank: Enhancing Large Language Models with Long-Term Memory — https://arxiv.org/abs/2305.10250
- AgentPoison: Red-teaming LLM Agents via Poisoning Memory or Knowledge Bases (NeurIPS 2024) — https://arxiv.org/abs/2407.12784
- MINJA: Memory Injection Attacks on LLM Agents via Query-Only Interaction — https://arxiv.org/abs/2503.03704
- OWASP AI Agent Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
- Claude Code 官方文档《How Claude remembers your project》 — https://code.claude.com/docs/en/memory
- Letta Memory blocks 文档 — https://docs.letta.com/guides/agents/memory-blocks
- Anthropic《Effective context engineering for AI agents》 — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Anthropic《Managing context on the Claude Developer Platform》 — https://claude.com/blog/context-management