Chain-of-Memory: Lightweight Memory Construction with Dynamic Evolution for LLM Agents

论文阅读：Chain-of-Memory——用动态记忆链替代复杂的 Memory Construction

论文标题：Chain-of-Memory: Lightweight Memory Construction with Dynamic Evolution for LLM Agents
作者：Xiucheng Xu, Bingbing Xu, Xueyun Tian, Zihe Huang, Rongxin Chen, Yunfan Li, Huawei Shen
发表位置：ACL 2026 Main Conference, Volume 1: Long Papers
arXiv 编号：2601.14287
ACL Anthology：https://aclanthology.org/2026.acl-long.534/
论文 PDF：https://aclanthology.org/2026.acl-long.534.pdf
arXiv：https://arxiv.org/abs/2601.14287
代码：https://github.com/Xiucheng-Xu/CoM
主题：LLM Agent、Long-Term Memory、Memory Retrieval、Memory Utilization
核心问题：Agent Memory 是否真的需要在写入阶段构造复杂的树或图？相比继续增加 Memory Construction 的复杂度，能否保持简单的扁平 Memory，而把计算资源用于“检索之后如何组织和使用 Memory”？

1. 问题背景：复杂的 Memory Construction 真的值得吗？

对于需要进行长期交互的 LLM Agent，仅依赖模型上下文窗口通常无法永久保留历史信息，因此需要一个外部 Memory 系统。

现有 Agent Memory 方法大体可以拆成两个阶段：

  1. Memory Construction（记忆构建）：把历史交互写入某种长期存储；
  2. Memory Utilization（记忆利用）：面对新问题时，从长期存储中找到相关记忆，再交给 LLM 推理。

近年来一个明显的发展方向，是不断加强第一阶段。

例如，一些方法不再简单保存原始对话，而是把记忆组织成：

  • 树；
  • 图；
  • 知识网络；
  • 带有动态链接关系的 Memory Notes。

这样做的动机很直观：如果在写入 Memory 的时候，就已经把不同历史信息之间的关系建立起来，那么未来检索和推理时应该更容易利用这些关系。

但本文首先提出了一个不同的问题：

这些复杂 Memory 结构付出的 Construction Cost，真的带来了与其成本相匹配的性能收益吗？

作者通过实验观察到两个问题。

1.1 问题一：复杂 Memory Construction 成本很高，但收益有限

树、图等 Memory 结构需要在记忆写入过程中完成额外操作，例如：

  • 信息抽取；
  • 压缩；
  • 节点生成；
  • 节点关联；
  • 图结构维护；
  • Memory 更新。

这些过程往往还需要额外调用 LLM。

因此，一个看起来更加“高级”的 Memory 系统，可能在回答问题之前就已经消耗了大量 Token 和时间。

作者发现，在长期 Memory QA Benchmark 上，这种高额的 Memory Construction Cost 并不一定带来相应的 Accuracy 提升。

一些复杂 Memory 方法甚至：

  • Token 消耗高于 Full Context；
  • 准确率却低于简单的 Turn-level RAG。

也就是说：

复杂结构本身并不能保证更好的长期记忆效果。

1.2 问题二：普通 RAG 检索到了证据，也不等于能够正确回答

另一个问题出现在 Memory Utilization 阶段。

传统 RAG 基本流程是：

Query
  ↓
Retrieve Top-K memories
  ↓
直接把 Top-K 拼接进 Prompt
  ↓
LLM Answer

问题在于，Top-K Memory 本质上仍然只是一些相互独立的片段。

对于 Single-hop 问题，这可能已经够用。

但对于 Multi-hop、Temporal Reasoning 等问题，答案经常依赖多个历史片段之间的组合关系。

即使 Ground-truth Evidence 已经成功被检索出来，LLM 仍可能：

  • 没有找到不同证据之间的关系；
  • 被无关上下文干扰；
  • 无法正确组合多个时间点的信息；
  • 在大量检索结果中忽略关键证据。

因此，作者区分了两个问题：

Retrieval：有没有把证据找到？

Reasoning / Utilization：找到以后，有没有正确使用？

论文认为，现有 Memory 系统过多关注第一个问题，却低估了第二个问题。

2. 论文的核心思路：Lightweight Construction + Sophisticated Utilization

基于上面的观察，作者提出一种 Memory 设计范式上的转移：

传统思路：

Heavy Memory Construction
        +
Naive Retrieve-and-Concatenate

转变为：

Lightweight Memory Construction
        +
