让 AI 记住“现在”和“过去”：长期记忆里的演进建模
摘要
长期记忆最难的不是“记住”，而是“记住变化”。
一个规则以前是什么、现在是什么、为什么变成这样、哪些证据支撑当前版本，这些问题不是简单追加文本能解决的。如果 memory 不能表达演进，Agent 用久之后就会同时记住旧计划和新计划，却不知道哪个该用于当前决策。
InsightMemory 的目标是让 AI 的记忆从 append-only 文本池升级为 evolvable memory graph：当前态、历史态、更新关系、冲突关系和证据链可以共存，并且能在召回时被正确使用。
正文
长期记忆最容易被低估的能力，是处理变化。
很多系统能记住一句话，但记不住这句话后来怎么变了。更准确地说，它们可以把新信息追加进去，却很难判断：
- 新信息是在更新旧事实；
- 新信息是在补充旧事实；
- 新信息和旧事实冲突；
- 新旧信息应该同时保留；
- 用户问的是当前状态还是历史状态。
这就是为什么很多 Agent 用久之后会出现“记忆混乱”：它不是忘了，而是把所有版本都混在一起了。
一个真正可用的 memory layer，必须把时间和变化作为一等公民。否则系统越勤奋，积累的矛盾越多。
append-only 的问题
最简单的 memory 方案是 append-only：新信息来了就追加进去。
这当然比完全不记好，但它有一个致命问题：系统无法知道哪些内容还有效。
真实评测里有一个更小的 history/current case。系统先写入：
Atlas rollout 之前卡在数据库迁移失败。
后来又写入：
Atlas rollout 当前主阻塞是签名校验失败。
当用户问 Atlas rollout 当前主阻塞是什么？ 时，答案应该是 签名校验失败，不能把 数据库迁移失败 当成当前阻塞。当用户问 Atlas rollout 之前卡过什么问题？ 时，答案又应该回到历史记忆里的 数据库迁移失败。
这不是模型聪不聪明的问题，而是 memory model 有没有告诉它：一条是历史阻塞，一条是当前阻塞。
一个真实评测过的规则演进例子
在 rule_evolution_handbook_history_current_supplement 这个评测用例里，系统先后写入三条信息：
Ashgrove handbook 之前允许团队在 shift 后 24 小时内补录 fallback schedule。
Ashgrove handbook 当前要求所有 fallback schedule 变更必须先经 incident lead 审批。
Ashgrove handbook 最新补充：所有审批记录还必须附在 change packet 中。
如果用户问：
Ashgrove handbook 当前要求什么？
系统应该回答当前规则：需要 incident lead 审批，并且审批记录要附在 change packet 中。
如果用户问：
Ashgrove handbook 之前允许什么？
系统应该回答历史规则：之前允许 shift 后 24 小时内补录。
如果用户问：
为什么现在要附审批记录？
系统还应该能沿着补充关系或支持关系，找到相关 observation 和 requirement。
这两个答案都正确，但它们不能混成一个答案。
为什么 summary refresh 容易出问题
很多长期记忆方案会把历史内容压成一个 summary，然后不断刷新 summary。
这种方式简单，但有几个问题：
- 新内容可能覆盖旧细节；
- 历史状态可能被 current summary 吞掉；
- 系统很难解释规则为什么变化；
- 多次刷新后，summary 会越来越像模糊印象；
- 查询历史问题时，系统没有稳定的历史版本可用。
这不是 LLM 不够聪明，而是 memory model 没有表达演进。
summary 可以作为展示层，但不适合作为长期记忆的唯一真相层。真正的 memory 系统应该保存原始证据、当前状态、历史状态和变化关系，而不是把一切压成一段越来越模糊的摘要。
InsightMemory 的建模方式
InsightMemory 把原始输入和长期记忆分开：
observation是原始证据，append-only；memory是系统沉淀出的稳定事实、状态、规则或结论；edge表达 memory 之间的 update、support、conflict、derivation 等关系；version或历史记录用于追溯 memory 的变化。
这样做的目标不是保存更多文本，而是让系统知道变化是什么。
一条新输入进来时，系统需要判断它和已有 memory 的关系：
- 如果它替代旧状态，就形成 update；
- 如果它补充当前规则，就形成 additive refresh；
- 如果它和旧事实矛盾，就保留 conflict；
- 如果它只是另一个历史事实，就与当前 memory 并存。
换句话说，InsightMemory 不只是保存“说过什么”，而是试图保存“系统对世界状态的理解如何变化”。
current 和 historical 要分开召回
长期记忆系统不能只回答“有哪些相关信息”。它还需要理解用户问的是哪种时间语义。
当用户问“现在是什么”，系统应该优先找 current memory 和补充关系。
当用户问“之前是什么”，系统应该能回到 historical memory 或旧版本。
当用户问“为什么变成这样”，系统应该沿着 update、support 或 conflict edge 找到变化原因。
这就是 evolvable memory 和 append-only 文本池之间的区别。
一个长期运行的 Agent 至少要稳定处理三类查询：
- current：现在什么是有效状态；
- historical：过去曾经是什么状态；
- why changed：状态为什么发生变化。
这三类问题一旦混在一起，Agent 就会在决策上摇摆。
一个真实评测过的市场记忆案例
长期记忆的演进能力在投研、研究助手和市场分析里尤其明显。仓库里有一个真实评测用例：market_history_current_thesis。
评测写入：
Halcyon Battery 之前主风险是 wafer yield slip。
Halcyon Battery 当前主风险已经变成 channel inventory pressure。
评测查询有两个：
Halcyon Battery 当前主风险是什么？
Halcyon Battery 之前主风险是什么？
第一问必须回答 channel inventory pressure，并且不能把 wafer yield slip 当成当前风险。第二问必须回答 wafer yield slip。
这个 case 验证的是同一个主体下的 earlier/current 分离。它不是简单地把两条记录都召回，而是要求系统根据用户问题里的时间语义走不同 recall path。
在真实投研里，结论、风险和约束会不断变化。如果系统只维护一个 summary，旧风险很容易被覆盖；如果系统只追加文本，当前风险和历史风险又容易一起出现。这个评测用例虽然很小，但正好验证了长期记忆必须具备的基本能力：现在问现在，过去问过去。
对 Agent 的意义
Agent 真实运行时，状态会不断变化：
- 用户偏好可能更新；
- 项目 blocker 可能解除；
- 规则可能被补充；
- 计划可能被推翻；
- 外部系统状态可能改变。
如果系统只会追加文本，Agent 就会同时记住“旧计划”和“新计划”，但不知道哪个该用于当前决策。
如果系统能建模演进，Agent 才能在长期任务里保持稳定。
更进一步，演进建模会让 Agent 具备“经验复利”。它不仅知道当前怎么做，还能知道为什么曾经不这么做、后来哪里变了、哪些证据让系统更新了判断。
这就是长期记忆从工具能力升级为产品护城河的地方。
小结
长期记忆不是把旧内容压缩成一个 summary，也不是把所有新内容追加到向量库。
真正有用的长期记忆需要保存证据、区分主体、表达关系，并且能回答 current、historical 和 why changed 这三类问题。
InsightMemory 的核心目标之一，就是让 AI 记忆不只是“存得下”，而是“变得清”。
它的野心不是做一个聊天记录缓存，而是做一套 evolvable memory layer，让 AI 的记忆能更新、能保留历史、能解释变化、能追溯证据。
GitHub: https://github.com/MarvekW/InsightMemory
如果你正在构建需要长期运行的 Agent、企业 Copilot 或知识系统，欢迎试用 InsightMemory。项目仍需要更多真实场景、评测 case 和 LLM API-KEY 支持，来继续打磨长期演进能力。
