Agent Memory 架构本质¶

Ch04.146 Agent Memory 架构本质¶

📊 Level ⭐⭐ | 13.0KB | entities/agent-memory-architecture.md

Overview¶

Agent Memory 不是"把聊天记录存起来"，而是一个完整的 write–manage–read 闭环，决定什么信息被允许持续影响未来决策。核心问题不是容量，而是治理——谁被允许持续影响未来。

核心命题¶

Context window 扩展解决的是带宽问题，不是建模问题。 benchmark 已证实：拉到 35 session、300 turn 的尺度，长上下文和 RAG 在时间推理、长程一致性上仍明显落后于人类。Memory 正在从附加功能变成 Agent 架构的核心子系统。

边界划定¶

概念	职责	与 Memory 的区别
State	当前 session 内的短期运行态	短期，Session 结束即销毁
Policy	权限边界、安全规则、合规约束	外部规范，Memory 系统不应动态修改
Profile	用户模型的低维快照（偏好标签）	Memory 的输出产物，不是 Memory 本身
Memory 定义：保存可跨时延续并影响未来决策的结构化历史——带来源、作用域、时间权重和可修正性的历史对象。

蒸馏 ≠ 记忆¶

	蒸馏	记忆
目标	把过去变成一句话	把过去变成一个还能继续更新的模型
擅长	留下结论	保留形成结论的轨迹
局限	偏向静态结论，无更新机制	需要完整的治理闭环
一个系统做完摘要就停了 = 没有在做记忆，只是在做归档。

四类建模对象¶

Agent Memory 需要同时建模四个维度： 1. 用户模型 — 偏好、风险偏好、沟通习惯、决策模式 2. 任务模型 — 被否决的方案、已确认结论、当前真版本、未完成的承诺 3. 世界模型 — 操作环境（仓库结构、API约束、系统边界、组织规则、数据新鲜度） 4. 自我模型 — 试过什么、哪条路径失败、哪个工具在什么场景下不稳定意图是这四层长期耦合后浮现的上层能力，不是单独存储的字段。

基本记忆单元：六维度¶

维度	含义	适用类型
内容	这条记忆说了什么	全部
类型	event / assertion / belief / constraint / commitment	全部
置信度	Agent 对这条记忆有多确信	belief, commitment
来源	用户表达/行为推断/环境观察/Agent生成	全部
作用域	它在什么上下文下成立	全部
时间与衰减	产生时间、上次确认时间、衰减权重	全部

三条链路¶

写入 = 预算分配¶

写入不是"有价值就存"，而是 decision under budget。关键洞察：

看边际价值而非绝对价值——已有高置信信念时，同一信号第四次出现的边际价值远低于第一次
冲突信号（如保守用户突然要求尝试新框架）= 高价值信号，值得优先写入
行为证据 provenance 更硬——连续三次手写SQL比一次口头说"不喜欢ORM"更值得写入

管理 = 防止垃圾堆化¶

五件事： 1. 整合 — 碎片信号聚合成结构化信念 2. 冲突处理 — 保留矛盾，建模为"情境依赖的偏好"，读取时按情境选择 3. 衰减与遗忘 — 防止旧判断锁死现实 4. 来源追踪 — provenance 是信任基础 5. 权限治理 — 用户必须能查看/编辑/删除记忆

读取 = 任务约束驱动¶

传统 RAG 式语义相似度召回的局限：最相关的记忆往往语义距离远（如"缓存方案"Query ↔ 黑五流量讨论）。升级为检索-推断耦合：

retrieve(query) → read(task_context, belief_graph)

进化 = 修正 + 遗忘¶

自我修正¶

负反馈必须回溯到记忆层判断问题在哪：

检索召回错了？
belief 过期了？
belief 没错但被错误应用到了当前 scope？只在回答层修补 = 打补丁，不是学习。

有策略的遗忘¶

什么该忘：

被后续信号反复否定的旧 belief
高度情境依赖且低泛化的细节
已被更高层抽象吸收的底层 event 洞察： 死的不是经验本身，而是那些失去了更新机制的经验。

与 Hermes Agent Deep Dive 的关系¶

Hermes Agent 深度解析中提到的 Self-Evolving / 动态 Skill 沉淀 与 Memory 系统的"修正 + 遗忘"机制有协同：Agent 的自我进化依赖于 Memory 子系统的有效治理。

深度分析¶

从信息论视角看 Memory 治理¶