Structured / Dynamic Memory Utilization

也就是说，作者并不试图提前把整个 Memory Database 建成复杂的图。

相反：

Memory 写入阶段尽量简单，把结构化组织放到 Query 到来以后，根据当前 Query 动态完成。

这也是 CoM（Chain-of-Memory）的核心思想。

它使用一个非常简单的扁平 Memory Database。

当 Query 到来以后：

  1. 先通过普通 Embedding Retrieval 找到 Top-K Memory；
  2. 再从这些候选 Memory 中动态构造多条 Memory Chain（记忆链）；
  3. 每次扩展一条 Chain 时，同时考虑：
    • Memory 与原 Query 是否相关；
    • Memory 与当前 Chain 是否连贯；
  4. 如果下一步的相关性突然下降，则提前终止这条 Chain；
  5. 最后把形成的 Memory Chains 提供给 LLM。

因此，CoM 的“结构”并不是一个长期存在的全局 Memory Graph。

它更接近：

面向当前 Query，在检索结果之上临时构造出的推理路径。

3. CoM 整体框架

论文将 CoM 分成两个主要阶段：

  1. Memory Construction and Retrieval
  2. Dynamic Memory Chain Evolution

image

【Figure 2（CoM 整体架构图）。重点观察左侧扁平 Memory Database、Top-K Candidate Pool，以及中间从多个 Anchor 出发动态构造 Memory Chain 的过程。】

整个信息流可以概括为：

Raw Conversation History
        ↓
Turn-level Memory Nodes
        ↓
Flat Memory Database
        ↓
Query
        ↓
Embedding Top-K Retrieval
        ↓
Candidate Pool
        ↓
选择 Top-L Anchor
        ↓
L 条 Memory Chains
        ↓
State-Aware Gating Evolution
        ↓
Adaptive Path Truncation
        ↓
最终 Memory Chains
        ↓
System Prompt + Chains + Query
        ↓
LLM Answer

下面分别展开。

4. Memory Construction：作者刻意把这一阶段做得非常简单

4.1 Memory 的最小单位就是一个 Conversation Turn

假设完整历史由多个 Session 构成：

H = {S_1, ..., S_M}

每个 Session 又由多个对话 Turn 组成。

CoM 不进行复杂的事实抽取或知识图谱构建，而是直接把一个 Turn 作为一个 Memory Node。

每个 Memory Node 保存：

m_i = (x, timestamp, role, embedding)

其中：

字段 含义
x 原始文本内容
timestamp 时间戳
role User 或 Assistant
embedding 该 Turn 的向量表示

最终得到的是一个扁平的 Memory Database。

这里非常关键：

CoM 并没有在 Memory Construction 阶段显式构建 Memory Node 之间的边。

没有：

  • 全局 Graph；
  • Tree；
  • 复杂知识结构；
  • 长期维护的节点关系。

Memory Construction 的主要工作就是：

Conversation Turn
    ↓
Embedding
    ↓
Store

这正是论文所说的 Lightweight Memory Construction。

5. Retrieval：先做一次普通的 Top-K 语义检索

用户提出 Query q 后，首先使用 Embedding Model 得到 Query Embedding。

然后计算 Query 与每个 Memory Node 的 Cosine Similarity：

retrieval_score(m_i) = cos(q, embedding_i)

按照分数从高到低选取 Top-K Memory Nodes：

P = {m_1, m_2, ..., m_K}

形成 Candidate Pool（候选池）。

论文实验中统一设置：

K = 20

到这里为止，其实和普通 Turn-level RAG 非常相似。

但作者认为问题恰恰从这里开始。

普通 RAG 会直接做：

Top-K memories
    ↓
Concatenate
    ↓
LLM

而 CoM 不会立即把这些 Memory 交给 LLM。

因为 Candidate Pool 中的节点依然：

彼此孤立。

因此接下来才进入论文真正的核心——Dynamic Memory Chain Evolution。

6. Dynamic Memory Chain Evolution：把孤立 Memory 组织成推理链

Dynamic Memory Chain Evolution（动态记忆链演化，DMCE）的目标是：

从 Top-K Memory Nodes 中，根据当前 Query 动态构造若干条具有上下文连续性的 Memory Chain。

它包含三个关键步骤：

  1. Initialization；
  2. State-Aware Gating Evolution；
  3. Adaptive Path Truncation。

6.1 Initialization：用 Top-L Memory 作为多个 Anchor

