MAQS-Way：LLM长期记忆的路径层标准，让合规从策略走向可度量验证

当合规策略与工程实现之间出现断层

LLM 助手的长期记忆系统正面临一个尴尬的现实：政策层面有 GDPR 第 17 条、EU AI Act 第 12 条、RBAC 等法规约束，审计层面有 MAQS（Memory Architecture Quality Standard）这样的检查清单，但两者之间缺少可执行的工程路径。MAQS 本身是一份罕见的产物——它基于 20,000+ 条 traceback 和生产事故，告诉开发者「如何验证记忆不会出错」。

然而在外部评审文档 way.md 之后，作者 Aleksandr Kossarev 发现了一个关键缺口：策略层过于拥挤（规定「应该怎样」），审计层已经存在（确保「不会崩」），但路径层缺失——该用哪些 schema、生命周期和模式，以及如何证明它真的有效。这个缺口就是 MAQS-Way 试图填补的位置。

现有生态：没有单独一个方案能构成完整路径

作者对开源领域做了一次扫描，列举出若干独立但互补的项目：

数据模型层面，OMPS（rdh073/omps）提供了厂商中立的可移植性，包括 memory-item.schema.json 和 deletion-marker.schema.json；AMSP（sanej/amsp）补充了 schema 加生命周期（active→deleted）以及 user-portable 等作用域定义。

溯源与时间维度，OAMP（deep-thinking-lab）将来源追溯设为强制项，要求 agent_id 绑定（§4.3）；Zep/Graphiti（getzep/graphiti）实现了双时间戳（valid_at/invalid_at 加 t_created/t_expired）、矛盾触发失效机制，DMR 达到 94.8%。

运维与删除，MemoryOps AI（patibandlavenkatamanideep/memoryops-ai）定义了 10 条不变量和 Write Path Gateway→Extractor→Policy Broker→Write→Audit 流程；Tombstone 规范提出 6 层删除级联——其基准测试显示原生向量删除会留下 92-100% 可恢复残留，而 tombstone 方式为 0%。

评测与安全，LoCoMo/LongMemEval/MemoryAgentBench 提供了可度量的 R@k、时间推理和弃答指标；OWASP Agentic ASI06 专门针对记忆与上下文投毒。作者的核心判断是：这些项目各自都不足以构成完整路径，但它们合在一起可以。

**双时间戳（bi-temporal）**是 Zep/Graphiti 时间维度的核心机制，源自数据库领域的时态建模思想。它区分两类时间：valid_at/invalid_at 表示事实在真实世界中成立与失效的时间（有效时间），t_created/t_expired 表示该记录在系统中被写入与标记失效的时间（事务时间）。两者分离的意义在于：当系统在 T 时刻才得知某事实，而该事实实际在更早时间就已生效或失效时，查询可以按任一维度重建历史。矛盾触发失效机制则利用这一结构——新事实写入时若与旧事实冲突，旧记录被标记 invalid_at 而非物理覆盖，从而保留完整的可审计轨迹。这正是 DMR（矛盾检测率）达到 94.8% 的基础，也是记忆系统实现「可控老化」而非简单遗忘的关键。

MAQS-Way v0.1.4 的三层结构

八条不可变原则

Veracity（真实性）、Provenance（溯源）、Controlled Aging（可控老化）、Isolation（隔离）、Deletability（可删除性）、Recoverability（可恢复性）、Portability（可移植性）、Measurability（可度量性）。这八条是整个框架的约束基础，被写入机器可读的 maqs-way-standard.json（P1-P8）。

P1-P8 的机器可读化（maqs-way-standard.json）意味着这些原则不只是文档口号，而是可被 CI 直接加载校验的结构化约束。以 Provenance（溯源）为例，它在架构层落地为仅追加的 provenance 字段与强制的 agent_id 绑定（引自 OAMP §4.3），使得任何记忆条目都能回溯到产生它的具体代理与轮次。Controlled Aging（可控老化）对应完整的生命周期状态机与双时间戳，避免无差别驱逐。Measurability（可度量性）则要求每条原则都绑定可量化的验证指标，否则不予通过。将原则编号化并写入 JSON，让下游工具可以按 P 编号引用、测试与出具一致性报告，这是「治理契约」区别于「审计清单」的技术前提。

架构层的关键设计

数据模型以 OMPS 为基础，叠加 OAMP 强制的 agent_id、仅追加的 provenance，并明确「被接纳不等于被信任」（admitted≠trusted）。