Memory 本质是一套注意力预算分配机制。Context window 是带宽，Memory 是决策——决定在有限的认知预算下，哪些信息值得获得持续影响未来的资格。这一洞察将 Memory 从"存储层"提升到"治理层"：写入不是采集，是授权；管理不是清理，是审计；读取不是检索，是情境匹配。

四模型耦合与意图涌现¶

用户模型、任务模型、世界模型、自我模型并非独立存在，而是通过持续交互形成耦合效应。意图作为这一耦合的上层涌现，并非单独存储的字段，而是四层模型在特定上下文下同时激活时自然浮现的判断。这一机制解释了为什么 Few-shot 示例无法替代真实记忆：示例提供的是静态激活，而非动态耦合。

写入的边际价值计算¶

记忆写入的核心问题不是"这条信息有没有价值"，而是"这条信息相对于已有信念的边际价值是什么"。这一思路直接受益于信息论中的边际效用递减原理：当某一信念已处于高置信状态时，同源信号第四次出现的边际价值远低于第一次。冲突信号因此成为最高价值的写入目标——它直接挑战现有信念体系，强制系统进行整合或修正。

检索-推断耦合的工程含义¶

从 retrieve(query) 到 read(task_context, belief_graph) 的转变，意味着检索层需要同时承担推断职责。语义相似度不再是主要度量维度，上下文适用性成为新的核心指标。这一转变对向量数据库的使用方式提出了根本性质疑：embeddings 擅长捕捉语义距离，但不擅长捕捉功能依赖——而后者才是 Memory 调用中真正决定质量的维度。

遗忘作为系统健康指标¶

有策略的遗忘不是退化，而是系统保持可塑性的必要机制。当旧信念在无新证据支持下持续强化，系统实质上是在对过去过拟合。有策略的遗忘使得系统能够持续校准，避免被历史判断锁死现实。

实践启示¶

设计原则¶

Memory 系统从第一天起就是治理系统：不要先建存储再补治理，治理逻辑应该嵌入写入决策的每个分支
边际价值优先于绝对价值：写入评估应引入已有信念置信度作为分母，而非孤立判断信息价值
保留冲突而非强制消解：冲突是高价值信号，消解会丧失上下文完整性
来源追踪是信任的基础：每一 belief 必须携带 provenance 信息，否则无法支撑修正决策

实现的五个关键模块¶

写入过滤器（Write Filter）：在写入前计算边际价值，过滤低价值信号，优先处理冲突信号
信念图谱（Belief Graph）：建模 belief 之间的依赖关系和冲突关系，而非仅存储独立条目
情境选择器（Context Selector）：读取时根据任务上下文从冲突记忆中动态选择，而非固定优先级
衰减引擎（Decay Engine）：基于时间、确认频率和覆盖关系计算衰减权重，触发遗忘
权限界面（Permission UI）：用户查看/编辑/删除记忆的入口，是信任建立的必要条件

评测指标转型¶

传统 Memory 评测聚焦 Recall / Precision / F1，新一代评测应关注：

Update Rate：系统能否在新信号出现后及时修正信念
Abstain Rate：系统能否识别当前上下文超出记忆适用范围并主动放弃调用
Drift Detection：系统能否检测信念漂移并触发重新评估
Selective Forget Accuracy：遗忘决策的准确率，而非遗忘行为本身

与现有系统的整合¶

Memory 不是独立系统，它需要与 Policy（权限边界）、State（当前会话上下文）、Profile（用户快照）形成清晰的分界与联动。推荐的整合模式：

Policy → 定义不可逾越的边界（Memory 只读不写）
State  → 当前会话数据源（Memory 从中抽取有价值信号）
Profile → Memory 的输出产物之一（而非 Memory 本身）
Memory → 持续治理层，支撑 Profile 更新、State 补充、Policy 理解

Perplexity Brain：产品级 Work Memory 实现（2026-06）¶

Perplexity 推出 Brain 系统，是首个公开的产品级 self-improving agent memory 实现。核心创新：

Work Memory vs User Memory：传统 AI memory 记录用户偏好（tastes/contacts/role），Brain 记录agent 做了什么（what worked, what failed, what corrections were made）。这是从"记住你是谁"到"记住我做了什么"的范式转换。
Context Graph：Brain 构建工作的上下文图谱，而非简单的 key-value 存储。
Overnight Self-improvement：定期（如过夜）回顾 context graph，自动优化未来任务的起点。

与本 entity 的关系：Brain 是"write–manage–read 闭环"的产品化实例——write 阶段记录工作上下文，manage 阶段构建 context graph，read 阶段在新任务起点注入经验。