文章深入探讨了 AI 助手在长期交互中普遍存在的“记忆失效”问题，指出其根源在于主流 Benchmark 采用静态（Off-Policy）评测，切断了 Agent 与用户间的反馈回路。AMemGym 框架通过模拟真实交互，将评测重点从“复盘历史”转向“主动塑造状态”。实测显示，静态榜单存在明显的“重用偏差”，偏向原生 LLM 和 RAG，而忽视了 Agent 架构在策略驱动记忆方面的优势。此外，文章提出了 Write/Read/Utilization 三阶段诊断体系，并展示了记忆策略自我进化的潜力，强调长期记忆应被视为 Agent 的核心系统策略而非外挂模块。

原创 NLPer 2026-01-30 13:53 江苏

首个面向长对话助手的交互式、在线策略 (On-Policy) 记忆评测框架，揭示了静态评测中的“重用偏差”并支持智能体自我进化。

如果让用户连续使用几周甚至几个月的 AI 助手，几乎一定会遇到这样一种情况：系统在短期内显得“很懂你”，但时间一长，它开始忘记关键偏好，开始重复推荐早就否定过的选项，开始在一些本该稳定的长期信息上反复出错。

而让工程团队困惑的是，当回到线下评测和 Benchmark 时，很多指标看起来又是正常的。RAG 的召回率不错，长上下文模型在技术指标上也站得住脚，长期记忆数据集上的分数也并不低。于是就出现了一种非常典型的错位：线上用户体验在下降，但线下评测却没有明显预警。

这不是某一个模型的问题，而是很多做 Agent、Copilot、个性化助手团队在过去一年里反复踩到的系统性问题。根本原因在于，真实产品里的长期记忆，本质上是一个反馈系统：Agent 的回复会改变用户接下来如何表达信息；用户表达方式的变化，又会影响哪些信息被暴露、以什么粒度被暴露；而这些变化，进一步影响 Agent 后续的记忆与决策。

换句话说，真实长期记忆的难点，不是“能不能读到历史”，而是：能不能在动态交互中，持续构建一个稳定、可用的用户状态模型。

但主流 Benchmark 的设计，恰恰切断了这个反馈回路。你拿到的是一段已经写好的对话历史，让模型去“复盘”并回答问题。这样的评测方式，在工程上非常高效，但它测到的，更像是“在既定轨迹上理解历史”的能力，而不是“在真实交互中主动塑造长期状态”的能力。这就解释了一个很多团队都有的直觉体验：为什么某些系统在 Benchmark 上看起来不错，但一旦进入真实长期交互，长期记忆相关的问题会被系统性放大。

AMemGym 出现的背景，正是为了正面解决这个错位问题。它并不是想再做一个更难的数据集，而是试图把评测本身拉回真实交互闭环，回答一个更底层的问题：如果评测放回实战环境，长期记忆系统的强弱排序，还会不会和静态榜单一样？实测给出的答案是：不会。而且，差异比很多工程团队预期的还要大。

• 📄 Paper: https://openreview.net/forum?id=sfrVLzsmlf

• 💻 GitHub:https://github.com/AGI-Eval-Official/amemgym

• 🌐 Project Page: https://agi-eval-official.github.io/amemgym/

• 📊 HuggingFace Dataset: https://huggingface.co/datasets/AGI-Eval/AMemGym

从“复盘历史”到“实战交互”：评测对象正在发生变化

在静态 Off-Policy 评测中，对话轨迹是预先生成好的，Agent 只是被动读取这些历史并作答。这种评测方式，对模型来说是公平的，但对 Agent 架构来说并不公平。因为 Agent 的核心能力，并不仅仅是读历史，而是能否通过自己的回复，影响信息在对话中以更有利于长期建模的方式暴露出来。

图1：Off-policy vs On-policy 评测对比

AMemGym 的 On-Policy 设计，把这一点放到了台前。在交互式记忆评测中，Agent的每一次记忆操作，都会影响它后续的交互行为以及模拟用户接下来的回复，从而改变对话轨迹本身。这意味着，评测对象不再只是“能不能记住”，而是变成了：是否在交互过程中，构建并维护了正确的长期用户状态。

这也是为什么，在 AMemGym 的实验中，一些在静态评测中表现中等的智能体架构，在实战评测中反而更稳定；而部分依赖固定上下文与检索的系统，在动态环境中开始出现明显退化。这不是模型突然变弱，而是评测终于开始测到“实战能力”。

AMemGym 最容易被忽略、但对工程决策影响最大的结果，其实不是某个模型拿了第几名，而是：同一批系统，在 Off-Policy 与 On-Policy 下，排名发生了系统性变化。

表1：不同系统在 Off-policy 与 On-policy 下的排名对比

