2.2 Memory 记忆模块定位：在架构中的位置与读写时序

2.2 Memory 记忆模块定位：在架构中的位置与读写时序

如果说 Profile 决定 Agent「像谁」，那 Memory 决定 Agent「知道什么」。一个没有记忆的 Agent 是金鱼——每轮从零开始，连上一句说了什么都忘了。Memory 模块的任务，就是给 LLM 这个「无状态的函数」外挂一层状态，让它在主循环的每一轮里都能读到该读的、写下该写的。

2.2.1 Memory 在架构中的位置

回到第 1.2 节的核心循环「感知-规划-行动-观察」，Memory 出现在其中三个环节：

注意一个关键点：Memory 既是「输入」也是「输出」。每一轮循环，Memory 先被读取（提供上下文），再被写入（沉淀本轮观察）。这个「读-用-写」的闭环，是 Agent 能跨轮次积累信息的根本机制。

💡 Memory 与上下文窗口的关系：很多人把「上下文窗口」当记忆，这是误解。上下文窗口只是 LLM 单次调用能「看见」的文本长度，本身不持久化——调用结束就消失。Memory 才是持久化的存储；上下文窗口只是 Memory 中「短期记忆」的载体。两者的关系是「Memory 是仓库，上下文窗口是工作台」。

2.2.2 短期记忆与长期记忆：功能边界

Memory 分两层，功能边界清晰：

┌──────────────────────────────────────────────────┐
│  短期记忆 (Short-Term / Working Memory)           │
│  ──────────────────────────────────────           │
│  内容: 当前对话、最近 N 步观察与行动              │
│  载体: LLM 上下文窗口                             │
│  容量: Token 有限(几K~几百K)                      │
│  速度: 极快(已在上下文里)                         │
│  持久性: 调用结束即消失                           │
│  作用: 支撑当前任务的即时推理                     │
└──────────────────────────────────────────────────┘
                       ↑ 溢出/检索
┌──────────────────────────────────────────────────┐
│  长期记忆 (Long-Term Memory)                      │
│  ──────────────────────────────────────          │
│  内容: 历史对话、用户偏好、事实知识、过往经验     │
│  载体: 向量数据库 / 知识图谱 / 文档库             │
│  容量: 近似无限                                   │
│  速度: 慢(需检索)                                 │
│  持久性: 跨会话持久                               │
│  作用: 跨任务/跨会话的经验积累                    │
└──────────────────────────────────────────────────┘
​

⚠️ 一个常被忽略的事实：短期记忆不是「免费」的。上下文越长，LLM 推理越慢、成本越高，且注意力会被稀释（这正是 2.1 节 Profile 漂移的成因之一）。把所有历史都塞进短期记忆，既贵又损害质量。优秀的 Memory 设计,核心是「该留在短期的不外迁,该外迁的及时外迁」。

2.2.3 读写时序：Memory 在一轮循环里的完整动作

把 Memory 在一轮循环里的动作展开，可以看到 5 个关键操作：

5 个操作的职责：

💡 关键设计点：⑤b 不是每轮都做。把每一步观察都写进长期记忆，会让向量库膨胀且充满噪声。生产实践通常只在「任务里程碑、用户偏好变化、关键事实更新」时才触发长期写入。写什么、何时写，是 Memory 设计的核心策略问题——第 5.4 节会专门讨论。

2.2.4 记忆的内容类型

无论短期还是长期，Memory 里存的内容可以按「信息类型」进一步分类：

这六类内容对应《具身智能技术原理》第 4.3 节提到的「工作记忆、情节记忆、语义记忆、程序记忆」四层架构——本教程聚焦软件 Agent，简化为「短期 + 长期两层 + 六类内容」的实用模型。第 5 章会进一步讨论每类内容的写入与检索策略。

⚠️ 不要把所有信息都当成同一种记忆。对话历史和用户偏好的生命周期、检索方式、更新策略完全不同。把它们混在一个存储里管理，会让 Memory 系统既慢又乱。好的 Memory 设计会按内容类型分库分表。

2.2.5 Memory 的三个核心问题

把 Memory 模块抽象出来，它要回答三个工程问题——这三个问题贯穿第 5 章的所有讨论：

问题一：写什么（Write Policy）

不是所有观察都值得记。写得太少，Agent 失去经验；写得太多，记忆库膨胀且充满噪声。

