「纯干货」几万字都讲不明白的Memory架构与思考
「纯干货」几万字都讲不明白的Memory架构与思考
来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, 记忆系统, 办公效率, 网络安全, 编程, 大模型
原文链接： https://mp.weixin.qq.com/s/bl77_Mb85C4AKe8h4__V6Q
摘要
阿里妹导读 本文讲述作者对 Memory 的一些理解与思考。（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。） Memory 的本质 本文所讲的 Memory：指 Agent 在长期交互中积累、可被检索与利用的记录/知识/经验库。它直接影响个性化、持续学习能力与长程任务表现。一个经验判断是：仅解决垂直问题的模型，其价值更依赖赛道规模；具备用户级个性化记忆的模型，其价值更强绑定于单用户价值。 Memory，是所有互联网公司都不愿意丢失的资产之一，就像BAT不愿意舍弃各种数据一样。 本文会涉及到一些最近一年内的Memory论文（甚至几乎都是 202...
核心内容
阿里妹导读
本文讲述作者对 Memory 的一些理解与思考。（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）
Memory 的本质
本文所讲的 Memory：指 Agent 在长期交互中积累、可被检索与利用的记录/知识/经验库。它直接影响个性化、持续学习能力与长程任务表现。一个经验判断是：仅解决垂直问题的模型，其价值更依赖赛道规模；具备用户级个性化记忆的模型，其价值更强绑定于单用户价值。
Memory，是所有互联网公司都不愿意丢失的资产之一，就像BAT不愿意舍弃各种数据一样。
本文会涉及到一些最近一年内的Memory论文（甚至几乎都是 2026 年初的新鲜文章）。未经过同行检验，因此，论文仅供参考。
无AI撰写、润色。
经过一层又一层的思考，我直接给出结论吧，Memory的抽象是：event 序列 / Raw Ledger + views / policy 层。那么我是如何推导和（不严谨）论证出来的呢？——通过提出下面的问题：
「记忆的本质是什么？」
我们能否通过更明确的逻辑推导得到合理的系统形态？我倾向于：长期来看参数化 Memory 的潜在上限更高，但在当前工程条件与资源约束下，非参数化 Memory 更易落地。但是，我觉得我们可以思考一下，如何设计非参数化 Memory，使其尽可能逼近参数化方案的效果上限。
在调研了多种记忆机制（logit 调制、工具化与 RL 训练、记忆固化、技能化、以及协议层的对象模型与闭环）之后，我认为"Memory 的本质"至少应该落到一组更硬的命题上，否则后面所有机制会变成散点。
文章读一遍是嚼不烂的。等你看完这篇文章，再回首探索Memory的本质（尤其是我以下提出的几个命题），或许你会有新的收获。
关于Memory的本质，我提出了以下三个核心命题：
核心命题：Memory 在 Agent 系统里到底"是什么"
命题 A：Memory 不是"存储"，而是可被决策利用的外部状态（external state）
如果把 Agent 看成一个从输入到输出的函数，仅仅"存了很多历史"并不构成能力；能力来自：在当前状态下，历史能否以某种形式影响决策分布。
记忆系统负责从历史中提取当前可用的信息（证据、摘要、子图、可执行技能等），并把它提供给推理层，共同产生决策。Memory 的价值不在于"存了多少历史"，而在于这条从历史到当前决策的通道是否有效。Memory 不等于历史本身，而是"把历史转成当前可用信息"的通道——它的输出要么进入上下文（证据/摘要/子图），要么直接参与决策（例如对输出分布做调制）。
命题 B：Memory 的最小闭包不是"文档块"，而是 (Ledger, Views, Policy) 三件套
只要系统要满足可溯源（provenance）、可回滚、可观测这些硬约束，那么 Memory 的最小形态就不可能是"一个向量库 + 若干 prompt"。它必须是一个能被审计的状态机：
1. Raw Ledger（权威记录）：追加式记录每次写入/更新/删除发生了什么（以及当时的输入、时间、scope 等）。2. Derived Views（派生视图）：面向检索/推理的派生状态（向量索引、keyword/hybrid、KG/TKG（时序知识图谱, Temporal Knowledge Graph）、timeline、skill index 等）。views 可以多、可以 lossy，但必须可回指到 Raw Ledger。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/rollback/replay 无从谈起。2. 单一 event 流不可用：因为推理需要高密度信息、需要索引、需要时序化、需要技能化；这些都要求 views。3. views 不可能"自洽地产生"：它们是派生状态，派生就意味着近似与冲突；因此必须有 policy 来决定写入/更新/检索/淘汰，并且决策过程必须被记录下来，否则系统不可治理、不可 A/B。4. 因此，Memory 的本质不是一个组件，而是一个闭环系统：Raw Ledger（权威）→ Views（可用）→ Policy（控制）→ Commit（回写）→ Provenance（可回放）。
命题 B 提出了 (Ledger, Views, Policy) 三件套，自然引出下一个问题：这个系统应该怎么组织？记忆系统和推理系统之间如何分工？——这就是 System 1 + System 2 的设计。
System 1 + System 2 的设计
这里说明为什么需要显式的 System 2：如果 System 2 不发挥作用，那么记忆能力只能通过 RL post-training 等方式固化到
...(内容截断，完整内容请查看原文)
本页由自动化脚本生成，待人工审核补充