给 AI 开发者：Valkey 在 AI 与 Agent 时代的全景
用一个内存引擎同时搞定向量检索、语义缓存与 Agent 记忆——为什么越来越多 AI 团队选 Valkey
如果你在用 Cursor / Claude Code 写 AI 应用、做 RAG、搭 Agent，这一篇是你的导航页。
为什么 AI 团队开始用 Valkey
核心论点——"三合一"：与其同时跑一个专用向量库 + 一个缓存 + 一个会话存储（还要做 CDC/ETL 同步），不如用 Valkey 一个内存引擎同时承担三件事——语义缓存、向量检索、Agent 记忆。同处一片内存、少跳几次网络、一套 SDK 和运维面。
三个具体理由：
- 许可证友好：Valkey 是 BSD-3。把它嵌进你的 AI 产品、当 Agent 的记忆层，没有 SSPL/AGPL 的 copyleft 顾虑——这对 AI 创业公司很重要。
- 速度：KV 状态读写微秒级，向量检索个位数毫秒级。Agent 循环里反复读写状态，速度直接决定体验。
- 成本：托管 Valkey 比托管 Redis 便宜 20%+；语义缓存还能直接砍掉大头的 LLM 推理账单。
一条贯穿全站的规则：纯 KV 功能（聊天记录 List、会话 Hash、精确匹配缓存、TTL）在任何 Valkey 上都能跑；任何语义能力（向量索引）需要带 valkey-search 模块的 Valkey（自建加载模块，或用 AWS ElastiCache / GCP Memorystore for Valkey）。
四个核心场景
向量检索 valkey-search
HNSW/FLAT 索引、FT.CREATE/FT.SEARCH、混合检索，替代 RediSearch。
LLM 语义缓存
按语义命中缓存，AWS 实测推理成本降 86%、延迟降 88%。
Agent 记忆与会话
短期会话 + 长期语义记忆，Mem0 / LangGraph 原生支持。
RAG 架构
向量库选型对照 pgvector/Pinecone/Milvus，何时该用 Valkey。
工具链
MCP Server
让 Claude/Cursor 安全操作 Valkey 的 MCP，AWS Labs 官方实现 + 自建护栏。
Bloom 与 JSON
valkey-bloom 去重 seen-before，valkey-json 存 Agent 状态。
框架集成
LangChain/LlamaIndex/Mem0/LangGraph/Spring AI 谁是原生、谁是兼容。
哪些是"原生 Valkey 支持"，哪些只是"兼容连得上"
这是最容易踩坑的地方。很多框架的"Redis 集成"能通过线协议连上 Valkey，但不代表官方测过。下面是截至 2026 年中的真实状态：
| 框架 | 状态 | 说明 |
|---|---|---|
| LangChain 向量库 | ✅ 原生 | ValkeyVectorStore（langchain-aws，用 GLIDE 客户端） |
| Mem0 | ✅ 原生 | 独立的 "valkey" provider |
| LangGraph | ✅ 原生 | ValkeySaver/ValkeyStore（langgraph-checkpoint-aws） |
| AWS Labs MCP | ✅ 原生 | awslabs.valkey-mcp-server |
| LangChain 缓存/历史 | 🔶 兼容 | 用 RedisCache 等指向 Valkey URL |
| LlamaIndex / Spring AI / Feast / Celery | 🔶 兼容 | 线协议连得上，但官方未针对 Valkey 测试 |
最常见的坑：那些会自动创建 TEXT（全文）字段的集成（langchain-redis、LlamaIndex 默认 schema、Spring AI），在 valkey-search < 1.2 上会失败——因为 TEXT 字段是 1.2（2026-03）才加的。用 tag 字段或升级到 1.2。
完整对照与代码见 框架集成。