给 Hermes 配个本地零成本、原生中文的记忆：honcho 换 Holographic 落地，顺带拆穿一个 SQLite 误报

每次开新会话，系统都刷这么一条：

Memory provider ‘honcho’ is selected but reports unavailable – external memory is disabled for this session.

外部记忆配了，但每次都说"不可用"。查了一下：memory.provider 设的是 honcho，可 ~/.hermes/.env 里 HONCHO_API_KEY 是个占位符 sk-...，根本没填真 key。结果就是认证失败、外部记忆整条链路挂着，每次会话都要吃一次这条噪音。

这篇文章记录我把它彻底解决的过程：选型 → 落地 Holographic → 验证中文召回 → 拆穿一个 SQLite 误报 → 顺带把 provider 配置迁到官方新 schema。全程本地、零成本，不引入新的 SaaS 依赖。

一、先搞清楚：honcho 值不值得填 key 用

honcho 是 SaaS 记忆服务，有两种形态：

我这一阵子的总原则是本地可控、零成本、能复利、不上新 SaaS。所以没打算为 honcho 专门去申请 key。转头对比了一圈同类（Holographic / ByteRover / Mem0 / Letta / Hindsight / Supermemory），选了 Holographic：

• 本地插件，不依赖外部服务；
• 零成本；
• 原生中文：底层 jieba 分词 + OpenCC 简繁归一，这对中文用户的记忆召回是决定性优势；
• 自带、无额外 CLI 依赖（ByteRover 要多装一个 brv）。

二、落地：装插件 → 启用 → 补 numpy → 中文冒烟

# 1) 先清掉死配置，止住噪音（走受保护 config set，不手改 config.yaml）
hermes config set memory.provider ''

# 2) 装插件（源 github.com/itpartypattaya/hermes-plugin-holographic）
hermes plugins install holographic

# 3) 启用
hermes config set memory.provider holographic
hermes memory status     # 应显示 available

两个坑：

1. clone 插件时 GnuTLS 报错（代理到 GitHub 的 TLS 握手失败）。别一上来就怪频道——开 WARP 后重试就成功了。
2. HRR 语义层依赖 numpy，缺了它语义召回会静默降级成纯关键词。补上 numpy>=1.26,<3（其实嵌入运行时自带 2.5.1，见后文，这里装了个双保险）。

中文召回冒烟（关键验证）：写个脚本，用中文 query 去搜，确认FTS5 全文层和 HRR 语义层都不依赖精确关键词——也就是说你搜"显存爆了怎么办"，它能把"VRAM 不足 OOM 的排查"召回来，而不是只匹配字面词。这一步过了，Holographic 才算真的能用。

三、那个 SQLite 误报：差点白折腾一场

冒烟测试时，Holographic 运行时冒出一条告警：

SQLite 3.50.4 有 WAL 重置数据损坏 bug，已自动降级 journal_mode=DELETE

我一开始吓到了——以为"生产记忆系统正跑在一个会损坏数据的 SQLite 上"。于是想"彻底一次解决"，准备把 venv 重建到 Python 3.14。

结果用 hermes 自带的 probe_sqlite_runtime 探针逐个解释器一测，发现我查错了对象：

也就是说：那条 3.50.4 降级警告，只是我拿闲置的 .venv（3.11.15）跑测试才触发的；真正在跑的记忆系统（CLI + gateway）用的是 embedded Python 3.14.7 / SQLite 3.53.1，WAL 正常、没有损坏风险。 ~/.hermes/memory.db 当时也还没生成（首次会话才建，届时跑在 3.53.1 上）。

这条的教训很值钱：诊断 SQLite 漏洞，必须定位实际运行时解释器，而不是随便找一个 venv 测。hermes 生产走 embedded 解释器，dev 的 .venv 完全是两回事。我之前差点让"彻底解决"变成一场对着错误对象的空转。

.venv（3.11.15/3.50.4）不在生产路径上，留着无害；想彻底消除隐患就 rm -rf .venv && uv sync（跟 .python-version=3.14 对齐），但对正在跑的系统零影响。当前选"不管它"。

四、顺带：把 provider 配置迁到官方新 schema

hermes doctor 报 8 个问题，其中一个是：provider 还挂在旧的 custom_providers（列表）里，而 0.22.3 运行时已经改用顶层 providers（对象）——旧列表被静默忽略。

我不手改 config.yaml，而是走 hermes 内部迁移函数，把 5 家（agnes / zai / tongyi / sensenova / free-ride）从列表转成对象，model 列表和 API key 环境变量引用原样保留，再删掉旧列表。验证后 hermes doctor 从 8 → 3（剩下的是 API key / npm 类，和本主题无关）。

五、命令速查

hermes memory status                          # 查记忆 provider 状态
hermes config get memory.provider             # 看当前 provider
hermes config set memory.provider holographic # 切 provider（'' = 清空）
hermes plugins list                            # 查插件
hermes doctor                                  # 全量体检

# 判断 SQLite 漏洞影响的是哪个解释器（别只看 .venv）
<python> -c "import sys; sys.path.insert(0,'/home/oklife/.hermes/hermes-agent'); \
  from hermes_cli.sqlite_runtime import probe_sqlite_runtime as p; i=p('<python_path>'); \
  print(i.sqlite_version_string, i.wal_vulnerable)"

六、三句话带走

1. 外部记忆不可用，先查是不是"配了但没 key"——这次就是 honcho 占位 key。
2. 选型按总原则：本地可控、零成本、能复利、不上新 SaaS。原生中文在中文场景是决定性优势（Holographic 胜出）。
3. 诊断运行时漏洞，先定位真正在跑的解释器（embedded 3.14.7），别拿闲置 dev venv（3.11.15）当靶子——否则"彻底解决"会变成空转。