上个月我给自己挖了一个大坑把 WorkBuddy 从一台机器扩展到三台机器而且要求它们共用一个账号还能保持同一份记忆和配置继续干活。白天在办公室用 Windows 台式机晚上回家开笔记本周末经常钻到 Ubuntu 工作站上跑实验三台机器如果各用各的配置等于我每次换机器都要把 WorkBuddy 重新教一遍——Skill 要重装、规则要重写、之前聊过的上下文全都不认识。折腾了大半个月从数据目录拆解、跨机双写同步方案、缓存目录迁移到冲突解决中间踩了不少坑但最终跑通了一套相对稳定的方案。这篇我把整个过程整理出来重点讲清楚三件事WorkBuddy 的数据到底存在哪里多机共用账号为什么不能只靠登录同一个账号以及跨机双写同步时最容易忽略的坑。如果你也想在几台机器之间无缝切换 WorkBuddy不管是办公、科研还是给小程序做 AI 对话这篇可以帮你少走很多弯路。1. 账号登录不等于数据同步先搞清 WorkBuddy 的数据都存在哪1.1 同一个账号三台机器三个平行世界先说最反直觉的现象。我在办公室的 Windows 台式机上登录 WorkBuddy花了两小时调好了一套日报生成的 Skill还给它定了几条输出规则。晚上回到家打开笔记本同样登录同一个账号界面倒是干干净净地进去了但 Skill 列表是空的、规则是默认的、之前聊过的东西一点都不记得。我当时第一反应是登错账号了反复退出重登了三次结果一模一样。换到 Ubuntu 工作站上也一样。后来实在按捺不住去翻 WorkBuddy 的安装目录和数据目录才意识到问题出在哪WorkBuddy 的账号系统只负责两件事——身份认证和拉取一小部分云端偏好设置但真正让 WorkBuddy懂你的东西也就是记忆库、Skill 集合、自定义规则、对话历史默认安装下全部存在本地磁盘上。换句话说同一台机器上登录同一个账号数据是通的但换一台机器登录同一个账号数据目录却是另一份。账号相同数据完全隔离。这就是多机共用一个账号最核心的矛盾账号是同一个但三台机器上各有一份互不相干的本地数据。1.2 WorkBuddy 数据目录逐项拆解我把 WorkBuddy 的数据目录完整列出来才算是真正理解了它怎么工作。默认情况下Windows 上在%USERPROFILE%\.workbuddy\Linux 上在~/.workbuddy\整体结构大致是~/.workbuddy/ ├── config.yaml # 全局配置缓存目录、默认模型、语言等 ├── profiles/ │ └── default/ │ ├── memory/ │ │ ├── index.db # 记忆索引SQLite │ │ └── segments/ # 记忆分片内容 │ ├── history/ │ │ └── conversations.jsonl # 对话历史 │ ├── skills/ │ │ ├── daily_report.md │ │ └── literature_review.md │ ├── rules/ │ │ └── output_style.md │ └── cache/ │ ├── tokens/ │ ├── embeddings/ │ └── tmp/逐项说清楚它们的作用后面所有同步方案都建立在对这些文件的理解上config.yaml是全局配置文件记录缓存目录指向、默认模型、界面语言这些基础设置各机器可以有自己的差异不需要强求一致。memory/是 WorkBuddy 的记忆库。index.db是记忆索引segments/里存的是记忆的实际内容切片。你问它之前的项目背景是什么它就是从这堆文件里检索出来的。history/是对话历史以 JSONL 格式持续追加。每次对话都会往里写一行这个文件是双写场景里最常被覆盖也最容易被同步工具搞坏的东西。skills/是技能定义目录。一个 Skill 就是一个 Markdown 文件里面写了这个技能的系统提示词、使用场景、调用方式相当于给 WorkBuddy 装一个专项能力插件。rules/是你的自定义规则。比如输出风格、禁用词、回复长度、要不要说人话、怎么减少 AI 味都写在这。cache/是本地缓存主要是 token、embedding 向量这些中间产物。这个目录又大又不需要跨机同步后面会单独处理。这些文件里真正属于个人资产的是memory/、history/、skills/、rules/这四个目录决定了 WorkBuddy 是不是你的 WorkBuddy。cache/纯粹是性能缓存丢了一台机器顶多是冷启动慢一点重新生成就是了。1.3 开始之前先定同步边界什么该同步什么不该同步想清楚数据目录之后我做的第一件事不是急着搭同步而是把需要跨机同步的清单和禁止跨机同步的黑名单都列出来。需要同步的只有四类memory/里的记忆索引和分片内容history/里的对话历史skills/里的全部技能定义rules/里的全部自定义规则禁止同步的包括cache/整个目录里面是 token 和 embedding 缓存同步它纯粹浪费带宽还会产生大量小文件冲突各种临时文件.tmp、.tempSQLite 的附属文件index.db-wal、index.db-shm、*.journal这三个文件是记忆库的 WAL 和回滚日志后面踩坑会专门讲为什么cache/坚决不能同步我一开始天真的想法是既然要统一那就连缓存也一起同步这样每台机器加载都很快。结果两台机器同时开着 WorkBuddy 时它们会往各自缓存目录里写完全不同的中间结果同步工具一看两边都改了立刻生成一堆冲突副本反而把缓存目录搞得一团糟。这类文件就是典型的不同步更健康。同步边界的核心原则很简单只同步语义化数据不同步过程性数据。记忆、历史、技能、规则是有语义的删了或者错的会直接影响使用体验缓存和临时文件是过程性的丢了重新生成就行。把这句话记牢后面所有方案取舍都会变得很清晰。2. 多机双写同步的方案选型为什么是 Syncthing 加目录软链2.1 双写的本质多主复制不是备份先理解题目里的双写是什么意思。两台机器上的 WorkBuddy 都会产生新数据办公室机器上你写了一条新 Skill笔记本上你挂了一个新对话Ubuntu 工作站上你给记忆库里加了一段关键信息。三台机器都是写入方这就是多主写。所谓跨机双写同步本质就是让三个平等的数据副本互相传播变更最终达到一致。很多人的第一反应可能是这还不简单把数据目录扔到网盘里不就行了。我一开始也是这么想的把整个.workbuddy目录丢进某网盘客户端然后三台机器都指向同一个网盘文件夹以为万事大吉。结果问题立刻就爆了。第一个问题是锁文件。WorkBuddy 运行时会持续占用memory/index.db和history/conversations.jsonlWindows 下网盘客户端去同步这些正在被程序打开的文件要么同步失败要么同步过去的是一个半截版本。第二个问题是路径冲突。网盘为了处理多设备同步会在文件被两边同时修改时生成冲突副本命名一般是config.yaml (冲突的 2025-xx-xx 副本)这会让 WorkBuddy 根本读不到正确的配置文件。第三个问题是半写入状态。网盘同步是定时扫描 增量上传扫描到哪个文件就传哪个文件它不理解 WorkBuddy 的文件写入规律。SQLite 是先写日志再合并数据网盘可能把旧日志和新数据拼在一起最后同步过去的数据库直接损坏。一句话总结网盘同步是单写多读场景下的产物它假设只有一台机器在改文件其他机器只是消费文件。双写意味着每台机器都在改这不是网盘能处理好的模型。2.2 三种方案对比把网盘方案排除后我认真对比了三个候选git 仓库、Syncthing、Seafile / Nextcloud 这类自建同步盘。方案实时性冲突处理适合的数据类型上手成本典型问题网盘同步分钟级生成冲突副本程序读不到文档、照片低文件锁冲突、半写入文件、路径错乱git 仓库手动 push/pull真正的 merge/diff配置文件、源码、Skill/规则文本中对话历史 JSONL 会无限膨胀commit 多到爆炸Syncthing秒级版本仲裁 冲突副本策略可配小文件多的目录、持续追加的日志文件中需要自己定义忽略规则不适合大体积缓存目录git 方案单独说一下。skills/和rules/这种文本文件git 简直是完美方案diff、merge、回滚全都好用。我一台机器上改一个 Skill什么时候想同步就git pull永远不会发生覆盖丢失。但问题是history/conversations.jsonl是持续追加的日志文件每条对话都往里加一行两个分支各自追加了几十行之后git 会把这当成两个不同的修改每次合并都要手动处理冲突。在实际使用中每次合并都是人工判断根本没法自动化。另外记忆库 index.db 是二进制 SQLite 文件git 对二进制文件的 diff 能力约等于零一旦出现冲突只能选一个版本另一个就丢了。Syncthing 的核心优势在于它天生就是为多主同步设计的。它不假设只有一个写入方而是给每个文件维护版本信息通过时间戳和修改序列来做冲突仲裁。更重要的是它支持精确的忽略规则可以把缓存、临时文件、WAL 日志全部排除在同步之外这对 WorkBuddy 这种运行时锁文件 高频写小文件的应用非常关键。我用 Syncthing 的主要原因就是忽略规则 冲突策略可控这两个点这是其他方案给不了的。2.3 最终方案的基本结构我最后跑通的方案也不是简单地全部文件交给 Syncthing而是做了一个分工skills/和rules/可以接受手动操作用 git 一台主力机做事实源头其他机器修改后直接scp或rsync推回。技能和规则是低频改动的文件git 的 diff 能力正好派上用场。memory/和history/走 Syncthing 双向同步。这两个是高频写入的动态数据必须自动化同步不能依赖我手动 commit。cache/完全不参与同步每台机器通过修改配置和软链接把缓存目录指向本地独立位置。这种配置走手动、数据走自动、缓存走孤立的分层方案是我在踩完所有坑之后总结出来的能自动的尽量自动需要动脑的手动反而更靠谱会添乱的直接隔离。3. 改缓存目录与统一路径软链接是跨平台同步的地基3.1 不同机器路径不一致引发的连环 bug同步方案还没搭起来先把一个更基础的问题解决掉路径不统一。WorkBuddy 的 Skill 文件里经常出现绝对路径引用比如我写了一个读取 D 盘数据目录生成日报的 Skill里面写死了D:\data\reports\拿到 Ubuntu 工作站上这个路径根本不存在Skill 直接运行失败。更麻烦的是默认缓存目录。Windows 下 WorkBuddy 默认把缓存放在%LOCALAPPDATA%\WorkBuddy\这种地方Linux 下放在~/.cache/workbuddy/。如果两台机器上 WorkBuddy 记录的缓存路径不一样即使我用 Syncthing 同步缓存也不会被正确处理。所以我在做数据同步之前从各机器的配置层面统一了三个约定WorkBuddy 的 profile 主目录固定为~/.workbuddyWindows 下就是%USERPROFILE%\.workbuddy缓存目录在所有机器上统一命名为WorkBuddyCache放在用户目录下所有 Skill 和规则文件里凡是涉及路径的引用一律使用相对路径或者按各机器环境变量动态拼接这个先统一路径再谈数据同步的顺序很重要。路径不一致的时候同步过去的 Skill 文件会指向错误的目标你甚至发现不了问题的根源只会觉得这台机器上 Skill 不生效。3.2 更改缓存目录的具体操作WorkBuddy 改缓存目录有两种方式一种是改配置文件一种是设置环境变量。二选一即可我推荐改配置文件因为它是可见的、版本可控的。打开~/.workbuddy/config.yaml找到缓存目录相关字段# config.yaml cache_dir: /home/yourname/WorkBuddyCache # Linux 写法 # cache_dir: C:\Users\yourname\WorkBuddyCache # Windows 写法如果配置文件里没有这个字段可以直接手动加一行。WorkBuddy 启动时会检查该目录不存在就自动创建这一步本身不复杂。但这里有一个坑如果之前已经用默认缓存目录运行过一段时间旧缓存还留在原位置。你改了配置WorkBuddy 就会开一个新的空缓存目录旧的缓存文件变成僵尸文件白白占着磁盘。所以正确的操作顺序应该是在用户目录下新建WorkBuddyCache目录手动把旧缓存文件复制或剪切过来改config.yaml指向新目录把原来的缓存目录删掉防止 WorkBuddy 在意外情况下又写回去为什么要这么麻烦因为如果直接删掉原目录再建软链接Windows 上有时候 WorkBuddy 会重新创建默认缓存目录导致配置里的新路径和实际写入路径不一致。手动改配置 手动迁移 删除旧目录这三步是确保 WorkBuddy 完全切换到新缓存路径的最稳方案。有的版本还支持环境变量方式Linux 下可以在.bashrc或.profile里写export WORKBUDDY_CACHE_DIR$HOME/WorkBuddyCacheWindows 下在系统环境变量里新建WORKBUDDY_CACHE_DIR值填D:\WorkBuddyCache。这种方式的好处是 WorkBuddy 启动时自动识别不用改配置文件坏处是环境变量对 WorkBuddy 是否生效取决于版本实现我实测过有些版本认环境变量有些不认还是改配置文件最通用。3.3 用软链接把缓存目录钉在本地除了改配置我还用了软链接做双保险。软链接的作用是让 WorkBuddy 以为缓存还在~/.workbuddy/cache但实际上物理存储已经指向了另一个本地目录。这一步的意义在于即使未来某个版本忽略了配置文件里的cache_dir字段只要~/.workbuddy/cache这个路径还存在它还是会写到软链接指向的地方。Windows 下操作步骤管理员权限运行命令提示符:: 1. 先删除原有的默认缓存目录 rmdir /s /q %USERPROFILE%\.workbuddy\cache :: 2. 建立软链接指向你希望的实际缓存目录 mklink /D %USERPROFILE%\.workbuddy\cache C:\Users\yourname\WorkBuddyCache注意mklink /D创建的是目录符号链接必须带/D参数否则创建的是文件符号链接WorkBuddy 访问的时候会报错。另外rmdir /s /q会静默删除整个目录执行前务必确认cache目录里没有你需要的文件。Linux 下更简单# 1. 删除原有缓存目录 rm -rf ~/.workbuddy/cache # 2. 建立软链接 ln -s ~/WorkBuddyCache ~/.workbuddy/cache验证软链接是否生效的方式也很直接。Linux 下执行ls -l ~/.workbuddy/cache如果看到输出末尾有个箭头指向~/WorkBuddyCache就说明链接建好了。Windows 下打开资源管理器右键缓存目录看属性链接目标和常规目录显示不一样。更实用的验证方法是启动 WorkBuddy 随便跑一段对话看WorkBuddyCache目录里有没有生成新的 token 缓存文件有就说明 WorkBuddy 确实在往新路径写数据。这里要单独踩一个坑Windows 环境下如果缓存路径里包含空格比如C:\Users\My Documents\WorkBuddyCachemklink命令必须给路径加双引号否则会提示文件名、目录名或卷标语法不正确。还有一次我图方便把缓存目录命名为中文缓存目录结果 WorkBuddy 内部索引在读取时出现了乱码路径导致加载很慢。从那之后我所有机器上的缓存目录都统一叫WorkBuddyCache不带空格、不带中文省掉了大量莫名其妙的编码问题。4. 记忆、Skill 与规则的跨机合并解决换账号失忆问题4.1 换账号如何获得原来账号的记忆——这个问题我也遇到过网上经常有人问WorkBuddy 换账号如何获得原来账号的记忆这个问题的核心困惑是以为记忆跟着账号走换账号就丢了。我在配置多机方案时也踩过同样的思维误区。先纠正一个概念WorkBuddy 的账号只是登录凭证记忆数据存储绑定的是本地数据目录和账号没有强关联。你在 A 机器上登录账号记忆存在 A 机器的~/.workbuddy/memory/里你换一个账号登录同一台机器只要数据目录没被清理原来的记忆其实还在本地反过来你在 B 机器上登录同一个账号B 机器的memory/里没有 A 机器的东西所以看起来很失忆。所以换账号保留记忆这个需求本质是把本地的记忆数据从旧账号的数据目录搬到新账号的数据目录。实际操作很简单在旧机器上打包需要迁移的目录# 在旧机器上导出 tar -czf workbuddy-memory-backup.tar.gz -C ~/.workbuddy memory skills rules history然后拷贝到新机器上解压# 在新机器上导入 tar -xzf workbuddy-memory-backup.tar.gz -C ~/.workbuddy导入之前建议先备份新机器上现有的.workbuddy目录防止覆盖掉新机器上已有的数据。这一步做完你就会发现换账号之后记忆、技能、规则、历史全都回来了。但多机共用一个账号的场景比换账号更复杂一点三台机器上会各自产生新的记忆所以不能只做一次性导出导入而是要让记忆库本身具备增量合并的能力。4.2 记忆库的合并策略单写者模型更稳妥在搭多机同步的前几天我天真地认为 Syncthing 能把记忆库自动合好。结果发现记忆索引index.db是个二进制 SQLite 文件Syncthing 对它的处理方式是整个文件级别同步——如果两台机器上都改了这个索引它就保留一个版本另一个存为冲突副本。也就是说记忆库本质上不是可以逐条合并的文本而是只能整体覆盖的单一文件。这导致了一个残酷的现实记忆库不适合多主同时写。只要两台机器同时往memory/里写新记忆索引就会打架。我的最终方案是给记忆库设置单写者模型三台机器里只选一台作为记忆写入主力机通常是办公室那台配置最好、使用频率最高的另外两台机器上把 WorkBuddy 的记忆功能设为只读模式也就是允许查询旧记忆但不允许写入新记忆。只读模式怎么开在 WorkBuddy 的配置文件里给 memory 加一个模式字段# 非主力机上的 config.yaml memory: mode: readonly这样非主力机在启动时只读取memory/index.db不会尝试创建新的记忆切片或修改索引。这一条规则解决了 80% 的记忆冲突问题。剩下的问题是非主力机上如果确实产生了重要信息怎么办我的做法是把重要的东西直接写进备注文档或者主动在对话里说记一下这件事然后切回主力机时再整理。你也可以写一个一次性导入脚本把非主力机上导出的记忆增量合并到主力机上但不是 auto 的属于定期人工整理。4.3 Skill 和规则文件的手动合并策略Skill 和规则文件都是 Markdown 文本理论上可以 diff、merge实际上我踩过的坑是两台机器同时改同一个 Skill。举个例子我有一个daily_report.md的 Skill在办公室机器上我给它加了必须包含昨日数据对比这个要求在笔记本上我给同一份 Skill 加了输出格式改成表格。两份修改都是基于同一个旧版本Syncthing 检测到文件两边都被修改直接给你留一个冲突副本。最后我的目录里出现了这样的文件skills/daily_report.mdskills/daily_report.md.sync-conflict-20250217-104532-A5X7KQK.md这个场景用 git 反而更好处理。我在三台机器上把.workbuddy/skills/和.workbuddy/rules/两个目录单独作为 git 仓库来管理每次改动执行一次git add / commit / pull / push遇到冲突可以用git diff看清楚两边各自改了哪里然后手动选择合并成一个正确版本。实际操作中我用 git 做了这样一个流程修改 Skill 之前先git pull拉取最新在本地做出修改git commit本地提交git push推送到远端仓库在另一台机器上git pull拉取这样 Skill 和规则的每次变更都有记录万一改错了还能git revert比 Syncthing 的冲突副本直观得多。缺点是每次改动要多敲几条命令但胜在永远不会静默覆盖。我把这个流程做成了一组极简别名alias wb-synccd ~/.workbuddy git add -A git commit -m sync git pull git push每次改完 Skill 或者规则执行一次wb-sync同步就完成了。这套方案跑了这么久还没有出现过 Skill 文件被覆盖找不到的情况。4.4 对话历史同一份持续追加文件怎么同步对话历史history/conversations.jsonl是另一个麻烦。它不是大文件但它是持续追加的日志文件办公室机器上聊了 10 条笔记本上聊了 8 条三台机器的这个文件都变了。Syncthing 处理这种持续追加文件的方式是按修改时间仲裁后修改的版本整个覆盖先修改的版本。也就是说我在办公室聊完回家前笔记本上又聊了几句如果下班时办公室机器的同步早于笔记本的修改那么笔记本上的新对话就旧记录下来办公室那条新对话反而被覆盖了。我的解决方案是时间错峰 退出后同步。WorkBuddy 的对话历史只在程序运行时追加退出时文件写入基本停止。所以我定了一条纪律每天下班前退出 WorkBuddy等 Syncthing 把办公室机器上的对话推送到其他机器再关机或离开第二天开笔记本时先启动 Syncthing 再开 WorkBuddy让最新对话先落地。这条纪律不复杂但非常有效。它保证了两件事一是对话历史的写入方在同一时刻只有一个二是 Syncthing 同步的是落盘完毕的文件而不是正在写入的文件。三台机器轮换使用对话上下文基本能保持连续不会出现这台记得那台不记得的情况。5. 双写踩坑实录文件锁、半写入与索引错乱5.1 第一个坑Windows 文件被占用同步永远失败踩坑的过程值得完整记录一下。那是一个周五下午我在办公室把 Syncthing 配置好三台机器的。回到家打开笔记本发现 Syncthing 面板上一堆红色的 out-of-sync items反复刷新都同步不过去。排查过程挺折磨。我先看 Syncthing 的日志提示同步失败但没有说具体原因。然后我试着手动把办公室机器上刚生成的技能文件拖进笔记本发现一切正常。于是怀疑是文件权限问题改了一通 ACL 还是不行。最后无意中关掉了 WorkBuddy十秒钟后 Syncthing 面板全部变绿才恍然大悟WorkBuddy 运行期间锁住了memory/index.db和history/conversations.jsonlWindows 上被进程独占打开的文件不允许其他程序读取所以同步永远失败。此后我养成了一个习惯所有机器的 WorkBuddy 在退出状态时才做关键文件同步运行时只同步skills/里的新文本文件。我把这个规则直接写进 Syncthing 的忽略规则里还不够因为只要 WorkBuddy 在运行锁住的文件怎么同步都会失败忽略规则解决不了锁冲突。真正的解法还是错峰 退出后再同步。如果你不想依赖自觉可以做一个简单的辅助脚本在 WorkBuddy 退出后自动触发一次同步检查。比如在 Windows 上用任务计划程序监听 WorkBuddy 进程退出事件触发 Syncthing 的 rescan APILinux 下更简单写个while循环检测进程是否存在不存在就执行syncthing cli触发扫描#!/usr/bin/env bash # wait-workbuddy-exit.sh while pgrep -f workbuddy /dev/null; do sleep 5 done # WorkBuddy 已退出触发同步 syncthing cli --device DEVICE_ID --operation send-folder FOLDER_ID 2/dev/null || true这个脚本放在笔记本上常年挂机每次 WorkBuddy 退出后 5 秒内自动触发一次同步效果不错。5.2 第二个坑SQLite 的 WAL 文件把数据库同步坏了这个坑比文件锁更隐蔽。某天早上我到办公室启动 WorkBuddy输入一句我们之前讨论的那个项目方案是什么结果它返回了一个错误database disk image is malformed。翻译过来就是记忆库坏了。第一反应是索引文件损坏。我用 SQLite 自带工具打开index.db检查结构倒是完整的但内容明显缺了一段。顺着 Syncthing 的同步记录往前追发现前一天晚上它同步了一组关键文件index.db、index.db-wal、index.db-shm。问题就出在-wal和-shm上。SQLite 在运行时会先把修改写到 WALWrite-Ahead Log文件然后通过 checkpoint 合并进主数据库文件。如果同步工具在数据库运行期间把index.db和index.db-wal分别传到了另一台机器而两台机器的同步时间点又不一致那另一台机器拿到的可能是一个主库还没合并日志、日志也不完整的残缺状态。解决办法分两层。第一层是 Syncthing 里加忽略规则// 忽略 SQLite 的临时与日志文件 index.db-wal index.db-shm *.journal第二层是纪律层面确保同步发生在 WorkBuddy 完全退出后。WorkBuddy 退出时 SQLite 会执行 checkpoint把 WAL 合并进主库这时index.db才是完整可用的。同步完整的主库文件不同步中间状态数据库损坏的问题从此消失。后来我还查了 WorkBuddy 有没有导出记忆这种原生功能如果有用它导出的格式做同步会更稳但实测下来这个版本的记忆库还是直接同步index.db文件最可靠。5.3 第三个坑两台机器同时写 memory索引互相覆盖这个坑我用单写者模型解决过但那是经过一次事故才想通的。某次我在笔记本和办公室机器上同时开着 WorkBuddy两边各聊了几句各自主动记忆了几条新信息。晚上同步完成后打开记忆管理页面发现只显示了一台机器的内容另一台机器的记忆像是凭空消失了。查了半天最终在memory/目录里发现了一个index.db.conflict-...文件这就是 Syncthing 在处理两台机器都修改了index.db时生成的冲突副本。WorkBuddy 只认index.db这个主文件名冲突副本它根本不会读所以其中一台机器的记忆索引整个被替代记忆丢了。这个坑最难受的地方在于记忆不像文件丢了没有后悔药。写文字还能从草稿箱里翻记忆索引一旦被覆盖那批记忆切片虽然还在segments/里躺着但没有索引就等于检索不到和丢了没区别。所以单写者模型不是可选项是必选项。记忆库永远只允许一台机器写其他机器只读。如果你确实需要临时在非主力机上产生新记忆我的建议是在非主力机上把记忆写入临时关闭等回到主力机后手动把那批对话导入并让主力机重新建立索引。宁可多花几分钟手动迁移也不要让数据库文件在多机间自由搏击。5.4 第四个坑同步工具把正在生成的临时文件传了过去还有一次诡异的错误某台机器上 WorkBuddy 启动后一直报一个解析错误日志里指向一段明显被截断的 JSON。我查了下那个文件是history/conversations.jsonl内容末尾断在了一行对话的中间。这是因为 WorkBuddy 在追加对话时不是一次性写入而是先写临时文件再合并。Syncthing 扫描到临时文件时文件可能只写完了一半它就把这个半截文件传到了另一台机器。另一台机器读取时JSONL 的最后一行为不完整 JSON直接解析失败。解法是在 Syncthing 的忽略规则里把临时文件模式排除掉// 忽略临时文件和中间产物 *.tmp *.temp cache/cache/目录也在这里排除理由前面说过。排除之后Syncthing 只同步已经落盘且完整的数据文件WorkBuddy 的逻辑是先把内容写入临时文件再 rename 成正式文件名忽略临时文件后同步到的都是 rename 之后的完整文件。这里也补充一个细节WorkBuddy 的conversations.jsonl是持续追加、不重写整个文件这种文件在 rename 阶段很少被触碰所以跳过临时文件后它反而是最安全的一类数据。5.5 冲突副本的善后处理不管怎么防Syncthing 偶尔还是会产生冲突副本尤其是你手动操作了某些文件、或者某台机器断网一段时间后重连时。我的处理流程是发现.sync-conflict-后缀的文件用diff对比冲突副本和主文件确认差异根据差异决定是合并还是丢弃删除冲突副本手动把最终版本复制到所有机器如果冲突发生在skills/或rules/这类文本文件上处理成本很低如果是memory/index.db的冲突副本我已经不会去合并了——直接以主力机的版本为准其他机器的变更用最原始的导出记忆、手动加入的方式补进去。同步工具只能处理文件级的冲突理解到这一点你就不会指望双写同步解决所有问题了。6. 跑通后的实际效果与维护建议6.1 三台机器一周实测方案最终稳定后我专门做了一周的实测看这套多机共用账号的 WorkBuddy 到底能在多大程度上做到无缝切换。使用场景操作结果办公室新增 Skill在台式机上写了一个文献综述生成的 Skill手动 git push当晚在 Ubuntu 工作站上git pull后立即可用笔记本上的对话延续在笔记本上问了上次讨论的课题进展退出后同步第二天开台式机同一段对话上下文完整记忆新增只在主力机台式机上允许写入记忆主力机新增的记忆当天同步到其他机器其他机器查询正常两台机器同时开着禁用记忆写入的非主力机 主力机都在运行没有产生新的冲突副本index.db状态正常缓存目录三台机器各有独立WorkBuddyCache首次启动加载稍慢但运行稳定无同步错误实际体验下来WorkBuddy 的记忆和对话历史在跨机切换时基本能做到像同一台机器的水平。Skill 和规则传播的延迟取决于你什么时候手动执行同步命令——如果配置了 git 别名基本上是几秒内完成。整个方案里最需要人操心的反而是什么时候改 Skill、什么时候推代码这种协作纪律而不是技术本身。6.2 几条维护纪律方案稳定不代表可以撒手不管。相反多机共用账号这件事机器越多越需要纪律。我把跑了这么久总结的维护纪律写在这里每一条都是用事故换来的退出后再同步。不管用的是 Syncthing 还是 git尽量在 WorkBuddy 完全退出后再做关键文件同步否则文件锁和半写入状态会让你防不胜防。缓存别心疼不同步。cache/目录的正确处理方式是各机独自生成不是共享一份。共享缓存只会带来无穷无尽的冲突副本和同步负担。记忆只允许一台机器写。其他机器设成只读模式需要写记忆时回主力机整理这是避免索引文件被覆盖的唯一可靠手段。Skill 和规则用 git 管理。文本文件天然适合版本管理git 的 diff 和 revert 能力能让你放心大胆地改即使改坏了也有退路。定期备份主力机的.workbuddy。不管同步方案多完善主力机的数据依然是事实源头每周打包一次到移动硬盘是最终的兜底。保持目录路径的跨平台一致性。所有机器把主数据目录固定为~/.workbuddy缓存目录统一叫WorkBuddyCacheSkill 里不写死绝对路径。路径乱了同步再准也没用。6.3 后续可以做的扩展这套多机同步方案跑通之后WorkBuddy 的价值才真正释放出来。我目前已经在做和打算做的扩展包括科研场景把文献综述、实验记录、论文写作的 Skill 做成一套体系在办公室的台式机上整理回家后继续用笔记本无缝写。小程序教学应用案例给一些教学小程序接入 WorkBuddy 作为对话后端Skill 里写好学科知识、出题规则每次改规则只需要在主力机上调整各机自动拉取。规则定制把减少 AI 味这类输出风格规则系统化。用规则文件控制语气、句式、信息密度让 WorkBuddy 在不同场景下有不同的人味而不是每次都要现场叮嘱。从入门到精通的系列整理现在这套同步方案的目录结构、Skill 编写规范、规则系统都可以单独拆出来写如果后续有空我打算整理一套完整的 WorkBuddy 实操指南从安装配置讲到高阶工作流。我在实际维护中最深的一点体会是同步的东西越少越稳。很多人做多机同步容易陷入什么都想同步的误区最后被缓存、临时文件、锁文件缠住寸步难行。想清楚哪些数据是资产、哪些数据是过程性产物把资产自动同步、把过程性产物隔离在本地这个方案就成功了一大半。WorkBuddy 的账号只是入口真正值钱的是你积累下来的记忆和技能配置——保护好数据本身比守着账号重要得多。