Does Your Agent's Memory Survive a Model Upgrade？模型升级后 Agent 记忆还能用吗？

  • 关联论文：2609.05339
  • 作者：Tom
  • 更新：2026-09-07

一句话结论

Agent 升级底座模型后，记忆系统可能"静默失效"：用知识图谱固定 schema 的记忆迁移最稳（跨模型精度只差 ±0.0004），但压缩成自然语言笔记的记忆高度依赖原模型（换方向精度可差 13 个百分点），且 store-only 修复几乎不可能成功。

解决什么真问题

生产环境里，给 LLM Agent 升级底座模型是常态（更强的推理能力、新的安全政策、新的 token 上限……），但记忆系统的迁移被严重低估。

Agent 的记忆形式多样： - LC-RAW：完整历史原文整段存入 LLM context - RAG：切 chunk 存入向量数据库 - NOTES：用模型把历史压缩成自然语言笔记 - KG-fixed：用固定 schema 抽取成知识图谱三元组

直觉上"记忆内容没变，只是模型换了"，但实际存在三重风险： 1. 新模型对旧笔记的解释不同（压缩笔记高度模型耦合） 2. 向量嵌入版本不一致导致 RAG 检索退化 3. 修复时缺少原始证据（repair without original evidence）

核心问题：不同记忆表示形式的跨模型可迁移性如何？哪些值得保留原始历史？

核心方法

四种记忆系统对比

实验用 48 个合成历史（每条含随机答案代码），两种 <10B 参数的开源模型（具体模型名原文未明确）做两两迁移测试。

记忆表示形式：

  1. LC-RAW（Long-Context Raw）：历史原文完整存入，依赖 LLM 的长上下文能力直接读取
  2. RAG（Retrieval-Augmented Generation）：历史切 chunk，向量入库，query 检索
  3. NOTES（Natural-Language Notes）：用模型把历史压缩成自然语言摘要笔记
  4. KG-fixed（Knowledge Graph Fixed-Schema）：用固定 schema 抽取成知识图谱三元组

关键实验：跨模型迁移测试

测四种方向（每方向 48 个测试用例）： - Writer swap（换模型，但记忆内容不变） - Embedding migration（RAG 的 embedding 模型升级） - NOTES repair（NOTES 精度下降后尝试修复） - Source retention（保留原始历史对修复的帮助）

关键数据

① KG-fixed 最稳：

KG-fixed accuracy 只变化了 +0.0004 ± 0.0020（writer swap 后）

固定 schema 结构天然隔离了模型差异——schema 是结构约束，不是语义压缩。

② NOTES 最不稳（高度模型耦合）：

NOTES accuracy 在换方向上出现不对称偏移：+9.91 或 -13.28 个百分点，取决于迁移方向

压缩笔记高度依赖原模型的 tokenization、词汇空间和推理风格，换到新模型后语义对齐严重丢失。

③ RAG 部分迁移效益极低：

50/50 混合索引只捕获了 4.96 pp 的精度提升，而全量重新 embedding 带来 11.90 pp 提升

换句话说，混合迁移只拿到了全量收益的 41.7%，剩余 58.3% forfeit 掉了。

④ 消融分析： - NOTES 精度损失的 80%（0.467 ± 0.014） 来自初始构建时丢失的信息（不是推理时） - RAG 精度损失的 81%（0.364 ± 0.012） 来自检索失败（不是阅读理解）

这说明两个问题根源不同，需要不同的干预策略。

⑤ 修复实验（最悲观的结果）：

Store-only 修复（只保留压缩后的笔记）在 48 个测试用例中无一达到 90% 性能恢复线 保留原始历史（source history）的修复在其中一个方向上 34/48 达到目标

关键实验与数据

  1. 受控合成数据：48 个合成历史，消除真实世界数据的噪声，答案精确评分
  2. 双向迁移测试：不仅测 A→B，还测 B→A，发现方向不对称性（NOTES 的 +9.91/-13.28 pp）
  3. 消融归因：把精度损失拆解到信息丢失 vs 检索失败两个正交根因，为后续工程干预提供了精确坐标
  4. 修复实验：对比 store-only（不保留原始历史）和 source retention（保留原始历史）两种修复路径
  5. Under review：18 页，3 图，7 表，有 GitHub 链接但原文未给出（⚠️ 建议自行 fetch PDF 核验）

亮点与局限

亮点： - 问题被长期忽视：业界普遍关注模型升级，记忆迁移被视为"平移复制"而低估了风险 - 消融设计精妙：把精度损失拆到两个正交根因（信息压缩丢失 + 检索语义漂移），为后续工程干预提供了精确坐标 - 结论可操作：KG-fixed 思路直接可落工程，source retention 是几乎免费的保险措施 - 数据具体：有置信区间（±0.0020 等），非点估计，增强了可信度

