几个月前，我审查了一个客服代理，发现了一个奇怪的故障模式。用户周一跟它聊账单问题，处理到一半，周三回来继续。周三的对话从零开始。代理不知道用户是谁，不知道之前是什么问题，不知道已经尝试过什么，也不知道承诺过什么。

这个团队的技术底子不差。动作端点上有幂等键。多步骤流程用工作流状态机。涉及账单的都用事务写入。正确性的基础设施是有的。缺的是让代理回忆和推理自己历史的能力——知道这个用户两天前被承诺了一笔还没到账的退款。

打开网易新闻 查看精彩图片

这才是我想聊的问题。不是系统工程已经解决的那部分代理可靠性。是上面更难的一层：代理的记忆能力。

先澄清：记忆不是什么

太多关于代理记忆的架构讨论跑偏，因为大家对"记忆"这个词理解不同。先排除三种误解。

记忆不是幂等性。如果代理因为同一个请求两次打到端点就执行两次动作，解决方法是幂等键。代理不需要记忆，系统需要识别重复。记忆不是工作流状态。如果代理处理到一半，解决方法是状态机记录当前步骤并控制合法跳转。记忆不是事务一致性。如果两个代理要操作同一份数据，解决方法是数据库级隔离。

这三样都必要，但都不是记忆。它们保证单个动作正确，不给代理历史感。

记忆到底是什么

我逐渐把代理记忆看作五种必须协同工作的能力。持久化存储是其中之一，也是最容易的。其他四项是大多数生产代理的短板。

一是持久化：代理的历史在会话结束、进程重启、部署后依然存活。靠写数据库解决。

二是选择：代理决定什么值得记住。把每次对话的每个token永远存下来，又贵又适得其反。会在召回时稀释信号。

三是压缩：原始历史被总结成有用的东西。两小时的对话变成一段文字加结构化事实。没有压缩，检索成本随交互时间线性增长。

四是衰减与遗忘：旧记忆不如新记忆重要，有些该被遗忘。没有衰减，陈旧信息和新鲜信息权重相同——这正是RAG流水线欺骗你的方式，也是我上篇文章的主题。

五是污染预防：错误的记忆比没有记忆更糟。坏事实一旦存入，会污染未来的每一次推理。