---
title: Agent Memory 架构本质
source_url: https://mp.weixin.qq.com/s/aBWunszbTVjI4bdguLIOvg
publish_date: 2026-04-27
tags: [wechat, article, agent, rag]
review_value: 7
review_confidence: 7
review_recommendation: neutral
sha256: 42790ade7f7d3265676fa439ee18b66f02c174546c4ec2ee68955fa38d381673
---
# Agent Memory 架构本质
> 来源：lencx/浮之静，2026年4月15日，上海
## 瓶颈在持续理解
今天的大模型在单次会话里已经足够聪明。问题不在于它一时想不出来，而在于它没法把昨天学到的东西，以一种可靠、可更新、可追责的方式带到今天。
**Context window 扩展解决的是带宽问题，不是建模问题。** benchmark 已经证实：拉到 35 个 session、300 个 turn 的尺度上，长上下文和 RAG 在时间推理、长程一致性上仍然明显落后于人类。
所以 memory 正在从附加功能变成 Agent 架构的核心子系统——一个完整的 **write–manage–read 闭环**，而不是"有个存储层就算有记忆"。
## 先划边界：Memory vs State / Policy / Profile
**Memory vs State：** State 是当前 session 内的短期运行态（对话上下文、工具中间结果、规划器当前步骤），Session 结束即销毁。Memory 是跨 session 持续存在的、可影响未来决策的结构化历史。
**Memory vs Policy：** Policy 管的是"允许与禁止"——权限边界、安全规则、合规约束。它是系统的外部规范，通常不应该被 memory 系统动态修改。
**Memory vs Profile：** Profile 是用户模型的低维、显式快照层（名字、角色、偏好标签）。它是记忆的一个输出产物，不是记忆本身。
> **一句话定义：** Memory 保存的是可跨时延续并影响未来决策的结构化历史——带来源、作用域、时间权重和可修正性的历史对象，而不是"把聊天记录再存一份"。
## 蒸馏是管道的一步，不是记忆本身
很多人把"蒸馏"和"记忆"混用。摘要、reflection、session summary——这些是 memory pipeline 里**管理环节**的一个操作，而不是 memory 本身。就像压缩是通信系统的一步，但你不会说"压缩 = 通信"。
**蒸馏的局限：** 一条摘要能写下"用户偏好 TypeScript"，却很难保留这条偏好是如何形成的、在什么上下文下成立、最近是否正在漂移。蒸馏擅长留下结论，不擅长留下形成结论的轨迹。
> "蒸馏试图把过去变成一句话，记忆试图把过去变成一个还能继续更新的模型。"
如果一个系统做完摘要就停了，没有后续的冲突检测、信念衰减、回溯修正，那它不是在做记忆，只是在做归档。
## 四个建模对象
面向工程实现，记忆的建模对象分成四类（不是只有"用户偏好"一个维度）：
| 模型 | 覆盖内容 | 示例 |
|------|---------|------|
| **用户模型** | 偏好、风险偏好、沟通习惯、决策模式 | 用户从"抵触TypeScript"到"主动要求重写"的转变轨迹 |
| **任务模型** | 被否决的方案、已确认的结论、当前真版本、未完成的承诺 | 事情推进到了哪一步 |
| **世界模型** | 操作环境：仓库结构、API约束、系统边界、组织规则、数据新鲜度 | 大量"个性化错误"本质是没注意到环境已变化 |
| **自我模型** | 试过什么、哪条路径失败、哪个工具在什么场景下不稳定、暂定假设 | Agent 不是在学习，只是在重复犯错 |
**意图**不是被单独存在某个字段里的东西。它是这四层模型长期耦合后浮现出来的上层能力——就像跟了三年的助理"懂你"，不是因为背了一本偏好手册，而是同时理解你的脾气、项目进度、组织环境和他自己的能力边界。
## 基本记忆单元：六维度
若把记忆做成可计算对象，至少需要六个维度：
| 维度 | 含义 | 适用类型 |
|------|------|---------|
| **内容** | 这条记忆说了什么 | 全部 |
| **类型** | event / assertion / belief / constraint / commitment | 全部 |
| **置信度** | Agent 对这条记忆有多确信 | belief, commitment |
| **来源** | 用户表达/行为推断/环境观察/Agent生成 | 全部 |
| **作用域** | 它在什么上下文下成立 | 全部 |
| **时间与衰减** | 产生时间、上次确认时间、衰减权重 | 全部 |
**类型详解：**
- **event**：发生了什么（高确定性事实）
- **assertion**：用户明确声明了什么（可直接推翻）
- **belief**：Agent 推断出来的（需通过新证据逐步修正）
- **constraint**：不可违反的边界（权威来源通常不在 memory 子系统内部，memory 可记录但不应定义或修改）
- **commitment**：Agent 做出但尚未完成的承诺
## 三条链路：写入、管理、读取
记忆系统不是容器，而是 **write–manage–read** 三条链路的闭环。
### 写入：预算分配
记忆写入本质是 **decision under budget**。存储预算有限，检索预算有限，未来注意力更有限——写入要决定的是：哪些信息值得获得对未来决策的影响力。
关键洞察：
- 不能只看"这条信息有没有价值"，要看它相对于已有记忆的**边际价值**
- 与已有信念冲突的新信号（如一直保守的用户突然要求尝试 alpha）= 高价值信号，值得优先写入
- **行为证据通常比口头表态更值得写入预算**——"用户说过不喜欢ORM"是 assertion；连续三次提供ORM方案后又手写SQL是可以提炼为belief的行为模式，且后者 provenance 更硬
### 管理：最容易偷懒也最关键
管理链路至少处理五件事：
1. **整合**：把碎片信号聚合成结构化信念（蒸馏在这里发挥价值，但只是手段之一）
2. **冲突处理**："以最新为准"是偷懒的蒸馏思维。更合理的做法是保留矛盾，建模为"此维度上的偏好是情境依赖的"，在读取时根据当前情境选择
3. **衰减与遗忘**：不能忘的系统会被旧判断拖死。遗忘不是 bug，是防止过拟合现实的必要机制
4. **来源追踪**：没有 provenance，Agent 无法判断自己的信念有多可信，也无法在出错时回溯责任链
5. **权限治理**：用户必须能查看、编辑、删除 Agent 的记忆
### 读取：任务约束优先
**传统做法：** RAG 式的语义相似度召回（假设相关性由表面语义决定）
**局限：** 真正有价值的记忆调用往往是反直觉的——用户问"帮我写缓存方案"，最相关的记忆可能不是上次讨论缓存的对话，而是三个月前提到的黑五流量问题（那条信息决定了设计约束，但在语义空间里跟"缓存"距离很远）
**升级方向：** 从语义相似召回，升级为**任务约束驱动的检索-推断耦合**：
- 先由任务理解层判断"当前决策真正受什么约束"
- 再由检索层去找对应记忆
- 最后评估这些记忆在当前情境下的适用性
接口上：从 `retrieve(query)` 到 `read(task_context, belief_graph)` 的转变。
## 进化 = 修正 + 遗忘
### 自我修正
当 Agent 基于记忆做出了用户不满意的响应，这个负反馈应该**回溯到记忆层**判断问题在哪一层：
- 是检索召回错了？
- 是某条 belief 过期了？
- 是 belief 没错但被错误应用到了当前 scope？
只在回答层修补，却不修正上游假设 = 没有在学习，只是在打补丁。
### 有策略的遗忘
什么该忘？
- 被后续信号反复否定的旧 belief
- 高度情境依赖且低泛化的细节
- 已被更高层抽象吸收的底层 event
**更深的洞察：** 死的不是经验本身，而是那些失去了更新机制的经验。Few-shot 示例、摘要、fine-tuned preference profile——它们并不天然低级。真正的问题是，一旦脱离了持续校正闭环，就从资产变成了惯性。
## 落地判断
每一步的核心问题都是同一个：**谁被允许持续影响未来。**
- 写入：决定什么信息获得对未来的影响力
- 管理：决定什么信念继续保持有效
- 读取：决定什么记忆真正进入当下决策
- 遗忘：决定什么经验退出舞台
这四个动作，没有一个是容量问题，**全都是治理问题**。
**评测也在转向：** 从"能不能 recall" 到"能不能 update、能不能 abstain、能不能 handle drift、能不能 selective forget"。Memory 的难点从来不在容量，在治理。