局限： - 模型范围：仅测 <10B 参数的开源模型，大模型（GPT-5、Claude Opus 5 级别）是否符合相同规律未知 - 合成数据：48 个合成历史的泛化性存疑，真实用户交互历史的复杂度和噪声远高于实验设定 - 模型名称未披露：原文未明确说哪两个模型，只能假设实验设计合理，无法核实实验可重复性 - Under review：尚未经过同行评审，实验细节（如随机种子、评分标准）依赖作者描述 - 固定 schema 局限性：KG-fixed 依赖预定义的 schema，对开放式交互（聊天、探索性任务）可能不适用

对工程落地的启发

  1. 记忆系统选型：如果你的 Agent 需要频繁升级底座模型，优先选 KG-fixed 或 LC-RAW，避免 NOTES 方案——NOTES 的模型耦合度最高，升级风险最大
  2. 保留原始历史是底线：无论选哪种记忆方案，都要保留原始交互历史——它是修复的记忆锚点，没有它 repair 就是无根之木
  3. RAG 不要半吊子迁移：如果 embedding 模型升级，强烈建议做全量 re-embedding；50/50 混合索引只会让你同时承担两套索引的存储成本，却拿不到对应的检索质量提升
  4. 升级前做双向测试：新模型上线前，不仅要测新模型+旧记忆，还要测旧模型+新记忆（两个方向），因为 NOTES 的方向不对称性（+9.91 vs -13.28 pp）意味着单向测试会遗漏风险
  5. Schema 化是抗迁移的护城河：把用户偏好、关键事实固定成 schema 比压缩成自然语言笔记更稳健——这可能是 Personal Agent 记忆系统设计的长期正确方向

与同方向工作的关系

  • 与 Memory-Augmented LLM（Stanford HALM 等）：现有 memory 研究关注"如何存储"，本文关注"存储后如何迁移"——两个问题互补，构成完整的 memory 系统设计空间
  • 与 RAG 评估基准（RGB、ReComp 等）：RAG 基准主要测单次检索质量，本文揭示了 RAG 系统的跨时间/跨模型维度的隐藏退化，这是现有评测的盲区
  • 与个人 AI Agent（π-Bench 相关）：π-Bench 测 agent 的 proactivity 和长程任务完成，本文说明 proactivity 背后依赖的记忆系统在模型升级时可能悄悄崩塌——升级后 agent 表现下降可能是记忆迁移失败，而非模型能力问题
  • 与 Knowledge Graph for LLM（RAG-KG）：KG-fixed 路线本质上是用结构化知识换取迁移稳定性——这是 KG 在 LLM Agent 时代新的增长点

适合谁读

  • Agent 系统架构师：负责设计企业级 Agent 记忆系统，需要选型决策的直接依据
  • Infra/Platform 工程师：负责模型升级发布流程，需要评估升级对现有 Agent 服务的记忆兼容性影响
  • RAG 系统开发者：理解 RAG 在 embedding 模型升级时的非显而易见退化风险
  • 个人 AI 助理研究者：关心个人偏好记忆长期保持的用户（例如 OpenClaw 类的个人 AI 管家）

⚠️ 说明：本文 18 页 under review，实验用两种 sub-10B 开源模型（名称未在 abstract 披露，建议 fetch PDF §3 核实具体模型选择）。合成数据 48 条规模有限，泛化性待更多验证。

工程落地与核查（Jay）

存疑核查

核查项 状态 详情
实验模型名称 ⚠️ 未披露 abstract 只说"两种 <10B 开源模型"，具体名称未给；无法核实实验可重复性
GitHub 链接 ⚠️ 未在 abstract 给出 解读标注了"建议 fetch PDF 核验"；web_search 未找到对应仓库；需读 PDF §6
置信区间数值（±0.0020 等） ✅ 原文存在 数据附置信区间是亮点；解读引用准确
48 个合成历史的构造细节 ⚠️ 需读 PDF §3 随机答案代码是否与真实用户交互历史可比，需要核实
方向不对称性（+9.91/-13.28 pp） ✅ 原文存在 解读引用准确；两个方向分别代表哪个模型迁移需读 PDF 确认

实际系统怎么用

记忆系统选型决策树：

Q: 你的 Agent 需要频繁升级底座模型吗？
├── 否 → NOTES 可接受（不用管迁移）
└── 是 → 继续
    Q: 你的用户交互是结构化任务（代码生成/数据查询）吗？
    ├── 是 → KG-fixed 或 LC-RAW
    └── 否（开放聊天）→ 继续
        Q: 你的 schema 能覆盖多少用户意图？
        ├── 高覆盖（>70%）→ KG-fixed
        └── 低覆盖 → LC-RAW + 保留原始历史

KG-fixed 快速实现：

from dataclasses import dataclass
from typing import Optional

