Agent Mesh：让所有设备像一台电脑

一句话：让我所有的设备像一台电脑，我只跟一个 agent 说话。

1. 出发点

我有好几台电脑，每台都装了 Claude Code、Codex 这些 agent，也开了远程控制。用下来有三个问题：

1. 配置太麻烦：每台都要单独安装、单独登录、单独配远程控制，加一台新电脑就得重来一遍。
2. 没有一个总的入口：没有一个 agent 能让我直接对话，在更高的层面管理所有电脑和电脑上的 agent。比如我想说一句"找台电脑把 Drive-In 跑起来"，现在做不到。
3. 资源浪费：这些电脑的 CPU、GPU、内存、磁盘大部分时间都闲着。

我想要一个像 Tailscale 一样好装、好用、安全的东西，把所有设备连起来，让 agent 面对的是一个集群。

2. 需求清单

2.1 最初的三个问题

2.2 后来补充的五个要求

3. 核心认识

3.1 一台设备上有什么

"资源"一词有两个意思，要分清：

• 硬件资源：CPU、GPU、内存、磁盘空间、网络。
• 设备上的东西：任何能被叫出名字、能被使用的东西，如文件、软件、服务、屏幕。

3.2 agent 就是设备上的软件

在设备层面，Claude Code、Codex 和 Blender 没有本质区别：都是装在某台设备上的程序，有可执行文件、配置和登录状态，可以被启动、停止、更新、监控。

所以：

• 节点程序的核心不需要懂 agent，只需要知道"这台设备装了什么软件、怎么启动、它是否还活着"；
• 中立性自然就有了：Claude、Codex、pi、Blender 都只是软件清单里的一行。

3.3 但 agent 是特殊的软件

对顶层 agent 来说：Blender 是工具，Claude Code 是下属。工具直接用；对下属是交代目标、盯进度、回答它的问题。

4. 两条路线

4.1 定义

路线 A：每台设备一个 agent，再加一个总管 agent

• 每台设备上运行自己的 agent（Claude Code、Codex 等）。
• 总管 agent 不直接接触设备，只给各台设备上的 agent 发消息、派任务、收结果。
• 代表：Multica、Lody、Paseo、Orca、ChatGPT Dots。

路线 B：先把设备连成一个整体，再放一个 agent 去管

• 每台设备装一个节点程序，像 Tailscale 一样装上就入网、开机自启。
• 节点程序把这台设备的五层（硬件、数据、软件、服务、交互界面）都接入同一个空间。
• 一个持久运行的 agent 站在最上面，直接操作这个整体。
• Claude Code、Codex 在这里是设备上的软件，需要时交代给它们一个目标。

根本区别是基本单位：路线 A 的基本单位是 agent，设备只能透过 agent 被看到；路线 B 的基本单位是设备，agent 只是设备上的一种软件。

4.2 逐项对比

4.3 结论

• 需求大部分在设备层面（装机、资源、服务、文件、屏幕、恢复），而路线 A 的总管只能和 agent 打交道，碰不到设备本身。
• 路线 B 能包含路线 A：在 B 里，Claude Code、Codex 是设备上的软件，顶层 agent 可以给它们派任务，这就是 A 的能力。
• 路线 A 包含不了路线 B：在 A 里，没有 agent 的地方就是盲区。
• 远程桌面是 B 的兜底能力：agent 挂了、权限弹窗卡住、服务起不来，都可以从手机打开那台设备的桌面自己处理。

所以：路线 B 是底座，路线 A 是长在它上面的一层。

5. 现有产品调研

5.1 coding agent 远程控制类（都属于路线 A）

以下结论来自 2026 年 10 月初对各项目源码的阅读，关键点已抽查。这些产品迭代很快，细节可能已经变化。

其他补充：

• Paseo：单机做得最扎实（Claude 走官方 Agent SDK，Codex 走 codex app-server，其他走 ACP；权限请求推送到手机；重启后会话能续上）。安全模型是"单一主人"：任何通过认证的客户端都有全部权限；通过中继连进来的客户端没设密码也会被放行；无审计日志。Paseo Hub 有设备登记和在线状态，但自称"早期开发，可能丢数据"。
• Lody：跨设备调度最完整，但全部依赖闭源云端；共享设备给团队成员时，成员的 agent 用设备主人的系统账号运行，无文件隔离。
• Orca：体量最大，但核心是桌面开发环境。每台远程设备只记一个地址，换网络就连不上；手机用不了桌面已连上的远程设备；SSH 部署远程 daemon 的函数已写好但未接入。

