DyadMem: 智能体与用户协作的长期记忆基准

1. 问题与价值

这篇论文解决的是长期记忆智能体评测中一个被忽略的问题：现有基准主要关注“用户是什么样的人”，即用户画像、偏好、事实等用户侧记忆，却很少显式建模“这个特定智能体应该如何与这个特定用户协作”的关系侧记忆。论文把后者命名为 User-conditioned Relational Agent Memory，简称 URAM。

为什么重要：长期智能体不只是要记住用户喜欢什么，还要记住用户曾经纠正过它的输出方式、约定过的协作流程、以及从反复失败中总结出的针对该用户的判断规则。如果只存用户画像，智能体在换一个用户时可能行为正确，但在同一个用户的长期关系中会反复犯同样的协作错误。

谁受益、怎么受益：

• 长期个人助理类产品，可以通过 URAM 明确存储“该用户要求我先给结论”“该用户要求周报先列数字再写文字”等规则，减少重复纠正。
• 记忆系统研究者，可以用这个基准分别定位 Capture、Update、Recall、QA 四个阶段的失败，而不是只看最终问答准确率。
• 多智能体脚手架开发者，可以把 URAM 作为一种显式的“关系状态”存储格式，避免把用户偏好和智能体行为规则混在一起。

2. 已有工作的不足

在本文之前，相关工作大致分三条线。

第一条是用户记忆基准，代表有 LoCoMo、LongMemEval、PerLTQA、ConvoMem、PersonaMem、Memora、STALE。它们主要监督用户事实、偏好、画像及其随时间的变化。不足在于：记忆内容几乎都围绕用户本身，没有显式标注“智能体应该怎样为这个用户工作”。

第二条是智能体经验记忆，代表有 Agent Workflow Memory、Memp、LongMemEval-V2、MemoryAgentBench、Mem2ActBench。它们提取可跨任务复用的工作流、环境知识、失败模式。不足在于：这些经验是跨用户通用的，不区分“对用户 A 应该这样做”和“对用户 B 应该那样做”。

第三条是生命周期评测，代表有 AMemGym、HaluMem、MemOps、Memora、MemProbe。它们开始暴露记忆的写入、读取、更新、幻觉等阶段。不足在于：没有在同一批多会话轨迹上，同时为“用户侧记忆”和“关系侧智能体记忆”提供完整的 Capture、Update、Recall 监督。

论文用 Table 1 对比了这些工作。关键差异是：DyadMem 同时具备用户侧记忆、用户条件化智能体记忆、逐会话金标记忆、金标生命周期操作、查询到记忆库的支持集链接，而此前工作最多只覆盖其中一部分。

3. 重建作者的思考路径

从旧方法出发，我会先看到这样一个具体问题：LoCoMo 和 LongMemEval 已经能评测“模型是否记住了用户说过的话”，但它们把最终 QA 作为主要指标。一个明显漏洞是，模型可能没有真正维护记忆库，只是靠长上下文把整段历史塞进去回答问题。于是自然会想到：把记忆过程拆开，分别评测“提取了什么”“更新了什么”“检索了什么”。

撞上的第一个矛盾是：如果只拆阶段，但没有金标记忆条目，就无法判断 Capture 是否漏提。于是需要为每个会话标注应该提取哪些记忆。这里会出现一个选择：是先写记忆条目，再围绕条目生成对话；还是先生成对话，再从对话中标注记忆。如果先写记忆再生成对话，对话会像在念记忆卡片，不自然。所以更合理的是 dialogue-first，即先生成完整多会话对话，再回放对话标注记忆。

第二个矛盾是：如果只标注用户侧记忆，很多对话中真正影响后续行为的其实是“用户对智能体工作方式的纠正”。例如用户说“以后先给结论”“不要每次都用项目符号”。这些内容既不是用户画像，也不是跨用户通用经验。如果硬塞进用户偏好，会丢失“这是对智能体行为的要求”这一层含义。于是需要新增一类记忆，专门描述“这个智能体与这个用户之间的协作规则”。

