HT1072公开知识系统
返回列表总览 ↗
决决策档案2026-08-12 · 评测记录
2026-08-12 · DECISION TRACE

跨设备 Hermes 记忆同步方案评估

保留方案、指标、验证、复盘和治理判断，让结论能够追溯。

2026-08-12记录日期
评测记录记录类型
25章节数

跨设备 Hermes 记忆同步方案评估

  • HTML: https://decision.ht1072.top/2026-08-12-cross-device-hermes-memory-sync-evaluation.html
  • Local HTML: [已移除本地路径]
  • Generated: 2026-08-12T09:35:27+08:00

跨设备 Hermes 记忆同步方案评估

结论

在远端机器安装完整版 Hermes 并与宿主机共享记忆是可行的，但"记忆同步"需要分层处理，不能用一种方案硬拼所有类型。当前宿主机已运行 Hindsight 0.9.0（11,568 条 facts，bank=hermes，API 在 127.0.0.1:8889），最优路径是将这个 Hindsight 实例暴露为远端可访问的 API，远端机器以 local_external 模式连入，共享同一个 bank。宿主机 24 小时在线、远端按需开机的场景，决定了应优先评估 Cloudflare Tunnel（+ Cloudflare Access 认证）而非裸端口暴露。用户已倾向 Cloudflare Tunnel 方向，当前先整理思路入档，暂不实施。

背景

需求

用户在宿主机（Linux 工作站，24h 开机）上长期运行 Hermes Agent，积累了大量记忆数据。现在需要在另一台按需开机的远端机器安装完整版 Hermes，要求两台机器的记忆能同步——远端机器能用到宿主机上积累的长期记忆。

网络条件

  • 宿主机：24 小时开机，有公网域名 ht1072.top（Cloudflare 托管），已装 cloudflared 但未运行
  • 远端机器：按需开机，与宿主机不在同一网络
  • 宿主机已有 Tailscale 在线（100.86.119.12），但更适合走 Cloudflare 路径

宿主机记忆架构实测

三层记忆

层 内容 存储位置 当前状态 跨设备？
内置短记忆 MEMORY.md / USER.md ~/.hermes/memories/ 活跃，接近容量上限 ❌ 本地文件
长期记忆 Hindsight 0.9.0 API 127.0.0.1:8889，PostgreSQL 在 pg0 健康，bank hermes，11,568 facts ❌ 绑定 localhost
会话历史 SQLite + FTS（state.db） ~/.hermes/state.db 活跃 ❌ 本地

Hindsight 配置实测

config.json:
  mode: local_external
  api_url: http://127.0.0.1:8889
  bank_id: hermes
  recall_budget: mid
  auto_retain: false

systemd:
  ExecStart: hindsight-api --host 127.0.0.1 --port 8889 --no-access-log
  EnvironmentFile: ~/.hindsight/embed

健康检查: healthy, database connected
版本: API 0.9.0
认证: 无任何 auth（裸 API，任何能触达端口者可读写全部 bank）

关键发现

  1. Hindsight 完全无认证——直接公网暴露 = 全部记忆数据裸奔
  2. 绑定 127.0.0.1，需要改 --host 0.0.0.0 或绑定特定接口
  3. ht1072.top 已在 Cloudflare，cloudflared 已装但未运行
  4. ufw 防火墙未启用
  5. Tailscale 已在线，之前那台 Windows Desktop 也连过（100.80.118.34，50 天前最后出现）

方案对比

方案 A：Hindsight 远程共享 bank（推荐）

原理：远端 Hermes 的 hindsight/config.json 设为 local_external，api_url 指向宿主机的 Hindsight 实例，用同一个 bank_id=hermes。

远端配置示例：

{
  "mode": "local_external",
  "api_url": "https://hindsight.ht1072.top",
  "bank_id": "hermes",
  "recall_budget": "mid",
  "auto_retain": false
}

网络可达性：通过 Cloudflare Tunnel 将 hindsight.ht1072.top 映射到 localhost:8889。

优势： - 零数据迁移——已有的 11,568 条 facts 立即可用 - 实时可见——写入即时生效，无需手动同步 - hindsight_recall / hindsight_retain / hindsight_reflect 全功能共用 - 一致的知识图谱和 entity resolution

局限： - 依赖宿主机在线（24h 开机满足此条件） - 会话历史仍各自独立——session_search 不跨设备 - MEMORY.md / USER.md 各维护本机版本（环境事实本该隔离，同步反而打架）

安全：Cloudflare Tunnel 不暴露公网端口，Cloudflare Access 可加认证层。

方案 B：Hindsight Cloud

将本地 Hindsight 数据迁移到 Vectorize Cloud（ui.hindsight.vectorize.io），两台机器都连 Cloud。

评估：有大量本地积累数据（11,568 facts + Postgres + 本地 embedding model），迁移成本不低。本地 pg0 + 本地 embedding 的性能和隐私均优于 Cloud。除非两台机器经常互离线且都需独立可用，否则不推荐。

方案 C：plur 社区方案（git-backed YAML memory）

来源：GitHub Issue #45331，社区开发者 @antoshik86 做的插件。