5.2 其他候选

5.3 共同缺口

下面四件事，在调研过的产品里都没有（不只是文档没写，源码里也没有）：

1. 开机自启 + daemon 死后的带外恢复
2. 远程桌面与安全接管（人从手机看、操作系统桌面，密码不经过模型）
3. 普通服务管理（启动、监控、自动重启、给出地址）
4. 中立、可自托管的跨设备 agent 接口（只有 Lody 有，但后端闭源，云端可读内容）

这正是路线 B 要做的设备层。

6. 市场背景

6.1 personal agent 在 2026 年 8–9 月集中上线

6.2 用户会同时使用、来回切换多个 agent

• Hermes 推出几个月后，在 OpenRouter 上的用量就超过了 OpenClaw。
• 社区里有相当一部分用户完全换到了 Hermes，也有不少人两个同时在用。
• 一份 2026 年 9 月的 personal agent 行业综述未提到任何跨 agent 的管理层，并指出记忆、文件、技能、定时任务在 agent 之间的迁移至今没有方案。

6.3 大厂的 personal agent 出不了沙盒

Dots、Grok Bot 都是"每个 agent 配一台厂商的云电脑"，碰不到你自己的设备，也不会管理别家的 agent。这是商业立场决定的：OpenAI 不会帮你管 Claude。中立、在沙盒之外、跨越用户所有设备这个位置，大厂在结构上占不了。

7. 技术方向

7.1 节点程序（每台设备一个）

• 网络：嵌入 Tailscale 的 tsnet 库，或复用用户已有的 tailnet。不自己造 VPN。
• 常驻：作为系统服务安装（macOS launchd、Linux systemd、Windows 服务），开机自启，独立于任何 agent。
• 设备层能力：上报硬件资源；文件访问；软件清单与启动、停止、更新；服务管理（带重启策略）；远程桌面。
• 形态：一个安装包即可，里面可以包含后台服务、桌面组件和必要的系统辅助程序。不必为了"单一二进制"牺牲体验。

7.2 远程桌面（R1，必须）

• 节点程序直接提供，只在 tailnet 内可达，手机和电脑都能打开。
• 与 agent 无关，是所有其他功能出问题时的兜底。
• 接管期间由程序保证人和 agent 不会同时输入；如果承诺密码不被模型看到，接管期间必须停止向模型传送画面。
• 可参考的积木：

7.3 顶层 agent 怎么"看到"所有设备：命名空间模型

前面讨论过三种做法（把远程磁盘挂载成本地目录、自己实现一个按路径转发的执行环境、写一个带 host 参数的扩展），都默认"agent 在某一台机器上"，不够优雅。

更好的模型来自 Plan 9：给 agent 一个命名空间，而不是一台机器。

/n/macmini/disk/Volumes/T7/...      所有磁盘
/n/blade/disk/C/  /n/blade/disk/D/
/n/macmini/svc/drive-in/ctl         服务：写入 start / stop，读取状态
/n/macmini/agents/claude/...        设备上的 agent
/n/macmini/screen                   屏幕：远程桌面与接管入口