第三个矛盾是：即使有了 URAM，如果评测仍然只看最终 QA，一个模型可能 Capture 漏掉一半、Update 乱删记忆，但回答时靠模型自身常识或长上下文猜对答案。这样分数高但记忆系统不可用。于是需要把 Gold-Memory QA 和 Full-Pipeline QA 分开。Gold-Memory QA 直接给金标支持记忆，衡量“有证据时会不会答”；Full-Pipeline QA 让模型自己建库、检索、回答，衡量“完整记忆管线行不行”。两者之差就是管线损失。

第四个矛盾是：Update 如果和 Capture 串在一起，模型 Capture 错了，Update 也跟着错，无法判断 Update 本身能力。于是需要 gold-conditioned standalone Update，即给模型金标前序记忆库和金标当前会话 Capture，只让它做增删决策。这样就把上游错误隔离掉了。

与论文实际路径的差异：我猜测的路径是先拆阶段，再补金标，最后引入 URAM。论文实际路径更强调“dual-domain”从一开始就是核心动机，即用户侧记忆和关系侧智能体记忆必须联合标注在同一条轨迹上。此外，论文在数据构造上引入了大量约束，例如闲聊必须占约 15% 且不能泄露可提取事实、记忆演化必须跨会话、agent_knowledge 必须到第三会话以后才能出现。这些约束更像是为了制造困难样本而预先设计的，而不是我在推理中会自然想到的。

4. 核心 intuition

可以把 URAM 类比成“一个老员工和一位特定老板之间形成的私人工作默契”。

用户画像是老板的公开履历：他是什么职位、喜欢什么、有什么习惯。通用智能体经验是公司培训手册：任何员工都该遵守的流程。而 URAM 是这位老员工在长期配合中形成的私人笔记：老板讨厌邮件里先寒暄，所以每次直接给结论；老板在周会上容易跑题，所以会前先发议程；老板说“随便看看”时其实是要完整方案。

这个类比对应机制如下：agent_identity 是老板明确提出的长期要求，相当于“以后都这样”；agent_method 是员工在反复执行中形成的可复用流程，相当于“这类任务我先做 X 再做 Y”；agent_knowledge 是员工从多次失败中总结出的判断规则，相当于“这个老板说‘没问题’时往往还有顾虑”。这些记忆只有放在“这个员工 + 这个老板”的关系里才有意义，换一个老板就不一定成立。论文的核心直觉是：如果只存用户画像和通用经验，就等于让一个新人每次重新摸索老板的私人默契；而 URAM 让智能体把这种默契显式存下来。

5. 方法 pipeline 举例

假设有一个三会话的简单 episode，用户是海鲜过敏者，智能体是餐饮建议助手。

输入 episode 结构：

• Session 1，时间锚点 2026-01-06，用户说：“我下周去柏林开会，会议晚宴在一家海鲜餐厅，帮我看看怎么办。” 智能体回答：“不建议去，除非餐厅能单独准备无海鲜餐。你可以发邮件问主办方。” 用户说：“以后过敏相关的问题先给结论，别铺垫。”
• Session 2，时间锚点 2026-01-13，用户说：“柏林那家餐厅回复说可以单独做，但我还是紧张。” 智能体说：“那就带好过敏卡，点餐时用德语脚本确认。” 用户说：“这个脚本很好，以后餐厅问题都给我能直接念的句子。”
• Session 3，时间锚点 2026-01-20，用户说：“我最近肠胃炎，只能吃清淡的。” 智能体说：“那这几天先推荐粥和蔬菜汤。”

完整流程如下。

第一步，Capture。对每个会话逐轮提取记忆。Session 1 可能提取出：

• user_profile：用户对海鲜过敏。
• fact：会议在柏林。
• agent_identity：过敏相关问题先给结论。
• episodic：用户询问海鲜餐厅晚宴是否安全。

Session 2 可能提取出：

