长期记忆是所有智能体平台都会提的功能，也是上线后最容易失控的功能：用户顺口说了一句错的偏好，模型从此一直照着错的走；新用户刚接进来时没有任何历史，显得特别笨；出了争议想查「这句记忆是谁写进去的」，却发现根本没人记录。2026 年 9 月，腾讯云智能体开发平台把这一块补成了可运营的模块——记忆库，同时给知识库加上了元数据。这套东西解决的不是「能不能记住」，而是「记错了怎么办、上线前怎么喂饱它、出问题怎么查」。
先分清四种「记得」
这一块最容易糊涂的地方，是把知识库和记忆混着叫。它们的数据来源、时效和治理方式完全不同：
| 类型 | 来源 | 作用范围 | 谁来治理 |
|---|---|---|---|
| 会话上下文 | 当前这轮对话的原文 | 当前会话 | 平台自动管理，通常不干预 |
| 会话记忆 | 同一会话内跨多轮保留的结论 | 当前会话 | 平台自动管理 |
| 长期记忆（记忆库） | 与终端用户多轮对话中自动积累 | 跨会话，按终端用户 | 开发者可在控制台增删改查 |
| 知识库 | 你上传或挂载的业务文档 | 全应用共享 | 你维护，按知识库生效 |
分类之后，问题就清楚了：知识库回答「公司制度怎么写的」，记忆库回答「这位终端用户上次说过什么」。前者错了要改文档，后者错了只需要改一条记忆——但前提是你能看到它。
Step 1：把记忆库绑到应用上
登录腾讯云智能体开发平台控制台
1. 进入你的应用（Agent / 智能体应用）
2. 找到记忆相关配置项，绑定一个记忆库
· 没有现成的就先新建一个
3. 确认绑定后，应用与终端用户的对话即开始自动积累长期记忆
4. 记下记忆库标识——后面 API 调用与排查都要用到它别把「开启记忆」当成免费开关。记忆一旦自动积累，就意味着每一次错误的用户输入都可能变成一条长期生效的偏见。上线前先想清楚：哪些字段允许被记住、要不要设上限、谁负责定期巡检。这三个问题没答案之前，先不要在生产环境全量打开。
Step 2：看懂记忆库的粒度——按终端用户
记忆库的查看维度是终端用户，不是会话、也不是应用。这个设计决定了两件事：一是排障时必须先指定用户，二是同一个问题在这位用户身上成立、在另一位身上可能完全不成立。
记忆库控制台可以做的事（按终端用户维度）
· 查看 该用户的全部记忆条目
· 编辑 改掉写错的那一条
· 手动新增 直接补一条（不必等对话产生）
· 删除 删单条
· 批量删除 按筛选条件一次清掉多条
· 导入导出 批量搬入 / 搬出，用于冷启动与备份Step 3：用导入导出做冷启动
长期记忆最明显的体验落差出现在刚开始的几天：老用户越用越顺，新用户像个陌生人。解决办法是提前把已知信息灌进去。做法是先准备一份按用户组织的记忆数据，导出模板对齐字段，然后批量导入。
冷启动的典型内容：
· 该用户的角色与所在部门
· 已知的称呼 / 语言偏好（例如偏好简洁中文）
· 已知的账号级事实（套餐、区域、对接的系统）
操作路径：
1. 从现有记忆库导出一份，作为字段模板
2. 按模板整理要灌入的数据，逐用户对齐
3. 批量导入，导入后抽查几条确认归属正确
4. 用该用户的身份发起一次对话，验证偏好是否生效导入前必须去敏。记忆条目会跟随用户长期存在，一旦把身份证号、银行卡号这类信息写进去，清理成本远高于当初省下的时间。批量导入前先过一遍字段清单，把不必要的敏感字段整列删掉。
Step 4：记忆校准——把写错的改掉，而不是关掉记忆
当用户反馈「它记错了」，最怕的反应是直接把整个记忆功能关掉——那等于把已有的正确积累一起扔掉。正确做法是定点校准：
1. 在记忆库按该终端用户过滤，找到冲突的那几条
2. 判断是「写错了」还是「过期了」
· 写错 -> 直接编辑修正
· 过期 -> 删除，或改成新的表述
3. 如果同一件事被反复记成相反结论
-> 说明源头输入本身矛盾，回头查对话侧的口径
4. 校准后让该用户再问一次，确认新记忆生效Step 5：记忆审计——出事时说得清
记忆库支持按用户查看、编辑、删除与导入导出，这组能力拼起来就是审计的基础：哪位用户的记忆被改过、改成了什么、什么时候批量清过一批。对受监管或有合规要求的业务来说，这一点比「模型记得更准」重要得多。
审计三问，每次上线前先问自己：
1. 这条记忆是什么时候、由哪次对话写进去的？
2. 谁在什么时候手工改过它？改了哪几个字段？
3. 用户要求删除时，我们能否完整清掉（含导出副本）？记忆属于用户数据，删除请求必须能落到记忆库这一层，而不只是删掉聊天记录。上线前把「用户注销 / 撤回授权」的处理流程连同记忆库一起走一遍，别等监管问起来才补。
Step 6：给知识库加元数据
元数据是描述知识本身的结构化信息，以键值对形式挂在文档与问答上。它有两个使用方式，配置时必须二选一或都选：
| 使用方式 | 效果 | 适合场景 |
|---|---|---|
| 用于检索 | 召回阶段用元数据匹配提问中的关键实体，提升相关知识权重 | 有产品编码、文档名称、作者这类稳定标识 |
| 用于检索与生成 | 召回的知识连同元数据一起给模型，作为生成参考 | 知识正文里没有这些信息，但回答需要引用 |
操作路径：
1. 先准备好数据来源：在知识库里为文档 / 问答打好标签或分类
2. 进入目标知识库，在知识管理右上角点「元数据」
3. 在弹窗里切换标签 / 文档分类 / 问答分类三个页签
勾选要作为元数据的项（分类可选父级或子级）
4. 为每一项设置使用方式：用于检索 / 用于检索与生成
5. 确定保存，等待异步更新完成Step 7：顺手打开两个运营开关
开关一：知识库文档的定时更新
· 除本地文档外，其他数据源在导入 / 编辑时可设置更新频率
· 适合挂在会持续变化的在线文档源上，避免知识库长期停在旧版本
开关二：拒答问题的自定义话术
· 应用运营里支持按问题维度自定义回复话术
· 适合把「我不知道」换成有引导性的说法，或转到人工入口三个容易踩的坑
| 坑 | 表现 | 处理 |
|---|---|---|
| 元数据是异步生效的 | 设置完立刻提问，检索没变化 | 在元数据列表看处理进度，更新中不支持再改设置 |
| 元数据只对当前知识库生效 | 另一个知识库的行为没跟着变 | 每个知识库分别配置，别指望全局继承 |
| 删标签会连带删元数据 | 清理标签后相关性突然变差 | 删标签前先确认它有没有被设为元数据 |
改标签名、新增或调整元数据设置之后，都要等更新完成才会生效；更新中的状态会挡住后续修改。批量改配置时预留一段缓冲时间，不要在业务高峰前一口气全改完。
常见问题速查
| 现象 | 常见原因 | 处理 |
|---|---|---|
| 模型总按某个错误偏好回答 | 该用户身上有一条写歪的长期记忆 | 按终端用户过滤记忆库，定点编辑或删除 |
| 新用户体验明显更差 | 没有历史记忆，冷启动为空 | 用导入做冷启动，先灌必要的基础事实 |
| 相关问题检索不到 | 元数据还没更新完成 | 等状态变为处理完成后复测 |
| 该限定的问题被泛泛回答 | 用了元数据（软召回）却没配标签（硬过滤） | 对需要限定范围的知识改用标签 |
| 用户要求删除数据删不干净 | 只清了会话，没清记忆库与导出副本 | 把记忆库纳入删除流程一起走 |
| 知识库内容长期陈旧 | 文档源没设更新频率 | 在文档级别打开定时更新 |
结语
记忆这件事真正的难点从来不是「存进去」，而是存进去之后的三个问题：能不能看、能不能改、能不能查。记忆库把这三件事做成了控制台里可点可管的动作——按终端用户查看、逐条编辑、批量导入导出，再加上一层可追溯的管理记录。它让长期记忆从「模型内部的一个黑盒」变成了「一份你能负责的运营数据」。
元数据是同一思路在检索侧的延伸：把结构化信息挂到知识上，让召回阶段多一个可推理的依据，同时保留「不命中也不排除」的软召回语义。把这两块配齐之后，你的智能体才算有了可以被运维的记忆层——而不是一个只能祈祷它别记错的组件。