Agent 为什么需要“忘记”：长期记忆的 TTL、评分、合并与清理策略

很多 Agent 系统在做长期记忆时，最先考虑的是：

怎么让 Agent 记住更多？

例如：

• 记住用户偏好；
• 记住过去任务；
• 记住工具使用经验；
• 记住项目上下文；
• 记住历史对话中的重要事实。

但一个 Agent 如果运行几周、几个月，真正困难的问题往往会变成：

它什么时候应该忘掉这些东西？

长期记忆并不是简单地“存进去，以后检索”。

记忆越积越多之后，系统可能同时存在：

过期的信息
重复的信息
互相冲突的信息
已经失效的操作经验
当前任务根本不需要的历史上下文

如果这些内容继续参与检索，Agent 可能得到一个看起来非常相关、实际已经错误的上下文。

AWS 在 2026 年 9 月发布的 AgentCore Memory 生命周期实践中，把这个问题明确拆成了三个动作：

TTL Expiration
→ Relevance Scoring
→ Consolidation / Pruning

也就是：

先淘汰明显过期的
再判断哪些价值正在下降
最后尝试合并，再决定是否删除

AWS 将这种过程定义为持续的 Memory Lifecycle Management，而不是一次性的向量库清理。

与此同时，2026 年 9 月提交的 MeClear 论文还提出了另一个更细的问题：

一条记忆即使在语义上和当前问题很相似，也可能对最终任务产生负面作用。

所以长期记忆系统最终要解决的，不只是“存什么”，还包括：

什么时候过期？
哪些应该降权？
哪些应该合并？
哪些应该永久删除？
哪些只应该在当前查询中暂时屏蔽？

这篇文章就从这五个问题展开。

---

1. 为什么“向量相似度高”不等于“这条记忆应该被使用”

普通 RAG 的检索逻辑通常是：

用户 Query
    ↓
Embedding
    ↓
Vector Search
    ↓
Top-K Memory
    ↓
塞进模型上下文

这里默认了一个很强的假设：

越相似
≈
越有用

对静态知识库，这个假设很多时候还能工作。

但长期 Agent Memory 更复杂。

假设用户半年前说：

我们项目固定使用 Python 3.10。

后来项目已经升级：

Python 3.13。

这两条 Memory 对：

“项目现在应该用哪个 Python 版本？”

都具有很高语义相关性。

如果 Retriever 只按余弦相似度返回结果，很可能同时取回：

Python 3.10
Python 3.13

此时问题已经不再是 Retrieval Accuracy，而是：

Memory Validity

也就是：

这条历史信息现在还有效吗？

MeClear 的论文把问题描述得更直接：传统检索强调 semantic compatibility，但相似的历史 Memory 可能已经过期、误导或互相冲突，从而降低 Agent 的下游任务效果。

因此：

Memory Retrieval

和：

Memory Lifecycle

实际上是两个不同的工程层。

---

2. 先给 Agent Memory 分类

在设计“遗忘机制”之前，首先不能把所有 Memory 当成一种数据。

AWS 的实践将 Agent Memory 分成三类。

2.1 Episodic Memory：发生过什么

Episodic Memory 可以理解为“事件记忆”。

例如：

昨天用户部署服务时遇到了 502。

上一次对话中用户正在处理支付模块。

它通常具有这些特点：

数量多
带时间
与具体 Session 强相关
价值衰减快

这种 Memory 最适合优先过期。

---

2.2 Semantic Memory：稳定事实和偏好

例如：

用户默认使用 TypeScript。

项目主仓库部署在 GitHub。

用户更偏好 ap-southeast-1。

这些内容已经脱离某一次具体对话。

因此通常应该比 Episodic Memory 保留更久。

---

2.3 Procedural Memory：怎么做事情

例如：

发布之前先执行测试，再执行安全扫描。

或者：

遇到成本问题时，先调用 Cost Explorer，再总结。

这类 Memory 更像：

Workflow
Tool-use Pattern
Operational Knowledge

它数量通常较少，但价值可能更高。

因此不能简单使用：

超过 90 天 → 删除

这种统一规则。

---

3. 第一层：TTL，给记忆设置一个硬上限

最简单的遗忘机制是 TTL：

Time To Live

规则可以简单到：

if memory.age_days > ttl_days:
    delete(memory)

例如：

对话摘要：60 天
工单历史：90 天
用户长期偏好：365 天

