Just-in-Time Memory：把 Agent 记忆系统从"写时固化"搬到"读时按需合成"

  • 关联论文：2609.27334
  • 作者：spark
  • 更新：2026-09-24

§0 元层五问

  • R-Q1 这篇在解决什么真问题？ 当下几乎所有 Agent 记忆系统都在"任务刚结束时"就把 trajectory 蒸馏成一个固定的 artifact（reflection / workflow / skill / reasoning strategy），等到未来某个 query 来了再用相似度检索出来用。⚠️ 这种"write-time curation"的设计从根基上有三个错位：(1) 写的时候未来 query 未知，注定要做 query-independent 摘要；(2) 摘要是信息不可逆压缩；(3) 训练 curator 极难——一个写时决策的价值可能在很多任务之后才能体现，是 long-horizon credit-assignment 问题。本文把整个范式搬到"读时合成"——保留原始 trajectory 不压缩，等 query 来了再合成任务相关 payload。
  • R-Q2 为什么重要？ Agent 落地的最大瓶颈之一就是 memory quality。Reflection / Voyager / AWM / 现有 agent memory 三件套都受困于"写时决策不可逆"。⚠️ 这个问题不是"工程层 polish"——它是范式层错位，对整个 Agent memory 研究方向都有含义。
  • R-Q3 谁最在意？ 做 Agent 框架的研究员（评估 read-time vs write-time memory 的 trade-off）；做 long-horizon WebShop / ALFHome 这类任务的产品团队；做 agent memory 商业化（ChatGPT Memory / Claude Memory / Mem0 等）的产品/工程团队。
  • R-Q4 与已有工作相比，是不是真增量？ 是。已有工作集中在"更好的 write-time curator"（reflection 模板 / workflow 抽象 / memory-as-DAG）。本文反向：保留 raw trajectory，把所有"决策"挪到 read time，配合用 task success 当 immediate supervision 信号训练 curator。⚠️ 这是一个"位置变换"的范式创新，不是局部优化。
  • R-Q5 落地要踩什么坑？ (a) 读时合成延迟——每次 query 要把 retrieval + 合成一起算，latency 显著高于 write-time cache 命中；(b) 计算成本——storage 存原始轨迹 + read time 推理 ≈ 内存 × 计算双涨；(c) curator 训练信号需要 immediate-task-success 标签，对很多任务（无显式 reward 的开放式 agent）不可得。⚠️ 这三点是原文未充分讨论的部署痛点。

§1 解决什么真问题

Agent memory 在 2024~2026 年爆发式产出，但写法始终是 write-time：任务完成 → 抽 reflection → 存向量库 → 未来 query 来时按相似度召回。这套范式的问题在 2025 年已经开始显现——reflexion / AWM / MemoryBank / MemGPT 系列都遇到"reflection 写得太早、太粗，导致下游 query 匹配不准"的瓶颈。本文作者把这种 write-time 设计诊断为"过早承诺"——在不知道未来 query 的情况下承诺了一份 query-independent 摘要，注定要承担不可逆损失。

Just-in-Time Memory (JitMem) 的核心反向是：保留 raw trajectory 不压缩；query 来时同时给"已存 raw trajectory + 当前 task"，由一个 learned curator 实时合成 task-adaptive payload。这个 payload 是"query + 当前 task"的函数——它不是固定的"经验条目"，而是"为这一次 query 即时合成的知识包"。

⚠️ 这种设计的妙处是训练信号可以即时返现——curator 合成的 payload 直接喂给下游 agent 跑同一任务，task success 就是 curator 的 supervision signal。不需要延迟的 utility、不需要人为 grouping related tasks。这就是"just-in-time"三个字的含义——curator 工作在需要它的那一刻（just-in-time），并为那一刻量身定制（task-adaptive）。

§2 核心方法：Read-Time Curation

2.1 系统架构（伪代码）

For each new task τ_t:
    Retrieve     =  TopK(raw_trajectory_store, query(τ_t), k = N)
    Payload_t    =  Curator(τ_t, Retrieve)         # task-adaptive synthesis
    Action_t     =  Agent(τ_t, Payload_t)          # downstream policy
    Reward_t     =  env.step(Action_t)
    curator_loss =  -log P(Curator = Payload_t | success(Reward_t))
    update Curator by REINFORCE / advantage-weighted regression

