Hermes 记忆系统深度分析

审计时间：2026-05-26 20:31 CST｜范围：Master/default、Worker、Network、Health、Stock、News/Sub 配置与当前注入链路

一句话结论：当前记忆系统总体可用且召回很快，Master 的“内置短索引 + TencentDB 四层外置记忆 + Scene Block 导航”已实际运转；主要风险不是失效，而是侧车进程常驻内存偏高、News/Sub 未接入 TencentDB、CLI 状态命令对 provider 显示有歧义，以及 L1/L2 自动沉淀仍偏保守。

可用

Master 本轮已成功注入 persona、scene navigation、外置记忆搜索工具。

1ms

本轮 Master TencentDB keyword recall 日志显示总召回耗时约 1ms。

5/5

8420–8424 五个 TencentDB sidecar 健康接口均返回 status: ok。

Master 当前 Scene Blocks：Telegram调用与模型恢复、内置记忆迁移承接、健康数据与热量核验。

1. 当前架构实际怎么运转

层级	当前职责	证据	评价
L0 原始会话	按 profile 写入 `conversations/YYYY-MM-DD.jsonl`，保留原始用户/助手片段。	Master 最新 `2026-05-26.jsonl` 存在；Health、Stock 等也有各自 conversations。	正常捕获链路存在，但不同 profile 活跃度不同。
L1 结构化记忆	抽取 episodic records，供搜索与后续 L2 聚合。	Master `records/2026-05-26.jsonl` 已记录“226 kcal 不应计入消耗”。	正常但记录偏事件化，仍有重复摘要。
L2 Scene Blocks	把高热度/跨会话主题收敛成场景块，并在 prompt 中注入索引。	Master scene navigation 注入 3 个场景；`内置记忆迁移承接.md` heat=9。	有效已承担长背景迁移职责。
L3 Persona	生成用户叙事画像，给交互风格与长期偏好提供背景。	本轮 prompt 注入完整 user narrative profile；日志显示 persona loaded 1763 chars。	有效但注入正文较长，要继续避免和内置 profile 重复膨胀。
内置 MEMORY/PROFILE	只保留高频规则、路径、禁忌、术语陷阱。	当前 MEMORY 约 32%，USER PROFILE 约 92%。	部分紧张 Memory 很健康；Profile 接近上限，需要后续瘦身。
Skills	保存 runbook 与可复用流程，不承载项目流水账。	存在 `agent-memory-governance` 与 TencentDB rollout/rebalance 参考。	健康流程知识放置正确。

2. Profile 接入与隔离状态

Profile	Provider 配置	端口/数据根	最近数据	判断
Master/default	`memory_tencentdb`	8424 / `/root/.memory-tencentdb/master`	2026-05-26 conversations + records；persona 与 3 个 scene block。	核心链路正常
Worker	`memory_tencentdb`	8421 / worker	最近 conversations 到 2026-05-24；records 到 2026-05-21。	低活跃/抽取滞后
Network	`memory_tencentdb`	8420 / network	最近 conversations 到 2026-05-24；records 到 2026-05-22。	低活跃/抽取滞后
Health	`memory_tencentdb`	8423 / health	2026-05-26 conversations；2026-05-25 records；健康/饮食 scene。	活跃正常
Stock	`memory_tencentdb`	8422 / stock	2026-05-25 conversations + records；库存 scene。	正常
News	provider 为空	未接入 TencentDB	无 TencentDB 数据根。	可接受 News 更依赖实时检索，记忆价值较低。
Sub	provider 为空	未接入 TencentDB	无 TencentDB 数据根。	待决策如果 Sub 承载长期财务/订阅偏好，可考虑接入。

3. 关键健康信号

Gateway 状态：Master、Worker、Network、Health、Stock、News systemd gateway 均为 active。
TencentDB sidecar：8420–8424 全部 status: ok，vectorStore=true，embeddingService=false。这符合当前 SQLite + keyword recall 灰度模式，不是故障。
本轮召回：Master 日志显示 keyword FTS5 命中 4 条、persona loaded、scene navigation 生成 3 scenes，召回总耗时 1ms。
注入质量：本轮进入上下文的记忆包含用户 persona、scene navigation、memory tools guide，说明 Gateway → provider → prompt 注入链路闭合。
数据写入：Master、Health、Stock 都有最近 L0/L1 文件；Master 的健康数据质疑已从 L0 抽到 L1。

4. 发现的问题与风险排序