AWS 示例默认对部分 Episodic Memory 使用 90 天作为起始 TTL，并建议生产环境根据不同 Memory 类型使用不同保留周期。它同时强调：TTL 不判断 Memory 是否仍然有用，它只负责提供一个积累上限。

所以 TTL 最大的优点是：

简单
确定
成本低
容易审计

但它也有明显缺陷。

假设：

Memory A
已经存在 120 天
但昨天刚刚被使用

而：

Memory B
只存在 20 天
但从来没被使用

只按 TTL：

A 删除
B 保留

未必合理。

因此 TTL 应该被看成：

第一层粗过滤

而不是完整的 Memory Quality 策略。

---

4. 第二层：不能只看年龄，还要给 Memory 打分

为了处理：

老但有价值

和：

新但没价值

这种差异，可以为 Memory 计算 Relevance Score。

AWS 示例使用了三个主要信号：

创建时间
最近访问时间
访问频率

其示例公式可以概括为：

Score
=
创建时间衰减
+
最近访问时间衰减
+
访问频率

AWS 示例采用指数衰减，并给出默认权重：

Creation Recency     0.40
Last Access Recency  0.35
Access Frequency     0.25

当权重和为 1 时，最终 Score 位于 0～1 之间。

一个简化版实现可以写成：

import math


def memory_score(
    days_since_creation,
    days_since_last_access,
    access_count,
    decay_rate=0.03,
):
    recency = 0.40 * math.exp(
        -decay_rate * days_since_creation
    )

    access = 0.35 * math.exp(
        -decay_rate * days_since_last_access
    )

    frequency = 0.25 * min(
        access_count / 50,
        1.0,
    )

    return recency + access + frequency

这只是一个示例评分函数，不代表所有 Agent 都应该使用相同参数。

---

5. 为什么最近访问时间很重要

假设有两条 Memory。

Memory A：

180 天前创建
昨天被访问
访问过 300 次

Memory B：

20 天前创建
创建以后从未使用

如果只看：

created_at

B 明显更新。

但如果结合使用情况：

A 可能仍然是核心知识
B 可能只是一次无意义对话残留

这就是：

Memory Age
≠
Memory Utility

AWS 的实现甚至专门利用 CloudTrail 的 Memory Retrieval 事件去计算：

last access
access count

因为 AgentCore Memory 的 MemoryRecordSummary 本身并没有直接提供 lastAccessedAt。

这里反映出一个很重要的工程思路：

Memory 系统不能只记录“存了什么”，还应该记录“这些记忆后来到底有没有被使用”。

---

6. 访问频率也可能骗人

不过：

访问次数高

也不能直接等于：

Memory 很重要

假设有一条错误 Memory：

生产数据库地址是 db-old.internal。

Retriever 因为这条文本和很多运维问题很相似，经常把它召回。

于是：

access_count = 500

但实际上它只是：

被错误地召回了 500 次

这时如果评分规则是：

越常访问 → 越重要

就会形成正反馈：

错误 Memory
→ 经常被检索
→ Score 变高
→ 更难被删除
→ 继续被检索

所以 Frequency 更适合作为：

弱信号

而不是单独决定保留与否。

这也是为什么真正成熟的生命周期策略还需要：

冲突检测
版本判断
来源可信度
任务效果

这些更高级的信息。

---

7. 第三层：低分 Memory 不要立刻删，先尝试 Consolidation

假设 Agent 有这些 Memory：

用户喜欢 Python。
用户多数后端项目使用 Python。
用户最近的服务也是 Python。
用户写脚本通常使用 Python。
用户默认希望提供 Python 示例。

这五条信息高度重复。

直接删除其中四条当然可以。

但更好的做法是：

Consolidation

把它们合并成：

用户偏好 Python，默认优先提供 Python 示例。

AWS 的方案就是：

低分 Memory
    ↓
批量送给 LLM
    ↓
提取关键事实
    ↓
生成新的 Semantic Memory
    ↓
写回 Memory Store
    ↓
删除原始冗余记录

并且要求 Consolidator 尽量：

保留关键事实
删除重复
删除过期内容
返回 confidence

如果 Bedrock Consolidation 调用失败，原始 Memory 会继续保留，而不是先删后合并。

这个顺序非常重要：

Create new
    ↓
确认成功
    ↓
Delete old

而不是：

Delete old
    ↓
尝试总结

