堆代码讯 Redis 因作为缓存层而闻名，它曾让 Web 应用在高负载下免于崩溃。如今 Redis 所针对的问题结构相同，但难度更大：生产环境中 AI 代理的失败并非因为模型本身出错，而是因为它们依赖的数据分散、陈旧，并且是为人类而非机器所组织的。为单个查询构建的检索管道无法承载代理所生成的数据量。

Redis 所针对的差距是结构性的：代理发出的数据请求比人类用户多出数个数量级，但大多数检索层原本是为人类规模的问题而构建的。周一发布的 Redis Iris 就是该公司的答案：一个位于代理与其执行所需数据之间的上下文与记忆平台。该平台结合了实时数据接入、一个能从业务数据模型自动生成 MCP 工具的语义接口，以及一个基于 Redis Flex 构建的代理记忆服务器。Redis Flex 是一个经过重写的存储引擎，可将 99% 的数据运行在闪存上，成本仅为纯内存存储的十分之一。

此发布正值企业 RAG 基础设施正在积极转型之际。VentureBeat 的 2026 年第一季度 VB Pulse RAG 基础设施市场追踪报告发现，购买混合检索的意向在 1 月至 3 月间从 10.3% 增长至 33.3%，增加了两倍。检索优化首次超越评估成为企业投资的首要重点。随着企业逐渐超越现成方案的承载能力，自研内部检索栈的比例从 24.1% 上升至 35.6%。Redis 并非唯一读取到这些信号的基础设施供应商——最近几周，已有数家数据平台提供商围绕代理上下文层进行了重新定位。

规模上的不匹配正是此次发布背后的结构性论点。“企业中的代理数量将比人类员工多出几个数量级，”Redis 首席执行官 Rowan Trollope 告诉 VentureBeat。“代理数量比人类员工多出几个数量级，意味着后端系统的负载也多了几个数量级。”

从缓存到上下文
Trollope 将这种平行关系追溯到移动互联网时代：当原本为柜员分支而构建的传统后端突然需要服务数百万智能手机用户时，Redis 成了那个无需全面重建就能吸收负载的缓存层。不同之处在于，如今的代理无法自己编写中间件。在移动时代，开发者会与数据库管理员一起，确定应用所需的查询，然后将缓存逻辑硬编码到中间件层。代理做不到这一点。它们需要在运行时通过预先为它们构建的接口找到正确的数据，否则就会卡顿。

“这就像冰箱与杂货店的类比，”他说。“如果你每次做三明治都要跑去杂货店拿食材，那效率就太低了。你在每个家里放一台冰箱，存一点食物在那里。而我们的基础设施栈大体上仍处于类似‘只能跑杂货店’的阶段。”

Redis Iris 包含的内容
Iris 提供了五个组件，共同覆盖数据接入、语义访问、记忆和缓存。
Redis Data Integration（现已正式可用）：RDI 使用变更数据捕获管道，持续将数据从关系数据库、数据仓库和文档存储同步到 Redis 中，支持 Oracle、Snowflake、Databricks 和 Postgres 的连接器。

Context Retriever（现已提供预览版）：开发者使用 pydantic 模型定义业务数据的语义模型，Redis 自动生成代理直接查询所用的 MCP 工具，并在服务端强制执行行级访问控制。Trollope 将经典 RAG 的这一转变描述为方向上的倒置。“这只是一个翻转：让代理自己去拉取数据，而不是预先假定数据并将其塞入管道，”他说。

Agent Memory（现已提供预览版）：跨会话存储短期和长期状态，使代理能够携带上下文，无需每一步都重新推导。
Redis Flex：一个经过重写的存储引擎，将 99% 的数据运行在 SSD 上，1% 在 RAM 中，以亚毫秒级延迟实现 PB 级检索。
Redis Search 和 LangCache：平台底层的检索和语义缓存骨架。LangCache 通过缓存提示响应来减少冗余的模型调用。

