5 篇博文 含有标签「agent-memory」

大多数智能体内存系统将一个四层的问题压缩成两层，然后在出现破绽时表现得大吃一惊。一个是当溢出上下文窗口时会被截断的会话缓冲区（conversation buffer），另一个是旧内容堆放其中的“长期记忆”向量数据库。那不是内存架构。那只是一个队列和一个杂物抽屉。

如果一个智能体连续三个周一向老用户询问同一个新手引导问题，这并不是因为模型不好，而是因为系统中没有一个地方能保存“该用户跨会话告知我的事情”，并且其生命周期不同于“所有用户告知我的关于产品如何运作的事情”。这是不同的记忆。它们有不同的访问模式、不同的隐私契约以及不同的遗忘规则。将它们混为一谈是架构上的错误——而且这是可以修复的。

当 100 万 token 的上下文窗口实现商业化时，许多团队悄然认定，他们已经解决了智能体记忆（agent memory）的问题。当你可以把所有内容都丢进去并让模型自己处理时，为什么还要构建检索系统、管理向量数据库或设计淘汰策略（eviction policy）呢？答案就在你的基础设施账单中。在每天 1 万次交互、拥有 10 万 token 知识库的情况下，这种暴力的上下文内（in-context）方法每天的成本约为 5,000 美元。而处理同样负载的检索增强记忆系统的成本约为每天 333 美元 —— 随着用户群的增长，这 15 倍的差距会产生复利效应。

真正的问题不仅仅是成本。更严重的是，更长的上下文会导致答案质量显著下降。研究一致表明，模型会丢失位于极长输入中间位置的信息；当相关的证据被埋没在无关的代码块（chunks）中时，准确率会如预见般下降；且延迟的攀升会使交互式智能体显得反应迟钝。这种“塞进一切”的方法不仅浪费金钱 —— 它还以牺牲准确性为代价换取了简单化的假象。

每个生产环境的智能体团队最终都会构建同一个东西：一个无限增长的记忆存储、悄然退化的检索性能，以及在用户报告智能体引用了他们的旧工作、已弃用的 API 或三个月前取消的项目后，一场疯狂的冲刺来添加遗忘功能。业界已经在赋予智能体记忆上投入了巨大的努力。更困难的工程问题——对记忆进行垃圾回收——才是真正的生产可靠性所在。

与软件垃圾回收的类比不仅仅是隐喻。智能体记忆系统面临着同样的根本张力：你需要回收资源（上下文预算、检索相关性），同时不能销毁仍然可达（语义上与未来查询相关）的数据。解决这个问题的算法与你的运行时已经使用的算法惊人地相似。

一个记住所有事情的 agent，最终什么有用的都记不住。这听起来像是悖论，却是每个在没有遗忘策略的情况下上线长期运行 AI agent 的团队的亲身体会。记忆存储不断膨胀，检索质量持续下降，某一天你的 agent 开始自信地引用用户的前雇主、一个已废弃的 API 端点，或者一个六个月前就已放弃的项目需求。

行业在赋予 agent 记忆能力上投入了大量精力，却很少关注那个更难的问题：教会 agent 如何遗忘。

一个客户服务智能体知道用户偏好在早晨送货。它还知道用户的主要地址在西雅图。但它无法理解的是，西雅图的地址是一个仅在工作日使用的办公地址，而且由于用户三个月前提到的一项大楼限制，早晨送货窗口期在周一并不适用。每个事实都可以被单独检索，但它们之间的关系却不能。

这就是在基于扁平向量库（flat vector stores）运行的生产级智能体中常见的故障模式。每一条信息都像是一个漂浮在高维空间中的嵌入（embedding）。相似性搜索检索与查询匹配的事实，但它无法恢复事实之间的结构化连接——即在组合中赋予它们意义的“边”（edges）。

大多数智能体记忆架构是围绕向量数据库构建的，因为它们速度快、设置简单，且适用于大多数检索任务。这些失败案例非常微妙，以至于在有人注意到这种模式之前，它们往往已经出现在生产环境中了。