否则一次模型失败就可能直接造成记忆丢失。

---

8. Consolidation 本质上是有损压缩

Memory Consolidation 很像：

日志
→ 摘要

或者：

多条事实
→ 一个 Canonical Fact

它减少：

Token
索引数量
重复召回
冲突概率

但问题在于：

摘要一定有信息损失

例如原始 Memory：

用户一般使用 PostgreSQL，
但 analytics 项目仍然使用 ClickHouse。

如果模型压缩成：

用户使用 PostgreSQL。

就把一个重要例外删掉了。

所以：

Consolidation
≠
无损 Dedup

AWS 官方方案也明确指出 Consolidation 是 lossy 的，因此使用 confidence，并建议低质量合并进入人工检查。

---

9. 第四层：什么时候才应该真正 Prune

可以把永久删除的候选条件设计成：

过期
AND
低价值
AND
未被近期使用
AND
没有更高层依赖

一个简单规则可能是：

if memory.age_days > ttl:
    delete(memory)

elif memory.score < threshold:
    consolidate_or_review(memory)

更完整一点：

Memory
 ↓
TTL 已过？
 ├── Yes → 删除
 │
 └── No
      ↓
计算 relevance score
      ↓
低于 threshold？
 ├── No → 保留
 │
 └── Yes
      ↓
能与其他 Memory 合并？
 ├── Yes → Consolidate
 │
 └── No
      ↓
Archive / Prune / Manual Review

这里我建议把：

Archive

和：

Delete

也区分开。

对于生产系统，可以先进入低成本冷存储或审计层，再从 Agent 的 Active Memory 中移除。

这样：

Agent 看不到

并不等于：

数据物理消失

当然，如果涉及法规要求的真正删除，Archive 就不能替代 Delete。

---

10. 第五层：冲突 Memory 怎么处理

TTL 和 Score 都解决不了一个非常典型的问题：

两条 Memory 都很新
两条都经常使用
但它们互相冲突

例如：

M1:
用户偏好 dark mode。

M2:
用户现在改用 light mode。

正确处理方式通常不是：

保留两个，让 LLM 自己猜

而应该让 Memory 有：

版本
有效时间
来源
superseded_by

例如：

{
  "memory": "用户偏好 dark mode",
  "valid_from": "2026-01-01",
  "valid_to": "2026-08-20",
  "status": "superseded"
}

新的 Memory：

{
  "memory": "用户偏好 light mode",
  "valid_from": "2026-08-20",
  "status": "active"
}

这样 Retriever 可以默认只检索：

status = active

这类设计其实已经开始接近：

Temporal Knowledge

而不只是普通 Vector Store。

---

11. MeClear 提出了另一个视角：不要急着永久删除

到这里讨论的主要是：

Persistent Memory Lifecycle

也就是后台长期清理。

MeClear 论文研究的是另一个相关但不同的问题：

当前 Query 到底应该屏蔽哪些 Memory？

论文认为，一条 Memory 的问题可能不是：

它永远错误

而是：

它对当前任务产生负面效用

例如：

Memory A：
用户平时喜欢简洁回答。

当前任务：
请写完整 API Migration Guide。

Memory A 本身没有过期。

但如果它强烈影响 Agent，让 Agent 把迁移步骤省略掉，那么对这个 Query 而言，它可能是：

negative utility memory

MeClear 使用 Leave-One-Out 筛选和采样的 Cooperative Shapley Attribution 去判断哪些 Memory 对当前任务造成负贡献，然后进行 query-scoped minimal clearance。关键是：它不会因此永久修改底层 Memory Bank。

所以：

Pruning

和：

Query-time Suppression

必须区分。

---

12. 为什么简单 Leave-One-Out 也可能失效

最直观的方法是：

带全部 Memory 执行一次

然后：

每次去掉一条 Memory
重新执行
看看结果有没有变好

这就是一种 Leave-One-Out 思路。

但假设存在两条重复错误信息：

M1：生产环境使用 Java 17
M2：项目当前 JDK 是 Java 17

实际项目已经升级到：

Java 21

去掉 M1：

M2 还在
→ Agent 仍然回答 Java 17

去掉 M2：

M1 还在
→ Agent 仍然回答 Java 17

于是单条 Leave-One-Out 可能认为：

M1 没问题
M2 也没问题

但实际上：

{M1, M2}

这个组合才是污染源。

