热点

AI SCORE

技术实践2026-08-20 00:00

PAM/PLUR/PROJECTMEM 对比如何改变 doll 的设计

dev.to · AI#AI记忆#架构设计#LLM

Editor brief · 编辑速览

作者在对比四种 AI 记忆方案后，将记忆从派生的召回状态中分离、确立项目经验为独立的追加历史、区分用户确认信息与模型提议信息的权限层级，最终带来具体设计改进。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

前文对 Portable AI Memory（PAM）、PLUR 的 Engram 规范、PROJECTMEM 以及 doll 进行了比较。

有价值的结果不是选出一个赢家，而是决定哪些概念应该放在哪一层。

我之前称之为"记忆"的很多东西，实际上是不同类型的、具有不同权威性的状态。这一区分改变了 doll 设计的具体部分。

最重要的五项变更是：

确认记忆（confirmed memory）与派生召回状态（derived recall state）分离；
交换格式（interchange formats）成为适配器（adapters），而不是 Doll State 本身的候选；
项目经验（project experience）成为自身面向追加的历史记录，而非当前项目权威；
导入的以及模型提出的信息保持在用户确认权威之下；
执行前连续性检查（pre-action continuity checks）成为独立的确定性读取模型，而非另一种执行权威。

本文讨论的是这些设计变更，而非对外部项目的又一次比较。

1. MemoryRecord 不是 RecallState

PLUR 有价值的地方在于，其 Engram 设计使检索动态变得可见：激活、衰减、强化、关联、使用反馈和搜索都会影响当前哪条记忆是有用的。

这与记忆本身是否仍然为真是不同的问题。

这个区分听起来显而易见——直到一个记忆系统开始把检索元数据与记忆内容存储在一起，并逐渐将两者视为同一对象。

在 doll 中，确认的 MemoryRecord 内容是规范性的持久状态。检索排名、激活类信号、搜索分数以及其他召回信号都是派生状态。它们可以改变、过期或重建，而无需重写记忆本身的内容。

这意味着，一条记忆不会因为最近没有被检索而变得"不够真"，也不会因为系统多次使用它而变得"更真"。

这也给 doll 提供了更清晰的单点故障模式。如果搜索索引或未来的激活缓存丢失，召回质量可能暂时下降，但确认的记忆不会随之消失。

召回可以从记忆派生。记忆不应该被召回默默重写。

2. PAM 成为适配器边界，而非 Doll State

PAM 使另一个边界变得清晰得多。

其规范明确将 PAM 描述为一种交换格式而非存储格式。这正是 doll 在边缘所需的那种边界。

PAM v1.0 规范：

https://portable-ai-memory.org/spec/v1.0/

一个诱人的替代方案是，仅仅因为可移植性很重要，就将一个可移植的外部模式作为规范的内部数据库。但可移植性和内部权威不是同一个问题。

因此 doll 将 PAM v1.0 视为适配器目标。导入的数据首先被解析并映射到一个暂存形式。不支持或含糊的语义保持可见。导入的记忆在通过适当的审查边界之前，不会成为正常的已确认 MemoryRecord。

导出则反向工作：确认的非秘密记忆可以用有限的 PAM 输出表示，而不需要假装 PAM 是一个完整的 Doll State 包。

最后一个区分很重要。记忆交换导出不是完整的连续性导出。它本身并不包含使长期运行的 AI 环境可恢复的每个项目、工作项、决策、权限、过程、恢复状态或执行边界。

在边界合适的地方使用外部标准。不要强迫内部权威模型成为交换格式。

3. 项目经验成为历史，而非权威

PROJECTMEM 锐化了一个不同的问题：项目历史应该超越聊天记录存留下来，并且应该在重复同样的错误之前就有用。

https://arxiv.org/abs/2606.12329

PROJECTMEM 源码仓库：

https://github.com/riponcm/projectmem

这促使 doll 将项目经验作为一级记录，而不是将失败尝试和教训困在对话历史中。

实现的 ProjectExperienceRecord 是面向追加的，可以表示观察、假设、尝试、结果、解决方案和教训。修正通过链接替换或取代来表示，而不是默默重写语义历史。