Candidate Pool 中已经存在 K 个按 Query Relevance 排序的 Memory Nodes。

CoM 首先取其中 Top-L 个节点作为 Anchor（锚点）。

因此初始化出 L 条不同的 Memory Chains：

Chain 1:
Anchor 1

Chain 2:
Anchor 2

...

Chain L:
Anchor L

这里的设计意味着：

系统并不是只构造一条唯一的 Memory Chain，而是从多个高相关 Memory 出发，同时尝试形成多条候选推理路径。

这样可以避免所有后续证据都被迫依赖于某一个初始节点。

论文正文给出了 Top-L 初始化机制，但没有进一步在方法部分明确给出 L 的具体固定值，因此这里不额外推断其实现设置。

6.2 State-Aware Gating：下一条 Memory 必须同时满足两个条件

假设当前已经存在一条 Memory Chain：

Anchor
  ↓
Node 1
  ↓
Node 2

现在需要从剩余 Candidate Nodes 中选出下一个 Node。

作者认为，仅仅计算：

cos(candidate, query)

是不够的。

因为它只能回答：

这个 Memory 和原始 Query 是否相关？

却不能回答：

它是否适合作为当前这条 Memory Chain 的下一步？

因此作者设计了 State-Aware Gating Score。

对于 Candidate Memory m：

S_gate(m)
    =
Global_Relevance(m)
    ×
Contextual_Consistency(m)

其中：

Global_Relevance(m)
    = cos(m, query)

表示：

这个 Memory 是否仍然围绕用户最开始的问题？

而：

Contextual_Consistency(m)
    = cos(m, current_chain)

表示：

这个 Memory 是否和当前已经构造出来的 Chain 在语义上保持连续？

所以完整形式是：

S_gate(m)
    =
cos(m, query)
    ×
cos(m, current_chain)

然后选择 Gate Score 最大的 Candidate 作为下一节点。

6.3 为什么必须同时考虑 Global Relevance 和 Contextual Consistency？

这两个分数解决的是两个不同的问题。

只看 Global Relevance

假设 Query 是：

用户现在正在做什么运动？为什么开始做这个运动？

历史中可能存在：

Memory A：用户最近开始跑步。
Memory B：用户去年买了一双跑鞋。
Memory C：用户最近因为医生建议开始增加有氧运动。

如果只看 Query 相似度，那么很多包含“运动”“跑步”的 Memory 都可能获得很高分。

但它们之间未必能形成回答问题所需要的逻辑链。

只看 Contextual Consistency

如果只要求新节点和当前 Chain 很相似，则又可能逐渐沿着某个局部话题偏离原始 Query。

例如：

跑步
→ 跑鞋
→ 鞋子
→ 购物
→ 电商

局部上每一步都可能语义连续，但最后已经偏离用户问题。

因此 CoM 要求：

与 Query 相关
AND
与当前 Chain 连贯

作者采用乘法来实现这种“Soft Conjunction（软逻辑与）”。

只有两个分数同时较高，最终 Gate Score 才会高。

6.4 一个很重要的区别：CoM 不是普通 Re-ranking

表面上看，CoM 似乎只是在 Top-K 检索结果之后又打了一次分。

但论文专门强调它与 Re-ranking 的区别。

普通 Re-ranking 通常计算：

score(memory_i, query)

也就是说：

每个候选片段独立面对 Query 打分。

然后重新排序：

m_7
m_2
m_13
m_5
...

但 CoM 的第 t 步打分依赖于：

Query
+
当前已经形成的 Memory Chain

所以：

score_t(memory_i)
=
f(
    query,
    current_chain,
    memory_i
)

同一个 Memory Node 在不同 Chain、不同演化阶段，其作用可能不同。

因此 CoM 做的不是：

“哪几条 Memory 最相关？”

而是：

“在当前已经形成这条证据路径的前提下，下一条最适合接什么？”

论文也额外使用 Cross-Encoder Re-ranker 进行了对比。

在 LongMemEval 上：

方法 GPT-4o-mini ACC Qwen3-32B ACC
Cross-Encoder Rerank 62.73 63.20
CoM 74.20 76.40

在 LoCoMo 上：

方法 GPT-4o-mini ACC Qwen3-32B ACC
Cross-Encoder Rerank 68.31 65.32
CoM 72.86 70.97

作者据此认为，CoM 的提升并不能简单归结为“使用了一个更好的 Retrieval Scorer”。

真正的区别在于：

它把检索结果动态组织成依赖于当前 Chain State 的结构化推理路径。