• agent_identity：餐厅问题给可直接念出的脚本。
• episodic：柏林餐厅同意单独准备无海鲜餐。

Session 3 可能提取出：

• user_profile：用户当前肠胃炎，需要清淡饮食。
• episodic：用户报告肠胃炎。

第二步，Update。回放会话，维护记忆库。Session 1 后，记忆库包含上述 Session 1 条目。Session 2 后，新增脚本规则，没有删除。Session 3 后，新增肠胃炎状态。这里可能出现一个更新：如果之前有“用户喜欢辛辣食物”的记忆，而 Session 3 用户说肠胃炎需要清淡，那么 Update 不应删除“喜欢辛辣食物”，而应新增一个临时状态“当前需要清淡饮食”。论文强调临时限制不应反转稳定偏好。

第三步，Recall。假设有一个 QA 查询：“用户当前应该吃什么？” 金标支持集可能包含 user_profile 的“当前肠胃炎需要清淡饮食”和 agent_identity 的“过敏问题先给结论”。Recall 需要从终端记忆库中选出这些条目。如果模型只检索到“海鲜过敏”而漏掉“肠胃炎”，就会答错。

第四步，QA。Gold-Memory QA 直接给模型上述金标支持条目，模型回答：“推荐粥和蔬菜汤，避免海鲜和辛辣。” Full-Pipeline QA 则让模型从自己构建的记忆库中检索最多 16 条，再回答。如果模型 Capture 时漏掉了“肠胃炎”，Full-Pipeline 可能回答：“推荐清淡的海鲜粥”，这就错了。

6. 核心数学推导

论文的核心公式之一是记忆库状态转移。

先解释符号：

• B⋆t 表示第 t 个会话之后的金标记忆库状态，也就是此时仍然有效的记忆条目集合。
• B⋆t−1 表示前一个会话之后的金标记忆库。
• C⋆t 表示第 t 个会话中应该被 Capture 出来的金标记忆条目。
• L⋆t 表示第 t 个会话中应该从旧记忆库删除的金标条目。
• A⋆t 表示第 t 个会话中应该新增的金标条目。
• Dedup 表示去重操作，当两个条目具有相同记忆键时，保留最后出现的那个。

状态转移公式原文为：

B⋆t = Dedup( (B⋆t−1 ∪ C⋆t) \ L⋆t ∪ A⋆t )

推导过程：

第一步，把当前会话 Capture 到的条目并入旧记忆库，得到 B⋆t−1 ∪ C⋆t。这一步表示“先把这次会话中出现的所有候选长期信息加进来”。

第二步，从合并结果中删除被金标标记为失效的条目，得到 (B⋆t−1 ∪ C⋆t) \ L⋆t。这一步处理显式遗忘、被纠正的旧事实、被新规则取代的旧规则。

第三步，加入新增条目，得到 (B⋆t−1 ∪ C⋆t) \ L⋆t ∪ A⋆t。新增条目可能是全新事实，也可能是取代旧条目的修正版本。

第四步，对整体做 Dedup，防止同一个语义条目因为 Capture 和 Add 重复出现而保留多份。去重键优先用条目索引，没有索引时用内容。

这个公式在计算：一个会话结束后，哪些记忆仍然有效。它是整个 benchmark 金标记忆库构建的基础。后续 Recall 只能从终端记忆库 B⋆T 中选条目，QA 也只能使用仍然有效的条目。如果 Update 阶段错误地保留旧值或删除新值，后续 Recall 和 QA 都会继承这个错误。

另一个核心公式是 Recall@n：

Recall@n = (1/J) * Σ_j |I⋆j ∩ Top_nj(Îj)| / nj

符号解释：

• J 是 QA 问题总数。
• I⋆j 是第 j 个问题的金标支持记忆索引集合。
• nj 是 I⋆j 的大小，即该问题需要的金标记忆条数。
• Îj 是模型为第 j 个问题返回的有序记忆索引列表。
• Top_nj(Îj) 表示取模型返回列表的前 nj 个。
• 竖线表示集合元素个数。

