1. 背景：AI Agent 市场爆发增长

2025 年被视为 AI Agent 市场元年，其中有一些关键性事件是被大家熟知的，比如：

• 2024 年 12 月底 DeepSeek-V3 发布和开源，性能对齐海外领军闭源模型
• 2025 年 1 月 DeepSeek-R1 发布和开源，性能对标 OpenAI o1 正式版。
• 2025 年 3 月 Manus 发布了，全球首个完全自主通用 AI Agent.

除了这些大家熟知的关键性事件，我们还发现 AI Agent 有这样的趋势：

• 市场规模爆发增长：中国表现尤为显著，2023年中国市场规模达554亿元，预计2028年将超8520亿元，复合年均增长率达72.7%，各种规模的企业通过 AI Agent 降本增效，因此对应的 AI Agent 存储需求越来越多。
• 技术迭代加速：厂商通过标准化工具（如Qwen Agent、通义万相）降低应用门槛，多模态协同、多智能体技术突破倒逼企业加大研发力度，2025 年 AI Agent 技术和应用都将爆发增长，与之带来的存储需求和挑战也会越来越大。

2. Agent Memory 存储需求

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

该图片来自论文 The Rise and Potential of Large Language Model Based Agents: A Survey，其描述了智能体 Agent 是如何工作的。首先，感知模块（对应人类的感觉系统，如眼睛和耳朵）感知外部环境的变化，然后将多模态信息转换为智能体可理解的表示形式。然后，作为控制中心的大脑模块进行信息处理活动，包括思考、决策和存储操作，其中存储包括记忆（Memory）和知识（Knowledge）。最后，行动模块（对应人类的四肢）借助工具执行操作，并对周围环境产生影响。通过重复上述过程，智能体能够持续接收反馈并与环境进行交互。

在 Agent 工作过程中，Memory 也就此孕育而生，负责和大脑(大模型)的短期记忆存储和外部知识获取，也就是 Memory 和 Knowledge。业界还存在这另一个角度的分类，如文章Short-Term vs Long-Term Memory in AI Agents中，将其命名为短期记忆（STM）和长期记忆（LTM），和上述 Memory 和 Knowledge 类似，只是换了另一个考虑的角度。

为了大家更直观的理解功能和应用，我们使用复旦大学的论文里的描述，将 Agent 的存储 ( Agent Memory ) 分为 Memory 和 Knowledge。

2.1 Memory

Memory 是指 AI 中的短期记忆，时间长短取决于任务的要求，一旦任务完成或不再需要信息，就会将其丢弃或覆盖。比典型的场景就是我们和 AI 聊天的上下文，即会话 Session 管理和聊天记录存储，AI 需要根据 Memory 中最近得最相关信息来回答用户的问题。为了能帮助大模型快速决策，需要能快速获取和存储这些上下文信息。

Memory 作为 AI Agent 的短期记忆中枢，其核心诉求可概括为"毫秒级响应"与"动态扩展"。以会话管理场景为例，某电商客服 Agent 需在 200ms 内响应用户咨询，且单日处理会话量可达千万级。传统方案的局限性逐步显现：

• In-Memory 方案：Redis 虽能满足低延迟需求，但面临成本和容量瓶颈，特别是当前大模型能力越来越强，用户的输入越来越大，内存成本会随着大模型能力变强而成本变得特别高。
• MySQL 方案：MySQL 在 OLTP 场景下，单表超过 5000 万行时性能会下降特别多，当业务起量后，很难支撑高 QPS 和低延时，且其 JSON 字段的动态扩展能力不足，难以应对多模态数据存储需求，随着 AI 业务的快速迭代，需要经常变更 Schema，运维压力较大。

2.2 Knowledge

与 Memory 不同，Knowledge 更关注一些长期存在的知识信息，或者叫知识库。就像人类大脑会学到的知识然后在未来的场景中使用一样，AI 大模型可以根据 Knowledge 中的知识信息进行信息补充，进行复杂的决策任务或者建议。Knowledge 中的记忆存储的数据量更大，可能是某个领域或者某个人的全部知识，这些丰富的知识特别适合大模型进行更深层次的推理。比较典型的场景就是 RAG 检索增强生成，让大模型能够检索外部信息或者特定领域的 Knowledge 知识库来生成更准确的回答。

对 Knowledge 存储来说，Knowledge 作为知识底座，其核心能力是检索，即语义搜索的效果，当然规模、性能也很关键，一般传统方案包括：

• 本地向量数据库：在业务初期，一般会使用 SQLite 或 Chroma 等本地向量数据库，快速进行业务迭代。随着对数据的可靠性、性能、规模等各方面的追求，会转向 PG-Vector 之类的向量数据库。
• PostgreSQL 向量扩展（PG-Vector）：随着用户越来越多，知识库规模越来越大，对查询的复杂度要求越来越高，传统的 PG 类数据库在性能、成本、全文检索、向量标量混合检索等各方面会有不足。根据客户反馈，PostgreSQL 的向量扩展（PG-Vector）在1亿向量规模时，混合查询响应时间超过 1 秒，且索引维护成本呈指数级增长。