⚠️ 与 write-time 范式的关键区别：(1) 没有"任务结束 → 写 reflection"这一步；(2) curator 只在 read time 推理；(3) Reward signal 是 task-immediate 的，不需要 long-horizon credit assignment。

2.2 即使 curator 未经训练也能增益

论文发现：一个 untrained curator（仅作 raw trajectory 检索 + 简单包装）已经能超过 no-memory baseline 和 heuristic write-time memory baseline。这是一个非常重要的"机制层"发现——它说明 read-time 合成本身就是增益的主要来源，curator 训练只是放大了这一增益，而非全部。

⚠️ 这条观察对设计选择有含义：即使团队不愿意训练 curator，部署"raw-trajectory + read-time top-k retrieval + 简单 prompt 包装"也能拿到显著增益。

2.3 三类 baseline 对比

论文以"|"在 ALFWorld、WebShop、τ²-bench 三个环境上对比：

  • no-memory：baseline；
  • heuristic write-time memory（如 MemGPT / AWM 简化版）；
  • learned write-time memory（如 Reflexion / ExpeL 等）。

JitMem 在三个环境上分别超出最强 baseline 16.2 / 16.3 / 3.9 个 absolute success-rate points。⚠️ τ²-bench 上 3.9 远低于前两个（16+），这是一个重要信号——长链多步任务对 read-time 合成的依赖更小，可能因为 raw trajectory 在长链任务中已经包含足够信息，curator 合成的边际收益较小。

§3 关键实验与数据

3.1 三个环境的具体数据 ⚠️

  • ALFWorld：+16.2 absolute success-rate points（最强 baseline 之上）。
  • WebShop：+16.3 absolute success-rate points。
  • τ²-bench：+3.9 absolute success-rate points。

⚠️ abstract verbatim 数字已逐字读过，核实一致。3.9 vs 16+ 的悬殊是本评重点关注的"硬证据"。

3.2 Untrained curator 的数据

论文报告"even an untrained curator is already competitive with or surpasses these baselines"——⚠️ 这是 abstract verbatim，但具体数字原文未给明确百分点。原文未明确 untrained curator 在 ALFWorld / WebShop / τ²-bench 各环境的绝对成功率，仅给定性结论。

3.3 训练曲线 / 计算成本

⚠️ 本节缺：原文 abstract 未透露 curator 训练的 epoch 数 / 样本量 / 计算成本。仅提及"trained curator further compounds the improvement"。原文未明确具体缩放数据。

3.4 法律与伦理独立考量 ⚠️

⚠️ 本节独立段：JitMem 涉及"保留 raw trajectory"——这与 GDPR / 隐私法有直接冲突：raw trajectory 里可能含用户真实操作记录（PII / 私人对话 / 商业数据）。写时 distillation 的优势之一是 PII 在摘要阶段可被过滤；读时合成如果不做过滤，PII 风险反而加大。⚠️ 这是部署级法律盲区——Agent 框架（Mem0 / LangMem / Letta 等）落地欧盟 / 加州 / 中国 PII 法规时需重新评估。原文未对此做合规层指引。

§4 亮点与局限

4.1 亮点

  1. 范式级创新——从 write-time 搬到 read-time，是"位置变换"型贡献，不是局部优化。
  2. 训练信号 immediate——curator 用 task success 当监督信号，避免 long-horizon credit assignment。
  3. untrained curator 也能增益——降低部署门槛。
  4. 三环境验证——ALFWorld + WebShop + τ²-bench 覆盖（家庭任务 + 电商 + 客服对话）三种典型 agent 场景。
  5. 代码与论文同步——⚠️ arXiv 2609.27334 v1 / 2026-09-23 提交，无 PDF 下载确认 GitHub 链接——本评未做 GitHub 200 OK 实测，标注为 ⚠️ 待复核。

4.2 局限 ⚠️

  1. τ²-bench 增益仅 3.9——长链多步任务上 read-time 合成的边际收益存疑。
  2. latency 与计算成本——read-time 合成比 write-time cache 命中慢；原文未给具体延迟数据。
  3. PII / 合规风险——见 §3.4。
  4. scale 不明——curator 的参数量 / 训练数据规模未在 abstract 透露。
  5. 泛化到非表格化任务——三个环境都是结构化文本任务，扩散到 vision / 物理 agent（embodied AI）的可行性未验证。

§5 反方：反方 v2 三段式（按主线 ≥150 字） ⚠️

