上下文、记忆与 RAG：数据库经验能复用到哪里

一个 Agent 把对话保存进数据库，下一次按相似度取回，便被介绍为“拥有长期记忆”。这件事的存储部分很普通：持久化、索引、查询、过期清理。真正需要追问的是，存了什么，什么时候有资格取回，以及取回后能推出什么。

同一个数据库，可能装着四种不同东西

故障助手曾读到“旧版本默认关闭自动恢复”，又听用户说“这次只调查，不创建工单”。如果把两句话不加区分地存为记忆，后续可能让旧版默认值覆盖当前部署事实，也可能在摘要时丢掉权限限制。

信息	角色	谁可以更新	失效条件
原始部署记录	事实来源	权威业务系统	部署或配置版本变化
模型的根因猜测	待验证假设	调查过程	新证据反驳或适用条件变化
用户当前约束	任务控制条件	合法用户更新及应用规则	当前任务被明确修订
对话摘要	派生工作视图	摘要器	依赖内容变化或摘要有误

四者可以使用相同存储产品，但不能具有同样的权威等级。数据库保证存下了那段内容，不保证那段内容代表真实世界。

一次模型调用前，需要从任务状态、资料、历史消息和工具结果中选取信息，统一格式，控制长度，附上来源，再构造请求。它与查询视图、投影、数据聚合和输入预处理存在清晰的工程联系。

新增困难是：下游使用者是根据语言含义工作、且使用信息不完全可控的模型。字段存在不代表被正确理解；文本更长不代表更有帮助；压缩后的摘要也可能改变原句的条件。

Anthropic 的上下文工程文章讨论上下文选择、压缩和外部笔记等方法。对本例而言，这些方法的共同目标应落实为可检查的问题：关键约束是否保留，证据能否回读，未知是否在压缩后被改成了肯定。

检索增强生成将外部检索与生成结合。RAG 原始论文提供了这一研究方向的早期具体实现；本文讨论的是通用工程分层，不将不同系统的训练与检索方式视为同一种实现。

全文索引、向量索引、过滤、排序和读取窗口都可借助成熟的数据系统。但查询返回一份文档，并没有执行“文档支持这条结论”的证明。

假设用户问当前部署能否自动恢复，检索命中了“产品支持自动恢复”。主题高度相关，答案却仍缺少当前配置。此时多换一个向量数据库未必能解决问题，因为缺口可能在任务条件和证据含义，而不是索引速度。

可以把链路拆为：资料是否存在、是否允许访问、是否被召回、是否进入上下文、是否支持主张、主张是否被忠实表达。每一层有不同的失败判据。所谓 RAG 质量差，需要先定位到其中一层。

“订单服务 5xx 怎么恢复？”与“订单服务升级后 5xx 怎么恢复？”在向量空间可能很接近，但第二问涉及新版本，旧答案未必适用。若缓存只按问题相似度命中，就把“相似”当成“可替换”。

正确缓存仍需考虑身份与租户、时间范围、资料版本、任务约束、允许动作等条件。缓存具体存的是检索列表、模型输入前缀还是最终答案，也会决定不同的有效性规则。

普通后端缓存同样需要处理失效和数据新鲜度；Agent 场景额外增加的是，键的语义边界往往没有预先完整编码。模型或嵌入相似度可以帮助寻找候选缓存，却不能单独证明复用合法。

模型将一次误判总结为“客户通常允许自动建单”，保存后多次召回。调用越多，系统越像是在“了解用户”，实际上只是在重复一条缺乏依据的推断。

记忆写入因此需要来源、状态和范围；用户明确纠正时，要沿引用关系更新相关派生产物。仅修改原始记忆、不使缓存摘要失效，会留下两个相互矛盾的版本。

可以用两组小反例检查设计：只更新资料版本，旧结论是否失效；只压缩聊天历史，明确的只读约束是否仍然存在。两者分别测试知识更新和控制条件保留，不必等待最终模型回答才发现所有问题。

本篇判断：存储、索引、投影和失效机制可以直接复用；信息的语义选择、抽取是否忠实以及证据是否支持结论，需要额外验证。把记忆称为数据库有助于设计持久化，却不能完成可信性设计。