3. Tablestore 的 Agent Memory 能力

Tablestore 在 Agent Memory 存储上有显著的优势，本章节会介绍 Tablestore 在 AI 场景的一些优势。首先，我们会先总结一下其基本能力，然后分别在不同的场景下介绍其优势。

3.1 核心基础能力

• Serverless：即开即用，无需运维，提供全周期的技术支持，大幅缩短研发周期，提早上线。
• 性能：自研宽表引擎和搜索引擎，相较于开源的 Hbase 和 Elasticsearch 有很大的性能优势。
• 成本和弹性：Tablestore 使用存算分离架构，PB级数据处理能力，支持自动水平分片与弹性资源调度，在成本上有很大优势。
• 稳定性： 默认使用 3AZ 同城容灾，在可用性、多租户保障等各方面有很多积累。

3.2 Memory 场景

Memory 场景主要依赖表格存储的宽表能力，其优势包括：

• 高性能：自研存储引擎，具备优秀的读写能力，Tablestore 线上用户单个实例的吞吐最高到千万 TPS/QPS。Tablestore 的宽表引擎这些年一直在持续精进，和 MySQL 等关系数据库对比，在几十亿以上规模情况下，其读写性能远超 MySQL。和开源的 Hbase 对比，如下图所示，相同规格的CPU核心数下的性能对比，读写能力都十分出众。

• 低成本持久化存储：相较于 Redis 等内存存储方式，Tablestore 默认写入即落盘，保证数据持久化，在满足业务性能和规模情况下，采用存算分离、数据压缩等各种技术，将成本压到最低。
• Schemaless 设计：AI 相关业务目前迭代特别快，和关系数据库对比，Tablestore 在宽表上默认支持 Free Schema 特性，方便用户实时增删字段，设计十分灵活。

通常情况下，宽表引擎能满足大部分的 Memory 场景的存储需求。如果需要在 Memory 存储上进行多字段的自由组合查询过滤、通过全文检索查询用户的内容、进行轻量级的业务分析能力，可以使用表格存储的 多元索引 进行数据的查询和分析。

3.3 Knowledge 场景

Knowledge 场景主要依赖表格存储的多元索引, 其提供全文检索、向量检索、混合检索等功能，下面会介绍一下其在各个方面的优势和原理：

• 基础原理
  

• Tablestore 支持混合索引：Flat、PQ、DiskANN、倒排索引、BKD 等，其中向量检索主要使用 DiskANN 算法。这些索引类型不需要用户选择，会根据用户写入模式、数据规模、查询特征自适应选择最佳方案，实现了自适应查询策略，高效进行向量检索同时大幅降低用户的参数选择困扰，以及避免参数错误导致的性能不足或者召回率低的问题。





• 向量检索为什么主要使用 DiskANN？ DiskANN 算法专为磁盘设计，其内部为磁盘友好的层次化图结构，能够处理远超内存容量的数据集。在 Tablestore 内部，我们只需要将图索引的 10% 的数据放进内存，剩余 90% 的数据放在磁盘上就能达到和 HNSW 相近的高召回率和性能，但是内存成本只有 HNSW 的 10%，这个就是低成本的原因。在规模上，经过引入 DiskANN 和表格存储的算法和分布式框架优化，最终能支持到千亿级别向量数据的存储和检索。
• Tablestore 在 DiskANN 上的通用优化：通过盘古分布式文件系统解决了 DiskANN 的 I/O 瓶颈问题、默认支持并发查询、使用 PQ 技术优化性能、优化 DiskANN 图索引结构减少内存占用、优化 DiskANN 二阶段精排、自研 Cache 技术避免系统 mmap 的 Cache 污染问题、SIMD 等硬件加速技术、查询优化......其中在写入方面，还有一些特殊优化：
• 向量检索的成本较高其中一方面是因为构建图索引的成本较高，我们引入了独立和弹性的远端构建节点(Remote Build Node)，将向量图索引构建任务从数据节点下放到离线节点，大幅提升吞吐效率和资源利用率。

• 实现了针对向量索引的特殊 Compaction 策略，降低写入放大问题，大幅节省资源消耗，同时解决分层构建策略，将向量检索的时效性做到近实时，向量检索几乎是写入即可见。
• 功能齐全：支持全文检索、向量检索、标量检索、混合检索多路召回、RRF(待上线)、稀疏向量检索(待上线)、一个索引支持多个向量等等功能，尽可能全的功能，让用户在 Knowledge 场景上能够做更深入的定制化能力。

