最近一直在折腾 Agent 项目的记忆模块发现团队内部对记忆的理解居然能差出十万八千里。有人觉得把聊天记录存数据库就算记忆有人坚持必须上向量库还有人张口闭口长短期记忆网络。正好这段时间密集对比了阿里、腾讯、字节这三家对外公开的 Agent 记忆方案踩了不少坑也摸清了一些门道写出来给同样在做 Agent 开发的朋友做个参考。先说结论这三家的方案没有绝对的好坏核心区别在记忆的建模粒度和召回策略上。阿里的方案偏结构化业务记忆腾讯的偏轻量会话记忆字节的则铁了心走语义向量记忆路线。下面逐个拆开聊。1. 为什么 Agent 的记忆成为核心问题1.1 记忆在 Agent 架构中的位置一个真正能用的 Agent底层逻辑其实就四件事感知、规划、行动、记忆。前三件事各家做得都差不多模型能力决定上限工具调用决定下限真正的差距全在记忆上。没有记忆的 Agent 是个金鱼脑子上一轮对话刚结束下一轮它就忘了你叫什么、刚才让它处理到哪一步、文档里哪个字段是关键。我实测过最典型的场景让 Agent 连续处理一份合同先让它提取关键条款再让它对比模板差异最后让它生成修订意见。如果每一步都当作全新对话前两步的结果它全不记得第三步的输出基本就是重新读一遍文档既浪费 Token 又容易出错。加了记忆模块之后中间结果直接复用整个流程的响应速度能提升 30% 以上输出质量也更稳定。从架构上看记忆模块夹在 LLM 和业务逻辑中间扮演的是状态层的角色。它决定了 Agent 能不能在多轮、多任务、跨会话的场景下保持一致性。这也是为什么各家大厂宁可牺牲一点响应速度也要把记忆模块做重。1.2 三层记忆结构短期、长期、工作记忆行业内比较统一的划分方式是三层结构这也是热词里双网络记忆模型的底层逻辑来源短期记忆Short-term Memory本质上就是 LLM 的上下文窗口Context Window模型能在本次请求内看到的所有内容都算短期记忆。特点是快、但容量有限而且请求一结束就没了。长期记忆Long-term Memory持久化存储的各类知识、用户偏好、历史事实放在向量数据库、图数据库或普通数据库里。特点是容量大、可跨会话复用但需要做召回Retrieval才能进入上下文。工作记忆Working Memory当前任务执行过程中的临时状态比如已经执行到子任务第几步、某个中间变量的值、步骤间的依赖关系。工作记忆通常在 Agent 的编排层Orchestration Layer维护任务结束可以丢弃也可以沉淀到长期记忆。这三层对应到具体实现上就是三类存储上下文窗口管短期向量库/键值库管长期执行器状态机管工作记忆。任何一家的方案本质上都是在给这三层做不同的编排和调度策略。2. 三套方案的整体设计与设计思路2.1 阿里业务链路驱动的结构化沉淀阿里这套方案给我最大的感受是重业务。它的记忆模块不是单纯做聊天记录归档而是把记忆拆成业务实体、业务关系、业务状态三个维度。比如客服场景实体是用户、订单、商品关系是用户 A 下单了订单 B订单 B 包含商品 C状态是订单 B 当前在退款流程中。这套设计的聪明之处在于它把记忆从自然语言片段提升到了结构化业务数据的层面。Agent 在跑业务的时候记忆不仅仅是给它提供参考背景而是直接参与决策逻辑。比如用户说上次那个订单怎么样了Agent 不用全文检索历史对话而是直接查结构化状态几毫秒就能拿到结果且回答准确率极高。实现上阿里偏向用一套轻量的业务记忆框架结合规则引擎做实体抽取和关系维护。记忆的写入不是靠模型每次对话完自动总结而是靠业务动作触发——用户下单写一条、退款状态变更更新一条、工单关闭归档一条。这样一来记忆的时效性和准确性都有保障不会出现模型总结出一堆废话存进去的问题。2.2 腾讯以会话为中心的轻量键值记忆腾讯的思路走的是另一个极端——轻、快、好接入。它的记忆模块核心是一个带 TTL生存时间的键值存储外加一个会话级的临时存储区。键就是会话 ID 或用户 ID值可以是字符串、JSON、甚至嵌套对象读取的时候按 key 直接取压根不做向量召回。这套方案对于轻量个性化场景非常友好。比如你让 Agent 记住用户所在城市是杭州、用户偏好简洁风格、用户上次登录时间是昨天直接 set 进去就完事。读取的时候按需取出来塞进 Prompt简单直接几乎没有额外延迟。但它的短板也很明显不擅长处理模糊的、语义化的记忆。用户说我记得上次有个文件里面提到过预算的事如果当时没把预算这个关键词显式写进键值里这套方案基本召回不出来。腾讯内部对这套记忆的定位也是辅助上下文而不是核心决策依据适合绝大多数轻量交互场景但不适合重度知识密集型任务。2.3 字节向量化语义记忆的坚定路线字节的方案是三家里最潮的核心就是一切皆向量。对话记录、用户偏好、任务约束、外部文档全部切块、Embedding、进向量库。召回的时候用余弦相似度或者点积相似度找出语义最接近的 top-k 片段拼进上下文。这套方案的优势在召回能力上确实是碾压级的。用户用口语化的方式提需求哪怕表达方式和当初写入时的文本完全不一样语义向量也能兜住。比如用户当初存的是我比较喜欢偏暖色调的设计后面问UI 风格能不能柔和一点向量召回能把这两条关联起来。这在腾讯的键值方案里就很难做到。字节的注意力花了很多在记忆的写入侧上。它会对原始文本做清洗、去噪、话题聚类聚完类的话题才作为一条记忆写入向量库每条记忆还附带置信度分数和时间戳。这个设计直接呼应了热词里的记忆score时间半衰期思路——记忆不是永不过期的分数会随时间衰减旧记忆会被逐渐降权避免长期运行之后记忆库被陈年旧事污染。3. 核心机制逐项拆解写入、召回、更新、遗忘3.1 记忆的写入策略谁来决定这值得记三家方案在写入策略上的差异直接影响记忆库的数据质量。阿里的方案靠业务事件驱动写入的是高度结构化的数据字节的方案靠模型驱动对话结束后异步做一轮总结、聚类、Embedding腾讯的方案最简单开发者自己决定什么时候 set。我的建议是混合策略最靠谱。用阿里那种业务事件驱动的方式保证核心状态准确叠加字节那种异步总结的方式捕获非结构化的用户偏好最后用腾讯的键值存储放高频访问的临时配置。三个写入通道各自负责一类记忆互不干扰。实操里异步总结有一个必须注意的点一定要做去重和合并。我把同一段对话跑了两遍第一遍和第三遍的总结结果有 60% 的内容是重复的如果直接都写进记忆库召回的时候会返回大量冗余片段白白吃掉上下文窗口。3.2 召回策略向量相似度之外的事召回是整个记忆链路里最影响体验的一环。很多人以为向量召回 top-k 就完事了实际上纯向量召回在真实业务里表现并不好。我跑过一组对比实验纯向量召回在用户明确提到某个实体词的场景下准确率反而比关键词召回低——因为向量把实体名的语义信息稀释了。现在业内普遍的做法是混合召回关键词BM25召回一路向量相似度召回一路两路结果用 RRFReciprocal Rank Fusion做分数融合取融合后的 top-k。三家里面字节其实最接近这个思路它虽然主打向量但也内置了轻量的关键词索引做补充。召回还有一个细节是带时间衰减的重排。召回结果不能只看相似度排序的时候要乘一个时间衰减因子。一条三个月前的记忆和一条昨天的记忆哪怕向量相似度一样在排序上也要拉开差距。具体做法我参照热词里的思路给每条记忆维护一个 score召回到候选集后按 score * (0.5 ^ (age / half_life)) 重排half_life 设成 7 天左右实测效果比较稳。3.3 上下文管理Token 的硬约束记忆召回结果的拼接方式直接决定 Token 消耗和模型理解质量。这里有个非常反直觉的结论召回结果不是越多越好拼接位置也不是越靠前越好。我最初的做法是把召回的记忆全部一股脑塞进 System Prompt结果模型经常把历史记忆当成交代任务来执行或者被不相关的记忆带偏。后来改成这套策略系统提示词只保留角色设定和硬性规则记忆内容单独放在一个已知信息的 sections 里并且每条记忆用[记忆时间: 2025-03-12] 记忆内容... 这种格式加时间戳前缀效果立刻好了很多。各家其实都在做类似的事核心逻辑就是把记忆和指令在 Prompt 层面拆开。阿里做的更细它会把记忆按业务维度分桶只把当前场景关联的实体和状态拼接进 Prompt其他的一概不塞。这个场景过滤思路非常值得抄能省一半的 Token。3.4 记忆的持久化与迁移跨账号、跨设备的灵魂拷问热词里那条workbuddy 换账号如何获得原来账号的记忆非常真实。记忆的持久化看起来简单——存库就行——但一旦涉及账号切换、设备迁移问题就全冒出来了。核心难点在于记忆的序列化格式和身份映射。我在实际项目里定的规范是记忆库底层全部按 user_id namespace 分片存储导出的时候打包成 JSON Lines 格式每条记录带版本号、时间戳、记忆类型。换账号的时候如果新旧账号在系统里有绑定关系比如手机号绑定直接触发一次记忆迁移任务如果没有绑定就只能靠用户手动导入导出文件。参考 yicat 那类记忆库文件的做法导出文件命名统一带上用户标识和版本避免迁移的时候覆盖错账户。我踩过的坑是字节那套向量化记忆导出的时候向量数据本身是几百维的浮点数组文件极大而且换了 Embedding 模型之后向量全废。后来我们迁移的时候干脆只导出原始文本和元数据到新环境重新 Embedding。这个重新向量化的过程要多花几分钟但胜在干净可靠。4. 选型建议与实战经验4.1 不同业务场景下的选型参考说到底选哪家的思路取决于你的 Agent 到底是干什么用的。我把常见场景和推荐方案列了个表方便直接套业务场景推荐思路原因客服/工单 Agent阿里式结构化业务记忆需要精准的实体状态追踪不能靠模糊语义个人助理/轻交互腾讯式键值记忆记忆内容简单需要低延迟高并发知识问答/内容生成字节式向量记忆查询方式多变语义召回能力强多步骤任务编排阿里式结构化 工作记忆任务中间状态必须显式管理不能靠上下文硬扛长期陪伴型 Agent字节式向量 时间衰减需要跨长期会话保持一致性且要防记忆污染这张表后面是血泪教训换来的。最开始我做客服 Agent 的时候一股脑上了纯向量记忆结果用户说我上次那个订单——向量召回把上次和订单这俩词分别匹配到了不同的历史对话压根没关联起来回答直接翻车。后来才明白业务状态类的问题结构化方案才是正解。4.2 我在实际落地中踩过的坑坑一记忆写入风暴。有段时间给 Agent 接了流式对话每轮对话结束都触发一次异步记忆总结结果高峰期并发一上来总结任务堆积数据库写入负载直接飙红。后来加了两个限制一是做了写入去抖短期内相同内容的记忆不重复写二是把总结任务改成批量处理攒够 N 条对话才触发一次总结任务。坑二记忆召回噪音。向量召回有个天然问题相似度最高不代表相关。我遇到过用户问推荐一部电影结果召回回来一堆这部电影很好看之类的影评——语义上确实像但根本不是记忆是垃圾。后来加了实体校验环节召回结果先做 NER 抽取抽取出来的实体和当前问题实体有重叠才保留噪音立刻降了一半。关于ai agent 怎么扛并发这个热词我的理解是记忆模块的并发瓶颈几乎都在写入侧和召回侧。写入侧用队列削峰召回侧用缓存——高频访问的记忆片段比如用户 id → 用户偏好直接放 Redis命中率能到 80%向量库的 QPS 压力能降一个量级。5. 常见故障与排查技巧速查故障现象排查思路解决方案Agent 总是忘记刚说过的内容检查是否启用了持久化记忆短期上下文是否被截断确认写入链路正常调大上下文管理中的关键记忆优先级召回的记忆和当前问题完全无关检查向量模型和查询预处理看是否做了实体对齐加混合召回加实体过滤必要时替换 Embedding 模型记忆库无限膨胀Token 消耗飙升检查去重和遗忘策略是否生效加时间半衰期衰减设置记忆条数上限定期清理低分记忆切换账号后记忆全部丢失检查身份映射和内存/持久化边界统一 user_id 分片手动导入导出 JSON Lines 格式记忆文件多轮对话后模型越聊越糊涂检查 Prompt 中记忆和指令是否混在一起记忆单独成 section加时间戳约束模型只把记忆当背景信息排查工具方面我现在最依赖的还是日志三件套写入日志、召回日志、Prompt 日志。每次对话都记录最终拼进去的召回片段出了问题能直接回放看是哪条记忆把模型带偏了。注意不要一上来就怀疑模型能力。在我接手的项目里70% 的记忆类问题出在写入侧——不是没记而是记了不该记的、或者记了没去重。还有个小技巧给记忆模块做一套可视化的管理后台。看起来重但排查问题非常管用——直接把当前用户的所有记忆列出来啥问题一目了然。我们内部叫它记忆检查员每次 Agent 表现异常先打开后台看它脑子里装的什么基本就定位了八成的问题。6. 最后分享一点个人体会做了这么久的 Agent 记忆方案我最大的感触是记忆架构没有银弹只有取舍。跑业务链路重的场景你就得放弃纯向量的浪漫老老实实做结构化状态管理做泛知识类的场景就得接受召回噪音用重排和过滤去补救。如果非要说有什么放之四海皆准的经验那就是记忆方案设计的第一件事永远不是选数据库而是定义你的 Agent 到底要记住什么、忘掉什么。这个定义想清楚了后面的一切——选型、写库、召回、衰减——都是顺理成章的事。定义没想清楚哪怕把阿里、腾讯、字节的方案整套搬过来照样跑不出效果。