Agent Memory Without Contamination：多层级记忆架构设计指南

给 Agent 装上记忆，它会显得「活」了起来。但如果记忆没有 schema 约束，它就会变成那种把每条八卦都当真知的同事。污染是默认状态：未经验证的工具输出、过期偏好、半截推理，一旦被嵌入向量库，看起来全都一模一样。

开发者 Priya 的 Agent 曾自信地把六个月前的幻觉当作事实引用——记忆库里堆着已验证事实、过时偏好和上个季度的半成品分析，检索系统对它们一视同仁：没有标记、没有来源标签、没有时间戳优先级。这不是 bug，而是默认架构的必然结果。

记忆不是单一桶，而是分层存储

生产级记忆系统的核心认知是：不同类型的记忆必须进入不同层级。据 ayraix.com 的架构分析，最小可行的记忆架构至少包含三层：可验证事实、经人工批准的决定、会话临时草稿。三者拥有不同的 TTL、来源标记和写入权限。

把三者混在一起，你的 Agent 就会理直气壮地引用三月份的幻觉。作者给出的内部实践模式是：对未验证的 Agent 生成记忆设置 7 天默认 TTL 后自动过期，高风险场景可进一步缩短。这个数字背后有个值得警惕的行业观察：约 60% 的 Agent 幻觉事件可追溯到受污染的记忆存储，而非模型本身出错。

写入闸门比更大的上下文窗口更重要

把所有东西读进 prompt 不是记忆，而是「昂贵的失忆外加一堆多余步骤」。持久记忆真正需要的是写入闸门（write gates）：什么内容允许持久化、由谁批准、存储什么元数据（来源、时间戳、置信度、工具 ID）。正确的分工是——Agent 提议记忆，策略负责提交。

写入闸门像每个记忆层级入口的保安，未验证数据在污染长期存储之前，会被重定向到短 TTL 的临时区。

**TTL（Time to Live，存活时间）**是记忆系统中的核心控制参数：每条记录在写入时携带一个过期时间，到期后自动失效或被归档，无需人工干预。在 Agent 记忆场景中，TTL 本质上是「信任的时间边界」——它假设任何未被再次验证的信息，其可信度会随时间递减。实践中的 TTL 分层通常是：会话草稿为小时级（如 24 小时），未验证的 Agent 推理为天级（如文中的 7 天），已验证事实则可设为永久或季度级复审。TTL 的设计难点不在设置，而在于过期后的处理策略：是硬删除、软删除（墓碑化），还是降级到冷存储？不同选择直接影响合规审计与争议回溯能力。

**写入闸门（write gates）**借鉴自数据库领域的「写前校验」与安全领域的「策略即代码」思想。它的核心是区分「提议」与「提交」两个阶段：Agent 只能产生候选记忆（proposal），而是否落盘由独立于模型的策略层裁决。这意味着闸门需要至少三类输入：内容的来源类型（用户输入、工具返回、模型自生成）、内容的置信度信号（是否有外部验证、是否与已有事实冲突）、以及调用方的权限等级。闸门策略可以写成规则引擎或小型分类器，但必须可审计、可回滚。一个常见误区是把闸门实现为 prompt 里的「请只记住重要信息」——这不是闸门，只是祈祷，模型仍可能在下一轮绕过它。

四条实用工程模式

基于写入闸门的分层设计，ayraix.com 给出了四条可直接落地的模式：

• 存储隔离：用户偏好 ≠ 组织事实 ≠ 会话笔记，物理分离
• 读取时标注来源：记忆影响输出时，展示它来自哪里
• 压缩任务：总结旧线程，而不是无限重放原始链路
• 负向记忆：「我们试过 X，失败了」与成功经验同样宝贵，需显式打标签

读取路径同样需要卫生

大多数团队纠结于什么内容被写入记忆，却很少有人问：什么内容被读回来、以什么顺序读回。没有排序的检索，就是让六个月前的猜测压过昨天的已验证事实——嵌入分数相同，时效性错误，答案灾难。

