1. 为什么AI Agent要跟Redis扯上关系1.1 一个让人头疼的真实场景先说个我最近处理的线上问题。我们组做了一个基于大模型的客服Agent刚上线那会儿并发一上来用户反馈特别直接问一句要等十几秒连续问两三句就卡死偶尔还出现答非所问——同一个问题隔一分钟问答案居然不一样。第一反应是调大模型接口的并发结果发现钱烧得飞快每次对话都要把整段历史记录发给模型重新算一遍几十轮上下文塞进去Token消耗直接翻倍。后来检查日志才发现真正拖垮系统的根本不是模型推理耗时而是会话状态的管理方式——所有上下文都存在进程内存里实例一重启就丢负载均衡一转发就串场用户在不同实例上问问题Agent根本认不出这是同一个人。这时候我才真正意识到AI Agent的瓶颈往往不在智能而在记忆和组织。而解决记忆和组织问题的标准答案里Redis几乎是绕不开的那一个。1.2 三个让Agent性能崩塌的高频瓶颈结合我们项目和其他同行踩过的坑我总结出AI Agent最典型的三类性能瓶颈每一类都跟缓存有关第一类上下文反复重算。Agent每轮推理都要携带完整的历史消息消息越长Token消耗越大响应越慢。如果能把中间结果、工具返回的数据、甚至用户的重复问题缓存起来很多计算是可以直接跳过的。第二类会话状态没有统一出口。分布式部署下Agent实例是多个但用户只有一个。会话状态放内存实例之间互相不认识放数据库每次读写都走磁盘慢得难受。Redis作为中间件把会话状态放在所有实例共享的存储里天然解决这个问题。第三类热点数据重复查。Agent经常要查商品信息、用户画像、库存状态这些数据从数据库里读一遍要好几毫秒甚至几十毫秒但它们的更新频率其实很低。这种情况不缓存等于把数据库的命根子交给流量。这三类问题有个共同特征问题的根源不是模型能力而是架构设计里缺了一层缓存。Redis正好就是为这种事而生的——内存级读写速度支持丰富的数据结构带过期时间还天然支持分布式。2. 先想清楚Agent的缓存到底在缓存什么2.1 缓存对象拆解会话上下文、工具结果、重复计算很多人一听Redis缓存第一反应是把数据库查询结果往里塞。但在AI Agent的场景里这句话只说对了一半。我按数据特征把Agent里值得缓存的内容拆成了三层第一层会话上下文。这是Agent区别于普通Web应用最核心的缓存对象。用户和Agent的对话历史、当前会话状态比如用户填到哪一步了、中间推理结果都适合放Redis。注意我强调的是缓存而非存储——重要会话的最终记录还是应该落到数据库做持久化Redis里放的更多是进行中的状态和短期上下文。第二层工具调用结果。Agent经常会调外部API或者查数据库比如天气查询、订单状态查询、库存查询。这类数据有明确的时效性有的五分钟一变有的一周一变。把这些结果按Key缓存起来TTL一到自动失效能省下大量外部API调用费用和数据库压力。第三层重复计算的结果。这一层最容易被忽略。比如Agent要做文本分类、意图识别甚至只是简单的关键词匹配如果输入完全相同的文本在短时间内反复出现完全可以缓存计算结果。我在电商客服场景里实测过用户反复问退款多久到账这种问题命中缓存时整个响应链路能从3秒降到50毫秒。2.2 Key设计用命名空间和版本号管理缓存结构缓存设计里最容易翻车的不是存储而是Key的规划。我见过团队把缓存Key直接拼成user:123:session:456:history一眼看去没问题但一旦要批量清理或者做灰度基本只能靠瞎猜。我的建议是给缓存Key加上命名空间和版本号格式统一为agent:{业务模块}:{数据类别}:{ID}:{版本标识}举个例子agent:chat:session:{sessionId}:v1—— 会话上下文agent:tool:order:status:{orderId}:v2—— 订单状态查询结果agent:llm:intent:{textHash}:v1—— 意图识别结果缓存这里有两个实操细节一是textHash别直接拼长文本对文本做一次hash比如MurmurHash或者MD5取前16位控制Key长度。二是版本号一定要留。一旦业务逻辑变了比如Prompt升级了或者数据字段改了把Key里的版本号一换新老数据自动隔离不用写复杂的清理逻辑去把旧缓存一条条删掉。2.3 失效策略不是所有数据都要TTLRedis的过期策略要分场景一刀切最害人。会话上下文给一个相对宽松的TTL。用户可能聊着聊着去忙别的十分钟后回来说刚说的那个订单呢上下文还在体验就好很多。我习惯设置在15到30分钟结合主动续期——用户每次发消息就重新刷一下过期时间。工具结果严格按数据本身的时效性来。订单状态5分钟天气信息30分钟商品详情2小时宁可多调几次接口也不能给用户看到过期信息。重复计算结果给短TTL比如10到60秒。意图识别、关键词分类这类计算用户不太可能在几秒内重复提交完全一样的内容但热点用户确实会短TTL既有效果又不至于失真。注意Redis的过期策略是惰性删除配合定期删除。惰性删除的意思是key过期了但还没被访问它就不会被立即清理掉。如果担心大量key堆积可以让Key带上时间戳配合定期扫描清理。3. 一个能直接抄的Agent缓存落地结构3.1 基于Spring AI的缓存接入流程我们团队技术栈是Java Spring Boot用的Spring AI框架来编排Agent。我先说这个组合下的落地流程其他语言比如Python的LangChain、Rust的Agent框架思路完全一致只是SDK换一下。第一步是引入依赖。Spring Boot下最省事的方式是Spring Data Redisdependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency第二步是配置连接池。这里有个严重被低估的坑单连接复用远不如连接池来得稳。Agent接口本身就是高延迟场景一个请求可能要5秒到10秒如果期间一直占着同一连接做Redis操作并发一上来连接必然不够用。我用的是Lettuce连接池的配置spring: data: redis: host: your-redis-host port: 6379 timeout: 3s lettuce: pool: max-active: 32 max-idle: 16 min-idle: 4 max-wait: 2smax-active设32是个比较稳的经验值太小扛不住突发流量太大Redis本身压力也大。max-wait设2s是为了防止高并发时线程全部卡在等连接上把应用拖死。第三步是序列化方案。很多项目用JdkSerializationRedisSerializer默认序列化完是二进制乱码存进去的东西在可视化工具里完全没法看排查问题时很绝望。我在项目里直接强制换成Jackson序列化虽然占用空间稍微大一点但可读性对排查问题太重要了。Configuration public class RedisConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); ObjectMapper om new ObjectMapper(); om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY); om.activateDefaultTyping(LaissezFaireSubTypeValidator.instance, ObjectMapper.DefaultTyping.NON_FINAL, JsonTypeInfo.As.PROPERTY); GenericJackson2JsonRedisSerializer serializer new GenericJackson2JsonRedisSerializer(om); template.setKeySerializer(RedisSerializer.string()); template.setHashKeySerializer(RedisSerializer.string()); template.setValueSerializer(serializer); template.setHashValueSerializer(serializer); template.afterPropertiesSet(); return template; } }序列化方案确定后所有缓存对象才能安全读写。注意一个兼容性问题对象结构一旦加了字段会导致反序列化报错。方案是给实体类加版本号字段升级时做兼容映射。3.2 会话缓存的读写封装接下来是Agent核心场景的会话读写。我先定义了一个SessionCacheService专门负责会话上下文的CRUDService public class SessionCacheService { private static final String SESSION_KEY_PREFIX agent:chat:session:; private static final Duration SESSION_TTL Duration.ofMinutes(30); Resource private RedisTemplateString, Object redisTemplate; public void saveSession(String sessionId, ChatSession session) { String key SESSION_KEY_PREFIX sessionId; redisTemplate.opsForValue().set(key, session, SESSION_TTL); } public OptionalChatSession getSession(String sessionId) { String key SESSION_KEY_PREFIX sessionId; ChatSession session (ChatSession) redisTemplate.opsForValue().get(key); return Optional.ofNullable(session); } public void extendSessionTtl(String sessionId) { String key SESSION_KEY_PREFIX sessionId; redisTemplate.expire(key, SESSION_TTL); } public void clearSession(String sessionId) { String key SESSION_KEY_PREFIX sessionId; redisTemplate.delete(key); } }这段代码本身很简单但有一个操作习惯必须养成每次用户发消息先调extendSessionTtl续期。这样用户聊一个小时后回来上下文还在而不是死板地按第一次进入会话的时间算30分钟。这个细节对用户体感影响很大——你总不希望用户刚离开五分钟回来Agent就一脸茫然地问你是谁。另外会话上下文里塞的东西要克制。别把大段系统Prompt塞进缓存那部分是静态配置每次从配置文件读就行。缓存里只放动态信息用户消息历史、工具返回结果、Agent中间推理状态。控制单条会话缓存大小在10KB以内对Redis和网络都是健康负担。3.3 工具结果缓存省下真金白银工具结果缓存这块直接带来的收益是省API调用钱和降低第三方服务压力。我们有个天气查询Agent之前每来一个问题就调一次天气API一天下来几千次调用每千次调用账单上就是几十美元。加了缓存之后效果很明显public String queryOrderStatus(String orderId) { String cacheKey agent:tool:order:status: orderId :v1; Object cached redisTemplate.opsForValue().get(cacheKey); if (cached ! null) { return (String) cached; } String result orderApi.queryStatus(orderId); redisTemplate.opsForValue().set(cacheKey, result, Duration.ofMinutes(5)); return result; }核心逻辑就是先查缓存没有命中再回源。这里有两个值得说的细节第一个是缓存穿透防护。如果orderId本身不存在API返回查无此单这时候也要把这个空结果缓存下来TTL可以短一点比如2分钟。否则攻击者或异常调用可以拿不存在的ID绕开缓存直接把打满后端API。第二个是缓存击穿防护。热点订单比如大促期间爆款订单的缓存一旦失效瞬间会有大量请求同时走后端API。两种处理策略一是加互斥锁只让一个线程回源其他线程等结果二是热点Key永不过期靠后台任务主动更新。Agent场景里我推荐方案二因为工具结果的数据量通常可控后台定时刷新更为直观。4. 扛并发Redis在Agent高并发场景下的特殊玩法4.1 分布式锁防止重复调用同一外部APIAgent多了以后系统容易滋生一个隐蔽问题——并发场景下的重复工具调用。举个例子两个用户几乎同时触发查询同一订单物流的动作如果系统没有约束会有两个请求同时打到快递API。再严重一点如果Agent具备自动发货自动退款这类写操作能力并发重复执行就会造成资金风险。用Redis做分布式锁是目前成本最低的解法。基于Spring Data Redis的代码如下public boolean tryLock(String key, String requestId, long expireSeconds) { Boolean locked redisTemplate.opsForValue() .setIfAbsent(key, requestId, Duration.ofSeconds(expireSeconds)); return Boolean.TRUE.equals(locked); }注意这里的两个细节一是setIfAbsent加过期时间必须是原子操作。用set加expire两步走中间宕机就锁死。二是value放requestId请求唯一标识解锁时先对比requestId再删Key防止一个线程把另一个线程的锁误删了。public void unlock(String key, String requestId) { String value (String) redisTemplate.opsForValue().get(key); if (requestId.equals(value)) { redisTemplate.delete(key); } }实际使用中锁粒度要控制好。按订单维度加锁而不是全局锁否则一个慢请求会阻塞所有Agent的工具调用流程。锁的过期时间建议设置成接口平均耗时的3到5倍给慢调用留足余量。4.2 限流降级别让模型接口被一个用户打满AI Agent的另一个并发难题是模型接口的成本型限流。外部大模型API的调用按Token计费同一个用户疯狂刷对话账户余额很快就会见底。用Redis做一套简单的用户级别限流比在应用层做内存计数强得多因为分布式环境下内存计数器根本不准。我的实现思路是滑动窗口加计数器public boolean checkRateLimit(String userId, int maxCalls, long windowSeconds) { String key agent:ratelimit: userId; Long count redisTemplate.opsForValue().increment(key); if (count ! null count 1L) { redisTemplate.expire(key, Duration.ofSeconds(windowSeconds)); } return count ! null count maxCalls; }这个做法的精髓在于第一次请求时计数为1同时设置整个窗口期的过期时间后续请求只递增计数不用再刷TTL。窗口滑动靠Redis天然的过期机制完成。实测单机Redis每秒能扛住几万次这这种操作限流逻辑放在这层对Agent整体性能几乎没有感知影响。但这里提醒大家注意限流之外的降级方案也必须提前设计。Redis一旦挂掉限流逻辑怎么处理我的方案是Fail-Open放行但记录日志保证Agent服务可用性优先。宁可让缓存作为辅助层失效也不能让缓存反过来成为整个Agent系统的单点故障。4.3 缓存穿透、击穿、雪崩的Agent版本这三个经典缓存问题在Agent场景下会换上Agent特色的马甲穿透恶意用户或者异常代码构造不存在的用户ID、不存在的订单号每次都绕过缓存直达底层数据库或外部API。解法就是前面提到的空值缓存。击穿某个热点会话上下文突然过期同时几百个请求都要读它。这时候回源会一次性消耗大量Token。解法是热点会话不设置固定过期时间改为后台定时续期。雪崩大量会话缓存集中在同一时间过期。这通常是因为所有会话都在同一时刻创建TTL又设成固定值。解法很简单——给TTL加随机扰动。比如30分钟过期实际设置成25到35分钟之间的随机值让过期时间均匀错开。Duration ttl Duration.ofMinutes(30 ThreadLocalRandom.current().nextInt(10) - 5);这一行代码能省掉绝大多数缓存雪崩引发的大模型API风暴。5. 缓存治理线上踩坑实录与排查链路5.1 一次会话错乱的排查过程这里分享一个我们线上真实踩过的坑排查链路比较典型。现象是客服Agent偶尔会把用户A的消息回复给用户B。这个问题最诡异的地方在于概率性出现没有固定复现路径压测时稳定生产环境随机炸。第一轮排查先看应用日志。发现错误消息的内容本身没错只是归属的会话对不上。接着查Redis里的会话记录通过可视化工具检查缓存数据结果发现同一个sessionId对应的value确实是正确的。到这里问题范围缩小到读出来的数据是对的但返回给用户时串了。第二轮排查检查Controller层的异步处理。我们用的WebFlux响应式编程问题在这里找到了——Agent处理完异步结果后返回用户时用的上下文对象里存的是一个会话引用而不是会话ID的副本。上下文对象被线程池复用时如果没做清理后面的请求就会拿到上个请求的会话引用。修复方案很明确异步返回前把上下文对象里所有可变引用重置只保留从Redis查到的会话快照。顺带在Redis里把会话快照的读取做成每次独立获取而不是缓存引用。这次事故给我的教训是Redis本身没毛病但用它存的数据在并发读写时要格外注意引用传递导致的共享可变状态问题。5.2 缓存可视化用Another Redis Desktop Manager排查数据排查问题离不开趁手的工具。我在多个环境里试过Redis Desktop Manager和Another Redis Desktop Manager后者的内存占用更低对生产环境的超大Key扫描更稳。用它的价值主要在两块一是按前缀扫描Key。检查agent:chat:session:*底下有多少条会话、分布是否均匀、有没有异常堆积。我常常用它一眼看出某个模块的缓存Key是不是被参数污染了比如订单ID拼进去时没做hash导致Key无限增长。二是直接看序列化后的内容。调整过序列化配置后工具里直接看到JSON格式的会话数据和工具结果排查效率翻倍。再配合工具自带的命令窗口跑TTL、MEMORY USAGE、SLOWLOG之类的Redis命令基本上线上缓存问题半小时内能定位。5.3 不该被缓存的敏感数据聊了这么多缓存设计最后必须强调一个底线问题。Agent的会话里可能有用户手机号、地址、身份证信息工具结果里可能有订单金额、支付状态。这些数据不是不能进Redis而是要有明确的红线第一条红线是加密分离。不能把密文和明文直接当value存。我的做法是敏感字段单独做加密加密后的字符串才放进Redis解密只在业务层做。即使Redis被拖库泄出去的也是密文。第二条红线是权限和审计。Redis的访问应该有独立的账号和密码并且限制只允许内网访问。同时开启Redis的慢日志和审计功能记录下所有对agent:*前缀的访问。我们团队有次排查安全风险时就是靠慢日志发现某个测试环境的Redis端口意外暴露了的。第三条红线是C端数据不留长TTL。用户会话上下文最长不超过一天敏感的工具结果最长不超过30分钟。宁可损失一些效率也不能让用户数据在缓存里躺太久。6. 什么时候不该用Redis缓存6.1 本地缓存和Redis的分工Redis不是万能的。Agent系统里有些场景用本地缓存比如Caffeine反而更合适单个实例内频繁访问、且数据几乎不变的内容比如系统Prompt模板、模型的接口配置、工具列表描述。这些数据每个实例自己存一份就够不值得网络IO。数据量特别小且访问极其频繁的热点Key比如当前可用模型列表几百字节的数据本地缓存比Redis快一个数量级。但本地缓存有个致命问题多实例间不一致。所以我的分工原则是——全局必须一致的用Redis允许短时间不一致的用本地缓存两者结合。6.2 向量数据库不能替代RedisAI Agent的常见配置中有时还需要向量数据库如Milvus、Qdrant、pgvector做向量检索。很多初学者会把这两个东西搞混下意识觉得都是缓存用向量库存上下文不就行了。这两者的分工完全不同。向量数据库负责的是长期记忆和语义检索——用户问我上次那个退货的订单怎么样了Agent需要到向量库里做语义匹配找到对应历史记录。Redis负责的是短期状态和热点数据——当前会话正在进行到哪一步、这个订单最近查过结果是什么。Redis的强项是毫秒级精确读写向量库的强项是百毫秒级相似度搜索。用Redis做向量检索要么全量扫描性能不可接受要么必须引入RediSearch模块复杂度反而上去了。两者服务的不是同一个问题不要试图互相替代。7. 我的经验和建议最后分享几个我在多次踩坑后沉淀下来的实操建议。关于缓存优先级的排序会话状态 工具结果 重复计算。如果团队资源有限优先做会话状态的Redis化。这一步能直接解决分布式部署下的会话错乱问题收益最明显。工具结果缓存属于用时间换金钱的优化短期收益藏在API账单里需要拉数据对比后才能体会到。重复计算缓存则是锦上添花建议放在前两项稳定之后再做。引入Redis不要一步到位。先从单个会话缓存服务做起跑通后再扩展工具结果缓存、分布式锁、限流。一上来就把所有功能铺开配置和排查问题的复杂度会直接在发布期爆发。稳扎稳打才是AI Agent项目该有的节奏。