记忆程序概述

最主要的痛点是：无状态性与有限。至于这导致，

• 每一次 API 调用都像“重启”。模型天然会失去之前对话记忆；多轮对话仅是把历史打包回传，不是真正意义上的记忆。
• 即便使用 100K 或 1M Token 的超长窗口，也无法容纳数年、无限轮次的对话历史；窗口过长还会带来噪音、成本和延迟。
• 真正的记忆需要像人脑一样结构化、可联想，并具备遗忘机制。

一个完整的记忆程序本质上是信息全生命周期管理程序，负责获取、存储、检索、更新与遗忘。它让 Agent 能够：

• 跨会话记住使用者偏好和历史交互。不过，
• 积累领域知识与执行经验。
• 执行长期任务并跟踪进度。
• 基于过往经验做出更好的决策。

分层架构

会话记忆

• 工程本质：内存中的严格保序 FIFO 队列 .
• 主要职责：维持当前对话连贯性，解决多轮代词指代问题。
• 生命周期：仅存在当前会话周期，只保留最近 N 轮。
• 绝不能被 LLM 修改或概括，必须保留原始文本内容。

短期记忆

• 工程本质：LMM 异步提炼出的结构化摘要或 Profile 标签。
• 主要职责：ID 当会话变长导致旧消息被挤出时承接主要含金量作为“前情提要”，常驻 System Prompt 中。
• 生命周期：DYNAMIC 更新，会话结束后可选择归档。话说回来，

长期记忆

• 工程本质：A vector database 与传统关系型数据库混合体。
• 主要职责：CROSS-SESSION 持久化。记住使用者几个月前设定的偏好、公司规章制度还有过去所有任务结果。
• 生命周期：PERSISTENT 存储，直至使用者显式触发擦除命令。

权衡与取舍

* 会话窗口调节：若 SessionMemory 太小，将细节丢失；因为成本下降，可增大窗口以缓冲原始现场信息。*

* 长期向量库垃圾数据污染：引入 Gatekeeper，只将高价值、有意义的数据写入长期向量库。 *

* 数据一致性 & 分布式锁：使用 Redis 分布式锁或时间戳队列确保写入顺序，从而避免“记忆错乱”或重复回复。*

主要流程 & 管道设计

A Agent 的记忆不是单一模块，而是一条包含“写入”和“读取”的完整管道：

• # 写入管道 — 对话转为可检索记忆
  • 感知与提取 → 转换与摘要 → 向量化 & 索引 → 存储.

-->

html