让 Agent 拥有长期记忆：基于 Tablestore 的轻量级 Memory 框架实践

推荐语

AI Agent如何实现高效记忆存储？阿里云Tablestore推出轻量级Memory框架，助力Agent智能升级。

核心内容：
1. AI Agent存储需求分析：Memory与Knowledge两类核心挑战
2. Tablestore框架设计：实时记忆存储与语义检索解决方案
3. 实际应用案例：通义App、AI搜索等场景验证框架优势

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

• Tablestore：表格存储（Tablestore）面向海量结构化数据提供 Serverless 表存储服务，同时针对物联网场景深度优化提供一站式的 IoTstore 解决方案。适用于海量账单、IM 消息、物联网、车联网、风控、推荐等场景中的结构化数据存储，提供海量数据低成本存储、毫秒级的在线数据查询和检索以及灵活的数据分析能力。

  https://www.aliyun.com/product/ots?utm_content=g_1000406083

• tablestore-for-agent-memory：基于Tablestore的 Agent Memory SDK 框架，提供 AI Agent 场景的通用存储和查询能力。
  

  https://github.com/aliyun/alibabacloud-tablestore-for-agent-memory

AI Agent 是指基于人工智能的智能代理工具，具备感知、推理、决策和执行能力，帮助人们解决问题和完成任务。通俗一点讲，可以简单的认为 AI Agent = LLM（大型语言模型）+ 记忆（Memory）+ 规划技能（Planning skills）+ 工具使用（Tool use）。

AI Agent 的 "感知-决策-行动" 闭环需要两类核心存储能力：

• Memory：作为回忆，提供情景记录、情景摘要、实时数据抽取等，其需毫秒级响应、支持高并发和动态 Schema 扩展等需求，典型场景包括用户与大模型的会话上下文管理、实时状态信息同步等。
• Knowledge：作为知识，提供知识库内容原文、摘要等存储和检索，其核心能力是语义检索，即语义搜索的效果，当然规模、性能、成本也很关键，典型场景如 RAG 知识库、多模态搜索等。

在处理 Memory 场景的需求时，我们需要关注几个关键点：大规模数据集下的低成本、稳定的性能、扩展性以及灵活的检索能力。这些需求在 Memory 管理和分析中变得越来越重要，尤其是在面对大规模数据集和复杂查询时。虽然传统的数据库解决方案如 MySQL 和 PostgreSQL 在许多场景下表现良好，但在满足上述所有要求方面，它们或多或少存在一些瓶颈。鉴于以上挑战，我们基于 Tablestore 天然适合 Memory 场景数据存储分析的特性，将客户经验进行总结，提出了一个基于 Tablestore 的 Agent Memory 框架：tablestore-for-agent-memory。

开发者友好，抽象通用存储接口，降低业务开发复杂度，做好技术深度与易用性平衡。用户不需要参与数据库和存储的接口调用，可以快速开发代码产出结果。

目前主要支持 2 个场景： Memory 的实时记忆存储、 Knowledge 的长期语义检索。在满足存储层需求的基础上，同时提供最新的业务场景解决方案，例如摘要 (Summary) 记录、事实数据提取、挖掘用户画像/标签等等。

用户不需要复杂的技术调研，即可快速复用成熟的业界方案，快速在自己的业务下进行价值验证。我们会将支撑的头部客户的案例进行技术沉淀，包括但不限于：通义千问 App、某头部浏览器的 AI 搜索 Memory、网盘、知识库 RAG、阿里巴巴(1688) 的商品 AI 搜索、阿里云对象存储 (OSS) 的 Meta 语义检索、钉钉的 AI 搜索等。

该框架中，我们引入 Agent Memory SDK，屏蔽了下面的实现细节，专注于提升 AI 场景下的使用体验。基于表格存储 Tablestore，实现了记忆 Memory 和知识 Knowledge，在记忆 Memory 中，我们会不断扩充新的场景。

如果你关心细节设计，可以在本章节的子章节了解内部实现细节，如果想快速了解如何使用，可以直接跳到下一章节。

Memory 记忆最常见的场景是情景记忆，即会话管理和历史消息存储，我们以该场景进行 Tablestore 的表设计介绍。该场景包括 2 个核心表：Session 表和 Message 表。

如果你们有特殊化的业务场景，可以参考这些表设计重新，也可以联系我们研发帮忙进行设计。

