前阵子有个做 AI 办公的朋友问我能不能在公司台式机和家里笔记本上同时登录同一个 WorkBuddy 账号而且两边都要能接着昨天的对话往下聊项目记录、技能、规则也得互通。我一听就知道他要的不是那种手动导出再导入的原始方案而是真正的跨机双写同步。正好我自己也在这个坑里爬了很长一段时间踩过不少软链、锁库、冲突文件的雷这篇就把我最终跑通的方案和完整排查过程整理出来。先说结论多机共用一个 WorkBuddy 账号这件事难点从来不在账号登录上而在WorkBuddy 的记忆和项目数据到底存哪里、怎么在两台机器之间保持一致。账号只是个身份外壳换台机器登录后你原来那个账号的记忆不会自动跟过来很多人以为是自己操作不对其实是没搞清楚 WorkBuddy 的数据架构。所以要实现两台机器真正的无缝切换核心问题就一个怎么让本地数据目录完成双向实时同步。这篇文章就是围绕这个目标展开的。1. WorkBuddy 的账号机制与本地数据分布1.1 账号只是身份凭证记忆默认长在本地先看一个大家踩得很高频的坑在 A 机器上用了很久 WorkBuddy积累了大量的会话记录、自定义规则、技能和项目上下文换到 B 机器登录同一个账号结果发现界面干干净净啥记忆都没有。很多人第一反应是去骂账号系统但实际原因很简单——WorkBuddy 的账号体系主要负责身份认证、收费订阅和云端偏好设置而会话历史、项目索引、记忆片段这些重数据默认是写在本地磁盘上的不会全量上传到账号云端。这个设计其实有它的合理性。AI 工作台的会话和记忆文件往往体积不小而且高频读写如果全部走云端实时同步离线场景就没法用了。所以 WorkBuddy 选择把账号和数据存储分开账号负责告诉系统你是谁本地目录负责告诉系统你做过什么。这也就解释了为什么换账号如何获得原来账号的记忆会成为高频问题——因为答案不是登录同一个账号而是得把原来的本地目录搬过去或者做同步。我一开始也试图在 WorkBuddy 里找那种一键云同步开关结果发现它只同步了账号层面的设置项比如主题、快捷键、模型选择这些轻量配置。真正值钱的记忆文件、会话 JSON、规则配置全都老老实实躺在本机目录里。所以想多机共用就必须自己动手把数据目录打通。1.2 数据目录里到底装了什么想做好同步得先弄清楚 WorkBuddy 在本地到底放了哪些东西。不同版本、不同操作系统的路径会有差异但核心目录结构通常长这样目录/文件作用双写同步建议config 或配置目录存放模型地址、账号设置、界面偏好可同步但因为绝对路径问题容易踩坑sessions/每次会话的完整记录必须同步这是双写的主体memory/ 或记忆目录长期记忆、向量索引、摘要快照必须同步rules/用户自定义规则文件必须同步但建议单写多读skills/自定义技能定义必须同步projects/项目索引和关联文件路径必须同步cache/ 或临时目录临时缓存、日志、锁文件坚决不同步登录态/凭据文件token、session 凭据选择性同步注意安全我在自己的 Linux 机器上做了一次完整排查用find / -iname *workbuddy* 2/dev/null把相关路径全部列出来发现数据分布得比较分散一部分在~/.local/share/workbuddy下面一部分在~/.config/workbuddy下还有日志和临时文件散落在~/.cache/workbuddy。Windows 上则是典型的%APPDATA%和%LOCALAPPDATA%双目录结构。这里想强调一点缓存目录是唯一可以放心忽略、而且必须忽略的部分。它里面装的是临时索引、网络缓存的响应片段、日志滚动文件这些内容同步过去除了制造冲突和垃圾没有任何意义。1.3 把缓存目录和数据目录分清楚热搜词里有个高频问题叫workbuddy 缓存目录怎么更改这说明有相当一部分用户把缓存目录当成了数据目录。从同步的角度来说这个区分特别重要改缓存目录解决的是磁盘占用问题跟记忆同步半毛钱关系都没有。我见过一个用户他在两台机器上分别把缓存目录改到了云盘同步文件夹里以为这样就能实现记忆互通结果同步了一堆.log和临时文件真正的 sessions 目录还留在本地默认位置。这种操作不仅没用还会让云盘客户端频繁扫描不断变化的临时文件导致严重的 IO 占用。正确的思路是只挑有价值的、需要跨机延续的目录做同步。简单说就是 sessions、memory、rules、skills、projects 这几个关键目录必选cache 和日志目录必须剔除。后面写 Syncthing 忽略规则的时候我会给出可以直接抄的配置。2. 三种跨机同步方案实测对比2.1 云盘软链接最省心但最脆这是大多数人第一个想到的方案把 WorkBuddy 的数据目录做成软链接指向 OneDrive、坚果云、Dropbox 这类云盘同步目录云盘负责把文件同步到另一台机器。听起来很美好实际上问题不少。先说优点云盘客户端有图形界面不需要学习任何新工具而且两台机器只要登录同一个云盘账号文件就会自动同步。如果你只是想在 A 机导出、B 机导入那这个方案足够用。但如果你追求的是双写——也就是两台机器都在高频写入那么云盘方案有几个致命伤。第一是文件占位符问题。很多现代云盘默认启用仅在线模式本地只有一个占位文件真正内容在云端。WorkBuddy 在启动时会大量读取记忆文件和会话记录遇到占位文件可能直接报错或者读取到空内容。我实测过把数据目录放到 OneDrive 里WorkBuddy 经常出现找不到会话的诡异问题必须右键逐一固定到本地而数据文件一多根本固定不过来。第二是锁和句柄占用。云盘客户端会持续监控同步目录里的文件变化而 WorkBuddy 这类 AI 工作台恰恰会频繁地写文件、改记忆、更新索引。两边同时操作同一个文件时Windows 上经常出现文件被占用无法写入的错误提示Linux 上则可能出现同步混乱。第三是冲突处理能力几乎为零。云盘遇到双端同时修改通常只会生成一个副本或者让后写者覆盖先写者不会像专业同步工具那样保留冲突版本。对 WorkBuddy 来说最坏的情况是两台机器各自写了不同的记忆片段结果云盘粗暴覆盖一边的记忆直接消失。我把这个方案定义为适合单向备份不适合双向协作。如果你能保证每天都只用一台机器干活另一台只是偶尔看看那云盘软链接还能凑合如果想实现真正意义上的双写同步请往下看。2.2 Git 仓库版本管理强双写很痛苦用 Git 管理 WorkBuddy 数据目录是很多技术型用户天然会想到的思路。毕竟数据也可以被视为一种代码会话记录可以提交记忆可以回溯版本看起来优雅得很。实际上我试过一周体验非常拧巴。核心问题在于 Git 的设计初衷是多人协作但文件彼此独立修改而 WorkBuddy 的数据文件恰恰是一台机器独占性的高频读写。双机同时开着 WorkBuddy两边都在写同一个记忆文件这时候你执行 pull 就会遇到大量冲突。Git 会要求你手动解决每个冲突文件而记忆文件内部是结构化数据人工 merge 基本不可行。另一个问题是敏感信息泄露风险。WorkBuddy 数据目录里的登录凭据、token、账号信息一旦被你git add .提交到了仓库里再推到远程 Git 服务上就相当于把自己的账号密钥公开了。即便后来删除历史记录里还是留存的。我自己的做法是给仓库加了gitignore把 token 类文件全部排除但这就又回到了哪些文件要同步的选择题上复杂度直线上升。当然 Git 也不是完全没有用武之地。如果你想做的是每周一次的版本留档或者某次重大调整前的手动快照Git 或者简单的 tar 打包都挺好用。但把它作为跨机双写的核心手段我是坚决劝退的。2.3 Syncthing 双写唯一真正满足双写的方案最后说说我最终采用的方案——Syncthing。这是一个开源的、点对点的文件同步工具不经过任何第三方云服务器两台设备之间直接加密传输。它天生就是为多设备、多端双写、实时同步设计的正好对口 WorkBuddy 跨机共用的需求。为什么它适合 WorkBuddy 场景关键有三点。第一双写友好它采用双向同步两端任何一端的修改都会实时合并到另一端。第二冲突处理完善当同一文件在两台机器上都发生修改时Syncthing 不会直接覆盖而是生成冲突副本命名为xxx.sync-conflict-日期-时间-设备名.ext保留两版内容给你人工处理的机会。第三忽略规则强大可以精确到子目录和文件名模式把 cache、锁文件这些垃圾内容彻底排除在同步范围之外。部署成本也不高。Syncthing 有 Windows 图形客户端、Linux 二进制包、Docker 镜像手机端也有对应 App。配置好设备互信之后只要两台机器处于同一个局域网或者都能连通对方同步就会自动进行延迟通常只有几秒钟。我最终的工作流就是Syncthing 双写 版本控制 单写多读规则。下面把完整落地过程写出来。3. Syncthing 双写落地目录定位、忽略规则与登录态处理3.1 先定位 WorkBuddy 的真实数据目录这一步是重中之重目录找错了后面全部白干。不同操作系统的定位方式不太一样我分别来说。Linux 和 macOS 可以直接用命令全文搜索我的实际执行结果是find ~ -maxdepth 5 -iname *workbuddy* 2/dev/null | head -50在 Ubuntu 上我最终确认主要数据位于~/.local/share/workbuddy/和~/.config/workbuddy/缓存则在~/.cache/workbuddy/。Windows 上我建议先看环境变量直接在资源管理器地址栏输入%APPDATA%\WorkBuddy和%LOCALAPPDATA%\WorkBuddy通常这里面藏着会话记录和配置文件。定位之后别急着同步先记下两个关键信息第一数据目录的整体大小如果好几个 G 那估计把缓存也包进去了需要细分第二目录内部的子结构确认哪些是 sessions、哪些是 cache。我自己的做法是先用du -sh *按大小排序把最大的几个目录列出来再用find查文件类型基本就能判断出个子丑寅卯。3.2 同步目录的初始化与忽略规则编写Syncthing 的配置过程可以分成三步设备配对、目录分享、忽略规则。设备配对最省事的方式是用二维码互相扫一下,前提是两台机器在同一个局域网如果跨网络就填写对方的设备 ID 并做引入 device。目录分享这一步要特别注意我建议在一台机器上新建一个干净的目录作为同步根目录然后让另一台机器以接受的方式加入而不是两台机器各自创建同名目录再手动引入。前者能确保初始状态完全一致后者容易出现目录结构对不上的问题。接下来是忽略规则这是双写方案里技术含量最高的一部分。我的最终配置如下// 忽略所有缓存和临时文件 cache/** Cache/** *.tmp *.log *.pid // 忽略锁文件和数据库临时文件 *.lock *.db-journal *.db-wal // Syncthing 自身文件不参与同步 .stfolder .stignore这里我想特别解释一下*.db-wal这个忽略项。很多 AI 工作台会用嵌入式数据库存索引SQLite 的 WAL 文件记录了未落盘的写入操作。理论上 WAL 也必须跟着主数据库文件一起同步否则另一端读到的可能是旧数据。但如果 WorkBuddy 正在运行WAL 在退出的瞬间会合并回主库文件所以我的做法是先彻底关闭 WorkBuddy再触发同步等同步完成后再启动。一句话总结忽略规则的核心优先同步数据类目录禁止同步锁文件和临时文件。犹豫不决的文件宁可先排除也不要放进来制造污染。3.3 登录态和会话数据的同步顺序双写方案里最容易翻车的点是两台机器同时启动、同时登录同一个账号在 Syncthing 还没来得及完成合并的时候就各自写入新会话。这时候两台机器的 sessions 目录都会新增文件Syncthing 会把两边的新文件都合并进来这是没问题的真正出问题的是那种同一个会话文件两端同时追加内容的情况。所以我给双机同步定了一个默认规则切换机器时先让 WorkBuddy 完全退出等待 Syncthing 状态显示已同步再在另一台机器上启动 WorkBuddy。任何云同步方案都适用这个原则——双写不等于无脑并发写同一个文件。关于登录态文件我的建议是同步但要做好安全准备。WorkBuddy 的登录凭证如果不同步那每台机器第一次启动后都要重新扫码登录一次虽然不麻烦但记忆文件已经同步过去了体验会有点分裂。如果同步登录态要注意两点一是不要把这个同步目录分享给不信任的设备二是云端备份层面尽量加密。家里两台自己的机器之间同步登录态风险和便利权衡下来我选择便利。4. 五个坑的完整排查记录4.1 退出不彻底带来的 SQLite 锁库第一个坑来得很快第一天配置完 Syncthing 我就遇到了。现象是Windows 笔记本上正常关掉 WorkBuddy 界面然后触发同步几分钟后打开桌面台式机上的 WorkBuddy直接崩溃日志里全是database is locked。排查链路是这样的先用 Windows 的任务管理器检查 WorkBuddy 相关进程发现主界面虽然关了但后台还有一个常驻的workbuddy-server进程没退干净。这个进程一直占着 SQLite 数据库文件Syncthing 同步过去的是一个正在被写入、尚未完整落盘的数据库副本另一台机器打开自然出错。解决方式也简单在任务管理器里把所有 WorkBuddy 相关进程全部结束后再同步。同时我在 Syncthing 里对数据库类文件设置了只在特定时间段同步的规则虽然最后觉得鸡肋删掉了但先彻底退出再触发同步这条铁律算是刻进脑子里了。4.2 跨机路径不一致导致项目全部失踪同步跑通三天后我在台式机上发现 WorkBuddy 里的项目索引全部失效点击任何项目都提示路径不存在。排查之后发现原因令人哭笑不得我笔记本上的项目放在D:\Users\me\WorkBuddyProjects而台式机上同样名字的目录在C:\Users\me\WorkBuddyProjects。WorkBuddy 项目索引里保存的是绝对路径同步这个索引文件到另一台机器路径不一致系统自然找不到项目。这类问题还容易蔓延到 config 文件里记录了模型缓存位置的绝对路径、某些资源的本机路径换机后全部失效。解决办法是统一两端目录结构。我花了一个晚上把两台机器的项目目录、WorkBuddy 数据目录调整成完全一致的相对路径布局这样同步过去的文件才有意义。这里也呼应了热搜词里workbuddy 搬迁项目 win的需求——搬迁本身不难难的是搬迁后让所有路径在另一台机器上继续有效。4.3 忽略规则正则误伤记忆目录第三个坑是我自己写忽略规则时踩的。某个版本我图省事写了一行类似(?i)*cache*的模糊规则本意是排除带 cache 字样的所有目录结果它把名字里任何位置包含 c-a-c-h-e 的路径全部排除了。更糟的是我有个 memory 子目录叫cache_memory_hooks直接中招导致所有会话记忆完全没有被同步我在台式机上怎么也看不到笔记本上的新对话记录。排查过程中我先确认 Syncthing 状态正常设备连接也好好的然后去查看了当前忽略列表才发现那个记忆子目录被静默忽略了。Syncthing 有条命令能列出某目录的忽略命中情况一查就暴露了。教训就是忽略规则必须精确到路径片段比如/cache/而不是全局*cache*。我现在用的是明确子目录加正斜杠限定的写法宁可多写两行也不贪图通配符的省事。4.4 Windows 符号链接权限难题这个坑属于云盘软链接方案的遗留问题但也值得记录。曾经一度我想在 Windows 上把 WorkBuddy 数据目录软链到云盘目录执行mklink /D后 WorkBuddy 启动完全正常但只要一写文件就报没有足够的权限或者文件句柄无效。根因是 Windows 的符号链接创建需要管理员权限或者开发者模式我用普通权限创建了一个伪链接系统虽然接受了但在实际读写时会受到权限限制。加上云盘客户端会监控链接指向的真实目录两边一叠加行为就非常怪异。排查到最后我选择了放弃软链接方案直接用 Syncthing 的本地目录作为 WorkBuddy 的数据目录。这个决定反而让配置简单了一大截也让我明白了一个道理在跨机数据打通这件事上原生同步工具永远比软链接云盘这种组合拳可靠。4.5 冲突文件与规则文件的单写多读跑通双写之后最大的困扰变成了一堆冲突文件。Syncthing 里每天都会出现rules_user.md.sync-conflict-20250112-001.dat这种文件用倒是能用但目录越来越脏强迫症很难受。查下来发现冲突主要集中在我两台机器上都会编辑的规则文件上。WorkBuddy 有个特性——通过规则文件控制 AI 的行为方式和输出风格也就是热搜词里说的给 workbuddy 定几条规则。这类文件体积小、编辑频繁、双方都在改自然是冲突重灾区。我最后的解法是单写多读策略rules 和 skills 这类配置型文件只在固定的主力机上修改另一台机器只读并用。而 sessions 和记忆目录保持双写。这个策略执行之后冲突文件数量从每天十几个降到了基本为零。中间我为规则文件额外开启过 Syncthing 的版本控制保留最近 30 天版本即使偶尔改坏了也能快速回滚。5. 现在我的双机日常与改进建议5.1 一套务实的双机切换流程配置稳定运行后我给自己定了一套切换机器的标准化流程供参考下班或离开主力机前确认 WorkBuddy 里当前会话已经保存然后彻底退出所有 WorkBuddy 相关进程。打开 Syncthing 界面看一眼已同步状态确认没有待处理的变化。到另一台机器上先启动 Syncthing等待同步完成后再打开 WorkBuddy。如果 Syncthing 弹出了冲突文件提示先不急着删点进去看一眼是哪个文件冲突。如果是配置类文件人工决定保留哪一版如果是会话记忆文件通常两边都会保留不影响使用。这套流程听起来有些繁琐但实际做下来也就一分钟以内的事。Windows 上我建议把 Syncthing 设置成开机自启Linux 上则用 systemd 服务托管省得每次手动启动。5.2 围绕双写还能做的备份与安全增强双写同步解决了多机一致的问题但没解决误删回滚和备份安全的问题。所以我额外做了两件增强。第一是启用 Syncthing 的版本控制功能。在目录设置里开启版本控制—错开版本模式保留最近若干天的文件历史。这样即使某天在 A 机上误删了记忆目录中的一个大文件它在 B 机上的历史版本也还在随时能捞回来。第二是给同步目录做定期镜像备份。我写了一个每天凌晨执行的 tar 脚本把整个 WorkBuddy 数据目录打包到本地另一个磁盘同时在关键里程碑节点比如完成一个项目问答库的构建手动再打一份快照。云端的登录态文件和 token 类内容我特意从备份脚本里排除掉了避免备份文件泄露后连带账号一起曝光。安全性方面还可以更进一步。如果你工作环境对数据隐私要求高建议对整个同步目录做一层磁盘加密Windows 上可以用 BitLockerLinux 上用 LUKS。这类加密是透明的WorkBuddy 完全无感知但任何第三方拿到同步文件都只能看到密文。最后分享一点个人体会多机共用一个 WorkBuddy 账号真正考验人的不是登录这个过程而是你对数据流的管理意识。只要搞清楚了哪些数据值得同步、哪些该隔离、什么时候允许双写、什么时候必须单写这个问题就能稳定地解决。希望这篇实践记录能帮你少走我踩过的那几个坑。