记忆怎样随时间变化
保留历史，识别变化，让当前回答与过去的经历各有依据。
个人记忆中的变化通常不意味着先前的信息写错了。一个人上个月在旧团队工作，这个月加入了新团队；曾经制定的计划，后来也可能被明确取消。系统既要保留当时发生了什么，也要在回答当前问题时使用正确的状态。把较早的内容全部删除会丢掉经历，把所有内容不加区分地交给模型又会造成冲突。
PersonOS 的组织机制保留原始证据和情节，再把关于同一事项的陈述关联起来。查询时能够沿着这些关系找回变化依据。完整框架进一步要求对有效期、记录时间和派生内容建立明确规则；这些要求需要具体实现分别验证。
发生时间与获知时间分别回答什么#
假设用户在 9 月 8 日说：“我从 9 月 1 日起调到新团队了。”9 月 1 日是这一状态开始成立的时间，9 月 8 日是系统获知它的时间。根据今天的材料回答“9 月 5 日在哪个团队”，可以说是新团队；追溯“系统在 9 月 5 日知道什么”，却不能使用尚未收到的消息。
这种区分称为双时间：有效时间（Valid Time）描述信息在现实中何时成立，记录时间（Recorded Time）描述系统何时知道它。历史导入、离线采集和事后纠正都会让这两个时间分离。消息的发送日期、录音的发生日期和文件的导入日期，也需要各自保留含义。
| 问题 | 需要的时间信息 | 常见误判 |
|---|---|---|
| 现在是什么状态？ | 陈述的适用时间、后续变化和当前有效性 | 最后导入的旧资料覆盖较新的现实状态 |
| 当时发生了什么？ | 事件发生时间与当时成立的条件 | 用今天的画像解释所有历史 |
| 当时系统依据什么回答？ | 截至当时已收到的证据与派生版本 | 用事后收到的材料证明当时已经知道 |
日期不明确时，应保留已有精度和不确定性。“去年秋天”不能为了填字段变成某个精确到秒的时间。相对表达可以结合消息日期解析，但要保留原话，方便在时区或来源日期有误时修正。
“双时间表达”与“双时间账本”的区别
有些抽取流程会同时在文本里保留“下个月”和解析出的绝对月份，便于检索。它解决的是相对时间可读性。完整的双时间账本还要保存现实有效区间、记录历史，以及按不同时间视角查询的能力。仅有 occurrence_time、recorded_at 或 updated_at 字段，不能直接证明已经具备这一整套能力。
先确认是不是同一件事#
把两条内容放在一起之前，需要判断它们是否描述同一主体的同一方面。摄影课程的上课时间、教室和收费都属于同一个话题，却是不同事项。时间改了，不能连带认为教室和价格都变了。领域标签能够帮助发现候选，具体关联还需要主体、对象和限定条件。
记忆链为同一事项保留连续陈述。链中的成员可以来自不同会话，保留各自情节和证据。链的先后顺序是一种组织线索；如果后写入的是补录的旧材料，就仍然需要读取其中的发生时间。一次关联也不等于已经裁决了哪条内容正确。
遇到主体不明、时间范围不一致或只是主题相似的材料，保留分开通常更容易纠正。错误合并会让后续检索携带不相关材料，进而影响回答；未关联的材料仍有机会由检索找回。关联应当可以追溯，而不依赖一段无法说明来源的总摘要。
变化、纠正和冲突如何区分#
“会议改到周六”是在修改安排；“刚才说错了，是周六”是在纠正表达；两份材料分别写周五和周六、却没有解释，则是待核对的冲突。它们需要不同的解释。明确更改关系可以更新当前视图，明确纠正关系可以限制错误陈述的使用，未解决的冲突应当保留双方和缺口。
框架设计用替代（supersession）和冲突（contradiction）等关系表达这些区别。现有的记忆链承担的是关联和补充上下文的职责，不能仅凭链存在就声称已经拥有完整的版本裁决系统。回答过程仍须检查原始语气、发生时间和证据是否确实指向同一件事。
以 9 月 20 日为查询时点。材料包括计划、取消和补录的旧对话。选择一个问题。
“下个月准备搬到杭州。”
计划“搬家取消了，还住在南京。”
取消计划 · 当前居住陈述补录一段 8 月的对话：“也许会考虑苏州。”
较晚录入 · 较早设想现在住在哪里？
9 月 10 日的消息直接说明了当前住址。9 月 20 日补录的内容发生更早，且只是设想，不能覆盖它。
“下个月准备搬到杭州。”
计划“搬家取消了，还住在南京。”
取消计划 · 当前居住陈述补录一段 8 月的对话：“也许会考虑苏州。”
较晚录入 · 较早设想9 月 3 日有什么搬家计划？
历史问题需要保留当时的计划，同时交代后续变化，避免让读者误以为计划仍然有效。
“下个月准备搬到杭州。”
计划“搬家取消了，还住在南京。”
取消计划 · 当前居住陈述补录一段 8 月的对话：“也许会考虑苏州。”
较晚录入 · 较早设想后来是否搬到过杭州？
计划与取消都不能证明搬家已经发生。回答应保留这个缺口，不能把计划地点写成居住经历。
任务和计划尤其需要保留状态语义。“希望参加”“已经报名”“已经完成”分别需要不同证据。截止日经过只说明时间到了；没有完成记录时，系统不能自行把任务标成完成，也不能因为久未提及就认定目标已经放弃。
画像与摘要怎样跟随变化#
画像把多段经历整理成便于使用的描述，例如当前角色、较稳定的沟通偏好和持续关注的事项。它有助于缩短后续任务需要读取的材料，但也会把许多判断压缩在一起。因此画像必须能够回到来源，说明哪些内容来自明确陈述，哪些是暂时归纳。
用户修正偏好后，仅修改原子记录还不够。如果画像仍然写着旧偏好，后续任务就可能继续受到影响。同样，一段派生摘要若引用了被撤销的证据，需要重算或标记失效。来源依赖、生成时间和版本信息让这种传播可以被检查。
派生内容有更新延迟时，读取方应知道它覆盖到哪里。在实际链路中，原始写入完成、情节生成完成、链叙述更新和画像整理完成，可能是不同阶段。一个进度标记不能替代对最终内容的读回核对。
离线巩固怎样减少重复，又保住证据#
随着经历累积，系统需要整理重复表达、关联跨会话内容、更新画像，并检查已经过时的状态。这些工作通常比当前对话允许的时间更长，可以在后台或空闲时处理。框架把这一类维护称为离线巩固，设计稿中也使用 Dream Cycle 这一名称。
巩固应当从已有证据出发。连续几次提到同一安排，可以合并展示或建立共同索引；但重复出现的模型摘要不能被当作多份独立证据，从而人为提高可信度。两个实体名字相似，也只能形成待核对的关联候选，不能直接合并身份。
完整的巩固设计将修改表示为可检查的操作：关联哪些对象、更新哪份派生视图、使哪个版本失效，以及依据是什么。高影响修改还需要相应审核。这样的过程可以保留历史并恢复错误修改；单次后台摘要调用并不自动具有这些能力。
检查一次巩固是否可靠
- 新摘要中的每个重要结论，能否定位到仍然有效的来源？
- 来源在任务执行期间发生变化时，是否会检测到版本过期？
- 删除或修正一条依据后，依赖它的视图是否会更新？
- 本次操作失败时，是否能区分没有执行、部分执行和结果未知？
本章区分当前的证据、情节和链组织机制与完整框架的时间、巩固契约。各实现的时间字段、画像更新和回滚范围需按版本核对；这里不将设计要求写成统一的现成功能。