Zep 为每条记忆事实记录两条时间线，以处理被覆盖或迟到的上下文
美国公司 Zep 在官方博客说明其上下文图（Context Graph）为每条事实同时记录事件时间线与系统时间线：旧事实被新事实否定时不删除，而是补上结束时间，供智能体回答历史问题。
文中称所调研的 15 份内部数据智能体工程记录里有 10 份只按新旧程度判断上下文是否过时，均未记录业务事实的生效期间。 上述属公司自述，无第三方验证。
文章举例：2025 年 9 月的数据迁移改变了订单与账户的关联键，工程师一周后才在聊天中说明； 若智能体只信任最新上下文，会把新关联键套用到 2025 年第一季度的订单上，结果看似合理但错误。
Zep 的上下文图中每条事实是一条连接实体的边，带四个时间戳：valid_at（事实开始为真的事件时间）、invalid_at（事实停止为真的时间）、created_at（Zep 学到该事实的系统时间）、expired_at（Zep 得知事实失效的时间）。
新事实与旧事实矛盾时，若新事实生效更晚，旧事实获得 invalid_at（等于新事实 valid_at）和 expired_at（当前时间），并保留在图中，每条事实保留指向来源片段的链接。 写入片段需设置 reference_time（消息发送时间、会议开始时间或业务记录事件时间），未设置则使用摄取时间；
Zep 依据它解析“上周”等相对日期，回填历史数据应逐条设置，否则可能关闭较新事实而非较旧事实。 检索可按任一日期字段过滤； 判断事实在 T 时为真需 valid_at 不晚于 T 且 invalid_at 为空或晚于 T，文章称单次过滤无法同时完成空值检查与日期检查，需发两次搜索。
文中另列 15 份工程记录的做法统计，是该文对所述对象的计数，非行业抽样。
价值不在“记忆更多”，而在“记忆可追溯”：把事实有效期与系统获知时间分开，让智能体能分别回答“当时是什么”和“系统当时知道什么”。 对做跨会话记忆、会议助手或企业知识库的团队，这提示除去重与更新外还要保留版本与来源，否则一次迟到更正会污染历史查询。 “15 份记录中 10 份只查新旧”是 Zep 对自家文章所描述对象的计数，不能外推为市场比例。
后续观察信号
- Zep 所称 15 份工程记录中 10 份只查新旧的统计口径与样本来源是什么
- 双时间线在批量回填与实时写入混合场景下的查询性能如何