你的 AI 不应该只活在一台机器上

我有一台 Mac Mini、一台 Linux 笔记本、一台远程 GPU VPS，还有一台吃灰的安卓手机。

每台设备都有自己擅长的事：Mac Mini 跑日常开发和 AI 对话，Linux 笔记本跑测试和构建，GPU VPS 跑本地模型推理，安卓手机……好吧，安卓手机目前只用来看消息。

问题是：当我想让 AI 帮我完成一个复杂任务时，它只能用当前这台机器的资源。想跑个本地模型？得 SSH 到 GPU VPS。想在 Linux 上跑测试？得手动切过去。每台设备都是一座孤岛。

我想要的是：跟 AI 说一句话，它自己决定用哪台设备、怎么分配任务、怎么把结果汇总回来。

所以我开始写 claw-mesh。

为什么不用现有方案

市面上做”多设备 AI”的项目不少，但它们解决的问题和我不一样：

exo 很酷——把多台设备变成一个推理集群，用 Tensor Parallelism 跑大模型。但它只做推理。你不能让它”在 A 机器上 clone 代码，在 B 机器上跑测试，在 C 机器上部署”。

Clusterflock 做的是 GPU 编排——自动检测 VRAM，把模型塞到最合适的 GPU 上。本质上是个”穷人的 GPU 调度器”。

这些项目的节点都是”算力提供者”——它们提供 GPU、提供内存、提供计算。但我的设备不只是算力，它们各自有独特的能力：Mac Mini 有我的开发环境和文件系统，Linux 笔记本有特定的工具链，GPU VPS 有显卡，安卓手机有摄像头和传感器。

claw-mesh 的节点是”能力提供者”。每台设备声明自己能做什么，coordinator 根据任务需求把工作路由到最合适的设备。

用 Go 写的，原因很简单：单二进制分发，交叉编译到 ARM/x86/macOS/Linux 都很方便。一个 Agent 编排器如果需要用户在每台设备上装 Python + pip install 一堆依赖，那它就已经失败了。

核心组件：

节点加入 mesh 的过程是自动发现的——同一个局域网内的设备会通过 mDNS 互相找到。远程设备通过 Cloudflare Tunnel 或者直接配置地址接入。

技术上最难的不是分布式通信（Go 的 goroutine + channel 天然适合这个），而是任务路由的决策。

一个用户说”帮我分析这个 repo 并生成文档”，coordinator 需要决定：

这不是简单的负载均衡，而是基于能力的路由。每个节点的能力是动态的——GPU VPS 可能正在跑别的推理任务，Linux 笔记本可能磁盘快满了。

目前的方案还比较朴素：节点定期上报能力和负载，coordinator 用贪心算法匹配。未来想做成更智能的——让 LLM 自己决定任务怎么拆、怎么分配。

用 React 写了一个 dashboard，能看到所有节点的状态、正在跑的任务、消息流。说实话前端不是我的强项，这部分 vibe coding 的成分比较大。但能用。

最有成就感的时刻是第一次在 dashboard 上看到三台设备同时在处理不同的子任务，消息在节点之间流转，最后汇总成一个结果。那种感觉就像……你搭了一个乐高机器人，然后它真的动起来了。

做 claw-mesh 的过程中，我越来越觉得单机 Agent 和分布式 Agent 面临的核心问题是一样的：怎么让 Agent 变得更好。

单机层面，Lumos 在做的是：通过 trajectory 记录和自动评估，让 Agent 的 Harness 自我优化。

分布式层面，claw-mesh 在做的是：通过能力声明和任务路由，让多个 Agent 协作完成单个 Agent 做不到的事。

它们是同一个问题的两个维度。Lumos 让每个节点更强，claw-mesh 让节点之间能协作。

v0.2 开发中。LAN 节点基本稳定，WAN 穿透还有些 edge case 要处理。安卓手机作为节点的支持正在做（Termux + Go binary）。

我想做一个 demo：四台设备同时工作，用手机俯拍桌面，终端同时滚动。不需要任何文字解释，30 秒视频就能说明一切。

但在那之前，得先把树莓派搞定。那个小东西已经折腾我好几周了。