Knowledge 主要依赖向量检索和全文检索，同时考虑了多租户的设计，具体如下：

• DocumentID 作为表的分区键，将所有的文档能离散到各个分区，全文+向量会导致单行较大，因此把 DocumentID 放在第一个主键当做分区键，这样能让每个分区的读写压力均衡。
• DocumentID 和 TenantID 这 2 个主键组合起来作为唯一主键，如果用户不是多租户场景，TenantID 填默认值即可。
• 多租户特性：当用户选择开启多租户特性后，会把 TenantID 设置为多元索引的路由键，这样同一个租户的数据可以落到指定的分区上，这样查询时候不需要访问所有分区，然后降低查询消耗并减少毛刺。
• 全文检索：text 文本字段在多元索引里会自动创建最大语义分词，如果需要其它分词，可以随时进行修改。
• 向量检索：embedding 向量字段会自动创建向量索引，内部自动选择合适的索引结构进行索引，用户无需进行调优和优化。

每个场景的功能实现，SDK 内提供了 Example 示例，具体参考 Github 里每个语言的 SDK 的介绍。我们以 Python SDK 为例，展示 2 个场景下的使用，同时也给出每个场景下的一些线上真实运行情况。

https://github.com/aliyun/alibabacloud-tablestore-for-agent-memory

以目前最火的大模型应用为例，用户和大模型应用进行聊天，我们将这个过程中的 Session 会话和 Message 聊天消息记录起来进行使用。

在该场景下，理论的写入和查询的 QPS 很容易支持到几百万甚至千万级别，受限于业务真实情况，目前 Memory 场景最大的线上真实业务查询和写入大概在 十几万 QPS 的量级，单行较大情况下写入延时 1~8ms，查询延时 1~4ms，单 Memory 表最大规模到 PB 级别。成本方面，我们按实际用量进行计费，对于存储型业务，在指标对齐情况下有信心做到成本最低。除了这些性能和成本指标，我们默认提供 3AZ（同城 3 可用区部署）的容灾能力，将可用性做到最高。

# 初始化代码请参考 Github 的 Readme 文档memory_store = MemoryStore()# 创建一个sessionsession = Session(user_id="1", session_id="session_id_1")session.update_time = microseconds_timestamp()session.metadata["model_name"] = "qwen 2.5"memory_store.put_session(session)# 用户提问：你好，帮我讲个笑话message = Message(session_id="session_id_1", message_id="message_id_1", create_time=microseconds_timestamp())message.content = "你好，帮我讲个笑话"message.metadata["message_type"] = "用户"memory_store.put_message(message)  # 记录用户消息session.update_time = microseconds_timestamp()memory_store.update_session(session)  # 记录用户消息时候，需要同时更新session信息，这里仅以更新update_time为例。# 大模型返回：小白＋小白=? 小白兔(two)message = Message(session_id="session_id_1", message_id="message_id_2", create_time=microseconds_timestamp())  # 消息id改变message.content = "小白＋小白=? 小白兔(two)"message.metadata["message_type"] = "大模型"memory_store.put_message(message)  # 记录大模型消息# 用户提问：再来一个message = Message(session_id="session_id_1", message_id="message_id_3", create_time=microseconds_timestamp())  # 消息id改变message.content = "再来一个"message.metadata["message_type"] = "用户"memory_store.put_message(message)session.update_time = microseconds_timestamp()memory_store.update_session(session)  # 记录用户消息时候，需要同时更新session信息，这里仅以更新update_time为例。# 查出来用户的最近3条历史消息: 后续将这3条消息传给大模型，这样大模型才知道“再来一个”的含义related_messages = memory_store.list_messages_paginated(session_id="session_id_1", page_size=3, metadata_filter=Filters.eq("message_type", "用户"))# 大模型返回：有一个躲猫猫社团，他们团长现在还没找到。message = Message(session_id="session_id_1", message_id="message_id_4", create_time=microseconds_timestamp())  # 消息id改变message.content = "有一个躲猫猫社团，他们团长现在还没找到"message.metadata["message_type"] = "大模型"memory_store.put_message(message)  # 记录大模型消息

我们将用户的文档存到 KnowledgeStore 里，然后通过向量检索和全文检索进行查询，查出结果后，将这些资料传输给大模型，即可完成 RAG 场景的典型应用。下面代码示例展示如何做文档的写入和查询。

