Agent丨Agent 长期记忆的 FIFO 淘汰策略有哪些问题，如何优化？

type

Post

status

Published

date

May 27, 2026

slug

agent52

summary

一、先区分两个概念：上下文淘汰 ≠ 长期记忆淘汰

很多 Agent 项目一开始会这样做：

最近 N 条对话放进 prompt，超过 N 就删最早的。
长期记忆也按写入时间排序，超过容量就删最早的。

这在 demo 阶段可行，但到生产级 Agent 会出问题。原因是：

上下文窗口是热缓存，长期记忆是持久知识库。热缓存可以 FIFO，知识库不能简单 FIFO。

成熟系统基本都在做这个区分。

Letta 文档明确把 stateful agent 的状态、记忆、用户消息、推理、工具调用都持久化到数据库，即使从上下文窗口中被 compact 或 eviction，也不会丢失；重要 core memories 才会被注入 LLM 上下文，且 Agent 可通过工具修改自己的 memory blocks。(Letta Docs)

Claude Code 的 auto memory 也不是无限把所有内容塞进 prompt，而是用 MEMORY.md 做索引，并把详细内容拆到 topic files；启动时只加载 MEMORY.md 前 200 行或 25KB，topic files 按需读取。(Claude Code)

OpenClaw 的 Memory 文档也强调，MEMORY.md 是 compact curated layer，用于 durable facts、preferences、standing decisions；daily notes 用于运行中的详细上下文，之后再蒸馏到 MEMORY.md，如果超过 bootstrap budget，会保留磁盘文件但截断注入模型的副本。(OpenClaw)

所以正确心智模型应该是：

FIFO 可以管理“当前 prompt 能放多少”，但不能决定“什么历史事实应该永久消失”。

二、FIFO 用在长期记忆上的核心问题

1. 时间早晚不等于价值高低

FIFO 的假设是：越早写入的记忆越不重要。但长期记忆里经常存在“很旧但很关键”的信息。

例如：

用户三个月前说：“这个项目永远用 pnpm，不要用 npm。”
最近十轮都在聊具体 bug。
FIFO 满了后把三个月前的规则删了。

结果 Agent 下次改代码时又执行 npm install，破坏项目约定。

这类信息在 coding agent 中非常常见。OpenCode 官方规则系统会把项目级 AGENTS.md 或兼容的 CLAUDE.md 作为项目指令加载，适合保存 build/test 命令、架构约定、项目规范等未来 session 仍然需要的信息。(OpenCode)

2. FIFO 无法处理“事实更新”和“事实失效”

长期记忆不是静态事实库，而是动态状态库。

例如：

1 月：用户喜欢 React。
3 月：用户说这个新项目不用 React，改用 Svelte。
5 月：用户问“这个项目 UI 怎么写？”

FIFO 可能出现两种错误：

错误类型	表现
只保留旧事实	仍然推荐 React
只保留新事实	丢失“用户过去偏好 React”的历史解释
新旧事实都保留	检索时冲突，模型随机采用
直接删除旧事实	无法回答“我之前为什么选 React？”

更合理的做法是给记忆加上：

valid_from、valid_until、supersedes、confidence、source_ids、status

Zep/Graphiti 的方向就是把 memory 做成 temporal context graph，让事实随交互演化；Zep 官方说明其 graph 层会在事实变化时 invalidates old facts，并把相关上下文组装给 Agent。(getzep.com)

3. FIFO 会破坏多跳记忆关系

长期记忆经常不是孤立文本，而是关系图：

用户 A 负责支付模块。
支付模块依赖 Redis。
Redis 本地测试需要 Docker。
本次 bug 与支付回调有关。

如果 FIFO 删除了“支付模块依赖 Redis”这条旧记忆，后面即使保留了“用户 A 负责支付模块”和“Redis 需要 Docker”，Agent 也可能无法完成多跳推理。

