结论先行
我给自己的 AI 助手装了两套长期记忆，用同一个事实、同一组问题做了对照测试。
结果很干脆：关键词记忆全军覆没，语义记忆全中。
| 测试问题 | 原方案（HRR向量） | 新方案（神经嵌入） |
|---|---|---|
| 家里的动物 | ❌ 0 条 | ✅ 命中 0.604 |
| 服务器机箱上的东西 | ❌ 0 条 | ✅ 命中 |
| 橘猫 轮子（含关键词） | ✅ 命中 | ✅ 命中 |
差别不在"存没存"，而在能不能用"意思"找到东西。
两套系统，本质是两种检索哲学
先说清楚我在比什么。
方案一：超维度向量（HRR）
这是 Hermes 自带的记忆插件。它把每条事实编码成 1024 维的"超维度向量"，做代数运算来检索。优点是零成本、离线、秒回。缺点也很直接——它不理解语义。
我实测：往里写一条"用户养了一只叫『轮子』的橘猫，它最喜欢趴在服务器机箱上取暖"，然后问它"家里的动物"。
返回 0 条。
数据明明在库里，26 条事实、26 条都有向量，一条都没漏。问题在于：HRR 靠的是词形匹配加代数运算，而"家里的动物"和"橘猫"之间没有任何字面上的关系。
方案二：神经嵌入（真 embedding）
腾讯这套 TencentDB Agent Memory 走的是另一条路：用真正的神经网络模型把文本转成语义向量。我用的是 NVIDIA 的 nemotron-3-embed-1b，2048 维。
同一个事实，同一个问题"家里的动物"——命中，相似度 0.604。
这两个查询的字面重叠度是零。0.604 这个分数只能来自语义空间的距离，不可能是关键词匹配。
真正的分水岭：注入方式
如果只是检索精度差异，还不至于让我换方案。真正让我下决心的是记忆怎么进到对话里。
旧方案：手动调工具
HRR 那套的记忆，要我自己想起来去查。也就是说——我得先知道"我可能不记得什么"，才可能去查。 这在一个上下文被压缩、跨会话的助手身上，基本等于没有。
有个更尴尬的实测结果：切到新方案之后，我翻了旧库，发现里面有 26 条事实。其中一部分写着"用户讨厌 AI 腔"、“用户要求先结论后原因”、“用户要求清空思维链只给 final”。
这些偏好我当时一条都看不到。因为它们躺在库里，不自动注入。它们能生效纯粹是因为另有一份静态文件（MEMORY.md）也写了同样的内容——那是独立于记忆插件的另一套机制。
换句话说：旧方案存了东西，但没送进我的视野。
新方案：自动预取
腾讯这套的做法是，每轮对话开始前，系统自动拿当前问题去检索相关记忆，塞进上下文。不需要谁主动去查。
还有个细节值得说：它分四层——L0 原始对话 → L1 原子事实 → L2 场景 → L3 角色画像。L0 是自动捕获的，每轮对话结束时后台落盘，然后由 LLM 从原始对话里抽出结构化事实，往上叠。
这意味着你不需要再对我说"记住……记住……"。捕获是自动的，抽取是后台的。
代价：算一笔真实的账
天下没有免费的记忆。说一下实际成本。
每轮对话的抽取开销：后台要用 LLM 从原始对话里提炼事实，一次大概 1~2K tokens。按 DeepSeek 的价，折下来一个月三到五块钱。嵌入查询更便宜，一次不到一分钱。
一个必须说的缺陷：这套架构里，Gateway 进程是跟着 Hermes 进程生灭的。L0 捕获是即时的，但 L1 抽取是后台任务。
我实测就踩到了：一次性跑完一轮对话，进程退出时 L1 还没抽取完，那条记忆就没落到库。手动等 45 秒才出来。
所以如果你追求抽取稳定，得让 Gateway 常驻。这是这套方案的真实门槛。
踩坑记录
整个过程踩的坑不算少，挑三个有代表性的。
| 问题 | 原因 | 解决 |
|---|---|---|
| npm 拉包失败 | .env 里设了全局代理 7897，而 npm 的 NO_PROXY 没覆盖 | 跑 npm 前先 unset HTTP_PROXY HTTPS_PROXY |
| Gateway 起不来 | npm 新版默认禁止 postinstall 脚本，esbuild 二进制没装 | 显式放行 esbuild，验证 .bin/esbuild --version 有输出 |
| 嵌入配置"看起来没生效" | 配置文件里 embedding/recall 必须嵌在 memory: 下，不是顶层键 | 加载配置打印出来验证，别靠猜 |
还有一个变更层面的坑，值得单独说：
Hermes 硬限制——同一时刻只能挂一个外部记忆插件。我切到新方案的那一瞬间，旧方案的工具就被禁用了。数据没删（SQLite 库原封不动躺在那），但能力没了。
这不是配置能绕过的限制，是架构约束。
我是怎么处理的
明白了这个约束之后，处理方式就清楚了：把真正有价值的事实，从旧库物理迁移到那份独立于插件的静态文件里。
旧库 26 条，逐条比对后，大约 15 条已经在静态文件里了（冗余），剩下的里面只有 5 条有真正的长期价值：
| 内容 | 为什么留 |
|---|---|
| 清空思维链只给 final，结论先行 | 直接决定我每次回复的形态 |
| 女娲研究→DOCX→飞书工作流 | 高频工作流，质量要求极高 |
| 本地模型独立命名 provider | 配置偏好，反复用到 |
| 微信公号文章保存目录 | 每次发文都要用 |
| GitHub 镜像 + 代理探测顺序 | 环境事实，绕不开 |
迁移完，静态文件 3530 字符，估算约 2033 tokens。原来那份 3152 字符本来就在跑，多这几百字符没有压力。
数据也都留了备份，随时可以切回去。
到底该选哪个
给你一张判断表。
| 你的情况 | 建议 |
|---|---|
| 只需要手动存几条偏好，成本敏感 | 用原方案（HRR），零成本够用 |
| 希望 AI 自己记住、自己想起来 | 上新方案，语义召回是质变 |
| 经常跨会话、上下文被压缩 | 上新方案，自动预取是刚需 |
| 不能接受后台进程常驻 | 用原方案，新方案需要 Gateway 常驻 |
| 两个都想要 | 做不到，架构限制一次只能挂一个 |
我的结论：如果你的助手经常跨会话工作、上下文会被压缩，语义记忆带来的差别是代际的——不是"好一点"，是"能用"和"不能用"的区别。一个记不住你说过什么的助手，和一个能自己想起来、还能被"意思"检索到的助手，是两种东西。
代价每月三五块，加一个需要常驻的进程。值。
中美 AI 的差距还在缩：斯坦福 HAI 2026 报告显示，中美顶级模型性能差距已收窄到 2.7%；投资规模上美国仍以约 23:1 领先；但论文与专利数量中国双第一，工业机器人装机量是美国的 9 倍。模型追得很快，落地的场景和数据，才是长期变量。
如果觉得有帮助，点个「赞」和「在看」支持一下 👇