Windows*Linux*Mac三端协同:OpenClaw多节点同步实战

What's up， 大家！这是我的第 14 篇原创文章。

三台机器、三个操作系统、一个持续推进的 OpenClaw 项目。Windows 负责写需求、审结果，Ubuntu 虚拟机负责执行和部署，Mac Mini 负责资源密集型任务。问题不是“能不能连起来”，而是怎么让最新需求、最新配置和最新产出稳定地在三端之间流动，而且不会把整个仓库拖进同步泥潭。

为什么 Git 和网盘都不是这次的答案

我一开始也想偷懒，觉得 Git 或网盘总有一个能直接用。真上手之后才发现，它们解决的是“文件传过去”的问题，不是“多节点协作不翻车”的问题。

我这套环境里，真正需要跨节点流动的其实只有三类东西：

核心矛盾不是“怎么同步所有内容”，而是只同步协作链路里真正会影响下一步决策的文本内容。

先把边界画清楚：谁负责什么，什么该同步

三个节点的职责分工

真正纳入同步的 7 类内容

必须排除的内容

# 1. 大体积媒体
*.mp4;*.mov;*.avi;*.mkv
*.mp3;*.wav;*.flac
*.png;*.jpg;*.jpeg;*.gif;*.bmp

# 2. 设计源文件
*.psd;*.ai;*.sketch

# 3. 依赖与缓存
node_modules\
oh_modules\
.gradle\
__pycache__\

# 4. 构建产物与日志
build\
dist\
*.log

# 5. 版本元数据
.git\

这一步如果不先做，后面所有“同步提效”都是伪命题。边界没画清楚，工具越自动，出事越快。

当前可落地的方案：Beyond Compare + SFTP + 双向确认

这套方案的关键不是某个工具本身，而是它允许我先比较，再决定同步方向。

落地步骤

冲突处理规则

我每天怎么跑这套流程

真正好用的不是“能同步”，而是你每天都知道什么时候该同步、同步完要看什么。

**操作流程：**拉取夜间结果 → 更新最新需求 → 推送执行端 → 阶段回传 → Windows 审核收口

我现在的频率大概是一天 4 到 6 次。不是越勤越好，而是每次同步都对应一个明确的协作节点，这样冲突不会堆积，审核也不会失焦。

第二阶段为什么还不能直接全自动

很多人看到这里会问：既然已经知道同步规则了，为什么不直接上自动监听？

答案很简单：自动监听解决的是触发问题，不解决冲突决策问题。

第二阶段我会做成“监听 + 防抖 + 批量触发”的形态，但现在还没上线，因为下面两个条件还没完全收口：

from watchdog.events import FileSystemEventHandler


class SyncHandler(FileSystemEventHandler):
    def __init__(self, sync_scopes, exclude_rules):
        self.sync_scopes = sync_scopes
        self.exclude_rules = exclude_rules

    def on_modified(self, event):
        # 1. 只关心被纳入同步边界的内容
        if not self.in_sync_scope(event.src_path):
            return

        # 2. 命中排除规则则直接跳过
        if self.is_excluded(event.src_path):
            return

        # 3. 进入防抖队列，合并短时间内的多次修改
        self.schedule_batch_sync(delay_seconds=5)

所以第二阶段的重点从来不是“把监听脚本写出来”，而是把同步边界、冲突优先级、批量触发规则写清楚。

别忽略 Skills：多节点最容易漏同步的其实是规则版本

多节点协作里最隐蔽的问题，不是代码没同步，而是约束没同步。Windows 上刚改完一条 Skill 规则，执行端如果还在读旧版本，结果就会出现“同一句命令、三台机器、三种行为”。

我现在的做法是把 Skills 治理成单源：

这一步看起来不起眼，但它决定了多节点是不是“同一个团队”。代码可以晚几分钟同步，规则版本一旦错开，执行结果就会立刻跑偏。

真正容易返工的地方

多节点同步没有银弹，真正有用的是一套可重复的协作秩序。对我这套 OpenClaw 环境来说，当前最稳的答案不是“最自动”，而是边界足够清楚、同步足够克制、决策最终能回到一个主控端。

历史文章，请看这里：