7. Adaptive Path Truncation：不是 Chain 越长越好

如果一直从 Candidate Pool 中选择节点，最终很可能把越来越弱相关的 Memory 也塞入 Chain。

因此 CoM 又加入了 Adaptive Path Truncation（自适应路径截断，APT）。

假设：

s_(t-1)

是上一轮被加入 Chain 的节点分数；

当前最佳 Candidate 的 Gate Score 是：

s_t*

如果：

s_t* < beta * s_(t-1)

则立即终止 Chain Expansion。

其中 beta 是控制截断敏感度的阈值。

直观来说，作者关注的不是某个绝对分数，而是：

下一步相比上一节点是否出现了“悬崖式下降”。

例如：

0.84
 ↓
0.79
 ↓
0.73
 ↓
0.68
 ↓
0.29

当分数从 0.68 突然掉到 0.29 时，很可能意味着：

已经没有与当前证据路径真正相关的 Memory 了。

那么继续扩展只会引入噪声。

于是 Chain 在这里停止。

7.1 为什么使用相对阈值？

如果采用固定绝对阈值，例如：

score < 0.5 → stop

不同 Query、不同 Chain 的 Similarity Score 分布可能并不一致。

CoM 更关心当前 Chain 内部的相对变化：

上一节点还很相关
→ 下一节点突然不相关

论文把这种情况称为类似 cliff-like drop（悬崖式下降） 的现象。

这样能够在不预先固定 Chain Length 的情况下动态决定每条路径应该有多长。

8. 最终交给 LLM 的不是散乱 Top-K，而是 Memory Chains

完成上述过程以后，系统最终得到：

Memory Chain 1
Memory Chain 2
...
Memory Chain L

然后将：

System Prompt
+
Memory Chains
+
Query

共同输入 LLM 生成答案。

所以，从整体上看，CoM 的核心改变并不是 Retrieval 本身：

普通 RAG：

Query
→ Top-K
→ Concatenate
→ LLM

而是：

CoM：

Query
→ Top-K
→ 构造多个 Anchor
→ 根据 Query + Chain State 动态扩展
→ 无关时截断
→ Memory Chains
→ LLM

它把“结构化 Memory”的时机，从：

Memory 写入时

推迟到了：

Query 到来后的 Memory Utilization 阶段

9. Complexity Analysis

设：

  • K：Candidate Pool 大小；
  • L：初始化 Memory Chain 数量；
  • d：Embedding Dimension。

如果完全不触发 Adaptive Truncation，那么单条 Chain 在不断选取节点时，需要重复比较剩余 Candidate。

论文给出的最坏情况复杂度为：

O(L * K^2 * d)

如果进一步限制最大 Chain Length 为 T：

O(L * T * K * d)

其中：

T <= K

不过论文指出，在实际设置中：

  • K 较小；
  • L 较小；
  • Adaptive Truncation 往往会提前终止路径；
  • Query 与 Candidate 的 Global Relevance 可以提前计算。

因此反复计算的主要部分实际上是：

candidate
vs.
current chain

之间的 Contextual Consistency。

从后面的 Runtime 实验来看，这部分成本仍明显低于需要进行复杂 Graph / Tree Construction 的方法。

10. 实验设置

10.1 Benchmark

论文使用两个长期记忆 Benchmark。

Benchmark QA 数量 Conversation 数量 平均 Context
LongMemEval-S 500 500 约 115k tokens
LoCoMo 1986 10 约 26k tokens

作者将问题统一划分成四类：

  • Single-hop；
  • Multi-hop；
  • Temporal；
  • Knowledge。

其中 LongMemEval 的问题分布为：

类型 数量 比例
Single-hop 156 31.2%
Multi-hop 133 26.6%
Temporal 133 26.6%
Knowledge 78 15.6%

LoCoMo 中按照 Mem0 的实验设置排除了 446 个 Adversarial Samples，剩余类别为：

类型 数量 比例
Single-hop 841 54.6%
Multi-hop 282 18.3%
Temporal 321 20.8%
Knowledge 96 6.2%

10.2 Baselines

论文比较了以下方法。

方法 Memory 方式
Full Context 直接输入完整历史
RAG (session) Session-level Retrieval
RAG (turn) Turn-level Retrieval
LangMem 抽取显著事实后进行 Vector Retrieval
A-Mem 构造带动态 Note Link 的结构化 Memory
Mem0 Incremental Fact Compression + Graph Extension
CoM Flat Memory + Dynamic Memory Chain Evolution

