HexaMind v2.0：第七层——让记忆系统拥有实时触觉

前五篇文章讲了 HexaMind 是怎么从五层走到六层、怎么搭建、怎么运维的。一个读者从头看到尾，会觉得这个记忆系统已经被造得很完善了：存事实、做语义搜索、自己进化教训、画知识图谱，甚至能主动预判你下一步想干嘛。

但如果你真的把它跑起来，会发现一个很微妙的问题：它是"档案馆"式的记忆。

HexaMind 所有知识都来自每日 cron 的批量整理：凌晨 2:30 读昨天的对话 → 提炼事实 → 写入知识库。它记得住你昨天说过的偏好、上个月踩过的坑，但对刚刚发生的事情（比如 5 分钟前你纠正了它一个配置路径）是完全盲的。它要等到下一个凌晨才知道这件事。

而 Hermes Agent 自己带的热缓存 MEMORY.md，虽然能记住一些东西，但它就是个平面文本文件：没有结构、没有语义、没有范围隔离。不同 session 的事实混在一起，长到一定程度就撑爆了。

这就是 v2.0 要解决的问题。

L0：不是又多一层，是补了一整个维度

scope-recall（范围感知记忆）是一个 Hermes 原生的记忆提供者插件。把它接入 HexaMind 后，它不是简单地变成"第七层"，而是补上了一个 HexaMind v1 从第一天就缺失的维度：实时性。

之前的六层（L1 事实库 → L2 向量编码 → L3 语义搜索 → L4 教训进化 → L5 知识图谱 → L6 主动性）全是"离线"层：它们依赖 cron 批处理，数据流是单向的、延迟 24 小时的。

L0 是"在线"层：每轮对话都在工作。

L0  scope-recall  ← 每轮自动捕获，实时写入
L1  agent-memory  ← 持久知识，cron 批处理
L2  embedding
L3  LanceDB 语义
L4  教训进化
L5  知识图谱
L6  主动性

L0 是怎么工作的：两阶段实时管线

L0 的内存管理不是每分钟轮询，而是事件驱动 + 定时消化：

阶段一：实时捕获（对话结束即写入）

scope-recall 作为 Hermes 的 memory provider，hook 在每一轮 user→assistant 对话结束时自动触发。你发一条消息、我回一条，这一轮结束，一条 journal_entry 就落盘了。不是定时扫，零延迟。

阶段二：后台消化（每 2 小时，LLM 提取）

journal 只是原始记录——把"刚才说了什么"记下来。真正把它变成结构化知识（memories、fact_claims、entities、relations）的是 journal digest。默认每 2 小时跑一次，把积压的 journal entries 批量送给 LLM 做语义提取。

每轮对话 → journal_entry (实时，0 延迟)
          │
          ↓ 每 2 小时
   digest 提取 (DeepSeek LLM)
   ├─ memories     (持久记忆，按范围隔离)
   ├─ fact_claims  (结构化事实主张)
   ├─ entities     (自动发现实体)
   └─ relations    (实体间关系)

重启网关后，L0 已经自动写入了 204 条 journal entries，Digest 从里面提取出了第一条记忆：

"在 Hermes 环境中，无法从网关内部执行 hermes gateway restart 命令，因为该命令会终止当前 shell 进程及其所有子进程，导致执行命令的自身也被杀死。正确的重启方式是通过外部终端或通过 systemd 用户服务。"

这条记忆被自动分类为 ops（运维），从 1 条 journal entry 提取。它不是我手动写的——它就是 L0 自己看完对话后总结出来的。

L0 的七张表

scope-recall 不是一个简单的"对话日志"。它的数据库有七张表，覆盖了从原始对话到结构化知识的完整管线：

这里面最有价值的是 范围隔离。scope-recall 把记忆分成两层：

• 共享范围（user / memory / project / ops）：跨 session 持久化，所有对话都能访问
• 本地范围（general）：仅当前 session 可见，下一轮就清掉

