最近，一篇聚焦Agent Memory的论文引起了业内关注，内容并非普通摘要，而是一次完整的实验复盘——梳理哪些实验切实有效，哪些方向出现偏差，哪些结果虽不理想却极具启发价值。

项目的核心构想其实非常直接：长期运行的Agent，不能仅仅“记住更多内容”，更需学会“治理自身记忆”。

原因十分简单：真实用户会不断发生变化。今天声称喜欢Java，过一段时间可能转向Rust；当前目标是申请PhD，后来决心创业；之前身处奥克兰，之后搬迁至悉尼。用户的偏好、目标、身份、状态，都会随时间推移而演变。

如果Agent仅把所有历史信息一股脑儿堆叠起来，不做任何区分——哪些属于当前状态、哪些属于历史状态、哪些已经过时——那么记忆越多，系统就越容易陷入混乱。正是基于这一判断，HSM-CR框架应运而生。它的目标并非单纯提升检索准确率，而是让Agent Memory具备冲突检测、状态迁移、时间衰减以及生命周期治理能力。

整个研究过程中，先后完成了四轮实验：

四轮实验跑下来，最深刻的体会是：做Agent Memory，最难的并非把系统搭建起来，而是搞清楚——你到底在评估什么能力。

下面逐一记录这四轮实验踩过的坑，以及每轮带来的宝贵教训。

一、为什么Agent Memory不只是“向量库+RAG”？

很多人一提到Agent Memory，第一反应就是把历史对话存入向量库，需要时再检索出来。这固然是memory的一种形式，但远远不够。

向量库解决的是“查找相似内容”的问题，但它无法判断“状态是否仍然有效”。用户三个月前说“我喜欢Java”，今天说“我现在主要写Rust”，向量检索可能同时找出两条记录——那么Agent该相信哪一条？

去年想申请PhD，今年决定创业，Agent是否还应该继续推荐导师和研究计划？以前住在奥克兰，现在搬到悉尼，Agent是否仍依据奥克兰的生活信息提供建议？

这并非检索问题，而是治理问题。长期Agent真正需要的能力清单包括：识别冲突、判断当前状态、保留历史状态、降低过时信息权重、必要时遗忘、以及在回答时避免引用过时记忆。这就是HSM-CR存在的理由。

二、第一轮：PAB v2——合成数据是系统开发的起点，但不是终点

第一轮实验选用了PAB v2。这是一个合成benchmark，包含20个场景、474个会话，覆盖偏好变化、目标演变、事实冲突、长周期对话等情境。它的作用非常明确：验证HSM-CR的完整pipeline能否顺利跑通。

整个流程包括四个关键环节：extract（从对话中抽取记忆）、score（计算记忆的重要性、置信度、时间新鲜度）、resolve（检测并处理冲突）、forget（对低显著性、过时的记忆实施遗忘或降级）。

在PAB v2及后续扩展实验中，陆续对比了几类基线：Latest-Wins、VM-LLM、Vector Memory、Hierarchical Memory、Full Context/Sliding Window。结果显示，HSM-CR在冲突检测、状态治理、active memory一致性等指标上表现良好。

这轮实验最重要的收获是：合成数据非常适合系统早期开发。因为可以精准控制变量——冲突何时发生、旧记忆与新记忆之间是否真正矛盾、两条记忆的置信度差多少、时间间隔多大、应该降级旧记忆还是忽略新记忆。这类控制在真实对话数据里几乎不可能实现。

PAB v2也确认了一个关键设计：双向仲裁至关重要。许多简单系统默认遵循latest-wins原则，认为“后来的信息一定覆盖前面的”。但真实世界并非如此。有时新信息确实应该替换旧信息，比如用户明确表示从Java转向Rust。但有时新信息只是噪声、误解或上下文切换，不能盲目覆盖。此时系统应保留更可靠的旧状态，忽略低置信度的新记忆。因此，HSM-CR中的downgrade和ignore，实际上是区分系统是否真正实现“记忆治理”的关键。