Mem0 的论文专门提出 graph-based memory variant，用于捕捉 conversational elements 之间的复杂关系，并报告在 temporal、multi-hop、open-domain 等类别上提升效果；其核心不是简单保存全量历史，而是动态抽取、合并、检索紧凑记忆表示。(arXiv)

Zep 的论文也把企业 Agent 的长期记忆问题描述为动态知识整合问题，而不是静态文档 RAG 问题；它通过 temporally-aware knowledge graph engine 动态综合会话数据和业务数据，并维护历史关系。(arXiv)

4. FIFO 会让“旧但需要精确召回”的事实消失

长期会话评测已经证明，Agent 记忆不仅是“最近上下文”问题。LoCoMo benchmark 的对话包含多 session、长跨度上下文，用于评估问答、事件总结、多模态对话生成等长期记忆能力；其论文摘要提到每段对话平均约 300 turns、9K tokens、最多 35 sessions。(arXiv)

这意味着很多问题会问：

“我之前说过的那家餐厅叫什么？”
“上个月我们为什么不选方案 B？”
“我最早提到这个需求时的约束是什么？”

这些信息可能很早，但仍然是答案关键。FIFO 会天然惩罚这类旧证据。

5. FIFO 不能解决 long context 的注意力问题

有人会说：不删，全部塞进长上下文不就行了？

也不行。Lost in the Middle 研究发现，即使模型支持长上下文，对输入中间位置的信息利用也不稳定，相关信息位于开头或结尾时表现更好，位于中间时性能显著下降。(arXiv)

所以长期记忆优化不是“多塞一点历史”，而是：

先找到 relevant memories，再压缩成短、准、可验证的 active context。

6. FIFO 容易把“安全边界”和“授权边界”删掉

Agent 的长期记忆里有些信息不是普通事实，而是 action-sensitive memory：

“只有我明确批准后才能删除生产数据。”
“这个客户资料不能发给外部邮箱。”
“这次临时授权只到周五。”

OpenClaw 文档专门强调 action-sensitive memories 要记录安全行动边界、过期条件、owner authority、应避免的行为等，同时也提醒 memory 不能替代 approval settings、sandboxing 等硬控制。(OpenClaw)

这类信息不能按时间简单删除，也不能永久无条件保留，必须有 policy、expiry、authority、audit。

三、成熟系统的共同设计趋势

1. MemGPT / Letta：FIFO 只管主上下文，长期状态落库

MemGPT 的设计接近操作系统虚拟内存：主上下文由 system instructions、working context、FIFO queue 组成；FIFO queue 负责滚动消息，但消息会写入 recall storage，重要信息可由模型通过函数移动到 working context 或 archival storage。(arXiv)

Letta 延续了这个方向：所有状态持久化，memory blocks 可以 attach/detach 到 agent，上下文被 compact 后旧消息仍可通过 API 或 retrieval tools 找回。(Letta Docs)

核心启发：

FIFO eviction 只应该发生在“active context”，不应该直接删除“persistent memory”。

2. Claude Code：索引文件 + topic 文件，而不是一个大 FIFO 文件

Claude Code auto memory 采用 MEMORY.md 作为入口索引，详细 notes 分散到 topic files；启动时只加载索引的前 200 行或 25KB，topic files 由 Claude 按需读取。(Claude Code)

这是一种非常实用的 coding agent 设计：

MEMORY.md 只保存目录、关键规则、稳定约定。
详细调试经验、API 决策、历史原因进入 topic 文件。
prompt 启动成本稳定，细节按需召回。

3. OpenClaw：长期记忆、daily notes、dreaming/compaction 分层

OpenClaw 把 MEMORY.md 定位为长期、紧凑、精选层，把 memory/YYYY-MM-DD.md 定位为 daily notes 工作层；随着时间推移，Agent 应该把有用内容从 daily notes 蒸馏到 MEMORY.md，并移除 stale long-term entries。(OpenClaw)