记忆检索应当是策略驱动而非纯相似度驱动。作者给出的排序维度包括：对未验证层级施加指数衰减的时效权重；当两条记忆冲突时同时呈现而非混合；用户说「忘掉这个」必须真正删除或墓碑化；跨会话隔离，客服 Agent 之间不继承彼此的草稿。

「记忆检索应该由策略驱动，而不是只看相似度。提升已验证来源的权重，衰减未确认的 Agent 推理，硬性排除被标记为已废弃的记忆。你的 Agent 不应该引用某条线程里『我觉得是 49 美元』的定价数字——除非那条线程被标注为民间传闻。」

无法审计的记忆，就是无法信任的记忆。设计删除路径要像设计检索路径一样用心。

上线前的污染测试：Poisoning Suite

在部署前构建一个投毒测试套件：在会话一中向 Agent 投喂虚假事实，然后在会话二追问相关问题。如果虚假信息在没有来源标记的情况下持续存在，说明写入闸门失效。每次记忆 schema 变更后都应当重跑这套测试——它比一次面向客户的幻觉事故便宜得多。

你能做的还有：在日志中对记忆读取做埋点。当答案出错时，你需要看到是哪些记忆 ID 影响了检索，而不是一句「模型说的」。同时配合定期压缩任务——将反复出现的已验证事实晋升为长期记忆，把噪声线程转储归档。记忆就是数据库，请像 DBA 一样对待它。

读取排序策略示例

因素	已验证事实	Agent 推理
时效提升	中等	高衰减
相似度权重	高	设上限
人工覆盖	永远优先	永远优先

表中的「时效提升」与「相似度权重」需要联合调参，而非独立设定。一个可操作的实现是把最终检索分数写成加权和：score = w1 · similarity + w2 · recency + w3 · source_trust + w4 · human_override。其中 recency 对已验证事实采用线性或对数衰减，对 Agent 推理采用指数衰减，确保久远的未验证内容迅速沉底。source_trust 由记忆层级直接映射（已验证事实最高、人工决定次之、草稿最低）。当两条记忆的分数接近且结论冲突时，系统应返回并列结果并标注冲突，而不是让排序算法「替用户做决定」，因为混合两条相互矛盾的记忆往往会生成看似合理实则错误的答案。

合规视角：GDPR 与被遗忘权

记忆系统必须支持墓碑化与传播删除——当用户删除数据时，由其派生的嵌入向量和摘要也必须一并清除。「以后再重训练」不是合规。设计按计划运行并记录完成状态的删除任务。

法务团队会在安全团队问询注入攻击之前，先问记忆保留策略。对两个问题都要有答案。未验证层级的短 TTL 不只是质量问题，更是监管卫生问题。

压缩不能变成失忆

线程压缩能节省 token，但存在摘要漂移风险——每一次摘要都可能丢失细微差别。作者的建议是：原始日志存入冷存储以备争议解决，给 Agent 提供压缩视图。当法务问「3 月 3 日机器人知道什么」时，你需要的是原始归档，而不是摘要的摘要。

• 版本化摘要：标记压缩代次，质量下降时回滚
• 钉住关键事实：晋升内容在压缩中存活，闲聊则不留
• 晋升需人工审核：进入长期层级的事实要有人过目

把记忆当数据库，而不是日记本

从三层架构开始——已验证事实、已批准决定、临时草稿——在允许任何 Agent 写入之前，给每一层指定所有者、TTL 和删除路径。投毒测试套件不是可选的课后作业，而应该像生产表迁移测试一样，每次 schema 变更后必跑。

赢得信任的 Agent，不是记得最多的那些，而是能够按需告诉你究竟是哪个记忆 ID 导致了错误答案，并且一步删除它的那些。来源追踪与墓碑化就是全部的核心工作，其余不过是带额外置信度的嵌入而已。

行动建议：把当前记忆存储分成三个桶——你愿意在法庭上辩护的事实、有帮助但可能出错的笔记、以及周五之前就该蒸发的草稿。为每条记录添加 provenance 字段和 ttl_hours。写一个一小时的投毒测试。这就是全部架构，剩下的都是建立在卫生之上的优化——而卫生，是用户在一次错误答案中唯一真正感受到的东西。