Agent 把错误信息写进记忆后怎么办？
记忆污染不是"清缓存重启"能收场的 bug，而是一次系统级的故障状态恢复。
- 本质区别：缓存异常是死数据、抛错即停；记忆污染是 agent 带着错误记忆继续自主决策，且 自己不知道错了。
- 攻击面：间接 prompt injection 把恶意指令藏进网页 / 文档，被 agent 写进长期记忆后静默持续执行。
- 事前 三 道防线：索引与内容分离、容量约束 + 快照漂移防护、写入前准入扫描。
- 事后三步走：全链路溯源 → 原子化回滚与补偿 → 认知重塑。
- 两条红线：不设计无限记忆空间、不剥夺用户对记忆的回滚控制权。
为什么"清空缓存"是面试官挖的坑？
因为记忆污染和缓存异常根本不是一类问题。
传统缓存或状态异常是"死数据"：程序走到某处抛出 error，链路直接中断。这种情况清空缓存、重启会话确实能解决——数据错了 ，但系统停在那儿，不会继续造成伤害。
记忆污染完全相反。agent 拿到错误甚至恶意的记忆之后，会带着这些错误信息继续自主做决策，而且它自己根本意识不到出了问题。这是认知层面的受损，不是数据层面的脏读。系统没停、没报错，反而在"正常"地干错事。
最典型的攻击是间接 prompt injection：攻击者把恶意指令藏在网页或文档里，当 agent 去读取这些内容时，指令会被不知不觉写进长期记忆。之后每一次任务，agent 都会静默、持续地执行这些被植入的动作。
到这一步，记忆已经不只是数据了——它变成了 agent 的动态配置，直接控制着行为逻辑。把它当缓存清理，等于没理解问题。
事前：三道架构防线
防重于治。绝大多数污染源应该在写入长期记忆之前就被拦下。
1. 索引与内容分离
不要让 agent 直接"生啃"原始的、可能带毒的文本。存储时只给它安全的摘要或元数据索引，真正的敏感内容放在受限的隔离环境里。这样即便某条内容被污染，扩散范围也被死死圈在一个小区域内。
2. 容量约束 + 漂移防护
给 agent 无限记忆空间，它迟早会被垃圾信息和恶意指令淹没。所以要给记忆容量设上限，倒逼它在写入新记忆前先过一遍价值扫描。
同时系统要定期给记忆做快照。一旦发现 agent 行为发生漂移，就有一个回滚窗口，能把它恢复到干净的快照配置。
3. 写入前准入控制
最直接的手段：数据正式写进长期记忆前，先过一道安全扫描过滤器，识别有没有异常行为模式。对关键、高价值的写入操作，甚至可以加上人工审批环节，把准入门槛直接拉高。
事后：错误已经用出去了怎么办？
这才是拉开差距的地方——要拿出全链路治理的思维，三步走。
第一步：全链路溯源
错误已经发生，不能乱撞。立刻调系统的 trace log，顺藤摸瓜精准定位到底是哪一个 memory id 出了问题。
找到毒源后，顺着决策链往下评估：它派生出了哪些后续决策，把受影响范围圈死。同时切断相关模块之间的互信关联，防 止污染在多 agent 系统里像病毒一样横向传染。
第二步：原子化回滚与补偿
对 agent 执行过的动作区分对待：
- 可逆操作（改了数据库、提交了某段代码）：直接触发物理回滚，把数据恢复到事故发生前。
- 不可逆操作（已经给客户发出错误邮件、已经创建扣费账单）：无法回滚，必须启动补偿任务——让系统自动生成并执行一个补救动作，比如发一封更正函、自动申请退款，把实体损失降到最低。
第三步：认知重塑
物理层面补救完，还得净化 agent 的"大脑"。拉起一个完全独立的审计 agent 来会诊，强行清空当前会话上下文，并从最近的一个健康快照里恢复它的思维状态。这样外部行为和内部记忆两条线都干净了。
一个必须记住的核心洞察
在现代 agent 系统里，长期记忆早已不是一个简单的数据库，而是非结构化的动态配置层。
既然是配置层，那就意味着：只要改了记忆，就能改变 agent 的行为逻辑。这个认识决定了两件事。
一是安全警觉要跟上——对待任何外部写入的数据源，都得像防 SQL 注入一样警惕。
二是有两条红线不能踩：
- 别设计无限记忆空间：没有克制的存储不仅带来高昂的 token 成本，更容易导致长尾指令混淆，给攻击者留下可乘之机。
- 别剥夺用户的最终控制权：无论 agent 设计得多自动化，用户必须始终握有对记忆系统的修改权和回滚权。这是系统的安全兜底。
一句话收尾：防重于治是基础，溯源回滚是核心。处理记忆污染，不能把它当成单点的数据清理 bug，而要上升为一次系统级的故障状态恢复。
References
- 面试官问：Agent 把错误信息写进记忆后要怎么办？ —— AI大模型原理, Bilibili