AI Memory 系统架构的构思、随想与工程实现

说在前面

今天为大家分享的这篇文章，将从系统架构视角，通过比较浅显易懂的方式，来剖析 AI Memory 的本质。

本文所讲的 Memory，指 Agent 在长期交互中积累、可被检索与利用的记录 / 知识 / 经验库。它直接影响个性化、持续学习能力与长程任务表现。

文章的作者是蚂蚁集团的库达大佬（陈梓康) ，在 DataWhale 和 OceanBase 联合发布的社区课程《Easy Data x AI》中，精心整理的一章共建内容（详见：https://github.com/datawhalechina/easy-data-x-ai/blob/main/docs/extra 的 X1-4 小节）。

因为原文的内容比较深，所以这里对复杂的公式定理部分，进行了一定程度的简化，保留了大家容易看懂并理解的关键内容。希望大家在阅读完这篇文章之后，都能够对 Agent 中 Memory 系统的实现形式有所了解。

除此以外，阿里云百炼还专门为我们 DataWhale x OceanBase 联合开发的《Easy Data x AI》课程 https://github.com/datawhalechina/easy-data-x-ai 的社区共建和实验内容，提供了专属的免费模型算力福利，详见文末的“福利环节”~

说明：

文中会提到一些 2026 年的新论文，但这些论文都仅供参考。

欢迎大家关注 OceanBase 社区公众号 “老纪的技术唠嗑局”。在这里，我们会持续为大家更新与 #AI 和 #Data 相关的技术内容~

正文开始~

一、Memory 的本质：三个核心命题

Agent 里的 Memory 要回答的问题是：“过去有没有帮它把今天的事做对”。要回答这个问题，靠一个 markdown 文件，甚至一个数据库，都还远远不够，Agent 需要一个小的 Memroy OS。

核心命题：Memory 在 Agent 系统里到底是什么？

经过最近一两年的思考，先给出一个结论吧：我认为 Agent Memory OS 的可以抽象三个词 —— Raw Ledger、Views、Policy。它们分别类似于操作系统里的原始日志、索引与缓存、调度规则。

命题 A：Memory 不是“存储”，而是可被决策利用的外部状态（external state）

如果把 Agent 看成一个从输入到输出的函数，仅仅“存了很多历史”并不构成能力；能力来自：在当前状态下，历史能否以某种形式影响决策分布。

记忆系统负责从历史中提取当前可用的信息（证据、摘要、子图、可执行技能等），并把它提供给推理层，共同产生决策。Memory 的价值不在于“存了多少历史”，而在于这条 从历史到当前决策的通道 是否有效。

Memory 不等于历史本身，而是“把历史转成当前可用信息”的通道——它的输出要么进入上下文（证据/摘要/子图），要么直接参与决策（例如对输出分布做调制）。

命题 B：Memory 的最小闭包是 Ledger、Views、Policy

  1. Raw Ledger（原始账本） ：它按发生顺序保留写入、修改、删除和反馈。Ledger 这个词本来就是账簿，前面加 Raw，是提醒我们这里存的是未经美化的原始事实。用户哪天说了什么，系统何时改过哪条记忆，当时属于哪个会话和任务，都应该能查回来。
  2. Derived Views（派生视图） ：也就是从账本加工出的各种“便于查找的版本”。向量索引适合按意思找，全文索引适合查姓名和编号，知识图谱适合查人物关系，时间线适合回答去年发生了什么。View 可以压缩，也可以丢掉一部分细节，但需要能够顺藤摸瓜回到原始账本。
  3. Policy（控制策略） ：决定何时读、读多少、何时写、如何更新、如何遗忘。并且这些决策必须显式化为可记录/可回放的 Action 序列（ADD / UPDATE / DELETE / NONE…），而不是“靠 prompt 里一句话暗示”。

Raw Ledger 像“账本/黑匣子”，views 像“缓存 + 索引 + 物化视图”；policy 像“调度器/控制回路”。三者缺一，系统要么不可治理（没有账本），要么不可用（没有索引/抽象），要么不可持续迭代（没有可 A/B 的控制点）。

命题 C：Memory 的基本单位是 event（事件）序列，但 event 流不等于可用系统

把 Raw Ledger 建模成 event 序列是合理的，因为协议里所有可审计性都依赖“事件闭包”。

一个最通用的 ledger 事件应当包含以下要素：

  • 作用域（scope） ：这条事件属于哪个用户、哪个会话、哪个任务
  • 时间戳 ：事件发生的时刻
  • 输入观测 ：当时的 messages / 环境状态片段
  • 系统动作 ：包括对外输出，也包括 Memory Tool 的动作
  • 记忆变更 ：对记忆状态的变更（ADD/UPDATE/DELETE/NONE）
  • 反馈信号 （可选）：reward / 用户评分 / 任务成败等
  • 决策元数据 （可选）：候选集合 candidate_set、命中证据 provenance、early stop 阈值等

