本文介绍了 AI Agent 对存储能力的挑战，尤其是 Memory 和 Knowledge 两类核心需求。为应对这些挑战，基于阿里云 Tablestore 提出了一种轻量化的 Agent Memory 框架设计，支持实时记忆存储与语义检索等场景。该框架已在多个实际业务中落地，如通义 App、某头部浏览器的 AI 搜索及 1688 商品 AI 搜索等，验证了其高性能、高扩展性和低成本优势。未来将继续增强多模态与用户行为分析能力，并与主流 AI 框架共建生态。

一、背景：AI Agent 对存储能力的挑战

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

图 1：AI Agent 架构示意——智能体在感知环境输入后，经大脑的存储（Memory/Knowledge）与决策（规划/推理）处理，再执行行动并反馈回环境，形成闭环

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

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

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

二、Agent Memory 框架设计目标

1. 轻量化设计

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

2. 场景驱动设计

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

3. 业务价值验证

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

三、框架核心架构

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

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

1. Memory 记忆设计

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

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

图 2：Session 表以 user_id + session_id 为联合主键（user_id 作分区键）；Message 表以 session_id + create_time + message_id 为联合主键（session_id 作分区键），其余字段为 schema free 的元数据

图 3：Session 与 Message 的索引设计——二级索引支撑"按时间排序/按主键点查"等场景，多元索引（选配）支持任意字段的自由组合查询

2. Knowledge 知识设计

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

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

图 4：Knowledge 表结构设计——document_id + tenant_id 联合主键，多元索引中 tenant_id 作为路由键，embedding 字段自动构建向量索引

四、场景化能力实现

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

alibabacloud-tablestore-for-agent-memory（GitHub）

1. 大模型聊天场景

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

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

图 5：Memory 场景线上性能监控示例——QPS 与 GetRow / GetRange 读写延迟曲线

# 初始化代码请参考 GitHub 的 Readme 文档
memory_store = MemoryStore()

# 创建一个 session
session = Session(user_id="1", session_id="session_id_1")
session.update_time = microseconds_timestamp()
session.metadata["model_name"] = "qwen2.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)  # 记录大模型消息

2. RAG 场景

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

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

图 6：RAG 场景线上性能监控示例——搜索 QPS 与搜索延迟曲线

# 初始化代码请参考 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" 相似的文档
# 假设已初始化 embedding_model（例如通义千问 Embedding 模型）
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)]),
)

五、行业案例

1. 通义 App

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

图 7：通义 App 界面示例——AI 助手聊天场景

2. 某头部浏览器

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

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

图 8：AI 搜索应用界面示例——集成"深度思考模式"等 AI 能力

3. AI 商品搜索

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

图 9：1688 AI 深度找体验界面——AI 采购助手推荐与商品匹配对比

六、未来演进方向

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

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

七、快速部署 Dify，高效搭建 AI 应用

Dify 让你无需编程即可快速构建 AI 应用。然而，本地私有化部署往往维护成本高且可靠性不足。本方案介绍如何在阿里云构建云原生高可用架构，实现 Dify 的快速部署，助力企业高效搭建 AI 应用。

参考资料

• 阿里云表格存储 Tablestore（产品介绍）
• alibabacloud-tablestore-for-agent-memory（GitHub 开源仓库）