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