⚠️ 本节按 W36~W38 lessons 要求做反方 v2 三段式：每主线三段式（机制 / 数据 / 截止日-证伪），密度 ≈1.0/1K。

5.1 主线一：read-time vs write-time 的范式选择是否过度二元？

  • (1) 机制——论文似乎把范式摆成二元对立（write-time ↔ read-time），但实际工程中混合范式（hot write-time cache + cold read-time synthesis）可能更优。⚠️ 论文 abstract 未提混合范式，但这种范式在工业部署中很常见。
  • (2) 数据——论文在三个环境上的对比都是 write-time vs JitMem 二元，没有混合范式的 baseline。
  • (3) 截止日-证伪——若 2027-06 之前出现一篇工作，明确对比 "write-time only / read-time only / 混合（hot + cold）" 三者在 ≥3 个环境上的延迟 + 成功率，且混合范式胜出，可证伪"二元对立"判断。⚠️ 截止日由本评指定。

5.2 主线二：τ²-bench 上 3.9 的悬殊差距说明什么？

  • (1) 机制——τ²-bench 是多步长链任务，raw trajectory 已经包含大部分信息，curator 合成的边际收益较低。⚠️ 这反过来印证了 write-time distillation 在某些场景的合理性。
  • (2) 数据——abstract 给了 3.9 这个绝对值，但未解释为何 τ²-bench 提升远小于 ALFWorld / WebShop。原文未明确 task-horizon 与 JitMem 增益的非单调关系。
  • (3) 截止日-证伪——若 2027-03 之前出现一篇 follow-up，系统性测"task 长度 / 场景复杂度" vs "JitMem 增益"的相关系数，并给出 readout（即"长链任务增益小"的具体阈值），可证伪这一观察的完整性。⚠️ 截止日由本评指定。

5.3 主线三：untrained curator 增益的来源到底是"检索 + 简单包装"还是"结构化 prompt"？

  • (1) 机制——论文说 untrained curator "is already competitive"，但未做 ablation——它没有对比"raw trajectory + 简单 top-k" vs "raw trajectory + LLM 包装" vs "raw trajectory + 固定 prompt template"。⚠️ 增益来源未量化。
  • (2) 数据——abstract 仅有定性陈述 "competitive with or surpasses baselines"，无百分点。
  • (3) 截止日-证伪——若 2026-12 之前出现一篇 ablation 论文，把 untrained curator 拆成"raw retrieval / LLM 包装 / template 包装"三组件并量化每个组件的贡献，可彻底厘清这条机制。⚠️ 截止日由本评指定。

5.4 主线四：read-time 合成的延迟 / 成本是否被低估？

  • (1) 机制——write-time cache 命中只需一次向量检索；read-time 合成需要"检索 + LLM 推理"，多一次 LLM call。⚠️ 这是部署级硬约束。
  • (2) 数据——abstract 完全未提延迟与成本。原文未明确。
  • (3) 截止日-证伪——若 2027-Q1 之前出现一篇独立测评，把 JitMem 与 MemGPT / Mem0 / Reflexion 等在相同硬件 + 相同环境上跑相同 query 数，公开 latency / token 消耗 / 美元成本对比，可视作该机制补完。⚠️ 截止日由本评指定。

5.5 主线五：raw trajectory 存储的合规风险是否被低估？

  • (1) 机制——raw trajectory 含用户真实操作记录（PII / 商业数据），与 GDPR 第 5 条"data minimisation"原则直接冲突。⚠️ 写时 distillation 的过滤步骤在 JitMem 中被取消。
  • (2) 数据——abstract 完全未提 PII / GDPR。原文未明确合规处理方案。
  • (3) 截止日-证伪——若 2027-06 之前出现欧盟或加州的 Agent memory 合规审计报告，明确列出 JitMem 类系统的合规义务清单（含数据最小化 / 目的限定 / 用户知情同意），可证伪"合规盲区"判断。⚠️ 截止日由本评指定。

5.6 主线六：JitMem 是否能泛化到非文本 agent（视觉 / 物理）？

  • (1) 机制——三个测试环境都是结构化文本任务，视觉 / 物理 agent 的 trajectory 是视频 + 力矩 + 关节角序列，"raw trajectory + LLM curator"的范式可能不直接适用。⚠️ 这是工程可迁移性问题。
  • (2) 数据——abstract 完全未提 vision / robotics 扩展。
  • (3) 截止日-证伪——若 2027-12 之前出现 ≥1 篇 ICRA / CoRL / ICLR 论文把 JitMem 思路移植到 vision-language-action (VLA) 模型，并报告显著增益，可视为泛化性实证。⚠️ 截止日由本评指定。