原理：记忆存为 YAML 文件，通过 git push/pull 跨设备同步。零基础设施。

评估： - 标记为 P3（Low — nice to have），feature request 阶段，未合入官方 - 独立 memory provider，不能与 Hindsight 共存（一次只激活一个 external provider） - 对当前环境是降级——从知识图谱退回到扁平 YAML - 适合无 Hindsight / 不想跑服务的轻量用户

方案 D：文件级同步（不推荐）

直接同步 ~/.hermes/ 子目录（Syncthing / iCloud / git）。

GitHub Issue #47341 明确指出的问题： - MEMORY.md 混了机器特定路径，直接同步会打架 - state.db（SQLite）多端同步极易坏库 - .env / auth.json 含凭据，需加密（git-crypt / sops） - 并发写冲突丢数据 - 脆弱，需手动管理 symlink 和 file layout

GitHub 相关需求全景

Issue 标题 状态 标签 核心诉求
#20510 Cloud Sync for All Configurations Open P3 全量 cloud sync（config/profiles/skills/memory/sessions）
#47341 First-Class Multi-Device Identity Continuity Open P3 agent 身份跨设备连续性（personality + memory + session）
#45331 plur — git-backed memory provider Open P3 YAML + git 轻量跨设备记忆
#31789 Memory-only profile isolation Open — 同一台机器多项目隔离 memory，共享其余

四个全是 Open + P3，说明官方认可需求但优先级低，短期不会出官方 cloud sync。[来源:1][来源:2][来源:3][来源:4]

推荐架构：分层处理

层 方案 理由
长期记忆（用户偏好、决策、知识） Hindsight 远程共享（方案 A + Cloudflare Tunnel） 已有数据，零迁移，实时可见
本机环境事实（路径、端口、服务状态） 各机器独立 MEMORY.md 环境事实本该隔离，同步反而打架
会话历史 各机器独立 session_search 跨设备 session 同步官方未做；Hindsight recall 可补偿大部分需求
Skills 可选 git 仓库同步 静态文件，适合 git 管理
配置与凭据 不同步 各机器独立维护，避免安全问题

落地步骤（暂不实施，待确认后执行）

阶段一：通过 Cloudflare Tunnel 暴露 Hindsight

  1. 创建 Cloudflare Tunnel，将 hindsight.ht1072.top 映射到 localhost:8889
  2. 配置 Cloudflare Access 策略，限制只允许指定邮箱/Google 账号访问
  3. 配置 cloudflared 为 systemd 服务并启动
  4. 验证 https://hindsight.ht1072.top/health 返回 healthy

阶段二：远端机器 Hermes 安装与配置

  1. 远端机器安装完整 Hermes Agent
  2. 配置 ~/.hermes/hindsight/config.json 为 local_external，api_url 指向 https://hindsight.ht1072.top
  3. 配置 memory.provider: hindsight，bank_id: hermes
  4. 安装远端 Hermes 所需的 LLM provider 和 API key（远端机器自己的 config.yaml / .env）
  5. 验证 hindsight_recall 能查到宿主机上的记忆

阶段三：双端协作验证

  1. 在远端写入一条新记忆，在宿主机 hindsight_recall 验证可见性
  2. 检查远端 Hindsight 自动 retain 行为（确保不影响生产 bank 的数据质量）
  3. 验证 reflect 工作正常

风险与边界

安全风险

Hindsight 无认证：当前 Hindsight API 没有任何内置认证机制。Cloudflare Tunnel + Cloudflare Access 可以弥补这一点，但必须正确配置 Access 策略，否则隧道本身就是开放的后门。Hindsight 已经有一个 Control Plane UI 在 127.0.0.1:9999（@vectorize-io/hindsight-control-plane），这个端口也应注意不要暴露。

数据风险

远端机器的 auto_retain 应保持 false（当前宿主机也是 false），避免远端机器的会话噪音自动写入共享 bank。记忆写入应通过显式 hindsight_retain 或会话结束时手动触发，而非自动管道。共享 bank 是生产数据（11,568 条 facts），远端写入需要谨慎。

可用性风险

宿主机离线时远端无记忆可用。虽然宿主机 24h 开机，但重启、维护、断网仍会发生。如果远端需要离线记忆能力，需要考虑本地缓存策略，或接受宿主机离线时记忆暂时不可用。Hindsight 本身不支持透明离线缓存。

不同步的内容

  • state.db（会话历史 SQLite）——多端同步极易坏库
  • .env（凭据）——安全风险
  • config.yaml（配置）——各机器 provider/model/路径可能不同
  • MEMORY.md / USER.md——本机环境事实应隔离
  • auth.json（credential pool）——安全风险

下一步

用户已倾向 Cloudflare Tunnel 方向但暂不实施。待用户确认后，按上述三阶段执行。实施前需要： 1. 确认 Cloudflare 账号中是否可以新建 Tunnel 和 Access 策略 2. 确认远端机器的 Hermes 版本应与宿主机一致还是用最新版 3. 决定远端机器使用什么 LLM provider（独立配置还是复用宿主机） 4. 确认远端机器的 retain 策略（显式 only 还是 session-end）