ProjectExperienceRecord 实现：

https://github.com/badjoke-lab/doll/blob/main/src/doll/project_experience.py

但最重要的是这条记录不被允许做什么。

一条经验记录不能完成或重新打开一个 WorkItem。它不能改变 ProjectRecord 范围。它不能创建 DecisionRecord。它不能批准一个必需的过程。它不能授予权限。

这个边界防止了一类非常容易犯的错误：把"这件事以前发生过"与"这是当前权威状态"混淆。

历史经验可以有价值，但不必是主权的。

4. 导入的和模型提出的信息保持在权威之下

一旦交换和项目经验都是一级概念，另一个问题立即出现：当导入的或模型生成的记录做出强声明时会发生什么？

一条导入的记录可能说一个项目已完成。一条模型生成的教训可能说某个特定动作不应再尝试。一种外部记忆格式可能包含一个看起来类似于本地权限的访问字段。

doll 不允许这些相似性制造权威。

导入的或模型提出的信息可以被保留、链接到来源、向用户呈现并用作证据。但它不能默默成为策略、权限、当前工作状态或硬性拒绝。

这也是为什么映射损失必须保持可见。如果一个外部概念没有精确映射到 Doll 概念，系统应该保留这种歧义，而不是发明一个干净的等价。

一个名为 confidence 的字段是简单的例子。一个系统可能指的是提取置信度；另一个可能指的是用户审查后的信任。因为名称匹配就将它们视为等价，会让迁移看起来更干净，同时损害权威模型。

保留导入的知识。也保留不确定性。

5. ContinuityPreflight 成为独立的读取模型

PROJECTMEM 的比较也让执行前检查更加具体。在重复一个已经失败的动作之前，系统查看已接受的项目历史是有价值的。

但 doll 已经有了针对策略、工作状态、过程、权限和能力的独立权威边界。将所有这些折叠到一个新的"记忆判断"层中，会使架构更难推理。

resulting implementation is ContinuityPreflight：一个确定的、模型无关的读取模型，覆盖明确的已接受项目和动作范围。

ContinuityPreflight 实现：

https://github.com/badjoke-lab/doll/blob/main/src/doll/continuity_preflight.py

它组合了现有的权威信号，如适用的策略拒绝、WorkItem 阻塞和不完整依赖、必需过程状态、权限解析和能力安全状态。它还可以将直接相关的先前失败从 ProjectExperienceRecord 作为带证据链接的警告呈现。

警告与权威之间的区分是有意为之。一次过去的失败尝试可以警告而不会成为永久禁止。导入的或模型提出的经验不能制造硬性拒绝。

而且预检结果为 clear 并不授予执行许可。Capability Broker 仍然是执行授权边界。

连续性检查可以影响执行，但不会成为授权执行的东西。

比较更多地改变了边界而非功能列表

这些变更都不是说 doll 应该全盘吸收 PAM、PLUR 或 PROJECTMEM。事实上，比较推动设计朝相反方向发展。

有用的部分属于不同的层：

PAM 属于交换边界；
类 PLUR 的激活和检索思想属于派生的召回状态；
类 PROJECTMEM 的项目经验属于面向追加的工作历史；
当前项目状态、权限、策略和执行权威保持分离；
执行前连续性是对已接受状态的确定性组合，而非新的真相来源。

这比添加另一个名为"记忆"的功能更重要。

我故意没有采纳的部分

比较同样有用，因为它识别了应该保持外部、派生或后续工作的想法。

doll 目前不声称有 PLUR 适配器或 PROJECTMEM 适配器。MCP 没有作为这项工作的一部分实现。PAM 互操作性不意味着完整状态包互操作性。ProjectExperienceRecord 不是 WorkItem、DecisionRecord、PolicyRecord、ProcedureRecord 或 PermissionRecord 的替代品。

该项目也不声称 Phase 6、Lite v1.0、primary Intel Mac 资源接受，或通用的反锁定标准已经完成。

这些限制很重要，因为架构比较很容易变成一个关于完成的通用层的故事。doll 还没有到那一步，这项工作也不假装如此。