Hermes 到底跑在 venv、.venv 还是别的？答案是「别的」，顺手清了 1.15G 残留

排查 Hermes 记忆系统的 SQLite 误报时（上篇《honcho 换 Holographic》提过），我一度以为生产正跑在一个会损坏数据的 SQLite 3.50.4 上，差点把 venv 重建到 3.14 去"彻底解决"。

结果逐解释器一测，发现我查错了对象。这篇把整个来龙去脉讲清楚：Hermes 现在到底跑在哪个 Python 上、为什么老文档会骗人、以及我最后怎么安全地把那堆闲置残留清掉的。

一、先给结论

现在的 Hermes（v0.22.3）既不是跑在 venv，也不是 .venv，而是跑在一个 embedded 托管运行时：~/.hermes/tools/python-3.14.7（Python 3.14.7 / SQLite 3.53.1）。

磁盘上其实有三种 Python 目录并存过：

hermes --version 报的是 Python: 3.14.7——不是 3.11。就这一条，足以说明生产不走 .venv。

二、为什么老文档会说「跑在 .venv」

我有一篇五月的运维文（《Hermes 环境配置与修复实录》），里面认认真真记录了怎么把 .venv 修好：补 pip、统一命名、uv sync --active。那篇文章在当时是对的——因为那是 v0.14.0 时代，Hermes 确实跑在 uv venv 建的 .venv（3.11.15）上。

但它现在过时了。 原因是架构变了。

三、架构变化：从「.venv 运行层」到「embedded 托管运行时」

• v0.14.0 时代：Hermes 源码装在 ~/.hermes/hermes-agent，靠 uv 管理的 .venv 当 Python 运行层，hermes 命令最终落到 .venv 的 python。
• v0.22.3（现在）：Hermes 改用托管的 embedded 运行时 ~/.hermes/tools/python-3.14.7。launcher 和 gateway 的 systemd 服务都直接指向它，不再经过 .venv。第三方依赖（openai、numpy）也装进 embedded 运行时自己的 site-packages。

所以那个"被五月修好的 .venv"，在架构迁移之后就自动变成了没人用的残留。venv（无点）同理。

四、三条铁证（你也能自查复现）

1. hermes --version：
   Hermes Agent v0.22.3+13.g47b23fa · upstream 47b23fa0
   Install directory: /home/oklife/.hermes/hermes-agent
   Python: 3.14.7          ← 关键：3.14.7，不是 3.11

2. gateway 活进程的 /proc/PID/exe：指向 ~/.hermes/tools/python-3.14.7…/bin/python3.14，不是 .venv。
3. CLI 启动链：
   ~/.local/bin/hermes  →  exec ~/.hermes/hermes-agent/.hermes/bin/hermes
   .hermes/bin/hermes   →  exec ~/.hermes/tools/python-3.14.7…/bin/python3 -I -c ...

   整条链最终落在 embedded 3.14.7，和 .venv 无关。

（Desktop 端走它自带的 Electron 运行时，也不碰 .venv。）

五、对 SQLite 误报的影响

• 生产（CLI+gateway）在 embedded 3.14.7 / SQLite 3.53.1，WAL 正常、无损坏 bug。
• 那条"3.50.4 有 WAL 损坏 bug、已降级 DELETE“的告警，只在我拿闲置的 .venv（3.11.15）跑测试时才触发。
• 结论：生产记忆系统不用修 SQLite，那条是"查错了解释器"闹的。

六、处置：删掉两个闲置残留（安全四查 + 零影响）

先做安全四查，再 rm -rf，别裸删：

AG=~/.hermes/hermes-agent
# 1) 确认没有活进程从 .venv/venv 里跑
for p in $(pgrep -f hermes); do readlink /proc/$p/exe; done   # 都不在 .venv/venv
# 2) 确认 embedded 自带依赖（不依赖 .venv）
~/.hermes/tools/python-3.14.7*/bin/python3.14 -c "import numpy, openai"
# 3) 留底
du -sh "$AG/.venv" "$AG/venv"        # 485M + 667M ≈ 1.15G
# 4) 删除 + 删后验证
rm -rf "$AG/.venv" "$AG/venv"
hermes --version                      # 仍报 Python: 3.14.7 ✓
pgrep -f 'gateway run'               # gateway 活体仍在 ✓

结果：释放约 1.15G，hermes --version 仍报 3.14.7、gateway 活体正常，生产零影响。

注意：若你以后在源码树里做 dev（uv sync），uv 会按 .python-version（3.14）自动重建 .venv——删了不碍事，需要时会回来。

七、判断命令速查 + 口诀

hermes --version | grep Python                 # 最省事：看 hermes 自报的 Python
readlink /proc/$(pgrep -f 'gateway run' | head -1)/exe   # 看活进程 exe 在哪个 python
which python; which pip; python -m pip -V      # 看当前 shell 落在哪个环境（别看提示符）

口诀：诊断 Hermes 运行时 / SQLite / 依赖，先定位 embedded 托管运行时（~/.hermes/tools/python-3.14.x），别拿 dev 的 .venv/venv 当靶子——它们和生产是两回事。

八、三句话带走

1. 运行时架构会随版本迁移：.venv（v0.14.0）→ embedded 托管运行时（v0.22.3）。老文档里的"环境位置"不保证还成立，引用前先看 hermes --version 的 Python 对不对得上。
2. 目录名并存 = 误诊温床：venv/.venv/tools/… 并存极易把闲置目录当生产。修环境前先搞清楚"到底哪个在跑”。
3. 删残留前四查（无活进程 / embedded 自带依赖 / 留底 / 删后验证），再动手 rm -rf。