【论文阅读】Agent记忆机制（112）：MemFit——保留对话原文，用多路检索降低长期记忆成本

---

前言

长期 Agent Memory 通常面临一个两难问题。

如果系统在每轮对话到来时，都让 LLM 判断“该记什么、该更新什么、该删除什么”，就能得到结构清晰、便于检索的事实库，但写入成本很高。一段持续数月的对话，可能触发成百上千次抽取、比较、合并和重写。

如果系统选择更便宜的做法，把原始对话直接放进向量库，写入虽然快，却会把检索压力推到查询时：相似但无关的片段容易污染上下文，跨会话事实难以组合，短句还经常脱离相邻 turn 后失去含义。

过去的 Agent Memory 工作，大多把重心放在写入与整理阶段：

• Mem0 对候选事实执行 Add、Update、Delete、No-op；
• A-MEM 把新记忆写成笔记并动态建立关联；
• MemoryOS 维护短期、中期和长期层级；
• LightMem 在离线阶段压缩和整理记忆；
• SimpleMem 把交互压缩成更紧凑的独立单元。

MemFit 选择了一条相反的路线：写入阶段尽量不判断、不合并、不删除，把不可逆决策推迟到问题出现之后。

每个对话 turn 原样写入 append-only episode store；系统仅在会话片段级别调用一次 LLM 生成两句摘要，而且摘要不是替代原始对话的压缩记忆，而是指向原始 episode 的索引。查询到来后，BM25、dense retrieval、summary provenance、pseudo-relevance feedback 和 cross-encoder 共同完成精确召回，最后才调用一次 LLM 回答。

本文的唯一核心增量：把长期记忆从“写入时由 LLM 决定保留什么”改成“原始 episode 无损追加、摘要只做可回溯索引，并在查询时用无 LLM 的多路径检索完成选择”，从而把高成本且不可逆的在线 consolidation 推迟为问题已知后的证据选择。

文本—图像融合、混合检索、候选扩展和 cross-encoder 并不是彼此独立的贡献，它们共同承担一个任务：补偿“写入时不整理”给查询阶段带来的更高检索难度。

零、论文基本信息

• 论文名称：MemFit: Efficient Long-Term Agentic Memory
• 发表平台：arXiv 预印本 / ICLR 2027 投稿版本
• 代码仓库：mitchellpiehl/MemFit
• 作者：Mitchell Piehl、Muchao Ye

一、背景：为什么 Agent Memory 的写入越来越贵

1. LLM 驱动的写入链路

典型事实型记忆系统收到新消息后，会执行：

1. 抽取值得长期保存的事实；
2. 搜索相关旧记忆；
3. 判断新事实与旧事实是重复、补充、更新还是冲突；
4. 创建、重写或删除记忆；
5. 更新摘要、图关系或用户画像。

这套流程很像数据库事务，但其中多个步骤由 LLM 完成。随着历史增长，单次写入不仅要处理新内容，还可能重新检查、重写已有内容。

问题不只是 token 成本。在线 Agent 每收到一句话都要等待 LLM 决策，写入延迟会直接影响实时交互；而且一旦 consolidation 删除了原始细节，后续问题出现时就无法恢复。

2. 压缩记忆的不可逆风险

假设用户先说：

我养的是金毛犬。

几个月后又说：

兽医确认它其实是金毛和拉布拉多的混种。

如果系统在写入时把旧事实覆盖为新事实，回答“你最初以为什么品种”时就可能丢失证据；如果摘要只保留“用户养了一只狗”，细粒度品种同样消失。

MemFit 的基本判断是：写入时并不知道未来会问什么。因此，没有必要提前决定哪一条信息“更重要”或哪条旧事实“可以删除”。

3. 不 consolidation 并不意味着什么都不做

直接保留所有 turn 会带来新的问题：

• 短回复缺少上下文；
• 同一主题跨多个 session；
• 专名、日期适合关键词检索，释义和改写适合语义检索；
• 多跳问题的第二条证据可能与原问题并不相似；
• 多模态记忆还要连接图片与上下文。

MemFit 因而把系统复杂度从写入侧移到 retrieval stack，而不是简单退化成 Naive RAG。

Figure 1：MemFit 与现有记忆系统设计的比较。 现有系统通常用 LLM 在写入阶段抽取、压缩、更新或组织记忆；MemFit 保留逐 turn 的原始 episode，只在片段级生成摘要索引，并把主要计算放在无 LLM 的检索阶段。

二、相关工作：MemFit 反对的不是摘要，而是“摘要替代证据”

1. LLM 管理型记忆

MemGPT、MemoryOS 把记忆做成层级存储，让 LLM 决定内容在不同层级之间如何移动。Mem0、A-MEM 则让 LLM 维护事实或关联笔记。

这些系统的共同优势是记忆库更紧凑、更有组织；共同代价是写入阶段持续消耗 LLM 调用，而且任何误删、误合并都可能成为永久损失。

2. 压缩与离线整理

LightMem 把复杂维护放到 sleep-time，SimpleMem 强调 semantic lossless compression。它们已经在降低在线成本，但最终存储单元仍经过压缩或重写。

MemFit 的差异不是“完全不用摘要”。它仍然为每个 conversation segment 生成两句摘要，只是把摘要定位为导航结构：摘要记录 provenance，可以把检索器带回组成它的原始 turns。