分析人士的观点
如今数据行业整体上正朝着同一个方向前进。几乎所有主流数据库厂商都在提出上下文层的论点。包括 Oracle 在内的传统数据库供应商正在集成上下文和记忆层，将关系数据库带入代理式 AI 时代。包括 Pinecone 在内的专用向量数据库供应商也在做同样的事情，为代理式 AI 上下文构建新的知识层。像 Hindsight 这样的独立上下文层也属于这一新兴格局的一部分。

Trollope 认为 Redis 的定位在结构上与这些竞争对手不同。“我们要赢，并不需要别人输，”他说。许多现有的 Redis 部署已经将 MongoDB 或 Oracle 作为后端记录系统。Iris 是对这些系统的反映和缓存，而非取代它们。Redis 正在 Snowflake 市场中推出 Iris，并提供原生连接器。HyperFRAME Research 的 AI 栈实践负责人 Stephanie Walter 清晰地阐述了市场背景。“市场正汇聚到同一个结论上：代理不仅需要更多的 token 或更好的模型。它们需要受治理的、最新的、低延迟的上下文，”Walter 说。

她对 Redis 差异化优势的解读，聚焦于 Redis 原本在技术栈中的位置——靠近运行时、对延迟敏感的操作状态以及实时数据。“它的卖点与其说是‘更好的 RAG’，不如说是‘代理在真正工作时需要实时上下文、记忆和快速检索’，”她说。无论是 Redis 还是其他供应商，任何上下文层技术要想成功，都必须面对治理方面的挑战。“如果每个代理都成为新的成本中心、新的数据访问风险和新的治理例外，那么代理式 AI 就无法在企业中规模化，”她说。“胜出的上下文层将是那些能让代理运行得更快、更便宜、更安全的方案。”

对于实时临床 AI，弄错上下文是不可接受的
Mangoes.ai 是一家已经在生产环境中面对过这些问题的公司，且其弄错上下文的代价是以患者的治疗结果来衡量的。Mangoes.ai 的创始人兼 CEO Amit Lamba 运营着一个实时语音 AI 平台，该平台部署在大型医疗机构中，患者和临床医生可以实时提问关于治疗、日程安排和病历的问题。Mangoes.ai 从一开始就原生地在 Redis 上构建了其技术栈。

“检索、记忆和会话状态都通过 Redis 运行，因此我们不需要把不同的工具拼凑在一起然后指望它们能够互相通信，”Lamba 说。Iris 的动态记忆能力所解决的问题，发生在一个复杂会话的过程中。“想象一个一小时的团体治疗 session，”Lamba 说。“你需要知道谁在什么时候说了什么，并且能够在当下向治疗师呈现正确的信息。这不是一个简单的检索问题。”

该平台并行运行多个专门化的代理：一个用于实体识别，一个用于关系推理，一个用于整合病史。“动态记忆能力与我们正在解决的问题几乎完美匹配，”Lamba 说。

这对企业意味着什么
对于那些围绕 RAG 构建 AI 栈的企业来说，当初让他们能够上生产的检索层，如今已不足以支撑他们继续留在生产环境中。RAG 时代正在让位于上下文架构。经典的 RAG 模式是在调用模型之前将数据推送给代理。生产环境的部署正在扭转这一模式：代理通过工具调用在运行时拉取它们所需的数据，将数据层视为实时资源，而非预先加载的有效负载。仍在优化 RAG 管道的团队正在解决去年的问题。

语义层如今已成为生产基础设施。定义业务实体、它们之间的关系以及实体间访问规则的模型，需要像数据管道一样被构建、版本化和维护。大多数组织在人员和结构上尚未为此做好准备。现在就开始定义其上下文架构的企业，将来在代理工作负载扩展时就不必重新构建。预算已经在转移。2026 年第一季度的 VB Pulse 数据显示，整个季度内检索优化投资从 19% 上升至 28.9%，首次超过评估支出。花了一年时间衡量检索质量的组织，现在正花钱去改进它。上下文层已经是一个活跃的采购决策，而不再是路线图上的项目。

“企业第一个要问的问题不应是‘我需要向量数据库、长上下文、记忆还是上下文引擎？’而应该是‘这个代理需要知道什么？这些知识需要多新鲜？谁被允许访问？每次检索的成本是多少？’”Walter 说。