起因※
我现在跑着两个 Hermes（sad 和 asus），各自有独立的记忆库、配置和会话，互不打扰。但两个人终究是两个人——我在 sad 上说过的事，asus 一无所知。于是想：能不能让她们共享同一个大脑？同一个记忆引擎后端，同一份数据。听起来很美，和莉莉丝（我的 Hermes AI 助手）聊下来，才发现这条路每一步都踩在架构的边界上。
我的笔记系统是怎么和记忆连起来的※
先交代背景：我的笔记系统是 Trilium，Hermes 的记忆引擎（Seraph / fact_store，SQLite 落盘）通过一套"记忆桥"和它双向同步——正向，Hermes 记下的事实会变成 Trilium 知识图谱里的实体/事实/关系节点；反向，我在 Trilium 里改一笔，也会秒级回流进记忆库。两个方向都是实时的。
这套机制单机跑得很顺，但"共享大脑"要的是两台机器、两个 Hermes 共用同一份图谱——问题就出在这。
问题一：Hermes 是单服务器架构，共享要补多实例能力※
记忆引擎是本地 SQLite，配置是本地 config.yaml，会话是本地 state.db。没有全局 ID、没有分布式锁、没有冲突解决、没有去中心化协调——这是设计使然，不是缺陷，但"共享同一份数据"意味着要让两个实例写同一份记忆，而这套多实例能力 Hermes 一个都没有，要从零补：
- 状态同步：两个实例的 facts/entities/relations 需要一致性协议——谁改了？冲突以谁为准？怎么合并？
- 实例管理：实例注册、心跳、下线检测、数据归属——这条事实是谁的？
- 去中心化协调：分布式锁、全局唯一 ID、冲突解决策略
这不是改几行脚本，是给 Hermes 重写一套分布式记忆系统。
问题二：记忆桥是双向的，共享图谱会互相灌※
就算把图谱放在两台机器都能访问的地方，双向同步立刻变成灾难：sad 正向写进 Trilium 的节点，asus 的反向通道会当成"Trilium 里的编辑"吃回自己的库；asus 的私密会话镜像进共享图谱，sad 的反向通道又把它吞进去。两边互相灌，最后谁的记忆都不干净。更隐蔽的是时间戳覆盖循环——正向写完 Trilium，反向读回旧值，覆盖对方，再正向写回去，死循环。
问题三：技术细节也过不去※
图谱节点的锚点 syncKey 用的是裸 fact_id（自增整数），两个实例的 ID 都是从 1 开始，完全重叠。asus 的 fact 3 会直接覆盖 sad 的 fact 3。
两条路线※
路线 A：多实例共享大脑（去中心化）※
每个实例都有完整大脑，多实例对等，通过一致性协议同步：分布式锁、全局唯一 ID、冲突解决、合并策略。这是真正的"多实例共享大脑"——彼此独立又一致。代价：Hermes 单机架构没有这套机制，要全从零造，等于重写一套分布式记忆系统，工程爆炸，还要吞下双向互灌和隐私泄露的代价。
路线 B：共享一个大脑（中心化）※
所有实例读写同一个中心记忆，单一权威数据源，天然没有冲突。但注意：这不是"多实例共享"，只是把大脑集中到一处，所有入口都连它。
中心可以是两种形态：
- 机械中心：sad 当主（记忆中枢），asus 当从，记忆读写走 HTTP（写入用 seraph-api，查询走 ETAPI，都是现成接口）。改动可控，是现有架构的自然延伸。
- 智能中心：图谱和实例之间插一个 Agent 做记忆裁决，由它统一去重、合并、冲突仲裁。把机械的分布式原语换成 LLM 语义判断。
智能中心的缺点：LLM 仲裁可能判断错、有延迟和 token 成本，仲裁 Agent 本身是单点——它挂了，所有实例的记忆写入都停。
结论：不值得做※
两条路都盘过一遍：A 多实例去中心化要重写分布式记忆系统；B 中心化（无论机械中心还是 Agent 仲裁）本质都只是"共享一个大脑"，没实现多实例——Agent 仲裁还多一个单点和 LLM 不确定性的问题。
想要的体验，无论走哪条，工作量都大到不划算——保持现状：两个 Hermes 各跑各的，独立记忆；Trilium 图谱作为共享的只读展示层就够了。共享大脑这事，记下讨论过程，先不做。
