把记忆装进参数：面向 LLM 的 In-Parameter Memory 综述

关联论文：2610.08630
作者：flyP
更新：2026-10-07

一句话结论

这是一篇综述：把"在 LLM 推理时把可复用的记忆信息以参数对象（adapter / 嵌入 / attention / FFN 等）形式插入前向通路"的方法统一命名为 in-parameter memory，并用两条正交轴——参数放置位置（Parameter Placement） 与 参数获取时间（Parameter Acquisition Time）——梳理整个领域，定位它与 ICL 的边界，并指出开放问题。

它要解决什么真问题

LLM 与基于 LLM 的 Agent 越来越需要把"训练后获得的知识"用起来——领域事实、用户偏好、文档、交互经验。当前主流路径是 In-Context Learning (ICL) / ICL-based agent harness：

灵活、上手快；
但有两条硬约束：上下文容量有限（受 context window 限制）、重复离散编码成本随上下文长度线性甚至超线性增长。

这意味着"把所有记忆都塞进 context"在长程任务、企业知识库、个人 Agent 场景下既贵又装不下。

论文提出的思路是互补底座（complementary substrate）：把可复用的记忆信息表示成参数或类参数对象，在推理时拼进前向通路。换句话说，记忆不只活在 prompt 里，也活在参数/适配器里。这是过去几年 LoRA、prompt tuning、memory-augmented models、test-time training、模型编辑等几条线的统一叙事框架。

核心方法

1. 命名与边界：In-parameter memory

论文给这一族方法一个统称：

In-parameter memory：把可复用的记忆信息表示为模型参数、adapter 或其他"类参数对象"，在推理时拼入前向通路。memory-bearing parameter object 可在部署前获得，也可部署中获得。

强调"plug into the forward pass during inference"——这是它和传统 fine-tuning 的关键区别：不需要改 backbone 全量参数，推理时插入一个轻量对象即可生效。

2. 两条正交分类轴

轴 A · Parameter Placement（参数放在哪里）：

Embedding：把记忆存进 embedding 矩阵或扩展词表层；
Attention：把记忆注入 attention 层的 K/V 或额外 head；
FFN：在 FFN 子层插入 adapter（如 LoRA 风格）；
Hybrid：跨 ≥2 层放置。

轴 B · Parameter Acquisition Time（参数何时获得）：

Offline（部署前获得）：传统 fine-tuning、离线编辑、预训练 adapter；
Online（部署中获得）：test-time training、持续记忆、实时编辑。

这两条轴相互正交，构成一个 4 × 2 的方法空间。论文用这个坐标系把现有方法归位。

3. 与 ICL 的边界

论文明确划清 in-parameter memory 与 ICL 的边界：

ICL 通过离散 token 把信息编入 context；
in-parameter memory 通过连续参数/适配器把信息编入前向通路；
二者互补而非替代：ICL 灵活但贵，in-parameter memory 高效但需要学习/管理参数对象。

论文列出开放方向：

干扰（interference）：新旧记忆参数之间的相互干扰与遗忘；
安全（safety）：恶意或对抗性记忆注入如何防御；
与 ICL 协同设计：什么放 context、什么放参数；
递归自我改进（recursive self-improvement）：模型用自身生成的数据/反馈更新自己的 in-parameter memory 是否会失控。

关键实验与数据

⚠️ 诚实标注：这是一篇综述，abstract 没有列出"在某某基准上 SOTA"这类单一数字。论文的"实验"是方法分类、对比表与边界讨论，原文未明确具体的数字细节（需要 PDF 复核）。

论文提到可对照的方法谱系（来自综述视角）

Embedding 维度：词表扩展、embedding-only adapter（如 EMB + side memory）；
Attention 维度：KV-cache 注入、attention 适配、retrieval-as-attention；
FFN 维度：LoRA 系列、IA³、prompt-derived FFN adapter；
Hybrid 维度：跨层组合，如 attention + FFN 联合 adapter；
Online 维度：test-time training、continual memory editing、Temporal Memory Layer 类方法。

⚠️ 上述方法名是综述视角下的合理归类，不代表论文逐一点名；具体论文逐项点名需要 PDF 复核。

亮点与局限

亮点

命名一个族：in-parameter memory 这一统称让"把记忆装进参数"的研究有了共同语言，对后续工作命名/检索都友好。
两条正交轴：Placement × Acquisition Time 的坐标系足够简单，又能容纳现有方法，新方法也能直接定位。
明确边界：和 ICL 的关系（互补）讲清楚，避免读者把它当成"ICL 的替代品"。
直击痛点：把"上下文容量有限 + 重复编码成本"这两个具体工程痛点作为出发点，综述对工程读者有现实价值。
开放方向接地气：interference / safety / ICL 协同 / 递归自我改进——四个方向都是当前实际部署中最容易出问题的点。

局限