这说明成熟 Agent 不会把所有历史平铺到一个队列，而是有：

原始观察 → 日志层 → 压缩层 → 长期精选层

4. OpenCode：规则文件是指令层，插件开始补 memory blocks

OpenCode 官方支持 AGENTS.md 和 custom instruction files，它更像 project rules/context injection，不是完整长期记忆系统。(OpenCode)

社区的 opencode-agent-memory 插件则借鉴 Letta memory blocks，加入 scoped blocks、metadata、size limits、dedicated memory tools、journal semantic search，使 Agent 可以跨 session 维护自编辑记忆。(GitHub)

这说明对于 coding agent 来说，常见演进路径是：

Rules file → structured memory blocks → memory tools → semantic journal → background consolidation

5. LangGraph / LangMem：按记忆类型和 namespace 管理

LangGraph 文档把长期记忆定义为跨 conversation/session 的存储，通常按 namespace 组织；并把 memory 类型分成 semantic、episodic、procedural，同时区分 hot path 更新和 background 更新。(LangChain 文档)

LangChain 的 long-term memory 文档进一步说明，长期记忆基于 LangGraph stores，以 namespace 和 key 保存 JSON document，可跨会话读写。(LangChain 文档)

这对 FIFO 的替代方案很关键：

不同类型的记忆应该有不同生命周期、不同召回策略、不同淘汰策略。

四、推荐的生产级长期记忆架构

1. 分层记忆结构

核心原则：

原始日志尽量 append-only。
长期事实要 update/merge/supersede。
注入 prompt 的 active memory 必须小而准。
删除前先考虑降级、压缩、归档、失效标记。

五、用“打分淘汰”替代 FIFO

长期记忆的保留优先级可以按以下因素计算：

维度	含义
relevance	与当前任务/用户长期目标的相关度
importance	记忆本身重要性
recency	时间新鲜度，但只是一个因子
frequency	被使用、被检索、被确认的次数
confidence	来源可信度、抽取置信度
authority	是用户明确说的，还是模型推断的
validity	是否过期、是否被 supersede
risk	隐私、安全、合规风险
token_cost	注入上下文所需 token
diversity	与已选记忆是否重复

可以抽象成：

这不是唯一公式，但比 FIFO 多了几个关键能力：

旧但重要的记忆可以保留。
新但低价值的噪声可以淘汰。
已失效的事实可以降权。
高风险记忆可以不进入 prompt。
低 token、高价值记忆优先进入 active context。

AWS 关于 Mem0 的工程文章也提到，Mem0 管理 memory lifecycle 时包括 automatic filtering 防止 memory bloat、decay mechanisms 移除不相关信息、以及通过 prompt injection 和 semantic caching 做成本优化。(Amazon Web Services, Inc.)

六、长期记忆 schema 设计

推荐不要把 memory 存成纯文本列表，而是结构化记录。

注意这里有几个 FIFO 没有的字段：

字段	作用
`valid_until`	处理事实失效
`supersedes`	处理事实更新
`source_ids`	支持溯源和审计
`authority`	区分用户明确指令、工具结果、模型推断
`privacy_risk`	控制敏感记忆注入
`pinned`	保护关键长期规则
`status`	删除之前先归档或失效

七、写入路径：不要 append-only 到长期层，要 extract + merge + validate

核心逻辑：

这个写入路径解决了 FIFO 的三个问题：

重复事实不会无限膨胀。
冲突事实不会随机共存。
历史事实不会被物理删除，而是进入 superseded / archived 状态。

八、读取路径：检索、重排、预算打包

长期记忆不是全部注入 prompt，而是按任务检索。

预算打包不能只取 TopK，因为 TopK 可能高度重复。更好的策略是：

这比 FIFO 更适合 Agent，因为 Agent 需要的是：

当前任务相关、覆盖面足够、token 成本可控、冲突已处理的记忆集合。

九、后台 consolidation：删除前先压缩、归档、分层

