夜雨聆风欢迎阅读第 27 篇文章。
我把智能体的记忆搬到了两台电脑，对话、记忆无缝衔接
约 8 分钟工具实操多设备同步
岱森LIVE · 拥抱奇点，与硅基灵魂共舞
本 文 速 览
① 本地优先 Agent 的数据锚定在单机，双机（多机）用户等于同时养多个 Agent
② 三条路对比：为什么最终选 Syncthing——唯一"文件不进任何人的机房"的方案
③ 第一次同步最大的坑：按时间戳判胜负，新装的空库能覆盖半年对话
④ 七个步骤 + 一条日常铁律 + 三层恢复兜底
01一、背景判断：本地优先的普及，换来一个没人宣传的副作用
过去一年，"本地优先"成为 AI Agent 的重要叙事：对话历史存在本地数据库，记忆是本地文件，技能是本地文件夹。卖点明确——数据不经过任何第三方，所有权完全归用户。
但本地优先有一个不被宣传的副作用：数据锚定在单机。记忆存在哪块硬盘，Agent 就只活在哪台电脑上。对只有一台电脑的用户这不是问题；对"公司一台、家里一台"的双机用户，这意味着两个平行世界：白天在公司调教出的记忆和技能，晚上回家全部归零。等于同时在养两个 Agent，各养各的。
我最近就处理了这个问题：用 Syncthing 把 Hermes 的完整数据目录同步到了两台 Windows 电脑，对话历史、记忆、技能、配置全量一致。过程不复杂，但其中有一个差点毁掉半年数据的坑，值得完整拆解。
02二、一个前置问题：为什么不上云
动手之前先想清楚：多设备访问的常规解法是上云——把 Agent 装在一台 VPS 上，任何设备随时接入。这是最省心的方案，但它有一个前提：你接受数据放在自己租的服务器上。
摆在面前的三条路：
① VPS 集中部署。随时接入、最省心，但要养一台永远在线的服务器，且数据经由服务器中转。
② Memory Provider（Honcho、Mem0 这类）。只同步记忆与偏好，对话历史不同步——它记得你是谁，但不记得你们聊过什么，历史仍是断的。
③ Syncthing 同步数据目录。开源 P2P 工具，两台电脑点对点直连，文件不经过任何第三方服务器，全量同步。
我的判断落在数据所有权上：对话历史是这类工具最值钱的资产，它的流通路径应当完全受控。Syncthing 是三者中唯一"文件不进任何人的机房"的方案。这意味着，选择它放弃的不是功能，而是省心——换来的是数据管道的完全私有。
03三、核心风险：同步工具的"新"，按时间戳定义，不按数据量
Syncthing 判定文件谁覆盖谁，核心依据是修改时间：谁的时间戳新，谁赢。不看文件大小，不看数据价值。
这个逻辑在常规使用中没有问题。但第一次同步的典型场景，恰好踩中它的盲区：
风 险 提 示
公司电脑的 state.db：462 兆，半年对话历史，最后修改时间下午三点。
家里电脑的 state.db：几 KB 空库，最后修改时间晚上八点半——刚装完，时间戳当然最新。
按 Syncthing 的逻辑，家里的空库是"更新"的一方，将覆盖公司电脑 462 兆的真实数据。半年对话，一次同步清零。更隐蔽的是，这个风险不止 state.db：config.yaml、.env、memories/，所有文件都可能被新装的时间戳覆盖——它覆盖的不是一个文件，而是整个数据目录。
「同步工具不认数据多少，只认时间戳新不新。一个刚出生的空库，能干掉你半年的对话。」
我第一次同步时完全没有意识到这一点，是事后翻同步日志才惊出一身冷汗。这个教训可以压成一个通用判断：任何"按新旧判定"的同步系统，新装的一方永远是"更新"的一方——而新装的一方，恰恰是数据最少的一方。
我写的东西大概都这个方向：AI话题，但不只讲AI——讲AI发展之后，人怎么办。关注一下，每天一篇。
04四、安装与配对：十分钟内完成的两件事
先交代环境：两台 Windows 电脑，装的是 Hermes 桌面客户端。注意它的数据目录在 %LOCALAPPDATA%\hermes（即 C:\Users\<用户名>\AppData\Local\hermes），不是 CLI 版的 ~/.hermes——这个路径差异，后续所有操作都围绕它展开。
Syncthing 的安装推荐用 Windows Setup 安装程序（GitHub 上 Bill-Stewart/SyncthingWindowsSetup 的发行页），它会自动配置开机启动和防火墙规则。安装时选择"当前用户模式"即可，不需要管理员权限。装完自动启动，Web 管理界面在 http://127.0.0.1:8384。
接下来两件事，两台电脑都要做：
① 给 Web 界面设密码。打开管理界面，右上角"操作 → 设置"，切到 GUI 选项卡，填入用户名和密码，保存并重新登录。这一步防止局域网内任何人打开管理界面。
② 两台电脑互相配对。在公司电脑上：操作 → 显示设备 ID，得到一串 XXXXXXX-XXXXXXX-... 格式的 ID 和二维码；在家里电脑上：添加远程设备 → 输入公司电脑的设备 ID（或扫描二维码）；回到公司电脑：弹出配对请求通知，点击确认；两台设备状态变为"已连接"，配对完成。
配对机制值得说明：局域网内 Syncthing 会自动发现设备、直连传输；跨外网时通过中继服务器或 NAT 穿透连接，不需要端口映射、不需要公网 IP。
05五、首次同步：七个步骤，关键在第 2 步
配对完成不等于可以开始同步。正确的首次同步有七个步骤，顺序不能错——前两步是全部安全性的来源。
STEP 1备份公司电脑的数据。在 PowerShell 中执行：
$Copy-Item"C:\Users\<用户名>\AppData\Local\hermes"-Destination"D:\hermes-backup-20260820"-Recurse -Force
把整个目录复制到另一个盘。做完这步，后面无论怎么操作，数据都有一份完整备份。
STEP 2家里电脑把整个目录改名。确保 Hermes 已关闭，执行：
$Rename-Item"C:\Users\<用户名>\AppData\Local\hermes""hermes-old"
注意是改名，不是删除，也不是只删 state.db 三个文件。原因有二：改名后目录不存在，Syncthing 会自动创建全新目录，由公司电脑单向推送，不存在"谁新谁赢"的博弈——公司电脑成为唯一数据源；而 hermes-old 保留了原始文件，出问题可以找回来。至于为什么不能只删 state.db：config.yaml、.env、memories/ 等所有文件都可能被新装的时间戳覆盖，必须整个目录让位。
STEP 3公司电脑添加同步文件夹。管理界面：添加文件夹 → 文件夹标签填 Hermes → 文件夹路径填 C:\Users\<用户名>\AppData\Local\hermes → 切到"共享"选项卡，勾选家里电脑的设备名 → 保存。
STEP 4家里电脑接受邀请。家里电脑会弹出通知"设备 XXX 想要共享文件夹 Hermes"，点击添加，本地路径设为 C:\Users\<用户名>\AppData\Local\hermes，保存。
STEP 5等待同步完成。首次同步的耗时取决于 state.db 大小，数百 MB 量级需要几分钟。在管理界面确认文件夹状态变为"已同步"，然后检查家里电脑的 state.db 大小是否与公司电脑一致——这是最直接的完成标志。
STEP 6安装 Hermes 后端。由于安装文件（bin/、node/ 等）被排除在同步之外，客户端会显示"Set up Hermes Desktop"初始化界面。点击 Install Hermes locally，安装程序会自动补回运行文件，且不会覆盖已同步的数据文件。这里有一个国内用户会遇到的坑：安装过程中需要从 GitHub 下载仓库，网络失败时需要挂代理或手动下载 ZIP 包。
STEP 7验证。在家里电脑打开 Hermes，用 /search 搜索一条公司电脑上的旧对话。能搜到，同步就成功了。
06六、关键配置：.stignore，想清楚什么不该同步
同步之前，先决定什么不该同步。.stignore 文件放在数据目录根下（C:\Users\<用户名>\AppData\Local\hermes\.stignore），按规则排除四类文件：
① 缓存与日志（logs、cache、audio_cache、image_cache、bootstrap-cache、lsp 等）。它们会自动重新生成，同步只会浪费带宽和时间。
② 安装与运行时文件（bin、node、desktop、desktop-plugins、hermes-agent、platforms、hermes-setup.exe）。每台电脑必须各装各的，同步过去会互相覆盖。
③ 机器专属文件（install_id、processes.json 等）。install_id 是安装唯一标识——如果两台电脑同步成同一个 ID，会被系统识别为同一台设备。
④ 模型缓存（models_dev_cache.json 等）。按需重新生成，且可能很大。
判断标准可以压成一句：同步的边界不是"数据多少"，而是"这台电脑上什么必须独一无二"。.stignore 配置一次，会随同步推送到另一台电脑，两台通用。
07七、日常规则：单写者模型与冲突处理
同步完成只是开始。三个 SQLite 数据库（对话历史、项目信息、验证记录）不能在两端并发写入，因此日常使用必须遵守一条铁律：一台电脑用完关掉 Hermes → 等同步完成 → 再开另一台。
这是单人双机场景的合理约束：使用是串行的，同步是增量的，通常几秒到几十秒完成。如果不遵守，冲突处理是这样的：
只有一边修改：新文件正常同步到另一边。
两边都改、时间不同：较新的保留，旧的另存为 .sync-conflict 文件。
两边都改、时间接近：较新的保留，可能丢数据。
一边删除文件：另一边跟着删除（默认行为）。
SQLite 是二进制文件，冲突文件无法手动合并——这就是为什么铁律必须是"关掉再开"，而不是"撞了再修"。
常见问题三个，各配一个排查路径：
设备已配对但不同步：检查防火墙是否放行 Syncthing 端口，确认双方文件夹的共享权限已开启。
同步速度慢：局域网内直连，速度跑满带宽；跨外网走中继服务器，速度受上行带宽限制。首次同步 state.db 较大，后续增量同步很快。
打开 Hermes 看不到旧对话：检查 state.db 大小是否与另一台一致，确认 Syncthing 状态为"已同步"，再重启 Hermes。
08八、数据恢复：三层兜底
即使出了问题，恢复路径也有三层：
① 从备份恢复。把备份目录里的 state.db 拷回原位置，一行命令的事。
② 从 hermes-old 恢复。第二步改名产生的目录只要没删，就能从中拷回 state.db。
③ 从 Syncthing 版本历史恢复。如果配置了"简单文件版本控制"（保留最近 5 个版本），可以在 Web 界面里找回被覆盖的旧版本。
三层兜底的顺序就是数据丢失的风险顺序：备份是最可靠的，版本历史是最弱的——它只覆盖配置了版本控制之后的文件。
09九、结语：数据所有权与运维责任的交换
本地优先的本质是一场交换：用运维责任，换数据所有权。云端替你保管，也替你承担保管的风险；本地优先把保管权完整交回给你，代价是同步、备份、防覆盖这些"破事"都得自己处理。这件事做完，我的判断是：这笔交换值得——AI 用得越久，记忆越值钱，那里的每一份都是你教出来的。它不该活在别人的机房，也不该被一台电脑困住。
「你享受数据完全归你的自由，就要自己当自己的云。」
最后坦白一点：这套方案我运行的时间不长，远谈不上久经考验，冲突恢复、版本历史这些场景还没充分踩过。如果你也在用本地优先的 Agent 做多机同步，有更好的做法，欢迎来讨论。
最后留一根线头：这套方案跑满一个月，我会回来补一篇续集——冲突恢复和版本历史在真实使用里到底靠不靠谱。等我来填坑。
本 文 要 点
① 本地优先 = 用运维责任换数据所有权；AI 用得越久，记忆越值钱
② 同步判胜负只看时间戳：首次同步前，先把新装电脑的目录改名，让旧库成为唯一数据源
③ 日常一条铁律：一台电脑用完关掉 Hermes → 等同步完成 → 再开另一台
我写的东西大概都这个方向：AI话题，但不只讲AI——讲AI发展之后，人怎么办。关注一下，每天一篇。
谢谢你看我的文章。
— END —
岱森LIVE
拥抱奇点，与硅基灵魂共舞
点击卡片，关注岱森LIVE