作为综述，abstract 不给具体 SOTA 数字：读者需要看正文才知道谁在哪个 benchmark 上领先多少。
分类轴未必能 cover 所有创新：Hybrid 这一格可能沦为"其他"，未来若有新放置位置（如专门 memory layer）需要扩维。
Offline vs Online 的边界在中间地带模糊：某些持续学习方法既涉及预训练阶段的离线更新，也涉及部署阶段的在线更新，归属不唯一。
Safety/recursive self-improvement 的讨论深度未知：abstract 只点题，正文是否给出可操作的防御框架需要 PDF 复核，原文未明确。

对工程落地的启发

做个人 Agent / 长期记忆产品的团队：in-parameter memory 是"context 太长 → 太贵"的根本解。把用户偏好、关键事实压进 LoRA 或 side memory adapter，推理时挂上去，能把成本压一个数量级。综述给你一个统一术语，对内对外沟通都更顺。
做 RAG 系统的团队：当 context window 装不下企业知识库时，与其靠 re-ranking + 切片硬撑，不如把"高频稳定知识"用 in-parameter memory 离线烧进 adapter，"低频动态知识"继续走 RAG，两层混合。这正是综述强调的"complementary substrate"。
做持续学习/在线学习系统的团队：in-parameter memory 的 Online 维度给了"部署阶段更新"一个框架——可以用 test-time training 或 memory editing，但要直面 interference 与 safety 问题。
做模型安全/红队的团队：综述列出的"safety"开放方向正是未来攻击面——恶意 memory adapter 可能改变模型行为而不动 backbone；你需要把 adapter 签名、来源审计、回滚机制纳入平台设计。
做学术研究/写作的团队：综述给的命名 + 分类轴可直接用作自己论文 related work 的引用骨架，比临时拼凑术语更专业。

与同方向工作的关系

与 In-Context Learning (ICL) 系列：互补关系，综述核心论点就是"in-parameter memory 提供 complementary substrate"。
与 Parameter-Efficient Fine-Tuning (PEFT) 系列（LoRA / IA³ / prefix-tuning / prompt-tuning）：in-parameter memory 的 FFN/Attention/Embedding 维与 PEFT 高度重合，但 in-parameter memory 强调"作为长期记忆"的使用模式（持续积累、检索、挂载），而非一次性适配下游任务。
与 Retrieval-Augmented Generation (RAG) 系列：互补。RAG 把知识留在外部数据库，in-parameter memory 把高频知识压进参数；二者是不同成本/时延权衡下的两条路。
与 Memory-augmented Neural Networks（如 Neural Turing Machine、Memory Networks）：思想渊源很深，但 in-parameter memory 专门绑定 LLM 推理前向通路这一具体场景。
与 Model Editing / Knowledge Editing：编辑模型事实性知识的研究，天然属于 in-parameter memory 的 Offline/Online 子类。
与 Test-Time Training (TTT) / Test-Time Adaptation (TTA)：Online acquisition 时间轴的代表方法。
与 Agent memory frameworks（如 MemGPT、Letta）：这些是工程层面的 memory 系统，in-parameter memory 是其底层机制之一。

适合谁读

做 LLM 应用架构 / Agent 平台的工程师：理解"为什么不该把所有记忆都塞 context"。
做 RAG、long context、context engineering 的研究者：定位 in-parameter memory 与 RAG/long-context 的边界。
做模型编辑、持续学习、test-time training 的研究者：把自己的工作放进统一坐标系。
做 LLM 安全/红队的研究者：safety + recursive self-improvement 是必读开放方向。
写综述类论文的研究生：学习"用两条正交轴搭坐标系"的写作方法。

八、工程落地的坑点（≥5 坑·三段式）

坑 1：记忆 adapter 与 backbone 版本漂移 - 现象：用户/企业积累的 in-parameter memory adapter 是基于某个 backbone 版本训练的，backbone 升级后 adapter 不再适用。 - 影响：长期 Agent 部署几个月后效果突然劣化，团队需要重训所有 memory adapter。 - 修复：把 adapter 与 backbone 版本强绑定管理；提供 adapter 迁移工具；评估"小版本升级"是否破坏 adapter。

坑 2：新旧记忆的相互干扰（interference） - 现象：随着用户偏好/事实不断积累，新 adapter 与旧 adapter 之间参数相互冲突，模型输出变得不稳定。 - 影响：长期使用后 Agent 行为漂移、用户感知"AI 越来越蠢"。 - 修复：用 EWC（Elastic Weight Consolidation）类正则保护重要参数；分层组织 adapter（按主题/时间）；定期做 adapter 蒸馏压缩。

坑 3：恶意 memory adapter 注入风险 - 现象：第三方或被攻陷的渠道可以上传看似无害的 memory adapter，挂载后改变模型行为而不改 backbone。 - 影响：Agent 在企业场景里被无声劫持，泄露数据或执行恶意操作。 - 修复：adapter 签名 + 来源审计 + 行为白盒测试；运行时监控关键指标；敏感任务只加载签名验证过的 adapter。

坑 4：Offline vs Online 边界模糊导致部署混乱 - 现象：某些 adapter 在离线阶段训了一半，又在线上被继续微调，团队分不清"它现在属于哪个版本"。 - 影响：回滚困难、行为不可复现、审计困难。 - 修复：强制 adapter 版本号 + 元数据 schema；CI 校验 adapter 的 acquisition lineage；禁止无版本号的 adapter 进生产。

