摘要

本 RFC 引入 atomic-memory Family，将原来 Memory 集合中的每条记忆改为独立 Artifact，由 Scope 组织。每条记忆分别维护自己的 ID、版本、证据和状态。

抽取先从 Source 生成候选记忆，再检索同一 Scope 内有权读写的相关在役记忆，由模型自动决定新建、更新、合并或不写入。多条记忆合并时创建新 Artifact，原记忆保留历史并停止演进；用户可以编辑合并结果，也可以撤销合并。检索遵守 RFC #1803，现有部署按照 RFC #1771 停服升级。

动机

Memory 集合与 Scope 的职责重叠

RFC 0014 将 Memory 设计为一个记忆集合：Memory Artifact 保存完整条目目录（manifest），其中每一项指向一个不可变的 entry version。修改一条记忆，需要写入新的 entry version，再生成引用它的集合版本。

RFC 1345 引入 Scope 后，同一 Scope 仍然只有一个活跃的 Memory 集合。因此，一条记忆同时涉及集合的 ID 和版本，以及 entry 的 ID 和版本。Scope 已经可以组织记忆， Artifact 也已经提供版本、证据、权限和标签，这层集合保留了额外的维护规则。

修改一条记忆，也要保存整个集合的目录

当前实现已经支持 entry 修订、历史读取、容量限制和可选的目录清理（compact）。正文和检索投影可以按变化的条目更新，但每次有效修改仍需重新构造并保存完整 manifest，其中大部分条目可能没有变化。

持续写入会积累重复的目录信息。两个任务即使修改不同记忆，也需要更新同一个集合的当前版本（head）。将每条记忆改为独立 Artifact 后，单条更新只增加该记忆的历史版本。

抽取上下文随记忆数量增长

当前内置抽取会把所选 Memory head 中的全部活跃 entry 交给模型。模型可以修订之前 Source window 产生的记忆，但随着记忆积累，每次抽取的上下文和输入成本都会增长。

本次改造需要在生成候选后先检索相关记忆，再交给模型判断，同时补充多条记忆合并及撤销合并的规则。仅增加 entry 替换接口，无法解决这些问题。

使用说明

一条记忆，一个 Artifact

Atomic Memory 表示一项可以独立理解、更新的事实、偏好或规则。“原子”描述内容粒度，不要求每条记忆只有一句话。一项事实需要时间、原因或适用条件才能说清楚时，应保留这些内容。

例如，“默认部署区域为华东”和“生产发布需要负责人审批”是两条记忆。部署区域改为华北时，只为第一条记忆生成新版本。旧版本的精确引用仍返回当时的正文。

记忆可以从 Source 自动抽取，也可以由有权限的调用方手工写入。

先检索，再由模型决定如何写入

处理新的 Source 时，先生成候选记忆，再检索同一 Scope 内在役、且执行身份有权读写的相关记忆。相似度用于寻找相关内容，模型结合候选、已有记忆和证据，决定新建、更新、合并或不写入。这些操作默认自动执行，无需逐次审批，也无需预先授权某一类合并。

只读共享内容不能成为本次更新、合并或停用的对象。同一事实在相同适用条件下出现冲突时，模型按时间采用较新的有效内容，自动完成修订或合并。优先依据明确的生效、事件或来源记录时间，缺少可比较时间时按 Source 采集顺序处理。Atomic Memory 不保留等待用户处理的冲突，也不要求用户逐项确认。

时间和适用条件仍需保留：迟到的旧资料不因刚被采集就成为新事实，不同环境的规则也不应互相覆盖。修订或合并本身不会更新事实的时间。旧内容和依据保留在历史与 lineage 中，判断有误时可由后续 Source、用户编辑或恢复操作纠正。

达到相关度阈值的记忆都应进入比较范围，不能只取固定的前 N 条并忽略其余结果。数量较多时可以分批检索、分批交给模型处理。未启用或无法使用向量检索时，也要通过全文检索等方式筛选相关记忆，不能将整个 Scope 的记忆直接放进模型上下文。

合并产生新的记忆

A、B 合并时，创建新的记忆 C。C 记录这次合并所使用的 A、B 的精确版本；A、B 进入“被合并”状态，停止正文演进，退出正常检索，但历史仍可点查。后续 Source 或用户修改继续更新 C。