此外，附录还补充了 Cross-Encoder Re-ranking Baseline。

10.3 模型和 Embedding

作者使用两个 Backbone：

GPT-4o-mini
Qwen3-32B (Non-Thinking Mode)

默认 Embedding Model 为：

Qwen3-Embedding-8B

Retrieval Size：

K = 20

此外论文还使用：

text-embedding-3-small

进行 Embedding Robustness 实验。

10.4 Evaluation Metric

主要效果指标是：

Accuracy

但这里的 Accuracy 不是 Exact Match，而是通过 LLM-as-Judge 判断回答是否与 Reference Answer 在语义上等价。

论文使用相同 Backbone 系列进行 Answer Generation 与 Judge Evaluation。

效率指标包括：

Total Token Consumption
Total Runtime

这里统计的是 End-to-End Cost，包括：

  • Memory Construction；
  • Retrieval；
  • LLM Generation。

因此论文评价的不只是 Answer 阶段，而是整个 Memory System 的实际计算开销。

11. Main Results

11.1 LongMemEval：CoM 明显超过普通 RAG 和复杂 Memory 方法

GPT-4o-mini 下：

Method Single-hop Multi-hop Temporal Knowledge Total ACC
Full Context 68.59 39.85 44.36 76.92 55.80
RAG (session) 75.64 54.89 44.36 57.69 59.00
RAG (turn) 79.49 54.14 48.87 76.92 64.20
A-Mem 73.72 42.86 34.59 55.13 52.20
Mem0 41.67 45.11 54.14 64.10 49.40
CoM 84.62 65.41 65.41 83.33 74.20

Qwen3-32B 下：

Method Single-hop Multi-hop Temporal Knowledge Total ACC
Full Context 73.72 41.35 38.35 70.51 55.20
RAG (session) 78.21 54.89 47.37 66.67 62.00
RAG (turn) 82.05 59.40 48.87 74.36 66.00
A-Mem 78.20 39.10 30.08 66.67 53.20
Mem0 54.49 45.86 43.61 62.82 50.60
CoM 86.54 69.92 69.17 79.49 76.40

最明显的优势主要出现在：

  • Multi-hop；
  • Temporal Reasoning。

这也与方法设计相对应。

因为这两种问题通常不是“找到一条 Memory 就结束”，而是需要把多个历史片段建立起关系。

12. LoCoMo 结果

GPT-4o-mini：

Method Single-hop Multi-hop Temporal Knowledge Total ACC
Full Context 88.59 53.55 50.78 50.00 71.88
RAG (session) 78.83 52.02 47.16 44.79 65.32
RAG (turn) 77.76 41.13 44.79 60.44 65.39
A-Mem 74.31 37.58 44.54 37.50 59.09
Mem0 73.72 40.07 61.05 47.91 63.31
CoM 83.59 48.94 73.52 46.88 72.86

Qwen3-32B：

Method Single-hop Multi-hop Temporal Knowledge Total ACC
Full Context 86.44 51.06 49.53 45.83 69.74
RAG (session) 78.83 45.39 44.85 39.58 63.18
RAG (turn) 75.26 34.04 57.32 41.66 61.88
A-Mem 77.88 41.48 40.49 36.45 60.84
Mem0 75.74 45.74 53.27 42.70 63.51
CoM 81.45 46.09 71.96 48.95 70.97

需要注意的是，CoM 并不是所有细分类别都取得最高分。

例如 LoCoMo 的 Single-hop：

  • Full Context 高于 CoM；
  • GPT-4o-mini 下的 Multi-hop 也是 Full Context 更高。

但在论文特别关注的 Temporal Reasoning 上，CoM 的提升非常明显。

这说明论文的结果并不是简单地证明：

“CoM 在所有 Memory QA 上都最好。”

而是表明动态组织 Evidence 在需要组合历史信息的任务上尤其重要。

13. 为什么作者强调 Efficiency？

CoM 的一个核心目标并不仅仅是提高 Accuracy。

论文还想证明：

没有必要为了长期 Memory 而承担非常昂贵的 Memory Construction Cost。

以 LongMemEval、Qwen3-32B 为例：

Method ACC Tokens (k) Runtime (s)
Full Context 55.20 119.6 11504
RAG (turn) 66.00 7.9 2891
A-Mem 53.20 331.8 32949
Mem0 50.60 156.0 19721
CoM 76.40 8.8 2002

这里一个非常明显的结果是 A-Mem。