3. 层次摘要检索

RAPTOR、MemTree、H-MEM、HiMem 都使用高层摘要帮助跨粒度检索。但许多系统会把压缩后的 segment 当成最终 memory unit。

MemFit 的原则是：

Summary finds; raw episode answers.

摘要用于发现一段相关对话，原始 episode 才是提供回答证据的单元。

4. 迭代检索

Self-RAG、FLARE、IRCoT、MemWalker 等方法让 LLM 多轮反思或生成中间查询，适合多跳问题，但增加串行延迟。

MemFit 使用 pseudo-relevance feedback 扩展查询，并用 cross-encoder 最终排序，全程不需要 LLM 参与搜索。只有最终 answer extraction 调用一次 LLM。

三、方法总览：把 Memory System 分成廉价写入与精细检索

下面这张图是理解 MemFit 的核心。左半部分解释系统如何“尽可能无损地存”，右半部分解释它如何“在问题已知后精确选”。

Figure 2：MemFit 方法总览。 写入阶段把文本或带图片 caption 的 turn 原样追加为 episode，同时建立 BM25 与 dense index；TextTiling 切分会话并用每段一次 LLM 调用建立可回溯摘要。检索阶段经过混合候选生成、摘要 provenance 与伪相关反馈扩展、cross-encoder 重排及邻域补全，最后只调用一次 LLM 生成答案。

MemFit 由两层存储和四阶段检索构成：

• Episode Store：逐 turn、append-only、原文保留；
• Summary Layer：描述对话片段并保存成员 episode ID；
• Stage 1：BM25 + dense hybrid candidate generation；
• Stage 2：summary provenance + pseudo-relevance feedback；
• Stage 3：cross-encoder rerank + context neighbor assembly；
• Stage 4：单次 LLM answer extraction。

四、问题形式化

对话历史表示为：

$$\mathcal{H}=\{(u_i,t_i,p_i,v_i){\}}_{i=1}^N$$

其中：

• $u_i$：第 $i$ 个 utterance；
• $t_i$：时间戳；
• $p_i$：说话人；
• $v_i$：可选图片。

Memory System 要把历史增量组织为持久结构 $\mathcal{M}$。查询 $q$ 到来时，从历史中选择少量相关 episode ${\mathcal{H}}_k$，再由 reader $f$ 回答：

$$a=f(q,{\mathcal{H}}_k)$$

这个定义把核心问题拆得很清楚：MemFit 不试图训练一个新的 reader，而是优化 ${\mathcal{H}}_k$ 的构建方式，同时降低 $\mathcal{M}$ 的写入成本。

五、模块一：Append-only Episode Store

1. 每个 turn 就是一条 episode

每个 utterance 被格式化为：

$$e_i=({\mathbf{x}}_i,{\mathbf{z}}_i,g_i,{\mathbf{m}}_i)$$

• ${\mathbf{x}}_i$：带时间、speaker 和正文的格式化文本；
• ${\mathbf{z}}_i=f_{enc}({\mathbf{x}}_i)\in {\mathbb{R}}^d$：冻结 sentence encoder 产生并做 $L_2$ 归一化的向量；
• $g_i$：全局顺序号；
• ${\mathbf{m}}_i$：session、turn、speaker、timestamp 等元数据。

例如：

[Time: 2023-05-12] [Speaker: Lena] I adopted a golden retriever yesterday.

论文选择 turn 级粒度有两个理由：

1. 三个 benchmark 的 gold evidence 主要标注在 turn 层；
2. 回答需要的内容通常恰好落在一两个 turn 中，避免系统自行切块把证据从中间截断。

2. 两个互补索引

Lexical Index

BM25 对 ${\mathbf{x}}_i$ 建倒排索引，适合精确匹配：

• 人名、地名；
• 日期、数字；
• 低频名词；
• 必须原样出现的实体。

Dense Index

所有 episode embedding 组成矩阵：

$$\mathbf{Z}\in {\mathbb{R}}^{N\times d}$$

查询向量 ${\mathbf{z}}_q$ 与全库的余弦相似度可写成一次矩阵—向量乘法：

$$\mathbf{Z}{\mathbf{z}}_q$$

它适合没有词面重叠的释义与改写。

插入 episode 只需要：生成一次 embedding、向 $\mathbf{Z}$ 增加一行、向 BM25 倒排表追加 postings。已有 episode 不会被重写、重新编码或重新摘要。

3. Append-only 的收益

• 写入时无需 LLM 判断；
• 原始证据不会因错误摘要而丢失；
• 旧事实和修正事实都带时间保留；
• 未来问题可以重新解释历史，而不受早期 consolidation 决策约束。

但它的代价同样明确：存储会单调增长，错误与敏感内容也会长期存在，检索器必须承担版本选择和冲突解释。

六、模块二：Summary 是索引，不是替代品

1. 为什么原始 turn 仍需要高层导航

一个问题可能对应一整段会话，而不是某一句与 query 高度相似的文本。高层 summary 能提供主题入口，但如果只保存 summary，姓名、日期和细节容易消失。

MemFit 因此让 summary 保存 member episode IDs。命中 summary 后，系统可以沿 provenance 拉回构成它的原始 turns。

