记忆系统 · 2026

Inside Out: Evolving User-Centric Core Memory Trees for Long-Term Personalized Dialogue Systems

这篇论文研究长期个性化对话系统中的记忆演化问题。作者提出 Inside Out 框架，用一个全局维护的 PersonaTree 作为长期用户画像载体：树干由生物-心理-社会模型约束，枝叶通过 ADD、UPDATE、DELETE、NO_OP 等原子操作随对话动态演化。为了让小模型也能维护记忆，论文用 28k 指令数据训练 MemListener，并通过过程奖励强化学习让它生成结构化、可执行、可解释的树操作。推理阶段，系统在低延迟场景直接读取 PersonaTree；遇到长尾细节需求时，再触发 agentic recall 进行查询扩展、并行检索和融合生成。实验显示，PersonaTree 在 PersonaMem 上跨三种响应模型稳定超过全文拼接和 LangMem、Mem0、A-Mem、MemoryOS 等记忆系统；训练后的 Qwen 系列小模型在记忆操作决策上能接近甚至超过强推理模型，同时把平均记忆上下文压缩到约 2.2K 到 2.6K tokens。

作者: Jihao Zhao^1,2,3Ding Chen⁴Zhaoxin Fan^2,5Kerun Xu^2,3Mengting Hu^2,6Bo Tang^2,3Feiyu Xiong^2,3Zhiyu Li^2,3
机构: School of Information, Renmin University of China中国人民大学信息学院
MemTensor (Shanghai) Technology Co., Ltd.忆象量子（上海）科技有限公司
Institute for Advanced Algorithms Research, Shanghai上海高级算法研究院
China Telecom Research Institute中国电信研究院
Beijing University of Aeronautics and Astronautics北京航空航天大学
Nankai University南开大学

进入中英精读 arXiv GitHub

读前先抓住结论

Inside Out 讨论的是长期个性化对话里的一个老问题：用户和 agent 聊得越久，历史越多，系统越难既记得细节，又保持低延迟和高一致性。直接把全部历史塞进上下文会变贵、变吵、变不稳定；只做向量检索又容易把记忆退化成一堆事实片段，缺少可控的长期用户状态。

论文的核心答案是：不要把长期记忆当作无边界文本仓库，而要把它维护成一棵可演化的 PersonaTree。这棵树的树干由生物-心理-社会模型约束，叶节点保存用户核心属性的压缩描述；对话不断到来时，系统不是追加摘要，而是生成 ADD、UPDATE、DELETE、NO_OP 四类原子树操作，持续更新这棵用户画像树。

为了让记忆维护不依赖每次调用强大推理模型，作者训练了一个轻量级 MemListener。它先通过监督微调学会输出可执行操作序列，再通过过程奖励强化学习对齐，让生成的树操作更接近人工标注的高质量记忆演化轨迹。论文想验证的不是“树结构看起来漂亮”，而是“小模型能否承担长期记忆维护，大模型只负责最终生成”。

实验结果比较有力。PersonaTree-ALL 在 PersonaMem 上跨三种回复模型都超过全文拼接和 LangMem、Mem0、A-Mem、MemoryOS 等记忆系统：总体分在 DeepSeek-V3.1、Longcat-Flash-Chat、DeepSeek-R1-0528 下分别达到 71.31、75.38、76.06。更关键的是，训练后的 PersonaTree 平均只带来约 2.2K 到 2.6K tokens 的记忆上下文，却能匹配或超过约 32K tokens 的全文历史。

为什么个性化记忆不能只是历史拼接

长期个性化对话和普通问答最大的区别，是系统需要持续理解“这个用户是谁”。用户的事实背景、偏好变化、表达习惯、关系立场和情绪模式，都会在很多轮对话中慢慢显现。短期里，一个大模型靠当前上下文还能模仿个性化；但历史变长后，相关线索会被大量普通对话、临时任务和无关细节淹没。

直接拼接全历史看似最简单，因为信息没有丢。但它有三个明显问题。第一是成本，32K 甚至更长上下文每轮都塞进去，部署成本和延迟都会快速上升。第二是噪声，模型需要在庞大上下文里自己找关键用户特征，注意力很容易被近期但不重要的片段吸走。第三是一致性，历史里可能有旧偏好、新偏好、一次性情绪和长期稳定特征，模型如果没有显式状态管理，就很难判断哪些应该长期保存。

向量检索能缓解成本，但不等于解决个性化。检索系统通常把记忆当作文本片段或事实列表：用户喜欢什么、说过什么、做过什么。问题在于，个性化不只是事实召回，还包括对用户稳定特征的组织。比如“用户最近反复提到睡眠不足”“用户在工作任务中偏好低风险方案”“用户对被打断很敏感”，这些信息需要被整合进长期画像，而不是每次都从分散片段重新推断。

论文借用了电影《Inside Out》的隐喻：人格不是所有经历的堆叠，而是由少数核心记忆塑造的“人格岛”。这个隐喻对应到系统设计，就是长期记忆应该有筛选、压缩和层级组织。用户画像不能无限增长；它必须有边界、有结构、有可解释的更新规则。

历史拼接 / 文本检索

把过往对话当作原始材料或相似片段。优点是简单，缺点是上下文成本高、噪声大、难以维护稳定用户状态。

PersonaTree

把用户长期特征维护成可编辑树状态。优点是压缩、可解释、可控，并且能用小模型持续更新。

这篇论文真正反对的不是检索，而是缺少“状态”的记忆。一个长期 agent 应该知道当前用户画像是什么、哪些字段可写、哪些新信息值得保留、旧信息如何被修正、删除或合并。PersonaTree 就是把这套状态显式化：不是一堆历史，而是一棵随交互演化的用户核心记忆树。

这也是它和“用户画像表单”的区别。传统画像表单通常是静态的：年龄、职业、城市、兴趣、偏好，填完以后很少变化。真实对话里的用户状态却是动态的。用户可能在某个时期改变作息，可能逐渐从“喜欢尝试新工具”变成“更在乎稳定性”，也可能在不同任务里展现出不同风险偏好。长期 agent 如果只保存静态字段，就会把过期信息当成当前事实。

Inside Out 的思路是把画像从静态 profile 改成可演化 state。这个 state 不是每轮都重写一遍，而是通过原子操作不断更新。这样做的好处是：每次变化都有操作记录，每个字段有明确路径，每个值是当前综合判断。相比一段自由文本摘要，树状态更容易校验、压缩、展示、回滚，也更容易交给小模型学习。

还有一个容易忽略的点：个性化不只服务“用户喜欢什么”。论文的指标里有偏好推荐、偏好演化、理由召回、新想法生成、用户事实召回等多个维度，说明个性化系统需要同时处理事实、偏好、原因和迁移。一个人过去为什么改变偏好，往往比偏好本身更能指导未来回复。PersonaTree 的层级结构给这些不同类型的状态提供了位置。

如果把长期 agent 想成一个系统，历史对话是日志，检索库是索引，PersonaTree 则是当前状态表。日志不能每次全读，索引不能替代状态，状态也不能丢掉证据。Inside Out 的贡献就是把这三者分清：树保存压缩后的核心状态，历史仍可被召回，生成阶段根据需求决定使用哪一种。