它大约消耗：

331.8k tokens

而 Full Context 为：

119.6k tokens

也就是说，其 Token Cost 甚至明显高于直接处理完整上下文。

CoM 则只有：

8.8k tokens

而 Accuracy 反而达到最高的：

76.40%

以该组实验中的 A-Mem 为参照：

CoM Token ≈ A-Mem 的 2.7%
CoM Runtime ≈ A-Mem 的 6%

这也对应了论文摘要中强调的效率数字。

因此，论文想表达的重点不是：

“Memory Structure 完全没有用。”

而是：

与其提前构造一个昂贵的全局 Memory Structure，不如针对当前 Query，在检索后的少量 Candidate Memory 中动态建立局部结构。

14. Ablation Study：Dynamic Chain 和 Truncation 都有作用

论文分别移除了：

  • 整个 Framework；
  • Dynamic Memory Chain Evolution（DMCE）；
  • Adaptive Path Truncation（APT）。

LongMemEval 上结果为：

Variant GPT-4o-mini ACC Tokens (k) Qwen3-32B ACC Tokens (k)
w/o Framework 55.80 112.66 55.20 119.56
w/o DMCE 64.20 7.57 66.00 7.90
w/o APT 70.49 9.45 72.75 9.60
CoM 74.20 8.24 76.40 8.81

其中最关键的是 w/o DMCE。

对于 Qwen3-32B：

w/o DMCE: 66.00%
CoM:      76.40%

说明如果只是做 Turn-level Retrieval，而不把 Memory 动态组织成 Chain，性能会显著下降。

而移除 APT 后：

72.75% → 76.40%

同时 Token 数：

9.60k → 8.81k

说明 Adaptive Truncation 同时承担两个作用：

  1. 减少无关 Memory；
  2. 降低计算和 Context Cost。

15. Gating Formula 消融：为什么一定要做乘法？

作者进一步比较了四种 Gate Score。

Qwen3-32B：

Gating Variant LongMemEval LoCoMo
Only Global Relevance 66.15 65.26
Only Contextual Consistency 69.35 66.84
Weighted Average 72.55 68.17
Multiplicative Combination 76.40 70.97

结果显示：

Global Relevance × Contextual Consistency

效果最好。

这支持作者前面的设计：

一个好的 Successor Node 需要同时满足：

Relevant to Query
AND
Consistent with Current Chain

如果只优化其中任何一个条件，都不够。

即使把两者做 Weighted Average，也不如乘法。

因为加权平均允许：

一个维度很高
+
另一个维度很低

仍然得到一个中等甚至较高的总分。

而乘法会更强地惩罚其中任意一个很低的候选节点。

16. Retrieval Size：Memory 并不是检索越多越好

作者在 LongMemEval 上测试：

K ∈ {1, 5, 10, 20, 50}

Qwen3-32B 的结果为：

K Accuracy Tokens (k)
1 0.4128 0.27
5 0.6814 2.09
10 0.7335 4.14
20 0.7660 8.24
50 0.7400 15.57

随着 K 从 1 增加到 20：

Accuracy 持续提升

但继续增加到：

K = 50

反而下降。

作者认为，这说明真正关键的信息主要集中在排名较高的 Retrieval Results 中。

检索更多 Memory 并不一定意味着：

给模型提供了更多有用信息。

也可能意味着：

给模型增加了更多噪声。

因此作者最终选择：

K = 20

作为信息充分性与效率之间的平衡点。

17. Adaptive Truncation Threshold

论文进一步测试：

beta = 0.3
beta = 0.5
beta = 0.7

结果如下：

Dataset beta=0.3 beta=0.5 beta=0.7
LongMemEval 73.95 76.40 70.14
LoCoMo 67.52 70.97 66.48

beta = 0.5 在两个 Benchmark 上都最好。

作者解释为：

beta 太小

不容易触发截断：

Chain 扩展过长
→ 引入更多 Noise

beta 太大

截断过于激进：

Chain 过早停止
→ 丢失必要的中间 Evidence

因此需要在：

保留 Evidence
vs.
及时去除 Noise

之间取得平衡。

18. Embedding Model Robustness

由于整个方法高度依赖 Semantic Similarity，一个自然的问题是：

CoM 的提升是不是主要来自 Qwen3-Embedding-8B？

作者把默认 Embedding Model 替换成：

text-embedding-3-small

同时保持 Qwen3-32B 作为 Answer Backbone。

LongMemEval：

