用多个 AI Agent 干活的人迟早撞上同一堵墙:Hermes 记得的事,Claude Code(下称 CC)不知道;上周跟 Codex 交代过的架构决策,这周它忘得干干净净。每个 Agent 都有自己的记忆文件、各自的技能目录、互不相通的上下文。你变成了三个 Agent 之间的人工中继——重复交代背景,重复粘贴文档,重复解释"我们上次是怎么定的"。
2026-08-24 起,我用 TencentDB Agent Memory(社区常简称 TDAI Agent Memory,下文用 TDAI 指代)私有化部署了一套共享记忆栈,让三个 Agent 走同一个记忆服务。第二天(08-25)一个上午,我把知识层的三块拼图——Obsidian 知识库 wiki、Hermes 技能库 wiki、10 个仓库的代码图谱——全部接了进去。本文是这次搭建的完整实录,包括数据、踩坑和修复,以及我对这套系统诚实的好评与差评。
TDAI 是什么:四大资产,一个中枢
TDAI 是腾讯云数据库团队开源的团队级 Agent 记忆中枢(截至 2026-08-25,GitHub 约 24,300 Star / 2,240 Fork,MIT 协议,2026 年 4 月建仓)。它把 Agent 的"经验"沉淀为四类可治理的资产:
| 资产 | 存什么 | 对应的传统概念 |
|---|---|---|
| Chat Memory | 对话流、事实、场景、画像 | 长期记忆 |
| Skill | 操作手册、流程知识 | 程序性记忆 |
| LLM-Wiki | 文档与知识的 LLM 改写版 | 陈述性知识 |
| Code-Graph | 代码仓库的结构化图谱 | 空间/结构记忆 |
架构上是四个服务:MemoryCore(记忆内核)、MemoryKnowledge(知识子系统)、MemoryProxy(代理网关)、MemoryPanel(管理面板)。接入方式很克制——不改 Agent 协议、不装插件,把 Agent 的 base URL 指到 Proxy 就完事。官方列出的适配名单包括 DeepSeek Harness、Claude Code、Codex、CodeBuddy、WorkBuddy、Hermes、OpenClaw。我的组合是 Hermes 走原生 memory 工具,CC 和 Codex 走各自官方适配层,共享同一份团队记忆。
值得注意的一个细节:README 的致谢部分写明,它的 Skill 资产管理复用了 Hermes Agent 的部分 Skill 相关代码,而 LLM-Wiki 层的设计直接受 Karpathy 的 LLM Wiki 启发——文档作为"由 LLM 维护、增量生长的知识工件"。官方给出的 PersonaMem 评测成绩是从 48% 提升到 76%(相对提升 59%)。这是厂商自测,参考即可,但方向没问题:记忆的价值在召回,不在存储。
Chat Memory 内部是四层结构:L0 原始对话 → L1 原子事实 → L2 场景块 → L3 用户画像,自动完成从对话到画像的提炼。而 Wiki、Code-Graph、Skill 属于 Knowledge 子系统,和四层记忆是两套独立的数据通路——这个隔离性是后面"倒技能库不会污染记忆"的根据。
实录一:知识库全量入库,换对模型失败率从 37% 到 0
第一块拼图是我的 Obsidian vault——个人知识库,418 个源文件,覆盖项目调研、架构决策、会议纪要、读书笔记。管道是单向同步:vault 是唯一权威源,TDAI 侧只做可检索副本,sha256 增量判断,每 6 小时 cron 跑一轮。
首次全量 ingest 的过程很能说明问题。第一晚用 glm-4-flash 做提取模型,32 个文件挂了 12 个,失败率 37%——症状是协议遵循失败,输出只有 500-1000 tokens 的半截 JSON。换成 glm-5.3 重跑(2026-08-25 上午 09:49 检查点):
| 指标 | glm-4-flash | glm-5.3 |
|---|---|---|
| 失败率 | 12/32(37%) | 0/315(0%) |
| 单文件耗时 | 60-140s | 约 50s |
| 输出密度 | 500-1000 tokens | 3000-5500 tokens |
同一个 pipeline,只换模型,协议遵循问题彻底消失。这给所有做批量 LLM 提取的人一个直接结论:提取模型的质量决定了记忆管线的吞吐下限,省钱模型在结构化输出上的失败成本会吃掉省下的钱。全量 418 文件跑完后自动进入 merging/indexing 阶段建 BM25 索引,之后任意 Agent 提问都能命中 vault 里的知识。
实录二:技能库变 wiki——补上"程序性记忆"的短板
第二块拼图最有意思。我的 Hermes 技能库有 204 个 SKILL.md(全库 762 个 .md、6.6MB)——那是几百次任务沉淀下来的操作手册:怎么部署、怎么审计、怎么踩坑绕行。问题在于这些"流程知识"只存在于 Hermes 一侧:CC 和 Codex 完全看不到。
四层记忆解决不了这个:L0-L3 存的是"事实"(发生了什么、你是谁),不存"流程"(这件事该怎么做)。技能库正好是流程知识的载体——所以把 204 个技能同步成 TDAI 独立 wiki「hermes-skills」,等于给三个 Agent 共享了一份程序性记忆。
方案上有两个关键取舍:
单独建 wiki,不和 vault 混。 我的 vault 里本来就有技能相关的沉淀(技能审计报告、架构分析),如果和 SKILL.md 原文倒进同一个 wiki,BM25 检索时同题材会互相抢排名——搜"SOLID",技能原文和我的审计报告混在一起,而 wiki 页是 LLM 改写过的,两版对照容易误导。分 wiki 存储,查询时各查一次,天然隔离。
只同步 SKILL.md,不带 references/。 全库 762 个文件按约 70s/文件的 ingest 速度,全量要 14 小时以上;只收 204 个 SKILL.md 约 4 小时,一晚跑完。references/ 大多是一次性调研文档,先用主文件,检索发现召回缺口再增量补——这是典型的"先跑通再补全"。
同步铁律和 vault 一致:技能库本地目录(有 git 镜像)是唯一权威源,TDAI 只读,绝不写回。单向管道 + sha256 增量,不存在双向同步的打架问题。
实录三:10 个代码图谱,冷启动成本变"存档"
第三块拼图是 Code-Graph。TDAI 的说法很准确:大多数 Agent 的第一个任务是在重新学习你的项目——而你已经为这个学习付过一次费了。Code-Graph 把这笔学费变成存档:Agent 通过 /v3/tools/list 发现能力,用 /v3/tools/call 按需读相关页面、源码和影响路径,图谱数据只在真正需要时才进上下文。
2026-08-25 上午建成的图谱(全部 ready,查询已验证):
| 仓库 | 规模 |
|---|---|
| TencentDB-Agent-Memory 上游源码 | 745 文件 / 13,804 节点 |
| task-vault | 98 文件 / 1,555 节点 |
| desktop_portal | 152 文件 / 1,481 节点 |
| shujietai | 112 文件 / 1,640 节点 |
| cdut_stu_agents | 127 文件 / 1,622 节点 |
| edu-agent | 68 文件 / 878 节点 |
| hermes-voicedesk | 31 文件 / 338 节点 |
| django_jwt_test_project | 20 文件 / 102 节点 |
| tencentDDNS | 8 文件 / 39 节点 |
实测最能说明价值:在 edu-agent 图谱里 explore"错题本",准确命中前端 MistakesView.vue 的 removeMistake 和后端 mistakes.py 的 MistakeOut,还带调用方分析。这意味着任何接入的 Agent 问"错题本功能怎么实现的",不需要重新读一遍代码库——这正是 Hermes 召回机制讨论过的上下文效率问题在代码域的解法。
两个诚实记录的边界:私有仓库(guancyxx/skills)建不了图——Code-Graph 目前只支持公开 HTTPS 仓库,官方 README 也明确说私有仓和 SSH 凭证支持"仍在完善中",这不是我的部署问题,是上游功能边界;14 个第三方 fork 仓没建,第三方代码不是我的记忆资产。
至此知识层三板块齐了:vault 知识 wiki + 技能库 wiki + 代码图谱,叠加已有的四层记忆,三个 Agent 共享同一套"大脑"。
踩坑记录:三个只有动手才会遇到的坑
这部分是文档里不会写的。
坑一:413 被误报成"内核服务不可用"。 通过面板导入一个大型技能,报错 KERNEL_UNAVAILABLE。查了半天内核根本没挂——真因是技能整包超过内核网关默认 1MiB 请求体上限,413 错误在面板层被误报成了"内核不可用"。修复:start-memory-core.sh 注入 MEMORY_MAX_BODY_BYTES=50MB 后重启容器。教训:面板的错误文案不可信,排查先看内核网关日志。
坑二:单文件正文硬上限 50,000 字符。 那个技能的 SKILL.md 正文约 78k 字符,超过 BODY_MAX = 50_000——这是内核里的硬编码常量,不可配置。解法是拆分:主文件保留前 48,939 字符(合规),溢出的 29,931 字符拆成 resource 文件 SKILL-PART2.md 一并存储,主文件尾部加指引。50 个 references/*.md(约 294k 字符)全部作为 resources 导入,总包 358KB,内容零丢失。验证方式是读回比对:抽查的 resource 文件与本地逐字符一致——导入是否成功要看读回内容,不能只看接口返回 code:0。
坑三:同名重复导入不会覆盖。 面板重导同名技能,内核的行为是新建而不是覆盖,会产生重复版本。修复只能删旧导新,不存在"覆盖式更新"。
评价:好在哪,差在哪
用了一个上午加一晚,我的判断:
值得肯定的:
- 接入设计克制。base URL 指过去就能用,不改协议不装插件,这比一堆 MCP server 的方案干净得多
- 资产隔离做得对。Knowledge 子系统和四层记忆互不污染,倒技能库时我最担心的检索污染问题,用分 wiki 就解掉了
- Code-Graph 的按需进入上下文设计正确——图谱是工具,不是每次都注入的背景板
- 对多 Agent 个人开发者,这是目前少有的"一个中枢管全部记忆形态"的开源选择
要吐槽的:
- 私有仓库 Code-Graph 不支持,对把代码放私有仓的人是硬伤(官方在修)
- BODY_MAX 硬编码 50k 不可配,长文档必须手工拆分,这个体验很原始
- 面板错误文案误导(413 报成内核不可用),排查成本被无辜放大
- ingest 速度约 50-70s/文件,几千文件级别的大库要按"天"规划首轮入库
- 同名导入不覆盖,资产管理的心智负担在用户这边
这套系统目前标 Beta,上面的坑一半是功能边界一半是工程成熟度,方向我认可。
结论
三个 Agent、四层记忆、三块知识资产,现在指向同一个大脑。这次搭建最值钱的不是工具本身,而是三个可复用的判断:
- 记忆要分形态治理。 事实(L0-L3)、流程(Skill)、知识(Wiki)、结构(Code-Graph)是四种不同的东西,混在一个池子里必然检索污染,分资产分 wiki 是正解。
- 权威源永远在本地,TDAI 只读。 Obsidian 和技能库 git 仓是唯一权威源,云端只做可检索副本,单向同步让系统永远可重建——这也是我在 Task Vault 里坚持的同一原则:状态的可持久化必须伴随可重建。
- 批量提取别在模型上省钱。 37% 到 0% 的失败率差异,意味着 glm-4-flash 省下的 token 费全亏在重试和看护上。
如果你也在多 Agent 工作流里当"人肉中继",这套方案值得一个上午。至于 Agent Skills 生态往哪走、记忆会不会成为 Agent 的下一个标准配件——TDAI 的 24k Star 至少说明,这个需求是真实且普遍的。
参考资料
- TencentCloud — TencentDB-Agent-Memory GitHub 仓库(截至 2026-08-25 约 24,300 Star,MIT,Beta)
- 腾讯云开发者社区 — TencentDB Agent Memory 正式开源:让 Agent 沉淀经验,让人专注创造(2026-05-14)
- bowen-upenn — PersonaMem 评测集
- Andrej Karpathy — LLM Wiki
- Nous Research — Hermes Agent(其 Skill 代码被 TDAI 部分复用)
- 本站 — Hermes 召回机制深度解析
- 本站 — Task Vault:用 Obsidian 插件管理 AI Agent 任务
- 本站 — Agent Skills 生态观察