问题二：检索什么（Retrieval Policy）

记忆库再大，LLM 一次只能看有限的内容。检索的目标是「把当前最相关的少数记忆送进上下文」。

这四个维度的加权组合，构成了 Generative Agents（斯坦福小镇）等工作中经典的「相似度 × 时效性 × 重要性」检索评分公式。第 5.4 节会展开。

问题三：何时遗忘（Forgetting Policy）

记忆无限增长会让检索变慢、成本变高、噪声变多。主动遗忘是 Memory 系统的健康指标。

💡 遗忘不是缺陷,是特性。人类大脑的遗忘机制是认知效率的关键；Agent 也一样——一个什么都记的系统,反而比一个懂得遗忘的系统决策更差。第 5.4 节会详细讨论遗忘的设计。

2.2.6 Memory 设计的三种典型架构

不同复杂度的 Agent 采用不同的 Memory 架构。这里给三种典型形态，从简到繁：

架构一：纯短期记忆（最小 Agent）

只有上下文窗口，无长期记忆。每轮把历史拼接进 Prompt。

• 优点：实现极简，无外部依赖。
• 缺点：上下文一满就丢历史；跨会话完全失忆。
• 适用：单轮任务、短对话、原型验证。

架构二：短期 + 长期 RAG（主流生产形态）

短期记忆管当前任务，长期记忆用向量数据库 + RAG 检索。

• 优点：跨会话有记忆，能积累经验。
• 缺点：检索质量决定一切；写入策略需调优。
• 适用：绝大多数生产级 Agent。

架构三：多层记忆（复杂长程任务）

在架构二基础上，把长期记忆再细分为「对话归档、用户画像、事实知识、经验反思」多个子库，各自检索策略。

• 优点：精细化管理，支持长程复杂任务。
• 缺点：工程复杂度高，维护成本大。
• 适用：长程自动化、个人助理类高价值场景。

⚠️ 架构选型建议：不要一上来就上架构三。先用架构一验证任务可行性，用架构二覆盖 80% 的生产场景，只在确有长程需求时才升级到架构三。过度工程化是 Memory 设计最常见的坑——很多团队上了架构三，结果发现 90% 的检索都走短期记忆，长期记忆库基本闲置。

2.2.7 Memory 与其他模块的耦合

Memory 不是孤岛，它与另外三个模块都有耦合点，理解这些耦合对设计 Agent 至关重要：

最关键的耦合是 Memory ↔ Planning：Memory 提供「已知什么」，Planning 决定「还要查什么」。一个成熟的 Agent，Planning 模块应当能主动发起检索请求——「我需要用户的历史订单数据」——而不是被动地等 Memory 喂什么就用什么。这种「主动检索」是高级 Agent 的标志，第 5 章 RAG 部分会展开。

2.2.8 Memory 设计的反模式

最后列出 Memory 设计的常见反模式：

本节小结

• Memory 在 Agent 主循环中扮演「读-用-写」闭环：每轮先读（提供上下文），规划与行动后再写（沉淀观察）。它既是输入也是输出。
• Memory 分短期（上下文窗口，快但有限）与长期（向量库，慢但持久）两层。两者关系是「工作台 vs 档案柜」。
• 一轮循环里 Memory 有 5 个动作：读短期、检索长期、规划、写短期、按策略写长期。⑤b 长期写入不是每轮都做，只在里程碑/偏好变化时触发。
• Memory 内容分六类：对话历史、任务状态、工具观察、用户偏好、事实知识、经验反思。不同类型生命周期与检索方式不同，应分库管理。
• Memory 的三大核心问题：写什么、检索什么、何时遗忘。检索的经典公式是「相似度 × 时效性 × 重要性」加权评分。
• 三种典型架构：纯短期（最小）、短期+长期 RAG（主流）、多层记忆（复杂）。按需升级，不要一上来就过度工程化。
• Memory 与 Profile/Planning/Action 都有耦合。最关键的是 Memory↔Planning 的「主动检索」——成熟 Agent 应能主动发起检索请求。

下一节《2.3 Planning 规划模块》将讨论任务建模、规划空间与策略路由——即「面对不同任务,怎么在 CoT/ReAct/ToT/任务分解之间选」。具体算法留待第 3-4 章。