Redis Iris 的 Context Retriever 和 Agent Memory 分别解决什么

如果一个客服代理要回答“这位客户当前有哪些未发货订单”，需要查的是业务系统里的结构化记录；如果问题变成“客户上次会议为什么拒绝换货”，需要回忆的是过去对话。Redis Iris 的 Context Retriever 和 Agent Memory 正好对应这两种上下文，不能把它们当成两个名字不同的向量检索器。

官方地址：https://redis.io/iris/

一句话判断：当前客户、订单、持仓、工单等可查询事实交给 Context Retriever；说过什么、做过什么决定、跨会话形成的偏好交给 Agent Memory。一个问题同时涉及两类信息时，再让代理组合调用。

Context Retriever 查的是当前业务事实

Context Retriever 解决的是“数据在那里，但代理不知道应该如何安全地使用它”。开发者先定义客户、订单、持仓等实体，以及字段类型、关系和访问规则，再由服务生成可发现的 MCP 工具。代理运行时拿到的是类似按客户筛选订单、按金额区间查持仓的工具，而不是一段可以随意拼接的 SQL。

这带来一个很实用的边界：问题里的时间词是“现在”“当前”“有哪些”，或者答案必须覆盖每条匹配记录时，优先走 Context Retriever。它的价值不是把文字相似度做得更高，而是让字段、筛选条件、关系和权限在工具层变得明确。官方介绍还强调，代理通过受限密钥访问工具，数据过滤可以在服务端执行。

Agent Memory 记的是会话经历与长期事实

Agent Memory 面向的是“这个代理以前和用户经历过什么”。session memory 保存当前会话的事件和元数据，可以设置 TTL；long-term memory 则从过往会话中提取可复用的事实、偏好或决定，并通过向量检索在后续会话中找回。会话内容转为长期记忆的过程可以异步进行，所以不必让当前回复一直等待提取完成。

因此，“客户上次会议提到的风险偏好是什么”“刚才已经确认了哪些行动项”属于 Agent Memory。它保存的是交互上下文，不应成为订单金额、库存数量或账户余额的唯一来源；这些内容仍应由业务数据层返回，记忆最多保存用户曾经表达过的意愿。

一个组合问题要让两层各做一半

真实请求往往是混合的，例如“客户当前的持仓比例是什么，他上次对再平衡说了什么”。前半句需要 Context Retriever 返回完整、可过滤的持仓记录，后半句需要 Agent Memory 按会话或语义搜索历史表达，代理再把两份上下文合成自然回答。Redis 的示例中就是把结构化持仓查询和会议记忆搜索串在同一个代理里。

落地时可以先写一条路由规则：带有实体字段、范围、状态和“当前”语义的请求进入 Retriever；带有会议、上次、偏好、决定和“曾经”语义的请求进入 Memory。还要给两层分别标注来源，避免模型把一条旧记忆误读成最新事实。

常见问题

Context Retriever 是不是普通 RAG 的替代品？

不是。它更适合结构化业务数据和受控工具调用；规章、手册、合同等非结构化文档仍可能需要文档 RAG，代理可以按任务组合多种检索方式。

Agent Memory 会自动保存所有聊天内容吗？

不能这样理解。会话记忆受 TTL 和会话范围约束，长期记忆是从会话中提取的可复用内容，应用仍应按隐私、删除和过期策略设计保存边界。

订单状态能不能只放进长期记忆？

不建议。订单状态会变化，应该从当前业务数据源查询；长期记忆可以保留“用户曾要求改地址”这类交互背景，但不能代替实时状态。

什么时候值得同时调用两个组件？

当问题同时要求“现在是什么”和“过去怎么说”时。先取结构化事实，再用记忆补足原因、偏好或承诺，回答会比只查一层更完整。