event 序列是“真相来源”，但 它太底层 。如果只存 event，你得到的是可审计的历史，不是可用的记忆能力；真正把历史变成能力的是 views（对 event 的重组织/压缩/索引/时序化/技能化）和 policy（决定什么时候触发哪些 view、怎么更新 view）。

换句话说： event 是 Ledger 的数据形态；views/policy 是能力形态 。

小结：为什么 Raw Ledger + views + policy 是自然解

三个命题可以补全成一个更明确的结论链：

  1. Memory 需要以 event/Action 序列为第一性对象 ：否则 Provenance（可回放）无从谈起。
  2. 单一 event 流不可用 ：因为推理需要高密度信息、需要索引、需要时序化、需要技能化；这些都要求 views。
  3. views 不可能“自洽地产生” ：它们是派生状态，派生就意味着近似与冲突；因此必须有 policy 来决定写入/更新/检索/淘汰，并且决策过程必须被记录下来，否则系统不可治理、不可 A/B。

因此，Memory 的本质不是一个组件，而是一个闭环系统 ：Raw Ledger（权威）→ Views（可用）→ Policy（控制）→ Commit（回写）→ Provenance（可回放）。

二、System 1 + System 2 的设计

为什么需要一个“非空”的 System 2

这里借用认知科学里的两个名字，但不讨论心理学争论。

System 1 是快速工作的通用 Agent ，也就是我们平时接触的大模型加工具：读懂问题、制定计划、写代码、调用搜索、生成回答。

System 2 是较慢的外部记忆回路 ，负责保存、检索、更新、压缩和遗忘。它像操作系统内核与后台服务，平时不抢镜，少了它，应用每次重启都像第一次安装。

如果 System 2 不发挥作用，那么记忆能力只能通过 RL post-training 等方式固化到 System 1（LLM 权重）中。在这种设定下，很难保证记忆特化训练后仍保持通用泛化能力，因此需要一个非空的 System 2，承担记忆的写入、检索与更新，并把相关决策显式化为可观测、可回放的过程。

并且，我们还注意到，记忆能力和 LLM 本身的其他 Agent 能力是“相对”正交的。因此，我们可以靠只牺牲一丢丢 Memory System 的上限，来获得大量的好处（这种好处很多，比如，不影响 System 1 的 Agent 性能，记忆可插拔、可迁移、更易归因）。

另外，做个不严谨地类比：从生物进化的角度上来说，让 Agent 学会使用外部系统，要比直接把能力内化在 LLM 里更符合人类的认知规律和进化速度。毕竟，我们人类也是通过工具来大幅度地、迅速地扩展自己的能力的。

为什么说“记忆能力”和 Agent 通用能力是“相对正交”的

先澄清这里的“相对正交”不是指严格独立，而是指：在工程上可以把系统拆成两块“低耦合”的模块/参数块（System 1 的通用 Agent 能力 vs System 2 的记忆读写与检索），并且分别优化时不会经常出现大规模的互相干扰与能力退化。

从经验现象看：同一个 base model 在不做记忆特化训练时，接入不同的 RAG / 长期记忆策略就能显著改变长程任务表现；而同一套记忆 infra（raw_ledger + views + 检索策略）也往往能服务多种不同的 base model（可迁移、可插拔）。这种“跨模型可复用”通常意味着能力更多绑定在接口与外部状态上，而非某个特定模型权重上。

非正交的边界：检索噪声、错检、时序冲突会直接破坏推理（导致推理偏离并引发幻觉）；同时，何时检索/检索多少/何时写入更新等策略也依赖 Agent 的自我评估与规划能力。因此更准确的说法是“相对正交 + 存在可控交叉项”，而 System 2 的 observability / provenance / sandbox A/B 的意义就在于把交叉项显式化、可诊断、可迭代。

在平衡挑战和上限的前提下，System 2 是必须要的（不为空）。既然有 System 2，我们完全可能把记忆的更新和召回完全脱离 LLM（System 1）来看。那么接下来的问题是，如何用一套统一的建模理论来建模这个 System 2 呢？让我们回到 Agentic Memory (

AgeMem ​[1]​) 这个概念，它非常有启发性。Agentic Memory 本质上就是一个独立的系统，并且最核心且本质的是：拥有主动控制的回路。

至此，System 2 的构型大致想好了，我们绘制了下图：

有了 System 1 + System 2 的分工框架，接下来要回答的核心问题是：“非参数化的 System 2 能做到多好？”——这就引出参数化 vs 非参数化的讨论，以及非参数化方案的效果上限分析。

非参数化逼近参数化 Memory

参数化与非参数化：在线适应的两种载体

把“学到的东西”抽象成一个对输出分布有影响的对象，它有两种经典承载方式：

  • 参数化记忆（parametric memory） ：经验被写进模型权重。训练 / 微调就是把历史数据编译进权重的过程，推理时直接用更新后的模型，不需要额外检索。
  • 非参数化记忆（non-parametric memory） ：经验被写在外部状态里（ledger + views + skill pool + 索引结构）。写入由 policy 决定写哪些、怎么写；推理时通过检索、汇聚、注入等环节让外部状态影响输出。

