ARTICLE · 990085
源码解读TencentDB-Agent-Memory原理
源码解读TencentDB-Agent-Memory原理源码解读： 如果你和现在的任何一个 AI Agent 聊过，就一定遇到过这种尴尬： 根源只有一个：**普通的大模型对话，是「一次性」的**——上下文窗口一关，刚才说过的话、做过的事、学到的经验，统统灰飞烟灭。 TencentDB-Agent-Memory 就是用来解决这个问题的：它是一套外挂在 AI Agent 身上的「长时记忆系统插件」，让 Agent 能像人类一样，**把对话里有价值的信息沉淀下来、整理清楚、下次遇到时立刻想起来**。 这套系统的设计理念可以用 5 句话概括： 🏷️ **宿主无关** 不管你的 Agent 是跑在自己的应用里、还是接入某个平台进程内，核心算法一套不用改。 🏗️ **分层渐进** 把「记忆」从最粗的原始对话，一层层过滤、抽象、压缩，变成越来越精炼的高层认知。 ⚡ **异步调度** 所有「把对话提炼成记忆」的重活，都在后台默默跑，绝不拖慢你跟 Agent 说话的响应速度。 🔍 **可追溯** 任何一条记忆，都能精确回溯「它是从哪几条对话里来的、当时用了哪份 Prompt 模板生成的」，出错能定位。 🔐 **强隔离** 多团队多用户共用一套系统时，每个人、每个团队的记忆空间完全独立，不会互相穿透。 --- 整个系统不是一个大而全的黑盒，而是由三个独立模块协同工作。 **记忆核心模块** 这是系统的大脑中枢。所有原始对话的落盘、结构化记忆的抽取与检索、技能经验的管理、自定义 Prompt 模板的维护、每条记忆的生成溯源日志，都在这里完成。对外通过 HTTP 网关提供服务。 **知识内容引擎模块** 专门处理「大块头」的知识：团队的 Wiki 文档、代码仓库的结构图谱。它负责把 Wiki 解析成索引、把代码变成关联图，记忆核心只保存这些知识的「元信息卡片」（叫什么、在哪、和谁有关），真正的内容检索交给知识引擎。 **前端管控面板模块** 纯界面层，给运维和用户看记忆、管技能、调配置，本身不承载核心逻辑。 一句话理解三者关系：**记忆核心管「人和经验」，知识引擎管「文档和代码」，面板管「看得见摸得着」。** 当你跟 Agent 说话时，记忆系统参与两个关键时刻： **第一刻：你说话之后，大模型动笔之前——「召回」** 记忆系统会把「和你现在说的这句话最相关的记忆」找出来，连同你的核心画像、有哪些场景可以参考、记忆系统有什么工具可用，一起塞给大模型。这样大模型回答时，是「带着记忆说话」，而不是「失忆胡扯」。 **第二刻：Agent 回复完你之后——「沉淀」** 这一轮对话结束，记忆系统把你和 Agent 说的话完整存一份原始副本，然后立刻通知后台：「有新素材了，该提炼记忆了！」后台调度器会根据时机，依次做「提炼原子记忆 → 聚合情境场景 → 更新核心画像 → 沉淀可复用技能」这四步。 这两步一收一放，就构成了记忆系统完整的「读-写」闭环。 对外来看，记忆系统提供 7 类核心能力，覆盖所有使用场景： **构造回答前召回记忆** 对应大模型动笔之前的那一步，把相关记忆、画像、场景导航一起准备好。 **对话结束沉淀素材** 每轮对话完成就记录原始内容，并通知后台开始提炼。 **会话结束收尾** 单会话关闭时把缓冲区冲掉，不影响其他正在进行的会话。 **主动搜索结构化记忆** Agent 可以像用搜索引擎一样，主动调用工具去记忆库里搜更详细的内容。 **主动搜索原始对话** Agent 也可以回头翻「聊天记录原文」，找更细节的对话上下文。 **技能模块门面（可选启用）** 如果启用了技能系统，所有技能相关的操作都走这个入口。 **生命周期管理** 启动时初始化目录、存储、调度、技能模块；关闭时优雅收尾，把尾巴数据写完整。 --- 这是本系统最核心的设计——四层渐进抽象。每一层解决一个明确的问题，信息量逐级减少、信息密度逐级升高。 第一层什么都不做，就是**原封不动地把每轮对话存下来**，不压缩、不改动、不抽取。 它是后面所有层的「数据矿」——将来哪条记忆被怀疑是错的，可以回到第一层挖原始对话素材重新验证；有了更聪明的抽取算法，可以拿历史对话重新抽一遍新记忆。 存储时有三个重要保障： **① 写入不重复** 用「读游标 → 写记录 → 推游标」的原子操作配合锁机制，保证同一个会话的两条并发结束事件不会写重复。 **② 还原真消息** 系统注入给 Agent 的记忆前缀会被剥掉，只存用户和 Agent 真正说过的话，不存「系统自己塞给自己的东西」。 **③ 向量化不阻塞** 先把元数据和文本索引写好（几毫秒就完），向量化这种慢活扔到后台慢慢做，**用户感觉不到任何卡顿**。 📌 性能：原始对话记录写入耗时不到 50 毫秒，完全不影响对话响应速度。 如果说第一层是「整本书」，第二层就是「从书里挑出来的知识点卡片」。 每张卡片有固定结构： - **类别**：用户画像类、事件片段类、指令偏好类、工作事实类、工作任务类、工作方法类、工作产物类 - **优先级**：0-100，重要的排前面 - **归属情境**：这条知识属于哪个话题/场景 - **时间点**：发生的时间或时段 - **来源引用**：对应原始对话里的哪几条消息 从「整本书」到「知识点卡片」经过 6 步流水线： **① 垃圾过滤**：过短消息（比如「好的」「收到」）、纯符号/表情、提示词注入特征、纯图像编码这类没信息量的东西先丢掉，大概减少 15-30% 的输入。 **② 分批组织**：拿最近 10 条新消息 + 上下文 5 条做背景，既不看太少（缺上下文）也不看太多（Prompt 爆掉）。 **③ 一次 AI 调用同时做两件事**：一边判断「哪些消息属于同一个场景」，一边把每个场景里值得记的内容抽成结构化卡片。一次 AI 调用解决两个问题，省 Token。 **④ 别名归一**：比如「episode」和「episodic」、「preference」和「persona」，历史兼容的各种别名统一成一个标准名，免得分类乱掉。 **⑤ 冲突检测（去重）**：这是关键一步，独立开小节讲。 **⑥ 生成留痕**：每条新记忆都写一条「怎么来的」日志，不存 Prompt 正文，只存模板 ID、版本号、来源、哈希值，出问题能溯源。 新的知识点卡片写库之前，要先跟库里已有的记忆「比对是不是重复/矛盾/互补」。这个比对分两阶段。 **阶段一：找候选（三级降级）** 最优情况用**语义比对**：把新卡片变成向量，在库里找语义最相近的前 5 条。这种方式能识别「字面不一样但意思一样」（比如「MySQL 5.7 升级注意事项」和「升级 MySQL 到 8.0 的坑」）。 次优情况用**关键词匹配**：当向量服务不可用时，退化成全文关键词搜索。只能字面匹配，但能覆盖专有名词。 最差情况**跳过比对直接写**：两种搜索都挂了，宁肯有重复也要保证新信息不丢——重复的信息，后面合并阶段还有机会清理。 **阶段二：AI 批量裁决（4 种决策）** 把所有新卡片 + 各自的候选池打包给 AI，让 AI 对每条新卡片做 4 种判断之一： - **全新入库**：从没见过的新信息，直接写。 - **更新覆盖**：和某条旧记忆意思一样，但内容更精确或时间更新，归档旧的、写新的。 - **合并归并**：和 2 条以上旧记忆分别描述了同一件事的不同侧面，合并成一条更完整的，旧的全部归档。 - **完全丢弃**：100% 冗余的重复信息，直接跳过。 如果 AI 调用超时或解析失败，不中断——所有新卡片退化为「全新入库」，记一条警告日志。下次有机会重抽到同一块对话时，比对会再跑一次自动修复。 第二层是一张张卡片，第三层就是**把主题相关的卡片装订成「话题册」**——每个话题是一份独立的 Markdown 文档，包含： - 元信息头：话题名、创建更新时间、标签、关键时间点 - 话题概述：这个话题讲的是什么 - 按时间串起来的关键事件链 - 核心结论 + 未解问题 - 对用户画像有什么影响 第三层的提取不是传统的「文本分类打标签」，而是一个**带文件编辑能力的智能编辑机器人**在做： **① 只能碰话题文档文件夹** 给 AI 的文件操作权限被严格限制，Persona 文档、调度标记这些系统文件物理上都看不到，安全。 **② 编辑前先做快照备份** 每次编辑话题之前先给整个话题文件夹拍个快照。AI 搞砸了（比如误删了一个话题的核心内容）可以立刻回滚。 **③ 话题数量上限强制管控** 话题不是越多越好——太多了翻都翻不过来，反而降低回忆质量。上限（默认 15 个）分三级预警： - 快到上限（差 3 个）：建议优先合并相似话题 - 差 1 个到上限：只能更新已有话题，不许新建 - 达到上限：必须先合并 2-4 个相似话题腾出空位，才能处理新内容 重点是：**合并哪些、怎么合并，不是系统硬编码的，而是让 AI 自己判断**。AI 看得懂「2025 年 Q4 大促压测」和「2026 年 618 压测」应该合并成「大促压测演练集锦」，关键词相似度只有 30% 的硬合并逻辑做不到。 **④ 四种操作语义** 新建话题、给老话题补信息、合并相似话题、软删除无效话题（话题删了还能从索引里清理痕迹）。 **⑤ 给核心画像发信号** 如果 AI 编辑话题时发现「这些内容值得上升到用户画像层」，就发一个特殊信号，下次画像更新时立刻响应。 第四层是记忆系统的最高抽象——**把所有话题文档里反映出来的身份、偏好、方法论、价值观，压缩成一份画像文档**。 画像内容按深浅分 4 层： **身份层（最浅）** 姓名、角色、团队归属、核心标签。 **偏好层** 语言风格、回答方式、工作习惯、常用工具链。 **方法论层** 做事流程、架构理念、风险偏好、遇到冲突的处理原则。 **世界观层（最深）** 长期目标、价值观、技术信仰、以及明确的「反模式」（告诉 Agent 什么事绝对不要做）。 画像更新有两种模式： **首次模式** 还没有画像时，从零构建四层结构。 **增量模式（重要！）** 已有画像时——**只让 AI 重点看「自上次更新之后有变化的那些话题」**，没变化的根本不塞给 AI。这样省 Token、聚焦注意力，还大大降低了「AI 手贱删掉原画像有用段落」的风险。 画像什么时候更新？5 条触发路径，任何一条命中都会启动： **第一优先级（立刻响应）** - 显式请求：某个话题编辑后发出了「这内容应该进画像」的信号。重要变更马上生效，不等阈值攒够。 **第二优先级（一次性初始化）** - 冷启动：已经有话题了但还没有画像。新用户不用等阈值就有第一版画像。 **第二优先级变体（灾难自愈）** - 画像损坏：画像曾经生成过，但现在文件空了（可能是文件系统坏块或运维误删）。系统自动从完整的话题库重新生成画像，不用人工操作。 **第三优先级（首次加速）** - 第一个话题提取完成。画像的首次生成不用等话题攒够，第一个话题结束就出第一版。 **第四优先级（周期性兜底）** - 阈值累积：积累的记忆数量达到了间隔阈值，保证以上都没命中时画像也会周期性更新。 任何一条路径没覆盖到，都会被另一条兜住——**画像永远不会「永远不更新」也不会「每 5 分钟重写一遍」。** --- 记忆提炼是 AI 重计算，不能乱调度。提炼太频繁浪费算力，提炼太久积压变质。调度器专门解决这个时机问题。 针对新会话用了「热身阶段」的指数阈值策略： - 会话第 1 轮结束 → 立刻提炼（新用户第 1 轮就有记忆） - 累积到 2 轮 → 再提炼（阈值翻倍到 4） - 累积到 4 轮 → 再提炼（阈值翻倍到 8） - 直到恢复到稳态值（默认每 5 轮提炼一次） 冷启动体验是质的飞跃：不用等攒够 5 轮，**第 1 轮自我介绍完，第 2 轮 Agent 就能想起你是谁。** 稳态阶段还有两条兜底路径： - **会话空闲 60 秒以上**：兜底捕捉那些没到 5 轮就结束的小会话。 - **优雅关机时**：把所有缓冲区里的内容全部冲完，不丢尾巴数据。 还有一个积压加速机制：当发现数据库后面堆了至少一个批次还没处理的消息，调度器就不等计数也不等空闲，立刻排下一个提炼任务——**像水管满了自动开泵排水一样。** 运维事故当天几百轮对话狂轰滥炸时，这个机制会自动提速跟上积压。 场景用的是一个「**只能提前、不能延后**」的智能计时器，有三个参数同时起作用： - 原子记忆结束后要等一会儿（默认 90 秒），别刚结束就立刻重抽 - 两次场景之间最少有一个大间隔（默认 900 秒），防止 10 分钟内反复抽同样内容 - 最长 1 小时一定抽一次（只要会话还活跃），别攒太久 当 L1 完成时，取「90 秒后」和「上次 L2 之后 900 秒」两者中**更晚**那个时间点，既不浪费新记忆的热度，也保证 15 分钟内最多抽一次。 画像生成是互斥的——**任何时候只跑一个画像生成任务**，避免并发写画像互相覆盖。 场景提取完成后，被影响到的团队/Agent 画像会被标上「脏了」的标记。然后画像触发器按五级优先级判断要不要真的跑。所有写操作都走统一存储层，单机模式和服务化模式行为完全一致。 --- 每次大模型动笔回答之前，召回流程就开始工作了。把相关的记忆上下文注入 Agent。 返回的记忆上下文被故意拆成两段，目的是**最大化 Prompt 缓存命中率**： **稳定段（塞在 System 提示词尾部）** 内容是：核心画像 + 话题导航 + 记忆工具指南。这些内容几小时甚至几天才变一次。Provider 级别的 Prompt 缓存可以稳定命中，大幅省 Token。 **动态段（塞在 User 消息前缀）** 内容是：本次具体命中的原子记忆结果。每轮都不一样，故意放 User 提示词里，不破坏 System 段的稳定性。 **纯关键词搜索** 走全文关键词排名（BM25）。不需要向量服务，字面匹配准，同义词会漏。 **语义向量搜索** 把查询转成向量，按余弦相似度取最接近的结果。能找到同义词和改写表达，语义匹配强。 **混合搜索（默认推荐）** 两路并行跑，然后用 RRF（倒数排名融合，常数 k=60）把两边结果合并打分后重排。字面+语义同时命中，精度最高。 💡 如果底层向量数据库原生支持混合搜索（一次 API 做完关键词+向量+融合），就直接走后端一次调用，省掉客户端做两次 HTTP 的开销。 **预算裁剪** 不能让召回的记忆撑爆 Prompt Token，所以有两道闸门： - 单条记忆最多多少字符，超了就截断并提示「用主动搜索工具可以看详情」 - 所有记忆拼接后总字符上限，超了就丢弃分数低的 截断按 Unicode 代码点计数，不会把一个汉字切成两半变成乱码。 **超时保护** 召回永远不会阻塞主 Agent 超过 5 秒。超时、配置缺失、存储异常都打包成结构化错误码返回，不会静默失败。监控可以基于错误码设告警，用户侧也能看到错误而不是「莫名其妙没回忆」。 --- 技能系统是在四层通用记忆之上叠加的**可复用经验资产层**。一个技能的载体是：一份 Markdown 规范的技能文档（包含元信息、适用场景、步骤、注意事项）+ 任意数量的配套资源文件（脚本、模板、数据等）。 对外提供 6 类写操作 + 4 类读操作，共 10 类： **写操作（都会触发版本递增）** - **新建技能**：生成唯一不可猜的技能 ID，碰撞时自动重试 - **整体更新**：替换整份技能文档 - **单点补丁**：只改一处文字（比如把步骤 3 的 A 命令改成 B 命令），成本最低、最常用 - **物理删除**：真删所有版本（2026-07 从软删改为真删） - **增改资源文件** - **删除资源文件** **读操作** - **取详情**：拿指定版本的完整内容 - **列列表**：按团队/归属 Agent/状态分页 - **搜技能**：关键词/语义/混合三种搜索 - **读资源文件 / 列历史版本 / 打包导出**：支持跨实例迁移导出为 zip 每次追加版本时，先把**上一版的全部资源目录完整复制一份**到新版目录，再在新版上做改动——这就是「不可变副本」模式。好处是：每版的资源是完整快照，回滚到旧版本直接读对应目录就行，不需要一层层 apply patch。 新技能或新版本的创建会跨三个存储系统：资源文件、技能数据库、资产注册表。没有真正的分布式事务，用「先做最容易失败的、最后做最可靠的 + 失败反向清理」的顺序来保证最终一致性： 1. 先写资源文件（最容易失败，失败了什么都没留下） 2. 再写技能数据库（几乎不会失败，失败了就反向清掉刚才写的资源） 3. 最后登记资产（失败了就反向删技能库再清资源） 极端情况下的兜底： - 技能库写了但资产登记漏了：下次读技能详情时自动补登记，用户再刷新一次界面就看到了 - 残留的孤儿资源文件：读路径永远走技能库，不会被误读到，只是占点空间 对话结束后，一个带「技能管理工具」的 AI Review 机器人会在后台默默看完整段对话： - 先搜一下团队已有的技能：有没有同一问题的？ - 有的话判断是「整体内容不够全」（整体更新）还是「局部一两处要改」（单点补丁） - 没有的话就新建 然后调用技能工具把经验沉淀下来，最后把候选结果（技能 ID + 版本号）上报供审计。 整个抽取在**后台异步队列**执行，用户对话时完全无感知，但团队技能库一直在悄悄长大。 AI 最大的坑之一是：看不到已有的技能，就会重复造一个重名/重复的。Review 机器人开始工作之前，先注入团队已有技能清单做前缀，根据数量多少选 4 种模式之一： - **全铺模式**：技能总数不多（≤20），直接全部铺开，不额外花 AI 调用 - **相关优先模式**：总数量超上限，额外花一次 AI 调用来生成搜索关键词，然后按相关性挑最相关的 top-N 注入 - **最近更新兜底模式**：相关模式失败时，按最近更新时间降序挑 top-N，并附带提示「还有 X 条没显示，可以主动列出来」 - **空模式**：技能库为空或配置了不注入 实测在 50+ 技能的团队里，相关优先 + 最近更新的组合把「技能重名错误率」从 17% 压到了 2% 以下。 版本 TTL 开关打开后，每次新版本成功，就顺手清掉过期的老版本。读路径引用过期版本时也会明确报错提示换最新版。效果是：**技能库永远是活的**——过期的操作步骤不会被照做，老版本占的存储和数据库空间也会自动回收。 --- 系统定义了两层可替换的存储抽象，所以部署方式可以非常灵活： **记忆检索层** 接口负责：原始对话、原子记忆的写和搜索（关键词/向量/混合/计数）。 内置实现用 SQLite + 向量插件 + 全文索引，零外部依赖就能跑。扩展实现切换到腾讯云向量数据库，适合多节点服务化。 **文件大对象层** 接口负责：读/写文件、建目录、列目录、复制目录、版本目录。 内置实现用本地文件系统，扩展实现切到腾讯云 COS，适合集群。 所以： - 单机/插件模式：SQLite + 本地文件系统，安装即用 - 服务模式：向量数据库 + COS，无状态可水平扩展 两种模式切换时，算法层零改动。 **关键词搜索（BM25）** 无需向量服务，纯字面。文档集很小时 BM25 的绝对分数不可靠，专门做了「结果数很少就全返回」的兜底。 **语义向量搜索（余弦相似度）** 能理解语义，支持服务端做向量化（向量数据库原生支持时），省客户端调用。 **混合搜索 + RRF 融合** 两条路并行，对同一条记录的排序倒数做累加后重排，精度最高。融合常数 k 固定为 60。 所有写和检索都支持五维过滤：团队 ID、Agent ID、用户 ID、会话 ID、任务 ID。v3 路由强制要求前三维必须通过请求体或请求头传入，从入口上杜绝跨租户穿透。 画像和话题的存储空间，按团队/Agent 拼成独立的目录前缀，在 COS 上就是互不相关的文件夹，天然不串。 --- 看不见的系统，等于黑盒。可观测性由三部分构成。 每一步都上报指标，通过 Kafka 或 OTLP / ClickHouse / 控制台输出。指标上报全被 try/catch 包住，上报失败静默忽略，绝不影响业务返回。 **原子记忆侧** 输入原始对话数、抽取到的原子记忆数、抽取率（低了可能是 Prompt 太保守或消息噪声多）、去重后 4 种决策（全新/更新/合并/丢弃）各自的数量、各阶段耗时。 **画像/场景侧** 场景生成延迟、画像生成延迟。 **召回侧** 使用哪种搜索策略、命中多少条原子记忆、总延迟、是否有错误。 **技能侧** 一次抽取耗时、处理了多少消息、产生了多少候选技能、用了哪种前缀注入模式、跳过执行的原因。 通过仪表盘观察这些指标的趋势，能发现「慢退化」： - 连续一周「纯冗余丢弃 / 总抽取量」> 50% → 提示对重复信息不敏感，该调 Prompt 或去重阈值了 - 召回错误突然升高 → 依赖的向量服务 / 向量服务在抖 - 技能抽取一直用「相关模式」却长期空命中 → Prompt 需要改 每条记忆关联一条生成日志，包含： - 使用的 Prompt 模板 ID、版本号、来源层级（系统/实例/团队/Agent）、内容哈希 - 输入引用：来自哪几条原始对话或上一层的哪些记忆 - 输出引用：同批生成了哪些本层记忆 - 层级、模型名、Prompt 家族、开始时间、耗时 有了这个：用户抱怨「怎么记住了我从没说过的事」时，5 分钟内就能从记忆 ID → 查到哪几条原始对话被误抽 → 回原文确认 → 到底是 AI 幻觉还是原始消息被注入污染 → 对应修 sanitize 规则 / 质量门 / 自定义 Prompt。**不是瞎猜「LLM 质量下降」，而是有因果链。** 每一次 AI 调用（原子记忆抽取 / 去重裁决 / 场景生成 / 画像生成 / 技能提炼）都通过四元组（团队/用户/Agent/会话）打身份标签，且有稳定的业务 trace 名（如 `memory.l1-extract`）、团队标签、Agent 标签。 界面上可以： - 按团队过滤，看整个团队一周内抽取有无异常 - 按 Agent 过滤，看某专用 Agent 抽取的质量 - 点进某条具体 trace，看完整的 System Prompt / User Prompt / AI 输出 / 工具调用链 和生成日志互补：日志是「这条记忆怎么来的」业务视角，Trace 是「这次 AI 调用发生了什么」LLM 视角。 --- 一位 DBA 跟 Agent 多次对话后，记忆系统自动沉淀了四层内容： **原始对话（约 40 条消息）**：从「凌晨 TDSQL-C 实例 A 慢查询」到「定位索引问题」再到「确认好转」的全过程。 **原子记忆（7 条卡片）**：比如「实例 A 在某日 02:10 出现慢查询，持续 45 分钟，Buffer Pool 命中率跌至 92%」「报表任务在 02:00 批量执行的新 SQL 没有走索引」「大表 DDL 优先用 CONCURRENTLY 模式避免长时间锁表」「优化后 SQL 耗时从 12 秒降到 80 毫秒」等等。 **情境场景（一份话题文档）**：时间范围写着「2025-08-20 02:10 ~ 03:00」，事件链按时间串：告警→定位报表 SQL→发现索引不匹配→CONCURRENTLY 建复合索引→命中率恢复 99.2%；可复用方法单独一节写着「大表 DDL 优先 CONCURRENTLY」「复合索引匹配 WHERE 列顺序（等值在前，范围在后）」。 **核心画像（更新片段）**：工作方法偏好里多了两条——「遇到 DDL 场景优先推荐 CONCURRENTLY/在线 DDL 方案」「索引优化先看 WHERE 组合再匹配等值/范围特征」。 **下次同类对话的效果**：用户问「实例 B 今早慢查询，能参考上次 A 的处理方式吗？」——召回同时从语义命中「慢查询+索引优化」、从关键词命中「CONCURRENTLY」「Buffer Pool」，把原子记忆和场景文档路径一起注入，Agent 不用再问什么是 CONCURRENTLY、上次怎么处理的，直接进入分析阶段——**每轮节省 2-3 次交互。** 一个运维团队跟 Agent 反复做过 5 次数据库版本升级，每次的步骤、注意事项、回滚点散落在对话里。 Review 机器人自动识别出这是可复用经验，沉淀了一份技能：`TDSQL for MySQL 滚动升级流程`（从 5.7 滚动升级到 8.0，数据量<5TB），内容包括适用场景、前置检查（从库延迟<1s、备份集校验、参数兼容清单）、标准步骤、灰度策略、回滚预案。 后续对话补充了 MySQL 8.0 的特殊注意事项，Review 机器人对技能做了单点补丁，版本从 v1 自动升到 v2。 **效果**：下次任何一位团队成员说「要把实例 C 从 5.7 升级到 8.0」，召回阶段就直接命中这份技能——**Agent 不用再被一步步教升级流程**。版本史完整记录，随时可以回看旧版本。技能可以导出 zip 跨实例迁移，团队经验真正变成了可复用资产。 第一次对话用热身模式： - 第 1 轮结束 → 立刻抽取原子记忆 → 抓出 2-3 条 - 第 2 轮结束 → 再次抽取 - **第 2 轮回忆时已经能引用第 1 轮的自我介绍** 比如第 1 轮用户说「我是腾讯云 DBA，主要管北京区的 TDSQL-C」——第 2 轮 Agent 就已经知道你是谁、干什么的，不会再重复问「您是什么角色？」。 对比传统「攒够 N 条才处理」的方案，冷启动从「前 5 轮像新 Agent」变成「第 1 轮就有记忆」。 --- TencentDB-Agent-Memory 的核心原理，最后可以归纳为五把钥匙： 🔑 **第一把：四层渐进抽象** 从保真原始对话 → 原子知识点卡片 → 情境话题文档 → 核心画像，每一层解决一个明确的粒度问题。越往上信息越少、越凝练、越能反映长期认知。 🔑 **第二把：异步智能调度** 热身阶段指数阈值（新会话快速出记忆）、向下计时器双约束（响应快+不反复）、积压自动加速排水、状态持久化重启不丢进度。所有 AI 重计算不阻塞对话路径，既快又准。 🔑 **第三把：智能抽取机器人** 场景机器人、画像机器人、技能 Review 机器人——不是打标签分类器，而是带文件编辑能力的真正智能体，在沙箱里自主编辑文档、合并话题、沉淀经验。 🔑 **第四把：多层冲突检测与去重** 原子记忆的 4 决策冲突检测、情境场景的强制 MERGE 上限治理、技能的版本幂等与补丁低成本增量——记忆不会越攒越脏，而是**越用越精炼**。 🔑 **第五把：全链路可观测** 全链路指标、每条记忆的生成溯源、每次 AI 调用的 Trace UI 回放——每一条记忆都能追溯「从哪来、怎么生成的、用了哪个版本的 Prompt」。 这套系统，单机零外部依赖就能跑，服务化场景下切换向量数据库 + COS 就能水平扩展，真正做到：**记忆能力可大可小、可本地可云端、随 Agent 和团队一起成长。**
# TencentDB-Agent-Memory原理
## 一、为什么 AI Agent 需要一套「长时记忆系统」
https://github.com/TencentCloud/tencentdb-agent-memory
上一轮你刚自我介绍过「我是 DBA，管理北京区的 TDSQL-C」，下一轮它又问「请问您是什么角色？」 两周前你让它帮忙排查过一次慢查询，同样的故障再出现时，它还要一步步重新做过 团队里 A 同事踩过的坑，B 同事再和同一个 Agent 对话时，Agent 完全不知道，再踩一次