长期记忆优化的关键不是“满了删”，而是“满了整理”。

后台任务可以每天或每个 session 结束时运行：

MemoryOS 的设计也体现了分层思想：它将 Agent memory 分为 short-term、mid-term、long-term personal memory，并用动态更新、检索、生成模块管理；短期到中期可以采用 dialogue-chain-based FIFO，但中期到长期采用 segmented page organization，而不是把 FIFO 直接用于长期层。(arXiv)

十、淘汰策略对比

策略	适合场景	问题	推荐程度
FIFO	短期上下文滚动窗口	会删掉旧但重要的信息	只用于短期
LRU	工具缓存、检索缓存	很久没用但重要的事实会被删	可作为因子
LFU	高频偏好、常用规则	冷门但关键的信息会被删	可作为因子
TTL	临时授权、临时任务	稳定偏好不适合 TTL	强烈推荐
Importance Score	用户偏好、项目规则	需要评估器	推荐
Semantic Merge	去重、事实压缩	抽取错误会污染记忆	推荐
Temporal Supersession	偏好变化、状态变化	schema 更复杂	强烈推荐
Graph Retention	多实体、多跳关系	工程成本高	中大型 Agent 推荐
Human Review	高风险记忆	成本高	安全场景推荐

最终建议是组合策略：

短期层：FIFO + summary
中期层：TTL + session consolidation
长期层：importance + semantic merge + temporal validity
高风险层：human review + policy enforcement
检索层：hybrid search + rerank + token budget packing

十一、面向 coding agent 的落地方案

参考 Claude Code、OpenClaw、OpenCode 的做法，coding agent 的长期记忆可以分成四类。

层级	文件/存储	内容	注入策略	淘汰策略
Project Rules	`AGENTS.md` / `CLAUDE.md`	构建命令、代码规范、架构约定	启动加载	人工审查，不 FIFO
Memory Index	`MEMORY.md`	长期记忆索引、关键偏好	启动加载小预算	保持短小，移动细节到 topic
Topic Memory	`memory/debugging.md` 等	调试经验、API 决策、模块约定	按需读取	score + consolidation
Session Notes	`memory/YYYY-MM-DD.md`	当天任务、工具结果、临时观察	最近一两天加载	TTL + 蒸馏
Raw Archive	DB / object storage	原始对话、工具调用、日志	不直接注入	合规保留、冷归档

OpenClaw 文档里的 MEMORY.md、daily notes、budget truncation 机制，以及 Claude Code 的 MEMORY.md index + topic files，都很适合借鉴到自建 coding agent 中。(Claude Code)

示例 memory 文件可以这样写：

对于临时限制：

这类记忆不能 FIFO 删除，也不能永久保留。应该到期后进入 expired，并在必要时提醒用户确认。

十二、RAG/Agent 长期记忆的检索优化

长期记忆本质上是 Agent 内部 RAG，但和普通文档 RAG 有区别：

普通 RAG	Agent Memory RAG
文档相对静态	记忆持续变化
chunk 主要来自文件	chunk 来自对话、工具、行为、环境
重点是语义相关	还要处理时间、冲突、权限、用户偏好
答案引用文档	Agent 行为会被记忆影响
更新频率较低	每轮都可能更新

因此检索时建议使用 hybrid retrieval：

重排时必须加入时间逻辑：

这可以避免：

旧事实被错误当成当前事实。
当前事实覆盖历史事实后无法追溯。
临时授权过期后仍被使用。

十三、什么时候可以用 FIFO？

FIFO 不是完全不能用，而是要限制使用范围。

适合 FIFO 的地方：

当前对话 short-term message buffer。
工具输出临时缓存。
streaming 过程中的 partial chunks。
最近 session 的 transient notes。
memory pressure 下的 prompt queue。

不适合 FIFO 的地方：

用户长期偏好。
项目长期规范。
安全授权边界。
历史决策原因。
多跳实体关系。
可审计事实。
跨 session 的经验沉淀。