两者的差别不在“有没有存储”，而在 适应算子写在哪里 。参数化把“写入成本”前置在训练阶段；非参数化把“写入成本”分摊到在线（commit）与推理（retrieve + inject）阶段。

前文讨论 System 2 的意义，其实就是：把在线适应的主战场从模型权重挪到外部记忆状态与控制策略上，并让它可观测、可回放、可 A/B。

记忆如何调制决策：修正项 Δ

如果把 LLM/Agent 的一步决策写成 logits（或 action distribution），最通用的“记忆影响决策”的表达方式是： 外部记忆对模型输出施加一个可控的修正项 Δ 。System 1 的权重提供基线能力（通用性），而 Δ 来自外部记忆，负责个性化、任务特化、时序修正、经验复用。

我们可以把一次决策写成一句很朴素的话：

新的动作倾向 = 模型原本的判断 + 记忆带来的修正 Δ

Δ 读作 Delta，这里只是一个“修正量”。可以把 Δ 看成“外置的可控偏置”——它不需要改模型权重，但能改变决策分布。比如小新明确说过讨厌青椒，点餐 Agent 就该把“青椒炒肉”往候选队伍末尾请；过去的部署记录显示某个命令会破坏数据，系统就该压低它的优先级。

这也解释了为什么我们前文强调 policy 的工具化：如果 Δ 的来源不可审计（比如隐式写在 prompt 里），那么系统无法做到 provenance / rollback / sandbox；而协议要求的正是把 Δ 的来源（命中证据、候选集合、写入动作）显式化。

JitRL[2] 与 UMEM[3]：外部经验怎样产生迁移

不重新训练模型，Agent 能不能在做决定时立刻用上过去的成败经验？有一类研究会在每步行动前检索相似轨迹，用过去的结果估计当前动作值不值得做，再调整动作优先级。任务结束后，新轨迹和结果继续写回经验库，JitRL 就是这条路线的代表工作。

RL 是 Reinforcement Learning，也就是强化学习。可以把它理解成“行动以后看结果，再调整下次选择”。这种方法不一定改模型参数，外部经验库也能参与调整，尝试逼近一次及时微调带来的变化。

仅仅找到一条相似案例还不够。今天记住“这个报错要检查连接池”，明天错误信息换了几个词，系统可能就认不出来。

更难的是让一次经验帮到一类问题。现在有研究会按语义相似度建立邻域，把意思接近的问题放到一起，再评估某条记忆对整个邻域带来了多少帮助。这样保存下来的不只是某道题的答案，还可能是一类故障的处理原则，UMEM 研究的正是这个问题。

“语义相似”指的是文字不同，意思仍然接近。向量检索常用一串数字表示这层意思，再计算两串数字之间的距离。读者不需要记公式，只要知道它让“数据库连不上”和“服务无法建立连接”有机会被当成近亲。

非参数化 Memory 的上限由什么决定

库里存一亿条记录，不代表 Agent 能在眼前这件事上用好一亿条。非参数化记忆要追赶的，是有效微调对决策产生的影响，不是硬盘容量。

1. 接口带宽（Memory → System 1 的注入容量）

无论是 passage、graph、skill，还是 tool using description，最终都要通过某种“Context Bridge”让 System 1 用上它。

最朴素的桥是“拼 prompt”，更激进的是 latent / KV 注入（后文整合层会展开），但不管哪种，带宽都有限：token 预算、注意力容量、或者注入的 KV 长度。

换言之，注入通道存在预算约束——你能往 System 1 塞进去的“可消费证据/表示”是有上限的，受限于 token 数、延迟、显存、注意力长度等。外部记忆再大也没用，真正起作用的是每一步你能注入多少“有效信息”。记忆固化/压缩、分层记忆、以及 latent token 的动机，本质都是在提高单位预算的信息密度。

2. 检索与聚合误差

views 是从 Raw Ledger 派生出来的近似结构——通过索引、固化、时序化、技能抽取等操作构建，再经由召回、重排、聚合、early stop 等环节产出最终的检索结果。

只要你不是直接把 ledger 全量塞进模型，views 就一定是近似。近似会带来错检、漏检、时序冲突、语义漂移，这些都会直接污染修正项 Δ（检索噪声会直接破坏推理）。因此，上限不仅取决于“存了多少”，更取决于 views 的误差是否被治理住：可观测、可溯源、可回放，才能迭代降低误差。

3. Policy 的学习与控制

决定读写是否靠谱。存太多会污染，存太少又学不到；召回太多挤占上下文，召回太少缺证据；错删一条长期偏好，后面的个性化会一路歪下去。

Memory Algorithm Protocol 把 policy 的输出强约束成 Action 序列，并且要求 UPDATE / DELETE 必须受候选集合约束、召回必须带 provenance。也就是说，控制策略接收当前输入、检索结果和记忆状态，输出一系列 Action，然后通过 Commit 把这些 Action 落盘。

非参数化 Memory 的真正“上限瓶颈”往往不是存储后端，而是 policy：

  • 写多了污染、写少了学不到；
  • 召回多了噪声、召回少了信息不够；
  • UPDATE / DELETE 做错一次，长期就会滚雪球。

