云数据库 Tair（兼容 Redis®）：Tair在AI Agent短期记忆中的最佳实践

适用场景

本文的设计模式适用于以下AI Agent场景：

• 需要维护多轮对话上下文的会话式Agent（如客服、导购、助手）

• 对话链路延迟敏感、需要毫秒级记忆读写的实时交互场景

• 存在并发写入风险的多工具调用场景（如Agent同时调用多个工具）

• 流量波动大、需要弹性扩展的线上业务

为什么记忆系统需要Tair

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

5ms和50ms的差别，不是体验上的优化，而是系统能否稳定扩展的分水岭。这正是淘宝闪购Agent选用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

业务上下文记忆（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

数据结构选型对比

Tair自研内核的性能优势

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

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

弹性扩展与无感扩缩容

在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分裂；同时通过中心化的控制组件协调集群行为，迁移效率更高、决策更精准。

带宽弹性扩展

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

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

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

• 突发弹性带宽：当瞬时流量超过固定带宽时，系统会秒级自动扩展带宽（单节点最高可达288MB/s），流量回落后自动回收，按实际突发量计费。突发弹性带宽以分片为粒度独立生效。当某个分片因热点Key出现带宽瓶颈时，仅该分片的带宽会被自动扩展，不会影响其他分片。

  说明

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

TTL自动回收

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

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