方法总览：Inside Out 的三段流水线

Inside Out 的整体框架可以拆成三段：先构造和演化 PersonaTree，再训练 MemListener，最后用 PersonaTree 做自适应回复生成。论文的 Figure 1 把这三段放在同一张流程图里：对话历史被切成 chunks，模型生成树操作，操作更新 PersonaTree；训练阶段让 MemListener 学会这套过程；推理阶段再把树作为长期用户状态使用。

论文原图：Inside Out 的完整流程。左侧是 PersonaTree 和数据构造，中间是 MemListener 的 SFT 与过程奖励 RL，右侧是基于 PersonaTree 的快模式和 agentic recall 推理。

第一段是 Dynamic PersonaTree Evolution。系统启动时先有一个初始树，这棵树由生物、心理、社会三个维度的 schema 约束。随着对话历史进入系统，每个 dialogue chunk 都会触发一次树更新：模型读取当前 chunk、上一版本树状态和规则约束，输出一组原子操作；安全门验证操作合法性；执行后保存新版本树。

第二段是 MemListener Training。论文不是每次都让大模型临时写树操作，而是构造约 28K 指令数据，用 DeepSeek-R1-0528 生成监督信号，并进行人工校验。之后训练 Qwen 系列小模型，让它成为专门负责记忆维护的 MemListener。训练分为 SFT 和强化学习两步：SFT 学格式和基本决策，RL 用过程奖励提升操作质量。

第三段是 Adaptive Response Generation。当用户问题只需要稳定画像时，系统进入快模式，直接把 PersonaTree 的非空叶节点作为个性化先验拼进上下文，一次生成回复。当问题需要更多长尾细节时，系统进入 agentic recall 模式，基于 PersonaTree 扩展多个查询、并行检索历史证据、重排融合，再生成回答。

1建树

用生物-心理-社会 schema 初始化用户画像树

2写操作

把新对话转成 ADD/UPDATE/DELETE/NO_OP

3训模型

用 SFT 和过程奖励 RL 训练 MemListener

4快回复

低延迟场景直接读树生成

5深召回

复杂查询触发 query expansion、检索、重排和融合

这个三段设计的一个重要好处，是把记忆维护和回复生成拆开。过去很多系统把“找记忆”和“生成回复”都压给同一个强模型；Inside Out 则让小模型维护结构化状态，让大模型基于状态生成。这样做如果成立，就能显著降低长期个性化系统的成本。

更细一点看，这三段流水线也对应三个不同的失败点。第一段如果建树失败，用户画像就会丢字段、混路径或把无关信息写入长期状态；第二段如果训练失败，小模型会生成不可执行操作，或者在冲突处理时覆盖旧信息；第三段如果推理失败，系统即使有好树，也可能在不需要时触发昂贵召回，或在需要细节时只给出泛化回复。论文的实验和消融基本就是围绕这三个失败点展开。

Inside Out 的名字也有方法含义。“Inside” 是用户核心状态：稳定特征、长期偏好、关系立场、行为模式；“Out” 是对话里的外部表现：用户每轮说了什么、提出什么请求、需要什么回复。框架不是直接从外部表现生成回复，而是先把外部对话压缩回内部状态，再从内部状态向外生成。这个方向和普通 RAG 的“找相关片段再回答”不同，它多了一步状态演化。

从数据构造角度，论文使用 DeepSeek-R1-0528 生成监督操作，再人工过滤无效语法、错误路径和语义不一致写入。这说明作者并不认为强模型输出天然可靠，而是把强模型当成数据合成器，再用校验和训练把行为固化到小模型里。对实际团队来说，这是一条可复制路线：先用强模型构造高质量操作轨迹，再训练便宜模型在线维护记忆。

PersonaTree：把用户画像变成可演化树

PersonaTree 的直觉很朴素：用户画像不应该是一段越写越长的自然语言摘要，而应该是一棵有固定主干、可更新叶子的树。论文采用生物-心理-社会模型作为树干约束，把用户特征分成 biological、psychological、social 三大类。每个叶节点是一个文本槽位，用描述性字符串保存该属性的当前状态。

这个 schema 约束非常关键。没有 schema，记忆系统会不断发明新字段，最终变成不可管理的文本堆。schema 给了树一个“可写空间”：哪些类型的信息值得长期保存，应该写到哪个路径下，每个叶节点容量如何控制。这样，长期记忆的增长不再是无边界追加，而是在固定结构中更新。

\mathcal{T}_t=f_{\text{update}}(\mathcal{T}_{t-1},D_t),\quad y_t=f_{\text{gen}}(x_t,\mathcal{T}_t,f_{\text{recall}}(\mathcal{T}_t,H))

公式的意义不是为了复杂化，而是把长期个性化问题重写成两个函数。第一个函数是状态更新：用户每次说了新内容，树状态是否应该改变？第二个函数是状态条件生成：有了当前树状态和必要历史证据，如何生成更个性化的回复？这比直接建模 $P(y_t|H)$ 更清晰，因为历史 $H$ 可能无限增长，而树状态 $\mathcal{T}_t$ 是可控的压缩表示。

PersonaTree 的另一个价值是可解释。向量记忆命中一个片段时，你知道系统找到了什么文本，但不一定知道它如何改变用户画像。树结构则可以显示：某条对话更新了哪个路径、旧值是什么、新值是什么、为什么该字段现在更准确。对真实产品来说，这种可解释性不仅是技术优势，也关系到隐私、撤销和用户可控。

当然，树结构也带来取舍。它适合保存稳定或半稳定的个性化属性，比如偏好、习惯、风格、身份背景、长期状态；它不一定适合保存所有短期事件。论文的做法是让 PersonaTree 承担核心用户状态，而不是替代完整历史。需要细节时，系统仍会通过 agentic recall 回到历史中找证据。

PersonaTree 里的叶节点值是 descriptive string，这个选择看起来简单，但很实用。完全结构化的枚举字段容易过窄，无法表达用户偏好的细微变化；完全自由的段落摘要又太难执行和校验。叶节点文本槽位介于二者之间：路径给出结构，文本保留表达弹性。比如“工作偏好.风险倾向”这个路径下，可以写“在财务相关任务中更倾向保守方案，但愿意在低成本工具试用上尝试新方法”，这种信息很难用单个枚举表达。

生物-心理-社会 schema 的作用也不只是理论包装。它提醒系统：用户画像不应只围绕消费偏好或显式个人资料，还应覆盖身体状态、心理特征、社会身份和行为模式等维度。长期陪伴、个人助手和学习辅导类 agent 都可能需要这些维度。树干来自统一 schema，可以让不同用户的画像可比较；叶节点内容又允许每个用户保持个体差异。

但 schema 越强，偏见风险也越强。如果树里预设了过多心理或社会类别，模型可能把用户短期表达过度归类。论文在局限里提到可以扩展 schema，却没有完全解决“哪些字段应该存在”的治理问题。工程上最好让 schema 分层：基础字段稳定启用，敏感字段需要明确用途和权限，高风险心理判断则尽量低置信度、可撤销、可展示依据。

