接入两个月长任务 Token 省了 61%而且终于不用每次开会话都重新自我介绍了。一、三个月前我被 Agent 的记性逼疯了我有一个长期维护的 Go 项目结构不算复杂但有一些约定俗成的规范——数据库连接用 sqlx、错误处理必须 wrap、测试文件放在__test__目录而不是跟源码混在一起。每次我开一个新的 Agent 会话让它写功能前 20 分钟基本都在做同一件事重新教它项目规范。“你想用 ORM不行我们项目用 sqlx。”“别用errors.New()用fmt.Errorfwrap。”“测试文件放哪再说一遍__test__。”教完之后Agent 表现确实不错。问题是一关会话第二天再来——全忘了。我试过不少方案。最开始是把规范写成 Markdown 塞进系统提示词但提示词有长度限制塞不了多少。后来用 Mem0 存用户画像检索粒度太粗经常把无关信息也拉进来反而干扰模型。也用 LangChain 自带的内存组件说实话它就是个简单的消息存储算不上真正的记忆。那段时间我一直在想为什么让 Agent 记住东西这么难二、真正难的不是存是找对琢磨了一段时间发现问题是怎么在需要的时候精准地找到那一段有用的信息。粗暴地把所有对话历史 dump 进向量数据库然后靠相似度检索——这看起来是最直接的方案但实际却处处是坑。Example我上周跟 Agent 讨论过数据库连接池的参数调优聊了大概 2000 个字。这周我想让 Agent 帮我写一个新的数据库操作模块它检索出的相关记忆可能是那 2000 字的调优讨论——但我要的其实只是一句话的结论“我们项目用的是 sqlx连接池最大 25。”RAG 的检索按语义相似度来而不是我需要的精确度。它能找到相关的内容却找不到正确的内容。更无语的是当检索结果混入大量无关文本时模型的注意力就会被稀释反而更容易出错达不到“准确”的效果。所以一个好的记忆系统至少要做三件事分层存储、精准检索、证据溯源。缺一不可缺任何一条都只是能存不能记。三、我试了腾讯这套方案拆开看看它到底做了什么5 月中旬腾讯云数据库团队开源了TencentDB-Agent-Memory。我当时在 GitHub Trending 上看到它第一反应是腾讯云数据库团队做 Agent 记忆看了一眼架构图问题是明白了——这本质上是一个数据库问题。记忆系统的核心就是存和取而数据库团队最擅长的恰好是这两件事。他们的设计思路是把数据库领域的分层存储理念搬到 Agent 记忆上热数据放内存温数据放 SSD冷数据归档。翻译成 Agent 的语言当前上下文是热数据可复用流程是温数据需要长期保存的知识是冷资产。架构是四级管道逐层提炼原始对话 │ ├─[第一层] Chat Memory ────── 结构化对话记录SQLite FTS5 全文检索 │ ├─[第二层] Skill ──────────── 最妙的一层自动沉淀可复用流程 │ ├─[第三层] LLM-Wiki ───────── 面向大模型优化的结构化知识库 │ └─[第四层] Code-Graph ─────── 代码关系图谱帮 Agent 理解项目结构我实际用下来每一层的体验第一层Chat Memory终于不用每次重新认识了这是最基础的一层也是最容易出问题的。开发者社区里有一个很火的 ChatGPT 提示词技巧——“请每次都记住我的偏好”。但这句话本身只是告诉模型要记住并没有给模型提供如何记住的机制。记忆不能靠 prompt 工程得靠基础设施。Chat Memory 做的事很简单把对话历史结构化存储到本地 SQLite用 FTS5 做全文索引。Agent 需要回溯时按需检索而不是把整个历史塞进上下文窗口。我实测的效果是跟 Agent 聊过的东西下次会话它确实能检索出来。比如我上一周让它帮我分析过一个 SQL 慢查询这周我提到上次那个慢查询它没有问哪个——直接给出了当时的分析结论。不过这还不是最让我惊喜的。第二层SkillAgent 终于学会了怎么做这一层是整套系统里我最喜欢的设计。Skill 并非硬编码的规则。它是一套从对话中自动沉淀的可复用流程。比如我经常让 Agent 帮我做为新模块写单元测试。第一次它会摸索先找到对应的源码文件理解函数签名生成测试用例调整 Mock 策略。这个过程可能来回十几轮。一旦这个流程被记录为 Skill下次我说写测试它会直接按上次的流程走从头探索这一步直接跳过。这本质上是一种程序性记忆——记的不是你叫什么是你上次怎么做的。这种记忆在工程场景下比事实性记忆有价值得多因为开发者的工作流往往是重复的。我统计过我每天跟 Agent 的交互中至少有 40% 是重复性任务。Skill 把这部分从探索变成了执行效率提升确实肉眼可见。第三层LLM-Wiki项目规范的第二大脑前两层解决的是聊过什么和怎么做的第三层解决的是需要反复用的知识。LLM-Wiki 是一个面向大模型优化的结构化知识库。它在传统 Markdown 文档集合之上进一步将对话和文档中的知识提炼为条目化的结构化数据——项目规范、技术决策、架构设计、踩坑记录统统收进来。我把我项目的 README、架构文档、代码规范文件都扔进去之后Agent 在写代码时明显更懂这个项目了。以前我需要在每次对话里反复强调别用 ORM现在它自己就知道。这一层还有一个特性我觉得很关键它面向大模型优化面向的不是人类阅读。存储格式和检索方式都是针对大模型怎么理解信息来设计的而不是人类怎么读文档。同样的知识用更少的 Token 就能让模型理解——这对成本和响应速度都有直接影响。第四层Code-Graph让 Agent 真正看懂代码最高层是代码关系图谱。它跟传统的 AST 分析工具不同定位是专门为 Agent 设计的代码理解辅助层。Example我让 Agent 修改一个底层函数它需要知道这个函数被哪些地方调用、会不会影响其他模块。传统做法是 grep 或者依赖 IDE 的查找引用但 Agent 没有 IDE。Code-Graph 把代码的静态结构转化为可查询的图数据Agent 在做修改前可以先查一下影响范围。这个功能在大型项目里尤其有用。我试过在一个 200 文件的 Go 项目里让 Agent 重构一个公共工具函数它用 Code-Graph 查到了 17 个调用点一次性改完了所有地方没有一个遗漏。四、数据比感觉更具说服力任何工具光说我感觉不错是不够的。我翻了官方的 README利用几个 Benchmark 数据来自它作为 OpenClaw 插件接入后的实际测试记忆类型Benchmark原始成功率加插件后相对提升Token 节省短期记忆WideSearch33%50%51.52%-61.38%短期记忆SWE-bench58.4%64.2%9.93%-33.09%短期记忆AA-LCR44.0%47.5%7.95%-30.98%长期记忆PersonaMem48%76%58.33%—几个数字印象深刻WideSearch 场景 Token 节省了 61.38%。这个任务需要频繁回溯历史信息传统做法会把大量历史塞进上下文而分层记忆按需检索大幅减少了冗余。我自己的项目里长任务的 Token 消耗大概降了 40% 左右——没到 61%但省下来的都是真金白银。PersonaMem 准确率从 48% 提升到 76%。这是测试 Agent 能否记住用户偏好和特征的长期记忆场景。接近 60% 的相对提升说明分层记忆在跨会话信息保留上确实有效。对应到我的实际体验Agent 确实记住了我喜欢用 sqlx、不喜欢 ORM、测试文件放__test__这些偏好。SWE-bench 和 AA-LCR 分别提升了约 10% 和 8%。这两个任务更多依赖推理能力而非记忆但即使如此减少上下文噪音仍然带来了可观的收益。这也印证了一个道理记忆的价值不仅是记住更多还在于忘掉不需要的。五、我的接入过程两条命令十分钟搞定项目用 TypeScript 编写Node.js ≥ 22.16 即可。接入过程简单# 安装核心包npminstalltencentdb-agent-memory/memory-tencentdb# 在 OpenClaw 中一键安装插件openclaw pluginsinstalltencentdb-agent-memory/memory-tencentdb openclaw gateway restart如果你用的是 Hermes Agent官方也提供了 Docker 镜像一行命令启动dockerrun-d\--namehermes-memory\--restartunless-stopped\-p8080:8080\-eMODEL_API_KEY$MODEL_API_KEY\-eMODEL_BASE_URL$MODEL_BASE_URL\-eMODEL_NAME$MODEL_NAME\-eMODEL_PROVIDER$MODEL_PROVIDER\-vhermes_data:/opt/data\agentmemory/hermes-memory:latest镜像同时支持 linux/amd64 和 linux/arm64。内置了腾讯云 DeepSeek-V3.2 的默认配置也可以自定义模型参数。验证是否正常运行# 检查健康状态curlhttp://localhost:8080/health# 进入 Hermes 对话dockerexec-ithermes-memory hermes所有数据存在本地不需要任何外部 API 或云服务。这对隐私敏感的项目来说是个硬需求——我的代码和对话历史不会上传到任何一个第三方服务器。MIT 协议开源意味着你可以随意使用、修改、商用没有任何限制。六、用了两个月几点实际感受好用在哪里完全本地运行零延迟。之前用 Mem0 的时候每次检索记忆都要走 OpenAI 的 Embeddings API加上 Pinecone 的向量检索延迟少则 500ms多则 2 秒。对于一个频繁检索记忆的 Agent 来说这个延迟叠加起来非常影响体验。本地 SQLite 的检索几乎是瞬时的。分层设计让检索更精准。不同记忆不该被同等对待。Skill 层和 LLM-Wiki 层把不同粒度的信息分开存储Agent 检索时不会大海捞针。我在实际使用中明显感觉到Agent 拉出来的记忆片段更对题了。证据可溯源。每一层记忆都可以向下追溯。Agent 引用了某个 Skill我可以追溯到它是在哪次对话中形成的。记忆不再是黑盒出了问题可以逐层排查而不是对着一个模糊的检索结果干瞪眼。还需要优化的问题团队协作记忆还在路上。目前主要面向个人 Agent但我跟同事共享项目时希望大家的 Agent 能共享同一个知识库。官方 GitHub 上有team相关的分支应该是在做这个方向但还没正式发布。记忆冲突没有智能解决。当我对同一个规范在不同时间说过不同的话——比如一开始说连接池最大 25后来改成 50——Agent 目前依赖时间戳判断哪个更新但缺少更智能的冲突检测和合并机制。这在小团队里影响不大规模化之后会是个问题。框架支持还需要扩展。目前主要支持 OpenClaw 和 Hermes。如果你用 LangChain 或 CrewAI需要自己写适配代码。不过既然开源了社区贡献适配层应该只是时间问题。七、我为什么觉得这个方向是值得关注的Agent 的记忆问题可能是当前 AI 应用落地最大的隐形瓶颈。推理能力在提升工具调用越来越成熟多模态大一统也在推进——但如果 Agent 每次会话都是全新开始这些能力都只能发挥单次对话的上限。记忆是 Agent 从好用走向能用的必经之路算不上锦上添花。腾讯云数据库团队做这件事角度选得精准。记忆系统的本质是存储检索这正是数据库的核心能力。他们没去发明新的算法范式而是用成熟的分层存储理念把 SQLite、FTS5、结构化索引这些被验证了几十年的技术重新组合解决了一个新场景的问题。没有追求架构上的标新立异扎扎实实地把分层存储、按需检索、本地运行这三件事做到位了。开源社区对这种务实方案的反应也说明了一些东西。三个月 13.3k Star在基础设施类项目里不算慢。说明大家都有同一个痛点也都在找同一个解法。如果你也在被 Agent 的失忆症折磨建议花十分钟跑一下试试。不需要迁移整个工作流先拿一个小项目跑几天看看 Agent 是不是真的记住了。项目地址https://github.com/TencentCloud/TencentDB-Agent-Memory协议MIT技术栈TypeScriptNode.js ≥ 22.16本文数据来自项目官方 README 及腾讯云官方发布文章实测体验基于 2026 年 5 月至 8 月的个人使用记录。 我用腾讯刚开源的这套记忆系统，治好了 Agent 的“失忆症“
接入两个月长任务 Token 省了 61%而且终于不用每次开会话都重新自我介绍了。一、三个月前我被 Agent 的记性逼疯了我有一个长期维护的 Go 项目结构不算复杂但有一些约定俗成的规范——数据库连接用 sqlx、错误处理必须 wrap、测试文件放在__test__目录而不是跟源码混在一起。每次我开一个新的 Agent 会话让它写功能前 20 分钟基本都在做同一件事重新教它项目规范。“你想用 ORM不行我们项目用 sqlx。”“别用errors.New()用fmt.Errorfwrap。”“测试文件放哪再说一遍__test__。”教完之后Agent 表现确实不错。问题是一关会话第二天再来——全忘了。我试过不少方案。最开始是把规范写成 Markdown 塞进系统提示词但提示词有长度限制塞不了多少。后来用 Mem0 存用户画像检索粒度太粗经常把无关信息也拉进来反而干扰模型。也用 LangChain 自带的内存组件说实话它就是个简单的消息存储算不上真正的记忆。那段时间我一直在想为什么让 Agent 记住东西这么难二、真正难的不是存是找对琢磨了一段时间发现问题是怎么在需要的时候精准地找到那一段有用的信息。粗暴地把所有对话历史 dump 进向量数据库然后靠相似度检索——这看起来是最直接的方案但实际却处处是坑。Example我上周跟 Agent 讨论过数据库连接池的参数调优聊了大概 2000 个字。这周我想让 Agent 帮我写一个新的数据库操作模块它检索出的相关记忆可能是那 2000 字的调优讨论——但我要的其实只是一句话的结论“我们项目用的是 sqlx连接池最大 25。”RAG 的检索按语义相似度来而不是我需要的精确度。它能找到相关的内容却找不到正确的内容。更无语的是当检索结果混入大量无关文本时模型的注意力就会被稀释反而更容易出错达不到“准确”的效果。所以一个好的记忆系统至少要做三件事分层存储、精准检索、证据溯源。缺一不可缺任何一条都只是能存不能记。三、我试了腾讯这套方案拆开看看它到底做了什么5 月中旬腾讯云数据库团队开源了TencentDB-Agent-Memory。我当时在 GitHub Trending 上看到它第一反应是腾讯云数据库团队做 Agent 记忆看了一眼架构图问题是明白了——这本质上是一个数据库问题。记忆系统的核心就是存和取而数据库团队最擅长的恰好是这两件事。他们的设计思路是把数据库领域的分层存储理念搬到 Agent 记忆上热数据放内存温数据放 SSD冷数据归档。翻译成 Agent 的语言当前上下文是热数据可复用流程是温数据需要长期保存的知识是冷资产。架构是四级管道逐层提炼原始对话 │ ├─[第一层] Chat Memory ────── 结构化对话记录SQLite FTS5 全文检索 │ ├─[第二层] Skill ──────────── 最妙的一层自动沉淀可复用流程 │ ├─[第三层] LLM-Wiki ───────── 面向大模型优化的结构化知识库 │ └─[第四层] Code-Graph ─────── 代码关系图谱帮 Agent 理解项目结构我实际用下来每一层的体验第一层Chat Memory终于不用每次重新认识了这是最基础的一层也是最容易出问题的。开发者社区里有一个很火的 ChatGPT 提示词技巧——“请每次都记住我的偏好”。但这句话本身只是告诉模型要记住并没有给模型提供如何记住的机制。记忆不能靠 prompt 工程得靠基础设施。Chat Memory 做的事很简单把对话历史结构化存储到本地 SQLite用 FTS5 做全文索引。Agent 需要回溯时按需检索而不是把整个历史塞进上下文窗口。我实测的效果是跟 Agent 聊过的东西下次会话它确实能检索出来。比如我上一周让它帮我分析过一个 SQL 慢查询这周我提到上次那个慢查询它没有问哪个——直接给出了当时的分析结论。不过这还不是最让我惊喜的。第二层SkillAgent 终于学会了怎么做这一层是整套系统里我最喜欢的设计。Skill 并非硬编码的规则。它是一套从对话中自动沉淀的可复用流程。比如我经常让 Agent 帮我做为新模块写单元测试。第一次它会摸索先找到对应的源码文件理解函数签名生成测试用例调整 Mock 策略。这个过程可能来回十几轮。一旦这个流程被记录为 Skill下次我说写测试它会直接按上次的流程走从头探索这一步直接跳过。这本质上是一种程序性记忆——记的不是你叫什么是你上次怎么做的。这种记忆在工程场景下比事实性记忆有价值得多因为开发者的工作流往往是重复的。我统计过我每天跟 Agent 的交互中至少有 40% 是重复性任务。Skill 把这部分从探索变成了执行效率提升确实肉眼可见。第三层LLM-Wiki项目规范的第二大脑前两层解决的是聊过什么和怎么做的第三层解决的是需要反复用的知识。LLM-Wiki 是一个面向大模型优化的结构化知识库。它在传统 Markdown 文档集合之上进一步将对话和文档中的知识提炼为条目化的结构化数据——项目规范、技术决策、架构设计、踩坑记录统统收进来。我把我项目的 README、架构文档、代码规范文件都扔进去之后Agent 在写代码时明显更懂这个项目了。以前我需要在每次对话里反复强调别用 ORM现在它自己就知道。这一层还有一个特性我觉得很关键它面向大模型优化面向的不是人类阅读。存储格式和检索方式都是针对大模型怎么理解信息来设计的而不是人类怎么读文档。同样的知识用更少的 Token 就能让模型理解——这对成本和响应速度都有直接影响。第四层Code-Graph让 Agent 真正看懂代码最高层是代码关系图谱。它跟传统的 AST 分析工具不同定位是专门为 Agent 设计的代码理解辅助层。Example我让 Agent 修改一个底层函数它需要知道这个函数被哪些地方调用、会不会影响其他模块。传统做法是 grep 或者依赖 IDE 的查找引用但 Agent 没有 IDE。Code-Graph 把代码的静态结构转化为可查询的图数据Agent 在做修改前可以先查一下影响范围。这个功能在大型项目里尤其有用。我试过在一个 200 文件的 Go 项目里让 Agent 重构一个公共工具函数它用 Code-Graph 查到了 17 个调用点一次性改完了所有地方没有一个遗漏。四、数据比感觉更具说服力任何工具光说我感觉不错是不够的。我翻了官方的 README利用几个 Benchmark 数据来自它作为 OpenClaw 插件接入后的实际测试记忆类型Benchmark原始成功率加插件后相对提升Token 节省短期记忆WideSearch33%50%51.52%-61.38%短期记忆SWE-bench58.4%64.2%9.93%-33.09%短期记忆AA-LCR44.0%47.5%7.95%-30.98%长期记忆PersonaMem48%76%58.33%—几个数字印象深刻WideSearch 场景 Token 节省了 61.38%。这个任务需要频繁回溯历史信息传统做法会把大量历史塞进上下文而分层记忆按需检索大幅减少了冗余。我自己的项目里长任务的 Token 消耗大概降了 40% 左右——没到 61%但省下来的都是真金白银。PersonaMem 准确率从 48% 提升到 76%。这是测试 Agent 能否记住用户偏好和特征的长期记忆场景。接近 60% 的相对提升说明分层记忆在跨会话信息保留上确实有效。对应到我的实际体验Agent 确实记住了我喜欢用 sqlx、不喜欢 ORM、测试文件放__test__这些偏好。SWE-bench 和 AA-LCR 分别提升了约 10% 和 8%。这两个任务更多依赖推理能力而非记忆但即使如此减少上下文噪音仍然带来了可观的收益。这也印证了一个道理记忆的价值不仅是记住更多还在于忘掉不需要的。五、我的接入过程两条命令十分钟搞定项目用 TypeScript 编写Node.js ≥ 22.16 即可。接入过程简单# 安装核心包npminstalltencentdb-agent-memory/memory-tencentdb# 在 OpenClaw 中一键安装插件openclaw pluginsinstalltencentdb-agent-memory/memory-tencentdb openclaw gateway restart如果你用的是 Hermes Agent官方也提供了 Docker 镜像一行命令启动dockerrun-d\--namehermes-memory\--restartunless-stopped\-p8080:8080\-eMODEL_API_KEY$MODEL_API_KEY\-eMODEL_BASE_URL$MODEL_BASE_URL\-eMODEL_NAME$MODEL_NAME\-eMODEL_PROVIDER$MODEL_PROVIDER\-vhermes_data:/opt/data\agentmemory/hermes-memory:latest镜像同时支持 linux/amd64 和 linux/arm64。内置了腾讯云 DeepSeek-V3.2 的默认配置也可以自定义模型参数。验证是否正常运行# 检查健康状态curlhttp://localhost:8080/health# 进入 Hermes 对话dockerexec-ithermes-memory hermes所有数据存在本地不需要任何外部 API 或云服务。这对隐私敏感的项目来说是个硬需求——我的代码和对话历史不会上传到任何一个第三方服务器。MIT 协议开源意味着你可以随意使用、修改、商用没有任何限制。六、用了两个月几点实际感受好用在哪里完全本地运行零延迟。之前用 Mem0 的时候每次检索记忆都要走 OpenAI 的 Embeddings API加上 Pinecone 的向量检索延迟少则 500ms多则 2 秒。对于一个频繁检索记忆的 Agent 来说这个延迟叠加起来非常影响体验。本地 SQLite 的检索几乎是瞬时的。分层设计让检索更精准。不同记忆不该被同等对待。Skill 层和 LLM-Wiki 层把不同粒度的信息分开存储Agent 检索时不会大海捞针。我在实际使用中明显感觉到Agent 拉出来的记忆片段更对题了。证据可溯源。每一层记忆都可以向下追溯。Agent 引用了某个 Skill我可以追溯到它是在哪次对话中形成的。记忆不再是黑盒出了问题可以逐层排查而不是对着一个模糊的检索结果干瞪眼。还需要优化的问题团队协作记忆还在路上。目前主要面向个人 Agent但我跟同事共享项目时希望大家的 Agent 能共享同一个知识库。官方 GitHub 上有team相关的分支应该是在做这个方向但还没正式发布。记忆冲突没有智能解决。当我对同一个规范在不同时间说过不同的话——比如一开始说连接池最大 25后来改成 50——Agent 目前依赖时间戳判断哪个更新但缺少更智能的冲突检测和合并机制。这在小团队里影响不大规模化之后会是个问题。框架支持还需要扩展。目前主要支持 OpenClaw 和 Hermes。如果你用 LangChain 或 CrewAI需要自己写适配代码。不过既然开源了社区贡献适配层应该只是时间问题。七、我为什么觉得这个方向是值得关注的Agent 的记忆问题可能是当前 AI 应用落地最大的隐形瓶颈。推理能力在提升工具调用越来越成熟多模态大一统也在推进——但如果 Agent 每次会话都是全新开始这些能力都只能发挥单次对话的上限。记忆是 Agent 从好用走向能用的必经之路算不上锦上添花。腾讯云数据库团队做这件事角度选得精准。记忆系统的本质是存储检索这正是数据库的核心能力。他们没去发明新的算法范式而是用成熟的分层存储理念把 SQLite、FTS5、结构化索引这些被验证了几十年的技术重新组合解决了一个新场景的问题。没有追求架构上的标新立异扎扎实实地把分层存储、按需检索、本地运行这三件事做到位了。开源社区对这种务实方案的反应也说明了一些东西。三个月 13.3k Star在基础设施类项目里不算慢。说明大家都有同一个痛点也都在找同一个解法。如果你也在被 Agent 的失忆症折磨建议花十分钟跑一下试试。不需要迁移整个工作流先拿一个小项目跑几天看看 Agent 是不是真的记住了。项目地址https://github.com/TencentCloud/TencentDB-Agent-Memory协议MIT技术栈TypeScriptNode.js ≥ 22.16本文数据来自项目官方 README 及腾讯云官方发布文章实测体验基于 2026 年 5 月至 8 月的个人使用记录。