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