模型可以根据新证据舍弃失效内容。提示词应区分失效与遗漏，保留仍然有效的事实、适用条件和证据，避免在改写时丢失信息。提示词无法消除所有误判，因此需要保留原记忆和合并历史，让用户能够纠正或撤销。

四种状态

状态	正常检索	有权限时点查	恢复方式
在役	可以	可以	—
遗忘	不参与	可以	可以单独恢复为在役
被合并	不参与	可以	撤销相关合并后恢复，不能单独修改状态绕过合并关系
退役	不参与	可以	不可恢复原身份

只有在役记忆参与新的合并。C 被遗忘后，A、B 仍处于“被合并”状态；恢复 C 只恢复 C，恢复 A 或 B 则需要撤销产生 C 的合并。点查历史不会自动恢复记忆。

纠正内容与撤销合并

用户可以通过 Agent 或管理界面编辑 C，也可以让后续采集的 Source 继续推动 C 演化。恢复 C 的旧版本时，以旧内容生成一个新版本，不改写历史，也不改变 A、B 的状态。

撤销产生 C 的合并，则恢复 A、B 被冻结时的版本，并将 C 退役。C 后续增加的内容也随之退出正常检索，不会自动分配回 A、B；C 的全部历史仍可点查。用户从 A 或 B 发起恢复时，由服务端完成这次整组操作。

连续合并同样由服务端处理。例如 A、B 合并成 C，C 又与 D 合并成 E。用户请求恢复 B，服务端依次撤销 E、C，最终恢复 A、B、D，退役 C、E。用户只需发起一次请求。若 D 也由其他记忆合并而来，恢复 D 即可，不继续拆开 D。

撤销合并默认恢复各输入被合并时的精确版本。请求也可以指定目标记忆的历史版本：先撤销使它处于“被合并”状态的后续合并，再用所选内容为目标生成新版本，其他被恢复的输入仍使用冻结版本。例如，恢复 C 的旧版本只需撤销 E，不撤销产生 C 的合并。上述过程仍由同一次请求完成；指定历史版本也不能恢复已退役的记忆。

只沿当前仍生效的合并关系处理，不沿普通证据引用回滚其他制品。撤销不回退 Source 消费进度；新的 Source 到来后，模型仍可决定再次合并，并创建新的记忆身份。

回滚预览与直接调用

服务提供独立的回滚预览和执行操作。预览不修改数据，返回将恢复的记忆及版本、将退役的合并结果，以及会退出当前检索的后续内容。管理界面据此展示影响，用户确认后执行。

前端已有状态只用于提示，实际影响范围由服务端确定。按预览执行时，服务端检查目标记忆及其版本、恢复操作是否与预览一致，以及当前合并终点的正文版本和状态版本是否改变；不一致则拒绝这次执行，要求重新预览，不能扩大用户已经确认的范围。

用户或 Agent 也可以直接请求恢复目标，无需先预览或逐层寻找合并结果。服务端按执行时的状态计算并完成恢复，返回实际受影响的对象。直接调用仍须通过权限、状态和并发检查。预览后的确认仅用于用户主动回滚，日常抽取和合并继续自动执行。

参考级说明

沿用的规范与本次调整

Scope 归属和组织沿用 RFC 1345，Source 处理沿用 RFC 0019，身份、版本和证据沿用 RFC 1549。多条记忆成为独立 Artifact，不意味着每条记忆分别消费 Source；处理进度仍由所属 Scope 的抽取流程维护。

本提案替代 RFC 0014、0019 中集合与 entry 分别维护版本的模型，并取消 RFC 1345 中每个 Scope 只有一个活跃 Memory 集合的要求。

RFC 1652 的证据保留原则继续适用。Atomic Memory 的新增、更新与语义合并默认自动执行，冲突按时间自动处理，不适用其中语义合并逐次审批和保留未解决冲突的要求；多条记忆合并采用“新建结果、冻结输入”的方式。本提案不修改其他制品的审批及冲突处理规则。

RFC 1718 针对完整 manifest 设置的集合容量限制不适用于新 Family，不将其换算为 Scope 记忆总量上限，也不新增历史版本到期删除策略。旧配置的处理在发布兼容说明中明确。