2. TextTiling 如何切 segment

系统不用 LLM 判断主题边界，而是在每个 gap 上比较左右两侧 episode embedding 的均值相似度。

窗口大小为：

$$b=\max \left(3,\mathrm{round}\left(\frac{\sqrt{n}}{2}\right)\right)$$

对每个 gap 计算 coherence score，并寻找局部低谷。若低谷相对左右峰值的深度超过：

$${\mu }_d+\frac{{\sigma }_d}{2}$$

就放置 segment boundary。${\mu }_d$、${\sigma }_d$ 分别是全部 gap depth 的均值和标准差。

这个规则的直觉是：主题切换处，前后窗口的平均语义相似度会显著下降。

3. 每段只调用一次 LLM

至少包含 3 个 episode 的 segment 会被总结。LLM 最多看到 14 条均匀采样的 excerpt，输出两句话且不超过 200 tokens。

摘要与以下信息一起保存：

• summary text；
• summary embedding；
• member episode IDs；
• 时间和 segment 范围。

因此，摘要可以与 episode 一样参与检索，但不能替代 episode。

4. 不做 consolidation，如何处理事实更新

当事实变化时，原说法与修正说法都保留。系统不在 write time 判断哪个应该存活，而依赖查询时的三个机制：

1. 相同主题共享词汇，旧值和新值通常会同时进入候选池；
2. episode 带日期并按时间顺序呈现；
3. reader 在问题已知时判断应该使用当前值还是历史值。

这个设计把“哪条事实有效”从静态存储问题改成 query-conditioned evidence interpretation。

七、模块三：Hybrid Candidate Generation

1. 双路径召回

查询向量为：

$${\mathbf{z}}_q=f_{enc}(q)$$

对 episode $i$，两种分数为：

$$\mathrm{lex}(q,{\mathbf{x}}_i)=BM25(q,{\mathbf{x}}_i)$$

$$\mathrm{sem}({\mathbf{z}}_q,{\mathbf{z}}_i)={\mathbf{z}}_i^{\top }{\mathbf{z}}_q$$

默认从 lexical 和 semantic 路径各取 Top-60，组成最多 120 条候选的并集。

2. 为什么必须归一化

BM25 没有固定上界，而 cosine similarity 有范围约束。直接加权会让其中一个尺度主导。

MemFit 先在候选并集内分别做 min-max normalization，再进行凸组合：

$$s_i=\alpha \widehat{\mathrm{sem}}({\mathbf{z}}_q,{\mathbf{z}}_i)+(1-\alpha )\widehat{\mathrm{lex}}(q,{\mathbf{x}}_i)$$

默认 $\alpha =0.7$，即 dense signal 权重更高，但保留 0.3 lexical signal 捕捉精确实体。

3. 元数据 Boost

如果 query 明确提到并匹配 episode 元数据，追加固定 boost：

• speaker：+0.10；
• month：+0.08；
• year：+0.05。

这些 boost 在归一化后加入，因此可理解为当前观测分数范围的固定比例，而不是跨不同量纲随意加数。

八、模块四：严格加法的候选扩展

论文认为，检索最常见的失败不是 gold evidence 已在候选池里但排序较低，而是它根本没有进入候选池。因此 Stage 2 专门扩大 recall。

1. Summary Provenance Expansion

Summary 与 episode 使用相同 hybrid score 搜索。Top summary 被命中后，其成员 episodes 通过 provenance 被加入候选池。

它解决的是“问题与整段主题相关，但和单句词面不相似”的情况。

2. Pseudo-Relevance Feedback

系统从 Stage 1 排名前两位 episode 中提取 IDF 最高的 12 个稀有词，使用这些词重新执行 candidate generation。

这针对 multi-hop：原问题先找到证据 A，A 中的专名或稀有概念再成为寻找证据 B 的桥梁。它类似一次自动 query expansion，但不需要 LLM 生成搜索词。

3. 为什么强调 Additive

两种扩展只向池中追加候选，绝不移除 Stage 1 找到的结果。因此扩展理论上不会因为替换候选而损失第一阶段的证据；真正的筛选留给 cross-encoder。

九、模块五：Cross-Encoder Reranking 与 Context Window

1. 第一阶段只决定“有没有资格”，不决定最终顺序

Cross-encoder 对 Stage 1 前 50 条候选和所有 expansion candidate 使用原始 query 重新打分。

Bi-encoder 把 query 与 document 分开编码，适合快速扫描；cross-encoder 联合阅读 query-document pair，更慢但能判断细粒度相关性。

2. Episode 与 Summary 分布不同

两句 summary 通常更完整、更主题化，原始 turn 可能很短。直接比较 cross-encoder 原始分数会偏向某一类文本。

MemFit 分别在 episodes 和 summaries 内做 score standardization，再统一排序。Summary 只有在“相对其他 summaries 足够好”时，才能与“相对其他 episodes 足够好”的候选竞争 pack slot。

3. Neighbor Context

最终选择 $k=10$ 条候选。每个被选中的 episode 还会带上同 session 内前后 $w=1$ 个 turn。

这解决了一个常见问题：

User：你周末去了哪里？
Assistant：去了杭州。

