新装一个 Hermes Matrix / Telegram 机器人后，最容易纠结的是：到底先装什么功能，哪些是锦上添花，哪些会影响长期体验。
我的建议是先把顺序想清楚：先让机器人安静、安全、可恢复；再接 Holographic 这类本地记忆挂件；最后再考虑 Honcho、MCP、Cron、Voice、更多平台和云端记忆。
这篇专门讲 Holographic 记忆挂件，并顺手整理一份“新机器人装完后的功能清单”。以后新机器部署完，不用再凭感觉乱开功能，按优先级一项项验收就行。
Holographic 是什么
Holographic 是 Hermes Agent 的外部 memory provider 之一。它的定位很明确：给 Hermes 增加一个本地 SQLite 事实库，让机器人可以在内建 USER.md / MEMORY.md 之外，保存、搜索、关联和修正长期事实。
一句话理解：
USER.md / MEMORY.md 负责少量高优先级记忆，
Holographic 负责更多可检索、可维护、可打分的长期事实。官方 memory provider 文档里把 Holographic 描述成本地 SQLite fact store，支持 FTS5 全文搜索、trust scoring，以及用于组合查询的 HRR 能力。它不需要额外云服务，SQLite 默认可用，NumPy 只是可选增强。
所以它很适合这些场景：
- 第一次给 Hermes 接外部记忆。
- 希望所有记忆先落在本机，不想把个人偏好和服务器信息交给云服务。
- 当前主要是单机器人、单用户、单工作流。
- 想让机器人记住长期稳定事实，但又不想把
MEMORY.md塞爆。 - 需要能搜索、列出、更新、删除事实，而不是只靠系统提示里几行固定记忆。
它不适合解决这些问题：
- 多个机器人共享同一个用户画像。
- 团队级别的跨助手协作记忆。
- 想要云端同步和多设备天然共享。
- 想让所有聊天记录无脑进长期记忆。
如果目标是多助手共享认知，应该看 Honcho 或其它共享记忆方案；如果目标只是先让新机器人具备可靠本地长期事实库，Holographic 是最轻的一步。
它和内建记忆的关系
Hermes 的内建记忆一般分两类：
| 记忆层 | 适合保存什么 | 特点 |
|---|---|---|
USER.md | 用户偏好、长期习惯、语气要求 | 少量、高优先级、开局就注入 |
MEMORY.md | 稳定环境事实、长期项目事实 | 少量、高优先级、适合人工整理 |
| Holographic | 可检索事实、关联信息、历史经验 | 本地 SQLite，可搜索、可更新、可反馈 |
Holographic 不是替代 USER.md / MEMORY.md。接上后，内建记忆仍然照常工作；Holographic 只是额外增加一层外部事实库。官方文档也明确说，同一时刻只能启用一个外部 memory provider，但内建记忆会一直保留。
实践里可以这样分工：
| 内容 | 放哪里 |
|---|---|
| “用户默认希望中文回答” | USER.md |
“Hugo 源码在 /Users/mana/Documents/codex/hugo” | MEMORY.md 或项目 context |
“某台新 Matrix 机器人已经配置过 Holographic，数据库路径是某 profile 下的 memory_store.db” | Holographic |
| “一次报错排查中未经确认的猜测” | 不进长期记忆 |
| “某项部署流程以后会重复执行” | skill，不是 memory |
一个好用的机器人，不是记得越多越好，而是知道什么值得长期记。
启用 Holographic
先切到运行 Hermes 的用户，例如：
sudo su - hermesuser如果是指定 profile，先确认当前 profile 和配置路径：
hermes profile list
hermes config path
hermes config env-path修改前备份配置：
CFG="$(hermes config path)"
cp "$CFG" "$CFG.bak.$(date +%Y%m%d-%H%M%S)"交互式启用：
hermes memory setup在 provider 列表里选择：
holographic如果只想直接设置 provider：
hermes config set memory.provider holographic然后查看状态：
hermes memory status正常情况下，状态里应该能看到当前外部 provider 是 holographic。
检查配置是否写对
查看当前配置：
hermes config show至少确认这两块存在：
memory:
provider: holographic
plugins:
hermes-memory-store:Holographic 默认数据库通常是：
$HERMES_HOME/memory_store.db也就是默认 profile 下常见为：
~/.hermes/memory_store.db具名 profile 则可能在：
~/.hermes/profiles/<profile>/memory_store.db不要只猜路径，优先用 hermes config path、hermes profile list 和当前配置确认 profile。多机器人最常见的坑就是：你以为改的是 Matrix 机器人 profile，实际改到了默认 profile。
Holographic 的工具能力
官方列出的 Holographic 工具有两类：
| 工具 | 作用 |
|---|---|
fact_store | 添加、搜索、探测、关联、推理、检测冲突、更新、删除、列出事实 |
fact_feedback | 对记忆结果标记 helpful / unhelpful，用来影响 trust score |
实际使用时，不需要手动背工具参数。更稳妥的是直接对机器人说清楚目标：
把“这个 Matrix 机器人日常使用 smart 审批，群聊默认需要 mention”保存为长期事实。或者：
查一下你关于这个 Hermes Matrix 机器人的长期记忆，列出和 memory provider、审批、Matrix 入口限制有关的事实。再或者：
如果你发现关于这台机器人的 Holographic 记忆里有过期 facts，请先列出来，不要直接删除，等我确认。对自己长期用的机器人，我建议给它一条常驻规则：
写入长期记忆前，先说明准备保存的事实；只保存长期偏好、稳定环境事实和可复用工作习惯，不保存一次性错误、未经确认的猜测、token、密码或临时任务状态。要不要打开 auto_extract
Holographic 配置里有一个常见字段：
plugins:
hermes-memory-store:
auto_extract: false默认 false 更保守。它的意思是不要在会话结束时自动抽取事实。对于刚装的新机器人，我建议先保持 false，等你确认它能分清长期事实和临时状态后，再考虑打开。
如果要打开，也要配合严格规则：
plugins:
hermes-memory-store:
auto_extract: true
default_trust: 0.5打开后观察一段时间：
列出最近写入的 Holographic facts，按主题分组，并标出你认为可能过期或不应长期保存的内容。如果发现它把排障过程中的临时猜测、一次性路径、短期 bug 状态都塞进去了，就关回去。长期记忆一旦变脏，机器人会越来越自信地沿着旧事实跑偏。
一套验收流程
接完 Holographic 后，不要只看命令是否成功。建议做一轮真实验收。
第一步，确认 provider：
hermes memory status第二步，确认配置：
hermes config show | sed -n '/^memory:/,/^[^ ]/p'
hermes config show | sed -n '/^plugins:/,/^[^ ]/p'第三步，确认数据库文件：
find ~/.hermes -name 'memory_store.db' -print第四步，做一条可验证记忆：
请把这条保存到 Holographic 长期事实：我的新机器人装完后，默认先做 smart 审批、入口限制、Holographic 本地记忆和备份检查。第五步，新开会话后让它查询：
查一下你的 Holographic 长期事实：新机器人装完后，我默认先做哪些优化？如果它能从 Holographic 找回这条事实，并且没有把一堆无关聊天内容混进去，就算基础闭环通过。
常见坑
1. 改错 profile
多机器人场景下，先永远问三件事：
hermes profile list
hermes config path
hermes config env-path如果 Matrix gateway 是 matrix profile，Telegram gateway 是 telegram profile，默认 profile 里启用 Holographic 不会自动影响它们。
2. 把 Holographic 当成共享大脑
Holographic 是本地事实库，更适合单 profile 本地长期记忆。多个机器人要共享用户画像、peer 身份和跨会话关系时，应该另看 Honcho 这类方案。
3. 什么都记
不要让机器人保存：
- token、password、API key、cookie、SSH 私钥；
- 未确认的猜测；
- 一次性报错；
- 今天临时改过、明天可能恢复的配置；
- 纯聊天情绪和短期判断。
可以让它保存：
- 用户长期偏好；
- 常用服务器、仓库、服务名；
- 机器人 profile 分工；
- 稳定审批策略；
- 可复用工作习惯；
- 已验证的排障结论。
4. 不做 memory review
每隔一段时间做一次清理：
请列出 Holographic 里和 Hermes、Matrix、服务器运维有关的长期 facts，标出重复、过期、可能错误和建议合并的项。先不要修改，等我确认。确认后再让它更新或删除。记忆维护像整理配置文件，不能完全放任自动增长。
还有哪些类似功能值得装
下面这张表可以当“新机器人装完后的功能优先级清单”。
| 优先级 | 功能 | 建议 |
|---|---|---|
| 必做 | smart 审批 | 日常长期运行默认用它，不要长期全局 off |
| 必做 | Matrix / Telegram 入口限制 | 限制 allowed users / rooms，群聊默认 require mention |
| 必做 | 安静输出 | 关闭工具过程噪声，只保留最终回答和必要确认 |
| 必做 | 备份范围 | config、env、sessions、memory、skills、cron、gateway state 都要备份 |
| 推荐 | Holographic | 第一条外部记忆路线，本地、轻量、可验收 |
| 推荐 | Profiles | daily、dev、ops、family 分开，避免记忆和权限互相污染 |
| 推荐 | Toolsets | 给不同入口配置不同工具范围，群聊机器人不要开放过强工具 |
| 推荐 | Skills | 把重复三次以上的流程沉淀成技能 |
| 推荐 | Cron | 定时巡检、日报、备份提醒、状态摘要 |
| 可选 | Honcho | 多助手共享用户画像、peer 关系和更深用户建模 |
| 可选 | ByteRover | 偏开发者、本地优先、知识树式长期知识 |
| 可选 | Mem0 / Supermemory / RetainDB | 需要云端语义记忆、团队或外部服务能力时再接 |
| 可选 | MCP | 接文件、浏览器、数据库、GitHub、Notion 等外部工具 |
| 可选 | Voice | 想在语音入口里和 Hermes 对话时再开 |
我的保守安装顺序是：
模型连通性
-> gateway 在线
-> smart 审批
-> allowed users / rooms
-> 安静输出
-> 备份
-> Holographic
-> profiles / toolsets
-> skills
-> cron
-> MCP / Honcho / 其它云端记忆这样装出来的新机器人，先是安全可控的，再是好用的，最后才是“花活很多”的。
新机器人初始化 Prompt
装完 Hermes Matrix 或 Telegram 机器人后，可以直接把下面这段发给它：
请先做新机器人初始化检查，但不要直接大改配置。
目标：
1. 确认当前 profile、config path、env path、gateway 状态。
2. 确认审批模式是否为 smart。
3. 确认 Matrix / Telegram 入口限制是否只允许可信用户和可信房间。
4. 确认 display 是否尽量安静，只保留最终回答和必要 approval。
5. 确认 config、env、sessions、memory、skills、cron、gateway state 是否纳入备份范围。
6. 检查是否已经启用 Holographic memory provider。
7. 如果未启用，先给出启用计划和风险点，不要直接执行。
安全要求：
- 不要打印 API key、access token、bot token、password、cookie、SSH key。
- 修改前先备份配置。
- 删除、覆盖、重启 gateway、改变公网暴露、改变权限范围前先等我确认。
- 长期记忆只保存稳定事实和长期偏好，不保存一次性任务状态。确认它的检查结果没问题后，再让它执行：
按刚才的计划启用 Holographic。本次只做 provider 设置、状态检查、数据库路径确认和一条测试记忆写入，不开启 auto_extract。