检索与并发

检索投影及其更新遵守 RFC #1803。Atomic Memory 可以使用宽表或独立投影；全文、向量召回不使用业务表 JOIN。抽取选择可修改的记忆时，Scope、读写权限和在役状态须在候选选择阶段生效。

单批大小用于控制每次读取和模型输入，不得截断达到阈值的总结果集。处理尚未完成时，不能将其报告为“没有新记忆”。具体阈值、分批方式和索引选择由实现设计确定。

合并、恢复及撤销涉及的记忆状态、关系和当前检索数据必须一起生效。不能出现原记忆已经恢复，而合并结果仍在正常检索中的中间状态；同一在役记忆也不能被并发合并进两个同时有效的结果。

执行恢复时，服务端在写入事务内检查当前正文版本、状态和合并关系。带预览标识时，还要检查是否符合预览；不带标识时，按当前状态处理。检查结果须在提交时仍然成立，不能覆盖期间发生的更新。

升级与兼容

现有部署按照 RFC #1771 停服升级。数据库结构变更、数据转换、投影重建、归档保留及旧表清理由其统一流程管理。

每条旧 entry 的完整正文版本、原有直接证据和当前生命周期状态迁入 Atomic Memory；保留已有 entry 标签和 Owner。合法的 entry 共享授权自动迁移，保留关系身份、权限以及撤销和过期状态。Atomic 的 Owner 要求与其他制品一致，未启用鉴权时不补造 Owner，启用鉴权时沿用公共授权规则。Source 处理进度继续有效，不重新抽取已处理的 Source。迁移前可恢复与不可直接恢复的条目保持各自语义，不能用当前正文猜测补齐缺失的历史版本。

业务中仍有效的精确 entry 引用转换为新的 Atomic ArtifactRef，按指定正文版本读取，不跟随当前 head。旧随机版本 ID 不提供在线别名；客户端须改用迁移后的制品身份和版本，不能继续提交旧 MemoryCitation。

旧集合正文、快照和必要元数据退出在线制品体系，转入新增的专用归档表，用于离线保管和核验原始数据，不承担接口兼容。整集合依据先在归档中保留引用来处及其与原集合的关联，再从在线 lineage 删除；不展开为成员或 Source，也不解释为某一条 Atomic。这明确放弃旧集合的在线读取和追溯，精确 entry 依据仍按上述规则转换。归档不参与查询、检索或生成，也不能替代升级备份；回滚和归档保留、清理条件遵守 RFC #1771。

若移除整集合依据使 Handoff、Work 或 Candidate 不再满足非空证据约束，预检阻断迁移，除非维护者的决策文件覆盖全部此类记录。决策只能用明确的精确 ArtifactRef 替换该引用、把已验证的 Work 条目降为 declared，或拒绝待审核的 Candidate；原值写入归档。不新增历史业务条目变体来绕过约束。

server 仅保留 memory.get/list/search/remember/flush 五个旧入口的适配，记忆结果使用 Atomic 身份和版本：

get 可用旧集合 ID 和 entry ID 定位对应 Atomic 的当前 head；精确历史读取改用新的 ArtifactRef。
list 和 search 查询 Scope 中的 Atomic Memory，采用新模型的列表、状态和检索语义。
remember 仅适配简单新增，不保留旧条目更新、集合追加版本或旧对象依据。
flush 使用保留的 Source 处理进度，继续向 Atomic Memory 抽取。

其他旧入口明确停止支持，包括通用 family=memory 操作、旧标签目标及其 ETag、旧 access selector、集合 CAS 和旧游标；不能通过忽略并发前提或过滤条件接受这些请求。客户端改用 Atomic 与通用 Artifact 的读取、写入、标签和授权接口，并按新契约重新查询和分页。鉴权与执行均指向同一 Atomic。

SDK 和 runtime 不保留旧 Memory 域模型、MemoryCitation 或其他旧 Memory 强类型引用。含旧结构的终态 Dream 在停服迁移时转换为显式无类型历史数据，只供展示，不参与证据解析、执行或恢复。历史回执在原有的 unavailable_evidence 中保留不可用的集合地址，只描述当时哪些证据不可用，不解析这些地址，也不接受它们作为新的依据；精确 entry citation 转换为 Atomic 引用。冻结的旧格式解码能力仅属于离线迁移工具，运行时不保留旧 decoder，也不依赖旧表或在线映射表。