Method S-hop M-hop Temp Kno Overall
RAG 80.77 54.14 53.38 74.36 65.40
CoM 84.62 68.42 67.67 79.49 75.00

LoCoMo：

Method S-hop M-hop Temp Kno Overall
RAG 74.31 43.26 66.35 43.75 65.06
CoM 81.92 43.61 69.47 46.87 70.12

因此作者认为，CoM 的提升并不是依赖某一个特定 Embedding Backbone。

19. Upper Bound Analysis：Retrieval 与 Reasoning 分别还剩多少空间？

论文进一步设计了两个非常重要的上界实验。

19.1 Gemini-2.5-Pro Full Context

作者使用具有 1M Context Window 的 Gemini-2.5-Pro，直接读取整个 LongMemEval Context。

这样基本绕开了 Retrieval 造成的信息丢失。

结果：

Accuracy = 89.20%
Tokens   = 122.89k
Runtime  = 8512.10s

19.2 Evidence-Only Oracle

另外一种设置则更加直接：

不让系统自己 Retrieval，而是直接把人工标注的 Ground-truth Evidence 给模型。

这样就可以测量：

如果 Retrieval 完全正确，当前 Backbone 的 Reasoning Ceiling 有多高？

结果：

Method Total ACC
Evidence Only, GPT-4o-mini 80.20
CoM, GPT-4o-mini 74.20
Evidence Only, Qwen3-32B 81.80
CoM, Qwen3-32B 76.40
Gemini-2.5-Pro Full Context 89.20

例如 Qwen3-32B：

Oracle Evidence Only: 81.80%
CoM:                  76.40%

两者已经比较接近。

这说明 CoM 已经能够找到并组织相当一部分真正关键的信息，但仍然存在：

  • Retrieval Error；
  • Evidence Organization Error；
  • LLM Reasoning Error。

20. Error Analysis：真正的大头并不是 Retrieval Failure

作者进一步分析了 LongMemEval 中 118 个错误样本。

结果：

Error Type 比例
Retrieval Failure 25.4%
Reasoning Failure 74.6%

也就是说，接近四分之三的错误发生在：

相关证据其实已经取得，但模型没有正确利用。

这个结果也是整篇论文最初动机的进一步验证。

Memory 系统的问题不能简单归结为：

Retrieval Recall 不够高

即使 Recall 已经足够，仍然存在一个独立的：

Memory Utilization / Reasoning Bottleneck

20.1 Retrieval Failure

论文总结了几种主要情况：

  • Multi-hop Evidence 分散在不同位置；
  • 长 Context 中存在 Middle-position Information Loss；
  • Query 与原始 Memory 文本之间存在 Semantic Misalignment。

20.2 Reasoning Failure

Reasoning Failure 又被进一步分成五类：

类型 比例 含义
Temporal Reasoning 30.7% 无法正确重建时间顺序或理解相对时间
Aggregation & Counting 29.5% 汇总、统计、计数时出错
Implicit Information 17.0% 难以从行为模式中推断隐含信息
Knowledge Update 13.6% 无法正确处理状态更新，仍使用旧信息
Hallucination 9.1% 缺乏证据时仍生成不存在的信息

其中最大的两个来源是：

Temporal Reasoning
Aggregation & Counting

这意味着，即使 Memory System 能够把相关证据提供出来，LLM 自身对长期、多片段 Context 的推理能力仍然是明显瓶颈。

21. 论文的核心结论

CoM 的核心并不是提出一种更加复杂的 Memory Storage。

恰恰相反，它试图减少 Memory Construction 的复杂度。

整个方法可以浓缩为：

Raw Conversation
      ↓
Turn-level Flat Memory
      ↓
Top-K Retrieval
      ↓
Dynamic Memory Chain Evolution
      ↓
Query Relevance
      ×
Chain Consistency
      ↓
Adaptive Truncation
      ↓
Compact Memory Chains
      ↓
LLM Reasoning

论文想证明的是：

长期 Memory 系统的性能不一定取决于 Memory 在写入阶段被组织得多么复杂，更重要的问题可能是检索出来以后，如何把孤立 Evidence 组织成真正适合推理的上下文。

因此，CoM 将结构化处理从：

Pre-retrieval / Memory Construction

移动到了：

Post-retrieval / Memory Utilization

并且这个结构还是：

Query-specific
Dynamic
Temporary

而不是一个需要长期维护的全局 Graph。

从实验结果来看，这种设计尤其改善了：

  • Multi-hop Reasoning；
  • Temporal Reasoning；

