從去年開始我一直在做AI Agent相關的落地項目。剛把Agent接入線上流量的時候遇到過一個很典型的狀況用戶數一旦上來接口響應時間從幾百毫秒直接飆到好幾秒甚至幾十秒。排了半天發(fā)現瓶頸根本不在模型推理而是每個請求都在重復調用同一個工具、把同樣的會話上下文拼了又拼第三方API配額被瘋狂消耗。后來把Redis作為中間件引入Agent架構才把這些坑逐個填平。這篇東西就是把這段實踐梳理清楚AI Agent為什么需要Redis、緩存層怎么設計、會話狀態(tài)和記憶怎么存、分布式鎖和限流怎么做、以及那些真正踩過的坑。不管你是還在搭Agent原型還是已經在做并發(fā)治理應該都能用上。1. Agent系統(tǒng)的三類性能瓶頸模型延遲往往不是罪魁禍首很多人誤以為Agent慢是因為大模型推理慢。但實際上當你把完整的調用鏈路拉出來看模型推理只是其中一環(huán)。一個典型Agent請求要經過路由、上下文拼裝、工具調度、多次LLM調用、最終整合每一環(huán)都可能成為瓶頸。我總結下來至少有三類瓶頸跟Redis這種緩存中間件直接相關。1.1 工具調用被重復執(zhí)行最隱蔽的資源黑洞Agent和普通接口最大區(qū)別在于LLM本身是無狀態(tài)的它每次面對請求都要重新推理。這意味著同一個查詢在多輪對話里極可能被反復執(zhí)行。舉一個我項目的真實case用戶問今天北京天氣怎么樣Agent第一步要調用天氣API拿數據再組織語言返回。但下一輪用戶追問那明天呢Agent可能再次調用同一個天氣API甚至因為工具描述不夠清晰連今天的數據又查了一遍。這些重復的工具調用不僅是浪費外部API配額還會讓整體耗時成倍增加。天氣接口還相對快如果Agent經常調用的是一些耗時服務比如搜索、文檔檢索、數據庫查詢那就更麻煩了。當時我用Redis做了第一層緩解把工具名 入參摘要作為key把工具返回結果緩存在Redis里TTL根據數據時效性來定。天氣這種數據十分鐘內基本不變緩存命中后Agent直接拿結果不會再反復打擾上游服務。這個改動非常小但效果立竿見影接口響應直接下降了一個量級。1.2 會話上下文被反復組裝同樣一個長記憶拼了又拼Agent每輪對話都要把歷史聊天記錄取出來拼成上下文喂給模型。用戶會話一長這個上下文就很占存儲和帶寬。如果Agent還要帶上一些長期記憶比如用戶偏好、歷史訂單、知識庫片段那就更重了。常規(guī)做法是把會話存數據庫每次請求實時查。但這套邏輯在并發(fā)量上來之后會出現明顯的瓶頸同一時間大量用戶都在做相似的查詢、相似的組裝數據庫壓力倍增響應時間也不穩(wěn)定。Redis在這里的價值是熱會話緩沖層把最近活躍的會話狀態(tài)放Redis訪問速度快再配合TTL自動清理不活躍的會話慢慢淘汰數據庫只負責持久化兜底。1.3 上游API配額與限流外部依賴比想象中脆弱Agent再強也離不開外部依賴LLM API、搜索API、支付查詢、天氣服務幾乎每個都有調用配額或速率限制。一旦并發(fā)突增上游直接開始返回限流錯誤Agent拿不到結果就只能重試重試又進一步消耗配額形成惡性循環(huán)。這個點很多人到了生產環(huán)境才意識到。我在項目里就碰到過LLM API被限流整個Agent服務跟著雪崩的事。Redis在這里的主要職責是限流閘門每個上游接口都設置一套調用頻率限制同時把工具返回結果緩存住盡量減少對上游的無效請求。所以綜合來看Agent不是要不要Redis的問題而是Redis要承擔幾個角色的問題緩存、狀態(tài)存儲、限流底座、任務隊列四個角色缺一不可。2. 緩存層怎么設計不是所有數據都值得塞進Redis把Redis引入Agent系統(tǒng)第一個任務就是做緩存設計。但緩存設計絕不是簡簡單單把結果set進去下次get出來這么粗暴。哪些數據值得緩存、用什么Key、TTL給多長每一層都要想清楚否則緩存命中率上不去還會處理一大堆一致性問題。2.1 值得緩存的四類數據根據我的實踐經驗Agent系統(tǒng)里有四類數據非常適合放到Redis里第一類是工具/API返回結果。天氣、匯率、股票行情、商品信息這類數據有明確的時效性重復查詢的比例非常高用Redis緩存能顯著降低外部依賴壓力。第二類是系統(tǒng)提示詞和固定模板。大型Agent的系統(tǒng)提示詞往往幾千字每次請求都完整傳給模型是浪費。雖然在很多框架里模板是代碼內常量但如果你的提示詞是配置化的、運營可調的緩存一份在Redis按版本號管理會非常方便。第三類是短期會話快照。多輪對話的中間狀態(tài)用Redis存讀寫都快比每次查數據庫合適得多。第四類是高頻知識庫檢索結果。很多Agent會做RAG同一個問題被不同用戶反復問是常態(tài)。如果問題本身完全一樣那就沒必要每次都對向量庫做檢索直接返回緩存結果就行。這四類數據我剛接入Redis時都沒怎么區(qū)分一股腦都往里塞結果發(fā)現TTL設置混亂有的緩存過期太慢導致數據明顯滯后有的太短導致命中率很差。后來專門按類型梳理了策略。2.2 不值得緩存的場景我也交過學費后來明確劃出了不要緩存的幾類數據實時性要求極高的數據比如用戶當前余額、庫存余量。這類數據寧可讓Agent多查一次數據庫也不要緩存一秒鐘。強個人隱私的數據涉及用戶明文敏感信息的盡量不要往Redis放Redis只是內存數據庫不是安全邊界。一次性極低頻的數據緩存一個只有兩三個人會訪問的數據沒有任何意義反而增加了維護成本。一句話緩存的價值等于訪問頻率乘以構建成本不要對低頻數據做緩存。2.3 TTL設計按數據時效性與業(yè)務容忍度來定TTL過期時間我覺得是整個緩存設計里最需要動腦子的一環(huán)。設計TTL時不要拍腦袋我習慣先列一張表把每個緩存數據源的更新頻率、業(yè)務容忍度列清楚再往下定。數據種類推薦TTL緩存Key設計思路天氣、匯率等常規(guī)API5-10分鐘agent:tool:weather:{city}股票行情30-60秒agent:tool:stock:{code}系統(tǒng)提示詞模板永久版本號agent:prompt:sys:v{version}短期會話快照30分鐘-2小時agent:session:{sessionId}固定問題檢索結果24小時agent:rag:ask:{sha256(question)}關鍵點在于TTL不能統(tǒng)一設成一樣的。我見過很多團隊把所有緩存都設成十分鐘過期業(yè)務上有些數據十分鐘是合理的有些數據十分鐘早就失真了。TTL要在數據成本和業(yè)務新鮮度之間取平衡沒有放之四海而皆準的值。另外熱點緩存建議在過期時間上加一個隨機抖動。比如TTL設10分鐘實際緩存可以設成8到12分鐘隨機值。這個做法是為了避免大量hot key同時過期進而引發(fā)緩存雪崩后面第5章會詳細說。2.4 命中判定等值匹配與語義匹配緩存命中不一定是等值判定。對于工具調用參數我采用的是參數序列化后做hash的方式也就是sha256(參數JSON)簡單可靠任何語言都能復現。但對于用戶自由輸入的問題比如RAG場景同一意思的不同表達會造成大量緩存miss。比如今天天氣怎么樣和今天天氣如何其實是同一個問題等值緩存完全識別不了。我實測下來如果Agent高頻回答的是一小類固定問題可以引入語義緩存把用戶query先embedding用向量相似度去匹配歷史問題相似度超過0.92直接返回對應結果。不過要提醒一下語義緩存不是默認選項。embedding本身也有成本如果Agent并不是面向大規(guī)模同質化問題引入它反而會拖慢鏈路。我在一個客服Agent項目里試過語義緩存命中率確實上去了但響應時間也被embedding和向量檢索拖慢了。后來只在Prompt分類這個環(huán)節(jié)用了語義信息工具場景全部改回等值緩存效果反而更好。3. 會話狀態(tài)與長期記憶用Redis搭建Agent的臨時大腦Agent的會話管理是Redis另一個核心用武之地。和普通Web會話不同Agent會話往往需要承載更多信息多輪對話歷史、中間推理片段、臨時記憶、已調用的工具結果。這些數據如果全放內存服務重啟就丟了全放數據庫讀寫效率不夠高。Redis剛好介于兩者之間適合承擔臨時大腦的角色。3.1 會話數據到底用Hash還是String這是我被問得最多的問題。很多人在Redis里存儲會話喜歡直接SET session:{id} {大JSON字符串}簡單直接。但這種做法有幾個隱患第一整個JSON串只有一個key你想單獨更新某一天的歷史消息必須把整個大JSON讀出來、反序列化、改完再寫回去第二字符串類型在Redis里對內存的利用相對低效尤其是這種頻繁變動的結構化數據。我的建議是用Hash來存多輪會話。一個會話ID對應一個Hash每一輪對話作為Hash里的一個fieldfield名是消息ID或時間戳field值是消息JSON。優(yōu)點很明顯追加一輪新對話只要HSET一個新field不需要動整個會話。要取最新N輪HGETALL拿全部代碼里再截斷或者維護一個Sorted Set做分頁?？梢葬槍δ骋粭l歷史消息單獨過期或刪除。下面是一個簡單的存儲示意HSET agent:session:abc123 \ round:001 {role:user,content:今天天氣怎么樣} \ round:002 {role:assistant,content:北京今天晴12到22度} \ round:003 {role:user,content:明天呢} \ round:004 {role:assistant,content:我查一下明天的情況...}每次對話追加新內容時再HSET新的field即可多個實例同時操作同一個會話也不會互相覆蓋因為Redis命令是原子性的。3.2 用Sorted Set來管理記憶時間線除了即時會話Agent系統(tǒng)還有一個長期記憶的需求用戶過去一周問了什么、偏好什么語氣、歷史訂單等都可能會影響當前回答。這類記憶具備兩個特點和時間強相關、需要按需裁剪遺忘。最適合的數據結構就是Sorted Set。思路是以記憶類型為key以記憶內容為member以時間戳為score。比如我存用戶感興趣的話題ZADD agent:memory:user:123:interests 1700000000 戶外跑步 ZADD agent:memory:user:123:interests 1705000000 攝影器材需要取近期記憶時用ZREVRANGE按score倒序拉取最近N條需要遺忘太久遠的記憶時用ZREMRANGEBYSCORE把某個時間戳之前的記錄清掉。這個模型非常貼近Agent記憶的真實語義不是把全部歷史都灌給模型而是按時間窗口取最相關的一部分。我在實際項目里還會給記憶加一個訪問計數放在ZSET的score里混合編碼用來決定哪些記憶進入Long-term storage這個后面有時間再展開。3.3 過期策略Agent服務的Redis別用allkeys-lru會話數據本質上是有生命周期的不可能無限膨脹。Redis提供了多種內存淘汰策略我建議在Agent場景里謹慎選擇。allkeys-lru是默認常見配置它的意思是當內存滿了不管key有沒有設過期時間一律按LRU淘汰。這對緩存工具結果來說沒問題但對會話數據可能是災難一個正在進行的會話可能因為內存壓力直接被淘汰用戶對話到一半Agent失憶了。我推薦用volatile-lru只淘汰那些設置了TTL的key不設TTL的關鍵配置數據比如限流版本號、白名單永遠不會被動淘汰。對應地會話快照、緩存結果這些要顯式設置過期時間把淘汰決策權交給Redis的TTL機制。這里有一個我一直用的配置組合maxmemory 1gb maxmemory-policy volatile-lru另外必要的持久化也要開。Agent會話丟了很影響體驗AOF的appendfsync everysec配置通常是個可接受的中間點最多丟一秒的會話數據但換來了不錯的性能。3.4 會話一致性與跨實例同步實際線上Agent很少是單機部署基本都是多實例負載均衡。如果沒有統(tǒng)一的狀態(tài)層用戶的兩次請求落到不同實例Agent會完全忘記上一輪說了什么。Redis在這里承擔共享狀態(tài)層的角色所有實例都從同一個Redis讀寫會話天然解決了多實例會話一致性問題。但也正因如此Redis一定要用帶高可用方案的部署形態(tài)比如哨兵或者集群。會話數據服務掛了整個Agent的服務能力會瞬間歸零這個重要性怎么強調都不為過。4. 并發(fā)治理分布式鎖、限流與任務隊列的實戰(zhàn)配方AI Agent怎么扛并發(fā)這個問題在這些熱度詞里排得非常高說明大家真正關心的是Agent不僅僅是跑得通還要在流量上來之后依然跑得穩(wěn)。好消息是Redis在這塊已經有非常成熟的套路只是需要針對Agent場景做一些定制。4.1 分布式鎖解決同一個任務被并發(fā)觸發(fā)的問題Agent場景比普通接口更容易出現重復執(zhí)行問題。舉個例子用戶點了幫我查一下公司年收入然后因為頁面卡頓又點了一次。這兩個請求會同時到達系統(tǒng)。如果Agent內部沒有鎖控制兩次查詢就會并行執(zhí)行浪費雙倍外部API配額甚至可能對下游產生重復扣款等不可控后果。更典型的場景是定時任務與用戶指令“撞車”晚上七點的定時總結任務觸發(fā)了用戶剛好在那個時間點手動問了同樣的問題。Redis分布式鎖是最簡單可靠的方案。核心命令SET lock:agent:task:{userId} unique_token NX EX 30NX保證同一把鎖只能被一個實例拿到EX 30設鎖自動過期防止持有鎖的實例掛掉導致死鎖unique_token是每個請求生成的唯一ID釋放鎖時只允許持有者釋放釋放鎖一定不能用DEL要配合Lua腳本比對token防止誤刪別人的鎖。我在工程上用的釋放邏輯-- KEYS[1]: 鎖名 -- ARGV[1]: 當前請求的唯一token if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end還有一個值得注意的細節(jié)鎖超時時間不能小于Agent單輪任務的預估最長時間。Agent的執(zhí)行鏈路跟普通接口很不一樣它可能調用兩三次LLM中途還會做工具調用整個流程很容易超過5秒。鎖設30秒是比較安全的起步值但如果Agent內部出現重試單輪任務可能超過這個時間建議用Redisson或自己做一個看門狗續(xù)期在任務未完成時自動延長鎖的過期時間。4.2 限流令牌桶擋住突發(fā)流量Agent服務最怕突發(fā)流量。這里的突發(fā)既指用戶側突發(fā)比如一場營銷活動帶來大量用戶也指Agent內部的自我請求放大一次用戶請求可能觸發(fā)多次LLM調用。如果不對上游API調用做限流上游會直接把你的Agent服務限流甚至封禁。我在項目里用Redis實現的是一個基于Lua的令牌桶邏輯是每個桶有一個容量和填充速率請求到達時如果桶里有令牌就放行否則直接拒絕。-- KEYS[1]: 桶名稱 -- ARGV[1]: 桶容量 -- ARGV[2]: 每秒填充令牌數 -- ARGV[3]: 當前時間戳毫秒 local capacity tonumber(ARGV[1]) local rate tonumber(ARGV[2]) local now tonumber(ARGV[3]) local last redis.call(get, KEYS[1] .. :last) if not last then last now end local tokens tonumber(redis.call(get, KEYS[1] .. :tokens) or capacity) local elapsed math.max(0, (now - last) / 1000) tokens math.min(capacity, tokens elapsed * rate) if tokens 1 then redis.call(set, KEYS[1] .. :tokens, tokens - 1) redis.call(set, KEYS[1] .. :last, now) return 1 else redis.call(set, KEYS[1] .. :tokens, tokens) redis.call(set, KEYS[1] .. :last, now) return 0 end這套邏輯跑在Redis里天然是原子的限流判斷和令牌扣減不會出現并發(fā)競態(tài)。我在Agent網關層對LLM API調用、搜索API調用分別建了不同桶限額按上游配額表來配。實測下來最明顯的變化是上游限流報錯幾乎消失了系統(tǒng)也不再因為API重試進入死循環(huán)。4.3 冪等與任務隊列把同步請求拆成異步流水線Agent的很多任務其實不需要同步返回。比如總結一下我這周所有郵件這個操作要調搜索、調郵件服務、再組織語言耗時可能幾十秒甚至幾分鐘絕不適合讓用戶HTTP請求一直掛著。我傾向把這類任務拆成異步流水線Redis的List正好能當任務隊列用。LPUSH把任務塞進隊列Worker用BRPOP阻塞消費# 入隊 redis_client.lpush(agent:tasks:summary, json.dumps({ user_id: 123, task_type: weekly_summary, created_at: time.time() })) # Worker 消費 while True: _, payload redis_client.brpop(agent:tasks:summary, timeout10) task json.loads(payload) execute_task(task) # 真正執(zhí)行任務這里面有一個可靠性技巧我想強調直接用BRPOP出隊后如果Worker執(zhí)行中崩潰任務就丟了。我采用額外List做處理中隊列用RPOPLPUSH把任務從待辦列表原子地移動到處理中列表任務完成后再確認刪除。如果超時還沒確認就把任務重新放回待辦列表。這套機制不復雜但能讓Agent的異步任務基本達到at least once的交付保證。5. 才踩過的坑緩存穿透、序列化、連接池和Key命名技術方案初具雛形還不夠生產環(huán)境真正要命的全是細節(jié)。我在這條路上踩過的坑絕對比成功經驗值得寫。5.1 緩存穿透和負緩存Agent場景非常容易出現緩存穿透。用戶問一個不存在的股票代碼、一個錯誤的地名Agent對上游發(fā)起請求拿到一個空結果但因為結果為空你下意識不會去緩存下次相同請求來了又穿透一次。真實翻車案例是我做過一個基金問答Agent用戶問幫我查一下xx基金凈值但用戶打錯代碼Agent查不到數據每次都會真去調用第三方接口。偏偏這個錯誤代碼被幾個用戶連續(xù)問了幾十次第三方接口的當日調用量直接被刷高。解決方案是負緩存即使上游返回空結果也緩存一個臨時空標記TTL給短一點比如30到60秒表示這個key短時間內查不到值。這樣同樣的錯誤問題再涌來時Agent直接命中空緩存不會再穿透到上游。5.2 緩存擊穿與雪崩熱點會話和集體過期擊穿和雪崩是兩個不同問題但Agent場景里都會遇到。緩存擊穿某個熱點問題比如怎么查賬單的緩存剛好過期一瞬間大量同質化請求涌入全部miss然后同時打到上游服務。解決方案上面的TTL抖動只能算輔助真正可靠的還是前面提的分布式鎖在緩存miss后只讓一個請求去加載真實數據其他請求等待并復用那個加載結果。這個模式也叫singleflight我實際測試過能把峰值打到上游的壓力降掉90%以上。緩存雪崩大量key在同一時間過期導致流量同時落入底層。我見過有人把系統(tǒng)里所有緩存統(tǒng)一設成緩存1小時結果每個整點所有key集體失效定時任務一定點出發(fā)數據庫和API就被打穿。解決辦法是過期時間加上隨機數比如10分鐘的TTL實際設為8到12分鐘。這一點看起來不起眼卻是線上最能保命的小技巧。5.3 序列化別用JDK默認序列化尤其是跨語言團隊序列化這個問題平時開發(fā)根本不會注意直到線上出了問題才明白。我見過某團隊用Java的JDK默認序列化往Redis里存對象Java側讀寫沒問題但后來同一個Redis被Python寫的Agent消費直接報反序列化錯誤?？缯Z言協作在AI Agent時代幾乎必然發(fā)生一套通用的序列化格式極其重要。我現在統(tǒng)一用JSON字符串存儲內部字段名固定加了一個版本號這樣可以控制演進。壓縮方面超過幾KB的大文本會考慮GZIP壓縮。有一說一目前很多Agent項目的響應體都是KB級別的文本不太需要壓縮但如果上下文非常大比如幾十KB級別的RAG片段壓縮能省不少內存。小建議如果多個服務共用一個Redis一定不要把序列化邏輯藏在各自的代碼里而是在公共模塊里約定一種統(tǒng)一格式。這個約定最好寫成文檔面試聊到Redis序列化的時候也是能加分的點。5.4 連接池與超時參數連接池問題經典但常被忽略。Agent并發(fā)上來后如果每個請求都新建Redis連接系統(tǒng)會先被打垮的就是連接數而且單條命令執(zhí)行時間一旦變長會占著一個連接不放。我在生產里遇到過redis command timed out的報錯根因不是Redis沒響應而是連接池的等待時間太長大量連接被慢命令占住新來的命令拿不到連接。后來在客戶端層面做了三個調整合理設置連接池大小標準是maxTotal略大于預期并發(fā)數同時設置maxIdle不小于minIdle打開連接池等待超時連接不夠時快速失敗而不是無限等待拖垮整個線程池給單個Redis命令設置超時時間單個命令超過幾百毫秒就要告警另外體系里盡量少用KEYS這種全量掃描命令用SCAN替代。一次KEYS user:*在生產Redis上可能會阻塞幾秒這個時間點在Agent高并發(fā)場景下足以引發(fā)連環(huán)故障。5.5 Key命名規(guī)范與可觀測性最后一項不涉及性能但直接決定排查效率。我最初寫代碼時Redis key是隨便取的比如user:123后來發(fā)現不同業(yè)務模塊之間互相覆蓋或者定位問題根本不知道這個key在哪個環(huán)節(jié)寫的?，F在我統(tǒng)一按這個規(guī)范命名agent:{環(huán)境}:{業(yè)務模塊}:{對象類型}:{ID}。舉個例子agent:prod:session:abc123 agent:prod:tool:weather:beijing agent:prod:lock:task:user_456好處是通配篩選的時候特別直觀SCAN agent:prod:session:*就能掃出所有會話緩存。配合INFO KEYSPACE里面的expired_keys指標以及SLOWLOG檢查慢命令線上Redis運行狀態(tài)基本都在掌握了。Redis的監(jiān)控不能全靠人肉盯。建議把used_memory、expired_keys、evicted_keys、connected_clients這些關鍵指標接入PrometheusGrafana或者云監(jiān)控設置告警閾值。Agent項目跑起來之后你會非常慶幸這些指標是自動報警的而不是等用戶先反饋。最后再分享一個經驗分布式鎖、限流、緩存、隊列這些東西我第一次用Redis實現的時候也走了不少彎路。但一旦把Agent的這些基礎能力從散落在代碼里收攏到Redis統(tǒng)一承載并發(fā)和穩(wěn)定性的思考框架就清晰很多了。上線前一定記得做壓測把Agent的每一個工具調用、每一輪LLM請求都算進耗時時才能真的知道你搭的這套緩存和限流方案扛不扛得住。