Tair (Redis® OSS-Compatible)：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延遲始終控制在毫秒級。