树状态还需要和证据层绑定。论文的主方法强调版本化持久化，但对每个叶节点的来源指针没有展开。真实系统里最好为每次 ADD/UPDATE 记录来源对话、时间、置信度和操作模型版本。这样，当用户质疑“你为什么认为我偏好低风险”时，系统能解释字段来源，也能删除或修正对应记忆。

树如何更新：四类原子操作和安全门

PersonaTree 的更新不是让模型随便改 JSON，而是要求模型输出四类原子操作：ADD(path, value)、UPDATE(path, value)、DELETE(path, value)、NO_OP()。这四类操作把非结构化对话转成可执行的状态编辑语言。

ADD 用于某个属性还没有记录时写入新信息；UPDATE 用于已有属性需要补充、修正或整合；DELETE 用于当前对话明确否定旧信息或要求删除；NO_OP 则表示这段对话没有稳定核心用户信息，不应写入长期记忆。这个 NO_OP 很重要，因为长期记忆系统最容易犯的错就是“什么都记”，导致噪声膨胀。

AlgorithmPersonaTree evolution with MemListener

1Require: dialogue chunks  $D_1...D_N$ , initial tree  $\mathcal{T}_0$ , rule set  $\mathcal{R}$ , MemListener  $\pi_\theta$ 2Ensure: updated PersonaTree  $\mathcal{T}_N$ 3for  $t \leftarrow 1$  to  $N$ :4   $Input_t \leftarrow (D_t, \mathcal{T}_{t-1}, \mathcal{R})$ 5   $\mathcal{O}_t \leftarrow \pi_\theta(Input_t)$ 6  validate paths, operation types, value strings, and length budgets7  execute ADD / UPDATE / DELETE / NO_OP on  $\mathcal{T}_{t-1}$ 8  persist  $\mathcal{T}_t$  as a new version9return  $\mathcal{T}_N$

这段伪代码把论文的树演化机制压缩成一个闭环：按时间处理对话块，生成操作列表，安全校验，执行树编辑，并把每次更新后的树保存为新版本。

算法的输入包括对话块序列、初始树、规则集合和 MemListener。规则集合 $\mathcal{R}$ 包含可写范围、路径约束、叶节点类型、输出格式和长度预算。它的作用是让模型在明确边界内工作，而不是让生成模型自由发挥。

主循环每次处理一个 dialogue chunk。模型看到当前对话块和上一版本树状态，决定这段对话是否包含应写入长期记忆的信息。如果有，它要选择正确路径和操作类型，并生成整合后的文本值。尤其在 UPDATE 中，论文提示要求新值不能丢掉仍然有效的旧信息，而要把旧内容和新补充融合成更准确的当前状态。

安全门负责结构约束而不是语义决策。它检查路径是否允许、操作类型是否合法、value 是否是字符串、长度是否超过叶节点预算。论文强调，冲突解决发生在操作生成阶段，由模型根据对话和旧值判断；安全门不再做二次语义改写。这种分工让系统既能利用模型的语义推理，又能避免执行层污染树结构。

版本化持久化则让记忆演化可追踪。每次执行操作后，系统保存新的树版本，形成 $\mathcal{T}_0,\dots,\mathcal{T}_N$ 的演化序列。对产品来说，这意味着可以回滚、审计、展示“某个字段为什么变成这样”。这比一条不断覆盖的摘要更可控。

四类操作背后其实是一个小型数据库协议。ADD 是插入，UPDATE 是合并式改写，DELETE 是删除或失效标记，NO_OP 是拒绝写入。很多记忆系统只有“新增摘要”这一种动作，所以很难表达偏好变化和信息撤销。Inside Out 把这些动作显式化，使长期记忆从 append-only 变成可维护状态。

其中最难的是 UPDATE。如果用户说“我以前喜欢跑步，但最近膝盖不舒服，改成游泳”，一个粗糙系统可能只写“用户喜欢游泳”，丢掉跑步和膝盖这两个重要上下文；另一个粗糙系统可能把“喜欢跑步”和“喜欢游泳”都保留，造成冲突。论文 prompt 要求 UPDATE 整合仍有效旧信息和新信息，本质上是在训练模型做时间敏感的状态归纳：过去是什么，现在变成什么，哪些原因值得保留。

NO_OP 同样值得强调。长期对话里绝大多数句子都不应该进入核心记忆：寒暄、临时情绪、一次性任务、随口举例、模型诱导出的假设。如果没有 NO_OP，记忆库会迅速膨胀，而且越个性化越危险，因为模型可能把偶然表达当成稳定用户特征。Inside Out 把“不写”作为一等操作，这比只优化写入召回率更成熟。

安全门的角色也很克制。它不尝试判断用户真正意思，只检查结构合法性和容量约束。这是合理的，因为执行层如果也做语义改写，就会出现两个模型争夺记忆解释权：一个生成操作，一个执行时再改。论文把语义判断集中在操作生成阶段，把执行层保持为确定性 gate，有利于调试和复现。

MemListener 训练：让小模型负责记忆维护

如果每次树更新都依赖大模型，Inside Out 的部署价值会打折。所以论文训练了 MemListener：一个轻量级模型，专门把对话块和旧树状态转换成树操作。训练数据来自 HaluMem 和 PersonaMem 中与用户特征有关的子集，并使用 DeepSeek-R1-0528 按 PersonaTree 更新流程生成监督信号，再进行人工校验。

训练第一步是监督微调。给定输入 $s$ ，其中包括 dialogue chunk、上一树状态和规则约束；目标输出 $o$ 是真值操作序列。模型优化标准自回归交叉熵，让它学会稳定输出合法操作。

\mathcal{L}_{\mathrm{SFT}}(\theta)=-\frac{1}{\tau}\sum_{t=1}^{\tau}\log P_\theta(o_t\mid o_{<t},s)

SFT 解决的是“能不能输出像样的操作”。但长期记忆维护还有更难的一层：操作是否真的高质量。一个操作可能格式正确，却写错路径、遗漏关键属性、冗余写入、或者把旧信息覆盖得太粗暴。因此论文继续使用过程奖励强化学习，让模型在操作质量上对齐人工标注。

强化学习阶段使用 DAPO 目标。对同一个输入，旧策略采样 8 个候选操作序列；评审器根据预测序列和真值序列的差距给出 $[-1,1]$ 分数；分数在组内标准化成 advantage；再用带裁剪的重要性比率更新策略。论文采用非对称裁剪， $\epsilon_{\text{low}}=0.2$ 、 $\epsilon_{\text{high}}=0.28$ ，给低概率探索 token 更大的上调空间。

\hat{A}_{i,t}=\frac{R_i-\operatorname{mean}(\{R_j\}_{j=1}^{G})}{\operatorname{std}(\{R_j\}_{j=1}^{G})},\quad G=8