不过，PAB v2也暴露了一个问题：合成数据获胜，不代表真实世界同样获胜。合成数据中的冲突模式通常比较清晰，比如Java vs Rust、PhD vs startup这类直接对立。但真实对话中的偏好变化往往非常隐晦，可能是叙事性的、渐进式的，甚至模棱两可的。PAB v2证明的是“机制有效”，但无法单独证明“该系统在真实长期对话中一定有效”——这也是评审人必然会追问的问题。

三、第二轮：LoCoMo——真实时间数据能验证遗忘，但冲突注入需谨慎

第二轮实验转移到LoCoMo。LoCoMo是真实长对话数据，其最大价值在于具有真实的multi-session和时间跨度。用它验证两件事：第一，时间衰减和遗忘机制是否合理；第二，完整conflict pipeline能否在真实时间数据上跑通。

在τ forgetting sweep实验中，发现默认阈值τ=0.20的行为比较合理：系统仅遗忘了29条记忆，占2541条记忆的很小比例，而且这些被遗忘的记忆均来自较早的时间段，没有误伤近期记忆。这个结果很有说服力——并非在合成时间上验证，而是在真实时间跨度的数据上验证。换句话说，HSM-CR的遗忘机制不是简单地“删掉一些内容”，而是倾向于处理那些时间上更陈旧、显著性更低的记忆。

随后进行了controlled conflict injection。由于LoCoMo原始数据中没有密集的冲突标注，因此构造了30对记忆注入其中：20对是真冲突，10对是非冲突；其中一部分用于测试downgrade，另一部分用于测试ignore。结果是：conflict sensitivity达到100%，non-conflict specificity达到100%，10个downgrade，10个ignore，最终active pool中没有残留注入冲突。

这轮实验的价值在于：它证明了HSM-CR的冲突治理pipeline不仅在PAB v2上能跑通，也能在真实时间戳数据流上顺利运行。

但这一轮也有一个必须诚实面对的问题：冲突注入并非自然冲突。注入的Java/Rust、PhD/startup这类词对，本身可能恰好落在规则检测器能处理的范围内。如果不小心，容易产生循环论证——设计一套规则，又注入这套规则能够轻易识别的冲突，然后证明系统识别得很好。因此，这轮实验不能被包装成“真实世界冲突全面验证”，更准确的定位应是“在真实时间数据基底上的受控pipeline验证”。它能证明系统链路通畅，双向仲裁有效，但还不能完全替代自然冲突标注数据。这个边界必须诚实，否则以后投稿更高质量会议或期刊时，容易被审稿人抓住漏洞。

四、第三轮：LongMemEval——好数据集不等于适合你的系统

第三轮尝试了LongMemEval。起初觉得它非常契合——长期记忆benchmark，看起来和Agent Memory很接近，规模和出处都不错。于是编写了adapter和runner，并跑了实验。

但跑完之后，意识到方向错了。LongMemEval主要评估的是长期记忆中的检索能力，简单来说，它更关注：系统能否从大量历史信息里找回正确答案。这固然是重要能力，但与HSM-CR的核心能力并不完全匹配。

HSM-CR的目标不是做一个更强的retrieval system，而是解决：旧状态与新状态冲突时，谁该覆盖谁；哪些记忆应该保持active；哪些记忆应该转为historical；哪些记忆已经stale；如何避免Agent同时相信两个互相矛盾的用户状态。换句话说，LongMemEval测试的是“找得准不准”，而HSM-CR解决的是“状态管得对不对”。

这轮实验最大的教训是：不要因为一个benchmark看起来规模大、出处好，就默认它适合你的系统。选择数据集前，必须先问一个问题：这个benchmark测试的能力，真的是我的系统要解决的能力吗？如果答案是否定的，实验跑得越完整，可能越浪费时间。这次损失了几个小时编写adapter和runner，事后反思，如果在调研阶段多花30分钟仔细查看数据结构和评测目标，完全可以避免。

