获课：xingkeit.top/16316/

Agent记忆机制，别把短期当长期用——关于会话记忆与业务记忆的几点偏见

做Agent应用这一年多，我见过最普遍也最致命的设计错误，就是把短期会话记忆和长期业务记忆混为一谈。很多团队在Demo阶段用同一个向量库存所有东西，看起来都能工作，但上线后问题接踵而至——用户问着问着就开始“失忆”，明明昨天刚确认过的偏好，今天又要重新说一遍。这不是技术能力不够，而是对记忆的分层理解出了偏差。

先说短期会话记忆。这东西本质上就是对话上下文的滑动窗口，存的是“刚才聊了什么”。它的核心约束很明确：容量有限、时效性强、优先级高。我们曾经在一个客服Agent里把上下文窗口开到32k，试图让模型记住整场对话的所有细节，结果效果反而变差了——模型被过多的历史信息干扰，抓不住当前问题的主线。后来我们把短期记忆严格限制在最近五到八轮对话，超出部分要么压缩摘要，要么直接丢弃，准确率反而提升了不少。

这里有个值得反思的现象：很多开发者对短期记忆的焦虑是多余的。 总担心用户切换话题后模型接不上，于是拼命扩充窗口大小。但实际用户行为告诉我们，绝大多数对话的有效信息密度很低，五轮之内基本能覆盖当前意图。与其花精力让模型记住更多，不如让它在记不住的时候能主动追问。一个敢于说“抱歉我忘了，能再说一下吗”的Agent，远比一个强撑记忆、胡编乱造的Agent可信。

但真正让我觉得有意思的是长期业务记忆。这个名字其实有误导性，它不该叫“记忆”，更准确的叫法应该是“可检索的事实沉淀”。短期记忆是临时的便签纸，长期记忆是归档的档案柜。两者的核心差异不在存储时长，而在写入和检索的触发机制。

短期记忆是自动写入、自动衰减的，用户说什么就存什么，轮次一过就清理。但长期记忆绝对不能这样。我们踩过一个很典型的坑：早期设计时，我们把所有用户对话都喂进长期向量库，试图让Agent“越来越了解用户”。结果长期记忆库里塞满了“今天天气不错”、“帮我查个订单”这类无信息量的噪声，真正的用户偏好反而被淹没了。

后来我们定了一条规则：长期记忆只能显式写入。 要么用户主动表达了偏好（“我喜欢简洁的回答”），要么系统通过业务逻辑判断该信息有复用价值（比如用户反复问同一类问题，说明这个问题值得被记住）。过滤掉那些随口的、临时的、场景绑定的信息之后，长期记忆的质量才真正可用。

一个更隐蔽的问题是两者的冲突处理。当短期记忆和长期记忆给出的信息不一致时，Agent该怎么决策？我们的做法是：短期记忆优先，但要标记冲突。 用户今天说“我最近喜欢详细的方案”，但长期记忆里存着他三个月前说过“要简短”。这时Agent应该先满足今天的偏好，同时悄悄更新长期记忆——因为人的偏好会变，长期记忆的价值在于捕捉变化趋势，而不是固化一个永远不会错的标签。

还有个技术之外的话题：记忆的可解释性和可干预性。我们在实际运营中发现，用户对Agent“记住自己”这件事既期待又警惕。让他们能查看、编辑甚至删除长期记忆中的条目，带来的信任增益远超我们预期。有一个用户专门感谢我们说“你们是唯一让我能删掉自己黑历史的Agent”——这提醒我们，记忆机制不只是一个技术问题，更是一个产品体验问题。

回到原点，我对Agent记忆机制的核心观点其实很简单：短期记忆是交互润滑剂，长期记忆是业务资产，两者最忌讳的就是混用。 用长期记忆的库去存会话上下文，成本高昂且检索不准；用短期记忆的窗口去承载业务知识，容量不够且容易衰减。清晰的分层设计，比任何花哨的检索增强都重要。

而更本质的一点是，好的记忆机制不是让Agent记住一切，而是让它知道什么值得记、什么该忘。 遗忘和过滤的能力，某种程度上比存储能力更稀缺。我们人类的大脑每天过滤掉大量无用信息才能高效运转，Agent也一样。做记忆机制设计时，多想想“哪些信息可以安全丢弃”，少纠结“能不能把所有东西都存下来”——后者只会把你的向量库变成一个数字化的杂物间，而不是一个有智能的助手。