外观
如何理解纠正、撤销与旧答案失效？
项目版本说明
这些问答整合历史设计与实现资料；当前 main 分支 README 以工作包描述建设状态。具体能力、实验数据与设计目标的边界见项目状态与证据。
标准回答
记忆发生变化时，要同时考虑原记录、基于它产生的结论、缓存答案，以及后续读取是否还允许使用。
先分清三种关系
| 关系 | 回答的问题 | 教学例子 |
|---|---|---|
| 来源追溯（Provenance） | 这句话来自哪里？ | “日志保留 30 天”来自一次已确认决定。 |
| 推导依赖（Dependency） | 这条结论建立在哪些记忆上？ | “30 天前的日志可清理”依赖保留期规则。 |
| 答案引用（Citation） | 这次回答用了哪些依据？ | “30 天”这个答案引用了规则记忆。 |
纠正：旧依据与新依据不是同一个版本
原记忆内容发生语义变化时，需要能区分修改前后。派生结果提交时携带它所依据的来源快照，Core 检查其中的版本等信息是否仍与当前来源匹配。
例：处理器拿到版本 1（30 天），运算期间用户改为版本 2（7 天）。处理器晚交的旧结论不能直接写成当前有效结论，需要按新投影重新处理。这就是防止“过时计算把旧事实写回来”。
读取现有派生内容和答案时也要检查依赖是否仍当前有效。仅在生成时校验一次，挡不住生成之后的变化。
撤销：先阻止使用，再处理清理
架构中的来源撤销使用短事务，把撤销标记（tombstone）、访问日志和 outbox 事件一起写下。受控召回立即排除被撤销来源影响的内容；隔离、重建索引与物理清理放到后台。
Outbox可以理解为“和业务变更一起保存的待处理通知”。如果只改状态、再临时发一条通知，程序在中间崩溃，后续工作可能丢失；把通知也写进同一事务，后台就能继续读取并处理。
纠正、撤销、删除的区别
| 操作 | 改变什么 | 关注点 |
|---|---|---|
| 纠正 | 事实内容或有效时间 | 旧结论是否还成立，历史如何保留。 |
| 撤销 | 来源或授权的可用性 | 是否继续在未来受控调用中泄漏。 |
| 删除 | 按策略移除内容 | 实体数据与审计锚点的保留规则。 |
缓存也必须检查依据
“命中缓存”只说明以前算过。返回前还需要确认支持它的记忆没有被撤销、替换或变得不再有效。依据不可用时，应停止返回旧答案；需要时用当前上下文重新生成。
一致性的边界
**立即：**安全撤销后的后续受控读取不能继续使用该来源。**最终完成：**语义重新处理和后台清理可以稍后完成。系统有时暂时缺少新的派生结果，也应避免返回已经无效的旧结果。
另外，无法保证外部 Agent 已取得的文字被自动抹去；跨系统撤回需要接收方配合。
自查：撤销以后数据库里还能看到记录，是不是撤销失败？
不一定。逻辑上停止可用与物理删除是两件事。撤销标记、依赖关系或不可恢复的审计锚点可能保留；关键是相关内容能否继续通过应受限制的路径被获取。
内容来源
- EachOf Wiki · 记忆与上下文 · 原条目
correction