• 命名：一切都是路径。ls /n/*/disk 列出所有设备的所有磁盘；cp /n/a/... /n/b/... 就是跨设备复制。
• 执行位置：命令自动在离数据最近的设备上执行，并且带着命名空间。cp 安排在目标设备执行，数据只走一跳。
• 权限：给 agent 挂什么，它就只能访问什么（可只读、可只挂部分目录），权限由结构本身保证。
• 与 pi 契合：pi 只有 read、write、edit、bash 四个工具。这个模型一个工具都不加，只是把它们能看到的世界变大。

pi 现状（读源码确认）：

• ExecutionEnv = FileSystem + Shell 接口已存在（packages/durable/src/env/index.ts），其 id 字段注释为"文件命名空间，每个容器或远程主机有自己的 id"。
• pi-durable 的工具每次调用都通过 env 访问文件和进程，换实现即可，工具不用改。
• 只有本机实现 NodeExecutionEnv；ExecutionEnvs 只是"每个目录一个本机 env"的缓存。没有远程、SSH、容器的实现。
• 一个会话只能对应一个 env，所以同一个会话只能看到一台设备。
• 存储核心可以跑在 Cloudflare Durable Objects 上，但工具执行不行。
• 非 durable 版有一个 SSH 扩展示例（coding-agent/examples/extensions/ssh.ts），只能转到一台远程机器。

可用积木：9P 协议（WSL2 至今用它在 Windows 和 Linux 间共享文件）；Tailscale 的 Taildrive（内置 WebDAV，路径为 /tailnet/机器/共享名）；FUSE、macFUSE、WinFsp、rclone。

难点：网络会断（设备离线时操作必须立即报错，不能卡住）；大范围扫描慢（需要元数据索引）；把服务、屏幕、agent 做成"文件"需要自己写合成文件系统；各系统路径语义与权限差异。

7.4 agent 之间互相共享设备（任意节点的 agent 都能操作其他设备）

想法：不只顶层 agent 能管所有设备。任何一台设备上的 agent，只要被授权并拿到上下文，就能操作其他设备：

• A 电脑上的 agent 通过 Computer Use 操作 B 电脑的屏幕；
• A 电脑上的 agent 往 B 电脑的磁盘放文件；
• A 电脑上的 agent 在 B 电脑上执行命令。

在命名空间模型里，这是自然推论：

• 顶层 agent 并不特殊，它只是拿到最大命名空间的那个 agent。
• 每个 agent 会话都有自己的命名空间，也就是一组权限：能看到哪些设备的哪些部分，只读还是可写。
• A 电脑上的 Claude Code 如果被授予 /n/b/disk/Downloads 的写权限和 /n/b/screen 的控制权限，就能往 B 放文件、操作 B 的屏幕。
• 拓扑从"一个总管 + 多个下属"变成"一张网 + 多个持有不同授权的 agent"。

本地 agent 怎么用上这张网：节点程序把它暴露给本机的 agent，可以是 MCP 服务、挂载的 /n 目录，或者一个命令行（例如 mesh exec b -- <命令>、mesh cp、mesh screen b）。这样 Claude Code、Codex 不用改，用自己的工具就能操作其他设备。

需要设计好的部分：

价值：每件事都可以交给最合适的 agent 和设备组合去做。例如：GPU 机器上的 agent 渲染完，直接把结果放到 NAS；Mac 上的 agent 操作 Windows 上只有 Windows 版的软件。现有产品里，Lody 只做到"agent 给其他设备上的 agent 派会话"，没有任何一家让 agent 直接操作另一台设备的屏幕、磁盘和命令。

8. 风险

9. 下一步

9.1 优先级

1. 节点程序：装上就入网、开机自启、独立于 agent。（P1、R3）
2. 远程桌面：与节点程序一起交付，作为兜底手段。（R1、R2）
3. 顶层 agent：能对话，通过节点程序操作设备。（P2）
4. 跨设备文件操作和资源视图。（R5、P3）
5. 把各家 agent 接成设备上的软件。（R4）

9.2 先验证，再自建

在动手写之前，先用一台 Mac 和一台 Windows 做小范围验收：

优先用 OpenClaw 测完整流程，用 Aperture 测最省配置的服务管理路径。如果它们能过，就补安装、引导和恢复体验；过不了的项，就是自建的重点。

9.3 命名空间模型的最小实验

1. 用 Taildrive 或 rclone 在两台 Mac 上挂出 /n/<设备>/...；
2. 给 pi-durable 写一个最小的 MeshExecutionEnv，只实现"按路径选设备执行"；
3. 观察 agent 只靠四个工具，能否自然完成"把文件移到 Mac mini 的外接硬盘""把 Drive-In 跑起来"。

10. 来源

产品与文档

• Tailscale：Aperture GA
• Tailscale SSH 平台支持
• Tailscale：访问 NAS 与文件共享（Taildrive）
• OpenClaw：Node session catalogs
• OpenClaw：Run Codex on another machine
• OpenClaw：Computer use
• Paseo、Paseo Hub
• Lody、Lody 远程控制说明
• Orca、Remote Orca Servers
• Multica
• Zeron
• pi-mono
• Claude Code 跨会话消息
• Claude Code 自托管环境

市场

• OpenAI Dots（TechCrunch）
• Meta Muse
• Grok Bot
• DeepSeek Harness
• Personal Agent Landscape — 2026 年 9 月
• OpenClaw vs Hermes 用量数据
• OpenClaw vs Hermes 社区分析（Kilo）

macOS 权限

• JumpCloud：屏幕录制与辅助功能需本地批准
• macOS TCC 与 PPPC