当你对千问说一句"帮我点杯霸王茶姬的伯牙绝弦，少糖去冰，送到公司"，背后的 AI Agent 需要在数秒内完成意图识别、地址解析、商品搜索、规格匹配、加购下单等一系列操作。整个过程涉及多轮对话、多次工具调用，每一步都依赖对"之前发生了什么"的准确记忆。

这就是 AI Agent 的短期记忆问题。在淘宝闪购与千问合作的"句话点外卖"项目中，Tair 承担了 Agent 短期记忆层的核心角色。本文将从这一真实业务场景出发，介绍 Tair 在 AI Agent 记忆管理中的数据模型设计、压缩策略与并发控制等关键实践。

淘宝闪购 Agent 支持用户通过自然语言完成从导购到下单支付的完整点单流程，目标是将传统 3-5 分钟的点单耗时压缩至 30 秒以内。一次典型的多轮对话如下：

在这个过程中，Agent 需要在每一轮交互时"记住"之前的全部上下文：第1轮获取到用户当前的位置，第2轮需要知道当前推荐的是哪个商品，第3轮需要确定购物车内容并汇总所有信息提交订单。这些"记忆"全部存储在 Tair 中。

AI Agent 的记忆系统对延迟极度敏感。根据 Little 定律 “并发数 ≈ QPS × 延迟” ，记忆访问延迟从 5ms 上升到 50ms，系统在途请求数就会膨胀10倍，这可能会迅速耗尽连接、线程和队列资源。而 Agent 每轮对话涉及多次记忆读写，延迟会被反复叠加放大，最终可能引发排队、超时乃至雪崩。

5ms 和 50ms 的差别，不是体验上的优化，而是系统能否稳定扩展的分水岭。 这正是淘宝闪购 Agent 选用 Tair 作为记忆层的核心原因 —— 通过自研多线程内核提供稳定的低延迟，将记忆访问稳定在安全水位，从根本上避免高并发下的恶性循环。

淘宝闪购 Agent 的记忆层（Memory Service）位于 Agent 中枢与底层工具服务之间，通过 Tair 提供会话级的状态管理能力。整体架构如下：

淘宝闪购 Agent 选择 Tair 作为短期记忆存储引擎，核心考量包括：

• 低延迟：Agent 对话链路对响应时间极度敏感，Tair 自研多线程内核提供微秒级读写能力，可满足实时交互需求。

• 丰富的数据结构：不同类型的记忆数据可以选用最匹配的数据结构，简化业务开发。

• 弹性扩展能力：支持集群无感扩缩容和带宽弹性突发，在流量洪峰期快速扩展、业务无感。

• TTL 生命周期管理：会话记忆具有自然过期属性，TTL 机制可自动清理过期数据。

短期记忆被划分为两大类，分别对应不同的 Tair 数据结构：

模型记忆（Model Memory）—— List

模型记忆存储供大语言模型消费的对话历史。每轮对话中用户的输入和 Agent 的回复，都会被记录并在下一轮推理时作为上下文传入模型。

使用 Tair 的 List 结构存储，每个会话一个 Key：

Key:  memory:model:{sessionId}Type: List
示例数据：[  {"role": "user",      "content": "帮我点杯奶茶"},  {"role": "assistant", "content": "为你找到附近3家奶茶店...", "cards": [...]},  {"role": "user",      "content": "就这个，少糖去冰"},  {"role": "assistant", "content": "已选择：伯牙绝弦 少糖去冰 大杯..."}]

核心操作： 

# 每轮对话结束后，追加新的对话记录RPUSH memory:model:{sessionId} "{对话记录JSON}"
# 模型推理前，读取最近N轮对话作为上下文LRANGE memory:model:{sessionId} -{N} -1
# 设置会话过期时间（如30分钟）EXPIRE memory:model:{sessionId} 1800

说明 对话记录在写入前，会将原始数据（包含文本和卡片等富媒体内容）转换为模型更易理解的自然语言格式，减少 Token 消耗。

