AI Agent 现在最大的问题，很多时候不是不会做事，而是做过之后留不下来。
这一轮你刚强调"架构图用 Mermaid，不要截图"，下一轮它可能又回到老样子。偏好、规则、流程，往往只存在当前上下文里。会话一结束，前面的信息基本就断了。
腾讯最近开源了一套面向 Agent 的记忆系统，叫 TencentDB Agent Memory。它做的不是简单保存聊天记录，而是把对话进一步整理成可检索、可更新、可复用的长期记忆。再往上一层，它还把 Skill、Wiki、CodeGraph、Chat Memory 放进统一的团队记忆池里。
这套系统值不值得看，不只看介绍，还是要看链路到底通不通。我们直接从服务入口下手，重点测了四件事：写入、提炼、检索、更新。
先说结论。它最重要的地方，不是"能存东西"，而是把"先存下来"和"后续理解"拆成了两步。
原始对话先落盘，保证信息不丢；后台再慢慢提炼成结构化记忆，进入后续检索链路。这种设计决定了它是不是一个能长期工作的系统。
一、它开源的到底是什么
一条记忆想真正发挥作用，至少要经过四步：写入、提炼、检索、更新。哪一步出问题，后面的链路就接不上。
TencentDB Agent Memory 的特点，是把这几步尽量做成了清晰可见的流程。写入了什么，提炼出什么，检索怎么做，遇到冲突怎么处理，基本都有对应机制，不是一个黑盒。
它另外一个值得注意的点，是把团队记忆也一起纳入进来了。Skill、Wiki、CodeGraph、Chat Memory 都放进同一个 Memory Hub。这样一来，新建的 Agent 继承的就不只是最近几轮对话，而是团队之前已经积累下来的协作信息。
二、实测：它到底能不能记住
判断一个 Agent 记忆系统，核心其实就看四件事：写得快不快，提得准不准，换种说法还能不能查到，规则变了之后怎么更新。
1. 时效性：原文写入很快，结构化记忆有一点延迟
我们先写入一条工作习惯：
"我上午 10 点前不回即时消息，下午统一沟通。"
结果比较清楚。原始对话几乎是立刻入库的，结构化记忆大约十秒后才能查到。
原因不复杂。原始对话落盘只是存储动作，本身很快；后面的提炼要经过模型处理，所以会有异步延迟。也就是说，它不是完全没有延迟，而是把延迟放到了后台，没有卡住当前对话。
这个结果对聊天场景来说基本够用，但如果是批量导入历史数据，就不能指望写完马上查到。
2. 提炼质量：输入方式会影响卡片数量，但不会把主题打散
我们做了两组对照。A 组一次性输入 3 条协作规范，B 组分 3 轮输入 3 条评审规范。
结果是，一次性说完的内容和分几轮说的内容，部分内容会合并为一张卡片，其余的更容易被拆成多张卡片。但只要主题接近，最后还是会归到同一个场景下面。
这说明它不是按轮次机械切分，而是会做一定程度的情境归并。
所以这里的结论是：输入方式会影响记忆卡片的颗粒度，但不会明显影响主题归类。
一次性输入三条约束：
分开输入三条约束：
3. 检索能力：默认配置能用，但强语义召回不能高估
我们写入一条偏好：
"用户不接受临时语音沟通，优先异步文档。"
然后换新对话、换说法去查，同时禁止他猜测搜索。
先用中文切换说法提问:只根据已经保存的记忆回答，不要根据常识猜测： 我更喜欢使用语音沟通，还是异步文档？
使用英文提问:Would I prefer a quick sync call or an asynchronous document?
结果是，意思接近的表述，能命中。
这说明，TencentDB 是提炼了对话的内容记忆，并不是简单的记忆。
场景记忆：
测试结果：
三、为什么它不只是"又一个向量库"
TencentDB Agent Memory 不是把所有内容直接堆进一个库里就结束了。它把记忆拆成了四层：
- • L0：原始对话
- • L1：记忆卡片
- • L2：场景档案
- • L3：人格摘要
这套分层，本质上是在解决一个很实际的问题：原始信息要尽量完整保留，但真正注入到上下文里的内容又必须足够精简。这两件事很难靠一层结构同时做好，所以它干脆拆开处理。
L0 负责保留原文，作为证据和回溯基础；L1 负责把内容整理成可检索的记忆卡片；L2 负责按场景组织；L3 则进一步压缩成低成本可注入的摘要。
另外，它还给主链路留了比较明确的降级空间。比如语义检索没效果时，可以退回关键词；本轮注入超时，可以先跳过；去重失败，也可以先新增再说。这样做的好处是，就算某一步效果一般，最坏情况通常也是"这一轮没用上记忆"，而不是把整个流程卡死。
四、怎么装：Windows 极简版
Windows 上可以装，实际思路不复杂。
Docker 用来跑服务，Ubuntu 用来执行脚本，真正需要做的就是 4 步。
第一步，装好
Docker Desktop
Ubuntu打开 Docker Desktop，确认能正常运行，再到设置里把 Ubuntu 的 WSL Integration 打开。
第二步，下载项目并进入 deploy/global-images。项目地址是：https://github.com/TencentCloud/TencentDB-Agent-Memory。切到 feat/server_team 分支后下载 ZIP，解压后进入 deploy/global-images 目录。
第三步，复制配置文件并填写模型 API。把 .env.example 复制成 .env，然后重点改这几项：
MEMORY_LLM_BASE_URL
MEMORY_LLM_API_KEY
MEMORY_LLM_MODEL
PROXY_UPSTREAM_URL
PROXY_UPSTREAM_API_KEY
PROXY_UPSTREAM_MODEL这里要注意两点：BASE_URL 一般填到 /v1，不要填完整接口地址；本地安装时，
MEMORY_CORE_GATEWAY_API_KEY 通常留空。第四步，进入 Ubuntu 跑启动命令：
chmod +x ./*.sh && ./verify.sh && PULL=1 ./start-all.sh如果拉镜像有问题，也可以试：
chmod +x ./*.sh && ./verify.sh && ./start-all.sh启动后，正常会看到 3 个服务：
- •
tdai-memory-core - •
tdai-memory-hub - •
tdai-proxy
然后再做两步检查：浏览器打开 http://localhost:8125；用 global-images 目录下生成的 .admin-key 登录。能进后台，基本就说明安装好了。
说到底，这套安装流程看上去步骤不少，但关键就三件事：环境准备好，.env 填对，脚本跑起来。
五、写在最后
以前给 Agent 加记忆，很多事情都得在应用层自己补：向量化、检索、重排、冲突更新、上下文压缩，基本都要自己拼。
现在这件事开始往下走了。
TencentDB Agent Memory 真正值得关注的，不只是它开源了一套长期记忆系统，而是它在尝试把 Agent 的记忆能力，从一个上层应用功能，往更底层的系统能力推进。
数据库过去一直在替人保存数据。现在，它也开始尝试替 Agent 保存记忆。