从工程视角看，这一点非常关键。因为这意味着，很多团队过去用来做架构决策的静态榜单，本身并不是一个中立的比较环境，而是在结构上更偏向某些类型的系统。在静态评测中，所有系统被强制复用同一段固定对话历史。这会产生一个隐蔽但非常重要的效果：对话路径无法被 Agent 的策略影响，Agent 无法通过追问、确认、总结等方式，主动改变信息在对话中的暴露方式。

这恰恰压制了智能体的核心优势。智能体架构的价值，不在于“读得更快”，而在于能否通过交互策略，规划长期记忆：什么信息值得长期保留，什么时候更新状态，用什么形式写入更利于后续推理。当对话轨迹被锁死，这种能力几乎没有发挥空间。结果就是，静态评测天然更偏向那些行为模式更趋同的系统，例如原生 LLM 或标准 RAG。它们不依赖复杂的交互策略，因此在固定轨迹下损失较小；而真正依赖策略来塑造长期状态的 Agent，在这种设置下反而显得“平平无奇”。

AMemGym 把这种现象明确命名为重用偏差（Reuse Bias）。从工程角度看，这个名字背后对应的是一个非常现实的风险：你可能在用一个对 Agent 不友好的评测环境，来决定是否要采用 Agent 架构。这也是为什么，在 AMemGym 的实战评测中，会看到一种让很多人直觉上感到“反常”的结果：一些在静态榜单中排名靠后的智能体配置，在 On-Policy 环境中反而跃升；而一些依赖固定上下文与检索的 RAG 配置，在真实交互中开始掉队。

这不是因为 RAG 突然不行了，而是因为：当评测开始允许交互策略发挥作用，系统之间的能力差异，才开始真正被放大。对工程团队来说，这一点非常重要。它意味着：如果你的系统最终跑在真实长期交互中，那么你在架构选型阶段，不能只看静态榜单，而必须警惕评测环境本身对不同架构的系统性偏好。

AMemGym 在测什么？本质是在测长期“状态建模能力”

如果把 AMemGym 只理解成一个“更真实的用户模拟器”，其实低估了它的工程含义。从系统角度看，AMemGym 真正测试的，不是模型能不能记住某条事实，而是：在长周期交互中，系统是否能够持续维护一个稳定、可用的用户状态模型。

图2：AMemGym 框架示意

AMemGym 的关键设计，是用结构化状态驱动自由对话。用户的真实状态并不会以结构化字段的形式直接提供给 Agent，而是通过自然语言借模拟用户之口逐步暴露。这迫使系统在交互过程中，自己判断哪些信息是长期重要的，什么时候应该更新状态，应该以什么形式写入记忆，才能在后续对话中持续发挥作用。

从架构角度看，这种设置让评测对象从“存储 + 检索模块”，升级成了“状态建模系统”。系统需要解决的，不再只是如何把信息存进去，而是如何把信息转化为对长期决策有用的内部状态。

AMemGym 的一个非常直观的结果，是原生 LLM 在长期交互中的 Memory Score 随时间明显下降。

图3：原生 LLM 在不同交互时期的记忆表现

这个结果，很容易被误解成“模型不够强”，但从工程视角看，这其实是一个非常合理的架构结果。因为原生 LLM 的长期“记忆”，本质上是通过上下文堆积来实现的。当交互轮次增加，历史信息越来越多，噪声和无关内容不可避免地累积，模型即使理论上能看到所有历史，也很难在长周期内持续聚焦于真正重要的长期状态。换句话说，这不是某个模型不行，而是：把长期记忆等价为长上下文，是一种不可持续的工程解法。

AMemGym 的实验数据恰恰把这一点量化了出来。即便是头部模型，在短期个性化上表现很好，但随着交互周期拉长，长期状态的一致性和可用性仍然明显下降。从架构角度看，这意味着：如果系统希望支持真实长期使用，仅靠扩大 Context Window，很难解决问题，必须引入显式的长期状态管理机制，让系统把长期信息从原始对话中“抽象”出来，而不是被动堆在历史里。

这也是为什么，AMemGym 的结果对 Agentic Memory 架构更友好。因为这类架构，本质上是在维护一个长期状态，而不是一段越来越长的历史文本。

比排行榜更有用的，是这套 Write / Read / Use 诊断信号

如果只看一个总分，很多长期记忆系统的问题，其实很难被工程团队准确定位。AMemGym 引入 Write / Read / Utilization 三阶段拆解，本质上是把“长期记忆”从一个黑盒指标，拆成了一套可 debug 的系统流程。

图4：Write / Read / Utilization 诊断流程

从系统角度看，这三阶段对应的是三个完全不同的工程问题：

• Write（写入）：系统是否在关键信息出现时，正确识别并写入长期状态？

• Read（读取）：已存的长期状态，是否能在合适的时机被准确召回？