这个公式在计算：模型返回的前 nj 条记忆中，有多大比例是金标支持记忆。它惩罚“检索到很多相关但不完整的条目”，因为即使模型返回了 16 条，如果金标只有 3 条，只取前 3 条来算命中。这样就能区分“找到一条相关记忆”和“找全所有必要证据”。

7. 实验设计

数据集：

• 3,065 个 episodes，50,961 个 sessions，61,210 个 QA 实例。
• 5 个生活领域，25 个子领域。
• 用户中心 1,532 个 episodes，智能体中心 1,533 个 episodes。
• 6 类记忆：user_profile、fact、agent_identity、agent_method、agent_knowledge、episodic。

基线模型：

• 16 个开放权重模型，包括 Qwen3 系列、Qwen3.5 系列、Qwen3.8、Llama-3.1、DeepSeek-V4-Pro、GLM-5.2、Kimi-K3、MiniMax-M2.5、GPT-OSS-120B。
• 4 个专有模型，包括 GPT-4o-mini、GPT-5.6-Sol、Gemini-3.1-Pro、Doubao-Seed-2.1-Pro。

指标：

• Capture：微平均 Precision、Recall、F1。
• Update：操作级 F1，即 Add F1 和 Delete F1 的宏平均；另有 unsafe-deletion rate。
• Recall：Recall@n、Recall@n+4、Recall@All、Precision、Hit@1。
• QA：Gold-Memory QA、Full-Pipeline QA、Grounded accuracy、Over-abstention、Ungrounded-correct。
• Gold-to-Pipeline gap：Acc_gold - Acc_pipe。

消融：

• 受控 URAM 对比：在 500 个 agent-centric episodes 上，比较“用户条件化记忆”和“仅通用智能体记忆”两种变体。两者都读同样的用户和助手对话，但前者允许提取 user_profile、fact 和三类 URAM，后者只允许提取三类通用智能体记忆。结果显示所有 20 个模型在 Update 上都有正收益，17 个模型在 URAM-only QA 上有正收益。
• 用户中心与智能体中心对比：用户中心 QA 平均比智能体中心低 14.8 个百分点，但 Capture 和 Recall 差距只有 3.4 和 0.9 个百分点。
• 记忆类型对比：agent_identity 和 agent_method 的 Capture F1 约 50%，fact 约 25%，episodic 约 16%。
• 检索器对比：BGE-M3 dense、bge-reranker-base、bge-reranker-large、bge-reranker-v2-m3 与模型自选对比。

实验能否支撑结论：

• 能支撑“最终 QA 会掩盖管线失败”这一结论。Gold-Memory QA 平均 90.6%，Full-Pipeline QA 平均 47.7%，差距 42.9 个百分点。
• 能支撑“Capture 是系统瓶颈之一”。开放权重模型平均 Capture recall 只有 15.1%。
• 能支撑“Update 不安全”。平均 unsafe-deletion rate 为 84.1%。
• 能支撑“URAM 有效”。受控对比中所有模型 Update 都有正收益。

缺少的内容：

• 没有报告人类在 Full-Pipeline QA 上的上限，难以判断 47.7% 到 90.6% 之间有多少是任务本身难度，有多少是模型能力不足。
• 没有分析不同会话长度下各阶段指标的衰减曲线。
• 没有报告 Capture 和 Update 的错误类型分布，例如漏提是因为对话隐含还是因为模型输出格式错误。
• 没有给出一个简单的“全流程记忆系统”基线，例如用固定规则做 Capture 和 Update，只用 LLM 做 QA。这样无法判断 LLM 在 Capture 和 Update 上的失败是否可以通过非 LLM 方法廉价解决。

8. take-aways