业务上下文记忆（Business Context Memory）—— Hash

业务上下文记忆记录业务流程中的结构化状态信息，供 Agent 的工具层和意图处理器在执行业务逻辑时查询和更新。

按业务领域拆分为 6 个子模块，使用 Tair 的 Hash 结构存储：

Key:  memory:context:{sessionId}Type: Hash
Field 结构：{  "session":      "{会话元信息: 用户ID、渠道、会话阶段等}",  "search":       "{搜索状态: 当前query、搜索结果、推荐商品列表等}",  "order":        "{订单状态: 购物车内容、已选SKU、商品数量等}",  "conversation": "{对话状态: 当前意图、上一轮意图、意图切换标记等}",  "coupon":       "{优惠信息: 可用优惠券列表、已选优惠等}",  "bizState":     "{业务状态: 收货地址、配送方式、支付状态等}"}

核心操作：

# 单独更新某个子模块（如用户确认了收货地址）HSET memory:context:{sessionId} bizState "{更新后的业务状态JSON}"
# 读取特定子模块HGET memory:context:{sessionId} order
# 一次性读取所有上下文（用于意图识别等需要全局信息的场景）HGETALL memory:context:{sessionId}
# 设置过期时间EXPIRE memory:context:{sessionId} 1800

说明 使用 Hash 的 field 级读写能力，各业务模块可以独立更新，互不干扰，避免了读取完整 JSON 再回写的竞争问题。例如搜索模块更新商品推荐结果时，不会影响订单模块正在写入的购物车数据。

数据结构选型对比

在实际业务中，同一会话可能存在并发写入。例如用户快速连续发送消息，或流式响应过程中用户再次输入，都会导致多个请求同时修改同一会话的记忆数据。

淘宝闪购 Agent 使用 Tair 分布式锁保护记忆的读写一致性，锁粒度为单个会话：

# 获取会话级分布式锁（锁超时3秒，防止异常阻塞）SET lock:memory:{sessionId} {requestId} NX EX 3
# 成功获取锁后，执行记忆读写操作HSET memory:context:{sessionId} order "{更新后的订单状态}"RPUSH memory:model:{sessionId} "{新对话记录}"
# 操作完成后释放锁（通过Lua脚本确保只释放自己持有的锁）EVAL   if redis.call('GET', KEYS[1]) == ARGV[1] then    return redis.call('DEL', KEYS[1])  else    return0  end

说明 锁粒度为会话级（sessionId），而非全局锁。不同用户的会话之间完全无锁竞争，不会影响系统整体吞吐。锁超时设置为秒级，避免持锁进程异常退出时造成长时间阻塞。

在千问春节红包活动期间，淘宝闪购 Agent 承受了超过 10 倍于预估峰值的并发压力。每次用户对话可能触发数十次 Tair 操作（读取历史、更新状态、锁操作等），Agent 的并发请求量会被放大为数量级更高的 Tair 操作量。

淘宝闪购 Agent 的记忆层底层使用的是云数据库 Tair（兼容 Redis）。相比自建 Redis，Tair 在内核性能、弹性扩展和运维方面的能力是应对此次流量洪峰的关键支撑。

突破单线程瓶颈：利用多线程内核压榨单节点吞吐

Tair（企业版）内存型采用多线程模型，读写性能达到同规格 Redis 开源版实例的 3 倍。这意味着在相同的实例规格下，Tair 能够承载 3 倍于开源 Redis 的操作吞吐量。

在 AI Agent 场景中，这一性能优势尤为关键。一次用户对话可能触发数十次 Tair 操作（读取对话历史、更新业务上下文、分布式锁获取释放等），如果使用开源 Redis 的单线程模型，在高并发场景下很容易成为瓶颈。Tair 的多线程内核使得单个节点可以充分利用多核 CPU 资源，在不增加节点数量的前提下即可承载更高的并发量。

读写比10:1下的弹性扩展与无感扩缩容