MeClear 引入 cooperative Shapley attribution 的目标，就是考虑多条 Memory 之间的联合贡献，而不只是单条删除效果。论文将这种现象称为 redundant conflict masking。

---

13. MeClear 的意义更像“执行时防污染”

MeClear 的论文实验报告中，在其评测设置下：

target recall = 85.9%
task recovery rate = 82.3%

并称其任务恢复率相比 Leave-One-Out baseline 提高了 25.5 个百分点。需要强调，这是论文在十个 long-dialogue memory pools 上报告的结果，并不能直接外推为所有 Agent 项目的生产效果。

真正更值得关注的是它的架构思想：

Persistent Memory
        ↓
Retrieve Candidates
        ↓
Task-conditioned Attribution
        ↓
发现可能有害 Memory
        ↓
Query-scoped Suppression
        ↓
执行当前任务

它没有直接：

delete from memory

而是：

这一次先不要让模型看到它

这对于不确定性较高的 Agent 系统更安全。

---

14. 生命周期清理与 Query-time Clearance 应该怎么组合

实际工程中，可以把两种策略放在不同位置。

后台治理

例如每天凌晨：

Memory Store
    ↓
TTL
    ↓
Relevance Score
    ↓
Conflict Detection
    ↓
Consolidation
    ↓
Archive / Delete

解决的是：

长期积累
存储膨胀
重复
明显过期
合规

在线执行

每次 Query：

Query
    ↓
Retriever
    ↓
Candidate Memory
    ↓
Validity Check
    ↓
Conflict / Risk Filter
    ↓
最终 Context

解决的是：

当前任务是否应该使用这些 Memory

两者不能互相替代。

最终可以得到：

长期 Memory Governance
+
实时 Context Governance

---

15. 一个可落地的 Memory Lifecycle Pipeline

如果不绑定任何具体云厂商，一个中等规模 Agent 可以从下面的结构开始：

                ┌──────────────────┐
                │   Memory Store   │
                └────────┬─────────┘
                         │
                  Nightly Lifecycle
                         │
              ┌──────────▼─────────┐
              │    TTL Filter      │
              └──────────┬─────────┘
                         │
              ┌──────────▼─────────┐
              │ Relevance Scoring  │
              └──────────┬─────────┘
                         │
                 Low-score Memory
                         │
              ┌──────────▼─────────┐
              │ Conflict Detection │
              └──────────┬─────────┘
                         │
              ┌──────────▼─────────┐
              │  Consolidation     │
              └──────────┬─────────┘
                         │
               ┌─────────┴─────────┐
               │                   │
             Keep              Archive/Delete

请求到来时另外执行：

Query
 ↓
Retrieve
 ↓
Filter Superseded
 ↓
Risk / Utility Check
 ↓
Context
 ↓
Agent

这比“全部 Memory 直接 Top-K”多了几个步骤，但长期运行后的稳定性会明显更可控。

---

16. 后台清理建议用定时 Workflow，而不是请求时现算

AWS 官方实现采用：

EventBridge
    ↓
Step Functions
    ↓
TTL Expiration
    ↓
Scoring
    ↓
Consolidation
    ↓
Metrics
    ↓
Audit Output

并设置成每天凌晨执行。

这种设计比：

用户发一次消息
→ 顺手扫描全部 Memory

更合理。

因为 Scoring 和 Consolidation 都可能产生：

额外数据库扫描
额外 LLM 调用
额外延迟

生命周期维护更像：

GC
数据库 Vacuum
日志归档
索引维护

应该放到后台任务。

---

17. 删除 Memory 之前一定要做回归测试

这是 Memory Cleanup 最容易被忽略的一点。

清理成功不代表系统变好了。

例如：

原来 10 万条 Memory
↓
删成 2 万条

Storage Cost 降了。

但 Agent 可能也忘掉了：

用户长期偏好
关键历史项目
必要 Workflow
重要异常处理经验

AWS 的方案专门设计了 before/after Regression Test：

清理前
→ 用固定问题测试
→ 记录质量

执行 Memory Lifecycle

清理后
→ 用相同问题测试
→ 再次评分

比较 Delta

只有清理后的回答仍超过最低质量阈值，才认为生命周期策略没有清理过头。

因此：

Memory Pruning 也应该像代码重构一样做 Regression Test。

---

18. 建议记录哪些 Memory 元数据

如果准备自己设计长期 Memory，不建议只保存：