五、第四轮：PersonaMem——QA准确率虽未获胜，但token成本提供了另一视角

第四轮探索了PersonaMem，这是最为彻底的一轮实验。做了两条路径：第一条是32K context场景（短上下文），第二条是1M context场景（极长上下文）。先看短上下文中HSM-CR是否能超越full context，再看极长上下文中，当full context已不可行时，结构化记忆是否能发挥作用。

Path A（32K，共589个实例）的结果是：HSM-CR 60.4% vs Full Context 70.1%。HSM-CR落败，差距接近10个百分点。这个结果并不意外——在上下文能容纳的情况下，原始对话本身就是信息最完整的表示，结构化记忆会压缩信息，而压缩必然导致信息丢失。

Path B（1M，共2674个实例）的结果是：HSM-CR 45.7% vs Sliding Window 46.7%。所有实例均超过128K tokens，全量上下文已不可行，只能使用Sliding Window这类截断方法作为基线。HSM-CR仍然略微落后1个百分点。

这里所说的“输了”，仅指在QA accuracy维度上失利，并不代表memory governance这个方向失败。单看QA accuracy，这轮实验的结果确实不够亮眼。但如果只关注准确率，也不全面——HSM-CR和Sliding Window的输入方式截然不同。

Sliding Window的思路是：尽可能保留最近的一大段原始上下文，优势是信息损失少，缺点是token消耗高，长对话越长，推理成本和上下文压力越明显。HSM-CR的思路是：先将长对话压缩成结构化记忆，再从记忆池中选取少量相关memory参与回答，优势是上下文更短、长期运行成本更可控，缺点是抽取和检索会带来信息损失。

因此，Path B的结果可以从另一个角度解读：HSM-CR在QA accuracy上仅低1个百分点，但它提供了一种不同的trade-off——不是把更多原始上下文塞入模型，而是尝试用结构化记忆压缩长期历史。当然，需要诚实说明：如果没有完整的token日志，无法直接断言HSM-CR节省了多少token。更准确的说法是，从机制上看，它具备更低token输入成本的潜力。后续若要将这个观点讲扎实，需要补充平均input tokens、P95 tokens、token reduction ratio等统计指标。

所以，PersonaMem第四轮实验并非简单的失败，而是揭示了一个更真实的权衡：Full Context/Sliding Window更像是“用token换取准确率”；HSM-CR更像是“用结构化记忆换取token效率”。问题在于，当前HSM-CR的结构化记忆质量还不够高。它的RuleBasedExtractor覆盖范围有限，只能捕获许多“宣布性”的表达，例如“I prefer X”、“My goal is Y”、“I no longer use Z”。但PersonaMem中的大量偏好信息并非以这种方式表达，而是隐藏在叙事中。用户可能不会直接说“I prefer quiet restaurants”，只是多次提到自己不喜欢吵闹的环境，或者描述某次经历。这类信息需要更强的叙事理解、事件抽取和偏好归纳能力，而非简单的trigger pattern。

第二个问题是top-k retrieval设置过紧。假设一个用户拥有580条记忆，而系统只取top-5，这不足1%。如果一个问题需要多条因果链共同支撑，关键信息很容易散落在多个memory item中，进而被top-k截断遗漏。这轮实验真正说明的是：HSM-CR的token效率方向具有价值，但当前的信息抽取和检索能力还不够强大，导致压缩后的记忆未能充分保留回答QA所需的信息。这比“单纯输了”更为准确。

若未来将RuleBasedExtractor升级为LLM-based extractor，将top-k retrieval升级为episode-level/graph-based retrieval，HSM-CR有机会在保持低token成本的同时，进一步缩小甚至反超Sliding Window。因此，PersonaMem带来的教训并非“结构化记忆无用”，而是“结构化记忆要想在QA benchmark上获胜，必须同时解决两个问题：高质量抽取 + 高召回检索”。