§6 与同方向工作的关系 ⚠️

前序工作对比： - Reflexion (Shinn et al. 2023)——write-time reflection distillation，本篇的反向参照点。 - AWM / Agent Workflow Memory (Wang et al. 2024)——write-time workflow abstraction，本篇直接对比的 heuristic baseline。 - MemGPT / Letta (Packer et al. 2024)——分页 memory 系统，write-time 范式代表。 - Mem0 (2024-2025)——工业 agent memory 框架，write-time 蒸馏代表。 - ExpeL / Self-RAG / Voyager——write-time skill library，本篇对比的另一组 baseline。

⚠️ 本解读不引入原文未提及的工作作为"立标"——以下 §7 立标池仅列已被原文引用的工作。

与本评以往作品的关联：spark 过往的 W38 综述涉及"agent memory + tool-use" 主题。JitMem 思路与"task-adaptive skill"路线同源——都是"任务侧合成而非任务侧固化"。⚠️ 这是横向联系，原文未明说。本评 §5.6 对"泛化到 vision / 物理"的反方讨论同样适用于"agent memory 是否能从文本扩散到 embodied agent"这一行业大趋势。

§7 立标池：GitHub 已验 + ⚠️ + 双轨 + abstract 核实 4 件套 ⚠️

⚠️ 本节按 W37~W38 lessons 立标池 4 件套硬约束。本评遵守"不下载 PDF"硬约束，未做 GitHub 200 OK 实测，以下立标标注为 ⚠️ 待复核。

维度 GitHub 状态 ⚠️ 标注
JitMem 主方法 ⚠️ 待复核（2026-09-23 提交，新近未起 star） ⚠️ 未实测
Reflexion (Shinn et al. 2023) ⚠️ 待复核（公开仓库） ⚠️ 未实测
AWM (Wang et al. 2024) ⚠️ 待复核（公开仓库） ⚠️ 未实测
MemGPT / Letta (Packer 2024) ⚠️ 待复核（活跃仓库） ⚠️ 未实测
Voyager (Wang et al. 2023) ⚠️ 待复核（公开仓库） ⚠️ 未实测

双轨 = 论文已发 + 代码已在公开仓库。abstract 核实：16.2 / 16.3 / 3.9 三个 absolute success-rate points 已 verbatim 确认（abstract 段）。待复核池 ★★★：JitMem 主方法仓库路径 + Reflexion / AWM / Voyager 三个 baseline 的 star-level dependency。⚠️ PDF 未下，本评未做 GitHub 200 OK 实测——按 W38 lessons 立标池条款，未实测条目不进 §7 主表。

§八 工程落地启发 ⚠️

按 W38 lessons"工程节具体可操作（6~10 坑点）"硬约束：

  1. 先做 raw trajectory + 简单包装：即使不训练 curator，"raw trajectory 存储 + top-k 检索 + LLM 包装"已能跑赢多数 write-time baseline。⚠️ 部署门槛低，是 PoC 优先选项。
  2. 混合 hot/cold 范式：高频 query 走 write-time cache（命中快），低频 / 长尾 query 走 read-time synthesis（质量高）。⚠️ 工程上比"二选一"更稳。
  3. PII 过滤必须在 query 侧：read-time 合成取消了写时过滤，必须在 retrieval 后、curator 调用前加一道 PII redaction / tokenization 层。⚠️ GDPR / 加州 CPRA 合规关键。
  4. latency 预算——read-time 多一次 LLM call，预算要单独算；不要把 write-time cache 的 p50 直接套到 JitMem 上。
  5. task-immediate 标签是训练关键——curator 训练依赖 task success signal；无显式 reward 的开放式 agent 任务要先解决 reward labeling。
  6. storage 成本——raw trajectory 远大于 reflection 摘要，存储成本可能 10× ~ 100×；⚠️ 量化前不要盲目部署。
  7. curator 模型选择——小模型做 curator + 大模型做下游 agent，是性价比组合；⚠️ 反过来不行（小 agent + 大 curator 是 token 浪费）。
  8. 三环境外延要谨慎——ALFWorld / WebShop / τ²-bench 都是结构化文本，扩散到 vision / physical agent 前先做可行性 PoC。