如果只检索“去了杭州”，speaker 和问题上下文并不完整。相邻 turn 恢复了局部语义。

十、模块六：单次 Answer Extraction 与多模态融合

1. 最终证据包

所有 excerpt 按时间排序，附带 session date；系统还用规则把相对时间预解析为绝对日期。Reader 在一次调用中读取 $q$ 与 ${\mathcal{H}}_k$：

$$a=f(q,{\mathcal{H}}_k)$$

Candidate generation、expansion、reranking 均不调用 LLM。

2. Text–Image Fusion

带图片的 turn 会把 image ID 与 caption 写入 ${\mathbf{x}}_i$：

[Image D1:IMG_001: a golden retriever on a beach ...]

这样，图片内容可以通过同一 BM25 与 dense index 检索，不需要另建跨模态向量库。

查询时有三种选择：

• 只使用 caption；
• 将 query image 交给 MLLM；
• 同时提供 query image 与被检索 episode 的 images。

论文发现，提供 query image 有明显帮助，但进一步提供 retrieved images 并没有总体提升，这一反例后面会详细分析。

十一、实验设置

1. 数据集

数据集	问题数	主要能力	评测指标
LoCoMo	1540 个非对抗问题	Single-Hop、Multi-Hop、Temporal、Open Domain	F1、BLEU-1、LLM Judge
MemGallery	1711	文本/图片检索、多模态推理、知识管理	Token F1、LLM Judge
LongMemEval-S	500	约 50 session、11.5 万 token、更新与时间推理	官方 LLM Judge Accuracy

Table 4：三个评测数据集。 LoCoMo 检查多会话文本记忆，MemGallery 检查文本—图像长期记忆，LongMemEval-S 检查超长历史中的更新和时序能力。

2. Backbone

• GPT-4o；
• GPT-4.1-mini；
• GPT-4o-mini；
• Qwen3-8B；
• Gemma3-27B；
• MemGallery 的 Qwen2.5-VL-7B。

3. 默认检索配置

• Episode/Summary encoder：all-MiniLM-L6-v2，384 维；
• Reranker：ms-marco-MiniLM-L-6-v2；
• Lexical Top-60 + Semantic Top-60；
• $\alpha =0.7$；
• Cross-encoder 首先处理前 50 条与全部扩展候选；
• Top-10 summaries 与 episodes 交错参与候选；
• Summary provenance 扩展 Top-5；
• PRF 使用 Top-2 episode 的 12 个稀有词；
• 最终 pack $k=10$，neighbor window $w=1$；
• Segment 至少 3 个 episode，最多采样 14 条，摘要不超过 200 tokens。

论文强调所有 backbone 与 benchmark 使用同一套配置，没有为每个 corpus 单独调参。

十二、LoCoMo 主实验

原始 Table 1 很宽，下面提取各 backbone 的平均 F1/BLEU 与主要对手。

Backbone	方法	Avg F1	Avg BLEU-1	Multi-Hop F1	Temporal F1	Open F1	Single-Hop F1
GPT-4.1-mini	SimpleMem	43.24	37.62	43.46	58.62	19.76	51.12
GPT-4.1-mini	MemFit	50.26	44.74	41.58	66.05	28.85	64.56
GPT-4o	SimpleMem	39.06	27.25	35.89	56.71	18.23	45.41
GPT-4o	MemFit	49.33	43.96	41.28	65.48	25.38	65.16
Qwen3-8B	SimpleMem	33.45	29.00	28.97	42.85	15.35	46.62
Qwen3-8B	MemFit	44.19	39.38	40.22	59.26	16.66	60.63
Gemma3-27B	SimpleMem	28.98	22.73	28.35	39.14	10.41	38.00
Gemma3-27B	MemFit	45.42	39.92	40.45	58.93	18.42	63.88

Table 1：LoCoMo 分类结果与四类平均分。 MemFit 在四个 backbone 上都取得最佳平均 F1/BLEU，并稳定领先 Temporal、Open Domain 和 Single-Hop；唯一明确例外是 GPT-4.1-mini 的 Multi-Hop，SimpleMem 以 43.46 高于 MemFit 的 41.58。

1. 换弱一些的 Reader，MemFit 下降更少

从 GPT-4.1-mini 换到 Gemma3-27B，MemFit 平均 F1 下降 4.84；最强 baseline 则下降 14.26。论文据此认为 MemFit 的检索包更稳定，不太依赖 reader 自己从噪声中补救。

2. Multi-Hop 是核心边界

GPT-4.1-mini 下，SimpleMem 的 Multi-Hop F1 比 MemFit 高 1.88。原因与方法设计一致：SimpleMem 在写入阶段已经用 LLM 压缩、组合事实，相当于预先计算部分跨 session 连接；MemFit 保留分散 episodes，只能在查询时依靠 PRF 与 summary expansion 拼接。

这说明“把 consolidation 推迟到 retrieval”虽然便宜，但不会免费获得同等的组合推理能力。

3. 与同一存储上的 Plain Retrieval 比较

Reader	Plain Judge	MemFit Judge	Judge 增益	Plain F1	MemFit F1
Qwen3-8B	57.24	61.88	+4.61	41.41	44.20
Gemma3-27B	59.09	64.59	+5.52	42.10	45.42
Gemma4-31B	61.75	69.42	+7.66	45.11	48.55
GPT-4.1-mini	64.33	72.37	+7.94	47.30	50.26
GPT-4o	60.06	64.91	+4.81	44.87	49.33

