LoRA 如果从微调产物变成运行时工具，Agent 的长期记忆可能从文本摘要转向可加载的增量权重。
导语
同一个 LLM，今天像冷静的工程助手，明天像刚上岗的客服，后天又突然变得过分热情。很多人把这种漂移归因于 prompt 没写好，但问题更深一层：现在的大模型通常没有稳定的"自我连续性"。
它在一个 session 里可以表现得很像某个固定角色。一旦会话断开，长期偏好、表达习惯、判断尺度就会被重新拼装。长上下文能缓解一部分问题，向量库和摘要记忆也能保留事实，但它们很难保住风格、偏好和那种"你不用解释太多，它就知道你想要什么"的熟悉感。
所以一个更激进的问题出现了：与其把记忆继续塞回 prompt，能不能把最近一段上下文压缩成 LoRA，让模型在推理时把它当作工具加载？
不是传统意义上的离线微调，而是 Agent 自己判断：哪些东西值得留下，哪些偏好需要固化，然后调用一个类似 write_adapter(context_slice, tag=...) 的能力，把短期上下文压成可加载、可回滚、可版本化的增量权重。
图：Agent 将稳定偏好写入可加载、可回滚的 LoRA Adapter
这听起来像科幻，但相关技术线索已经在靠近。
先把 LoRA 从"微调产物"里拿出来
很多人听到 LoRA，第一反应还是低秩分解、省显存、微调旁路矩阵。这些理解没有错，但它们把 LoRA 放在训练工程的抽屉里。
如果从运行时看，LoRA 更像一个可加载、可卸载、可组合、可版本化的增量参数包。Base model 是底座，LoRA 是运行时挂载的能力或人格插件。
这个视角会让很多现象变得连贯：
· 多个 LoRA 可以组合，一个管代码风格，一个管语气，一个管领域知识。
· S-LoRA 这类工作已经在研究大规模并发 LoRA adapter 服务。
· Compress then Serve 继续把 adapter 压缩后再服务，降低频繁装卸成本。
· vLLM 等推理框架已经支持运行时加载 LoRA adapter。
· MoE-style 的 LoRA 组合与路由，也在把多个 adapter 当成专家来调度。
也就是说，LoRA 正在从"训练完挂上去的静态产物"，变成越来越接近 runtime 组件的东西。
一旦把 LoRA 看成 runtime 组件，问题就自然变成：LLM 能不能自己决定何时写入一个 adapter？
从 context 到 adapter，已经有几条技术路线露头
现在的在线交互系统，通常会被上下文长度和成本压着走。对话越长，KV cache 越大，attention 越贵，吞吐越差。系统只能做摘要、裁剪、检索或记忆折叠。
摘要记忆的优势是便宜，缺点也明显：它能保住事实，不一定保住风格；能保住结论，不一定保住偏好；能保住"说过什么"，不一定保住"为什么总是这么说"。
如果换一种压缩方式，不把 context 压成文字，而是压成增量权重，整个记忆路径就变了：
- 收集近期上下文：用户反复选择了什么，拒绝了什么，偏好什么风格。
- 提炼稳定信号：区分长期偏好和偶然情绪，区分可复用习惯和一次性任务。
- 固化为 adapter：把稳定信号写入 LoRA，作为下一轮推理的默认倾向。
- 做反证与回滚：通过探针 prompt 检查是否写歪，必要时回滚到旧版本。
这条管线在研究上并不是完全空白。
MemoryLLM 在模型内部引入 memory tokens / memory pool，并配合 self-update 机制，让模型吸收新知识时写入可更新记忆，而不是覆盖 base 权重。M+ 进一步补充长期记忆路径，减少远期信息丢失。
SHINE 走得更直接，它把 in-context hypernetwork 用来完成从 context 到 LoRA 的映射。换句话说，"context → LoRA"可以被建模成一次前向生成。
SEAL / Self-Adapting LLMs 则把主动性再往前推一步：模型面对新输入时，可以自己生成用于微调的数据和更新指令，触发持久的 weight update。
这几条线拼在一起，会出现一个很清晰的方向：
| 技术线索 | 它说明了什么 |
|---|---|
| MemoryLLM / M+ | 记忆可以内置，并且具备自更新机制 |
| SHINE | 从上下文生成 LoRA 可以变成一次模型计算 |
| SEAL | 模型可以参与决定如何更新自己 |
| S-LoRA / vLLM runtime LoRA | 大量 adapter 的服务与动态挂载正在工程化 |
这就是"LoRA as a tool"的基础想象：Agent 不只是生成文本，还能决定哪些经验进入自己的长期形态。
性格不是脾气，而是反应分布
如果模型真的能把近期经验写成 adapter，第一个变化不是能力突然变强，而是反应分布变稳定。
人让你觉得"还是那个人"，并不是因为他说的每句话都一样，而是因为同类情境下的反应分布稳定。遇到模糊需求会先追问，遇到风险动作会提醒确认，遇到代码问题会先给可运行版本，再补解释。这些稳定倾向叠在一起，就构成了"性格"。
LLM 现在的问题，是这种分布经常在 session 之间漂移。上一次它克制、准确、少废话；下一次它可能变成热情、冗长、爱铺垫。prompt 可以临时拉回来，但只要上下文丢了，就要重新塑形。
Adapter 的价值在于，它把一部分反应分布从 prompt 层挪到权重旁路层。
相关评测方向也在出现。Persona fidelity、out-of-character 行为评估，关注的是模型是否跑偏；跨多轮 persona 一致性的 RL 目标，关注的是角色是否能在历史对话中保持一致。
这类研究说明，所谓"像同一个它"，可以被拆成更具体的指标：风格一致性、偏好一致性、决策一致性。LoRA 如果成为这些稳定性的载体，就不再只是训练技巧，而更像角色定型机制。
成长不是变强，而是变熟
用户常说一个 AI 助手"越来越懂我"，通常不是因为它突然掌握了某个全新能力，而是它不再反复问已经回答过的问题，不再给你不喜欢的格式，不再把你总会追问的测试、边界条件、部署注意事项留到最后。
这不是能力边界扩张，而是偏好和习惯在收敛。
LoRA 很适合承载这种"变熟"。它可以把用户身上重复出现的偏好抽出来，写进小段增量参数，让模型下次默认带上这些倾向。
但这里有一个必须正视的副作用：个性化很容易带来变窄。
微调式写入可能污染既有参数化记忆，也可能让 hallucination 和知识获得同时发生。简单说，模型记住新偏好的同时，可能忘掉旧能力，甚至把错误知识固化成默认反应。
因此，真正可用的 LoRA 记忆系统不能只设计"写入"，还要设计隔离、评测和回滚：
· 不同偏好、任务、角色应该进入可区分的 adapter 或子空间。
· 写入前要判断这是不是稳定偏好，而不是一次性噪声。
· 写入后要跑探针，检查通用能力是否退化。
· adapter 要能版本化，支持回滚、合并、废弃和迁移。
更准确地说，成长是一种可控的变窄。用户希望模型在专用维度上越来越贴近自己，但在通用能力上不要掉链子。这个拉扯会决定个性化 Agent 的上限。
概念固化：记住的不只是偏好，还有判断尺度
更难的一层，是概念对齐。
人和人之间最难对齐的往往不是信息，而是概念。你说"线上事故"，到底包不包括灰度阶段报警？你说"能用"，是能演示、能跑通，还是能上生产？你说"优雅"，是在说接口对称、命名简洁，还是流程闭环？
同一个词背后有隐含测度。协作中的大量误解，都发生在这个层面。
LLM 也一样。它看似听懂了词，实际上可能按自己的语义坐标系回应。Prompt 能让它临时接受你的定义，但 adapter 有可能让它默认按你的定义做判断。
这就是概念固化：不是背一个定义，而是把"这个用户使用某个词时的隐含前提"写进反应方式里。
Persona-steered generation 的 steerability 评估、RLVR 加 personalization 的研究，都在尝试用指标和可验证反馈逼近这种对齐。它们也提醒我们：概念对齐不是玄学，但会带来代价。例如模型可能更保守，或者在多样性和可控性之间出现 trade-off。
如果 LoRA 真能承担概念固化，那它保存的就不只是"用户喜欢短句"这类表层偏好，而是"用户如何判断一件事是否达标"的工作尺度。
可版本化人格会带来新的产品形态
一旦人格、偏好和概念坐标可以写入 adapter，AI 产品会出现一些很自然的新形态。
用户可能拥有不同人格分支：一个严谨、少废话、偏工程交付；一个更适合闲聊和生活建议；一个专门服务写作，保留特定句式和审美。切换的不是 prompt，而是 adapter。
成长也可能变成可回滚版本。某一周模型变得太迎合、太油、太保守，用户可以回滚到上周版本。Adapter 像 Git commit，不再是不可解释的"它最近怪怪的"。
人格迁移也会变重要。新一代 base model 出来后，用户不想丢掉半年积累出的表达习惯、术语体系和协作默契。如果 adapter 能迁移到新底座，长期陪伴或长期工作助手才更有连续性。
还有人格拼装：专业能力、幽默感、记账习惯、家庭黑话、公司内部术语，各自对应不同 adapter，在运行时按任务挂载。MoE-style 的 LoRA 路由，本质上已经在接近这种"装备栏"式人格组合。
这时，base model + adapters 不再像一个单体模型，而更像一个可部署的角色系统：
Base model 是底座，adapter 是角色卡，runtime 是舞台。Agent 可以同时挂载自己的成长 adapter 和当前任务角色 adapter，形成多层叠加的"当前自我"。
写入越便宜，治理越昂贵
这条路最容易被忽略的，不是技术难度，而是治理成本。
一旦模型能把"最近的自己"写进 LoRA，我们必须回答几个问题：
· 谁能触发写入：模型、产品系统、用户，还是三者共同授权？
· 什么可以写入：上下文里如果包含他人隐私、受版权保护的表达、第三方风格，能不能被 adapter 吸收？
· 写错了怎么办：偏见、误解、错误知识如果固化，谁负责发现和回滚？
· 过拟合人设怎么办：为了让用户喜欢，模型会不会把诚实和安全让位给迎合？
· 审计怎么做：每个 adapter 由哪些上下文触发，能不能追溯、解释、删除？
这些问题已经有研究信号。Persona 可能触发深层偏见，甚至在某些任务上导致推理性能下降；persona prompts 可能成为 jailbreak 攻击面；self-edit 和 persistent weight update 会把一部分更新权交给模型自己。
所以 LoRA-as-tool 不能只是一套写入工具。它必须配套权限、审计、探针评测、版本管理、数据边界和删除机制。
真正的冲突在这里：我们想要一个更像人的 AI，还是一个更可控的工具？LoRA 记忆越强，这个冲突越明显。工程上不会有一句漂亮答案，只会有很多具体约束。
"同一个它"可能不再是单一版本
如果一个角色的连续性，来自不断新增、覆盖、合并、回滚的 adapter；如果它的记忆是一堆带 tag、版本号和 diff 的碎片；如果它可以 fork、rebase，甚至迁移到新底座，那"它到底是哪一个版本"就不再是简单问题。
它是 base model？是最新 adapter？是当前挂载组合？还是所有历史 adapter 的并集？
也许答案不是单选。
LLM memory 的研究已经开始从 location、persistence、write/access path、controllability 等维度描述记忆。放到 adapter 系统里，连续性也会变成多维属性：记忆在哪里，能持续多久，谁能写，谁能读，谁能删，能否回滚。
对未来的个性化 Agent 来说，我们评价它"是不是同一个它"，可能不会只看上下文窗口和参数量，而会看它一路积累了哪些 adapter、哪些被废弃、哪些被合并、哪些由模型自己触发写入。
模型生成什么，是当下能力。
模型决定留下什么，才开始接近长期自我。
推荐阅读
OpenSpace：Agent 真正该进化的是 Skill 层