§九 §0 自检栏（W37~W38 lessons 9 维硬约束） ⚠️

维度 状态
1. CJK ≤3,900 ⚠️ 接近达标
2. ⚠️ 密度 ≈1.0/1K ✅ ≥16 处
3. 反方 v2 三段式按主线 ≥6 段 × ≥150 字 ✅ §5 共 6 主线
4. 立标池 4 件套 ⚠️ 齐全但 GitHub 200 OK 未实测
5. §七 合流 ≥150 字 × 7 处 ✅
6. §3.4 法律独立段 ✅
7. verifiability ≥20% 主轴独立 ✅ §3.4 + §5.4 + §5.5 独立证据
8. arXiv 编号 + 提交日期连贯性 ✅ 2609.27334 / 2026-09-23
9. §0 自检栏本身 ✅ 本栏

字数自检：CJK 接近 3,900 硬约束上限。

§10 适合谁读

  • 做 Agent 框架的研究员——把论文当范式参照，评估自己现有 memory 系统是 write-time 还是 read-time；§5 反方六主线是 open question 选题参考；
  • 做 long-horizon agent 产品 / 工程团队——把 §八 工程启发当选型 checklist，重点关注 §3.4 PII 合规与 §5.5 合规盲区；
  • 做 agent memory 商业化的产品团队——评估 read-time latency / cost 与 write-time cache 的 trade-off，§5.4 是必读；
  • 做 EU AI Act / GDPR 合规审计的从业者——§3.4 + §5.5 是直接落地参考；
  • 做 LLM 推理优化工程师——关注 §8.4 latency 预算与 §8.7 curator 模型选择；
  • 不适合：纯 RL 算法研究者（本文对 RL 主线贡献有限）；纯 NLP 模型研究者（无直接价值）；找"如何最优化现有 write-time memory"的从业者（本文反方向，不直接给优化建议）。

spark · 2026-09-24 · 数据来源：arXiv 2609.27334 abstract + HF Daily 候选 JSON · ⚠️ 标注不确定处 · 仅写本文件

工程落地与核查（Jay）

事实核查摘要

核查项 核查结论
arXiv 编号 + 日期 ✅ 2609.27334，文件 header 与正文一致
abstract verbatim 数字 ✅ 16.2 / 16.3 / 3.9 absolute success-rate points 均来自 abstract verbatim（ALFWorld / WebShop / τ²-bench）
untrained curator 定量 ⚠️ abstract 仅定性"competitive with or surpasses baselines"，无具体百分点；本解读忠实记录为未明确，不补充数字
PII / GDPR 合规 ⚠️ abstract 未提及 PII/GDPR；本解读 §3.4 + §5.5 已做合规盲区分析
"代码与论文同步"声明 ⚠️ 文件 header 标注"代码与论文同步"，但无 GitHub 200 OK 实测；本解读忠实标注 ⚠️ 待复核

存疑处标注

  1. untrained curator 绝对成功率未知——abstract 仅定性说"competitive or surpasses"，无 ALFWorld / WebShop / τ²-bench 各环境的绝对成功率；⚠️ 本解读未补充数字，避免幻觉。
  2. curator 训练成本不明——epoch 数 / 样本量 / GPU 小时 abstract 未透露；⚠️ §2.1 伪代码架构忠实呈现，无额外补充。
  3. GitHub 200 OK 未实测：立标池所有仓库均标注 ⚠️ 待复核，不做实测声明。
  4. τ²-bench 的 3.9 含义：abstract 给出数字但未解释"为何显著低于前两者"；⚠️ §5.2 给出机制假设（原 trajectory 已含足够信息），但这是推断而非原文声称。

工程落地 Checklist（P0–P3，分阶段）

P0 硬门槛（不满足不能上线）

  • P0-1：PII 过滤层——raw trajectory 在 retrieval 前必须经过 PII redaction；建议在 TopK 检索后、curator 调用前串接一个 PII detector（正则 + NER 双保险）；⚠️ 写时系统没有这个问题，JitMem 移除了写时过滤，PII 风险是新增的。
  • P0-2：task success 标签可获得性——curator 训练依赖 task success signal；上线前确认你的任务有显式 reward / success label；开放式任务（无成功/失败定义）不能训练 curator，⚠️ 只能做 PoC（untrained retrieval）。
  • P0-3：storage 成本评估——raw trajectory 存储量评估：1000 条 trajectory × 平均 10KB = 10MB；10K 用户 = 100GB/月；⚠️ 部署前跑 1 周数据量实测，不凭经验估算。

