揭秘千问 APP 千万级 AI 订单背后的记忆存储实践
2026 年春节,千问 APP“春节请客计划”上线 9 小时,订单量突破 1000 万单,“帮我买”指令被调用超 3000 万次。用户点奶茶、送祝福的每一次交互,背后都是一套记忆系统在高速运转——记住用户偏好、关联订单信息、同步配送状态。 下面我们展开说说记忆系统如何实现的。 真正好用的记忆系统,应该具备两种能力: 为了更“好用”的体验,千问构建了一套一站式记忆存储系统,整体架构分三层: Agent 的记忆存储远不止“写进去、读出来”。随着用户规模和场景复杂度增长,挑战接踵而至: 当记忆规模膨胀至数十亿条,数据如何存储、检索、扩展,成了千问必须解决的问题。Tablestore 没有选择“堆砌功能”,而是用一套开箱即用的方案,把记忆管理的复杂流程变成了“自动运转”的简单操作。 Tablestore 进一步封装了开箱即用的记忆存储解决方案,提供短期/长期记忆统一管理能力,内置了短期记忆到长期记忆的自动抽取流程,开发者无需自行编排,降低业务接入门槛和开发成本。 支持在宽表上直接开通多元索引,无需部署独立的搜索引擎,可以实现通过向量检索召回记忆片段、根据关键词全文检索对话内容以及多条件组合查询等能力。 Tablestore 底层是分布式引擎,存储和计算分离,数据按分区键自动分片。单表可以存储数万亿甚至更高量级的行,不需要手动分库分表。宽表模型本身支持灵活的列定义,文本、结构化属性和向量嵌入可以作为不同列存在同一行中。也就是说,一个用户的短期上下文、长期画像、语义向量可以存在同一张表里,查询时一次读取就能拿到,不需要跨多个系统做 join。这让整体架构保持简洁,也省去了维护额外向量数据库的成本。 对于单行读和单行写操作,Tablestore 的延迟在个位数毫秒级别,这一点不会因为数据量增长到数十亿而明显劣化——因为底层基于 LSM-Tree 存储引擎,数据按主键有序存储、分层压缩,读路径上通过 bloom filter 和 block cache 加速,写路径上顺序追加。对记忆场景来说,最常见的操作就是“根据 user_id + session_id 读写某条记忆”,这正好命中单行读的最优路径。 Tablestore 是 Serverless 架构,按实际吞吐和存储量计费,不需要预留资源。流量上来的时候自动扩分区、扩资源,流量下去之后自动收缩。千问 APP 推广活动期间,峰值流量飙升数十倍,存储层全程自动弹性承接,业务侧不需要做任何扩容操作。 Tablestore 凭借分布式引擎、原生向量检索、Serverless 弹性和全托管免运维的组合优势,是 Agent 记忆场景的理想底座,在千问的记忆场景中也得到了充分验证。记忆存储是 Tablestore 的典型场景之一,除了千问之外,还支撑了夸克、钉钉等关键业务。 欢迎开发者前往阿里云官网申请试用。还可扫描下方二维码,通过查看 hermes-tablestore-memory 插件将 Hermes Agent 接入 Tablestore Memory 服务,为智能体构建云端持久化、跨会话和跨 Agent 共享的语义记忆。
流量洪峰之下,基于 Tablestore 的记忆存储系统成为关键支撑:Serverless 弹性伸缩平稳承接百万级QPS,读写延迟稳定在毫秒级,确保用户“说买就买”的即时体验。数十亿条记忆数据实时流转,让千万次请客互动丝滑落地,零卡顿、零遗漏。
没有这套记忆系统,就没有这场全民请客的狂欢。
千问 APP 支持日常对话、知识问答、外卖点餐等多种 Agent 场景。
记忆能力对这些场景至关重要——没有记忆的 Agent 每次对话都像初次见面,无法延续上下文、不了解用户偏好、也做不到个性化推荐。有了记忆,Agent 才能在多轮对话中保持连贯,跨会话积累对用户的了解,真正从“能用”变成“好用”。
让长期记忆自动沉淀
记忆检索:像查字典一样简单Tablestore
装下数十亿记忆:“一个库”即可搞定
数据量再大,延迟也不“掉链子”
流量来了自动“撑伞”,流量走了自动“收摊”

多业务验证的一站式记忆存储方案

链接:https://help.aliyun.com/zh/tablestore/use-cases/implementatio...