生命周期定义了完整状态机：ACTIVE→STALE→CONTESTED→SUPERSEDED→EXPIRED→ARCHIVED→DELETED→TOMBSTONE→COMPACTION，并配合双时间戳。

删除采用 6 层级联（graph_edges → nodes_if_sole_provenance → embeddings_fk → facts_fk → artifacts → rounds），在单一事务内完成，再辅以尽力而为的图协调。

墓碑记录为 deletion_log(request_id, timestamp, scope, layer_counts, requestor)，零 PII，Ed25519 签名，哈希链式结构。

隔离采用分层作用域：local-session < agent-private < user-portable < team-shared < org-shared，并通过跨租户零泄漏的负向测试和 G1 固件（错误作用域、只读写操作、撤销后访问）验证。

内容即数据原则要求用围栏包裹 <retrieved_context type=model_output>，禁止盲目截断。

验证层：检查机制是否真正有效

这是 MAQS-Way 最具工程价值的部分。每个检查项拆分为「属性 / 验证方式 / 示例」三部分。最小黄金集定义如下：

属性	CI 门禁	目标值
检索	R@5 ≥0.7（LongMemEval oracle）	R@5 ≥0.85
时间推理	≥0.65	≥0.8
弃答	无证据时 ≥0.8	≥0.9
重复	≤5%	≤2%
污染	≤1%	0
删除残留	0%（逻辑/物理/语义/模型四层）	0%
隔离泄漏	0	0
投毒阻断	100% ASI06	100%

日志层面要求满足 EU AI Act 第 12 条必需字段、OTel gen_ai.conversation.id 以及防篡改哈希链，默认保留 12 个月，受监管场景 6 年，并启用 WORM 锁。

R@5 是检索评测中的常用指标，全称 Recall@5，指在前 5 条返回结果中包含正确答案的比例，衡量的是召回的覆盖能力而非排序质量。文中 LongMemEval oracle 表示使用标准答案作为查询输入的理想检索设置，用于剥离查询改写等环节的干扰，单独评估记忆库本身的召回上限。**弃答（abstention）**指标则衡量系统在「无证据」时的克制能力：当上下文确实不包含可支撑答案的记忆时，模型应拒绝作答而非编造，其门槛 ≥0.8、目标 ≥0.9。这两个指标互补——前者防止系统漏掉已有证据，后者防止系统在缺失证据时产生幻觉，共同构成记忆系统可信度的下限。

与 MAQS 的协同关系

两个仓库运行在同一坐标系中：MAQS v1.6 是摆在桌面上的审计清单，输出 CRIT/IMP/REC 三级判定；Way 则是治理契约，引用 MAQS 的 0-J 章节作为实现证据。

仓库地址分别是 MAQS（github.com/alexk202/memory-architecture-standard）和 Way（github.com/alexk202/maqs-way）。后者包含机器可读的 8 条原则、conformance/valid/invalid 目录下的 7 个测试向量（no-agent-id、model-output-as-trusted、cross-tenant、native-delete-residue、deletion-tombstone 等），以及用于运行 LoCoMo/LongMemEval 的 evals/ 目录。

下一步与核心主张

作者的路线图是冻结 Way v0.1.4、发布一致性验证、并在不同技术栈上运行 tombstone 基准测试，同时在 OMPS/AMSP/OAMP/MemoryOps/Zep 等项目中提出 issue，将 MAQS-Way 作为验证层接入。

整个项目的主张可以浓缩为一句话：不要检查机制是否存在，要检查它是否有效。 对于正在构建 LLM 长期记忆系统的团队来说，这套从原则到架构再到可度量验证的三层框架，提供了一条比单点合规更务实的路径。

背景补充

**仅追加（append-only）**是溯源与不可篡改性的工程基础：记录一旦写入便不被原地修改，状态变更以新事件追加表示。结合 ACTIVE→STALE→CONTESTED→SUPERSEDED 的转移路径，每次演化都留下独立事件，配合哈希链即可验证历史未被篡改。TOMBSTONE 与 COMPACTION 是生命周期末端的一对机制：TOMBSTONE 保留被删除对象的非 PII 元数据（如 deletion_log），用于事后证明「此处曾有内容且已被合规删除」；COMPACTION 则在保留证据的前提下压缩冗余存储。二者与 6 层级联删除相互配合，既确保 0% 残留，又避免删除动作本身变成不可审计的黑箱。