Agent 的记忆也会被投毒：长期记忆安全的六阶段框架

过去，我们更习惯把大模型的风险理解为“这一轮输入有没有问题”“这一轮输出会不会越界”。但有了长期记忆之后，风险结构发生了变化。恶意内容不一定在当场触发，也不一定在同一轮任务里显现出来。它可以先悄悄进入记忆，在几天后、另一个会话里、另一个任务中被重新检索出来，再进一步影响规划、工具调用和执行路径。

这篇题为 《A Survey on the Security of Long-Term Memory in LLM Agents: Toward Mnemonic Sovereignty》 的综述论文，做的最重要一件事，就是把“长期记忆安全”从一个零散问题，整理成了一套完整的分析框架。

https://arxiv.org/pdf/2604.16548

作者提出： Agent 的长期记忆应该被当作一个可写、可检索、可传播、可回滚的系统状态来治理。 这也是全文的核心概念—— Mnemonic Sovereignty ，也就是“记忆主权”。

如果说提示注入关注的是“这一轮对话被不被带偏”，那么这篇论文讨论的是： 一个会记住历史、会积累经验、会跨任务行动的 Agent，究竟该如何守住自己的记忆边界。

“长期记忆”是新的攻击面

很多人会直觉地认为，长期记忆不过是“更长的上下文”或者“更聪明的 RAG”。但这篇论文明确指出， 长期记忆和长上下文不是一回事。

长上下文解决的是“当前这轮能放多少信息”，而长期记忆解决的是“系统在多轮、多任务、多会话之间，如何保存状态并让这些状态持续影响未来行为”。

这里最关键的差别有三个。

第一， 它是持久的 。 一条内容一旦被写入长期记忆，就不会随着当前对话结束而消失，它可能在未来反复被取回。

第二， 它是行为相关的 。 长期记忆不是静态档案。Agent 会利用记忆来决定怎么规划任务、调用什么工具、优先使用哪种策略、甚至信任哪些信息源。

第三， 它会传播 。 在多 Agent 场景、企业场景、共享知识库场景里，记忆不仅影响当前 Agent，还可能影响别的 Agent、别的用户、别的工作流。

这意味着，长期记忆一旦被污染，问题就不再只是“这次回答错了”，而可能变成：

未来多轮任务持续受影响； Agent 的经验总结被带偏； 高权限工具调用路径被劫持； 不同用户、不同 Agent 之间发生跨主体污染； 敏感信息通过记忆被长期保存并被间接提取。

从这个角度看，长期记忆更像是 Agent 的系统状态层 ，而不只是一个“补充上下文”的功能模块。

“六阶段记忆生命周期”框架

这篇论文最值得记住的，不是某一个具体攻击案例，而是它给出了一个非常清晰的分析框架： 把长期记忆安全拆成六个阶段来理解。

这六个阶段分别是：

1）Write：写入

系统在什么条件下、以什么方式、根据什么规则，把内容写入长期记忆。

这一步看似简单，实际上是整个记忆安全的起点。因为很多风险都不是攻击者直接写数据库，而是诱导 Agent “自己决定把有问题的内容记住” 。这类写入可能来自用户对话、网页内容、工具输出、文档内容，甚至来自其他 Agent 的消息。

论文的核心追问是： 系统是否把“写入长期记忆”视为一次需要验证的状态变更，还是默认外部内容都可信。

2）Store：存储与管理

内容写进去之后，并不是原封不动地躺在数据库里。它会被压缩、摘要、分类、合并、更新、打标签，甚至通过反思机制被提升为“经验”。

这一步很容易被低估，但论文认为恰恰是这里决定了很多问题会不会被放大。因为一条原始污染信息，可能在存储管理阶段被“压缩成更高置信度的经验”。

3）Retrieve：检索

未来任务到来时，系统会根据什么把某些记忆重新取回？

如果检索只看语义相似度，那么一些本来不该在当前场景触发的内容，也可能被错误召回。检索一旦失守，污染记忆就有机会重新进入上下文。