所以 policy 必须既能学习（RL 训练范式），又能治理（protocol 的候选集合约束 + provenance 闭包 + sandbox 回放 A/B）。这也是为什么本文一直强调“rubrics based 的 policy 不可持续”，必须把控制回路显式化为可训练对象。

三、Memory 的核心模块设计

Memory System 控制层/策略层（policy）

首先，我们必须打破传统工程师的思想禁锢——rubrics based 的 policy，即，基于预定义的规则（rubrics）来控制记忆的读写更新。因此我们必须得用一个 model 来处理这件事。有两种方案：一，训练一个外部的神经网络；二，Prompt/SFT/RL 一个语言模型来做这个事。无论哪种方案，我们都要让这个 model 具备“记忆操作工具化”的能力，即，能够像控制手臂一样控制记忆的读写更新，而非被动接收上下文。

第一种方案的难度比较大，目前学术界也是探索为主，而且如果我们在面对任何参数化问题上，都选择训练一个外部的神经网络，那么我们就会陷入“每个问题都要找到正确的训练方法，并成功训练”的困境，显然这是不可持续的。（至少 GRPO 训练方法是大家公认的，要比自己重新训练一个神经网络要简单太多）

因此，我们尝试第二种方案。不妨提出 Agentic Memory 这个概念，它将记忆操作彻底工具化，整合进 Agent 的动作空间。这是逼近参数化上限的关键一步——让模型像控制手臂一样控制记忆，而非被动接收上下文。因此，这个步骤的参数就落在底层 LLM Agent 上了（让我来解释下这种偏好：因为我们还是更加相信 LLM 的泛化能力和迁移能力，并且 LLM 自身迭代速度也极快）。

记忆工具分类 具体操作 功能描述 对应参数化行为
长期记忆 (LTM) ADD 存储新知识 梯度更新 (Training)
长期记忆 (LTM) UPDATE 修正旧知识 权重调整 (Fine-tuning)
长期记忆 (LTM) DELETE 移除过时信息 灾难性遗忘管理 / 剪枝
短期记忆 (STM) RETRIEVE 语义搜索并注入 激活相关神经元
短期记忆 (STM) SUMMARY 压缩对话历史 抽象表征形成
短期记忆 (STM) FILTER 移除无关 Context 注意力机制 (Attention Masking)

以下，我列举一些 2026 年，新出现的参数化 Memory 工作：

AgeMem RL 训练

Agent 同时面对长期记忆和眼前上下文时，很难一上来就用好整套记忆工具。一种训练思路是把能力拆开来练，再逐步放进复杂任务，AgeMem 采用的就是这种分阶段强化学习。

第一阶段练长期记忆，Agent 在日常对话里判断什么值得新增，什么是在修正旧信息。第二阶段练短期管理，系统故意塞入干扰内容，让它学会过滤和摘要。第三阶段才把长期检索与短期整理放进复杂任务。

这个训练顺序很像新员工入职：先学会归档，再学会清桌面，最后才把人放进真实项目。第一天就让他同时接客户、管资料、写复盘、修线上故障，培训效果通常只剩一张疲惫的脸。

InfMem[4]：PreThink-Retrieve-Write 协议

除了工具化训练，System 2 中的主动控制回路还可以通过更精细的检索策略来实现。InfMem 这篇工作为了解决长文档推理中的“迷失中间”（Lost-in-the-Middle）问题，引入了 PreThink-Retrieve-Write 协议，显式模拟了慢思考过程，本质上是一种 policy 机制：

  • PreThink（预思考）：在检索前，Agent 先评估当前内部权重知识是否足以回答问题。这有效减少了不必要的外部检索，降低了延迟。
  • Adaptive Early Stopping（自适应早停）：传统 RAG 往往检索固定数量的块（Top-K），而 InfMem 训练了一个策略网络，当累积证据置信度达到阈值时立即停止检索。实验显示，这一机制将推理速度提升了 3.9 倍，极大地逼近了参数化模型的即时响应速度。
  • 训练范式（SFT-to-RL）：InfMem 通过从监督微调（SFT）过渡到强化学习（RL），直接优化检索和记忆更新决策，确保每一次外部交互都是为了最大化最终答案的准确率。

Policy 决定“写什么、读什么”，而“写什么”取决于记忆单元本身的结构与压缩方式。

接下来，我们讨论具体的记忆单元设计。

Memory 单元的结构、时序和压缩

现在，我们选择了 Agentic Memory 的设计，并且大致想好了 System 2 的构型，那么接下来，我们还需要考虑具体的记忆单元的结构、时序和压缩。

借鉴 SimpleMem [5] 的思路，它针对长期交互中的“语境通胀”（Context Inflation）问题，提出了一套模拟生物记忆固化（Consolidation）的机制。

SimpleMem 不存储原始文本，而是存储压缩后的“记忆单元”。它定义了记忆单元间的亲和力评分（Affinity Score）：

