Agent Memory Management

为什么需要 Memory

LLM 原生没有记忆

大语言模型本质上是类似y = f(x)的函数

其中x是用户输入，模型参数A、B、C在训练结束后就固定了，不会因为输入的改变而改变

因此原生 LLM 没有任何记忆能力

我们之所以觉得大模型"有记忆"，是因为采取了上下文注入的方式：把历史对话S1、S2……直到最新的输入Xn拼成一个很长的序列丢给 LLM

LLM 凭借注意力机制"看到"历史记录，从而看似有记忆。

上下文窗口的局限性

即使采取了上下文注入的方式，存在两个问题：

因此需要限制上下文窗口（Context Window）

目前业界主流采用200K tokens作为窗口大小——这个数值是通过大量实验得出的平衡点：一方面支持足够的上下文，另一方面避免注意力涣散

朴素方案：Sliding Window

原理：当窗口填满时，丢弃旧内容，移入新内容

缺陷：以前的内容大概率不如新内容重要，但很容易举出反例

比如用户在第一轮对话中做了自我介绍、设置了个性化偏好（如"请用中文回答"），一旦被滑动窗口划走，这些关键信息全部丢失。

主流方案一：基于数据库（类 RAG）

对话记录本质是一串文本，与公司文件库没有本质区别。天然适合用传统 RAG（检索增强生成）的方法处理：建立数据库 →存储切分后的文本块→ 检索 → 加载回上下文。

存储流程

1. 切块（Chunking）：如果历史消息很长（如几千字），可以按段落或按字数切分
2. 添加元信息：提取 topic、用户偏好等语言信息，一并嵌入到 chunk 中
3. 插入数据库：使用 Elasticsearch 等数据库，支持关键字搜索（BM25）和向量搜索（Vector Embedding），甚至混合搜索

检索流程

检索时主要有两种套路：

方案 A：止取（不经过 LLM）

• 将用户 query 直接 embedding 成向量
• 在数据库中进行比对检索（关键词搜索 + BM25 评分）
• 优点：速度快，不需要额外消耗 token
• 缺点：无法理解语义，对复杂查询的召回效果有限

方案 B：经过 LLM（ReAct 模式）

• 由 LLM 分析用户 query，生成更合适的搜索方案（确定关键词等）
• 从数据库检索到一堆文档后，让 LLM 做 reasoning 判断内容是否足够
• 如果不够，调整优化 query，重新检索（refine）
• 优点：语义理解能力强，检索更精准
• 缺点：消耗更多 token 和时间

最终处理

无论哪种方案，检索得到的 chunk 都被插入到上下文 Context Window 中，再附上 query，一起交给 LLM 处理。

主流方案二：基于 Markdown（蒸馏压缩）

这是Claude Code使用的方法，被很多人归为业界标准。但核心痛点是"写代码"，该方案有天然的优势，需要具体问题具体分析。

三层记忆结构

第一层：Memory（长期记忆）

特点：跨 session 永远生效，永久加载到上下文窗口。

典型内容：

• 用户编号（Profile）
• 用户偏好（User Preference），如"生成内容时尽可能少辅助信息，多用代码回答"
• 全局约束（Constraints），如"删文件时必须提示我"

第二层：Topics（专题记忆）

特点：按 topic 划分，每个 topic 是一个独立文件。

典型场景：用户让 agent 写数据库接入代码，会涉及 topicdatabase_deployment，从中提取结构化信息：

• type：例如 MongoDB
• version：例如 8.0
• constraints：约束条件

更新机制：当内容发生变化时（如 version 从 8.0 升级到 8.1），在 topic 文件中记录Historical信息，便于回溯和查找 bug。这样 LM 就能意识到旧记忆可能已过时。

加载机制：只有当当前对话涉及某个 topic 时，才会把对应 topic 内容加载到上下文窗口中。

第三层：Transcript（兜底层）

原生的原始对话记录，保存在 message 文档中。作用：万一前两层都命中不到相应信息，可以从原信息中回溯查找。

注：从性能上看，Transcript 的查找效率不如第一种 RAG 方法。但若能在前两层命中关键内容，效果往往更好。

结构化维护方法

Markdown 本质上是纯文本文件，手动维护更新非常痛苦（如需要读取文件、定位行、删除内容）。

标准做法：

1. 加载时：将 Markdown 结构化为 JSON / Dict 数据结构
2. 更新时：让 LLM 进行 distill（蒸馏压缩），按预定义的 key 生成结构化 Dict，逐项更新 Dict 内容
3. 落盘时：将 Dict 重新渲染回 Markdown 格式输出

这样做既规范又稳定，避免 key 偏移的问题。

冰与火：Key 定义的 Trade-off

在 distill 过程中，最核心的不稳定点在于：key 是预定义的，还是让 LLM 自由生成。

最冰端：Predefined Keys

• 把固定的 key（如profile、user_preference、constraints等 20 个 key）写入 system prompt
• 让 distill agent 按这 20 个 key 归纳总结
• 优点：非常稳固，即使 LLM 生成了同义词（如生成了overview而不是profile），可以通过 merge 代码将其映射回正确 key，再丢回给 LLM 让它生成一模一样的 key
• 缺点：不够灵活，可能无法覆盖新场景

最火端：LLM 自定义 Keys

• 所有 key 都由 LLM 生成
• 优点：更动态，可以适应新场景
• 缺点：不可控。例如第一轮 distill 生成了overview和focus，第二轮可能生成profile和concentration，需要多轮次判断overview与profile是否应该 merge，新 key 是 append 还是 update

业界中庸之道

取长补短，在中间状态平衡：

• 预定义足够广泛的 key，让 LLM 不需要自造词
• 也保留让 LLM生成新 key 的能力
• 既保证稳定性，又保持灵活性

如何让 LM 知道存在哪些 Topics

需要解决一个问题：LM 怎么知道该加载哪个 topic？

方法一：主动搜索

给 agent 一个 agent 去遍历所有 markdown 文件，列出有哪些 topic 可用。

方法二：轻量化写入 Memory

在 Memory 文件中维护一个轻量化的 key（如known_topics），只写简短简介（因为 Memory 是永远加载的，不能太长）。LM 看到这个列表就知道有哪些 topic 可以加载，避免每次都做遍历操作。

两种方法对比：

总结

Memory 是 Agent 设计中的重中之重。好的 memory 设计几乎在很大程度上决定了 Agent 到底好不好用。

对比：