Table 6：相同 Episode Store 上，完整 MemFit 与 Plain Retrieval 的比较。 五个 reader 的 Judge 均提升 4.61–7.94 个百分点，全部 $p<0.001$，说明收益不只是“保留原文”，而是来自摘要导航、扩展、宽扫描和邻域补全组成的 retrieval stack。

十三、MemGallery 与 LongMemEval-S

1. 总体结果

数据集	方法	分数
MemGallery / Qwen2.5-VL-7B	NaiveRAG	59.74 F1
	A-MEM	62.28 F1
	MemoryOS	61.09 F1
	MemFit	67.66 F1
LongMemEval-S / GPT-4o-mini	Full Context	56.80 Acc.
	NaiveRAG	61.00 Acc.
	A-MEM	62.60 Acc.
	LightMem	64.29 Acc.
	MemFit	64.60 Acc.

Table 2：MemGallery 与 LongMemEval-S 总体结果。 MemFit 在 MemGallery 领先 A-MEM 5.38 个 F1 点；在 LongMemEval-S 仅比 LightMem 高 0.31 个百分点，优势很小，但构建成本结构明显不同。

2. 多模态：Query Image 有效，Retrieved Images 没有额外收益

MemGallery 上：

• Text-only MemFit：64.82 F1；
• 加 query image：67.66 F1；
• 加 query image 与 retrieved images：67.47 F1。

Query image 的 +2.84 F1 主要来自 Test-Time Learning（72.7→82.4）和 Visual-centric Reasoning（45.2→52.7）。因为 337 个 TTL 问题中有 333 个直接询问 query 自带图片。

但再把检索历史中的图片全部交给 reader，没有进一步提升总体结果。这说明 caption 已经承担了主要历史检索作用，而更多视觉输入可能增加注意力竞争。

更有意思的是，text-only Gemma3-27B 达到 69.85 F1，甚至高于 Qwen2.5-VL-7B 多模态配置。由此不能简单宣称“MemFit 的图像能力本身达到 SOTA”；部分优势来自 reader 和官方协议。

3. 官方 Prompt 协议影响很大

MemGallery 官方协议会对 AR、CD、VS 类问题追加专门格式指令。若把它替换为一个 category-blind 统一指令，F1 从 64.82 降到 47.92。

这 16.9 个点的下降远大于多数记忆模块消融，说明 benchmark protocol 对结果有巨大影响。跨论文比较时，必须确认是否完全遵循官方 prompt。

十四、效率：便宜的是写入，不一定是完整生命周期

为了直观看清各系统把成本花在哪里，需要结合 Figure 3 的调用、token、成本和延迟。

Figure 3：LoCoMo 上的效率比较。 左侧依次比较 LLM 调用、输入 token、输出 token与估算成本；右侧横轴为全量 memory build 时间，纵轴为单问题延迟。MemFit 的构建时间最低，但查询延迟不是所有系统中最低。

1. 与 LLM-heavy 系统比较

在 LoCoMo 全量 10 段对话、1540 个问题上：

• MemFit：1977 次 LLM 调用；
• SimpleMem：10,554；
• Mem0：12,551；
• A-MEM：15,736。

MemFit 少 81%–87% 调用，输出 token 少 32–45 倍；按 GPT-4.1-mini 列表价格估算，总成本 $1.53，而三者为 $8.51–$12.38。

2. 与 LightMem 比较：成本只是发生位置不同

MemFit 与 LightMem 都约有 400 次写入调用加 1540 次回答调用。

写入阶段：

• MemFit：0.22M token、$0.14；
• LightMem：1.13M token、$0.81。

但回答阶段 MemFit 传入原始 turn，平均每题输入 2210 tokens；LightMem 只有 1015。最终完整运行成本分别为 $1.53 与 $1.46，几乎相同，MemFit 甚至略高。

所以论文最可靠的效率结论是：MemFit 显著降低 memory construction 成本和延迟，而不是在所有使用模式下都拥有最低总成本。

3. Build Time 与 Query Latency

Gemma3-27B 下，全 LoCoMo memory build：

系统	Build Time/s	每题延迟/s
MemFit	946	1.23（正文对比口径）
SimpleMem	3708	22.39
LightMem	5750	0.75
A-MEM	9240	4.94
Mem0	49,765	1.06

Figure 3 对应数值：构建与查询延迟权衡。 MemFit 构建速度快 3.9–52.6 倍，但单题延迟仍慢于 LightMem 和 Mem0，体现“快写、稍重读”的设计交换。

4. Stage-level 成本

LoCoMo 的纯写入基础操作非常便宜：

• Embed turns：约 1.2 秒；
• Index + insert：约 13.8 秒；
• TextTiling：不到 0.2 秒；
• 真正耗时的是 437 次 segment summary call。

查询端纯 retrieval 为 87–105ms/题，其中约 60%–65% 来自 cross-encoder。Gemma3-27B 的平均端到端延迟为 1.95 秒，Qwen3-8B 为 0.67 秒。