其中 是记忆单元的嵌入向量。

基于该评分，SimpleMem 会在后台异步执行递归固化（Recursive Consolidation），将高亲和力的记忆单元合并为更高层级的抽象表征。这个过程很像参数化模型训练中的“层级抽象”：通过多层结构把具体样本逐步提炼为更通用的特征表示，从而在不丢失关键信息的前提下显著提升存储效率。

实验表明，SimpleMem 在其报告的长时序多轮对话任务上，以约 的 Token 消耗击败了全量上下文模型，说明固化的效果还算不错。

参数化记忆的一个重大缺陷是“静态世界观”——一旦训练完成，权重就趋于固化，难以自然地表达随时间变化的事实。LLM 天生对于时间不敏感，这导致我们的生活世界和 Memory 想要承载的世界是有着同步化的问题。关于时序化这个方向，相关工作——Zep [6] 及其引擎 Graphiti [7] 引入了时序知识图谱（Temporal Knowledge Graph, TKG）来缓解这一问题。

具体来说，Zep 会对图谱中的边（Edge）加入时间标注（Temporal Validity）。例如“拜登是美国总统”不再是一个静态事实，而是带有一个有效时间窗口（如 ），用来区分“曾经为真”和“当前为真”。

在检索阶段，Zep 会结合查询的时间语境动态合成“当前时刻”的真值图谱。直观上，这让 Memory OS 能模拟参数化模型在经历“遗忘学习”（Unlearning）后的状态：能更精确地区分历史事实与当前事实；据称在其报告的长时序记忆评测上，相比传统 RAG 可提升 18.5% 的准确率。

上面的内容相对比较深，所以这里再多做一个容易被大家理解的小总结：

完整对话信息最全，也最占上下文；一句极短摘要很省地方，细节和来源可能一起被省掉。长期系统需要同时保留原始证据与高密度抽象。

交互时间越长，上下文就越容易膨胀。一种处理办法是把历史压成记忆单元，再根据语义亲和度，在后台递归合并相近内容，慢慢形成更高一层的抽象。SimpleMem 采用的就是这条路线。

可以把它想成照片整理。底层留着原片，上面有按旅行生成的相册，再往上可能是一份年度回顾。平时先看概览，需要确认“那天到底是谁说的”时，再回到底片。压缩不是越狠越好。摘要必须保留来源指针，系统才有机会在细节被压错时回去核对。

时序记忆（Temporal Memory）：从“发生过什么”到“何时为真、何时被相信”

“拜登是美国总统”这句话在 2024 年可能没什么问题，2026 年可能就不对了。语义相似度只知道两句话谈的是同一件事，不会自动判断哪条现在有效。

在 Memory OS 的三件套 (Raw Ledger, Views, Policy) 中，“时间”并不是附加字段，而是会改变三层的语义边界：

  • Raw Ledger ：append-only 记录“发生了什么写入动作”。加入时序后，Ledger 不仅要能回答“系统何时写入/更正”（transaction time），还要能表达“该事实在世界中何时为真”（valid time）。这两者不等价：你可以在今天纠正上周发生的事实。
  • Views ：检索不是“相关即可”，而是“在某个查询时间语境下成立”。没有时间切片（time slice），语义相似检索会把旧事实当作当前事实。
  • Policy ：默认 time_scope=current 意味着“宁可漏，不可错”。但这要求 policy 在需要历史时能显式触发 historical/all，并让 EvidencePack 承载“冲突并存”的证据结构，让 System 1 决策，而不是 Memory OS 私自裁决。

推演链条（为什么必须把时序提升到架构骨架层）：

  1. LLM 对时间天然不敏感（尤其是隐含时间、相对时间、跨时区）
  2. 纯语义检索会把“过去的高相似事实”错当成“现在仍为真”
  3. 决策层出现“过时事实复活”、以及“被纠正的事实仍反复召回”
  4. 解决方案不是更强 prompt，而是： 以 bi-temporal + time-sliced recall 把“何时为真”变成检索与聚合的硬约束，并让 policy 可控、可回放。

分层记忆：同一段历史需要不同抽象

一种存储形态，很难同时满足关系推理、经验迁移和证据核对。为了让三类任务各有合适的记忆形态，可以把记忆分成图记忆、经验记忆和片段记忆，MemWeaver [8] 就是这种分层思路的代表。

图记忆保存实体关系，适合回答谁和谁有关；经验记忆从多次交互中抽象处理模式，适合遇到类似问题时借鉴；片段记忆保留原文，负责核对和溯源。

这很像同一套项目资料同时有架构图、复盘笔记和会议原文。它们都来自同一段历史，却服务于不同问题。强行只留一种，阅读体验可能整齐，工作起来就没那么体面了。

到这里为止，我们讨论的“记忆单元”更多还是 Declarative Memory（事实/证据/关系）：能回答“是什么/发生过什么”。接下来，我们从“存什么”过渡到“存怎么做”——也就是程序性记忆。

程序性层（The Procedural Layer）：从“知识”到“技能”