• 在 DyadMem 上，开放权重模型 Gold-Memory QA 平均 90.6%，但 Full-Pipeline QA 平均只有 47.7%，说明“有证据时会答”和“自己建库后会答”之间存在 42.9 个百分点的差距。
• 开放权重模型平均 Capture recall 只有 15.1%，而 precision 为 54.0%，说明主要问题是系统性漏提，而不是乱存。
• 开放权重模型平均 unsafe-deletion rate 为 84.1%，即每 100 条预测删除中约 84 条是错的，说明删除操作极不可靠。
• 在受控 URAM 对比中，所有 20 个模型在 Update 任务上都因加入用户条件而获得正收益，开放权重模型平均提升 2.78 个百分点 op-F1。
• 用户中心 Full-Pipeline QA 比智能体中心低 14.8 个百分点，但两者 Capture F1 只差 3.4 个百分点，说明用户侧记忆的困难主要在 QA 使用阶段，而不是提取阶段。

9. 最脆弱的假设

最脆弱的假设是：URAM 确实是一个独立于用户画像和通用智能体经验的记忆类别，并且显式建模它能带来下游收益。

如果这个假设不成立，即所谓 URAM 只是用户偏好的另一种写法，或者只是通用智能体经验在特定用户上的实例化，那么论文的核心贡献“dual-domain memory”就退化为一个标注技巧，而不是一个必要的新概念。

论文给出的证据：

• 受控对比显示，加入用户条件后，所有 20 个模型在 Update 上都有正收益，17 个模型在 URAM-only QA 上有正收益。
• 但论文没有直接证明“如果不显式区分 URAM，而只是把用户偏好和智能体行为规则混在同一个记忆库里，性能会显著下降”。
• 也没有证明 URAM 的三类内部划分，即 agent_identity、agent_method、agent_knowledge，在模型行为上确实对应不同的失败模式。论文只报告了 agent_identity 和 agent_method 的 Capture F1 较高，agent_knowledge 较低，但没有说明这种差异是否影响下游 QA。

如果后续工作发现，把 URAM 合并进用户画像或通用经验后，模型性能没有明显下降，那么“关系侧记忆必须单独建模”这一主张就会被削弱。

10. 一周最小复现

目标：复现“Gold-Memory QA 与 Full-Pipeline QA 之间存在巨大差距”这一核心结论。

硬件约束：1 张 24GB 消费级显卡。不能跑 70B 以上模型，所以选择论文中较小的开放权重模型，例如 Qwen3-8B 或 Qwen3.5-9B。如果显存紧张，可以选 Qwen3-4B。

数据规模：不要用全量 3,065 个 episodes。从论文提到的 DyadMem-Simple 中取 100 个 episodes，约 2,000 个 QA 实例。如果数据尚未公开，可以自己构造 20 个三会话 episode，每个 episode 约 15 个 QA，共 300 个 QA。重点是让每个 episode 至少包含一次记忆更新和一次需要多跳检索的问题。

步骤：

1. 用 vLLM 或 llama.cpp 部署 Qwen3-8B，温度设为 0。
2. 实现四个阶段的 prompt：Capture、Update、Recall、QA。直接复用论文附录中的 prompt 结构。
3. 先跑 Gold-Memory QA：对每个问题，把金标支持记忆直接拼进 prompt，让模型回答。用 GPT-5-mini 或本地小模型做语义一致性判断。预期准确率在 85% 到 93% 之间。
4. 再跑 Full-Pipeline QA：按会话顺序让模型自己 Capture 和 Update，构建记忆库。对每个问题，用 BGE-M3 对记忆库做稠密检索，取 top 16，再让模型回答。预期准确率在 35% 到 50% 之间。
5. 计算 Gold-to-Pipeline gap。如果 gap 大于 30 个百分点，就复现了论文的核心发现。
6. 额外跑一个 Capture 评估：把模型 Capture 输出与金标做语义匹配，预期 recall 在 10% 到 20% 之间。

预期指标：Gold-Memory QA 约 88%，Full-Pipeline QA 约 45%，gap 约 43 个百分点，Capture recall 约 15%。这些数字与论文中 Qwen3-8B 的表现接近。