十五、LongMemEval-S 的构建成本

方法	每个 History 的 LLM Calls	Tokens/k	Accuracy/%
LangMem	520.62	1102.16	37.20
A-MEM	986.55	1605.81	62.60
MemoryOS	2938.41	2991.75	44.80
Mem0	811.57	1152.62	53.61
LightMem	25.67	30.81	64.29
MemFit	40.14	25.07	64.60

Table 13：LongMemEval-S 每条 History 的构建成本。 MemFit 的调用数并非最低，LightMem 只需 25.67 次；MemFit 的优势是 token 更少且准确率高 0.31 个百分点。不同方法的成本数据来自 LightMem 报告与 MemFit 自测，仍需注意实现和运行环境差异。

十六、消融实验：每个组件有用，但高度重叠

配置	Judge	Avg F1	BLEU-1
w/o context window	62.87	43.56	38.49
w/o PRF	63.68	44.07	38.84
w/o summary expansion	64.46	44.29	39.12
w/o wide scan	63.94	44.53	39.28
w/o summaries	63.94	44.59	39.34
w/o all / plain retrieval	59.09	42.10	36.99
Full MemFit	64.59	45.42	39.92

Table 3：LoCoMo / Gemma3-27B 消融。 单独移除任何组件都会下降，但除 context window 外单项 Judge 差距较小；全部移除后 Judge 下降 5.50、F1 下降 3.32，表明多个召回机制存在功能重叠。

1. Context Window 贡献最大

去掉邻域补全后 F1 下降 1.86，Judge 下降 1.72。分类结果显示 Single-Hop F1 从 63.88 降到 59.63，说明许多答案位于命中 turn 的紧邻回复中。

2. Summary 不一定提升所有类别

去掉 summaries 后，Temporal F1 从 58.93 反而升到 59.66，Single-Hop 从 63.88 升到 64.09；但 Multi-Hop/Open/平均分与 Judge 下降。

这说明 summary 不是无条件帮助。它扩大主题召回，也会引入更宽泛候选；整体有益，但局部类别可能被噪声抵消。

3. 单项统计显著性有限

Gemma3-27B 上：

• w/o context window：Judge -1.69，$p=0.054$；
• w/o summary expansion：-0.13，$p=0.884$；
• w/o summaries：-0.65，$p=0.418$；
• plain retrieval：-5.52，$p<0.001$。

跨三个 reader 的 18 个单项比较都朝下降方向，但显著的主要是 context window、少量 wide scan 结果和完整 plain retrieval 对照。因此，论文能够稳健支持“组合 retrieval stack 有效”，对“每个小模块单独都不可替代”的证据较弱。

十七、检索命中率与失败位置

配置	Pack Hit/%	Hit@30/%
w/o PRF	81.5	88.0
w/o summary expansion	80.9	86.7
w/o wide scan	81.1	87.5
w/o summaries	82.1	87.4
Plain Retrieval	79.2	83.4
Full MemFit	82.5	88.5

Table 8：LoCoMo 检索命中率。 完整系统的 Top-30 gold evidence hit 为 88.5%，但最终 pack hit 只有 82.5%，说明约 6 个百分点的证据在 reranking 或 pack 截断阶段丢失。

Context window 在排名后才加入，因此它不会改变 Hit@30 或基础 Pack Hit，却能明显改善回答。这证明 retrieval metric 不能只看 gold turn 是否命中，还要看证据是否带足局部上下文。

十八、超参数敏感性

设置	Judge	Avg F1	每题输入 Token 相对量
Pack $k=5$	60.06	42.84	×0.56
Pack $k=10$	61.82	44.19	2156
Pack $k=20$	62.29	43.89	×1.85
Pack $k=30$	61.64	42.78	×2.65
PRF 4 docs	61.23	43.99	×1.00
Summary expansion 10	61.49	44.59	×1.01
Narrow pools 30/40	60.45	43.26	×0.99
Wider scan 100/50	61.56	44.27	×1.01

Table 3（续）：MemFit 检索设置敏感性。 $k=20$ 的 Judge 略高，但 F1 下降且 token 增至 1.85 倍；$k=30$ 更长却更差。默认 $k=10$ 是准确率与上下文成本的折中，而非所有单项指标的绝对最佳。

整体 Judge 落在 60.06%–62.29%，说明方法不依赖非常精细的超参数调节。但“多给 evidence 总会更好”明显不成立：候选增加后，reader 会受到无关内容干扰。

十九、失败案例与证据边界

1. Cross-session Multi-Hop 仍是软肋

写入阶段不预先连接事实，使 MemFit 更依赖 query-time expansion。当两个证据分别位于不同 session，且第一条证据没有提供足够稀有词引出第二条时，PRF 可能失败。

2. 不可回答问题仍有 20% 被错误回答

LongMemEval-S 的 30 个 abstention question 中，MemFit 正确拒答 80%，还有约 20% 会在部分证据上生成没有支持的答案。

3. Open Domain 结果波动较大

LoCoMo Open 只有 96 个问题。每个组件在该类都带来提升，但样本少，单项差异的统计稳定性有限。

4. MemGallery 上复杂检索几乎没有显著优势