在 Agent 对话链路中，记忆数据呈现典型的读多写少特征：每轮推理前需要读取完整的对话历史和业务上下文（读操作），而写操作仅在每轮对话结束后追加一条记录。读写比通常在 5:1 到 10:1 之间。

Tair 支持集群架构开启读写分离功能，主节点挂载只读副本（Read Replica），读请求自动分发到只读节点，写请求路由到主节点。只读副本支持 1~9 个灵活调整，集群分片支持 2~256 个水平扩展。在流量高峰前增加只读副本或分片即可线性提升吞吐，峰值过后缩减节点降低成本。

日常流量：  集群 8 分片，每分片 1 只读副本 → 满足日常业务需求
春节活动（5～10 倍峰值）：  方案一：每分片扩展至 5 只读副本 → 读吞吐线性提升  方案二：集群扩至 16 分片 + 每分片 3 只读副本 → 读写能力同步翻倍

而这些扩缩容操作对业务完全透明。传统 Redis 集群在 Slot 迁移过程中可能产生 -ASK、-TRYAGAIN 等错误，对 Agent 对话场景来说，任何一次请求失败都可能导致对话中断或记忆丢失。Tair 云原生版通过内核级优化实现了无感扩缩容——数据以 Slot 为单位原子性整体迁移（而非逐 Key 迁移），不会造成 Slot 分裂；同时通过中心化的控制组件协调集群行为，迁移效率更高、决策更精准。

说明 在数据迁移的最终阶段，对应 Slot 的写请求时延会略有增加，但不会失败。对于 Agent 记忆服务而言，表现为个别请求延迟略升，但不会出现数据丢失或请求报错。

运维团队可以根据业务流量实时调整集群规模——活动前扩容、活动后缩容——全程业务无感，无需应用层做任何适配。

解决带宽侧的木桶效应

除了 QPS 压力，在千问春节红包的活动中还面临了显著的带宽挑战。AI Agent每次记忆读取涉及对话历史和业务上下文的传输，单次请求的数据远大于传统缓存场景中的简单KV读写。在业务高峰期，带宽很大可能先于 CPU 和 内存成为瓶颈。

Tair 云原生架构提供了两层弹性机制：

• 集群带宽水平扩展：集群架构可以通过增加 LB 数量来扩展实例总带宽，单个 LB 带宽上限 20Gbps，当分片数超过 8 个时，可按需新增 LB，新增过程中不会中断现有连接。

• 弹性突发带宽：当瞬时流量超过固定带宽时，系统会秒级自动扩展带宽（单节点最高可达 288MB/s），流量回落后自动回收，按实际突发量计费。开启和关闭均不会影响实例正常访问。弹性突发带宽以分片为粒度独立生效。当某个分片因热点 Key 出现带宽瓶颈时，仅该分片的带宽会被自动扩展，不会影响其他分片。既精准应对热点问题，又避免不必要的成本开销。

说明 弹性突发带宽特别适合 Agent 场景中不可预测的流量尖峰。相比提前购买高规格的固定带宽包，按需突发在成本上更省。

利用 TTL 实现冷热数据自动清理

所有会话 Key 设置合理的 TTL（如 30 分钟），流量高峰过后内存自动回落，无需人工干预。结合 Tair 的弹性扩缩容能力，实现了"高峰扩、低谷缩、过期自动数据清理"的全自动资源管理。

最终，整套记忆服务在春节流量洪峰期间保持稳定运行，P99 延迟始终控制在毫秒级。

在淘宝闪购 "一句话点外卖"场景中，Tair 作为 AI Agent 短期记忆层的核心存储，提供了以下关键能力：

随着 AI Agent 技术的演进，记忆管理正在向更深层次发展。短期记忆之外，长期记忆（用户偏好、历史行为模式）的建设已在规划之中，让 Agent 不仅记住"这次对话说了什么"，更记住"这个用户是谁、喜欢什么"。

AI Agent 的记忆系统，正在从"对话级"走向"用户级"，Tair 在这一演进过程中将持续扮演关键角色。