场景：你的算力和数据本来就不在一台机器上
真实的数字生活是这样的：日常开发在 MacBook 上，跑模型的高性能主机在书房，一两个 VPS 在云上挂着网站和服务，NAS 里躺着数据和备份。这些机器各自有各自的价值，但也各自是孤岛。
传统做法是 SSH 到每台机器分别操作，或者写一堆脚本互相调用。而 AgentDock 提供的方案优雅得多：每台机器跑一个 AgentDock 节点，AI 客户端连上任何一个节点（或统一入口），就能调度所有机器。 这就是「多设备编排」——把你的机器群变成一个可被 AI 调度的资源池。
这个思路和本站之前讨论的 ADE（Agent Development Environment）一脉相承：Agent 的执行环境不该被单台设备限制。
架构：节点、入口、编排
多设备部署的拓扑分两层：
AI 客户端（ChatGPT / Claude Code / 自研应用）
│
├── 直连模式：连到某个节点的 8765 端口
│
└── 中心模式：连 NexusDock 的统一 MCP 入口（18777）
│
├── AgentDock 节点 A（MacBook）
├── AgentDock 节点 B（VPS）
└── AgentDock 节点 C（GPU 容器）直连模式适合设备只有一两台的起步阶段：AI 客户端直接配某台机器的 AgentDock 地址，简单直接。
中心模式适合设备多起来之后：NexusDock 作为中心服务提供统一入口、设备管理和集中记忆（本系列有NexusDock 部署专篇）。数据本身仍留在各节点的 AgentDock 上，中心只做编排和视图——这是「数据不搬家」的设计。
单机多角色：一台机器里的多设备思维
值得先说的入门玩法：哪怕只有一台机器，AgentDock 的容器形态也能模拟出「多设备」。比如在你的开发机上同时跑：
- 一个原生 AgentDock 节点管你的开发环境
- 一个 Docker 节点专管构建和测试（环境干净，随便折腾）
- 一个 GPU 容器节点跑模型推理
三个节点三个工作区，AI 在不同任务里用不同节点，互不污染。这是「用容器隔离出专用工人」的思路，成本几乎为零。
跨设备任务的正确派法
多设备编排最常见的失败模式，是派了一个「跨机器大任务」然后 AI 自己把流程搞乱。实操下来，跨设备任务要遵守三条纪律：
第一，任务绑定设备。 派活时明确说「在 VPS 节点上重启 nginx」「在书房主机上跑这个推理」，而不是「帮我把服务重启一下」。AgentDock 的工具调用是按节点寻址的，模糊指令会让 AI 猜。
第二，产物用路径交接。 A 机器生成的文件要给 B 机器用，让 AI 用工作区文件操作下载/上传，或者走 NexusDock 的节点文件代理。不要指望 AI「记得」另一台机器上的内容——每台机器的工作区是独立的。
第三，长任务用可恢复任务。 跨机器的长流程（比如「在容器里跑完训练，把结果传回 NAS」）用 AgentDock 的任务系统托管：agentdocks task list 查状态、agentdocks task logs 看日志、失败用 agentdocks task retry 断点重试。手工盯着 SSH 窗口跑长任务的时代可以结束了。
一个真实结构的配置示例
以「Mac + VPS + GPU 容器」三设备为例，各节点的分工建议：
| 节点 | 角色 | 工作区内容 | 挂什么技能 |
|---|---|---|---|
| MacBook | 日常开发 | 当前项目代码 | Git 自动化、构建命令 |
| VPS | 线上运维 | 部署脚本、服务目录 | 进程管理、日志巡检 |
| GPU 容器 | 算力工人 | 模型与数据集 | 动态 MCP 接推理服务 |
AI 客户端侧（以 Claude Code 为例）把各节点配成不同的 MCP server 条目，或者在中心模式下只配 NexusDock 一个入口。前者灵活，后者省心。
网络与安全：多设备后暴露面翻倍
必须泼一盆冷水：每多一个节点，就多一个需要保护的入口。多设备部署的三条安全底线：
- 节点不直接暴露公网。 VPS 上的节点可以用防火墙只放行你自己的 IP 或 Tunnel；家里设备一律走 Cloudflare Tunnel 之类的穿透方案
- 每节点独立 Token。 不要三台机器用同一个
AGENTDOCK_TOKEN，一台泄露全部沦陷 - VPS 节点的工作区最小化。 只把需要 AI 操作的目录设为工作区，其余一概不给
安全配置的系统展开（包括各变量的详细说明和公网部署的权限边界）见AgentDock 安全实践，这里不重复。
多设备部署 FAQ
Q：节点之间需要互相连通吗？
不需要两两打通。直连模式下客户端分别连各节点的 8765；中心模式下客户端只连 NexusDock 的统一入口，各节点与中心保持可达即可——省掉了节点之间互联的防火墙工作。
Q：家里的设备没有公网 IP，怎么被外面连到？
走 Cloudflare Tunnel：机器上跑 cloudflared 做出站连接，不开放任何入站端口，外部客户端通过 Tunnel 域名访问节点。家庭宽带和 NAS 部署基本都走这条路。
Q：一台节点掉线会拖垮其他机器吗？
不会。各节点独立运行，任务状态、工作区数据都留在各自机器上，中心只做编排视图。某台掉线时其余节点照常接活，恢复后直接回来继续用。
Q：直连和中心模式可以混用吗？
可以。比如 Claude Code 在内网直连 MacBook 节点求低延迟，ChatGPT 走 NexusDock 入口省去逐台公网配置；两种模式按客户端的网络位置各取所需。
三个进阶技巧
- 给每台节点起带角色的名字。 派活指令里直接喊「vps-web」「gpu-box」，节点称呼和角色对得上，AI 按节点寻址就不容易找错机器。
- 跨机产物交接固定走
/artifacts和工作区路径。 把「A 机产物放哪、B 机从哪取」定成死规矩（或沉淀成 Skill），交接就不再依赖每次口头描述。 - 长流程一律进任务系统。 开头就让 AI 用可恢复任务托管，中途断网、机器重启都能用
agentdocks task retry续上，比人肉盯着重跑省心得多。
什么时候升级到 NexusDock
经验值是三台：设备少于三台时直连足够，配置成本最低；到三台及以上，每台都配一遍客户端会开始烦，Token 管理开始乱，这时候上 NexusDock 中心模式，统一入口加集中记忆的收益就体现出来了。
下一篇就是 NexusDock 的部署教程——Docker 一条命令起服务，18777 端口打开控制台，你所有节点的状态一目了然。