在该场景下，单向量表理论规模最大可以到千亿级别，目前线上最大向量单表在百亿级别，查询 QPS 峰值在 2K+，向量检索的延时在 10ms~120ms。除了规模和性能的优势外，我们在成本方面按量付费，在可用性方面默认提供 3AZ（同城 3 可用区部署）的容灾能力。

# 初始化代码请参考 Github 的 Readme 文档knowledge_store = KnowledgeStore()# 声明文档document = Document(document_id="1", tenant_id="user_id_1")document.text = "你好，世界!"document.embedding = [1.0, 2.5, 3.5, 1.3]document.metadata["meta_string"] = "hi"document.metadata["meta_long"] = 123456# 写入和点查文档knowledge_store.put_document(document)document = knowledge_store.get_document(document_id="1", tenant_id="user_id_1")# 向量搜索文档：查询和“abc”相似的文档query_vector = embedding_model.embedding("abc")response = knowledge_store.vector_search(    query_vector=query_vector,    top_k=20,    tenant_id="user_id_1",  # 租户id    metadata_filter=Filters.logical_and([Filters.eq("meta_string", "hi"), Filters.gt("meta_long", 1)]),)# 全文检索文档：查询包含“abc hi”的文档response = knowledge_store.full_text_search(    query="abc hi",    tenant_id="user_id_1",  # 租户id    limit=50,    metadata_filter=Filters.logical_and([Filters.eq("meta_string", "hi"), Filters.gt("meta_long", 1)]),)

通义 App 是阿里巴巴智能信息事业群旗下的 AI 应用，作为实用、贴心的个人AI助手，通义覆盖办公、学习、生活等多个场景，助力用户提升效率，优化决策，增强创意表达。目前通义 App 的聊天记录、会话管理等是基于 Tablestore 实现的，主要使用了宽表模型、二级索引、多元索引等功能，该产品的存储量和查询写入流量十分高，目前是我们 Agent Memory 的头部客户。

该 AI 搜索应用 ( 浏览器 ) 深度融合了多项人工智能技术，通过核心搜索界面集成AI核心功能，并创新性地引入"深度思考模式"。当用户发起交互指令时，系统内置的智能处理系统将自动解析语义意图，通过任务拆解与流程规划，协同调用多种算法模型与智能代理组件。当前已构建起覆盖AI知识检索、智能文档生成、图像创作、幻灯片制作、学术研究支持、题库解析、健康咨询及旅行攻略规划等多维度应用场景的完整解决方案体系。

在数据架构层面，该 AI 搜索应用采用阿里云表格存储 ( Tablestore ) 构建存储中台，重点运用其宽表、二级索引、多元索引等技术，实现会话、日志、交互等核心数据的高效存储与管理。基于该存储方案，该AI 搜索应用在 Memory 场景中展现出卓越的性能优势，成功构建起具备高吞吐、低成本特性的大规模智能记忆存储体系。得益于产品本身的庞大用户基数，叠加AI功能带来的查询写入倍增效应，当前已成为阿里云表格存储 (Tablestore) 的 Agent Memory 场景的标杆级应用，日均处理数十亿次智能交互请求。

1688 的 AI深度找，作为一种新的搜索范式，通过 AI 帮用户从 1688 上的全部商品里挑选出用户需要的商品。Tablestore 的多元索引支撑了 1688 的大规模商品数据的向量检索，其使用了全文检索、标量检索、向量检索等多路召回能力，业务侧再进行分析、Rerank 排序、总结等，最终给用户展示出用户需要的商品，网页端体验地址如下：http://aizhao.1688.com，手机端可以打开阿里巴巴 App 进行体验。

首先，在技术路线上持续发展，针对 Memory 和 Knowledge 扩展进行增强，例如在记忆 Memory 场景上引入会话行为、用户画像、标签等分析挖掘能力，用户可以根据这些挖掘的数据进行业务场景使用，提高用户转换率，例如在知识 Knowledge 场景上可以引入多模态的向量融合能力，提供更加全面的文本、稠密向量、稀疏向量的一体化解决方案。其次，持续与主流 AI 框架共建标准化接口，将业界最新的 AI 能力和应用放到 Agent Memory SDK 中，方便用户在 AI 场景进行快速使用。

最后，欢迎加入我们的钉钉公开群 (钉钉群号： 36165029092)，与我们一起探讨 Agent Memory 相关问题。