知识库刚上线，下一笔预算又要花在“记忆”上？
产品手册已经能查，工单系统也有记录。可客户昨天解释过的问题，今天还是要重新说一遍——这笔钱到底该花在知识库，还是花在记忆上？
2026 年 10 月 16 日，腾讯混元发布 Hy-Memory 2.0，开源模型、框架和应用，覆盖聊天、工作和代码记忆。四天后，Databricks 介绍了 Agent Bricks 中的 Agent Memory Beta，把会话记录、长期记忆和后台整理放进同一套服务。
对已经做过 RAG 的企业，这很容易变成一道采购题：原来的系统是不是又落后了？
先别急着换。两次发布都涉及对话结束之后的信息使用，但企业要补什么，得看自己的应用到底卡在哪里。能查到一份产品手册，和能接着处理昨天的工单，确实是两种要求。
客户昨天解释过，今天还得再解释
拿一个假设的软件售后场景来说。
周一，客户反馈所有报表都导出失败。换过浏览器，缩小过日期范围，都没用。
周二，客户回来问：“昨天那个问题有进展吗？”
AI 找到了产品手册，认真回答：“您可以尝试更换浏览器，或者缩小导出的日期范围。”
建议本身未必有错。可客户已经试过了。
这时问题来了：客户已经说过，工单也建了，为什么 AI 还是像第一次见到这个客户？
客户得再解释一遍，客服得再核对一遍。下一步本来该查询工单进展，现在却用来恢复昨天已经说清楚的背景。企业为知识库付了钱，也在为这些重复沟通付钱。
这时，继续上传产品文档，解决不了缺失的客户历史。至少要找回三件事：这是哪张工单，客户已经做过什么，支持团队有没有新的处理结果。
它们未必要放在同一个系统里，但回答时需要把它们接起来：客户历史帮助 Agent 理解已经发生了什么，工单系统提供当前的处理进展。
现有 RAG 不必拆，先看漏了哪段信息
RAG 是把外部信息检索出来，再交给模型辅助回答的方法。它可以查产品手册，也可以查获授权的工单、客户历史和业务数据。把 RAG 说成“只能查文档”，再用记忆替代它，比较的起点就错了。
区别在于，你的应用是否已经把这些信息接了进去，是否有人负责维护。
产品手册回答“通常怎么办”；客户历史说明“这个人已经试过什么”；工单系统确认“现在处理到哪一步”。长期记忆可以保存并维护其中需要跨会话使用的事实、偏好和已知进展，让应用在下一次需要时取回。对于持续变化的工单状态，应用还可以结合工单系统查询最新结果。
向量数据库能帮助寻找相关片段，但它不会仅凭文字相似度，就替团队决定谁能读、哪条是当前结论、哪条已经被纠正。上下文窗口决定一次调用能放多少信息，也不会自动把昨天的客户和今天的工单关联起来。
如果现有应用已经能处理这些事，就没有必要为了名字里多一个 Memory 再建一套系统。字段固定、历史不长的业务，查询工单并带入相关消息，也可能够用。
麻烦出在信息不断变化时。客户先说“所有报表都导不出来”，后来改口：“销售报表好了，只剩库存报表。”系统不能继续按第一次的说法处理，也不能因为看见“好了”，就把整张工单当成已经解决。
这种维护做得越多，单独管理记忆就越值得考虑。
MemOS 补的是客户历史，不是另一套产品手册
记忆张量 MemTensor 的 MemOS 提供记忆写入、检索、修改、反馈和删除操作。已有 AI 应用可以调用这些能力，让需要延续的对话信息进入记忆，并在后续会话中检索相关内容，同时保留自己的模型、知识检索和业务工具。
还是刚才那张工单。客户第一次反馈时，应用可以把已经尝试过的方法和相关背景写入 MemOS，同时保留客户身份、工单归属和来源。客户说“我上传了日志”，就记下这份陈述；技术团队是否收到、是否开始处理，仍由工单系统确认。
第二天客户回来追问，后端可以结合客户身份和相关历史，定位他提到的工单，并确认访问权限；如果无法确定是哪一张，也可以请客户补充信息。应用再取回相关记忆，结合工单系统里的最新进展和原有知识检索的结果，组织回答。
这样，Agent 知道客户已经试过什么，也能去确认问题现在处理到哪一步。已有知识库不用为了这一步整体迁移。
MemOS Cloud 也支持在检索时结合用户记忆与指定知识库。团队可以采用这种方式，或者保留现有知识检索，再组合两边的结果。
如果工单系统确认日志已收到、仍在排查，一个合适的回复可以是：
“昨天您已经换过浏览器，也缩小过日期范围，问题仍在。工单里显示日志已收到，目前还在排查，暂时没有新的处理结果。”
没有新进展，也可以准确地说没有。至少客户不必再证明自己昨天配合过。
这里的接入价值很具体：产品手册继续发挥作用，客户之前说过的话也能进入回答。团队可以把跨会话记忆的检索和维护交给 MemOS 处理，再由应用结合知识库和工单系统的结果组织回答。
纠正过一次，下一次就别再用旧说法
记住昨天只是第一步。如果客户今天改口，昨天留下的信息又该怎么办？
客户补充“销售报表已经恢复”，接下来就应该继续处理库存报表。此前的排查经历可以保留，但“所有报表都失败”不能再作为当前结论。
MemOS Cloud 为此提供两种入口：知道是哪条记录，可以按记忆 ID 修改；用户直接在对话里纠正，可以提交自然语言反馈，由系统结合上下文处理相关记忆。
接入时仍要检查更新后的检索结果。异步操作收到请求，并不代表新内容已经能被下一轮回答采用。测试时应等相关处理完成，再确认“已恢复”和“仍未解决”有没有被分清。
历史也不必一律删掉。支持人员问“最初有哪些报表受影响”，需要旧记录；客户问“现在还剩什么问题”，需要最新进展。MemOS Cloud 的时间感知可以帮助检索区分当前信息和历史信息，让这些变化在后续对话中更容易被用上。
预算该不该加，让客户第二天回来试一次
测试这类能力，不必先做一场复杂演示。
保留现有的 RAG 流程，让测试客户完成一轮排查，记录一条后续纠正。新开会话，只问：“昨天那个问题有进展吗？”不要把昨天的背景和正确答案重新写进问题里。
接入记忆前后，在相同的客户、工单和知识检索条件下，比较客户要补充多少旧背景、已完成的排查会不会被无理由地重做，以及人工需要纠正多少次。再看整体处理时间和成本，包含记忆写入、整理与检索的开销。只统计少用了多少回答 token，会漏掉一部分账。
同一套测试还应换一个客户账号跑一遍。服务更连贯，不能以读到别人的历史为代价。
腾讯和 Databricks 的发布让记忆有了更多实现方式。对于已经有 AI 产品的团队，MemOS 提供的是一条在原有系统旁边增加、维护和使用记忆的接入路径。如果现有工单查询已经能满足需求，不一定需要新增系统；如果客户背景散落在多轮对话里，问题又会不断变化，就值得看看记忆能否减少重复解释和维护工作。
知识库不必推倒重来。客户已经解释过一次，让这次解释在下一段对话里仍然有用，才是企业该为记忆付费的理由。