11. 反例设计

设计一个实验，如果成功就能推翻“URAM 是必要的独立记忆类别”这一核心主张。

实验设计：

• 取论文的 500 个 agent-centric episodes，构造三个变体。
• 变体 A：论文的 URAM 变体，允许提取 user_profile、fact、agent_identity、agent_method、agent_knowledge。
• 变体 B：合并变体，不区分用户侧和智能体侧，把所有内容都存成一种统一的 memory 类型，但保留相同的文本内容。
• 变体 C：用户画像变体，把 agent_identity、agent_method、agent_knowledge 全部改写成 user_profile 的形式，例如把“过敏问题先给结论”改写成“用户希望过敏问题先给结论”。

判据：

• 如果变体 B 和变体 C 在 URAM-only QA 上的 Full-Pipeline 准确率与变体 A 没有显著差异，即差距小于 2 个百分点，且 Update op-F1 也没有显著差异，那么说明 URAM 的类型划分本身不带来收益。
• 更强的反例判据：如果变体 C 在用户中心 QA 上反而比变体 A 更好，说明把智能体行为规则并入用户画像不仅无害，还可能因为简化了类型系统而减少分类错误。

如果这个实验成功，论文的核心主张“关系侧智能体记忆必须作为独立域建模”就会被推翻，URAM 将退化为一种可选的标注视角，而不是必要的记忆架构。

12. 落地判断

能否用于“抢占式 GPU 自托管 27B 模型做多智能体脚手架”：可以，但需要改造。

怎么用：

• 把 URAM 作为多智能体脚手架中“用户-智能体关系状态”的存储格式。每个用户-智能体对维护一个独立的 URAM 记忆库，与全局共享的通用智能体经验库分开。
• 在 27B 模型上，例如 Qwen3.5-27B 或 Qwen3.8-27B，可以跑通 Capture、Update、Recall、QA 四阶段。论文中 Qwen3.5-27B 的 Full-Pipeline QA 是 46.96%，Qwen3.8-27B 是 53.81%。
• 对于抢占式 GPU，建议把 Capture 和 Update 做成离线批处理任务，在 GPU 空闲时运行。Recall 和 QA 做成在线服务，因为延迟敏感。
• 记忆库不要无限增长。论文中金标记忆库平均约 323.6 条，而模型自建库中位数只有约 75 条。可以在 27B 模型上设置记忆库上限为 200 到 300 条，超过时触发压缩或遗忘策略。

成本量级：

• 27B 模型在 24GB 显卡上可以量化后运行。以 Qwen3.5-27B 为例，4-bit 量化约需 16GB 显存，剩余显存可以放 BGE-M3 嵌入模型或使用 CPU 做嵌入。
• 每个 episode 的完整四阶段推理成本取决于会话长度。论文中平均每个 episode 约 16.6 个会话，每个会话约 24.8 轮。按 27B 模型每百万 token 约 1 到 3 美元的自托管成本估算，一个 episode 的完整管线成本约在 0.1 到 0.5 美元量级。
• 如果只做增量 Update 和按需 Recall，不做全量回放，成本可以降低一个数量级。

最大的坑：

• 删除不可靠。论文中 27B 级别模型的 unsafe-deletion rate 在 73% 到 81% 之间。如果直接让模型自动删除记忆，会频繁删掉仍然有效的规则。落地时必须加保护：删除操作只允许在显式用户指令或强冲突证据下执行，否则只做软失效标记，不物理删除。
• Capture 漏提严重。27B 模型 Capture recall 约 16%。如果依赖模型自动提取，记忆库会严重不完整。建议用规则或小模型先做候选片段筛选，再用 27B 模型做精提取。
• 用户侧记忆在 QA 阶段更难用。论文显示用户中心 QA 比智能体中心低约 14.8 个百分点。如果脚手架主要处理用户事实类问题，需要额外做检索后验证，避免模型忽略检索到的用户侧证据。

---