腾讯 Agent Memory 开源项目解说 1 | Agent 团队"换人就失忆"问题出在哪
digoal约 9 分钟TencentDB Agent Memory 开源项目回答的是一个问题: 一群 Agent 协作时,怎么把"已经会的事"沉淀下来,不让下一个人从零开始?
OPC 养不起八个失忆的 AI
2026 年的开发者大多有过这种体验:早上让 Claude Code 帮一个老项目接 OAuth2,折腾两小时调通了;下午换 Codex 改同样的模块,它对着同一个文件问"这是什么";晚上开 CodeBuddy 修 bug,又把 OAuth2 的来龙去脉讲了一遍。
不是工具不好——是工具之间没有交接。Agent 的"上下文"是一次性的:会话结束,记忆蒸发。下次再启动,所有走过一遍的弯路都得重新走一遍。
如果你只有一个人用一款 Agent,这只是烦;如果你是一个"一个人的公司",一个人分饰多个角色——调研、写代码、审 review、画架构、写公众号——同时让几款 Agent 协同,这种"换人就失忆"就从烦变成了生产力的硬天花板。
TencentCloud/TencentDB-Agent-Memory 是腾讯云在 2026 年开源的一个项目,目标正是治这个病。它的口号很直白:**Agents remember. Humans innovate.**——让 Agent 替人记住,让人腾出手来创新。
但读完它的全部源码、CHANGELOG、ROADMAP 之后,我更愿意把它叫做 **Agent 团队的"记忆中枢"**——一个介于"工具"和"平台"之间的东西。
这篇文章先用最朴素的视角回答三个问题:它是什么,为什么是现在,和你有什么关系。
一个看似朴素、实则要害的问题
项目创始人在 README 里第一句话就承认:这事儿不是从宏大理论出发的,是从一个很实际的问题出发的。
How do you reduce repetitive work when using Agents?
——怎么减少使用 Agent 时的重复劳动?
如果项目背景已经解释过,就不该在新会话里再讲一遍。如果文档已经读过,就不该每个 Agent 都从第一页重读。如果一套已经验证过的工作流,就不该下次还得重新发现。
这件事的本质不是"记忆对话"。对话本身不重要——任何"上下文里都该有的信息"都该被记住、组织、复用。
项目用一句话把价值链点透了:
已有信息 → 可复用记忆资产 → 更少回合 → 更少返工 → 更稳的结果与更高效率
一句话:别让 Agent 团队每一代都重新发明轮子。
它究竟在卖什么
市面上的"Agent 记忆"工具很多,Mem0、Zep、Letta、Cognee、Supermemory,各家卖点不同。但 TencentDB Agent Memory 有几个相当独特的设计选择,让它看起来更像一个中台而不是一个工具。
1. 团队资产,不是个人笔记
Chat Memory、Skill、Wiki、CodeGraph 这四类资产,在系统里有完整的所有权、版本、状态、可见性、用量、绑定管理。新建的资产默认是 private,只属于 Owner;要分享给团队必须显式操作,不是"自动泄露"。
四类资产各有分工:
| Chat Memory | ||
| Skill | ||
| Wiki | ||
| CodeGraph |
四者并列的好处:**Chat Memory 解决"我是谁",Skill 解决"怎么做",Wiki 解决"产品/流程是什么",CodeGraph 解决"代码在哪、动谁"**——完整覆盖了一个 Agent 团队会需要的"沉淀物"。
2. 不是把记忆"塞进 prompt",而是给 Agent "装配装备"
普通 RAG 的逻辑是:用户问一句话 → 去文档库搜 → 把搜到的塞进 prompt → 让 LLM 答。
TencentDB Agent Memory 的逻辑是:每个 Agent 在创建时就绑定好一组记忆资产(Skill x N、CodeGraph x M、Wiki x K、Chat Memory x J),由 Memory Hub 决定它能看到什么、什么能用;运行时不是"全量注入",而是通过 /v3/tools/list + /v3/tools/call 这两个端点按需调用。
这就是 README 里反复强调的 Agent Loadout 模型——给每个 Agent 装配一个角色装备,而不是所有人共用一个全局 prompt。
🔭 调研 Agent
├── 用户访谈 Chat Memory
├── 市场研究 Wiki
└── 竞品分析 Skill
🛠 编码 Agent
├── 产品 Wiki
├── 项目 CodeGraph
└── 功能交付 Skill
🧪 Reviewer Agent
├── 历史事故 Chat Memory
├── 项目 CodeGraph
└── 上线检查清单 Skill
同一个团队、不同角色、不同装配,看到的"团队经验"完全不一样。
3. 显式超越 RAG 的五个维度
README 里有一张对比表,把"聊天历史"、"标准 RAG"、"TencentDB Agent Memory"放到一起比较。差异点直接戳穿 RAG 的天花板:
RAG 答的是"什么能找到";团队记忆还要答"谁能用、哪一版有效、哪个 Agent 应接收"。
这不是文案话术,而是真实的设计取舍——你会在后几篇看到,这套语义渗透到了每一个 API、每一条 ACL、每一次绑定。
为什么是 2026 年开源这个
把这事放到时间线上,有几个独立的线索在 2026 年汇合到了一起:
第一,Agent 数量从"一个"变成"一群"。 当年 Mem0 之类工具解决的是"单个 Agent 怎么记得住",那时候用户是一人一 Agent。今天 Claude Code、Codex、CodeBuddy、Hermes、WorkBuddy、OpenCode、DeepSeek Harness(代号 dsh)、OpenClaw 这八个 IDE/CLI/Harness 类工具并行使用已经是常态。一个开发者跑两个 Agent 协作不奇怪;一个"一人公司"同时调度四五个 Agent 各司其职也常见。Agent 数量爆炸让"团队记忆"从一个 UX 优化升级成了协作基础设施。
第二,LLM 的 context window 不再稀缺,但 context 质量变得稀缺。 早期大家焦虑"装不下",现在动辄 200K、1M 的窗口,塞是塞得下,但塞进去 50 个文档的 LLM 反而不如只看 3 个相关文档的 LLM。Memory Proxy 把这套理念翻译成了产品语言:默认 L2/L3 上下文快速引导,具体事实走 BM25 + 向量 + RRF,最终用条数/字符预算/超时三重限速——避免"记忆淹没 context"。
第三,从 Karpathy 的 LLM Wiki 到 Hermes Agent, 这个项目明确地站在两个开源巨人的肩膀上。Wiki 的设计直接致敬 Karpathy 的 LLM Wiki("把文档当成 LLM 维护、渐进生长的知识产物");Skill 资产的管理基于 Hermes Agent(Nous Research)的 Skill 系统优化而来;CodeGraph 直接复用了 colbymchenry/codegraph 的代码索引设计。这三个开源项目本身就是 2025-2026 年"Agent 工程化"最被引用的范式,TencentDB Agent Memory 的发布时间卡得很准。
第四,MongoDB 后端在 2.0.2-beta.1 上车。 v2.0.0 早期只支持 SQLite(本地)与 TCVDB(腾讯云向量数据库)两种存储;2026-09-07 的 v2.0.2-beta.1 把 MongoDB 作为"试验特性"加进来,目的是给那些评估非 SQLite 数据面、需要 mongot 原生全文检索的用户一个选项。一个 Agent 记忆产品能不能在生产用,数据面选择是绕不开的——SQLite 撑不住万人团队时,后端多样性是真痛点。
第五,PersonaMem benchmark +59% 的"开箱即用"。 README 给了个很硬的数字:同一个 Agent,在 PersonaMem 评测集上,接上 TencentDB Agent Memory 之前是 48%,接入之后是 76%,相对提升 **+59%**。
需要诚实交代:这个数字是官方在自家 README 里宣称的 benchmark,没有看到复现所需的测试集、提示词、参数全部开源。换言之,+59% 是项目方说它能做到的水平,不是第三方独立复现的保证。但这个数字至少说明两件事:项目方对自家效果有信心;并且它不是空喊"我们做了记忆",而是绑了一个公开评测集(PersonaMem)去量。你在决定是否引入前,应该在自己的数据集上复测一遍,别直接把这个数字当作 SLA。
一个真实的使用场景
光看架构图太空。来看一个具体场景——
假设你在搭"PostgreSQL DBA Copilot":一个 Agent,负责每天早上帮你巡检数据库、总结前一天事件、给出次日待办。
没有 TencentDB Agent Memory 的世界:
第 1 天,Agent 学到了你的 12 套 PG 集群清单、磁盘阈值、巡检节奏 第 7 天,新会话,Agent 问"你的集群在哪?" 第 8 天,你又把 PG 12 升 PG 16 的告警信号讲一遍 第 14 天,你做了一个"高可用切换演练 checklist",Agent 不知道这个 checklist 存在,你自己凭记忆把步骤列出来 第 30 天,Agent 升级到新版,你跟它说"用 pg_stat_statements + auto_explain 这套方法分析慢 SQL"——它下次又忘了
有 TencentDB Agent Memory 的世界:
第 1 天,巡检脚本沉淀成 Skill,绑定到这个 Agent 第 2 天,你把 12 套 PG 集群清单喂进 Wiki,链接到产品 Wiki 的"集群拓扑"页 第 3 天,你之前已经聊过 PG 16 升级的所有坑,被自动精炼成 L2 Scenario,Agent 一上来就有 第 7 天,新会话,Agent 第一句话:"早上好,昨天 3 套集群有异常事件,巡检节奏按你前两周习惯的 '9:00 + 21:00' 跑。" 第 30 天,你把自动巡检脚本改了一版,Skill 自动版本化,下次 Agent 直接用新版
差别不是 30% 或 50%,差别是第 30 天的 Agent 是否还在替你重复第 1 天的工作。
我该用它吗?三段式判断
不要被开篇的赞美迷惑,任何工具都有自己的适用边界。给你三个判断维度:
✅ 强烈建议试
你的"一个人公司"同时调度 ≥ 2 个 Agent 协作 你的项目历史超过 3 个月,有大量"已经做过"的事 你的团队有 3+ 个不同角色(调研/编码/Review/写作),希望它们各自背不同记忆 你愿意投入"第一周"整理 Wiki 和 CodeGraph,换取之后每周的复利
⚠️ 先想清楚再上
你是单 Agent 重度用户,一周只用一个 Claude Code → 这种场景下杀鸡用牛刀,先做好自己的笔记/SKILL.md 你的项目极简(单文件脚本、单数据库、单 API),记忆资产没有"复杂可共享"价值 你对数据合规有极端要求,无法接受对话内容进入任何中央存储——这点我建议你看 MongoDB 后端的部署方式,以及 README 里"private 默认不分享"的兜底设计
❌ 暂不建议
你只是想要一个"对话能跨会话保留"的轻量记忆——这种 Mem0 / Zep / Cognee 都更轻 你的 Agent 框架不在它原生支持的 8 个客户端里,且你没能力写适配器 你希望它"开箱即用,零配置"——诚实地说,第一次启动到真正好用至少要半天到一天,Wiki 整理 + CodeGraph 索引 + Skill 沉淀都要时间
文章系列预告
这一篇是开篇科普。接下来 6 篇会按下面顺序展开:
架构全貌:四件套(MemoryCore / MemoryKnowledge / MemoryProxy / MemoryPanel)+ SDK 的边界与协作 L0/L1/L2/L3 精炼管线:从原始对话到 Persona 文件,异步流水线的实现细节 Wiki + CodeGraph 双引擎:文档和代码如何成为 Agent 的"按需工具"而不是 context 负担 MemoryProxy 反向代理:一份 <tdai_injections>XML 喂饱 8 种 Agent 客户端的设计Memory Hub + Agent Loadout:团队资产控制面板的可见性、版本、ACL 语义 实战与选型:什么时候用、什么时候别用,以及与同类方案对比
如果你是入门者,读这一篇就够了,其余的按需;如果你是架构师或 DBA,建议你按顺序读完 6 篇源码级别的解析,你会看到一个非典型的"中国云厂做的开源 Agent 中台"是怎么把记忆这件事工程化的。
参考
TencentCloud/TencentDB-Agent-Memory · GitHub — 当前版本 v2.0.2-beta.1,发布日期 2026-09-07 Andrej Karpathy · LLM Wiki — Wiki 资产的设计灵感 Hermes Agent · Nous Research — Skill 资产的管理基础 colbymchenry/codegraph — CodeGraph 资产的代码索引基础 PersonaMem Benchmark — 项目方引用的评测集(48% → 76% 的来源)