同时避免了 A-Mem、Mem0 等复杂 Memory Construction 所产生的大量 Token 和 Runtime 开销。

22. 论文指出的局限性

作者在论文中明确给出了四类限制。

22.1 仍然依赖 Embedding Similarity

CoM 的 Retrieval 和 Chain Evolution 都大量依赖 Embedding-based Semantic Similarity。

如果 Embedding Model 无法捕捉：

  • 细粒度时间关系；
  • Pragmatic Relation；
  • 隐式关系；

那么 Memory Chain 的质量也会下降。

也就是说，CoM 并没有彻底解决 Semantic Retrieval 本身的表示能力问题。

22.2 Adaptive Truncation 可能误删弱连接证据

APT 的目标是及时停止已经开始偏离主题的 Chain。

但某些问题可能天然需要：

很长
+
中间关系较弱

的推理链。

这种情况下，某个必要的 Intermediate Evidence 可能暂时只有较低的 Gate Score。

Adaptive Truncation 就有可能过早停止路径，导致后面的关键 Evidence 无法加入。

22.3 当前实验只验证了文本长期 Memory

本文主要研究：

Textual Long-Term Memory

还没有验证：

  • Vision-Language History；
  • Multi-modal Memory；
  • Tool-use Traces。

因此 CoM 是否能够直接迁移到多模态或 Tool Agent 场景，论文尚未给出结论。

22.4 Benchmark 与真实 Agent 环境仍存在差距

真实 Agent 可能需要面对：

  • 更开放的目标；
  • 持续变化的用户偏好；
  • 更嘈杂的 Memory Update；
  • 长期交互过程中的状态变化。

现有 LongMemEval 和 LoCoMo 不能完整覆盖这些情况。

因此作者认为，还需要在真正的 Interactive Deployment 中进一步验证 CoM 的 Robustness。

23. 总结

本文提出 Chain-of-Memory（CoM），其出发点与许多长期 Memory 工作不同。

论文首先质疑了一个常见方向：

Memory 越复杂
→ 关系表示越丰富
→ Memory 效果越好

作者通过实验发现，复杂的 Graph / Structured Memory 往往带来很高的 Memory Construction Cost，却未必得到相匹配的 Accuracy。

与此同时，普通 RAG 的问题也不只是 Retrieval：

找到 Evidence
≠
能够正确利用 Evidence

因此 CoM 采用：

Lightweight Construction
+
Sophisticated Utilization

Memory 本身保持简单的 Turn-level Flat Storage。

真正的结构化过程发生在 Query 到来之后：

  1. Top-K Retrieval 得到 Candidate Pool；
  2. Top-L 节点作为多个 Anchor；
  3. 根据 Global Relevance 与 Contextual Consistency 动态扩展 Memory Chain；
  4. 通过乘法 Gate 要求新节点同时满足 Query 相关性和 Chain 连贯性；
  5. 使用 Adaptive Path Truncation 在相关性突然下降时停止扩展；
  6. 最终把紧凑的 Memory Chains，而不是无结构的 Top-K List，提供给 LLM。

在 LongMemEval 和 LoCoMo 上，CoM 在 GPT-4o-mini 和 Qwen3-32B 两个 Backbone 上均取得较强结果，优势尤其集中在 Multi-hop 与 Temporal Reasoning；与此同时，其 Token 和 Runtime Cost 显著低于需要复杂 Memory Construction 的方法。

论文最后的核心观点可以概括为：

对于 Agent Long-Term Memory，与其不断增加 Memory Construction 的复杂度，一个值得关注的方向是保持 Memory Storage 简单，并把更多设计放到 Query-aware、Context-aware 的 Memory Utilization 阶段。

参考

  1. Xiucheng Xu, Bingbing Xu, Xueyun Tian, Zihe Huang, Rongxin Chen, Yunfan Li, Huawei Shen. Chain-of-Memory: Lightweight Memory Construction with Dynamic Evolution for LLM Agents. ACL 2026.

  2. Di Wu et al. LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. arXiv:2410.10813.

  3. Ashwin Maharana et al. LoCoMo: Evaluating Very Long-Term Conversational Memory of LLM Agents.

  4. Wujiang Xu et al. A-Mem: Agentic Memory for LLM Agents. arXiv:2502.12110.

  5. Prateek Chhikara et al. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv:2504.19413.

posted @ 2026-09-15 10:11  YourF4u1t  阅读(12)  评论(0)    收藏  举报