• 成本控制

• 相较于 HNSW 的全内存实现，DiskANN 在大多数场景下只需要 10%的内存即可达到和 HNSW 接近一致的效果。
• Tablestore 支持 bytes 格式的向量表达，相较于字符串格式的向量，最高能节省 4 倍存储成本。
• DiskANN 图索引优化：将图索引的原始向量转为 Tablestore 的原生列存实现，降低存储成本同时提高性能。
• Tablestore 使用存算分离架构，并将向量的索引构建资源独立出来放到远端构建节点，这样资源能够更加弹性，可以将成本控制到更低。

• 稳定性优化

• 多租户能力：Tablestore 有多年的多租户运维经验，其多元索引支持路由能力，可以把每个用户的数据放到一个分区内，在查询时候减少查询消耗。针对热点大租户，我们支持二级路由散列能力，可以将大租户二级散列到更多分区上，解决数据倾斜和热点问题。除此之外，我们还有丰富的流控能力，能在多租户场景下有效组阻断某个租户造成稳定性问题。
• 提供基于扫描量的保护能力，避免用户走到向量检索领域里的扫描黑洞里，影响其它正常请求的执行，保证实例整体稳定运行。
• 针对向量索引容量进行了特殊的监控和自动扩容处理，保证向量索引和标量索引的稳定运行。

3.4 生态和易用性优化

Tablestore 积极参与 AI 生态的建设，进行集成和被集成，包括以下一些方面：

• 多语言 SDK：包括 Java、Python、Go、Nodejs、C#、PHP 等等。除了易用的原生接口外，支持标准 SQL 语言，方便用户使用 JDBC 等框架进行集成。
• Langchain 类开源框架：支持 LangChain、LangChain4J、LlamaIndex、LangEngine 等等。
• Dify 等上层应用：Dify、PAI-RAG、Higress 等等。
• Demo 应用：MCP、RAG、多场景案例 等等。
• 探索多种生成向量方式，方便用户在云上或云下本地生成向量，降低用户使用门槛。

3.5 Agent Memory 框架：Tablestore for Agent Memory

使用方式可加入最后的钉钉群进行了解。

为了用户能够方便地用起来 Agent Memory，我们基于现有的阿里内部大型成熟业务抽象了 Agent Memory 框架：“Tablestore for Agent Memory”，在 Memory 场景和 Knowledge 场景让用户能在自己业务上快速使用起来。 我们的目标包括但不限于：

• 轻量：针对 Memory 和 Knowledge 的极简 AI 设计，同时提供高级用法，让 AI 入门用户和资深用户都可以快速使用。
• 易用：基于 Tablestore 提供高性能服务的同时，减少了调研、设计、开发的成本，很方便就能复刻阿里内部该领域经过锤炼的成熟方案。

4. Agent Memory 客户案例

在 Tablestore 上的 AI 领域里关于 Agent 储存的现有案例特别多，这里我们仅列举一些规模较大和较成熟的业务。

4.1 Memory 场景案例

4.1.1 通义 App

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

4.1.2 某 AI 搜索应用

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

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

4.2 Knowledge 场景案例

下面展示 Tablestore 上常见的 Knowledge 场景案例，每个场景仅介绍头部成熟业务。

4.2.1 AI 搜索：阿里巴巴的商品搜索

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

4.2.2 多模态语义搜索：阿里云对象存储（OSS）

阿里云对象存储（OSS）提供了 MetaQuery 的能力，MetaQuery 与 OSS 的标签能力相结合，满足了用户的海量数据多维查询需求，截至目前 OSS 的 MetaQuery 业务总行数有数十千亿规模。Tablestore 支持了 MetaQuery 的向量检索能力， 用户可以使用文本直接查询 OSS 中的文本文档、图片、视频、音频等数据，进行多模态语义搜索。

4.2.3 RAG 知识库应用：阿里云“网盘与相册服务”的 AI 助手

阿里云的网盘与相册服务（Drive&Photo Service）是为客户提供的面向企业、团队与个人的数据管理开放平台，提供一站式数据存储、分析和AI的能力，方便客户快速高效的构建可支撑海量用户的网盘与相册服务，同时针对团队及个人用户，支持免开发开箱即用。目前网盘和相册服务使用 Tablestore 存储了网盘文件的元数据和 Embedding 语义数据，其 AI 助手具备知识库能力，可以将网盘里的知识库文档进行学习，基于 AI 助手可以进行答疑和智能检索。

5. 总结

在 AI Agent 不断的发展与实践中，Tablestore 在构建大规模、高性能、低成本的 Agent Memory 存储底座方面做了很多工作，逐步积累和沉淀了丰富的技术经验、多样化的应用场景以及高效的业务上线能力。欢迎加入我们的钉钉公开群，与我们一起探讨 AI 技术，钉钉群号：36165029092。