![四个坑.png](https://developer.qcloudimg.com/http-save/yehe-1177371/ea31dab892b0c00ce78788456b961744.png)

最近这段时间，我一直在做一篇关于 Agent Memory 的论文。
这篇文章不是论文摘要，而是一次实验复盘：哪些实验有效，哪些实验走偏，哪些结果不好看但很有启发。
项目的核心想法很简单：
**长期运行的 Agent，不能只是“记住更多”，还要学会“治理记忆”。**
因为真实用户是会变化的。
今天说自己喜欢 Java，过一段时间可能转向 Rust；
现在目标是申请 PhD，后来可能决定创业；
之前人在奥克兰，之后可能搬到悉尼；
某些偏好、目标、身份、状态，都可能随着时间发生变化。
如果 Agent 只是不断把所有历史信息存进去，而不区分哪些是当前状态、哪些是历史状态、哪些已经过时，那么记忆越多，反而越容易混乱。
所以我做了一个框架，叫 HSM-CR。它的目标不是单纯提升检索准确率，而是让 Agent Memory 具备冲突检测、状态迁移、时间衰减和生命周期治理能力。
在这个过程中，我前后做了四轮实验：
1. PAB v2：自己构造的合成数据；
2. LoCoMo：真实长对话数据；
3. LongMemEval：长期记忆评测数据集；
4. PersonaMem：人格记忆与长上下文 QA 数据集。

四轮实验跑下来，最深的感受是：
**做 Agent Memory，最难的不是把系统跑起来，而是搞清楚：你到底在评估什么能力。**
下面记录一下这四轮实验踩过的坑，以及每一轮带来的教训。


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

很多人一提 Agent Memory，就会想到：
>把历史对话存进向量库，需要时检索出来。

这当然是 memory 的一种形式，但还远远不够。
因为向量库解决的是“找相似内容”的问题，不解决“状态是否仍然有效”的问题。
如果用户三个月前说“我喜欢 Java”，今天说“我现在主要写 Rust”，向量检索可能两个都找出来。
那 Agent 应该相信哪个？
如果用户去年想申请 PhD，今年决定创业，Agent 是否应该继续给他推荐导师和 research proposal？
如果用户以前住在奥克兰，现在搬到了悉尼，Agent 是否还应该根据奥克兰生活信息提供建议？
这不是检索问题，而是治理问题。
长期 Agent 真正需要的是：
- 识别冲突；
- 判断当前状态；
- 保留历史状态；
- 降低过时信息权重；
- 在必要时遗忘；
- 在回答时避免引用 stale memory。

这就是我做 HSM-CR 的原因。


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

第一轮实验，我做的是 PAB v2。
这是一个合成 benchmark，包含 20 个场景、474 个 sessions，覆盖偏好变化、目标演化、事实冲突、长周期对话等场景。
它的作用非常明确：验证 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 consistency 等指标上表现很好。
这轮实验最重要的收获是：
**合成数据非常适合系统早期开发。**
因为你可以精准控制变量：
- 冲突什么时候发生；
- 旧记忆和新记忆之间是否真的矛盾；
- 两条记忆的置信度差多少；
- 时间间隔是多少；
- 应该 downgrade 旧记忆，还是 ignore 新记忆。

这类控制在真实对话数据里几乎不可能做到。
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 这类词对，本身可能正好落在规则检测器能处理的范围内。如果不小心，容易产生循环论证：
>我设计了一套规则，又注入了这套规则容易识别的冲突，然后证明系统识别得很好。

所以这轮实验不能被包装成“真实世界冲突全面验证”。
更准确的定位应该是：
>在真实时间数据基底上的 controlled pipeline validation。

它能证明系统链路是通的，双向仲裁是有效的，但还不能完全替代自然冲突标注数据。
这个边界要诚实，否则以后投更高质量会议或期刊时，很容易被审稿人抓住。


----
## 四、第三轮：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%
Full Context：70.1%

HSM-CR 输给了 Full Context，而且差距接近 10 个百分点。
这个结果不意外。因为在上下文能放得下的时候，原始对话本身就是信息最完整的表示。结构化记忆会压缩信息，压缩就会丢信息。
Path B 是 1M，共 2674 个实例。
这时所有实例都超过 128K tokens，全量上下文已经不可行，只能用 Sliding Window 这类截断方法作为基线。
结果是：
>HSM-CR：45.7%
Sliding Window：46.7%

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 第四轮实验并不是简单的失败，而是暴露了一个更真实的 trade-off：
>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|机制验证|双向仲裁有效|合成数据外部有效性有限|
|LoCoMo|真实时间验证|遗忘阈值合理|controlled injection 不能等同自然冲突|
|LongMemEval|benchmark 试错|数据集名气不等于适配|检索评测不等于治理评测|
|PersonaMem|长上下文 QA 压力测试|token 成本有潜力|QA accuracy 不等于记忆治理|
回头看，四轮实验其实形成了一个完整的认识过程。
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 真正走向成熟的关键。
相关代码和实验记录我已经整理到 GitHub：
https://github.com/yuanrengu/hsm-cr 
论文 arXiv 版本准备中，后续会继续更新。

最近这段时间，我一直在做一篇关于 Agent Memory 的论文。这篇文章不是论文摘要，而是一次实验复盘：哪些实验有效，哪些实验走偏，哪些结果不好看但很有启发。项目的核心想法很简单：长期运行的 Agent，不能只是“记住更多”，还要学会“治理记忆”。因为真实用户是会变化的。今天说自己喜欢 Java，过一段时间可能转向 Rust；现在目标是申请 PhD，后来可能决定创业；之前人在奥克兰，之后可能搬到悉尼；某些偏好、目标、身份、状态，都可能随着时间发生变化。如果 Agent 只是不断把所有历史信息存进去，而不区分哪些是当前状态、哪些是历史状态、哪些已经过时，那么记忆越多，反而越容易混乱。所以我做了一个框架，叫 HSM-CR。它的目标不是单纯提升检索准确率，而是让 Agent Memory 具备冲突检测、状态迁移、时间衰减和生命周期治理能力。在这个过程中，我前后做了四轮实验：

我做 Agent Memory 论文时踩过的四个坑：从合成数据到真实长对话

最近这段时间，我一直在做一篇关于 Agent Memory 的论文。项目的核心想法很简单：长期运行的 Agent，不能只是“记住更多”，还要学会“治理记忆”。因为真实用户是会变化的。今天说自己喜欢 Java，过一段时间可能转向 Rust；现在目标是申请 PhD，后来可能决定创业；之前人在奥克兰，之后可能搬到悉尼；某些偏好、目标、身份、状态，都可能随着时间发生变化。如果 Agent 只是不断把所有历

人工智能

职业发展

算法

HSM-CR框架专攻Agent记忆治理，解决用户状态变化时的冲突检测和动态更新问题。通过四轮实验验证其在衰减遗忘、冲突仲裁和状态一致性上的优势，比传统向量库更智能地管理记忆生命周期。关键词：AgentMemory、状态治理、冲突检测、记忆更新、动态管理。

数据结构

压力测试

数据流

GitHub

Agent

Java

2026采购季 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我做 Agent Memory 论文时踩过的四个坑：从合成数据到真实长对话-腾讯云开发者社区-腾讯云

我做 Agent Memory 论文时踩过的四个坑：从合成数据到真实长对话

我做 Agent Memory 论文时踩过的四个坑：从合成数据到真实长对话

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