事实记忆回答“是什么”和“发生过什么”，长程任务还需要“接下来怎么做”。

Agent 成功完成一次数据库迁移，如果只保存聊天片段，下次仍得重新规划、试错和验证。程序性记忆要保存的是可复用过程，像操作系统里的可执行文件：满足什么条件时启动，依次执行哪些动作，什么时候算结束。

现在已经有研究专门讨论，怎样让 Agent 从多次尝试中学出可复用技能，同时避免越改越离谱。技能可以用 Skill-MDP 描述，简单理解，就是明确什么时候启动、执行哪些动作、什么时候结束，ProcMEM [9] 就是这一方向的代表工作之一。

一项技能包含触发条件、动作序列和终止条件。系统先回看成功与失败轨迹，用自然语言分析技能哪里该改，这被称为语义梯度。模型参数不会因此改变，修改意见写在技能文本上。

候选技能不会写完就直接上岗。ProcMEM 用 PPO 风格的门控做反事实验证，检查新技能是否更偏向历史中的好动作，同时又没有偏离旧技能太远。PPO 是一种常见强化学习算法，这里借用的是它“每次改一点，别突然性情大变”的思想。

技能上线后还要看真实回报。长期没有贡献的技能退出，语义重复的技能合并，环境变化后太久没验证的技能重新试跑。收藏了一百份“高效工作法”不叫程序性记忆，能在合适时机执行，并用结果证明有效，才算技能。

Memory 整合层（The Integration Layer）：潜层融合与零样本对齐（Memory Tokens）

文本、图谱、时间边和技能最后都要送进大模型。最常见的办法，是把它们转成文字，拼到上下文里，再由模型重新编码。这个过程直观、可读，也会消耗 Token 和时间。

Memory Token 探索另一条路线。这里的 Token 可以理解成模型处理信息的基本单位；Memory Token 则希望把外部记忆压成更接近模型内部表示的形态，减少来回翻译。

LycheeMemory[10]：潜层压缩与 KV-Cache 注入

外部文本每次送进模型都要重新编码，会增加计算和显存开销。有研究训练压缩器，把内容变成潜层 Token，再以接近 KV-Cache 的形式注入注意力计算。LycheeMemory 探索的就是这种潜层压缩路线。

KV-Cache 是模型推理时保存中间计算结果的缓存，避免每生成一个字都从头计算。把记忆做成类似形态，有机会减少文本编解码。

代价也很直观：人越来越看不懂这段记忆。潜层表示如果影响了错误答案，系统必须能追到原始证据，否则排障人员面对的会是一串很有数学气质、但拒绝作证的数字。

MemAdapter[11]：异构记忆的对齐器

文本、图谱和技能各有自己的表示方式，同一个模型未必能直接读懂。一种思路是先从图谱中取出与问题相关的局部子图，再把结构化信息对齐到模型的语义空间，这样不用微调主模型也能融合异构记忆。MemAdapter 研究的就是这类零样本对齐方法。

Adapter 就是适配器，类似出国时带的转换插头。插得上只是第一步，电压是否匹配、接错后能否定位，同样重要。对齐层需要支持来源追踪、回滚和沙箱对比。沙箱指隔离出来的试验环境，可以让几种策略在不影响真实记忆的情况下跑同一批任务。

Memory Token 容易被忽略的控制与治理

潜层注入也没有取消注意力上限。系统仍要决定注入哪些内容、给多少预算、什么时候停。表示、对齐、选择、治理和溯源需要一起设计，单独追求压缩率，很容易把可读性压没了，问题还在。

Memory System 架构总结

不知不觉，我们就讲了很多很多……

很多时候我也是在写作的过程中，不断重塑我对 Memory System 的构想。整篇文章，我还是倾向于用“内核/文件系统/可执行文件”这种 linux 味道满满的笔触来写，因为我觉得一个好的系统最后应该能沉淀成一组 不绑定具体实现与细节 的抽象：它描述的是“我心里认为必须存在的模块与接口”，而不是“教别人怎么拼装某某方案”。

  • 内核（Kernel / Control Plane） ：System 2 的慢回路与调度器。它决定何时检索、检索多少、何时写入、何时更新、何时遗忘，并把这些决策显式化为可训练/可评估的策略（这类想法可参考 AgeMem、InfMem 的控制协议与训练范式，但抽象本身不依赖某一篇论文）。比如，其中一个子模块是规划器/路由器（Planner / Router）：可类比为内核里的 scheduler + syscall dispatcher，把一次输入/查询编译成一份可执行的读写计划（可理解为一串 Memory“系统调用”的调用序列），包括：查哪些 views、每个 view 取多少证据、是否需要闭环检索以及何时停止；以及哪些记忆单元（units）值得写入、写到哪类 view、UPDATE/DELETE 必须引用的候选集合约束。实现上它可以是 rule-based router，也可以是 LLM-as-planner 或 learned controller；但无论实现形态如何，都应当让决策可记录、可回放、可对比，避免“policy 只存在于描述里”。
  • 文件系统（File System / Storage Plane） ：以“权威记录（Raw Ledger，记忆原始数据/raw 账本）+ 派生视图（views）”为核心的数据层。底层需要承载时序一致性与冲突消解（事实在时间上何时为真），上层需要做语义压缩与分层固化（把大量事件/片段逐步抽象成更高层的表征），并且始终保留可溯源链路（这类方向可分别类比时序 KG 与递归固化/分层记忆）。
  • 可执行文件（Executable / Skill Plane） ：把经验固化成可执行、可复用的程序性单元（skill/macro/workflow），让系统复用“怎么做”，而不仅是复用“是什么”。关键不是技能形式本身，而是它必须满足可执行、可验证、可治理，才能长期演化且不发生系统性退化。
  • 总线接口（Interface / Context Bridge） ：记忆与推理之间的接口层。它负责把外部状态以尽量低开销、低失真、可控的方式注入到计算核心中，并支持可观测与溯源（部分工作用 latent token / memory token 作为桥接手段）。
  • 学习引擎（Learning Engine / Online Adaptation） ：在不必频繁更新权重的前提下，持续把交互反馈转化为可用的改进信号。它可以体现在推理端的优势调制、技能层的演化算子、检索策略的分块优化等。关键是让“学习”发生在外部状态与策略上，从而保持可插拔、可回滚、可 A/B 的工程属性（JitRL/优势调制是其中一种实现方式）。

