MAQS-Way v0.2 发布：为AI长期记忆制定可验证标准

大多数发布说明都在讲完成了什么。这一篇，从没完成的部分开始。

MAQS-Way v0.2 正式发布了。它不再是一个预览版本，而是一个面向 AI 长期记忆的实用标准的首个次要版本。与一般软件发布不同，这个版本主动公开了 12 个已知缺口，每一个都附有负责人和目标版本，直接列在规范文档里。作者 Aleksandr Kossarev 把这种做法称为"设计使然"。

缺失的中间层

MAQS-Way 试图填补的是一个已经被政策文件和企业内审文件夹击、但始终未被系统化描述的空白地带。

政策层规定了"什么必须成立"，比如 GDPR 第 17 条、欧盟 AI 法案第 12/13/19 条、RBAC 等。审计层则有 MAQS v1.6 这样的清单，背后是实际生产事故的沉淀。但从政策到审计之间，一直缺少一条路径层：具体应该选择哪种实现，怎么证明它真的能工作。

MAQS-Way 就是这个路径层。它包含 8 条原则（P1–P8）、基于 OMPS 的数据模型、生命周期管理，以及可度量的验证手段（LoCoMo、LongMemEval、删除格、负向测试）。按作者的说法，它今天是一个"配有部分可执行检查的描述"，其余部分被声明出来并分配了负责人，而非假装已经在生产环境中验证过。

OMPS（Open Memory Persistence Schema） 是 MAQS-Way 用来描述 AI 记忆系统底层数据契约的一套模式规范。它定义了记忆条目、来源、租户边界、生命周期状态等核心实体及其关系，类似于数据库的 schema，但面向的是跨系统的记忆持久化语义。OMPS 的目标是让不同实现（如 Mem0、Graphiti、Letta）能够在同一套字段语义下被审计和比对，从而把“记忆系统是否合规”从主观判断变成可机械检查的结构问题。MAQS-Way v0.2 所冻结的 way-v0.1.3 正是 OMPS 的一个具体版本快照，独立于标准发布号，以保证数据契约的稳定性。

验证而非信任：审计真的跑起来了

MAQS-Way 最具特色的地方在于，所有声明都是可执行的。整个验证过程只需一条命令：

$ python3 schemas/maqs_way_audit.py all
schema 4/4 + manifest 12/12 + declared 8/8 (005 ∈ declared) + executed (canon-pin) 1/1 + namespaces ok
GAP (enumerated, not folded): B4 -> owner SPEC §2.5, closes in v0.3
GATE GREEN

输出结果的含义是：4 个 schema 通过，12 个 manifest 条目通过，8 个行为被声明（并且诚实地标注为"已声明"而非"已验证"），1 个数字被固定到规范，命名空间验证通过——同时那个已知的缺口被打印出来，而不是被隐藏。

关键细节在于门禁如何处理缺口：它把缺口大声列出来，同时保持绿灯。一个版本可以携带缺口，但绝不允许携带沉默的缺口。这里的"绿灯"认证的是发布规则的合规性——包括"每个缺口都已列出"这条规则——而不是没有问题。这种设计将对标准的信任建立在透明之上，而非完美之上。

LoCoMo（Long-Context Memory Benchmark） 与 LongMemEval 是评估长期记忆能力的基准测试集。LoCoMo 侧重多轮长对话中的事实召回与一致性，LongMemEval 则覆盖更广泛的长时记忆任务，包括时间推理、冲突消解和遗忘验证。在 MAQS-Way 中，它们被用作可度量的验证手段，而不是单纯的功能演示——审计报告会引用具体测试结果来证明某个原则（如矛盾失效、老化衰减）是否真正生效。Graphiti 被评为“评估故事最完整”，正是因为其单元测试、端到端测试和 LongMemEval 预言机三者齐备，形成闭环证据链。

三套独立代码库，同一把尺子

MAQS-Way 团队把检查清单应用到了三个开源记忆系统上，采用静态阅读、file:line 证据、帮助而非批评的语气。三套代码库、一套清单，每个系统都会被评出"典范"项和缺口项，加减分用的是同一把尺子。

一个观察如何变成裁决的例子：在 Mem0 中，租户过滤器在 top-k 之前就到达了向量存储（main.py:1471），因此隔离性是通过"尝试违规"来证明的，而不是通过过滤器是否存在来判断。这对应 MAQS 的 G1 原则，是可执行的。

三份完整报告的结果如下：

• Mem0：租户隔离堪称典范（pre-top-k 过滤器）；在来源追溯、老化（衰减仅限平台层）、删除残留、写入原子性上部分达标；在信任类型和内置评估工具上存在缺口。
• Graphiti：矛盾即失效机制堪称典范（旧边被保留并标记 expired_at）；三家中评估故事最完整（单元测试 + 端到端测试 + LongMemEval 预言机）；在审计接收器、无范围搜索上存在缺口。
• Letta MemFS 客户端：构造即失败关闭的隔离机制；策略测试深度足够；在老化机制上存在缺口（只有预算，没有 TTL）。

这种跨代码库的横向审计方法本身值得关注：它把"标准"从纸面文字变成了可以对照执行的动作，而且对开源项目保持建设性而非攻击性的姿态。

Mem0、Graphiti 和 Letta MemFS 是三个面向 AI 记忆的开源实现，设计取向不同。Mem0 以向量存储为核心，强调租户隔离和可扩展写入；Graphiti 基于时序知识图谱，用边过期（expired_at）实现矛盾消解；Letta MemFS 则把记忆当作文件系统来管理，侧重构造即失败关闭的策略。MAQS-Way 用同一份检查清单对三者进行静态审计，并以 file:line 形式给出证据，使得跨系统的横向比较成为可能——这既是标准的落地验证，也是开源生态中一种建设性的互评机制。

开放缺口与关闭时间表

所有剩余缺口都通过明确的发布决策被重新定档到 v0.3，没有任何一个被悄悄处理。

具体包括：B4 写入原子性；E10/E11、I10–I12、I14、I15、P9/P10 的规范化；死代码规则 0.5a 和漂移阈值 0.6a——总计十二个，每个都有负责人。

说个细节数据模型的状态：它已经被冻结（schema_version way-v0.1.3，而发布版本是 v0.2）。所有 v0.2 的变更都是表述和测试框架层面的，没有触及数据模型。这种版本号与规范版本号的分离设计，使得标准的表述层可以持续演进，而底层数据契约保持稳定。

如何参与

MAQS-Way 的仓库、发布页面和讨论区都已开放。作者特别强调了一点反馈机制：如果你发现审计报告中有误读，可以提 issue，修正会以第二个 commit 的形式落地，发现的内容永远不会被静默地重写。

作者 Aleksandr Kossarev 来自爱沙尼亚的 Jõgeva，他用一句话概括了整个项目的立场：不要检查机制是否存在，要检查它是否真的工作。

对于一个试图成为"AI 长期记忆标准"的项目来说，这种把缺口写进规范、把验证做成可执行命令、把修正记录在 commit 里的做法，可能比任何功能列表都更有说服力。毕竟在 AI 记忆这个领域，最大的风险从来不是缺少机制，而是机制看起来存在却经不起验证。