2 个默认命令入口：OpenClaw 的 headless node 默认提供 system.run 与 system.which。所以，主要执行获准命令、浏览器代理或 CI 自动化时，先选 headless node；需要屏幕采集、电脑控制或 macOS App 提供的原生能力时，选 macOS App。两种形态都要按任务配置权限与审批；这不是 Gateway 部署位置的比较。(OpenClaw 节点 CLI 文档)
维护 OpenClaw 自动化的开发者：需要决定 Mac 节点应提供哪些执行能力。
AI 工程师：正在把 Agent 任务从 Gateway 拆分到远程 Mac。
DevOps 工程师：需要在图形能力与无界面自动化之间选择节点形态。
最后更新于 2026 年 10 月 15 日，能力边界核对自 OpenClaw 官方文档。发布前还应复核最新文档和版本说明，确认节点公开的工具与审批行为没有变化。
01 先按任务能力划边界，不要按部署位置猜
Gateway 负责接收 Agent 请求并转发工具调用；Mac 节点负责在本机执行命令，或提供它声明且获准的其他能力。选择 macOS App 还是 headless node，判断的是执行节点要做什么，而不是 Gateway 应放在哪台机器上。
macOS App 节点包含命令执行能力，也提供屏幕采集、电脑控制等原生 Mac 能力。headless node 是无界面的执行目标，默认提供命令执行入口；浏览器代理等能力则要按配置和节点实际提供的工具确认。能执行命令不等于能控制桌面；任务涉及浏览器，也不代表一定要使用 App。(OpenClaw macOS App 文档)
在同一台 Mac 上，菜单栏 App 已内嵌 node-host runtime。如果你改用 openclaw node run 运行 headless node，就不要再同时启动 App 节点，否则同一台机器会出现两个节点身份。先定好该 Mac 的接入形态，再进行配对。(OpenClaw 配对与节点状态文档)
02 只跑获准命令或 CI 作业时，headless node 更直接
如果 Agent 需要在 Mac 上查询工具是否存在、调用获准的构建命令或执行脚本，headless node 通常更贴合任务。它连接 Gateway 并提供节点命令能力，不要求你为了命令任务额外启用桌面控制。
但“命令受限”不等于“天然安全”。你需要分别检查设备配对、命令面审批、Gateway 命令策略和节点本地执行审批。官方 CLI 支持用 --commands 限制节点声明的命令范围；执行权限仍须按实际策略配置。(OpenClaw 命令策略文档)
命令还可能受运行环境影响。服务的工作目录、工具路径与交互式终端不一定相同；终端里构建成功，不代表节点服务启动后能找到相同工具。上线前用服务实际采用的运行方式执行低风险测试，并核对输出、退出状态、工作目录和工具路径。
03 需要桌面交互时，选择 macOS App 节点
当任务必须读取屏幕、点击界面或通过桌面操作完成步骤时，选择提供相应原生能力的 macOS App 节点，并分别验收目标能力。电脑控制需要节点连接并声明对应能力；Mac 端还涉及电脑控制设置、屏幕录制、辅助功能等系统授权。具体要求以官方电脑控制文档为准。(OpenClaw 电脑控制文档)
屏幕采集成功，不代表输入控制也可用。macOS 会分别管理屏幕录制、辅助功能等权限；App 身份或权限状态异常也可能让授权无法生效。若画面可读、点击却失败，先检查实际运行的 App、节点能力声明和各项权限，再决定是否重新配对。
⚠️ 系统权限不能替代执行审批。设备配对、节点命令审批、Agent 工具策略和 macOS 权限分别控制不同环节；通过其中一项，不表示其他项也已通过。(OpenClaw macOS 权限文档)
04 浏览器与应用混合任务，确认实际调用路径
把浏览器相关任务拆开判断，比简单地按“网页操作”选节点更可靠：
- 浏览器代理：先确认浏览器运行在哪台主机、节点是否提供所需代理能力，以及目标配置文件和授权范围。若代理已满足任务，不要仅因任务访问网页就默认启用桌面控制。
- 命令启动工具：如果 Agent 只是通过获准命令启动测试、构建或脚本，按命令执行场景配置。
- 操作桌面界面：若任务必须观察屏幕、点击原生窗口或响应界面状态，则需要对应的屏幕采集与电脑控制能力，并核实系统授权。
混合任务可以拆分职责：让 headless node 承担命令或 CI 工作，让 App 节点负责确实依赖图形界面的步骤。拆分会增加节点身份、审批规则和运行状态的管理成本。若能力边界尚不清楚，先用最小任务验证单一节点是否够用，再决定是否拆分。
05 常驻与 CI 场景，先验证连接和审批链路
把节点接入持续运行的流程前，先确认 Gateway 可达、节点能启动并重新连接，再核对任务来源和执行策略。节点设备配对通过，不代表节点声明的命令已经批准；命令范围变化后也应检查待审批请求。(OpenClaw 节点主机文档)
headless node 适合无界面服务式执行，但服务在线不代表每个任务都能完成。你还要管理重启方式、凭据、日志和失联后的任务处理。macOS App 能提供额外图形能力，却需要你把本机权限与桌面状态纳入运行检查。任务若依赖桌面操作，不能只通过节点连接检测就判定可用。
用最小任务完成节点形态验收
依次完成以下检查。只有任务确实需要浏览器或图形能力时，才继续测试对应项目；不要为了验收而扩大权限。
- [ ] 核实运行形态。确认目标 Mac 使用 macOS App 节点还是 headless node；避免无意中同时启动两种接入方式。
- [ ] 验证 Gateway 连接与设备配对。在 Gateway 侧确认节点身份和连接状态；配对完成后，再检查命令面是否有待审批请求。
- [ ] 检查命令审批。查看节点本地执行审批和 Gateway 命令策略，只开放任务所需的命令。
- [ ] 执行低风险获准命令。核验输出、退出状态、工作目录与工具路径；如果服务找不到工具，先修正运行环境。
- [ ] 单独验收浏览器代理。确认请求由预期节点处理，并核对浏览器配置文件和任务所需权限。
- [ ] 单独验收屏幕与电脑控制。只有任务需要时才做；分别确认能力声明、工具策略和 macOS 系统权限。
- [ ] 记录失败后的回退方案。命令通过但图形步骤失败时，改选 App 节点或拆分任务；若不需要图形能力，就不要为此保留桌面访问。
把连接、命令、浏览器和桌面能力分开验证，有助于把失败定位到具体授权层，而不是笼统地归因于“节点没连好”。
06 对照任务场景选择节点形态
| 任务场景 | 优先评估 | 必须核对 | 不要据此推断 |
|---|---|---|---|
| 获准命令、脚本、CI 构建 | headless node | 命令审批、本地执行策略、服务环境 | 无界面就天然安全 |
| 浏览器代理自动化 | 按代理能力选择节点 | 浏览器所在节点、代理是否可用、配置文件范围 | 有浏览器任务就必须用 App |
| 屏幕采集 | macOS App 节点 | 屏幕能力声明与屏幕录制权限 | 能读屏就能点击 |
| 桌面键鼠操作 | macOS App 节点 | 电脑控制、系统权限、节点审批与工具策略 | 一个系统授权就等于全部授权 |
| 命令与桌面交互并存 | 先验收 App 节点；必要时拆分 | 两类能力是否分别通过任务测试 | 两种形态叠加就一定更可靠 |
两种形态不是简单的“轻量版”和“全功能版”。headless node 侧重无界面执行；App 节点把命令能力与 Mac 原生能力结合。只需命令时，启用桌面能力可能增加不必要的权限管理；流程依赖屏幕控制时，单独使用 headless node 又可能缺少所需能力。
07 决策清单：根据验收结果定运行方式
| 检查项 | 满足条件后的动作 |
|---|---|
| 必须采集屏幕或操作 Mac 桌面 | 选 macOS App 节点，逐项验收相关能力与权限 |
| 只需执行获准命令或 CI 自动化 | 从 headless node 开始，限制命令范围并配置本地审批 |
| 只需浏览器自动化 | 先确认节点代理能否满足目标，不预设必须用 App |
| 同一工作流既要 CI 命令又要桌面交互 | 先验证单节点；若能力或权限边界冲突，再拆分职责 |
| 无法说明为何需要桌面控制 | 暂不启用该权限，先验收最小命令流程 |
上线前还要分清各项控制的作用：配对建立节点身份，命令面审批决定节点可声明哪些命令，节点执行审批约束实际命令；屏幕与电脑控制则需另外满足能力和系统权限要求。headless node 可以限制公开命令，但权限仍要逐层配置。(OpenClaw 节点命令策略文档)
08 常见问题
OpenClaw 的 macOS App 节点与 headless node，差别主要在哪里？
判断重点不是 Gateway 放在哪里，而是 Mac 节点要向 Agent 提供什么能力。macOS App 节点结合命令执行与屏幕、电脑控制等原生能力；headless node 面向无界面执行。若屏幕或原生权限是任务硬要求，选 App；否则先用 headless node 验证获准命令链路。
headless node 能在 Mac 上运行命令吗？
能。它可以在 Mac 上运行节点命令，但调用仍受配对、命令面审批和节点本地执行审批等约束。命令执行不包含桌面控制。若任务需要操作界面，应另外验收屏幕采集和电脑控制能力。
什么情况下应给 OpenClaw 节点启用 macOS 原生权限？
当任务依赖屏幕采集、桌面键鼠操作或 macOS App 节点提供的本机能力时，才需要启用对应能力并检查系统授权。命令执行、构建脚本和浏览器代理不自动要求桌面控制。权限应按目标能力分别验证。(OpenClaw 电脑控制文档)
远程 Mac 节点上线前，怎样确定运行方式？
先写清任务需要执行的命令、浏览器代理能力，以及是否要观察或操作桌面。接着单独验收配对、命令审批和目标工具；仅需命令或代理时先尝试 headless node，必须使用屏幕或电脑控制时再选 macOS App。任务边界不同，也可以拆分节点职责。
当前依赖 Linux 或 Windows 执行时，可能缺少 macOS 专属工具链、原生权限能力，或需要另行维护 Mac 执行节点；但这不表示每个任务都应迁移到 Mac。先确认任务确实需要真实 macOS 环境，再比较自购、自行维护与远程使用：长期稳定重负载或依赖本地物理接口时，自购设备可能更合适；临时测试、短期构建或隔离的远程执行环境，则可查看 CALMVPS 的远程 Mac 方案说明 与 套餐和费用信息。下决定前，核对交付方式、工具链与权限是否符合你的工作流。