跳转至

Redis agentic AI flowers with Iris

Ch01.1534 Redis agentic AI flowers with Iris

📊 Level ⭐⭐⭐ | 7.6KB | entities/www.blocksandfiles.com-5241795.md

Redis agentic AI flowers with Iris

摘要

Redis 推出 Iris Context Engine——一个构建在 Redis 之上的统一上下文与记忆层，让企业数据能够被 AI Agent 通过工具主动发现和获取，并同步发布了基于 SSD 的 Redis Flex 以解决 PB 级规模的存储成本问题。CEO Rowan Trollope 将这一转变概括为"上下文范式翻转"：LLM 变聪明之后，Agent 的工作方式从"预先填充上下文"转向"给 Agent 一组工具，让它自己决定需要什么"。文章同时预言企业 AI 将走向"每千名员工上千个 Agent"的密度，而 Oracle、Snowflake 等传统数据平台并非为此种规模而生。

核心要点

  • Iris 不是数据库，而是 Agent 平台：Redis 是底层数据库，Iris 运行在 Redis 之上，向 Agent 提供企业数据访问与长期记忆能力
  • 三组件架构：Context Retriever（让外部数据源可被 Agent 导航）、Agent Memory（跨任务保留短期与长期上下文）、Data Integration / RDI（基于 change data capture 的实时数据流）
  • 范式翻转：Trollope 描述 Agent 从"prefill context"转向"获得一组工具后自己探索"——记忆工具、上下文工具由 Agent 按需调用
  • 优秀上下文的四支柱：动态可导航（dynamically navigable）、数据具有语义定义、上下文随时间自动变好、始终保持在最新状态
  • MCP / CLI 工具接口：Agent 通过 list objects、list tools、search tools、call tool 等命令与 Iris 交互
  • RDI 保证数据新鲜：连接 MongoDB、Oracle、Postgres 等数据源，表一旦变更即通过 CDC 推入 Redis，Agent 始终拿到最新副本
  • Flex SSD 把成本降低一个数量级：Redis 内核被重新架构以原生利用 flash，实现 PB 规模、亚 5ms 延迟与 99.9999% tail latency 的组合
  • 百万 Agent 密度预言："每千名员工一千个 Agent"，电子表格的每个单元格都是一个 Agent；传统数据平台无法支撑，Redis 作为 view & cache 层即可扩展而无需改动后端

深度分析

Redis 的战略转身：从缓存数据库到 AI 上下文基础设施

Redis 以缓存和内存数据结构的身份起家，但近一年动作密集：推出 Vector Sets 数据类型、RedisVL 向量库、LangCache 语义缓存，如今又发布 Iris Context Engine。其叙事逻辑来自 AI 工作负载的进化——LLM 聊天机器人只处理一次性请求，而 Agent 需要多步执行、向其他 Agent 或数据库发起内部请求、并在间隔后恢复之前的上下文。Redis 把自身重新定位为"Agent 平台"：Iris 不是数据库，数据库仍由 Redis 承担，Iris 负责把企业数据资产（财务、运营、IT、制造等）以 Agent 可消费的方式供给出去。

上下文范式翻转：从预填到工具化发现

Trollope 的核心论点是"LLM 在过去 12-24 个月变聪明，改变了 Agent 的工作方式"：过去是人预先判断哪些上下文与查询相关并填充给 Agent，现在则把记忆工具、上下文工具等一组工具交给 Agent，让它自己判断需要什么。他强调"好的 Agent 真正需要的是好的上下文"，并给出四个支柱：上下文必须动态可导航、数据要有语义定义、上下文要随时间变好、必须始终最新。这实质上把上下文从"一次性打包的静态输入"重构为"持续供给的动态服务"，与上下文工程领域关于 context freshness 的讨论同频。

三组件如何分工：检索、记忆与数据新鲜度

Iris 的三个组件对应 Agent 上下文的三个不同问题：Context Retriever 解决"外部数据在哪里、如何被 Agent 导航"；Agent Memory 解决"跨任务的短期与长期记忆如何保存"；RDI 解决"数据如何保持新鲜"——它是一个实时数据流 / change data capture 产品，通过 MongoDB、Oracle、Postgres 等连接器监听表变更并推入 Redis。三者叠加的效果是：Agent 通过 MCP 或 CLI 暴露的工具接口（list objects、search tools、call tool）主动探索企业数据，而后端数据始终有最新副本兜底。MCP/CLI 作为工具面，也印证了工具接口协议正在成为数据层与 Agent 之间的标准接缝。

规模经济的赌注：Flex SSD 与百万 Agent 假设

Trollope 设想"每千名员工上千个 Agent"的世界，并以电子表格为例：100 家公司 × 10 列数据，每个单元格就是一个持续触发的 Agent。这种密度下，上千个 Agent 并发冲击企业基础设施，Oracle、Snowflake 这类数据平台并非为此设计；Redis 的解法是作为 scaling / view & cache 层叠加在现有数据平台之上，不改动后端即可大规模扩展。而"把公司数据子集全部载入 Redis"的经济性问题由 Flex 解决：SSD 版 Redis 成本比纯 RAM 低一个数量级，内核被重新架构以把 flash 当作原生存储介质，实测可达 PB 规模、亚 5ms 延迟与 99.9999% 尾部延迟。文章的潜台词是：Agent 规模化的瓶颈不只是推理算力，更是"给 Agent 喂新鲜上下文的存储成本"。

实践启示

  1. 把"Agent 可访问性"加入数据平台评估维度：除了事务、一致性、SQL 能力，还需评估数据能否通过 MCP/CLI 工具暴露给 Agent、实时同步延迟是否可接受。
  2. MCP 正在成为数据与 Agent 之间的工具接口事实标准：Iris 通过 MCP/CLI 暴露工具面是一个明确信号，数据平台不支持 MCP 将逐渐成为集成短板。
  3. 用增量缓存层代替系统迁移来应对 Agent 规模化：Redis 的定位是"view & cache 层"，不动底层数据平台；在数据源与 Agent 之间加一层可扩展的实时上下文层是可复用的架构思路。
  4. 把记忆与上下文检索分开设计：Iris 将 Agent Memory（长短记忆）与 Context Retriever（外部数据导航）拆成独立组件，短期记忆、长期记忆与外部检索需要不同的机制与存储策略。
  5. 数据新鲜度是有成本的，需要专门管道：RDI 用 CDC 实时推送保证上下文新鲜，说明"始终最新"不是靠 Agent 反复查询能解决的，需要专门的变更数据管道。
  6. 把存储介质成本结构纳入大规模 Agent 架构预算：全量 RAM 缓存不经济，SSD/分层存储（如 Flex）可将成本降低一个数量级，规模化设计时应把"上下文的经济性"与延迟指标一起考虑。

相关实体

→ 原文存档