优先级	问题	影响	证据	建议
P1	Master 进程内存很高。	不是记忆链路不可用，但 gateway 常驻 10.7G、峰值 13.2G，长期可能挤压系统资源。	`hermes-gateway.service` Memory 10.7G；其 cgroup 下包含多个 LSP 与 5 个 TencentDB Node sidecar。	拆分/托管 sidecar 为独立 systemd 或减少 gateway 内衍生进程；先做资源治理，不急着改记忆逻辑。
P2	`hermes memory status` 显示 provider none，与实际运行矛盾。	容易误导运维判断，以为只剩 built-in。	status 命令显示 “Provider none”；但 config/provider discovery/sidecar/注入日志都证明 Master 使用 TencentDB。	后续修 CLI 状态命令 profile/env 识别，或在 runbook 标注“以 config+health+日志为准”。
P2	News/Sub 未接入 TencentDB。	News 可接受；Sub 若承载长期订阅/财务习惯，则会缺少长期偏好沉淀。	news/sub config provider 为空；无对应 data root。	News 暂不动；Sub 视使用范围决定是否灰度接入独立端口。
P2	USER PROFILE 接近上限。	未来新偏好难以写入；重复 persona 注入可能增加噪音。	当前 profile 约 92%。	把“叙事型偏好”继续迁出到 L3/scene，内置 profile 只留决策简报、HTML、重启上下文等硬偏好。
P3	L1 记录存在重复/事件流水倾向。	长期会增加召回噪音，尤其邮件报告、升级过程等一次性事件。	Master 2026-05-23 records 中多条邮件报告摘要高度相似。	提高去重/合并策略；完成型任务不要过度 durable 化。
P3	embedding disabled。	语义召回能力弱于向量召回，但当前 keyword FTS5 很快、低风险。	所有 health endpoint `embeddingService=false`。	保持现状，等 L1/L2 去重稳定后再评估 embedding，不建议现在引入复杂度。

5. 对“运转如何”的总体评价

做得好的部分

分层职责基本正确：内置记忆没有继续承载长项目历史，而是作为短索引；长背景进入 TencentDB scene block。
召回链路真实生效：不是只配置了 provider，本轮用户问题已触发外置 memory recall、scene navigation 与 persona 注入。
多 profile 隔离合理：Master/Worker/Network/Health/Stock 分别有独立端口与数据根，避免相互污染。
安全边界较清楚：scene block 中是偏好、系统事实、操作硬约束，没有看到密钥类内容。
恢复导向一致：restart-context、Report Center、VPS inventory 等硬约束仍保留在内置高优先级层。

不够理想的部分

资源成本偏高：每个 profile 一个 Node sidecar 当前可用，但挂在 gateway cgroup 下，Master 进程组内存明显偏大。
状态观测有歧义：CLI memory status 与实际 provider 状态不一致，后续排障容易走偏。
抽取质量需要治理：L1 episodic 容易把“已完成任务结果”也存成长期事实；这和用户偏好的低噪音记忆相冲突。
USER PROFILE 太满：虽然 Memory 本体很健康，但 profile 92% 会限制未来高价值偏好写入。

6. 建议路线图

阶段	动作	预期收益	风险
立即，无需重启	把“评估标准”固化：判断 TencentDB 是否正常时，以 config + provider discovery + health + 日志 + 数据文件为准，不单看 `hermes memory status`。	避免误判。	无。
短期	瘦身 USER PROFILE：把叙事型偏好迁到 L3 persona/scene，只保留硬规则。	降低 prompt 噪音，释放写入空间。	低；需逐条确认避免删掉硬约束。
短期	治理 L1 去重：邮件报告、一次性升级、完成型任务不应反复生成多条高优先级 episodic。	减少未来召回噪音。	中；需要看 provider 抽取逻辑。
中期	将 TencentDB sidecar 从 gateway cgroup/子进程模式转成 profile-scoped systemd owner，或至少做内存/进程巡检。	降低 Master gateway 内存压力，提升可观测性。	中；涉及服务变更，需 restart context 与分 profile 验证。
可选	评估 Sub 是否接入 TencentDB；News 暂可不接。	让订阅/财务/项目偏好可长期沉淀。	低到中；取决于 Sub 是否有敏感数据过滤需求。
暂缓	开启 embedding/向量语义召回。	提升语义召回。	当前收益不如先治理去重与资源成本。

7. 最终判断

当前系统不是“记忆没跑起来”，而是已经进入可用灰度后的治理阶段。最值得处理的不是立即换召回算法，而是三件事：一是修正观测面歧义，二是控制 gateway/sidecar 资源成本，三是继续把内置 profile 瘦身并提升 L1 去重质量。