记忆可能仍然真实，却已经不再安全

持久记忆改变了 AI Agent 的风险边界。Agent 可以跨会话恢复之前的事实、决策、批准和计划，但它也可能非常自信地从一个“昨天正确、今天已不适用”的状态继续执行。

信号来自 provenance 讨论。

在 Claude Code 的记忆讨论中，贡献者 DanceNitra 区分了“看起来有来源”与“真的可以重新访问来源”。在其报告的数据集中，大约 98.3% 的记录拥有 source 字段，但只有 24 条记录——约 0.01%——使用了真正可以重新获取并验证的来源标识。

像 agent:scholar 这样的值可能标识写入者，却不一定能定位原始内容。因此，拥有 provenance 元数据，并不等于系统能够检测来源漂移、删除或替换。

同一讨论还暴露了第二类风险：如果库之后把 caller-controlled metadata 当成自己可信验证路径产生的状态来解释，这些元数据就可能错误地获得信任。

但 provenance 即使正确，也还不够。

假设 Agent 记得某个 pull request 在 commit A 上已经通过审查。这一历史事实可以完全真实。但当前 branch 可能已经移动到 commit B，策略可能改变，租户可能不同，API 可能升级，授权也可能过期。

如果 Agent 只问“这条记忆当时有效吗？”，它可能得到“是”，却仍然做出错误决定。

从讨论到可执行契约。

我们在开源 Causal Memory Layer (CML) 中实现了一个确定性的 Current-State Applicability 层。该实现经过 review，并针对 stale-SHA 与跨仓库替换进行了强化，随后合并，并通过 Python 测试、deterministic-contract 检查、package validation、secret scan、dependency audit 与 CodeQL。

为什么 repository 与 commit SHA 必须更严格。

Review 中出现了一个重要边界案例：如果历史记忆从未绑定 repository 或 commit SHA，即使来源 digest 匹配，它也可能在新的代码上下文中错误地获得 MATCH。现在，只要当前 authoritative state 提供 repository 或 commit SHA，而历史证据缺少相应绑定，就必须返回 REVALIDATE。

缺少历史上下文，并不等于可以假设连续性。

环境应该按用途绑定，而不是整体做一个全局哈希。

并不是每一种变化都应该使每一条记忆失效。修改一个无关 README，不一定要撤销关于 tenant-scoped billing rule 的记忆。Applicability 因此需要 purpose-bound context fingerprint：只让与当前行动真正相关的环境维度参与判定。

应该过期的是权限，不是真实。

过期的 approval 仍然应该保留在审计记录中。旧 commit 的 review 在 branch 移动之后仍然是历史事实。后来被删除的来源也不应该让过去“从未发生”。

这不应该成为 vendor moat。

我们将这一提案同时分享给了 Anthropic 和 OpenAI。原因很简单：Memory Revalidation 作为跨生态的安全与互操作 primitive，比作为单一厂商的封闭功能更有价值。

memory
→ provenance verification
→ source re-fetch / integrity
→ current environment comparison
→ applicability verdict
→ current authority
→ action

更有用的覆盖率指标也可以拆成四类：

1. Locator coverage：我们能否识别来源？
2. Re-fetch verification coverage：我们能否重新访问并比较 digest？
3. Source enumeration coverage：我们能否检测删除或 orphaning？
4. Environment binding coverage：我们是否掌握足够的当前上下文来判断复用是否安全？

记忆告诉 Agent 什么曾经是真实的；Applicability 告诉它，这个真实现在是否仍有资格驱动行动。