Agent Memory
定义
Agent Memory 是面向 Agent 的长期记忆层，用来保存、更新、检索与当前任务相关的历史交互和状态信息，使系统在多轮对话、跨时段任务和连续操作中不必只依赖一次请求内的上下文窗口。
在本文语境中，它不是泛指一切 AI 数据存储，而是更具体地指向“回忆类能力”的工程实现：承担情景记录、情景摘要、实时数据抽取等能力，服务于 Agent 对过往状态的回看与继续推理。
它与 Knowledge 的边界被明确区分：
- Memory 是“回忆”，强调会话上下文、状态同步、历史消息、摘要和事实提取等，要求低延时、高并发、灵活查询。
- Knowledge 是“知识”，强调知识库原文、摘要、向量检索与全文检索，典型用于 RAG 和多模态搜索。
因此，Agent Memory 在本文中并不负责知识库原文管理，重点不是保存“所有资料”，而是保存 Agent 为了持续完成当前或后续任务所需要的用户相关上下文与状态。
在本文中的语境
原文将 AI Agent 简化概括为：
- LLM（大型语言模型）
- 记忆（Memory）
- 规划技能（Planning skills）
- 工具使用（Tool use）
这个划分的含义是：单有模型并不足以构成可持续工作的 Agent。Agent 要形成“感知—决策—行动”的闭环，除了推理模型本身，还需要能够回忆历史、保留状态并在后续步骤继续使用这些状态的机制。Agent Memory 因而是 Agent 闭环中的基础组成部分，而不是附属优化项。
原文进一步指出，AI Agent 对存储能力的挑战可以分成两类：Memory 和 Knowledge。其中本文讨论的重点是前者，即长期记忆如何在真实业务里做到可用、便宜、稳定且可扩展。
核心工程要求
Memory 场景并不是简单把聊天记录存下来，而是有一组很强的工程约束。原文强调的核心要求包括：
- 毫秒级响应：Memory 参与在线推理链路，不能因为读取历史消息而显著拖慢模型调用。
- 高并发：对话式应用、搜索型 Agent 和大规模用户场景都可能带来非常高的读写吞吐。
- 动态 Schema 扩展：不同业务会不断新增 metadata、状态字段和分析字段，数据模型不能过于僵化。
- 大规模低成本：Memory 往往是高频写入、长时间累积的数据，成本控制非常关键。
- 稳定性能：在数据规模持续增长时，读写和查询延迟不能明显失控。
- 灵活检索：既要能按会话取消息，也要能按条件过滤、按时间回看、按业务元数据筛选。
原文还指出，传统数据库如 MySQL 和 PostgreSQL 虽然在许多场景表现良好，但面对上述要求的组合时会存在不同程度瓶颈，因此作者基于 Tablestore 总结出一个更贴合 Memory 场景的轻量级框架。
框架定位
本文中的 Agent Memory 实现建立在 Tablestore 之上，并通过 Agent Memory SDK 屏蔽底层存储细节，让业务侧优先按 Memory/Knowledge 的场景接口进行开发，而不是直接面向底层数据库操作。
该框架的设计目标包括：
轻量化设计
- 抽象通用存储接口，降低业务开发复杂度。
- 屏蔽底层数据库和存储接口调用细节。
- 在技术深度与易用性之间做平衡，使开发者可以更快产出业务结果。
场景驱动设计
原文说当前主要支持两个大场景：
- Memory 的实时记忆存储
- Knowledge 的长期语义检索
其中 Memory 侧并不只停留在聊天记录保存，而是明确提出后续会持续补充更贴近业务场景的能力，包括：
- 摘要（Summary）记录
- 事实数据提取
- 用户画像挖掘
- 用户标签挖掘
这说明 Agent Memory 在本文中被定义为一个可演进的能力层：先解决高频、核心、可落地的会话与消息存储，再逐步向更高层的结构化记忆能力扩展。
关键机制与组成
Session 表与 Message 表
原文在 Memory 记忆设计部分明确指出，最常见的情景记忆场景是“会话管理 + 历史消息存储”，并以此介绍两张核心表：
- Session 表：承载会话级数据。
- Message 表：承载消息级数据。
这是本文 Memory 设计的核心数据模型。
Session 表的职责
Session 表保存的是一个会话整体的信息，而不是单条对话内容。它适合记录：
- 用户 ID 与会话 ID 的关联
- 会话的更新时间 update_time
- 会话级 metadata，例如使用的模型名称
- 会话管理所需的其他聚合状态
从示例代码看，一个 Session 在创建时至少包含 user_id、session_id，并显式设置 update_time。此外，会话元数据中可以存 model_name = "qwen 2.5" 这样的业务字段，体现了动态 Schema 扩展能力。
Message 表的职责
Message 表保存的是会话中的每一条消息，是更细粒度的历史记录层。示例中每条 Message 都包含：
session_id：归属哪个会话message_id：消息唯一标识create_time：消息创建时间content：消息正文metadata：消息属性，例如message_type
其中 message_type 在示例里被用来区分“用户”与“大模型”消息，这意味着后续检索既可以按时间取，也可以按消息类型过滤。
当前已实现与可扩展能力
原文对 Memory 侧的能力覆盖有明显层次：
当前典型实现
- 会话管理
- 历史消息存储
这两项是最基础、也最直接参与在线推理的能力。
后续扩展方向
- 摘要记录
- 事实提取
- 用户画像
- 标签挖掘
- 会话行为分析
这些扩展说明本文中的 Agent Memory 并不是“只存原始日志”，而是可以逐步把原始对话加工成更可复用的长期状态，例如用户偏好、身份信息、已确认事实、行为模式等。
实际使用方式
原文给出了一个非常具体的聊天场景示例，能够反映 Agent Memory 在业务中的标准用法。
1. 创建会话
示例先创建一个 Session：
user_id = "1"session_id = "session_id_1"update_time = microseconds_timestamp()metadata["model_name"] = "qwen 2.5"
然后调用 memory_store.put_session(session) 写入会话。
这一步表明 Session 是后续所有消息的容器，也是会话列表、最近活跃时间等功能的基础。