但最重要的教训还不止于这些工程问题，而是评估维度的问题。PersonaMem本质上仍是QA accuracy评估，它关注的是“你能否回答对问题”，而HSM-CR的核心价值在于“你能否治理好记忆状态”。这两者固然有关联，但并非同一回事。如果用QA accuracy来衡量HSM-CR，就像用尺子称重——不是尺子没用，也不是重量不重要，而是工具与目标不匹配。HSM-CR可能让active memory更一致，减少过时状态干扰，保留历史lineage，使Agent不被矛盾记忆污染，但这些能力未必会直接转化为普通QA benchmark上的准确率提升。

这轮实验让人更加确信：Agent Memory需要建立自己的评估体系。同时也多少找回了一点面子：HSM-CR虽然在QA accuracy上略微逊色，但它证明了结构化记忆在token成本控制方面的潜力。真正的问题并非结构化记忆方向错误，而是当前版本的抽取器和检索器还不够强大。

六、四轮实验小结

回顾来看，四轮实验实际上形成了一个完整的认知闭环。PAB v2告诉我们：合成benchmark是必要的，因为真实数据很少具备密集的状态迁移标注。LoCoMo告诉我们：真实时间数据很重要，但必须诚实地区分自然冲突与控制注入。LongMemEval告诉我们：长期记忆benchmark不一定适合评估记忆治理。PersonaMem告诉我们：QA准确率并非Agent Memory治理能力的唯一尺度；同时，token成本、推理延迟、长期运行成本，也应成为长期记忆系统的重要评估指标。

最终沉淀下来的核心结论是：HSM-CR不是一个通用检索优化器，而是一个memory governance framework。因此，它不应仅用普通retrieval accuracy或QA accuracy来衡量。更合适的指标应该包括：active memory contradiction rate、current-state consistency、stale memory usage rate、lifecycle transition precision、downgrade regret、historical awareness、response consistency under state change、token cost/latency/long-term running cost。这些指标关注的是：这个Agent是否清楚什么是当前事实、什么是历史事实、什么应该遗忘、什么应该保留，以及在长期运行中是否足够高效——这才是长期Agent Memory真正困难的所在。

七、未来真正需要的benchmark

经过这几轮实验，越来越觉得Agent Memory领域仍缺少一种合适的benchmark。它不应该只问“你能否从长上下文中找出答案”，还应该问“当用户状态发生变化时，你能否正确更新记忆”。

它应该具备：长时间跨度、多轮对话、用户偏好变化、目标演化、身份状态更新、明确的current/historical/stale标注、下游回答一致性评估、token成本与延迟统计。

理想情况下，它还应该同时评估两类能力。第一类是治理正确性：旧记忆是否被正确降级，新记忆是否被正确激活，低置信度冲突是否被忽略，active memory是否无矛盾，stale memory是否被正确抑制或遗忘。第二类是下游有效性：Agent回答是否符合当前状态，是否错误引用过时信息，是否能在必要时利用历史信息，是否能解释状态变化过程，是否能在较低token成本下保持稳定表现。只有这样，才能真正评估长期Agent Memory。

八、最后：失败实验不是浪费，而是在帮你定义问题

这四轮实验中，并非每一轮都收获了“漂亮结果”。LongMemEval未能成为主实验，PersonaMem的QA准确率也未能获胜，LoCoMo的冲突实验仍然只是controlled injection，PAB v2也存在synthetic benchmark的天然局限。但这些实验都不是浪费——它们让人逐渐认清：到底在解决什么问题，什么指标能够衡量这个问题，什么benchmark其实并不适合这个问题。

做研究最怕的不是实验失败，而是不知道失败说明了什么。这次做Agent Memory最大的收获是：长期记忆的关键，不是“记得更多”，而是“知道如何改变”。Agent Memory的下一步，也许不单单是更大的上下文窗口、更强的向量检索、更长的历史存储，而是一个更底层的问题：Agent如何管理不断变化的用户状态？这，可能才是长期Agent真正走向成熟的关键。