给生产级智能体做记忆：写入、读取、复核与遗忘要分开治理

智能体记忆是一套治理架构

写入、读取、复核、遗忘四条路径，各有责任方

文章在讨论什么问题

Microsoft Foundry 博客在 2026 年 10 月 26 日发表了一篇文章，讨论生产环境里的智能体该如何管理记忆。作者的核心判断是：记忆能力不能只靠更好的提示词或更大的向量库。它应当拆成四项相互配合的能力，即 Remember（记住）、Retrieve（检索）、Revalidate（复核）和 Forget（遗忘）。

这四项能力由智能体、应用策略层、平台记忆服务以及各自拥有数据的业务系统分担。每一项都有自己的身份校验、策略关卡、失败处理和审计记录。

文章用什么例子说明风险

文中设想了一个发布协调场景。面向用户的编排智能体记住了负责人的汇报格式偏好，这类内容适合作为用户级长期记忆。但项目日期应由另一个有权读取项目系统的数据智能体提供。

如果编排智能体把用户曾说过的某个日期存成了长期事实，而权威系统之后已经改期，那么回答的格式可能很规整，内容却是错的。作者的结论是：偏好可以记住，日期应当检索并回到权威系统复核，过期的副本应当被清除。

四条路径的分工

文章用同一套契约描述四项操作，包括触发条件、决策方、各层职责、身份授权、来源记录、失败行为和审计。我的理解是，这套做法的重点是“谁有权决定”，而不是“模型能不能做到”。

记住：智能体只能提名候选事实，不能把模型输出直接写进持久记忆。是否写入由应用层的写入关卡决定。

检索：智能体只声明信息需求。文章强调先授权再排序，因为语义相似只代表相关，不代表有权访问。

复核：当任务需要当前事实时，由策略决定新鲜度要求，再向权威系统核对版本或标记。

遗忘：按保留、数据主体请求或事故处置策略执行，需要覆盖索引、衍生摘要和缓存，并验证结果。

文章还提到，Microsoft 的智能体追踪规范已经把创建、搜索、更新、写入或更新、删除记忆定义为可单独观测的操作。

写入与读取的实现要点

在写入侧，文章给出了一个与具体 API 无关的伪代码关卡。它按来源与敏感度分类，丢弃凭据、失败工具调用的输出和低置信推断，把不可信内容隔离，并在涉及敏感信息时要求用户同意。通过之后才做范围解析、抽取、合并去重，并带着有效期和删除谱系写入存储。

文章还列出了一份受治理记忆记录应有的字段，例如租户、所有者、来源、置信度、有效期、被取代关系和保留类别。在读取侧，伪代码先按身份缩小候选集，再混合检索、排序，并剔除缺少来源或已被取代的条目。必要时再向权威系统复核，最后只组装最小上下文并附上引用。

对开发者的影响

这是我的分析，不是文章原话。

1. 记忆应当作为一个有独立权限与生命周期的服务来设计，不要把它当成提示词的附属品。 2. 多租户场景下，授权过滤要放在检索之前。共享向量库如果缺少过滤，即使结果很相关，也构成边界故障。 3. 日期、状态、价格这类会变化的事实，更适合每次查询权威系统，而不是缓存为长期记忆。 4. 删除需求要在设计之初就纳入，因为只删主记录可能遗留嵌入、摘要和缓存。