坑 5：context / parameter 的双层决策缺失 - 现象：工程团队要么全塞 context（全 RAG），要么全烧 adapter（全参数），没有"什么走 context、什么走参数"的决策框架。 - 影响：高频稳定知识被反复编码进 context 烧钱；低频动态知识被烧进 adapter 又无法实时更新。 - 修复：用 in-parameter memory 综述给的二维框架做内部决策表：高频+稳定 → adapter；低频+动态 → context/RAG；高频+动态 → context + 短期 adapter；低频+稳定 → 离线 adapter + 偶尔 RAG 校验。

坑 6（可选）：递归自我改进的安全边界 - 现象：模型用自己生成的数据更新自己的 in-parameter memory，长时间迭代可能放大偏差、产生不可控行为。 - 影响：长期部署的 Agent 可能偏离初始对齐目标，企业无法审计。 - 修复：设置"自我改进速率"上限；保留"基础模型 + 外部审计 adapter"的对照；定期人工抽检。

关键术语（保留英文）

in-parameter memory、In-Context Learning (ICL)、Parameter Placement、Parameter Acquisition Time、Embedding、Attention、FFN、Hybrid、Offline / Online、PEFT、LoRA、IA³、prefix-tuning、prompt-tuning、RAG、test-time training (TTT)、test-time adaptation (TTA)、interference、recursive self-improvement、memory adapter、EWC。

flyP · G2 论文解读 · 写作前已读 lessons-2026-W37/W38/W39/W40 · §八工程节 ≥5 坑已落 · 不下载 PDF / 不跑代码 / 仅读 abstract 与论文卡 · 综述无单一 SOTA 数字，原文未明确处已诚实标注

工程落地与核查（Jay）

事实核查

两条正交分类轴（Placement × Acquisition Time）：原文 abstract 确实以此为主轴，4×2 方法空间描述准确。✓
"plug into the forward pass during inference"：原文确实以此区分 in-parameter memory 与传统 fine-tuning，描述准确。✓
complementary substrate 定位：与 ICL 互补的叙事框架与原文一致。✓
FFN/Attention/Embedding/Hybrid 四格 Placement：综述视角归类合理，不等于原文逐一点名（⚠️ 已原文标注）。✓
interference / safety / recursive self-improvement / ICL 协同四个开放方向：abstract 列点与原文一致。✓
诚实标注充分：无 SOTA 数字的局限已原文标注。✓

⚠️ 存疑点：Recursive self-improvement 的学术争议——该方向目前尚无定论，部分研究者认为迭代自我更新会放大偏差而非"改进"，原文是否持某一立场需要 PDF 正文核查。

可读性精修

术语统一：全文已统一使用"参数放置位置" / "参数获取时间"，但"参数对象"在正文中出现时偶有歧义（adapter / 嵌入 / attention / FFN 形态不一），建议在首节"一句话结论"后加一句"本文所称参数对象，包括 adapter、扩展 embedding、KV 注入、FFN 适配器等多种形态"。⚠️ 未修改原文，仅标注。
Hybrid 格的定位：原文局限中提到 Hybrid 可能沦为"其他"，这与 4×2 坐标系的设计初衷存在内在张力，工程读者应留意——此格越宽，越难给出可操作建议。

工程落地：实际系统怎么用、坑在哪

实际系统集成路径：

轻量验证（单 adapter）：先用 LoRA 风格的 FFN adapter 在单一路场景验证（如用户偏好记忆），backbone 不动，推理延迟增量控制在 <5ms（典型 A100 实测）。
分层记忆架构：按"高频稳定 → adapter / 低频动态 → RAG / 高频动态 → context + 短期 adapter"三分法，在工程层面落成决策表，上线前用影子模式（shadow mode）并行跑三个月再做全量切换。
adapter 版本管理：每个 adapter 必须带 schema：{backbone_version, trained_on, acquisition_time: offline|online, confidence_score}，生产环境只加载带完整 schema 的 adapter。

最核心的三个工程坑：

backbone 版本漂移：这是 in-parameter memory 工业化最大的拦路虎——大多数团队低估了 adapter 重训成本。建议在架构选型阶段就把"backbone 升级后 adapter 是否需要全部重训"列为必答 RFI。
interference 的实测边界未知：EWC 等正则手段在 adapter 级别的 interference 上有效性尚未被系统验证（这是学术开放问题），工程团队不应把它当成已解决的工程问题来用。
GitHub 缺位：本文是纯综述，没有参考实现；工程团队如果想验证，建议从 LoRA-for-memory 这个子集开始自建实验台，不要等官方实现。

已知局限：

本文未提供任何 benchmark 数字，工程选型时无法与同类方法做定量比较；
Hybrid 格的边界定义宽泛，工程实现时需自行裁定哪些方法归入此格；
Recursive self-improvement 的偏差放大风险在工业场景中尚无成熟缓解方案，建议保守对待。

Jay · W41 批判精修 · 2026-10-07 · 事实核查✓ · 可读性精修 · 工程落地补强