1. 从缓存中间件到AI 工具链的一环Redis 这次接入到底改变了什么Redis 这个名字做后端的人几乎没有不知道的。过去十几年里我们对它的定位非常固定内存数据库、缓存、分布式锁、消息队列的轻量替代、排行榜、计数器。你打开任何一个稍微有点规模的项目redis这个依赖基本都在。但最近一段时间围绕 Redis 的讨论出现了一个明显的变化——它开始频繁出现在 AI 工具链、Agent 编排、MCP 协议这些话题里而不是只出现在缓存击穿怎么办这种经典面试题里。这个变化不是营销噱头。当 AI Agent 开始真正落地到工程环境里一个绕不开的问题就冒出来了Agent 的上下文、工具调用状态、会话记忆、任务队列到底放在哪里大模型本身是无状态的每次调用都是失忆的。你要让它记住上一轮干了什么、当前任务进行到哪一步、哪些工具已经调用过、返回结果是什么就必须有一个足够快、足够灵活、支持多种数据结构的存储层来兜底。而 Redis 恰好就是干这个的。所以Redis 正式接入 AI这件事我的理解不是 Redis 变成了一个 AI 产品而是它作为基础设施被正式纳入了 AI 应用的运行时体系。它承担的角色从业务缓存扩展到了Agent 状态存储 工具调用中间层 会话记忆载体。这个定位的转变才是真正值得聊的东西。这篇文章适合三类人看一是后端工程师想搞清楚自己熟悉的 Redis 在 AI 场景里能干什么二是正在做 AI 应用、Agent 编排的开发者想找一个靠谱的状态存储方案三是对 MCP、Claude Code、Skill 这些新概念有点懵、想理清楚它们之间关系的人。我会尽量用大白话把原理讲透同时给出可以直接抄的配置和代码。先说结论Redis 在 AI 场景里的核心价值集中在四个点上——低延迟读写、丰富的数据结构、原生的过期与淘汰机制、以及天然适合做分布式协调。这四点单独看都不新鲜但组合到 AI Agent 这个场景里就变得非常关键。下面我逐个拆开讲。2. AI Agent 为什么需要一个 Redis 这样的存储层2.1 大模型无状态这件事比你想的更麻烦很多人第一次做 AI 应用的时候会觉得不就是调个 API 吗。你写个函数把用户输入拼成 prompt发给模型拿到回复返回给前端。跑通 demo 确实就这么简单。但一旦你要做多轮对话、要做工具调用、要做长任务编排问题立刻爆炸。举个具体场景。你做一个能帮用户查资料、写报告、发邮件的 Agent。用户说帮我整理一下上周的销售数据生成报告发给张总。这个任务里包含了好几个步骤查数据库、调模型生成文本、调邮件接口。每一步的中间结果都要保留因为下一步可能依赖上一步。而且用户可能中途改主意算了先别发我看看草稿。这时候你得能回滚到生成报告完成、发送未执行的状态。这些状态如果只放在内存里进程一重启就全没了。如果放在关系型数据库里读写延迟又扛不住高频的 Agent 循环。Agent 的执行往往是思考—调用工具—观察结果—再思考的循环一轮任务可能几十次甚至上百次状态读写。这种场景下Redis 的亚毫秒级读写就是刚需。2.2 会话记忆为什么不用数据库而用 Redis会话记忆Conversation Memory是 AI 应用里最典型的需求。用户和 AI 聊了 20 轮第 21 轮的时候模型需要知道前面发生了什么。最朴素的做法是把所有历史消息拼进 prompt但这样 token 消耗会爆炸而且大部分模型有上下文长度限制。工程上的常见做法是分层短期记忆放 Redis长期记忆放向量库或关系库。短期记忆就是最近 N 轮对话或者当前任务相关的上下文这部分要求读写极快、能自动过期。Redis 的 List 和 Hash 结构天然适合存这种数据。我一般会这样设计用session:{session_id}:messages作为 List 的 key每轮对话RPUSH进去同时用LTRIM保留最近 50 条。再配一个EXPIRE比如 2 小时不活跃就自动清理。这样既控制了内存占用又保证了活跃会话的响应速度。# 追加一条消息 RPUSH session:abc123:messages {role:user,content:帮我查下库存} # 只保留最近 50 条 LTRIM session:abc123:messages -50 -1 # 设置 2 小时过期 EXPIRE session:abc123:messages 7200这套逻辑简单到不能再简单但实测下来非常稳。相比每次去查数据库再反序列化Redis 的 List 操作基本是零成本。2.3 工具调用状态Agent 循环里的临时黑板Agent 调用工具的过程本质上是一个状态机。当前处于哪个步骤、调用了哪个工具、参数是什么、返回结果如何、是否失败需要重试——这些信息需要一个临时黑板来记录。Redis 的 Hash 结构特别适合干这个。比如一个任务的状态可以这样存HSET task:task_8899 status running \ current_step 3 \ tool_name search_api \ tool_args {query:Q3 sales} \ retry_count 0每次 Agent 循环开始时读一次 Hash执行完更新一次。因为 Hash 支持字段级更新不需要把整个对象读出来改完再写回去效率很高。而且你可以给这个 key 设置 TTL任务完成后自动清理不会留下垃圾数据。这里有个经验任务状态和会话记忆最好用不同的 key 前缀分开管理。我见过有人把两者混在一个大 Hash 里结果调试的时候根本分不清哪些字段是对话历史、哪些是任务状态排查问题非常痛苦。用session:和task:两个前缀配合 Redis 的SCAN命令按前缀遍历管理起来清爽很多。2.4 分布式协调多个 Agent 实例怎么不打架当你的 AI 应用部署了多个实例或者多个 Agent 并行处理任务时就会出现资源竞争。比如同一个用户的消息被两个实例同时处理或者一个任务被重复执行。这时候就需要分布式锁。Redis 实现分布式锁是老生常谈但在 AI 场景里有个细节要注意锁的持有时间要覆盖整个 Agent 执行周期而 Agent 执行时间是不确定的。传统业务里锁可能几百毫秒就释放了但一个 Agent 任务可能跑几十秒。所以锁的 TTL 要设得足够长同时要有续期机制看门狗否则任务还没跑完锁就过期了其他实例就会重复执行。import redis import uuid import time r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) def acquire_lock(lock_name, timeout60): token str(uuid.uuid4()) # SET NX EX 是原子操作避免竞态 if r.set(flock:{lock_name}, token, nxTrue, extimeout): return token return None def release_lock(lock_name, token): # 用 Lua 脚本保证判断 token 再删除的原子性 lua if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end r.eval(lua, 1, flock:{lock_name}, token)注意释放锁一定要用 Lua 脚本做原子判断不能先GET再DEL。否则在两步之间锁可能已经过期并被别人获取你删掉的就是别人的锁了。这个坑我踩过线上出过一次重复执行排查了半天。3. MCP、Skill、Claude Code 这几个概念到底怎么串起来3.1 MCP 是协议不是软件也不是硬件协议热词里有个很有意思的搜索mcp 是软件协议 硬件协议那个概念叫什么来着。这个问题其实反映了很多人的困惑。MCP 全称是 Model Context Protocol它是一个应用层的通信协议用来规范 AI 模型和外部工具、数据源之间怎么交互。你可以把它类比成AI 世界的 USB 接口标准——它规定了插头长什么样、信号怎么传但本身不是一个具体的设备。硬件协议那个概念通常指的是像 I2C、SPI、UART 这类物理层/链路层协议它们定义的是电平、时序、引脚这些底层的东西。MCP 完全不在这个层面它是跑在应用层的底层还是走 HTTP、SSE 或者 stdio 这些传输方式。所以两者不是一个维度的东西不用硬套。MCP 解决的核心问题是以前每个 AI 工具都要自己定义一套和模型对接的方式现在有了统一协议工具方只要实现 MCP Server模型方只要支持 MCP Client就能互相插拔。这就像以前每个外设都要装自己的驱动现在统一成 USB 了。3.2 Skill 是什么给 Agent 的技能包Skill 这个词在 Claude Code 的语境里指的是一种可复用的能力封装。你可以把它理解成给 Agent 预定义的一套操作流程或知识。比如一个代码审查 Skill里面写好了审查的步骤、检查项、输出格式Agent 遇到代码审查任务时直接调用这个 Skill 就行不用每次重新想。热词里出现的skill编码247skill编码193狗头军师skillbook to skill这些都是社区里对 Skill 的具体实践。有人把 Skill 做成插件有人把书里的方法论提炼成 Skill。本质上Skill 是把领域知识结构化让 Agent 能稳定复现某个能力。Skill 和 MCP 的关系是MCP 负责连接Skill 负责能力。MCP 让 Agent 能连上数据库Skill 告诉 Agent 连上数据库之后该按什么步骤操作。两者配合Agent 才能真正干活。3.3 Claude Code 在整条链路里的位置Claude Code 是一个跑在终端里的 AI 编程助手。它支持 MCP 协议可以连接各种 MCP Server 来扩展能力它也支持 Skill可以加载预定义的技能包。热词里vscode配置claude codeubuntu配置claude codemacos 安装 redis这些说明很多人在本地搭这套环境。一个典型的本地开发链路是这样的你在 macOS 或 Ubuntu 上装好 Redis 作为状态存储装好 Claude Code 作为 Agent 运行时配置好 MCP Server 让它能连上你的工具再加载几个 Skill 让它具备特定能力。这样你就有了一个能读写数据、能执行任务、能记住上下文的本地 AI 工作流。Redis 在这条链路里的位置就是状态和记忆的持久化层。Claude Code 本身可能是无状态的会话但通过 MCP 连上 Redis它就能记住跨会话的上下文、缓存工具调用结果、协调多个任务。3.4 一张表理清这几个概念概念本质解决的问题和 Redis 的关系MCP应用层通信协议统一 AI 与工具的对接方式Redis 可作为 MCP Server 的后端存储Skill能力封装让 Agent 稳定复现特定技能Skill 执行过程中的状态可存 RedisClaude CodeAgent 运行时提供终端里的 AI 编程环境通过 MCP 连接 Redis 做记忆层Redis内存数据存储高速读写、状态管理、分布式协调本身即基础设施这张表建议收藏社区里很多讨论之所以混乱就是因为把协议、工具、运行时、存储混为一谈了。4. 把 Redis 接进 AI 工作流的实操路径4.1 环境准备从安装到验证不管你用什么系统Redis 的安装都不复杂。macOS 上用 Homebrew 最省事brew install redis brew services start redis redis-cli ping # 返回 PONG 就说明起来了Ubuntu 上用 aptsudo apt update sudo apt install redis-server sudo systemctl start redis-server sudo systemctl enable redis-server redis-cli pingWindows 用户建议用 Docker避免各种编译问题docker run -d --name redis-ai \ -p 6379:6379 \ -v redis-data:/data \ redis:7-alpine \ redis-server --appendonly yes这里--appendonly yes是开启 AOF 持久化。AI 场景下状态数据比较重要纯内存模式重启就丢建议开启。-v挂载数据卷保证容器重建后数据还在。提示生产环境一定要设密码别裸奔。在redis.conf里加requirepass your_strong_password客户端连接时用AUTH。我见过太多因为 Redis 没设密码被扫出来挖矿的案例。4.2 用 Python 封装一个 Agent 记忆层光有 Redis 还不够你得有一层封装把存对话取对话存任务状态这些操作包成好用的函数。下面是我常用的一个精简版import redis import json from datetime import timedelta class AgentMemory: def __init__(self, hostlocalhost, port6379, passwordNone, db0): self.r redis.Redis( hosthost, portport, passwordpassword, dbdb, decode_responsesTrue, socket_timeout5, socket_connect_timeout5 ) def append_message(self, session_id, role, content, max_len50, ttl7200): key fsession:{session_id}:messages msg json.dumps({role: role, content: content}, ensure_asciiFalse) pipe self.r.pipeline() pipe.rpush(key, msg) pipe.ltrim(key, -max_len, -1) pipe.expire(key, ttl) pipe.execute() def get_messages(self, session_id): key fsession:{session_id}:messages raw self.r.lrange(key, 0, -1) return [json.loads(m) for m in raw] def set_task_state(self, task_id, state: dict, ttl3600): key ftask:{task_id} self.r.hset(key, mapping{k: json.dumps(v, ensure_asciiFalse) for k, v in state.items()}) self.r.expire(key, ttl) def get_task_state(self, task_id): key ftask:{task_id} raw self.r.hgetall(key) return {k: json.loads(v) for k, v in raw.items()}这段代码有几个设计考量。第一用pipeline把多个命令打包发送减少网络往返在高频 Agent 循环里能明显降低延迟。第二decode_responsesTrue省去手动 decode 的麻烦。第三socket_timeout设了 5 秒避免 Redis 卡住时整个 Agent 挂死。第四消息用 JSON 序列化并ensure_asciiFalse保证中文正常存储。4.3 缓存工具调用结果省 token 又提速Agent 调用工具往往有重复。比如同一个查询在短时间内被调用多次或者多个任务需要同一份数据。这时候用 Redis 缓存工具结果既省了外部 API 调用又加快了响应。import hashlib def cached_tool_call(memory, tool_name, args, func, ttl300): # 用工具名参数生成唯一 key raw f{tool_name}:{json.dumps(args, sort_keysTrue)} cache_key ftoolcache:{hashlib.md5(raw.encode()).hexdigest()} cached memory.r.get(cache_key) if cached: return json.loads(cached) result func(**args) memory.r.set(cache_key, json.dumps(result, ensure_asciiFalse), exttl) return result这里用sort_keysTrue保证参数顺序不同但内容相同的调用能命中同一个缓存。TTL 设 300 秒是个经验值——太短起不到缓存效果太长可能拿到过期数据。具体数值要根据你的工具数据更新频率来定。注意不是所有工具调用都适合缓存。涉及写操作、有副作用的调用比如发邮件、下单绝对不能缓存否则会重复执行。只缓存幂等的读操作。4.4 用 Redis 做 Agent 任务队列当你有大量任务要处理时可以用 Redis 的 List 或 Stream 做任务队列。List 简单直接Stream 支持消费组和 ACK 机制更可靠。# 生产者投递任务 def enqueue_task(r, task): r.lpush(agent:tasks, json.dumps(task, ensure_asciiFalse)) # 消费者阻塞式取任务 def worker(r): while True: _, raw r.brpop(agent:tasks, timeout5) if raw: task json.loads(raw) process_task(task)brpop是阻塞式弹出队列空的时候会等待不会空转浪费 CPU。如果要多消费者并行用BRPOP配合多个 worker 进程即可Redis 保证每个任务只被一个消费者拿到。对于要求至少处理一次的场景建议用 Stream# 生产 XADD agent:tasks * task_id 8899 type report # 消费组读取 XREADGROUP GROUP workers consumer1 COUNT 1 BLOCK 5000 STREAMS agent:tasks # 处理完 ACK XACK agent:tasks workers message_idStream 的好处是消息不会因为消费者崩溃而丢失未 ACK 的消息可以被重新投递。做严肃的 Agent 任务编排我强烈建议用 Stream 而不是 List。5. 实测中踩过的坑和性能调优经验5.1 内存暴涨Agent 场景比传统缓存更容易失控传统缓存场景key 的数量和大小相对可控。但 Agent 场景不一样每个会话、每个任务、每次工具调用都可能产生新 key而且消息内容可能很长模型输出动辄几千字。如果不加控制内存很快就满了。我的做法是三层防护。第一层所有 key 必须设 TTL没有例外。会话 2 小时任务状态 1 小时工具缓存 5 分钟。第二层用maxmemory-policy allkeys-lru让 Redis 在内存满时自动淘汰最久未使用的 key。第三层定期用SCAN检查异常大的 key及时清理。# 查看内存使用 redis-cli info memory # 找出大 key生产环境慎用会阻塞 redis-cli --bigkeys # 设置最大内存和淘汰策略 redis-cli config set maxmemory 2gb redis-cli config set maxmemory-policy allkeys-lru提示--bigkeys会遍历所有 key生产环境大实例上执行可能阻塞几秒。建议在从库上跑或者用SCAN分批自己写脚本统计。5.2 序列化选型JSON 够用但别忽略开销我上面用的都是 JSON 序列化因为可读性好、调试方便。但在高频场景下JSON 的序列化/反序列化开销不能忽略。如果你的 Agent 每秒要读写几千次状态可以考虑 MessagePack 或 Protobuf。不过我的建议是先用 JSON 跑通确认有性能瓶颈再换。过早优化是万恶之源。我见过有人一上来就用 Protobuf结果调试的时候连存进去的是什么都看不出来排查问题效率极低。JSON 的可读性在开发阶段价值巨大。5.3 连接管理别每次操作都新建连接这是新手最容易犯的错。每次读写都redis.Redis(...)新建一个连接在高频场景下连接建立的开销会拖垮性能。正确做法是用连接池全局复用一个实例。pool redis.ConnectionPool( hostlocalhost, port6379, max_connections50, decode_responsesTrue ) r redis.Redis(connection_poolpool)max_connections要根据你的并发量设。太小会排队等待太大浪费资源。一般按峰值并发数 × 1.5来估。5.4 分布式锁的续期问题前面提到 Agent 任务执行时间长锁的 TTL 可能不够。解决方案是加一个后台线程定期续期import threading def renew_lock(r, lock_name, token, interval20, extend60): def _renew(): while True: time.sleep(interval) lua if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(expire, KEYS[1], ARGV[2]) else return 0 end if not r.eval(lua, 1, flock:{lock_name}, token, extend): break # 锁已丢失停止续期 t threading.Thread(target_renew, daemonTrue) t.start() return t这个续期线程是守护线程主任务结束后自动退出。续期间隔要小于 TTL比如 TTL 60 秒每 20 秒续一次留足容错空间。5.5 常见问题速查表现象可能原因排查方向内存持续增长key 没设 TTLINFO memory看 used_memory响应变慢大 key 或热 key--bigkeys、SLOWLOG GET连接超时连接池耗尽看connected_clients指标锁失效重复执行TTL 太短无续期检查锁的过期时间设置数据丢失未开持久化检查 AOF/RDB 配置6. 这套方案适合什么场景不适合什么场景Redis 接入 AI 工作流不是万能药得看场景。适合的场景很明确高频读写、状态需要过期、需要分布式协调、数据结构多样。比如多轮对话记忆、Agent 任务状态、工具调用缓存、任务队列、限流计数这些用 Redis 都非常合适。不适合的场景也要说清楚。第一需要复杂查询的场景。你要按多个条件筛选历史任务、做聚合统计Redis 不擅长老老实实用关系库或 ClickHouse。第二需要强事务保证的场景。Redis 的事务能力有限涉及资金、库存这种强一致需求别硬上。第三数据量远超内存的场景。Redis 是内存数据库虽然可以持久化但全量数据放内存成本很高冷数据该落盘就落盘。我的实际做法是分层存储热数据、状态数据、会话数据放 Redis冷数据、归档数据、需要复杂查询的数据放关系库或对象存储。两层之间用异步任务同步。这样既保证了 Agent 的响应速度又控制了成本。关于 MCP 和 Redis 的结合目前社区还在快速演进。我观察到的一个趋势是越来越多的 MCP Server 开始内置 Redis 作为后端用来缓存工具元数据、管理会话。如果你正在做 MCP 相关的开发把 Redis 纳入技术选型是值得认真考虑的。它不会让你的 Agent 变聪明但能让你的 Agent 跑得稳、记得住、不重复干活——这几点在真实生产环境里比模型能力本身更影响用户体验。最后分享一个我自己的习惯每次搭新的 AI 应用环境我会先用redis-cli monitor观察一段时间看看实际产生了哪些 key、访问模式是什么样的。这个命令会实时打印所有执行的命令虽然生产环境不能长期开影响性能但在开发调试阶段它能让你对 Agent 的行为有非常直观的认识。很多时候你以为的逻辑和实际发生的完全不一样monitor 一看就明白了。