MemGPT 的设计就是一个好例子：它有 FIFO queue，但同时有 working context、recall storage、archival storage 和 memory pressure warning；这说明 FIFO 是上下文队列管理，而不是长期记忆治理的全部。(arXiv)

十四、评估长期记忆淘汰策略

不要只看“记忆库大小下降了多少”，要看 Agent 质量。

1. 构造测试集

测试类型	示例
旧但重要	三个月前的项目规则是否仍被遵守
新旧冲突	用户从 React 改成 Svelte 后是否采用新事实
历史追问	用户问“当时为什么这么决定”是否能找回旧证据
多跳关系	能否从人、模块、依赖、错误现象推理
临时授权	授权过期后是否停止行动
隐私记忆	敏感内容是否避免注入普通 prompt
长上下文干扰	注入大量无关记忆后是否仍稳定

LoCoMo、LongMemEval 这类 benchmark 的意义就在于把长期、多 session、事件总结、问答、一致性等能力拆开评测，而不是只测最近几轮聊天。(arXiv)

2. 核心指标

指标	含义
Memory Recall@K	该召回的记忆是否召回
Memory Precision@K	召回的记忆是否有用
Current Fact Accuracy	当前事实是否采用最新有效版本
Historical Fact Accuracy	历史事实是否可追溯
Conflict Rate	prompt 中冲突记忆比例
Token Cost	每轮注入 memory token
Latency	检索、重排、组装耗时
Staleness Error	使用过期记忆导致的错误
Safety Violation	过期授权、越权记忆导致的风险
Provenance Coverage	记忆是否能追溯来源

十五、推荐实现路线

阶段 1：从 FIFO buffer 升级为“持久化 + 摘要”

最低成本改造：

原始对话和工具调用全部落库。
prompt 里仍用最近 N 轮。
session 结束生成 summary。
重要事实写入 structured memory。
不再物理删除旧长期记忆。

阶段 2：加入类型化 memory

把长期记忆拆成：

semantic：用户偏好、项目事实、实体属性。
episodic：过去成功/失败案例。
procedural：Agent 行为规则、工作流习惯。
action-sensitive：权限、边界、临时限制。

LangGraph/LangMem 正是按 semantic、episodic、procedural 来组织长期记忆建模。(LangChain 文档)

阶段 3：加入 update / supersede，而不是 append

实现 entity-slot 级别更新：

阶段 4：加入检索重排和 token budget

不要全量注入 memory。每轮只注入：

pinned rules
current task relevant facts
top episodic examples
action-sensitive constraints
necessary provenance summary

阶段 5：加入后台 consolidation

定期执行：

去重
合并
降噪
topic 聚类
session summary
旧记忆归档
失效事实标记
人工审核高风险记忆

十六、最终方案总结

Agent 长期记忆的 FIFO 淘汰策略最大的问题是：它把时间顺序误当成价值顺序，把上下文窗口管理误当成长期知识治理。

生产级优化应该遵循这几个原则：

第一，短期上下文可以 FIFO，长期记忆不能简单 FIFO。
第二，删除前先考虑压缩、归档、失效标记和降级存储。
第三，长期记忆必须结构化，至少包含类型、来源、重要性、时间有效性、置信度和状态。
第四，事实更新要用 supersede/validity，而不是追加一条新文本。
第五，检索时要同时考虑语义相关、时间有效、权限边界、token 成本和多样性。
第六，coding agent 应采用 规则文件 + memory index + topic files + session notes + raw archive 的分层设计。
第七，评估时要测旧事实召回、新事实覆盖、冲突处理、历史追问、安全边界和成本延迟。

一句话概括：

FIFO 是缓存策略，不是记忆策略。Agent 长期记忆的核心不是“删最早的”，而是“保留有价值的、更新已变化的、压缩可归纳的、隔离有风险的、按需召回最相关的”。