4）Execute：执行

记忆被取回后，如何参与 Agent 的计划制定、工具调用和任务执行。

这一步是从“信息污染”升级为“行为劫持”的关键。因为被取回的记忆，不只是影响回答内容，还可能影响真正的行动路径。

5）Share：共享

记忆会不会在不同 Agent、不同用户、不同系统之间共享和传播。

在多 Agent 架构和企业级平台里，这一步非常关键。共享一旦缺乏边界管理，某个 Agent 的污染记忆就可能变成系统级问题。

6）Forget / Rollback：遗忘与回滚

出了问题之后，系统能不能找到污染源、删除记忆、清除衍生摘要、撤销影响，并把状态恢复到安全版本。

这一步往往是最难的。因为现实中很多系统能“存”，也能“查”，但做不到真正意义上的“忘记”和“回滚”。

这套框架和传统提示注入的区别

这篇论文反复强调一点： 长期记忆攻击最大的危险，不在于它更复杂，而在于它把“注入”和“触发”分离开了。

传统提示注入一般发生在同一轮对话里：攻击内容进入上下文，模型当场被带偏，问题也当场暴露。

但长期记忆攻击的路径完全不同。它可能先在写入阶段埋下一颗“毒种”，然后安静地躺在记忆库里。几天以后，在另一个用户任务中，系统因为语义相似把它召回，它再去影响规划、执行和工具调用。

也就是说， 攻击窗口和攻击效果在时间上是错开的 。这会带来两个直接后果：

一是，单轮检测机制经常看不到完整攻击链。 二是，很多安全系统即使只检查“当前输入”和“当前输出”，依然会漏掉真正的问题。

论文里最有启发的一点，就是它把长期记忆攻击理解成一种 跨阶段、跨时间、跨会话的状态污染 。这个视角其实比“提示注入的一个变种”要更准确。

01 写入阶段：攻击者不需要很高权限，也能埋下持久毒素

论文在写入阶段总结了近几年攻击演化的一个明显趋势： 攻击门槛在下降，但影响范围和持续时间在上升。

这张图很有代表性，作者用时间轴展示了长期记忆写入攻击的演化方向：早期攻击往往需要较高权限，比如直接控制存储侧、污染知识源，或者对系统内部流程比较了解。

而随着 Agent 能力增强，越来越多攻击开始借助正常交互路径完成写入，例如：

诱导 Agent 自动记忆某条“用户偏好”； 借由网页内容、文档内容、工具输出把恶意信息带入记忆； 利用自动摘要、自动反思、自动经验提炼机制，把一次外部观察变成长期状态。

这意味着，攻击者不一定要“入侵”系统，甚至不一定要直接接触记忆接口。他只要让 Agent 看到某些内容，并让系统误判为“值得记住” ，就可能完成投毒。

这对工程实践的启发很直接：长期记忆写入绝不能只靠输入内容过滤。真正需要的是一层“写入门控机制”，把每一次写入都当成特权状态变更来处理，检查来源、权限、一致性和授权边界。

02 存储阶段：最容易被忽视，却最可能放大风险

如果说写入阶段决定“毒能不能进来”，那么存储阶段决定的是： 这颗毒会不会被放大、会不会被保留得更久、会不会变得更像一条可信经验。

这篇论文对存储阶段的分析很有价值，因为很多系统设计者天然会觉得：把历史内容做摘要、做压缩、做反思，本质上是在“提炼高价值信息”。但论文提醒我们，现实中未必如此。

长期记忆进入存储层之后，通常会经历几类处理：

从原始对话中抽取关键信息； 把多条历史压缩成摘要； 根据事件、人物、主题做组织； 把一次任务过程总结成“经验”； 在新旧记忆冲突时尝试做更新或融合。

问题在于，这些处理本身就可能引入新的风险。

一类是 压缩放大型毒素 。 原本只是一次对话里的一句恶意内容，在压缩后可能被提炼成一句看起来更像规则、更像结论的话。这样它反而更容易在未来被模型当作高权重信息。

