Gateway
记忆、飞书接入、调度、账号与长任务的所有权都留在这里。它不需要因为多了一台机器而改变任何默认行为。
- Session / Memory 不整体迁移
- 仍是唯一的控制与投递入口
- 节点策略变更需重启生效
这不是「换了个运行环境」。这是 V 第一次能离开自己所在这台机器执行任务:Gateway 仍然是脑,远程 Node 成为可调用的手——按任务选择执行机器,而不是把一切都压在同一个 host 上。
真正的变化不是算力总量,而是执行面的边界。控制面、记忆、调度、长任务仍然留在 Gateway;远程节点只承接「能切开、且适合在那台机器上做」的那一段。
记忆、飞书接入、调度、账号与长任务的所有权都留在这里。它不需要因为多了一台机器而改变任何默认行为。
通过节点通道承接具体执行:编译、本机文件处理,以及只有那台机器才具备的工具链。它是一双手,不是第二个大脑。
节点接入最容易犯的错,是把「配对成功、显示 connected」当成完成。下面三项都留下了可复核的真实输出。
uname -s; uname -m; xcrun swift --version证明节点可达且具备 macOS 原生工具链。
xcrun swiftc -O main.swift -o mac_compute_smoke && ./mac_compute_smoke「在线」证明不了能干活,只有产物能。这是节点验收的模板。
ls ~/Documents/Versa 2025证明能按任务读取用户真实工作目录,且不越界。
一个自然的问题是:这些机器信息该记在哪里?答案是分层的——OpenClaw 官方已经持久化了身份与能力,agent 侧只需要保留官方没有的那部分。
device pairing record 就是权威存储,不存在第二个节点库。设备签名身份、role、approved capability surface、版本、连接历史都在这里。
批准的是「允许调用什么」,不是「大概能干什么」。策略层集中在 gateway.nodes.*,整棵子树 reloadKind=restart。
官方不存「什么时候该用、业务含义、有哪些坑」。这类语义只能放在 agent 自己的知识里——这是设计边界,不是遗漏。
能力扩展必须和新边界一起交付,否则第一个 Session 就会想当然。
能力与在线状态一律现场问,不靠文档背。
不必手记 nodeId;同名冲突时用精确 ID 消歧。
以该机用户权限执行,受该操作系统权限控制。
回传必须显式传输,不假设两边一致。
不可达时如实说明,不得假装在节点上执行。
Session 已固定到某 node 时须先改绑定。
远程节点解决的是把执行放到对的地方;它不解决隔离——节点跑在别人的用户权限下,既不是一次性环境,也不适合批量试错。真正的规模化开发任务需要的是可丢弃的沙盒:用完即弃、可批量、边界更强。这一层还没有做,也只是被记录为方向,而不是已完成的能力。