把AI Agent从Demo推到线上，第一波崩溃往往不是模型太笨，而是并发进来之后会话上下文跟开玩笑一样到处丢。我接手维护过一个基于大模型做的客服Agent，上线两周接口超时率飙到三成，日志里全是超时报错，定位到最后才发现问题根本不是模型响应慢，而是所有用户上下文都堆在进程内存里，多实例部署后负载均衡一转发，Session直接错乱。那次之后我把Redis正式纳入Agent架构，从会话记忆、并发限流到任务队列全部重做了一遍，才把系统真正扛住。这篇文章就把这套打法完整拆开讲讲，适合正在做AI Agent落地、被并发折腾得睡不着觉的后端工程师，也适合准备把LLM产品化的技术负责人参考。
1. 当AI Agent开始承接真实流量：第一个崩溃从哪里来
1.1 Agent不是"调个接口"那么简单
很多人一开始做Agent，觉得就是在后端调一次大模型API返回文本。但真实业务里的Agent是个多步骤状态机：用户问一句，Agent要决定是否调用工具、查知识库、拼接上下文、再次请求模型、校验输出，一整轮下来可能需要几秒钟。这个过程中最脆弱的就是上下文——用户上一轮说过什么、Agent调用过哪些工具、中间结果怎么缓存，都要在下一次请求时继续沿用。
HTTP接口天然无状态，你不可能让每次请求都从头把历史聊一遍，那样token开销直接爆炸。所以Agent服务必须有个地方把会话中间态放进去。最开始我图省事用进程内ConcurrentHashMap，单机跑没问题，一旦部署副本超过一个立刻露馅：用户在A实例聊两句，下一次请求被负载均衡转发到B实例，A实例内存里的上下文B看不到。轻则答非所问，重则直接报“会话不存在”。这就是Agent上生产环境必踩的第一道坎：状态必须外置。
有人会说我用数据库存不就行了？MySQL确实能存，但Agent对上下文读写的特征是高频小数据量、延迟要求极高、过期逻辑复杂。你把每次对话轮次都落MySQL，一个活跃用户一天可能几百次读写，DB连接难扛且慢，更别提清理过期会话还得定时任务扫表。此刻Redis的价值就出来了。
1.2 Redis为什么会在Agent技术栈里成为标配
做AI Agent选Redis，先说三个最直接的理由：
- 快：走网络比跨进程调内存慢不了多少，Response Time稳定在亚毫秒级，Agent一次决策链路要串好几次缓存读写，整体延迟仍然可控。
- 数据结构全：ZSET天然适合按时间排序的消息列表，HASH适合存用户画像字段，List/Stream能做任务队列，SET NX能实现分布式锁——Agent需要的会话、限流、幂等、队列几乎都被Redis原生数据结构覆盖，不用自己造轮子。
- 分布式能力现成：多实例共享访问，天然解决Session漂移问题。配合主从或集群模式，挂了还能切换。
后面聊的所有方案，核心逻辑都是把Redis当成Agent的“操作协调层”，大模型的计算没办法缓存，但会话状态、请求上下文、知识命中、并发控制这些脏活累活都可以交给Redis。搞明白这个定位，你就知道项目里每个缓存键该怎么设计了。
2. 会话状态与上下文：把Redis当成Agent的短期记忆中枢
2.1 用ZSET存多轮对话，而不是Hash或String
我先试过用String类型的JSON整体存会话，每次请求把整段历史取出来重新序列化，再整个覆盖写回去。数据量少时没问题，聊到十几轮上下文变成一个巨大的JSON串，读写开销越来越大；而且并发下两个人同时往会话里追加消息，后写覆盖先写，消息直接丢掉。后来又试过用HASH字段存单条消息，字段名设计成turn:1、turn:2，但是要按时间取最近N条就必须把全量字段拉回来，再在内存里排序，数据大了照样卡。
最终稳定方案是用ZSET存消息，member存消息内容，score存时间戳：
ZADD agent:chat:ctx:{sessionId} 1720000000000 "user:今天天气怎么样" ZADD agent:chat:ctx:{sessionId} 1720000001000 "assistant:建议您查一下本地气象台..."这样做的好处极其明显：
- 取最近20轮：
ZREVRANGE key 0 19，Redis直接按评分倒序返回，根本不需要业务侧排序。 - 清理太长的历史：
ZREMRANGEBYRANK key 0 -21，把排名靠前的旧消息批量删掉。 - 天然支持时间窗口：只需要按score做范围查询，比如只查最近30分钟的有效对话。
用ZSET看似只是选了个数据结构，实际上把后面所有会话维护逻辑都简化了。这个细节在面试里讲出来也很加分，它体现了你对Redis特性与业务场景的匹配理解。
2.2 TTL设计：短会话怎么变成长期记忆
会话缓存和普通缓存最大的不同是数据生命周期像金子一样值钱。给Agent会话设TTL有几档常见做法，我按使用场景分过类：
- 聊天式Agent（像客服机器人）：30分钟到一个小时没交互就整个淘汰。设置成
EXPIRE agent:chat:ctx:{sessionId} 1800，每次写入时刷新TTL，用户重新回来还能接着聊。 - 工作流式Agent（像数据分析助手）：用户可能隔一段时间回来查上次结果，TTL放宽到24小时。
- 长期记忆（用户画像、偏好）：不该受会话TTL管，单独用另一套前缀，比如
agent:user:{userId}:profile，通过更新业务事件来刷新。
这里特别说一下Redis过期机制：Redis的过期清理是惰性删除加定期抽样删除，不会秒删。如果大量key同时过期，到点的那一下Redis会额外消耗CPU去清理，可能导致请求处理变慢。所以批量创建会话的时候，TTL可以加一点随机偏移，比如1800 + (int)(Math.random() * 300)，避免大量会话在同一秒集体过期。这也是后面雪崩问题的一个预防措施。
2.3 上下文裁剪策略：Redis从不负责"无限记忆"
有了ZSET，最容易被忽略的问题是上下文的长度。很多人一股脑把几百轮对话全塞进Redis，取出来之后直接拼到Prompt里，结果模型输入远超上下文窗口，被截断，而且token费用居高不下。
我实际在项目里做的是分文件管理：Redis里只保留最近20到30轮的高频短期记忆；更早的历史压缩成一个摘要文本，单独存到另一个key里。每次Agent对话开始时做两段拼装：
- 先拉取摘要key里的历史总结；
- 再拉取ZSET里的最近轮次明细；
- 合并后作为完整上下文交给LLM。
这种方式虽然会丢失一些细节，但对大多数Agent场景完全够用。总结的产生可以在每N轮对话后触发一次模型调用，或者在用户主动结束会话时执行。你不需要实时更新摘要，背景里慢慢算就行。Redis在这里的价值就是让你可以快速读写短期记忆，同时给长期记忆一个稳定的存储侧，两个层级互不干扰。
3. 并发防护三件套：限流、分布式锁与任务队列
3.1 滑动窗口限流：先把瞬间流量挡回去
AI Agent上线后，最让我头皮发麻的场景是某个功能上了热搜，或者一条运营消息触达几万用户，瞬间进来的并发请求把后端打趴。大模型API本身有速率限制，后端假如不做限流，排队超时、报错、用户体验稀碎会一起爆发。
Redis做限流最常用的方案之一就是滑动窗口。用ZSET记录每个用户或每个IP的请求时间戳，每次请求先移除窗口外的记录，再统计窗口内数量，超过阈值就拒绝：
local key = KEYS[1] local now = tonumber(ARGV[1]) local window = tonumber(ARGV[2]) local maxCount = tonumber(ARGV[3]) redis.call('ZREMRANGEBYSCORE', key, 0, now - window) local current = redis.call('ZCARD', key) if current < maxCount then redis.call('ZADD', key, now, now) redis.call('PEXPIRE', key, window) return 1 else return 0 end这段Lua脚本用ZREMRANGEBYSCORE把窗口外的请求时间戳清掉，再统计当前窗口内请求数。如果没超限就加入当前时间戳并刷新过期时间，返回1放行；否则返回0直接拒绝。我用它做过单用户5秒10次的限流，也用同样的脚本按Key粒度扩展成全局限流。只有一个注意点：这套限流必须在网关入口或Agent服务入口做，而不是等请求进入Agent内部流程后再做，越早拦截越省资源。
3.2 分布式锁：解决重复触发和资源竞争的丑陋问题
Agent业务里有一种特别容易翻车的场景：用户点了按钮没等到响应又点了一下，或者定时任务触发和用户手动触发同时进行，导致同一个Agent任务被执行两遍。大模型调用很贵不说，两遍执行还会相互污染上下文。
这时候得用Redis分布式锁保证同一任务只有一个实例在跑。核心命令是SET key value NX PX timeout，在Redis 2.6.12之后一个命令就能完成原子操作：
SET agent:task:lock:{taskId} {token} NX PX 30000执行成功说明当前实例拿锁成功，可以执行任务；执行返回Nil说明锁已被其他实例持有，直接跳过。释放锁时不能直接DEL，要用Lua脚本先校验值再删，防止误删别人的锁。因为可能你的锁已过期被他人拿到，然后你把别人的锁删了：
if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end锁的超时时间要根据Agent任务时长留足余量，通常30秒起步，但也要避免时间过长让后续请求一直block。我给Agent任务做过“锁内续期”的增强：拿锁后起一个后台协程，每隔10秒检查任务还在跑就PEXPIRE续一次，防止长时间任务把锁耗尽自动释放。这一套做下来，线上重复执行的情况几乎归零。
3.3 任务队列：LLM调用异步化才能真正释放线程
把Agent请求做成同步接口确实开发简单，但问题在于一次Agent任务往往包含多次模型调用，中间还有工具调用，整个链路耗时可能超过10秒。后端的Tomcat线程被这种长任务占住，一旦并发稍微上来，线程池就撑死，其他所有接口全部连带变慢。
我对付这个问题的方法是把耗时任务扔进Redis队列异步执行。最朴素的方案是List：
- 生产者：
LPUSH agent:task:queue {json}； - 消费者：
BRPOP agent:task:queue 0。
BRPOP是阻塞读，队列为空时挂起等待，有任务立刻取出。多个消费者实例可以同时阻塞读，天然实现任务在多Worker之间的分发，而且List结构保证一个任务只被一个消费者取走，不会重复消费。
任务量大了之后建议升级到Redis Stream + Consumer Group，它能给你消费组、ACK、Pending List这些机制，某个Worker挂掉后任务不会丢，重新分配即可。我在项目里用Stream替换过List，最大的体感是故障恢复轻松很多，之前挂了消费者光靠手动排查，后来直接看Pending列表就能定位未处理的消息。队列这部分做扎实后，Agent同步接口只负责把任务入队然后立刻返回“已受理”，用户下次查询结果时再到Redis拿真正的产出，这套异步模式是撑住并发的大前提。
4. 知识记忆层的缓存治理：从短时会话走向长期偏好
4.1 语义缓存：相同的用户问题不该让模型算两遍
做大模型产品的人容易陷入一个执念：每个问题都让模型回答一遍。但实际业务里大量请求是重复或高度相似的，比如天气类Agent里十个用户里有八个都问“上海明天会下雨吗”。这种问题走完整Agent链路纯属浪费钱和算力。
语义缓存的思想是把用户问题的Embedding向量存进Redis，查询时先算当前问题的向量，再去Redis里比对相似度，相似度高于阈值就直接返回之前的结果：
- 存：
SET agent:sem:cache:{questionHash} {answerJson} EX 3600，同时把向量放在一个专门的小集合里用于比较。 - 查：算当前问题向量，遍历缓存集合，用余弦相似度计算，超过0.92就命中。
数据量小的时候直接在业务代码里遍历算相似度完全可行，几千条缓存毫秒级搞定。数据量大了再引入专门的向量检索服务，但前面这层Redis仍然可以承担“热数据入口”。语义缓存需要注意时效问题——涉及价格、天气、新闻这类动态信息的问句不能盲目命中缓存，我通常会给这类问题加一个“不缓存”的标记，或者TTL控制在两三分钟以内。缓存命中率做起来之后，模型调用成本肉眼可见地往下掉，这比任何代码优化都直接。
4.2 用户画像与长期记忆缓存结构
Agent除了短期聊天，还经常要做长期记忆的沉淀。比如电商导购Agent要记住用户偏好品牌和尺码，助教Agent要记住学员的学习进度。这类长期记忆数据结构上用HASH最合适：
HSET agent:user:{userId}:profile name "张三" size "L" brand "YT" HSET agent:user:{userId}:progress lastCourse "Python基础" score 86HASH的好处是字段级的读写非常轻量，更新一个偏好不需要把整个JSON取出来改。每个字段都可以单独管理TTL吗？不行，HASH过期是针对整个Key的。所以长期记忆的字段如果冷热差距大，我会再拆一层：高频字段单独String Key，低频大字段单独一个HASH Key，避免整个用户画像因为某个字段更新而集体续期，造成“该冷的冷不下来”。
长期记忆的更新时机也要把握好。我在实践里采用的是“对话结束时统一更新”，而不是每轮都写，因为大模型返回的偏好提取结果本身可能在多轮中反复变化，轮轮写会出现抖动。这个更新动作用Lua脚本做“读旧值、合并、写回”的原子操作，防止多个会话同时更新同一个用户画像时丢字段。
4.3 主动失效比被动过期更可靠
缓存界老生常谈的一条准则，在Agent场景下放大了十倍：被动过期永远不够。比如用户主动修改了收货地址，Agent回复里还在用旧地址；比如用户在小红书风格的推荐Agent里点了“我不喜欢这个”，画像里还留着“喜欢这个类目”的旧标签。等TTL过期再更新？用户早就体验完负面效果了。
所以必须建立主动失效机制。我一般在业务侧做了一个CacheInvalidationService，当用户资料更新、订单状态变化、知识库内容改版时，直接删除或重写对应缓存Key：
redisTemplate.delete("agent:user:" + userId + ":profile"); redisTemplate.delete("agent:sem:cache:" + knowledgeBaseVersion);删除比更新更稳，因为删除后下一个请求天然回源，从主库或模型重新计算结果再回填缓存，不会留下“修改一部分字段另一部分还是旧值”的中间态。主动失效的时机要嵌入业务事务的同一上下文，比如“数据库更新成功后立即清缓存”而不是“任务提交后异步清”，后者会出现一个很窄的窗口期里缓存还是旧值。这些细节看着碎，但都是线上事故换来的教训。
5. 落地过程里我踩过的坑：序列化、雪崩、连接池
5.1 序列化格式不一致，存进去容易读出来难
把Redis接入Agent时，最容易遇到的第一个技术坑是序列化。Spring Data Redis默认会用JdkSerializationRedisSerializer，你要是没注意，调试工具里看到的全是一堆\xAC\xED开头的二进制乱码，跨语言读数据基本不可能。而且Agent项目经常是Java和后端服务混布，Python脚本也要读同一个Redis里的上下文，这时候JDK序列化就是灾难。
我现在的做法是统一用String序列化所有缓存内容，业务数据以JSON字符串作为载体。如果不强迫要求跨语言互通，可以在Spring配置里把ValueSerializer换成GenericJackson2JsonRedisSerializer；但注意LocalDateTime这类时间字段直接序列化会报错，得提前在ObjectMapper里注册JavaTimeModule。更省事的方案是直接用StringRedisTemplate，读写都是字符串，自己在业务层做JSON的序列化和反序列化。少一层框架魔法，多一层明确控制，排查问题也容易得多。
5.2 缓存雪崩、击穿与穿透在Agent场景的特殊表现
缓存三大经典问题的概念大家都熟，但在Agent场景里它们有时披着另一层皮。首先说雪崩：很多人做会话TTL时图省事统一设成一个数，结果凌晨3点所有会话同时过期，下一秒早高峰用户全部重新发起对话，LLM调用潮水一样涌过来，模型API限流直接触发。解决方式还是那几句话：过期时间加随机偏移、多级降级、熔断保护。
穿透是另一个让我一度很头疼的问题：用户或爬虫拿一堆随机不存在的SessionId狂刷，每次请求Redis查不到就去调用Agent流程，白白消耗模型额度。应对穿透不能只靠布隆过滤器，因为会话ID是动态生成的，Redis里刚删除的上一个会话ID也可能被继续请求。实际的方案是：对不存在的会话ID也设置一个极短TTL的空值缓存，比如5秒，防止每次请求都穿透到模型侧去。
击穿在Agent场景里最常见的表现是热点知识库内容。某篇文档突然被大量用户引用，Agent每次都要回源解析文档再注入上下文，一旦单个Key的缓存到期，所有请求同时涌向同一个回源点。我的做法是加逻辑过期锁：回源前先抢锁，只让一个实例去重新生成缓存，其他实例先用旧值撑着。陈旧一点总比全面超时好。
5.3 Redis连接与实例选型：从单机到主从集群的路径
最后必须说的是Redis自身怎么部署。第一次线上事故就是Redis单机，某个大Key操作导致Redis主线程卡顿，所有请求的Redis命令全部超时，日志里狂刷RedisCommandTimeoutException，整个Agent集体不可用。那次之后我对Redis部署的理解彻底改变了。
单机Redis确实简单，但它撑不起Agent服务的核心依赖地位。我的建议路线是：
- 起步期：单机主从，读写分离，至少解决单点故障。
- 稳定期：哨兵模式做自动故障转移，客户端配置好连接池和超时，防止一个Redis节点挂了就全站瘫痪。
- 规模期：业务拆分多个Redis实例，会话缓存、限流队列、业务数据分开部署，互不干扰。
连接池参数也有讲究。以Lettuce客户端为例，max-active默认给8很可能不够用，我调大到32到64之间；timeout从默认的几秒缩短到3秒以内，宁可快速失败也别长时间阻塞调用方。Redis命令超时这个问题，十有八九不是网络慢，而是实例CPU被打满或者有bigkey操作阻塞了单线程，所以上线后务必开启慢日志监控，把耗时超过50毫秒的命令抓出来逐个处理。
我还吃过一个亏：Redis里存了超大JSON上下文，读取一次要几十毫秒，看似没问题，但叠加高并发后Redis主线程被拖慢，其他所有命令跟着遭殃。后来再处理会话大对象，我都主动拆成多个小Key或者用Stream做分段存储，绝不把一个会话的一整段历史做成一个巨型Value。Redis的瓶颈往往不是内存不够，而是单个命令的耗时拖垮整体吞吐，这才是生产环境里最需要警惕的。
6. 最小可运行参考实现：Spring AI + Redis实战骨架
6.1 依赖与基础配置
我把前面这套思路浓缩成一个最小可运行的工程骨架，用的Spring Boot + Spring AI + Redis这套组合，其它语言你完全可以平移思路。工程里先引入依赖：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-openai-spring-boot-starter</artifactId> <version>1.0.0</version> </dependency>配置文件里给Redis连接池设置合理的参数：
spring: data: redis: host: 127.0.0.1 port: 6379 timeout: 3s lettuce: pool: max-active: 32 max-idle: 16 min-idle: 4这里max-active我特意没按默认值来，Agent场景的高并发下8个连接根本不够用，32是相对保守又能撑住日常峰值的选择。注意不要为了“保险”调到几百，一个服务几百条连接对Redis本身也是负担。
6.2 对话上下文缓存与限流的代码实现
核心类是一个会话管理Service，负责往ZSET里写入对话记录、读取最近上下文、控制长度并设置过期时间：
@Service public class AgentContextService { private static final String SESSION_KEY = "agent:chat:ctx:"; private static final int MAX_TURNS = 20; private final StringRedisTemplate redis; public AgentContextService(StringRedisTemplate redis) { this.redis = redis; } /** * 追加一条会话记录，自动裁剪超出部分 */ public void appendTurn(String sessionId, String role, String message) { String key = SESSION_KEY + sessionId; long now = System.currentTimeMillis(); String member = role + ":" + now + ":" + message; redis.opsForZSet().add(key, member, now); redis.expire(key, Duration.ofMinutes(30)); Long size = redis.opsForZSet().zCard(key); if (size != null && size > MAX_TURNS) { redis.opsForZSet().removeRange(key, 0, size - MAX_TURNS - 1); } } /** * 读取最近N轮上下文 */ public List<String> lastTurns(String sessionId, int limit) { String key = SESSION_KEY + sessionId; return redis.opsForZSet().reverseRange(key, 0, limit - 1L); } }这里是纯String序列化方案，不依赖框架的Serializer配置，正好避开序列化的坑。appendTurn里的裁剪逻辑我用了ZSET的removeRange，每次只裁掉排名靠前的旧消息，动作非常轻量。
限流部分我封装了一个注解式的拦截器或过滤器，每次请求进入Agent流程前先执行Lua脚本判断是否允许继续。前面已经展示过Lua脚本，Java侧用DefaultRedisScript<Long>把脚本注册进去，调用方式如下：
@Autowired private StringRedisTemplate redis; public boolean allowRequest(String userId) { DefaultRedisScript<Long> script = new DefaultRedisScript<>(LUA_SCRIPT, Long.class); Long result = redis.execute(script, List.of("agent:rate:" + userId), String.valueOf(System.currentTimeMillis()), "5000", "10"); return result != null && result == 1L; }明确了Key粒度是用户维度，窗口5秒内最多10次请求。更粗的全局维度也可以做同样的脚本，Key换成agent:rate:global就行。这套实现没有引入额外中间件，只依赖Redis自身能力，运维成本非常低，很适合Agent项目前期的并发保护。
6.3 验证效果与上线建议
骨架搭完之后，我建议你至少做三组对比测试再上生产。第一组是“会话恢复正确性验证”：模拟用户聊多轮后更换实例访问，确认上下文完整恢复，这是Redis会话缓存的最基本价值。第二组是“并发压测”：用Jmeter或wrk灌入每秒几百个请求，观察限流是否正确触发、分布式锁是否保证任务只执行一次、接口P95延迟是否在可控范围。第三组是“缓存命中率监控”：Redis里统计会话Key数量和语义缓存命中率，命中率低于预期就找找Key命名和过期策略是不是有问题。
我个人在这些项目里总结出的一个重要经验是：不要追求一次把所有功能都做进去。先做会话缓存和限流，这两块能解决80%的Agent并发问题；跑稳之后再上任务队列和语义缓存。Redis配置和监控也建议先从慢日志、info命令开始，每周花时间看一眼Redis的CPU和内存曲线，比出事故再排查强太多。
最后分享一个小技巧：给所有Redis Key加上统一前缀，比如agent:开头的设计，既是为了区分项目，也是为将来用Redis Desktop Manager这类工具排查问题时一眼能看明白业务归属。Key命名这件事，等缓存Key多了之后再改非常痛苦，越早规范越省心。