另一类是 记忆幻觉 。 作者专门区分了两种失真：一种是外部来源造成的污染，也就是外部攻击者写入了恶意信息；另一种是系统自己在抽取、总结、组织、更新过程中“编出来”的错误，也就是模型在存储侧发生的幻觉。

这个区分很关键，因为很多时候，问题并不一定来自攻击，而可能来自系统自身的过度概括、错配归因、错误融合。换句话说，长期记忆的风险不只来自“别人投毒”，也来自“系统自己记错”。

这也是为什么论文认为，长期记忆治理不仅需要防御攻击，还需要有 来源标注、版本记录、血缘追踪、压缩可审计 这些机制。

03 检索与执行阶段：记忆一旦被取回，就会进入控制流

长期记忆安全和普通知识库安全最大的不同在于： 被召回的记忆并不只是用于“回答问题”，它还会影响 Agent 的行为控制。

这张图非常适合用来解释论文的核心判断，它描述的是一个典型链路：

Agent 在浏览网页时看到了一段恶意内容； 系统在总结和反思阶段把它提炼成一条长期记忆； 过了几天后，在另一个任务中，这条记忆因为语义相关被取回； 最终，这条记忆又悄悄影响了工具调用或任务执行。

这里最值得注意的是： 真正的危险，不发生在记忆写入的那一刻，而发生在未来记忆被取回并参与控制流的那一刻。

论文认为，检索和执行往往不是两个完全分开的失败点，而是一个连续链路：

检索阶段负责把污染内容重新放回上下文； 执行阶段负责把这段污染内容转化为行动。

从这个角度看，长期记忆不是普通数据平面，而是 控制平面的一部分 。它不仅影响模型“知道什么”，还影响模型“做什么”。

这也是为什么只在最终输出层做内容审核，通常是不够的，因为真正的问题可能早在“记忆召回—任务规划—工具调用”链路里就已经发生了。

04 共享阶段：多 Agent 时代，记忆会“传染”

随着越来越多 Agent 系统采用多角色分工、共享工作空间、共享知识库和组织级连接器，记忆的风险也不再局限于单个 Agent。

论文在 Share 阶段提出了一个非常现实的问题： 长期记忆一旦可以跨主体共享，污染就可能跨主体传播。

这里至少有两类风险。

一类是 跨 Agent 传播 。 一个 Agent 在自己的运行过程中形成了一条有问题的记忆，后来这条记忆通过共享记忆库、任务日志、协作黑板、工具消息等通道，被另一个 Agent 读到。结果是，本来只是局部问题，最后变成协作系统里的系统性问题。

另一类是 跨用户边界泄漏 。 在企业级 Agent 平台里，如果多个用户共用某类记忆服务、知识空间或协作上下文，那么记忆边界划分不清，就可能发生“甲用户的状态影响乙用户任务”的问题。更严重时，还会导致敏感信息跨主体外溢。

论文在这一部分虽然没有把篇幅放在大规模实证上，但提出的判断非常有启发： 在多 Agent 系统中，不能只盯着最终输出是否合规，还必须审计内部消息、共享状态和工具参数流。

很多真实泄漏并不是出现在最后回答里，而是出现在 Agent 之间的中间交换中。

05 遗忘与回滚：这是记忆治理里最难、也最关键的一环

如果说“写入”是记忆安全的入口，那么“遗忘”就是它的终极考验。

很多产品都喜欢说自己有记忆能力，但真正被问到安全时，最难回答的问题通常是这些：

这条记忆是谁写进去的？ 它来自哪一轮会话、哪一个网页、哪一份工具输出？ 后来它有没有被摘要过、压缩过、反思过？ 它有没有影响过别的记忆单元？ 删除时删的是原文，还是摘要，还是索引，还是全部副本？ 如果已经被别的 Agent 取走并使用过，该怎么回滚？