四、上文回顾

回顾全文，从命题 A/B/C 出发，经过层层论证，我们最终可以得到以下核心结论：

  1. Memory 不是存储，而是闭环系统 ：它的本质是 Raw Ledger（权威记录）→ Views（可用能力）→ Policy（控制层）→ Commit（回写）→ Provenance（可回放）的完整闭环。三者缺一，系统要么不可治理，要么不可用，要么不可持续迭代。
  2. System 2 是必要的 ：记忆能力与 LLM 通用 Agent 能力相对正交，外置化的 System 2 在可插拔、可迁移、可归因方面带来大量工程好处，值得牺牲一定的理论上限。
  3. 非参数化 Memory 的上限由三类瓶颈决定 ：接口带宽（注入容量）、检索与聚合误差（views 近似）、以及 policy 的可学习性与可控性。其中 policy 往往是最被低估的瓶颈。
  4. 时序是架构的结构维度，而非 metadata ：bi-temporal + time-sliced recall 是区分“曾经为真”与“当前为真”的硬约束，不能交给 LLM 自洽猜测。
  5. 架构五件套 （内核/文件系统/可执行文件/总线接口/学习引擎）是不绑定具体实现的抽象，它描述的是“必须存在的模块与接口”，而不是“教别人怎么拼装某某方案”。

五、从架构构想到工程实现：PowerMem[12]

前面花了这么多篇幅讲账本、内核、文件系统和可执行文件，但理论真正有用的时候，是它能变成一套可运行、可接入、能持续积累的 AI Memory 系统。

一个开源项目 PowerMem（项目地址：https://github.com/oceanbase/powermem%EF%BC%89 可以看作这套 Memory OS 的开源工程落点。它面向 AI Agent 提供持久化、自演化的记忆能力，把对话、行动与反馈整理成长期可用的状态。前文那些看起来略有距离的抽象，在这里能找到具体位置。

会话结束了，状态还在

System 2 的第一件工作，是把长期状态从模型和单次会话里拿出来。PowerMem 提供持久化记忆、用户画像和作用域管理，让记忆可以按用户与 Agent 隔离，也能在需要时共享。

这意味着模型可以换、会话可以重开，用户偏好和任务进度不用陪着上下文一起下班。多 Agent 协作时，各自该记什么、能够看到什么，也有明确边界。

同一份历史，要有不同的查法

向量检索擅长找意思相近的内容，全文检索擅长名字和编号，图检索擅长关系，新近度信号负责提醒系统别忽略刚发生的变化。PowerMem 让这些方式参与混合检索，对应的正是前文 Views 的设计。

用户问“上次那个类似故障”，语义检索可以帮忙；用户问“订单 OB-20260716”，关键词更可靠；用户问“这个客户和哪个项目有关”，关系图更顺手。把所有问题都交给一种检索方式，像拿着一把螺丝刀装修整套房，认真是很认真，效率另说。

记忆库也得有人定期收拾

PowerMem 用大模型参与记忆抽取、更新和合并，并结合艾宾浩斯式时间衰减调整记忆优先级。艾宾浩斯遗忘曲线原本描述人类记忆随时间减弱，这里借用的是“越久未被使用，默认权重越低”的思路。

新地址可以更新旧地址，反复出现的稳定偏好可以获得更高权重，长期没有用过的零碎信息逐渐退到后排。记忆库由此不再是只进不出的聊天仓库，Policy 的生命周期管理开始真正工作。

时间衰减并不等于粗暴删除。明确过期、仍然有效、只是很久没用，是三种不同状态。前文谈到的有效期、撤回记录和软排序，仍然是理解长期治理的关键。

经验留下来，还要变成会做的事

