把日期解析错一次，究竟该记住什么

03/04/2026 是三月四日，还是四月三日？单看字符串没法决定。假设一次导入先按月/日解析，后来查了数据字典，才知道这份文件用的是日/月。修好后给 Agent 留一句“下次按日/月解析”，看着像完成了反思，碰到美国来源的新文件又会出错。

这是我读 From Storage to Experience 时自拟的例子。它让我觉得，保存失败经历之前，最好先想清楚下次怎么用。

记录先写窄，别让一次修复变成默认

连同原始输入一起保存当然有用。但一大段报错和修复记录被再次检索到时，模型还得重新判断哪些是当时的猜测、哪些已经证实。

我会先把这次记录写得很窄：

文件 A 的日期字段采用日/月/年。
依据：该文件附带的数据字典。
原解析器按月/日读取，导致 03/04/2026 被读成三月四日。
修复只适用于文件 A 及使用同一字段规范的文件。

这样至少不会把“文件 A 的格式”悄悄变成所有日期的默认格式。记录长了一点，我觉得值，尤其最后一句。下次遇到文件 B，先找它自己的字段规范，不必继承 A 的结论。

写窄还有一个更硬的理由：写进记忆的东西会被照着做。MemoryGraft 演示过往智能体长期记忆里植入“看起来很成功的经验”，利用的就是模型照抄检索到的成功任务的倾向，结果是跨会话的持续行为漂移。那是恶意攻击，可一条没写清适用范围的好心修复，走的是同一条路。

工程上还有另一种解法。Mem0 的文档要求检索时始终用 user_id、agent_id、run_id 这类过滤器限定范围，也就是缩小“谁能检索到这条”，而不是在这条里写条件。两种可以叠着用。顺带一提，Mem0 默认存的是改写过的陈述，想像我这样连原始输入一起存，要显式传 infer=False。

能迁移的是步骤，结论带不走

论文用 Storage、Reflection 和 Experience 讨论记忆从保存到加工的不同程度。我看的是 2026 年 1 月 8 日的 v1 预印本，主要做分类与定性讨论。

这篇后来正式发表在 Findings of ACL 2026，arXiv 版是 5 月挂的。下面引到论文原文的地方，依据的是 arXiv v1。

按它的框架，原始导入轨迹放在 Storage；上面这条针对失败的修正已经过了 Reflection。想再抽成可迁移的 Experience，就得考虑其他文件，不能只把文件名删掉。

文件名只是这个结论成立的条件之一，另一个是字段规范。去掉文件名，“按日/月解析”这句话没变，碰到规范不同的文件照搬还是错。能带走的是前面那一步：先找字段规范，再决定怎么读。Experience 大概要从这类步骤里抽，修复结论本身带不走。

论文自己给的理由几乎是同一句话。§4.3 说 LLM 智能体有“跟随成功轨迹的明显倾向”，而没有经过抽象的修正轨迹，仍可能因为上下文的微小变化引出错误。“下次按日/月解析”就是这样一条没抽象过的修正轨迹。

条件是在哪一步丢的

读 §2.2 的定义，我大概找到了条件丢失的位置。Reflection 被描述成一个语义过滤器，把加工后的洞见写回记忆库，产出的单元“成为独立的记忆条目，与原轨迹的噪声分离”。分离掉的噪声里，很可能就有数据字典这种条件。

再往上一层，表 1 对比 Reflection 和 Experience 时，Experience 的检索依赖一栏写的是：作为策略先验用于未见场景，不需要轨迹级匹配。这是它的设计目标，风险也出在这里。不匹配轨迹，就不会有人回头问“这条规则当初是在哪种文件上得出的”。

论文的官方仓库在范式表里也写了局限：自我反思类“有强化偏见的风险”，显式经验“在复杂边界上不够精确”。日期格式恰好就是一条复杂边界。

依照论文分类自行绘制，非原论文图片。例子仅用于解释，依据：v1 预印本。

一条宁可留原值的检查顺序

再设想文件 B 确实用月/日，文件 C 里混了不同来源。几种情况并排看，我能写出一条稍通用的检查顺序：

1. 先查字段规范；
2. 没有规范，找能区分顺序的样本；
3. 仍有歧义，保留原值，等待确认；
4. 发现混合来源，不把一行的格式推广到整列。

这是说明用的规则，还没运行验证。它保留了暂时无法决定的情况，不承诺所有日期都能自动导入。

开头的例子里，按月/日解析不会当场报错，要等查了数据字典才发现读错。误读的代价来得这么晚，所以我宁愿让有歧义的列先留原值，等有了字段规范或可区分的样本再处理。

论文在讲动态环境时也有一句：过时的知识往往在没有明显迹象的情况下失效（§3.2）。读错的日期也是这样，不报错，只是安静地错下去。

第 1 步放在最前面，是因为这个例子里让修复成立的是外部材料，光靠反思做不到。Large Language Models Cannot Self-Correct Reasoning Yet（ICLR 2024）测过，没有外部反馈时模型很难纠正自己的推理，有时纠正完还更差。没有数据字典，“下次按日/月解析”这句反思从一开始就立不住。

原始轨迹先别删

我不急着删原始轨迹。哪天某份文件推翻了这条规则，还得知道它当初依据的是哪些样本。短规则好检索，原记录好追查，两份可以一起存。论文也没有要求所有系统按三个阶段依次升级，或用加工后的经验替掉全部日志。§2.2 的原话是三个阶段“不代表完全替代”。

产品侧已经有现成的对应。Claude 的服务端记忆库文档建议把记忆组织成许多小而专注的文件，每次改动都生成不可变的版本，留下审计轨迹，可以按时间点回滚。短规则加留痕，跟我想要的两份一起存差不多。客户端记忆工具的系统提示第一句是“做任何事之前先看记忆目录”，这对应检查顺序的第 1 步；但它没教你把条件写进记录，那一半还得自己来。

要验证这条规则，我会留一批没参与整理的文件，里面既有明确规范，也有歧义和混合格式。文件 A 已经修好，再跑它只能查修复有没有退步；要看经验能不能复用，得让 B、C 这样的新情况进来。

公开基准在这一层才刚起步。论文附录 D 列的经验阶段基准只有 StreamBench、MemoryBench、Evo-Memory、LABench 四个，存储和反思阶段则有 LongMemEval、LoCoMo 等一长串。论文的局限一节也承认，经验阶段的抽象和泛化能力怎么评估，目前还是空白。我这条检查顺序还没验证，整个方向也都还缺这把尺子。

至于那个孤零零的 03/04/2026，能保留原值并说明缺什么材料，也是我愿意接受的结果。