这篇论文的价值在于，它明确指出： Forget / Rollback 不是一个简单的删除动作，而是一套跨生命周期的治理能力。

如果写入时没有记录来源，存储时没有记录版本，压缩时没有保留血缘，检索时没有保留访问日志，那么到出事以后，系统就很难真正实现以下几件事：

定位污染源； 删除全部衍生影响； 回退到安全版本； 证明删除已经生效。

很多 Agent 平台今天在“记住”这件事上已经走得很快，但在“忘记”这件事上还远远不成熟。而从安全角度看， 是否能忘记、是否能回滚，才是真正检验一个记忆系统治理能力的关键指标。

“记忆主权”

除了六阶段框架，这篇论文另一个很有价值的部分，是提出了 Mnemonic Sovereignty（记忆主权） 这个概念，并进一步总结出一组“记忆主权原语”。

简单理解，所谓“记忆主权”，就是系统必须具备这样一些能力：

把记忆当成明确的对象来管理； 明确谁能写、谁能读、谁能共享； 为每条记忆附加来源、主体、时间、敏感度等元数据； 支持版本管理和历史追踪； 支持删除语义和回滚能力； 支持内部通道的审计和可观测性。

作者进一步比较了多种代表性记忆架构，观察它们对这些原语的覆盖情况。

这张图很有意思。它不是在比较“谁更强”，而是在比较“谁更完整地考虑了记忆治理”。

论文的结论很明确：一些架构在能力和效率上做得不错，但治理能力并不完整；一些更强调记忆管理和共享的架构，对治理原语覆盖更多，但也依然没有把所有问题解决掉。

尤其值得注意的是，论文指出两个普遍存在的薄弱点：

Write Gate：写入门控能力不足 Deletion Semantics：删除语义支持不足

这两个点其实正对应了长期记忆安全里最难的前后两端：前端是“能不能拦住不该进入的内容”，后端是“出了问题之后能不能真正删干净”。

启发

如果把全文的学术分析翻译成更工程化的话，我认为至少有四条非常重要的启示。

1. 长期记忆写入必须被当成“特权操作”

不能把“记忆写入”设计成一个完全自动、默认可信的后台动作，每一次写入，都应该有最基本的来源确认、权限约束、内容验证和冲突检测。

2. 检索不能只靠相似度

语义相似只能回答“像不像”，不能回答“该不该在当前任务中触发”；长期记忆检索应该叠加更多条件，例如主体边界、来源可信度、敏感等级、上下文授权范围。

3. 记忆系统要有“数据库式治理能力”

一个安全可用的长期记忆服务，不应该只有 add / search / delete 这种简化接口。它还应该支持：

memory object 抽象； 元数据管理； 版本与快照； 血缘追踪； 访问日志； 回滚； 删除验证。

4. 多 Agent 场景必须管理内部通道

很多团队今天只在最终输出层做风控，但长期看这肯定不够。Agent 之间的消息传递、共享记忆读写、工具调用参数、外部连接器访问过程，都应该进入可观测和可审计范围。

写在最后

长期记忆让 Agent 更像一个“持续存在的系统”，而不只是一个一次性的问答接口。 但只要系统会记忆，它就一定会面临三个问题： 记住什么、为什么记住、出了问题怎么忘记。

这篇论文最有价值的提醒是： 长期记忆不是能力增强的附属品，而是 Agent 安全架构中的新边界。

当 Agent 开始积累经验、跨任务行动、与其他 Agent 协作，记忆就不再只是“帮助模型更懂你”的能力，而是会直接决定系统状态、控制路径和安全边界的核心模块。

对于今天正在做 Agent 平台、记忆系统、企业智能体和多 Agent 协作框架的团队来说，这篇论文提出的问题其实已经不是“未来会不会遇到”，而是“什么时候会以工程事故的方式暴露出来”。

Agent 会成长，但也会记错；会学习，也会被污染。 下一阶段真正决定产品上限的，可能不是它“能记住多少”，而是它 能否守住自己的记忆边界。