这意味着 A 群聊里讨论的项目配置，不会被 B 群聊引用。v1 的所有 facts 都在一个全局池子里，没有这个边界概念。

从"档案馆"到"活系统"

架构层面上最大的变化，是数据流从单向变成了闭环：

v1 的数据流：

用户对话 → 凌晨 cron 批处理 → 提炼 facts → 写入 L1
（中间有 24 小时真空期）

v2 的数据流：

用户对话 → L0 实时捕获（journal → digest 每 2h 提取 → memories）
                │
                ↓  每日 02:30
          L1 持久化（promote）+ 02:30 cron 消化新增对话
                │
                ↓  每日 03:30
          L2 → L3 向量化上线

L0 先把"刚发生了什么"记录下来并即时消化成结构化记忆，让 Hermes 在当前 session 就能引用。到了凌晨，cron 把 L0 里高价值的持久事实提升到 L1，同时对当天新增的对话做深度提炼。两条数据线并行不冲突。L0 的数据库（~/.hermes/scope-recall/memory.sqlite3）和 L1 的数据库（~/.agent-memory/memory.db）完全独立。

检索也打通了。原来的 hexamind_search.py 只搜 L1（FTS5）+ L3（语义向量）。现在原生支持 L0，一条命令搜遍七层：

hexamind_search.py "gateway 重启配置" 8
# 输出：
#   channels: L0=1  L1=3  L3=3  merged=5

L0 返回的是最近几分钟内和你聊过的内容；L1 返回的是知识库里精确匹配的配置事实；L3 返回的是语义相近但你用词不同的记忆。三个通道的结果自动去重合并。

真实的坑：打通实时提取花了什么代价

说起来很顺滑，实际上搞的时候卡了半天。

scope-recall 的 digest 需要调 LLM 做语义提取。默认配置指向 OpenAI 的 gpt-4o-mini，但我没有 OpenAI 的 API key。于是第一步：切到 DeepSeek——写 config.json 配 model 和 base_url。

重启后 digest 跑了三次，全报错：LLM extraction failed (unknown)。

排查发现 scope-recall 的 journal_extractors.py 里读取配置是这样的：

api_key_env = str(journal_config.get("api_key_env") or "")

我传进去的是 ["DEEPSEEK_API_KEY"]，一个数组。str() 强转后变成了字面量字符串 "['DEEPSEEK_API_KEY']"——没有一个环境变量叫这个名字。所以 scope-recall 永远读不到 API key，LLM 调用永远失败。

改成裸字符串 "DEEPSEEK_API_KEY"，第二条 digest 立刻就跑通了，第一条结构化记忆就被提了出来。

配置只需要这么几行：

{
  "capture_llm": {
    "enabled": true,
    "model": "deepseek-v4-pro",
    "base_url": "https://api.deepseek.com",
    "api_key_env": "DEEPSEEK_API_KEY"
  },
  "journal": {
    "extractor": "llm",
    "background_digest_enabled": true,
    "api_key_env": "DEEPSEEK_API_KEY",
    "model": "deepseek-v4-pro",
    "base_url": "https://api.deepseek.com"
  }
}

加上把 DeepSeek API key 写到 .env，重启网关，就完了。

运行半天后的数据

journal 在跑，memories 在涨，digest 每 2 小时跑一次。scope-recall 不是一个"装好就摆着"的插件——它在每一轮对话里都在工作，每 2 小时把原始对话消化成结构化知识。

一句话总结

HexaMind v2 不是又多了一层。

它补上了 v1 从第一天起就存在的空白：实时记忆。v1 是档案馆，v2 是活的。能记住 5 分钟前你说的话，也能从三个月前的知识图谱里推理出你不认识的新关系。

L0 scope-recall 负责"这一秒"；L1-L6 负责"这一生"。两个加起来，才是一个完整的 AI 记忆系统。

HexaMind 系列文章： - 五层记忆体系 - 六层记忆架构进化 - 搭建攻略 - 完整实践 - 运维篇