Qwen2.5-VL-7B 下，plain retrieval 已经让 95.5% 问题的 gold evidence 进入 pack；完整系统 Judge 只高 1.52，$p=0.094$，未达显著。

这说明当 history 只有约 200 rounds、基础检索已经很强时，summary expansion、PRF 和 wide scan 的边际收益很低，瓶颈转移到 reader。

5. Retrieved Images 没有总体增益

加 query image 有效，但再加入 retrieved images 从 67.66 降到 67.47。更多模态输入并不自动带来更强记忆，可能只是增加视觉噪声。

二十、与 Agent Memory 系列方法的横向比较

方法	写入单元	写入时 LLM 决策	原始证据保留	主要检索/组织思路	与 MemFit 的关键差异
Mem0	抽取事实	Add/Update/Delete	可能被更新替代	向量/图事实库	MemFit 不提前裁决事实状态
A-MEM	原子笔记	写笔记、连边、演化	以笔记为主	可演化关联网络	MemFit 用轻量检索换取低写入成本
MAGMA	多粒度、多关系记忆	结构化组织	依实现而定	多图关联	MAGMA 显式组织，MemFit 延迟组织
CoM	组合/压缩记忆	形成可用压缩表示	存在压缩损失风险	压缩后推理	MemFit 保留逐 turn 证据
ReMemR1	可回访的写入状态	写入时 callback	通过回访修复	强化学习写入/回访	ReMemR1 改进写入，MemFit 避免写入决策
Mem²Evolve	演化记忆	持续更新和适应	依演化策略	生命周期演化	MemFit 选择 append-only，不主动演化内容
MemCode	AMU + 离散指纹	LLM 原子化、异步整合	有 source pointer	向量 + code topology	MemCode 写得更结构化，MemFit 写得更便宜
MemFit	原始 turn episode	每 segment 一次摘要	完整保留	BM25 + dense + provenance + PRF + reranker	将不可逆选择推迟到 query time

横向比较：MemFit 在 Agent Memory 路线中的位置。 它不是“更强的 consolidation”，而是对 consolidation 必要性的反思：先保留全部事实，再在问题出现时选择证据。

MemFit 与 MemCode 形成很有意思的对照：

• MemCode 用 LLM 把对话改写成可独立检索的 AMU，再增加离散关联路径；
• MemFit 拒绝重写原始 turn，用 summary provenance、PRF 和 context neighbor 恢复可检索性。

前者优化 memory representation，后者优化 evidence preservation 与 retrieval economics。

二十一、对 Coding Agent、Tool Agent 与 Multi-Agent 的启发

以下是基于论文机制的工程推演，不是论文直接实验结果。

1. Coding Agent：保存原始操作日志，摘要只做导航

Coding Agent 的历史可以按事件追加：

• 用户请求；
• Agent 修改说明；
• command 与关键输出；
• test failure；
• review 结论；
• commit 与版本信息。

高层 summary 可以描述“这一段在修复认证刷新问题”，但真正回答“当时哪个测试首先失败”时，仍回到原始 episode。

这种设计能避免摘要把具体文件名、错误码和版本号压掉。

2. Tool Agent：适合审计，但必须支持删除

Append-only 对工具审计很有价值：旧状态和修正状态都保留，系统可以解释决策过程。

但现实部署不能真的“永不删除”。应补充：

• 用户主动删除；
• 数据保留期限；
• 权限和租户隔离；
• 删除 episode 后重建相关 summary；
• 敏感字段加密与访问审计。

3. Multi-Agent：把 Author 与 Role 作为检索元数据

不同 Agent 的结论可以按原文保存，用 author/role boost 找回。Reviewer 的批评不应覆盖 Executor 的原始操作记录，而应与其并列，让最终决策 Agent 在查询时看到时间与角色关系。

4. 两阶段成本模型比单一“Memory Cost”更合理

工程评估应该拆成：

$$C_{total}=C_{write}+Q\cdot C_{read}$$

$Q$ 是该记忆库生命周期中的查询次数。MemFit 的 $C_{write}$ 很低，但 $C_{read}$ 因 verbatim context 较高。

对于“写入频繁、查询较少”的日志型 Agent，MemFit 很有吸引力；对于“同一记忆库被高频反复查询”的客服知识库，离线 consolidation 可能更经济。

二十二、局限性与风险

1. 查询成本被推高

MemFit 用低写入成本换取更复杂的查询和更长 reader prompt。与 LightMem 的完整运行成本几乎相同，说明成本并未消失，只是搬家。

2. 存储无限增长

Append-only store 随时间单调增长。论文分析检索扫描线性增长，却没有长期评估百万级 turns、索引重建、冷热分层和 summary 漂移。

3. 事实更新交给 Reader

保留旧值与新值使历史问题可回答，但也要求 reader 正确理解时间顺序。对于权限、支付、医疗等高风险状态，不能只依赖 LLM 从冲突片段中选择当前事实。

4. Multi-Hop 不如预聚合方法稳定

检索时组合事实仍然困难。GPT-4.1-mini 的 Multi-Hop 落后 SimpleMem，论文也明确承认跨 session 组合是代价。

5. 当前只支持文本和图片

音频、视频、工具轨迹、结构化状态和代码执行结果尚未覆盖。简单把它们转 caption 可能丢失关键时序或结构。