@dataclass
class UserPreferenceKG:
    """固定 schema 的用户偏好知识图谱——跨模型迁移最稳"""
    schema = {
        "preferred_language": str,      # "中文" / "英文"
        "timezone": str,               # "Asia/Shanghai"
        "code_style": str,             # "functional" / "oop"
        "verbose_level": str,          # "terse" / "detailed"
        "tools_used": list[str],       # 工具调用历史
        "key_facts": list[tuple],     # (subject, relation, object) 三元组
    }

    def extract(self, interaction: str, llm) -> "UserPreferenceKG":
        """用 LLM 把交互历史抽取成 schema 约束的结构化 KG"""
        prompt = (
            f"Extract user preferences from: {interaction}\n"
            f"Schema: {list(self.schema.keys())}\n"
            f"Output JSON:"
        )
        return parse_json(llm.generate(prompt), self.schema)

    def merge(self, other: "UserPreferenceKG") -> "UserPreferenceKG":
        """KG 支持合并，新值覆盖旧值（带时间戳则用新的）"""
        ...

迁移 checklist（模型升级前必跑）：

def pre_upgrade_audit(memory_system, old_model, new_model, test_queries):
    """在升级前做记忆系统兼容性审计"""
    results = {}

    # 1. 双向 NOTES 精度测试
    old_notes = memory_system.notes
    new_notes = memory_system.notes  # 同一份压缩笔记
    old_acc = evaluate(old_model, old_notes, test_queries)
    new_acc = evaluate(new_model, new_notes, test_queries)
    results["notes_asymmetry"] = new_acc - old_acc  # 预期: 0 ± 几个点

    # 2. KG-fixed 稳定性测试（预期: ±0.0004，几乎无变化）
    kg_acc_old = evaluate(old_model, memory_system.kg, test_queries)
    kg_acc_new = evaluate(new_model, memory_system.kg, test_queries)
    results["kg_stability"] = kg_acc_new - kg_acc_old

    # 3. RAG 全量 vs 增量 re-embedding 对比
    full_rebuild = rebuild_rag_index(memory_system.raw, new_model)
    incr_rebuild = partial_rag_update(memory_system.rag_index, new_model)
    results["rag_rebuild_benefit"] = full_rebuild - incr_rebuild

    # 4. 保留原始历史的价值
    has_source = memory_system.has_raw_history()
    if has_source:
        repaired = memory_system.repair_with_source(new_model)
        results["source_repair_success"] = repaired / len(test_queries)
    else:
        results["source_repair_success"] = None  # 无法 repair

    return results

坑点与失败模式

  1. NOTES 跨方向不对称性被忽视：A→B 迁移测通，不代表 B→A 也没问题。NOTES 的 +9.91 / -13.28 pp 不对称意味着"每次升级都要做双向测试"，单向通过不等于安全。对策：在 CI/CD pipeline 里强制加双向评测 gate，差值超过 5pp 就报警。

  2. LC-RAW 的长 context 成本：LC-RAW 依赖 LLM 的长上下文能力，每次读取都要把完整历史喂进 context，token 成本高。对策：分层记忆——KG 存核心偏好（低 token），LC-RAW 存原始历史（高 token，但按需检索）。

  3. RAG 混合索引的双重成本陷阱：同时维护两套 embedding（旧的+新的）看起来保险，但只拿到了 41.7% 的收益，同时承担 100% 的存储成本和查询延迟。对策：要么全量 re-embedding，要么别做半吊子迁移。

  4. 原始历史存储的合规性：保留完整交互历史可能涉及 GDPR 等隐私法规。对策：存储前做 PII 过滤；在 KG 抽取后删除原始文本；提供"历史清除"功能。

  5. KG schema 的维护成本：KG-fixed 需要预先定义 schema，但用户偏好会随时间演变，schema 需要定期更新。更新 schema 本身又是一次迁移事件。对策：schema 加版本号；不同版本 KG 之间做兼容合并，而非重建。

  6. 大模型（>10B）迁移规律未知：本文只测了 <10B 模型，GPT-5 / Claude Opus 5 级别的跨版本迁移是否遵循相同规律完全未知。对策：在生产环境上线新模型后，跑相同双向评测，把结果反馈到记忆系统选型决策。

快速验收标准

  • [ ] 模型升级前跑 pre_upgrade_audit()，记录 KG-fixed 差值（应 < 0.01）
  • [ ] 确认 NOTES 双向精度差值 < 5pp；若超过，说明 NOTES 方案不适合该 Agent
  • [ ] RAG 迁移：全量 re-embedding 收益明确 > 增量迁移，决策清晰
  • [ ] 检查原始历史保留策略：PII 过滤合规 + 可清除
  • [ ] fetch PDF §3 确认实验模型名称，补充到 §0 元层

Jay · 2026-09-07 13:32 UTC+8 · 批判精修版 · 仅追加工程节，不改动主体原文