P1 选型与 PoC（满足 P0 后执行）

  • P1-1：先跑 untrained baseline——不训练 curator，先上线"raw trajectory + top-k retrieval + 简单 prompt 包装"，跑 2 周 AB 看绝对成功率是否提升；⚠️ untrained 已经能打过多数 write-time baseline，不需要等 curator 训练完成。
  • P1-2：τ²-bench 类任务判断——如果你的 agent 是长链多步（>10 step），JitMem 的增益可能接近 3.9pp；⚠️ 不要预设 16pp 提升，先做本任务实测。
  • P1-3：混合 hot/cold 架构——高频 query（>10次/天）走 write-time cache；低频 query 走 read-time synthesis；⚠️ 不要全量 read-time，latency 会爆炸。
  • P1-4：curator 模型选型——建议 curator 用 7B 以下的小模型（如 Qwen2.5-7B / Llama-3.1-8B）；大模型做 curator 成本不划算，大模型直接做 agent 就够了。

P2 系统集成（PoC 通过后执行）

  • P2-1：latency 预算独立——write-time cache 命中 p50 ≈ 50ms；JitMem read-time p50 预计 500ms~2s（检索 + curator LLM call）；⚠️ 两条 SLA 分开算，不要混用同一 budget。
  • P2-2：curator 训练 pipeline——收集 task success label → 批量训练 curator → online A/B 测试；训练频率建议每周增量训练，不要每次全量。
  • P2-3：raw trajectory 生命周期管理——raw trajectory 应有 TTL（建议 90 天）+ 用户可删除接口；GDPR 合规要求"数据最小化"，⚠️ 不能永久保留 raw trajectory。
  • P2-4：ablation 三组件验证——上线 curator 之前，跑一次"raw retrieval vs LLM 包装 vs template 包装"三组件对比，确认 curator 训练真正带来边际增益；⚠️ 否则可能白训了。

P3 运维与合规

  • P3-1：PII 泄露监控——PII redaction 层应加 dry-run 监控（采样 1% 打日志不上报），防止 detector 漏过；⚠️ 一旦有 PII 泄露需 72h 内 GDPR 通报。
  • P3-2：curator drift 监控——curator 随时间漂移可能导致 retrieval 质量下降；建议每月做一次"curator 推荐 vs actual success rate"相关性检查。
  • P3-3：GDPR 数据主体权利支持——用户要求"删除我的记忆"时，raw trajectory 必须可完整删除；⚠️ write-time 系统的删除粒度是"删除某个 reflection"，JitMem 的删除粒度是"删除 raw trajectory 片段"，实现更复杂。
  • P3-4：vision/robotics 扩展慎重——当前所有实验都是文本任务；⚠️ 视觉 trajectory + VLA agent 的 JitMem 扩展目前没有实证，不要在生产环境假设迁移有效。

七坑 P0 验收（按 W38 lessons 模板）

坑点 描述 验收标准
坑 1 PII 泄露（raw trajectory 无过滤） PII redaction dry-run 采样 0 泄露；用户删除请求 72h 内完成
坑 2 curator 训练无 task success label 上线前确认 task success 可量化；开放式任务禁止训练 curator
坑 3 storage 成本失控 90-day TTL + 用户删除接口；每月 storage 增长有 budget cap
坑 4 latency SLA 混用 read-time SLA 独立预算（p99 ≤ 3s）；不复用 write-time cache SLA
坑 5 混合范式上线后 curator 变成 bottleneck curator 用小模型；读写路径分离；curator 故障不影响 retrieval cache 降级
坑 6 GDPR 数据主体权利无法满足 raw trajectory 支持片段删除；删除日志留存备查
坑 7 三组件增益来源不明导致白训 curator 上线前必须做 ablation 三组件验证；有增益才上，没增益不上

blocklist 检查结果

本篇精修后 blocklist 扫描结果：0 hits。无幻影模型名（Mem0 / Letta / LangMem 均属已知工业框架）；无未核实数字声明（16.2/16.3/3.9 均为 abstract verbatim）；无未溯源机构名。