6. Caption 决定多模态可检索性

Text-image fusion 的效果受 caption 完整性限制。若 caption 没描述未来问题需要的属性，BM25 与 dense index 都无法召回正确图片。

7. 隐私风险比压缩型系统更突出

原始 turn 永久保存意味着敏感细节不会自然消失；细粒度搜索还可能被用于跟踪与画像。论文明确指出实际系统必须实现删除、retention limit 和 access control。

8. Memory Injection

系统写入时不验证内容。攻击者注入的恶意或错误文本会与正常 turn 一样长期保存，并可能在未来被检索进 prompt。

9. Baseline 比较并非完全同源复现

部分 LoCoMo baseline 来自既有结果，LongMemEval-S 成本取自 LightMem 论文，MemGallery 使用官方报告。模型版本、硬件和实现细节不完全一致，最可信的是同一 store 上的 Plain Retrieval 对照和作者自行计量的效率实验。

10. ICLR 投稿版尚非正式录用论文

当前 PDF 标注 Preprint / Under review。结论和实验可能在后续版本中调整，发表平台不能写成“已被 ICLR 2027 接收”。

二十三、我的理解与启发

1. MemFit 的本质是“推迟不可逆决策”

很多 Memory System 把写入看成信息清洗：越早消除重复、冲突与噪声，存储越整洁。

MemFit 提醒我们，清洗也是一种预测：系统必须猜未来会问什么。只要这个猜测错误，被删掉的信息就无法恢复。

Append-only 的价值不是结构简单，而是保留 option value：未来问题出现时，系统仍能重新解释历史。

2. Summary 可以是 Routing Layer，而不是 Memory Content

“摘要会丢信息”并不意味着摘要无用。关键在于摘要扮演什么角色：

• 若摘要替代原文，它承担事实保真责任；
• 若摘要指向原文，它只承担导航责任。

后者容错性更好。即使 summary 不完整，只要能把检索器带到相关 segment，原始证据仍可恢复。

3. Memory Architecture 应根据读写比选择

MemFit 适合 write-heavy 场景：持续写日志、偶尔查询。Consolidation-heavy 系统可能适合 read-heavy 场景：先付一次压缩成本，之后大量查询都读取更短上下文。

因此不存在脱离 workload 的“最省成本记忆系统”。至少应报告：

• 每次写入成本；
• 每次查询成本；
• 存储增长；
• 在不同 query/write ratio 下的总成本交叉点。

4. Retrieval Stack 的价值来自组合，而非神奇单模块

消融显示每个组件单独收益有限，且常常不显著；但全部移除会稳定退化。MemFit 更像一个经过工程配合的 retrieval recipe：

• BM25 保专名；
• dense 保释义；
• summary 找主题；
• PRF 找第二跳；
• cross-encoder 控制精度；
• neighbor window 恢复局部上下文。

它的成功来自误差互补，而不是某个新公式。

5. 下一步可能是“可撤销的轻量 consolidation”

完全 append-only 与完全重写并不是唯二选择。更成熟的系统可以：

• 原始 episode 永久作为 source of truth；
• 派生 fact、summary、graph 可以重建；
• consolidation 只修改派生视图，不删除原始证据；
• 高频查询结果形成 cache；
• 低频历史进入冷存储；
• 敏感内容按策略真正删除。

这样既保留 MemFit 的可追溯性，也减少每次查询都重新组合历史的成本。

二十四、总结

MemFit 对长期 Agent Memory 的核心判断是：写入阶段并不知道未来问题，因此不应让 LLM 过早决定哪些细节值得保存、哪些旧事实应该删除。

它把每个 turn 原样追加为 episode，同时建立 BM25 和 dense index；使用 TextTiling 切分会话，并让每个 segment 只调用一次 LLM 生成两句、带 provenance 的摘要。摘要负责找到对话区域，原始 turn 负责回答问题。

查询时，系统通过 lexical/dense 混合召回、summary provenance、pseudo-relevance feedback、cross-encoder 和 neighbor context 逐步构造证据包；整个搜索过程不调用 LLM，最终只做一次 answer extraction。

实验表明，MemFit 在 LoCoMo 的四个 backbone 上获得最佳平均 F1/BLEU，在 MemGallery 达到 67.66 F1，在 LongMemEval-S 达到 64.60% 准确率；相同 episode store 上，完整 retrieval stack 比 plain retrieval 稳定提升 4.61–7.94 个 Judge 点。它还显著降低 memory build 的调用和延迟。

但论文也清楚展示了交换条件：查询 prompt 更长，完整成本未必低于 LightMem；跨 session Multi-Hop 仍可能弱于预先 consolidation；append-only 带来无限增长、隐私与注入风险；MemGallery 的结果高度依赖官方 prompt 协议。

一句话总结：MemFit 不让 LLM 在写入时提前裁剪历史，而是用“原始 episode 永久保留、摘要只做索引、查询时多路径选择证据”的方式，把长期记忆从昂贵的在线整理问题改造成可追溯的检索问题。

参考资料

1. MemFit: Efficient Long-Term Agentic Memory
2. 论文 PDF
3. MemFit 官方代码
4. LoCoMo
5. LongMemEval
6. Mem0
7. A-MEM

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/weixin_45642847/article/details/169169820