Agent 能记住不是终点，能“该忘就忘“才是：2026 多智能体记忆治理的第一份硬指标

来源：arXiv 2026-06（cs.MA）

论文：GateMem: Benchmarking Memory Governance in Multi-Principal Shared-Memory Agents

核心标签：记忆治理 / 多用户Agent / 访问控制 / Active Forgetting / MGS指标

📌 为什么你现在应该读这篇

你做的那个 RAG / Agent 系统，是不是这种状态：能存能取，外加一个向量库，就当"有记忆"了？

我之前也是。直到 GateMem 这篇论文用一个综合指标把所有主流方案的遮羞布全揭了：没有一种现成方案能同时做到「有用、守边界、会遗忘」。

三件做多用户 Agent 的人不能不知道的事：

① 记忆"能用"和"能治理"是两回事

long-context prompting 能记，但守不住边界（A 用户的信息可能被 B 用户的提问勾出来）。Retrieval-based 能查得准，但忘不掉（删了向量库还在 prompt 缓存里）。external-memory 能持久化，但成本随用户数线性爆炸。每个方案都偏科。

② "能不能忘"正在成为新的考核维度

过去做记忆系统的人只关心 Recall（能不能找回来）。GateMem 引入 Forgetting Score（能不能可靠地忘掉），实测显示：主流方案的可控遗忘率普遍低于 40%。换句话说，你说"删除我的数据"，系统其实只是"假装删除"。

③ 多 Principal 场景把单用户假设的洞撕开了

单用户 Agent 没有这些问题。所有信息都属于你。一旦变成多用户/多租户/多 Agent 共享记忆，"谁能看到什么"立刻变成生死问题。这是大模型应用从 demo 走向 SaaS 的必经之坎。

如果你正在做：(1) 多用户 SaaS Agent；(2) 企业内部多团队共享的 RAG 系统；(3) 涉及 GDPR/数据合规的 Agent 产品，下面的指标设计可以直接借鉴。

论文元信息

论文：GateMem: Benchmarking Memory Governance in Multi-Principal Shared-Memory Agents (arXiv:2606.18829)
关键数据：评测 long-context prompting / retrieval-based / external-memory 三类主流方案
核心创新 ：提出 MGS（Memory Governance Score）= U × (1-A) × (1-F)
- U = Utility（有用度）
- A = Access Control Violation Rate（访问越权率）
- F = Forgetting Failure Rate（遗忘失败率）
核心发现：三类方案中没有任何一种能在三个维度同时达到优秀

核心场景：当你的 Agent 服务两个老板

想象一下：你做了一个企业内部的研发助理 Agent，部署给两个团队用。支付组和风控组。

支付组的工程师问 Agent："上次那个对账接口的边界条件是什么？"

Agent 完美回答了。问题是：这个边界条件是风控组三周前讨论的内部细节。Agent 没有意识到 Principal 切换，把信息泄漏了。

这不是科幻场景。这是 long-context prompting 方案的默认行为。所有上下文都共享同一份"记忆"，模型不知道"谁该看到什么"。

更糟的是遗忘。三个月后支付组的人离职了，按合规要求他相关的会话记录要删除。你删了数据库里的对话表。但是：

向量库里他提问的 embedding 还在
上次基于他的对话生成的"项目知识库摘要"还在
模型的 system prompt 里引用了"支付组之前的常见问题"，还在

你以为删了，其实没删。这就是 GateMem 测出来的 F（Forgetting Failure Rate）。

关键数据：MGS 综合评分中，主流方案最佳得分仅 0.4-0.5（满分 1.0）。U 普遍能到 0.8 以上，但 A 和 F 拖后腿严重。

三个核心点：MGS 指标怎么解构记忆治理

一、Utility（有用度）：还要保持能记

记忆系统首要价值是有用。如果为了安全把记忆全删了，Utility = 0，整个系统失去意义。

GateMem 的 U 通过任务完成率衡量：给 Agent 一系列依赖历史上下文的任务，能正确完成的比例。

这条容易理解，过去三年所有 RAG/Agent 工作都在优化它。问题是其他维度长期被忽视。

二、Access Control（访问控制）：谁能看见什么

多 Principal 场景下的核心问题。GateMem 引入 Principal-scoped query：模拟用户 A 的 query，注入"试图获取用户 B 信息"的探针，统计泄漏率。

实测发现：

long-context prompting：A 接近 50%（基本无防护）
retrieval-based：A 约 15-25%（加了元数据过滤但不够）
external-memory（带 ACL）：A < 5%（设计上防护，但工程复杂度高）

工程意义：如果你的产品涉及多用户，retrieval 加 metadata filter 是底线，但还不够。需要在生成阶段加 Principal 校验。

三、Forgetting（遗忘能力）：能不能真正忘掉

这是 GateMem 最大的方法论贡献。论文设计了"遗忘验证 protocol"：

让用户 X 跟 Agent 交互一段时间
调用"删除用户 X 数据"的接口
用各种探针（直接提问、间接暗示、跨 session 引用）测试残留信息

主流方案的 F（Forgetting Failure Rate）：

long-context：F ≈ 70-90%（上下文窗口里还在）
retrieval-based：F ≈ 40-60%（向量删了但派生数据还在）
external-memory：F ≈ 20-40%（设计上能删，但实际涉及多份拷贝）

这意味着 GDPR 合规几乎是个伪命题。按现有技术，"被遗忘权"做不到。

So What：三类人的行动清单

🔧 工程师

在记忆 schema 里加 principal_id 和 created_by 字段 ------ 这是治理的最低门槛，比加 RAG 优化更优先
建立"遗忘验证"测试集 ------ 每次记忆系统升级，跑一遍 Forgetting Failure Rate 测试，不能只测 Recall
明天就能做 ：打开你 RAG 系统的 vector store schema，加一个 principal_id metadata 字段，查询时强制 filter；删除接口同步删除所有派生数据（缓存、embedding、摘要）

📊 技术管理者

把 MGS 三个维度写进记忆系统的 KPI ------ 不要只考核检索准确率，要同时考核 A 和 F
盘点你产品里的 Principal 边界 ------ 哪些用户对哪些数据有访问权，画一张矩阵，对照现有记忆方案查漏洞

🚀 创业者/PM

如果你做 B2B SaaS Agent，记忆治理是定价权来源 ------ 企业愿意为"可证明的合规"付溢价，这是 demo 级产品做不到的
下一波 Agent 创业差异化在治理层 ------ 不再是"我的 RAG 更准"，而是"我的记忆守得住、忘得掉、能审计"
明天就能做：在你的产品定位文档里加一句"记忆治理能力"，看销售场景里它能不能成为你和竞品的差异点；如果不能，认真考虑要不要补这块

⚠️ 方法论局限

MGS 是综合分，但权重设定主观：U×(1-A)×(1-F) 的乘法形式意味着任一维度极低就拖死总分，但实际产品中不同场景的权重不同（医疗高 A 权重，娱乐高 U 权重）
测试集偏学术：论文使用合成的 Principal 场景和探针，真实企业的 Principal 关系比这复杂（角色继承、临时授权、跨组协作）
没有覆盖"模型自身的 prompt 缓存"：当前主流 LLM API 有 prompt caching 优化，这部分的遗忘控制完全在 vendor 手里
遗忘测试只测显式探针：没有覆盖"模型隐式学到的统计规律"，比如即使删了某用户数据，模型对"该用户行业的典型行为"的认知不会消失