PowerMem 提供 Experience + Skill 两层蒸馏。Experience 保存从交互中提炼出的经验，Skill 再把反复验证的经验整理成更可复用的做法。

这对应程序性记忆：Agent 除了知道“上次迁移成功了”，还要能留下当时的前置检查、执行步骤和验证方式。下一次面对相似任务，历史不只是几段可供怀旧的聊天记录，而能成为行动参考。

应用可以换，记忆不用反复搬家

Context Bridge 最怕每个应用都发明一种私有记忆格式。PowerMem 提供 Python SDK、HTTP 服务、MCP 和 CLI，让聊天助手、开发工具和 Agent 通过不同入口访问同一套后端。

MCP 是 Model Context Protocol，也就是模型上下文协议，用统一方式把工具和数据源提供给 Agent。CLI 则是命令行接口，方便开发者在终端调用。这些入口负责让不同应用稳定接上 Memory OS，记忆内容仍由后端统一管理。

先在电脑上跑起来，再考虑更大的场面

存储层也保留了伸缩空间。PowerMem 支持 OceanBase、嵌入式 seekdb、PostgreSQL 和 SQLite 等主流数据库。本地实验可以从轻量后端开始，长期服务再选择更适合持续运行的数据库，Memory OS 上层的抽象不用跟着全部推倒重来。

一个长期运行的 Agent，可以顺着几个问题检查自己的记忆系统：会话结束后状态还在不在；历史是否只有向量这一种查法；旧事实能否更新，低价值内容会不会退场；成功经验能否沉淀成技能；多个应用能不能共用同一套记忆底座；本地原型走向长期服务时，存储是否留有余地。

PowerMem 已经把这些关键能力放进一套开源系统。它适合用来搭建长期助手、个性化应用、Copilot 和多 Agent 工作流，也适合作为理解 Memory OS 的一份可运行样本。读完前面的理论再看它，会更容易明白每个模块为什么存在；先把系统跑起来再回看理论，也能看到这些抽象都来自长期运行后迟早会遇到的真实问题。

写在最后

AI Memory 系统的下一步演进仍然值得期待：更细的 Ledger 回放与来源追踪，更自然的双时态查询，能从真实反馈中持续调整的 Policy，以及更高效的潜层记忆注入。

方向变得更远，但是内核、文件系统、技能平面、总线与学习引擎这套骨架仍然适用。

如果大家想继续看工程细节，可以从

PowerMem GitHub 仓库 [13] 和它的 PowerMem 架构说明 [14] 开始。一个 Agent 真正记住你，靠的不会是一句“请记住以上内容”，而是背后这套持续工作的系统。

参考资料

[1]

AgeMem: https://arxiv.org/abs/2601.01885

[2]

JitRL: https://arxiv.org/abs/2601.18510

[3]

UMEM: https://arxiv.org/abs/2602.10652

[4]

InfMem: https://arxiv.org/abs/2602.02704

[5]

SimpleMem: https://arxiv.org/abs/2601.02553

[6]

Zep: https://arxiv.org/abs/2501.13956

[7]

Graphiti: https://github.com/getzep/graphiti

[8]

MemWeaver: https://arxiv.org/abs/2601.18204

[9]

ProcMEM: https://arxiv.org/abs/2602.01869

[10]

LycheeMemory: https://arxiv.org/abs/2602.08382

[11]

MemAdapter: https://arxiv.org/abs/2602.08369

[12]

PowerMem: https://github.com/oceanbase/powermem

[13]

PowerMem GitHub 仓库: https://github.com/oceanbase/powermem

[14]

PowerMem 架构说明: https://github.com/oceanbase/powermem/blob/main/docs/architecture/overview.md

文末福利环节

今天阿里云百炼为我们 DataWhale x OceanBase 联合开发的《Easy Data x AI》课程 https://github.com/datawhalechina/easy-data-x-ai 的社区共建和实验内容，提供了专属的模型算力福利（这篇公众号文章，就出自该课程的社区共建章节）~

社区课程学习者和共建者，均可通过阿里云百炼 × OceanBase 专属福利页面 https://opc.aliyun.com/oceanbase?utm\_content=g\_1000415375 领取模型算力支持，可获得 1 亿 Token 的免费额度（实测新、老用户均可获得）。

除此以外，百炼新老用户及个人、企业均可参与无门槛 Token 满返补贴；还有最高 100 万元等额 Token 的 OPC 创新助力，以及高校学生模型通兑补贴等课程共建、学习的专属福利。这些权益和福利将为本课程的共建和实验实践提供专属模型算力支持，欢迎大家领取百炼的模型算力福利，积极参与课程的学习和共建~

课程链接：https://github.com/datawhalechina/easy-data-x-ai

福利链接：https://opc.aliyun.com/oceanbase?utm\_content=g\_1000415375

往期内容推荐

了解更多

添加社区小助手，加入微信交流群~

AI 技术 · 目录

作者提示: 个人观点，仅供参考

阅读原文

posted on 2026-07-27 16:00  老纪的技术唠嗑局  阅读(21)  评论(0)    收藏  举报