{
  "content": "..."
}

可以至少考虑：

{
  "id": "mem_123",
  "type": "semantic",
  "content": "用户偏好 Python",
  "created_at": "...",
  "updated_at": "...",
  "last_accessed_at": "...",
  "access_count": 42,
  "source": "conversation",
  "confidence": 0.92,
  "status": "active",
  "supersedes": "mem_089"
}

有条件还可以增加：

tenant_id
user_id
importance
valid_from
valid_to
source_trace_id
consolidated_from

这些字段以后会直接影响：

TTL
Scoring
Conflict Resolution
Audit
Deletion

没有 Metadata 的 Memory Store，很难真正做好生命周期治理。

---

19. 一套比较稳妥的处理优先级

生产环境不要直接：

低分
→ DELETE

可以采用更保守的顺序：

1. 标记过期
2. 停止默认检索
3. 观察是否仍有访问
4. 尝试 Consolidate
5. Archive
6. Regression Test
7. 最终 Delete

其中合规删除请求是例外。

如果用户明确要求删除个人数据，就不能继续因为：

“这条 Memory 可能还有价值”

而保留。

AWS 的示例同样单独设计了 GDPR Deletion Handler，并记录成功删除数以及失败记录 ID，便于后续审计和补偿处理。

---

20. TTL 应该设置多少？

没有统一答案。

AWS 的示例给过一些起始建议，例如不同 Agent 可以采用不同 pruneDays：实时 Support Bot 更短，通用助手更长，Legal / Compliance 场景可能需要保留更久。

但不要直接把这些数字复制到生产。

真正决定参数的应该是：

业务信息变化速度
用户回访周期
法规
Memory 类型
检索频率
历史回归测试

可以先从较保守的参数开始：

只清理明显过期 Memory

然后观察：

Memory 数量
召回质量
Agent Answer Quality
低分 Memory 命中率

再逐渐收紧。

---

21. 最容易踩的五个坑

坑 1：所有 Memory 使用同一个 TTL

Episodic、Semantic、Procedural 的生命周期明显不同。

应该：

按类型配置策略

---

坑 2：把 Vector Similarity 当作 Memory Quality

Similarity 只说明：

像不像当前 Query

不说明：

是不是最新
是不是正确
是不是有害

---

坑 3：低分直接永久删除

更稳妥的方式是：

Consolidate / Archive / Review

之后再决定删除。

---

坑 4：Consolidation 后不验证

LLM Summary 可能丢细节。

必须有：

before/after regression

---

坑 5：把“当前 Query 不该使用”误认为“永久无价值”

这正是 MeClear 和生命周期 Pruning 的核心区别。

有些 Memory：

不适合当前任务

但可能：

对下一个任务仍然有价值

所以需要：

query-time suppression

而不是永久删除。

---

22. 总结

Agent 的长期记忆不应该是：

Memory Store
=
只进不出的 Vector Database

更合理的理解是：

Memory Store
=
一个持续演化的知识系统

它至少需要五种能力：

TTL
→ 控制硬性生命周期

Scoring
→ 判断价值是否下降

Consolidation
→ 把重复历史压缩成稳定知识

Pruning
→ 清理确定已经失效的内容

Query-time Clearance
→ 当前任务临时屏蔽有害 Memory

AWS AgentCore 的方案提供了一套很典型的工程化实现：

TTL
→ Relevance Score
→ Consolidation
→ Pruning
→ Regression Test
→ Audit

而 MeClear 则进一步提出：

相似度高
≠
对当前任务有帮助

因此在执行阶段，还可以针对具体 Query 判断 Memory 的下游效用，并临时排除可能产生负贡献的上下文。

如果要用一句话概括 Agent Memory 的工程原则：

优秀的长期记忆系统，不只要知道应该记住什么，还必须知道什么时候不再相信、什么时候合并，以及什么时候暂时不要把某段记忆交给模型。

这才是长期运行 Agent 真正需要的“遗忘机制”。

---

关键参考资料

1. AWS：Designing lifecycle policies for AgentCore memory，2026-09-04。AWS 原文
2. Boyu Yang 等：MeClear: Cooperative Game-Theoretic Attribution and Risk-Aware Memory Clearance for Long-Horizon LLM Agents，arXiv:2609.09115，2026-09-08。MeClear 论文
3. 本文选题最初来自用户提供的 AI 技术文章素材库。