Agent运行越久，记忆成本就越高。这是目前所有长期记忆系统都头疼的问题。
哈工大深圳团队在2026年8月发布的LycheeMemory V2给出了一个数据：相比A-Mem，它的构建token用量在LoCoMo基准上降低86%，在LongMemEval-S上降低76%，准确率不降反升。这组数字背后是一个被忽视的工程问题：记忆不是"存得越多越好"，而是"在什么粒度上存"。
图注：LycheeMemory将多轮交互打包成语义段，编码为独立记忆记录，降低构建频率
三种省钱方式都不够好
现有的Agent记忆系统有三种降低成本的方式，但每种都有代价。
第一种是急切合并。每轮对话后调用LLM提取、摘要或更新记忆。效果好，但对话越长成本越高——记忆构建变成了高频LLM操作，token消耗随会话增长线性累积。
第二种是粗粒度摘要。把多轮对话压成一段总结，构建成本低了，但会丢失细粒度证据。用户三周前提到的某个偏好、某次任务中的具体约束，这些细节在摘要中很容易被抹掉。长期记忆的问题往往依赖这种细节——实体、时间表达、共指关系、小的上下文线索。
第三种是把成本挪到查询时。检索时扩大top-k范围或用LLM做多跳搜索。查询质量上去了，但token开销从构建端转移到了检索端，总成本没降，反而增加了延迟。
LycheeMemory V2的核心思路是换一个合并粒度。它不用每轮合并，也不用粗摘要，而是把多轮交互打包成语义段，在每个段完成后才编码一次。语义边界检测帮助保留连贯的事件级和时间证据，相比固定窗口的分批，更不容易把一个完整事件切两半。
段级编码与结构化检索
LycheeMemory V2的编码流程是这样的：在线语义分段先把对话流切成语义连贯的段，每段完成后编码为上下文无关的类型化记忆记录。这些记录带有语义、时间、主题和实体标签，用轻量级结构化索引组织。
检索时不是简单的向量top-k。系统先做查询规划，根据问题类型决定走哪条检索路径。单跳问题走单跳路径，多跳问题走多跳路径，时间相关问题走时间索引。这种多路由检索避免了"语义相近但当前不该用"的记忆混入上下文。
数据说明这个设计是有效的。在LoCoMo基准上，LycheeMemory V2达到89.22%准确率；在LongMemEval-S上达到92.20%。与之对比，A-Mem在相同基准上的构建token用量高出数倍。
更关键的是消融实验的结论：记忆的准确率-成本权衡不仅取决于保留什么信息，还取决于在什么粒度上合并。每轮合并太贵，整段摘要太粗，语义段级恰好是成本和信息保真度之间的平衡点。
图注：LycheeMemory V2在LoCoMo上构建token仅154K，比A-Mem降低86%
记忆不只是存下来
公众号"七牛开发者"在2026年8月发布的一篇工程实践中，梳理了Agent记忆的完整生命周期：交互内容到候选记忆到写入到活跃记忆到检索使用到更新失效到衰减合并到归档删除。
这个生命周期里最容易出问题的是写入边界。只要系统不断追加"以后可能有用"的信息，临时状态、重复事实和未经验证的推断就会混入长期存储。等这些内容积累到一定规模，检索和排序再复杂，也只能在被污染的数据中筛选。
另一个问题是状态更新。如果项目从Node.js 20升级到Node.js 22，append-only的记忆会让两个版本同时存在。直接覆盖旧值能保证当前状态一致，却丢失了版本变化的历史。更好的做法是保留版本记录和有效时间：旧记录标记为superseded并退出默认检索，但保留可追溯的历史。
检索也需要分层。Core Memory长期占用上下文预算，保证关键状态始终可见；Searchable Memory按需检索；Evidence Archive默认不进入推理链，只在追溯验证时使用。如果所有记忆都堆在一个向量库里做top-k，"语义相近"和"当前可用"就混在了一起。
源势AI怎么看
我们在企业Agent部署中，记忆系统是返工率最高的模块。客户反馈最多的问题不是"Agent记不住"，而是"Agent记住了不该记的东西"。
LycheeMemory V2的语义段级合并解决了一个实际问题：企业场景中，Agent的对话往往很长，但并非每轮都有价值。一个客服Agent可能跟用户聊了20轮，真正值得记住的可能只有3到4轮里的用户偏好和问题结论。如果每轮都调LLM做记忆提取，成本不可接受；如果只做粗摘要，关键细节又丢了。语义段级合并在这里找到了一个务实的平衡。
但我们实践中发现，纯技术优化解决不了全部问题。记忆系统的根本挑战是治理而非存储：谁决定一条信息该写入？写入后谁负责维护它的有效性？当新旧信息冲突时，按什么优先级裁决？
这些问题在企业场景中需要明确的规则。我们给客户做Agent记忆系统时，会先定义信息来源的优先级：工具检测结果大于用户明确确认大于Agent归纳推断。低置信度的推断不能覆盖已验证的事实。这跟LycheeMemory的结构化索引是互补的——技术解决"怎么存得省"，治理解决"存什么、信什么"。
LycheeMemory V2的86%token降幅意味着，以前因为成本太高而放弃长期记忆的Agent场景，现在可以重新评估了。但记住一点：省下来的token应该用来存更多有价值的信息，而不是让Agent记住更多噪音。