附录里的奖励函数 prompt 也值得注意。评审器不是评价最终对话回复，而是评价 Pred_Ops 与 GT_Ops 的整体一致性，包括操作类型、路径、值语义和冗余程度。输出必须是 {\"score\": <float>}，没有解释。这说明论文训练的是“记忆操作能力”，不是把回复质量直接反传给生成模型。

先学会输出合法、稳定、可解析的树操作。

这个设计的工程含义很清楚：如果你的长期 agent 每轮都调用强模型总结记忆，成本会很高；如果能训练一个小模型只负责树操作，整个系统就可以更便宜、更稳定，也更容易审计。

为什么过程奖励适合这里？因为树操作不是单一分类题。一个样本可能包含多个属性，每个属性涉及路径、动作和值；预测中只要漏一个关键路径，或把 UPDATE 写成 ADD，最终树状态就会变差。但这些错误又不是全错全对，很多预测是部分可用的。连续分数比二元标签更能表达这种灰度，强化学习也能把高质量轨迹和低质量轨迹区分开。

论文还提到超长序列优化问题。输入包括对话块、旧树状态和规则约束，长度上限到 10K；如果用普通样本级组相对优化，长序列里的关键 token 信号容易被平均掉。DAPO 的优势在于更细粒度地处理 token-level policy gradient，并通过动态采样避免同组候选全对或全错导致 advantage 退化。换句话说，训练目标不是“让输出更像一段文本”，而是“让长操作序列里的关键决策更可靠”。

附录超参数也说明这不是轻量玩具实验。训练使用全量微调、bfloat16、学习率 $1\\times10^{-6}$ 、最大序列长度 11264、最大生成长度 512、每个输入采样 8 个候选、KL 控制系数 0.001，并启用动态采样。它的成本比简单 prompt 工程高，但换来的是在线推理时小模型维护记忆的可能性。

这里要区分两个模型角色。MemListener 不需要擅长最终聊天，也不需要掌握所有世界知识；它只需要擅长读对话、读树、读规则，然后输出操作。回复模型则不需要理解完整历史演化过程，只需要使用当前树和必要证据。这种职责分离让每个模型的任务更窄，也让系统更容易优化。

如果团队没有能力做 RL，也可以先复用论文的两阶段思路做简化版：用强模型生成操作数据，人工抽查高风险字段，用 SFT 训练小模型，在线阶段保留规则校验和人工反馈通道。等有足够线上纠错数据后，再做偏好优化或过程奖励训练。Inside Out 的核心不是必须使用某个算法，而是用训练让记忆写入从 prompt 行为变成模型能力。

推理：快模式与 agentic recall

推理阶段，Inside Out 不会每次都做复杂检索。它把最终 PersonaTree $\mathcal{T}_N$ 当作结构化长期记忆，根据用户请求选择两种路径。

第一种是 PersonaTree-Augmented Generation，也就是快模式。系统直接读出树结构和非空叶节点，把它们作为个性化先验与用户查询拼接，然后一次生成回答。这个模式适合用户问题主要依赖稳定画像的场景，比如偏好推荐、风格适配、长期习惯相关的简单回应。它的优势是低延迟、低成本、上下文短。

第二种是 Agentic Recall and Fusion。当用户明确要求更多细节，或者查询更长尾、更复杂时，系统基于 PersonaTree 生成多个扩展查询。每个扩展查询强调不同属性维度或潜在缺失信息；系统并行检索历史证据，再重排候选，融合成上下文 $C$ ，最后用 $[q,\mathcal{T}_N,C]$ 生成回答。

1判断需求

先判断是否需要深度细节

2扩展查询

基于 PersonaTree 生成多个属性相关查询

3并行检索

从历史中检索候选证据

4重排融合

按相关性重排并合并上下文

5生成回答

用原查询、树状态和证据共同生成

这个自适应策略在实验中很重要。只用 PersonaTree 已经能覆盖大量稳定属性问题，但遇到细粒度事实或长尾需求时，单靠树叶文本可能不够。agentic recall 补的是细节证据，而 PersonaTree 负责约束召回方向，避免检索在长历史中漫游。

路由机制则是成本控制。完整 agentic recall 效果最好，但不一定每次都值得触发。论文消融显示，PersonaTree+Router 可以接近完整模式性能，同时显著减少额外检索开销。这类设计很符合实际产品：默认快，必要时深。

快模式和深召回的区别，也对应两类用户问题。用户问“帮我按我的偏好推荐一个周末计划”，系统大概率只需要树里的偏好、作息、兴趣和约束；用户问“上次我说不想参加那个活动，是因为什么来着”，系统就需要回到历史证据，因为原因可能藏在某段具体对话里。PersonaTree 可以告诉检索器应该往哪类证据找，但不能替代所有细节。

agentic recall 的查询扩展很有价值。原始问题常常很短，例如“那件事后来怎么想的？”如果直接向量检索，可能找不到正确历史片段；如果先用 PersonaTree 展开成“用户最近关于工作冲突的担忧”“用户对风险和人际压力的长期偏好”等多个查询，检索覆盖会更好。树状态在这里不是回答内容，而是检索导航。

这也解释了为什么 PersonaTree-ALL 在 New-Ideas 和 Gen-New 上提升明显。生成新建议或新内容不只是回忆旧事实，还要把用户长期状态迁移到新场景。快模式提供稳定画像，深召回补充具体证据，二者结合比全文拼接更少噪声，也比普通检索更有方向。

部署时，路由器的设计会非常关键。触发太频繁，成本接近完整召回；触发太保守，复杂问题会缺证据。论文没有展开路由器训练细节，因此真实系统可以先用规则或轻量分类器：检测是否出现“更多细节”“为什么”“上次”“之前说过”等历史依赖信号，再逐步用用户反馈调整。

实验怎么读

论文主实验使用 PersonaMem。每条历史约由 10 段多轮对话按时间拼接，长度约 32K tokens，覆盖 15 类需要个性化的真实任务。指标是准确率，既报告 Overall，也报告七类细分能力：Recall-Facts、Pref-Rec、New-Ideas、Recall-Reason、Pref-Evol、Gen-New、Recall-User。

这些指标的含义可以分成三组。Recall-Facts 和 Recall-User 看系统是否能找回用户说过的事实；Pref-Rec、Pref-Evol、Recall-Reason 看系统是否能理解用户偏好及其变化原因；New-Ideas 和 Gen-New 则更接近开放生成能力，看系统能否基于用户画像提出新想法或迁移到新场景。

基线也覆盖了几类典型方案。Only LLM 不给历史，是下界；ALL Dialogue 拼接全历史，是高成本参考；LangMem、Mem0、A-Mem、MemoryOS 代表不同记忆管理框架。为了公平，论文统一使用 BGE-M3 做检索、BGE-Reranker-Large 做重排，并在三种 response model 下测试：DeepSeek-V3.1、Longcat-Flash-Chat、DeepSeek-R1-0528。

主结果最核心的数字是三组 Overall。DeepSeek-V3.1 作为回复模型时，最佳 PersonaTree-ALL 达到 71.31，比 Only LLM 高 18.68，比 ALL Dialogue 高 7.47，比 MemoryOS 高 8.83。Longcat-Flash-Chat 下，PersonaTree-ALL + Qwen3-8B-RL 达到 75.38，比 ALL Dialogue 高 13.58，比 MemoryOS 高 10.35。DeepSeek-R1-0528 下，PersonaTree-ALL + Qwen3-8B-RL 达到 76.06，比 ALL Dialogue 高 11.20，比 MemoryOS 高 13.41。

这说明 PersonaTree 的收益不是只来自某个特定回复模型。无论回复端是普通聊天模型还是强推理模型，结构化用户记忆都能提高结果。尤其在 Pref-Rec、New-Ideas、Recall-Reason、Pref-Evol 等维度上，PersonaTree 的提升说明它不仅记住事实，还能更好地调用偏好、原因和演化线索。

论文原图：雷达图展示 PersonaTree 在多指标上整体外扩，提升覆盖事实召回、偏好推荐、偏好演化、理由召回和新内容生成等多个维度。

额外实验把抽取模型从 DeepSeek-R1-0528 换成 DeepSeek-V3.1，PersonaTree-ALL 仍然在三种回复模型下取得最高 Overall：70.80、73.34、74.53。这说明方法不完全依赖某个特定抽取模型，树结构和自适应召回本身提供了可迁移收益。

不过，实验也需要保守解读。PersonaMem 是一个判别式 benchmark，模型最终输出选项，准确率能很好比较方法，但它不完全等价于真实开放域聊天体验。真实产品还要看用户满意度、回复自然度、隐私接受度、错误记忆的可纠正性，以及长期运行几周或几个月后的状态漂移。论文证明了结构化记忆在 benchmark 上有效，但还不能证明它在所有长期陪伴场景中都足够安全。

另一个值得注意的点是，ALL Dialogue 并不是总是上限。理论上全历史包含最多信息，但实验中 PersonaTree 经常超过它。这说明长上下文里的“更多信息”可能变成负担，模型面对 32K 历史时可能被噪声稀释；结构化树虽然更短，却提供了更高密度的个性化状态。这个结果对长上下文时代很有提醒意义：窗口变大不等于记忆问题消失。

主结果还显示，强推理模型作为回复端时，PersonaTree 仍然有明显收益。也就是说，即使最终回答模型足够强，它仍然受益于更干净、更结构化的用户状态。长期个性化不是单靠底座模型能力解决的问题，前置记忆表示的质量会直接影响下游回答。

消融、窗口和实现选择

消融实验先看推理组件。Only PersonaTree 是只用快模式；PersonaTree+Router 是加路由触发；PersonaTree-ALL 是完整 agentic recall 和融合。结果显示，只用 PersonaTree 已有稳健收益，但完整 agentic recall 最强；路由版本接近完整模式，同时降低额外检索成本。这支持论文的部署判断：快模式作为默认，复杂问题再触发深召回。

另一个关键表格比较不同记忆操作模型。未训练的 Qwen、GPT-4o-mini、Longcat、DeepSeek、Gemini 等都可以生成 PersonaTree 操作，但训练后的 Qwen2.5-7B 和 Qwen3-8B 明显更稳。Qwen3-8B + SFT+RL 在 Longcat 和 DeepSeek-R1 回复模型下总体达到 65.20 和 65.70，而平均记忆上下文只有约 2348 tokens。相比之下，ALL Dialogue 需要约 32K tokens。

论文原图：不同记忆操作模型的总体表现。训练后的 MemListener 相比未训练抽取器更稳定，SFT+RL 带来可迁移提升。

这张表最重要的不是某个小数点，而是 cost-performance trade-off。全文历史保留信息完整，但每次都要消耗 32K 上下文；训练后的 PersonaTree 用 2K 多 tokens 就能匹配或超过它。这意味着结构化记忆不是“把历史压短一点”，而是通过 schema 和操作学习保留更高信噪比的信息。

直接生成操作也优于“先抽取信息再转换操作”。论文比较了 direct generation 和 extract-then-transform，直接生成在不同抽取模型和回复模型组合下都更好，提升约 0.34 到 3.06。原因是两阶段方案会在中间表示里丢失细粒度语义和时间线线索；直接生成让模型从对话和旧树状态一步到位决定路径、操作类型和值。

对话分块窗口大小也很关键。论文测试 $w=1,3,5,7,10,13,15$ ，发现 $w=3$ 最稳定。窗口太小，信息碎片化，容易产生噪声写入；窗口太大，单块里跨话题混合、时间线折叠，关键线索反而被稀释。 $w=3$ 在“上下文充分”和“更新频率”之间取得了较好平衡。

论文原图：分块窗口大小对性能的影响。中等窗口，尤其 $w=3$，在三种回复模型下更稳定。

从实现选择看，Inside Out 给了几个很实用的经验。第一，记忆 schema 要先定义清楚，否则模型会无界扩展字段。第二，操作生成最好直接面向最终可执行格式，减少中间抽取误差。第三，记忆更新需要 NO_OP，否则长期系统会把闲聊和临时情绪都误写进核心画像。第四，路由式深召回能在效果和成本之间取得更好平衡。

消融结果还能读出一个更细的结论：Only PersonaTree 已经有用，但不是全部。它相当于把核心画像直接交给回复模型，适合稳定属性问题；PersonaTree+Router 说明只在必要时补历史证据就能接近完整模式；PersonaTree-ALL 则是效果上限。这为产品提供了三档配置：低成本默认版、平衡版、效果优先版。

直接生成操作优于两阶段方案，也提示我们不要过度拆分中间任务。看起来“先抽取用户信息，再映射到树操作”更可解释，但中间抽取一旦丢掉时间顺序、冲突关系或旧值上下文，后续转换就补不回来。直接生成让模型同时看到旧树和新对话，能一次性决定“这是新增、补充、修正还是不写”。

窗口大小实验则是非常落地的参数经验。 $w=3$ 并不是理论最优，而是在 PersonaMem 设置下更稳定。它说明记忆写入需要适度上下文：一轮对话太短，模型可能误判；十几轮太长，话题混杂，模型又难以提炼。真实系统可以根据业务调整窗口，比如客服任务可能用较短窗口，长期陪伴可能用事件边界而不是固定轮数。

附录 prompt 告诉我们什么

附录里的 PersonaTree 操作生成 prompt 很具体。它要求模型给定初始 persona schema 和对话历史后，输出更新 schema 的操作序列，并强调“尽可能全面覆盖这个人的信息，尤其是个性化特征”。但它同时约束：已记录信息不要重复抽取；如果对话与旧 schema 冲突，以最新明确陈述为准；每个 distinct 属性只生成一个操作。

这说明论文把 prompt 当作系统协议的一部分，而不是随便一句“请总结用户画像”。prompt 里明确规定了 ADD、UPDATE、DELETE、NO_OP 的使用条件、path 格式、value 格式和输出格式。这种严格格式是训练 MemListener 的基础，也是后续安全执行的前提。

尤其是 UPDATE 规则很值得借鉴。它要求新 value 必须语义上包含或整合此前仍然有效的信息，同时加入新信息，形成更完整、更准确、更及时的描述。它明确禁止“丢掉有用旧内容，只保留新信息”。这正是长期记忆系统里最容易出错的地方：更新不是覆盖，而是带时间意识的整合。

奖励函数 prompt 则把评审任务变成操作序列质量评分。评审器看到 GT_Ops 和 Pred_Ops，需要输出 $[-1,1]$ 的整体分数，评价类型、路径、值语义和冗余程度是否一致。分数锚点从 1.0 的几乎完美，到 -1.0 的无意义输出。这个连续分数比简单对错更适合操作序列，因为一个预测可能路径正确但值略有偏差，或漏掉少量属性。

1ADD(path, "value")2UPDATE(path, "integrated old and new value")3DELETE(path, None)4NO_OP()

如果要在自己的系统里复用，这两个 prompt 的启发是：记忆写入必须是可执行协议。不要只要求模型“总结用户记忆”，而要告诉它可写路径、操作类型、冲突策略、输出格式、何时不写、如何整合旧值。这样，后面的数据库、审计、回滚和用户管理才有可能稳定工作。

局限与复用启发

论文在局限里也很坦诚。PersonaTree 当前基于生物-心理-社会 schema，适合用户长期画像，但对更细粒度领域知识、任务技能画像或跨领域状态，还需要扩展成可组合子树或插件式模块。换句话说，这棵树不是一次设计完就适配所有应用，它需要随业务领域调整可写空间。

第二个局限是时间和证据。论文的叶节点主要保存描述性字符串，这对稳定核心属性有效；但如果记忆需要强时间约束、证据来源、多版本共存，就要增加时间戳、置信度、source pointer 等元数据。否则，系统可能知道“用户现在偏好低风险方案”，却不知道这个偏好来自哪段对话、是否仍然有效、是否和更早偏好冲突。

第三个边界是治理。PersonaTree 显式保存长期用户画像，天然支持访问控制、可解释编辑和撤销，但也意味着隐私风险更清晰地暴露出来。真实产品需要用户可见的记忆管理、敏感字段分层、数据最小化策略，以及对 DELETE 操作的严格执行。个性化越深，治理越不能事后补。

用 schema 约束长期画像，只把稳定核心属性写入树，短期细节保留在历史或检索库。

对 agent 工程来说，Inside Out 最值得带走的是一个架构判断：长期记忆应当分成“核心状态”和“历史证据”。PersonaTree 是核心状态，提供低成本、可解释、可持续更新的用户画像；检索历史是证据层，在需要细节时补足上下文。两者配合，才能避免全文拼接的高成本，也避免简单摘要的失真。

这篇论文和 RoleMemo 这类工作也有互补关系。RoleMemo 强调角色如何把事实解释成洞察，Inside Out 强调用户画像如何被结构化维护。前者偏向“解释层”，后者偏向“状态层”。如果把二者结合，长期 agent 可以既维护用户核心属性，又为这些属性保留证据和解释，这会比单纯记事实或单纯写摘要都更强。

最后要记住，Inside Out 不是说树结构万能。它最适合稳定画像、偏好、风格、长期状态这些可压缩信息；对一次性任务、复杂事件链、强时序证据，仍需要检索和版本元数据。真正的复用方式不是照搬 schema，而是照搬它的思想：把长期记忆变成可写、可审计、可训练、可路由使用的状态系统。

如果要把它落到一个真实 agent 产品里，可以先从最小版本做起。第一步定义一个很窄的 schema，只覆盖用户明确允许保存的偏好、沟通风格、长期目标和禁忌事项。第二步让强模型离线生成树操作，并把每次操作保存为日志：旧树、对话块、预测操作、执行后树。第三步给用户提供“查看/删除/纠正记忆”的界面。等这些基础闭环稳定后，再训练小模型接管在线写入。

这个顺序很重要。很多团队会先追求自动化写记忆，但没有 schema、没有执行日志、没有用户纠错入口，最后得到的是一个难以解释的隐形画像系统。Inside Out 的树结构恰好能让产品从一开始就保留管理接口：字段可以展示，操作可以审计，删除可以执行，冲突可以追踪。长期个性化越强，这些接口越不是附属功能，而是安全边界的一部分。

还要注意评估闭环。线下可以用 PersonaMem 这类 benchmark 验证准确率；线上则需要看四类信号：用户是否觉得回复更贴合，错误记忆是否减少，记忆上下文是否真的变短，深召回触发是否合理。尤其是错误记忆率，不能只看总体满意度。一个错误但自信的长期画像，会比一次普通答错更伤害信任。

在多用户或多人协作场景中，PersonaTree 还会遇到权限问题。个人助手可以维护单个用户树，但家庭、团队或社群 agent 可能同时面对多个人。此时每棵树的可见性、共享字段和隔离策略都要明确。用户 A 的偏好不能被错误写进用户 B 的树，群聊里的临时共识也不能直接变成某个人的长期属性。论文没有处理这个问题，但它的 path-based 操作协议为隔离提供了基础。

另一个扩展方向是把树操作和时间线结合。当前论文主要把 UPDATE 视为叶节点字符串重写；真实用户状态有时需要保留演化轨迹，例如“过去喜欢高强度健身，受伤后改为低冲击运动，恢复后逐步增加训练”。这种状态如果只写成当前值，会丢失原因和变化路径；如果保留版本和时间戳，agent 在生成建议时就能更准确地解释“为什么现在这样推荐”。

所以，这篇论文的长期价值不只在某个模型或某个分数，而在于给 agent memory 提供了一个清晰工程范式：先定义可写状态，再训练写入策略，再用路由决定何时读取状态、何时召回证据。 这套范式比“把历史都塞给模型”更像一个能长期运行的系统，也更接近真正可治理的个性化智能体。

它和记忆图、向量库也不是替代关系。向量库擅长从大规模历史里找相似片段，记忆图擅长表示实体和关系，PersonaTree 擅长维护“当前用户状态”。三者可以组成一套更完整的记忆系统：向量库保存原始证据，图结构连接人物、事件和时间，PersonaTree 则保存已经被系统确认、压缩和可用于生成的核心画像。查询时先读树判断用户状态，再用树上的字段去约束图遍历或向量检索，最后把证据回填给生成模型。

这种组合能避免两个极端。只用向量库，系统每次都像重新读档，容易忘记哪些信息已经成为长期状态；只用 PersonaTree，系统又可能缺少具体证据，回答会显得过度概括。Inside Out 的自适应召回其实已经朝这个组合迈了一步：默认使用树，必要时回历史找证据。未来如果把 tree、graph、vector 三层明确化，长期记忆会更稳。

还有一个复用点是“操作日志即训练数据”。每次线上用户纠正记忆时，都可以转成一条监督样本：旧树是什么，用户如何纠正，正确操作应该是什么。长期运行后，系统会自然积累适合自己业务的 MemListener 训练集。这样，记忆模块可以从通用论文数据逐渐进化成领域特定能力，而不是永远依赖一套固定 prompt。

最后，PersonaTree 的可解释性也能反过来改善用户体验。用户不一定想看完整对话历史，但可能愿意看到“系统记住了我偏好简洁回答、晚上不安排高强度任务、旅行时重视预算”。这种可见的记忆比隐形画像更容易建立信任。Inside Out 给出的不是一个完美答案，但它把长期个性化从黑箱摘要推向了可管理状态，这一步非常重要。

把这个思想迁移到 agent skill 系统里也很自然。用户画像树可以换成 skill 状态树：哪些技能已经掌握、适合什么任务、最近失败在哪里、需要淘汰或修订哪些步骤。ADD 可以写入新技能，UPDATE 可以根据执行反馈改写技能说明，DELETE 可以移除失效技能，NO_OP 可以避免把一次偶然成功误认为稳定能力。这样，Inside Out 的价值就不只限于个性化聊天，它也能启发“长期能力状态”如何被结构化维护。

治理上还可以给每个叶节点设置“可见、可编辑、可用于生成、可用于检索、禁止长期保存”等权限标签。这样，同一棵树既能服务个性化，又不会把所有推断都默认暴露给生成模型。对敏感场景来说，这种字段级权限比单纯的全局开关更细，也更符合长期记忆系统的实际风险。

因此，评估这类系统时也应把权限和纠错纳入指标：用户能否发现系统记错了什么，能否删除某条记忆，删除后是否真的不再影响生成。这些问题不在论文主实验里，但会决定长期个性化系统能不能被信任地使用。

换句话说，长期记忆不是越多越好，而是越可治理越好；PersonaTree 的结构化操作，正好让“记住、改正、忘记、解释”这些能力都能进入同一个工程闭环。

这也是它区别于普通摘要记忆的地方：摘要只负责压缩过去，树状态还负责约束未来。

因此它更像长期 agent 的状态机，而不只是资料夹。

这点真的尤其关键。

学习批注

1PersonaTree 是树还是链表？

PersonaTree 本体是树，不是链表。它的节点按 schema 分层组织：树干是生物、心理、社会三类主干，下面再挂具体属性路径，叶节点保存用户当前核心属性的描述性字符串。

容易混淆的是，论文还会保存每次更新后的树版本：

text

T_0 -> T_1 -> T_2 -> ... -> T_N

这条时间上的版本序列看起来像链表，但它串起来的是一棵棵树的快照。每个 T_t 仍然是一棵 PersonaTree。

用户的理解基本准确：生物、心理、社会三个维度下面会有多个可写子维度或叶节点。每个 dialogue chunk 进来时，MemListener 会根据当前 chunk、上一版本树状态和规则约束，生成一组操作，对相关路径做更新。

需要补两点：

一个 chunk 不一定只操作一个子维度。它输出的是操作列表，可能同时更新多个路径。
NO_OP 通常表示这个 chunk 没有稳定核心信息可写，不一定是“对某个子维度执行 NO_OP”。

可以把一次更新理解成：

text

T_{t-1}
+ [
  UPDATE(psychological.preferences.communication_style, "偏好简洁解释"),
  ADD(social.work.role, "产品经理"),
  NO_OP()  // 如果没有任何应写信息，则可能只有这一项
]
-> T_t

对于被操作到的叶节点，系统会得到一个最新值；没有被操作到的路径保持上一版本不变。UPDATE 不是简单覆盖一句新话，而是要把仍然有效的旧信息和新信息整合成更准确的当前状态。

所以结构可以这样理解：

text

树：表达用户画像内部结构
叶节点：保存某个属性的当前综合值
操作列表：表达本轮 chunk 对哪些路径产生变化
版本序列：表达整棵树随对话如何演化

PersonaTree 的特点有四个：

层级 schema 约束：字段不是模型随便发明的，而是被生物-心理-社会 schema 限定。
叶节点保存当前状态：叶子不是无限日志，而是对某个属性的压缩描述，例如长期偏好、习惯、状态。
用原子操作更新：新对话不会直接追加到末尾，而是生成 ADD、UPDATE、DELETE、NO_OP 来修改指定路径。
版本化持久化：每次执行操作后保存新树版本，方便审计、回滚和解释“这个字段为什么变了”。

和链表的区别在于：链表主要表达线性时间顺序，适合追加历史；PersonaTree 主要表达结构化用户状态，适合维护“当前这个用户是什么样”。Inside Out 不是要保存每一句历史，而是把重要长期信息压缩进可写、可校验、可演化的树状态。

2历史证据是什么？

历史证据不是 PersonaTree 里的父节点或叶节点本身，而是系统从原始对话历史中重新检索出来的具体片段。

PersonaTree 保存的是压缩后的当前用户状态，例如：

text

用户近期倾向减少高压力社交活动。

但用户如果问“上次我为什么不想参加那个活动？”，只看这条树叶可能不够。系统需要回到历史中找更具体的证据，例如某段对话里用户曾说：

text

那个活动人太多，而且我最近工作压力很大，怕去了更累。

这类原始或近原始的历史片段，就是论文说的历史证据。它的作用是补足树状态没有保存的细节：时间、人物、原因、事件经过、用户当时的表达方式等。

agentic recall 的流程可以理解成：

先用 PersonaTree 判断问题大概属于哪个用户状态范围。
基于这个树状态扩展多个查询。
用这些查询去历史对话库里检索候选片段。
重排、融合成上下文 C。
最后让回复模型基于 [q, T_N, C] 生成回答。

所以树状态负责“往哪里找”，历史证据负责“找到具体凭据”。这也是 Inside Out 不把 PersonaTree 当成完整历史替代品的原因：树适合保存稳定核心画像，证据层适合在需要细节时补回上下文。

3agentic recall 为什么还需要父节点？

叶节点通常保存某个属性的当前综合值，但父节点不是“老旧历史值”。父节点更像路径和类别语义，例如 psychological.preferences、social.relationships、biological.health。它的作用不是提供最新事实，而是告诉系统：这个叶子属于哪类用户状态，应该往哪个方向扩展查询或组织上下文。

快模式下，如果问题只需要稳定画像，读非空叶节点就够了。例如用户问“按我的偏好推荐周末计划”，系统直接使用偏好、作息、兴趣等叶子值即可。

但长尾细节问题经常需要回到历史证据。比如用户问：

text

上次我说不想参加那个活动，是因为什么？

叶节点可能只保存当前状态：

text

social.activities.preference = "近期倾向减少高压力社交活动。"

这个值能说明当前倾向，但不一定包含“上次那件活动”的具体原因、时间、人物和上下文。此时 agentic recall 要回历史里找证据。

父节点/路径在这里有三类作用：

约束召回方向：看到路径属于 social.activities，检索就更该找社交活动、压力、人际互动相关历史，而不是泛泛搜“活动”。
生成扩展查询：树状态可以展开成多个查询，例如“用户最近拒绝社交活动的原因”“用户对高压力活动的长期态度”“用户上次提到活动压力的对话”。
提供语义范围：父节点告诉模型这个叶值属于社会关系、心理偏好还是身体状态，避免把不同类别的记忆混在一起。

所以父节点不是为了保存旧信息，而是为了保存结构语义和检索导航。叶节点回答“当前状态是什么”；父节点/路径回答“这个状态属于哪类问题、该去哪里找证据”。

论文里也把二者分开：PersonaTree 负责结构化长期记忆和查询扩展，历史证据由 agentic recall 并行检索、重排和融合。也就是说，树不是替代历史，而是指导系统更有方向地回到历史。

4树越深会不会丢信息？

PersonaTree 的确会带来信息压缩损失。它不是把完整对话搬进树里，而是把长期有用的信息压缩到固定 schema 下的叶节点。

树越深，字段语义越窄，优点是更可控：

记忆写到哪里更明确。
生成时更容易只读取相关属性。
安全门更容易检查路径和格式。

但代价也很明显：叶节点通常只保存某个属性的当前综合描述，容易丢掉短期细节、事件过程、语气、原因链和时间变化。

例如一个叶节点可能只剩下：

text

用户近期倾向低压力社交活动。

它不一定保留完整历史：是哪次活动、和谁有关、当时为什么拒绝、这个偏好从什么时候开始变化。

论文的解决思路不是让叶节点保存所有东西，而是把记忆分成两层：

PersonaTree：保存稳定或半稳定的核心状态。
历史证据层：需要细节时，通过 agentic recall 回到原始历史里检索证据。

所以 PersonaTree 更像“当前画像索引 + 压缩状态”，不是完整记忆库。论文也承认它适合核心属性，不适合覆盖所有短期事件。

论文未完整展开每个叶节点是否绑定来源指针、时间戳或多版本证据。如果真实系统担心信息丢失，通常需要给叶节点补充 source pointer、时间、置信度或版本记录，让压缩状态能够追溯回具体历史。

5MemListener 具体负责什么？

MemListener 的任务不只是从 ADD / UPDATE / DELETE / NO_OP 里选一个标签，而是输出一组可执行的树操作序列。

每个 dialogue chunk 进来时，它会读三类输入：

当前对话块 D_t。
上一版本树状态 T_{t-1}。
规则集合 R，包括可写路径、值格式、长度预算等约束。

然后它要决定：

这段对话有没有稳定用户记忆值得写入；没有就输出 NO_OP()。
如果要写，应该写到哪个树路径。
使用 ADD、UPDATE 还是 DELETE。
ADD/UPDATE 的值具体是什么；DELETE 通常不需要新值。
如果是 UPDATE，如何把旧值和新信息合成更准确的当前状态。

例如用户说：

text

我以前爱跑步，但最近膝盖不舒服，改成游泳。

MemListener 可能输出：

text

UPDATE(psychological.preferences.exercise, "过去喜欢跑步；近期因膝盖不适，运动偏好转向游泳。")

安全门后续会检查路径、操作类型、值字符串和长度预算是否合法；它更像执行前校验，不负责把语义重新写一遍。

所以 MemListener 是记忆维护模型，不是最终聊天模型。回复模型后面才会使用当前 PersonaTree 和必要证据生成回答。SFT 让它学会合法格式和基本决策，过程奖励 RL 则进一步优化操作类型、路径、值语义和冗余程度。

6快模式会查历史吗？

快模式基本不查询历史对话。它的设计目标就是低延迟、低成本：直接读出当前 PersonaTree 的结构和非空叶节点，把这些压缩后的用户状态拼到用户问题里，然后一次生成回答。

可以把两种模式区分成：

快模式：读 T_N 的非空叶节点，不额外检索历史证据。
agentic recall：基于 T_N 扩展 query，再去历史对话库检索证据、重排、融合。

快模式的输入更像：

text

用户问题 q
+ PersonaTree 当前非空叶节点
-> 一次生成回答

它适合问题主要依赖稳定画像的场景，例如：

text

帮我按我的偏好推荐一个周末计划。

这类问题通常只需要树里的偏好、作息、兴趣、约束，不一定需要回到某一段具体历史对话。

如果问题问的是具体历史原因，例如：

text

上次我为什么不想参加那个活动？

快模式就可能不够，因为原因可能没有完整保存在叶节点里。这时才需要 agentic recall 回到历史证据层检索。论文的部署判断就是：默认快模式；复杂、长尾、需要细节的问题再触发深召回。

7扩展查询是怎么来的？

agentic recall 里的扩展查询，可以理解成把原始问题 q 和当前 PersonaTree T_N 一起作为条件，让系统生成几条更适合检索历史的 query。

更精确地说，论文写的是 expanded queries conditioned on T_N，也就是“由树状态条件化”。这不等于论文明确说“一定把整棵树完整塞进 prompt”，也不等于一定遍历所有叶节点。论文未提及具体的树节点选择策略、prompt 模板和扩展条数。

论文明确说明的流程是：

输入当前用户问题 q 和最终树状态 T_N。
生成多个 conditioned on T_N 的扩展查询。
用这些查询并行检索历史证据。
对候选证据 rerank。
融合成上下文 C，再用 [q, T_N, C] 生成回复。

直觉上，系统会利用 PersonaTree 里的相关用户状态，把短问题改写成更容易命中历史片段的检索语句。原始问题可能是：

text

那件事后来我为什么不想去了？

PersonaTree 里如果有这些状态：

text

social.activities = "近期减少高压力社交活动"
psychological.stress = "工作压力较高时倾向回避额外安排"

系统就可以扩展出几条更具体的检索 query：

用户最近提到不想参加活动的原因
用户关于高压力社交活动的对话
用户工作压力影响活动安排的历史片段
用户拒绝某个活动时提到的人物、时间或原因

这些 query 不是最终答案，而是为了从历史里找证据。不同 query 覆盖不同属性维度：社交活动、压力状态、时间事件、缺失原因。

所以可以说：agentic recall 是“基于整棵 PersonaTree 的当前状态来引导查询扩展”，但论文没有证明它在实现上会无差别读取整棵树。更稳妥的理解是：T_N 提供结构化记忆条件，系统据此生成多条历史检索 query。检索器使用 BGE-M3，重排器使用 BGE-Reranker-Large。

8Overall 是什么指标？

这里的 Overall 不是 precision，也不是检索里的精确率。论文在 PersonaMem 主实验里使用的是 accuracy：回答是否被判定为正确。

可以把它理解成：测试集中有很多个性化问答样本，系统根据长期历史和当前问题生成答案；评测器判断答案是否答对。Overall 就是所有类别合在一起后的总体准确率。

论文还报告七类细分能力：

Recall-Facts：回忆用户事实。
Pref-Rec：基于偏好推荐。
New-Ideas：生成符合用户状态的新想法。
Recall-Reason：回忆原因或动机。
Pref-Evol：理解偏好演化。
Gen-New：生成新的个性化内容。
Recall-User：回忆用户相关信息。

三组 Overall 对应三种不同回复模型，不是三种指标：

text

DeepSeek-V3.1        -> Overall 71.31
Longcat-Flash-Chat   -> Overall 75.38
DeepSeek-R1-0528     -> Overall 76.06

所以这组实验想说明的是：换不同的最终回复模型，PersonaTree-ALL 的总体准确率仍然高于 Only LLM、ALL Dialogue、MemoryOS 等基线。它评的是最终个性化回答质量，不是单独评检索命中率，也不是评 MemListener 生成树操作的 precision。