保留入口的语义变化、停止支持的操作、替代调用及退出安排均按 RFC #1771 对外声明，不承诺旧客户端无需调整。旧接口兼容期和归档保留条件由对应发布声明；清理旧集合存储不授权删除已迁入 Atomic 的正文历史。

缺点

记忆身份与接口需要适配，完整历史迁移需要停服时间和额外空间。
每次合并都会增加一个 Artifact，并保留输入记忆和合并关系。撤销可能涉及多条记忆，需要整组处理权限与并发变化。
达到阈值的相关记忆可能很多，需要分批完成比较。阈值和模型判断仍可能遗漏关系或产生错误合并。
按时间自动处理冲突可能采纳有误的新内容，时间缺失时尤其依赖 Source 顺序；纠正通过后续演化、编辑或恢复完成。
撤销合并后，结果记忆上的后续修订退出正常检索；已经引用这些版本的其他制品不会自动回滚。
旧客户端需要调整引用和调用方式；五个旧服务入口仍需适配，旧集合在线读取和追溯不再提供。

设计理由与替代方案

每条记忆使用独立 Artifact。 Scope 负责组织，Artifact 负责单条记忆的版本、证据和状态，单条更新不再生成整个集合的目录版本。增量 manifest 或多个小集合可以缓解目录复制，但仍保留集合与 entry 两层身份。

使用 atomic-memory Family。 名称表达可独立维护的记忆粒度，适用于自动抽取和手工写入。继续使用 memory 会让旧集合与新单条记忆共用一种 Family 含义；新 Family 可以明确区分它们，并按操作提供旧接口兼容。

合并生成 C，冻结 A、B。 原地把 B 并入 A 后，纠正合并可能需要从不断更新的 A 中重新拆出 B 的内容。新建 C 保留了明确的合并前状态，后续编辑作用于 C，撤销则恢复输入记忆。直接将 A、B 不可逆退役，会失去恢复原身份的能力。

默认自动合并。 合并作为 Source 抽取的一部分，与普通新增、更新采用同样的自动执行方式。逐次审批或按类别预授权都会增加维护步骤。本提案通过保留历史、允许纠正和撤销处理错误，不要求用户逐次确认模型的合并判断。

冲突按时间自动处理。 原子记忆持续大量产生，把每次矛盾留给用户判断会积累维护工作。模型按时间更新当前记忆，历史与恢复能力承担纠错需要，不建立独立的待处理冲突流程。

先例

RFC 1345 和 1549 分别提供 Scope 组织方式和通用 Artifact 能力。
RFC 0019 定义 Source 消费与抽取进度。
RFC 1417 先生成候选，再选择相关 Topic，可供相关记忆检索参考。
RFC 1652 定义证据、有效性、冲突与生命周期规则，本提案调整 Atomic Memory 的合并审批及冲突保留要求。
RFC 1718 说明完整 manifest 的容量成本及历史保护要求。
RFC #1803 定义公共检索规范， RFC #1771 定义统一迁移流程。

未解决问题

用户通过 Agent 纠正记忆时，Source 是否需要保留被纠正记忆的引用及相关上下文？现有 Agent 集成和采集方式能否提供这些信息，哪些地方需要调整？
其他制品是否也采用这四种状态？现有 deprecated 状态如何对应“遗忘”和“被合并”？Atomic Memory 的行为在本提案中明确，其他制品是否统一及如何改造另行讨论。

本提案不包含 Atomic 正文历史的物理删除、跨 Scope 自动合并或整个 Scope 的快照回滚。具体表结构、接口参数、锁与事务实现放在实现方案中；迁移遵守 RFC #1771。

后续可能性

管理界面可以展示记忆版本与合并关系图，帮助用户查看原文、比较版本和选择恢复目标。更完整的历史展示不改变上述状态和恢复规则，也不作为基础预览与恢复能力的前置条件。

Atomic Memory 独立记忆制品

摘要

动机