• Use（利用）：即使信息被召回，模型是否能在推理阶段正确使用？

AMemGym 的数据非常清楚地表明，不同架构的失败模式是结构性不同的。对于标准 RAG 来说，最常见的问题并不是“完全没记住”，而是随着原始对话不断被写入外部存储，长期下来检索结果越来越碎，噪声比例不断上升。这会直接导致利用阶段失败：模型明明召回了相关内容，但在多个相互干扰的片段中，难以稳定使用真正关键的长期状态。

对于 Agentic Memory 架构来说，问题结构刚好相反。通过压缩与重写，系统能够显著减少冗余信息，从而降低利用失败率，使长期状态更集中、更稳定。但这种压缩也带来了信息有损，导致在某些情况下读取失败略有上升。这是典型的工程 trade-off：你用结构化状态换取长期稳定性，同时承担一定的信息损失风险。

图5 诊断流程与各架构故障率分析

AMemGym 还揭示了一个对检索系统非常实用的工程细节：Top-k 并不是越大越好。Top-k 过大，会引入大量噪声，导致利用失败显著增加；Top-k 过小，则容易导致关键信息未被召回，从而引发读取失败。真正可用的配置，往往需要在召回率与信噪比之间做精细权衡。

从工程视角看，这套诊断体系的价值，在于它让团队不再只围绕“榜单排名”做优化，而是可以有针对性地改系统：是该优化写入策略？还是检索策略？还是推理阶段对记忆的使用方式？这些问题，现在可以被拆解成可操作的工程决策。

记忆策略开始“可学习”：从工程规则，到系统策略

AMemGym 最有前瞻性的部分，并不是排行榜，而是对记忆写入策略自我进化的实验。从工程视角看，这一实验的意义远大于当前分数的提升。

表2：记忆策略自我进化效果对比

在实验中，研究团队让智能体基于不同形式的反馈，自动调整自己的记忆管理 System Prompt。结果显示，写入失败率出现了稳定下降，且记忆策略从模糊的通用描述，逐步演化为更具体、可执行的规则。例如，从“记录用户偏好”，进化为“在教学场景中记录具体教学方法”等。这说明，记忆策略本身可以被视为一种可学习的系统组件，而不仅仅是人工手工配置的工程参数。

对做 Agent 的团队来说，这一点非常重要。它意味着，长期记忆系统未来可能不只是“设计出来的”，而是可以通过真实交互不断被训练和调整。这与当前 Agent 研究中对自我反思、自我优化的整体趋势是高度一致的，也为减少人工调参、降低系统维护成本提供了现实路径。

从更大的系统视角来看，AMemGym 的意义并不在于它给出了一个新的排行榜，而在于它用实验证明了一件很多工程团队已经隐约意识到的事实：评测范式，本身正在决定我们会构建什么样的长期记忆系统。

如果评测长期基于静态对话，那么系统自然会向“更强的长上下文 + 更大的检索库”演化；而当评测切换到真实交互，系统开始向“状态建模 + 策略驱动记忆 + 动态更新”演化。这不是模型好坏的问题，而是目标函数发生了变化。

对做 Agent、Copilot、长期用户建模系统的团队来说，这一点具有直接的架构含义：长期记忆不应该被视为一个外挂模块，而应该被视为 Agent 核心策略的一部分。系统需要回答的，不再只是“怎么存”，而是“怎么建模用户状态，怎么持续更新，怎么在决策中使用”。

总结：长期记忆不是存储问题，而是系统问题

AMemGym 真正重要的地方，不是某个模型在榜单上排第几，而是它用一种更接近真实产品环境的方式，把长期记忆从“存储问题”，重新拉回到“系统问题”。它让我们看到：

• 静态评测并不是中立的

• 评测方式会系统性偏向某些架构

• 长期记忆的核心难点，是状态建模与交互策略，而不是上下文长度或存储规模

对所有正在构建 Agent、RAG、Copilot 与长期个性化系统的团队来说，这篇工作传递出的信号非常清晰：

如果你的系统跑在真实长期交互中，那么你需要的不只是更大的模型或更长的上下文，而是一套能在动态交互中持续维护长期状态的系统架构——以及一套能真实测到这些能力的评测方式。

进技术交流群请添加AINLP小助手微信（id: ainlp2)
请备注具体方向+所用到的相关技术点
关于AINLP
AINLP 是一个有趣有AI的自然语言处理社区，专注于 AI、NLP、机器学习、深度学习、推荐算法等相关技术的分享，主题包括LLM、预训练模型、自动生成、文本摘要、智能问答、聊天机器人、机器翻译、知识图谱、推荐系统、计算广告、招聘信息、求职经验分享等，欢迎关注！加技术交流群请添加AINLP小助手微信(id：ainlp2)，备注工作/研究方向+加群目的。


阅读原文
跳转微信打开