在个人 AI 助手领域，跨平台能力与安全性往往是难以兼顾的两极。OpenClaw 作为一款开源的个人 AI 助手项目，采用独特的 "龙虾方式" 实现了在任何操作系统上运行、连接任意消息渠道的能力，同时通过分层隔离机制确保运行时安全。其架构设计回避了传统 Bot 框架的轻量客户端模式，转而采用 Gateway 中心化控制平面，配合节点远程执行与 Docker 沙箱隔离，形成了一套完整的跨平台执行方案。
Gateway 中心化架构与网络隔离模型
OpenClaw 的核心架构建立在 Gateway 中心化设计之上，这与传统 Bot 框架的轻量客户端模式形成了鲜明对比。Gateway 是唯一负责管理所有渠道连接的长运行进程，默认监听 ws://127.0.0.1:18789 端口提供 WebSocket 控制平面。这种 loopback-first 的网络策略确保了默认情况下所有通信仅限于本地，即使 Gateway 需要暴露给远程访问，也必须通过 SSH 隧道或 Tailscale Serve/Funnel 等机制实现，且需配合认证令牌使用。
从架构演进来看，OpenClaw 经历了从 Clawdbot 到 Moltbot 再到 OpenClaw 的三次更名，每一次蜕变都伴随着架构的深化。"龙虾方式" 不仅是项目命名来源，更隐喻了其跨平台适应能力 —— 如同龙虾能在多种海洋环境中生存，OpenClaw 被设计为可在 Windows、Linux、macOS 上运行，并通过节点机制延伸至 iOS 和 Android 设备。这种适应性的技术基础正是 Gateway 的平台无关性：Gateway 本身是用 Node.js 编写的单一二进制，能够在任何支持 Node 22+ 的系统上运行，而平台特有的功能则通过节点系统暴露。
Gateway 的职责边界清晰且集中：管理渠道连接、处理会话路由、协调代理通信、服务控制 UI、提供 Canvas 渲染能力。这种设计避免了多进程间的状态同步问题，也使得安全策略能够统一实施。值得注意的是，官方建议一台主机仅运行一个 Gateway 实例，这是因为某些渠道（如 WhatsApp Web）需要在同一进程内维护会话状态，多实例可能导致冲突。
节点系统与操作系统差异抽象
跨平台 AI 助手的核心挑战之一是如何在统一抽象层下处理不同操作系统的本地能力。OpenClaw 通过节点系统（Nodes）解决这一问题，将 macOS、iOS、Android 等设备的特有功能通过 WebSocket 协议暴露给 Gateway，由 Gateway 统一调度执行。
节点系统的设计遵循外围设备模型：节点本身不运行 Gateway 服务，仅作为外围设备连接到 Gateway 的 WebSocket 服务器。连接时，节点以 role: "node" 身份握手，并通过 node.invoke 方法暴露其命令表面（command surface），包括 Canvas 操作、相机拍照录像、屏幕录制、位置获取、系统命令执行等功能。macOS 平台的菜单栏应用还能以节点模式运行，使其本身也能被远程管理。
这种架构的核心优势在于操作系统差异的透明化。对于消息接收、模型调用、工具路由等通用流程，Gateway 无需感知底层操作系统的细节；而对于需要平台特定能力的操作（如 macOS 的系统通知、iOS 的相机访问），则通过节点协议转发至对应设备执行。节点的权限状态通过 node.list 和 node.describe 方法中的 permissions 字段报告，Gateway 可据此判断哪些能力当前可用。
对于需要在异构环境中执行命令的场景，OpenClaw 提供了节点主机（Node Host）机制。当 Gateway 运行在 Linux 服务器上而需要在 macOS 设备上执行命令时，可将 Gateway 的 exec 工具指向节点主机，由节点在本地执行系统命令。这种设计将模型推理与命令执行分离，既保持了架构的一致性，又解决了跨平台命令执行的问题。
统一插件模型：AgentSkills 兼容的技能系统
OpenClaw 的插件系统采用了 AgentSkills 规范，这是一种面向 AI 代理的工具描述格式。每个技能（Skill）是一个包含 SKILL.md 文件的目录，通过 YAML 前 matter 定义元数据，后跟自然语言指令告诉代理何时及如何使用该技能。
技能加载遵循三级优先顺序：工作空间技能（<workspace>/skills）拥有最高优先级，其次是托管技能（~/.openclaw/skills），最后是捆绑技能（随安装包分发）。这种层次设计允许用户在不修改原始安装的情况下覆盖或扩展功能，也支持不同代理拥有各自的技能集。在多代理配置中，每个代理的工作空间是独立的，因此其技能目录也相互隔离；而共享技能目录（~/.openclaw/skills）则对所有代理可见。
技能的门控机制是其工程化管理的关键。通过 metadata.openclaw.requires 字段，技能可在加载时根据多个维度进行过滤：二进制依赖（bins 列表检查 PATH 中的可执行文件）、环境变量依赖（env 列表验证配置或 API 密钥）、配置项依赖（config 列表检查 openclaw.json 中的设置）以及操作系统过滤（os 列表限定可用平台）。这种加载时过滤避免了运行时错误，也使得技能能够自适应不同环境。
OpenClaw 还提供了 ClawHub 作为公共技能注册表，用户可以浏览、安装和同步社区贡献的技能。技能安装默认写入当前工作目录下的 ./skills 文件夹，Gateway 会在下次会话启动时将其识别为工作空间技能。CLI 命令如 clawhub install <skill-slug> 和 clawhub update --all 提供了便捷的管理接口。
对于需要秘密注入的场景，skills.entries.<skill>.env 和 skills.entries.<skill>.apiKey 允许在配置中定义环境变量，这些变量会在代理运行时注入到主进程环境（而非沙箱容器），并在运行结束后恢复原状。安全提示强调应将第三方技能视为不受信任代码，并在沙箱环境中运行。
运行时隔离：Docker 沙箱配置与工具策略
OpenClaw 的运行时隔离机制是保障多用户或高风险场景下系统安全的关键设计。不同于简单的进程级权限控制，OpenClaw 采用了 Docker 容器作为隔离单元，允许在主机 Gateway 进程之外创建独立的工具执行环境。
沙箱模式通过 agents.defaults.sandbox.mode 配置，支持三种选项：off 表示关闭沙箱（所有工具直接在主机执行）、non-main 表示仅对非主会话启用沙箱（主会话保留完整权限）、all 表示对所有会话启用沙箱。隔离范围（scope）则决定了容器的复用策略：session 为每个会话创建独立容器、agent 为每个代理创建独立容器（同一代理的多个会话共享容器）、shared 则所有会话共享一个容器 —— 后者会禁用会话间隔离。
工作空间访问控制（workspaceAccess）决定了沙箱内的代理能访问哪些文件：none 表示仅使用临时沙箱目录（~/.openclaw/sandboxes）、ro 表示将代理工作空间以只读方式挂载至 /agent（此时 write、edit、apply_patch 等操作被禁用）、rw 则允许读写代理工作空间。对于需要访问本地文件的场景，正确的配置至关重要。
Docker 容器本身的硬化通过 agents.defaults.sandbox.docker 下的众多参数实现。网络策略默认使用 none（完全禁止出站连接），如有需要可显式启用。资源限制包括内存（memory、memorySwap）、CPU（cpus）、进程数（pidsLimit）、文件描述符（ulimits.nofile）等。安全加固选项涵盖用户身份（user）、能力降级（capDrop: ["ALL"]）、Seccomp 与 AppArmor 配置文件路径等。
工具策略是沙箱的核心控制层。默认策略允许执行以下工具：exec、process、read、write、edit、sessions_list、sessions_history、sessions_send、sessions_spawn、session_status；同时默认拒绝：browser、canvas、nodes、cron、discord、gateway。拒绝规则优先于允许规则，因此即使将 browser 加入允许列表，只要它同时出现在拒绝列表中，工具仍将不可用。
对于需要浏览器工具的场景，OpenClaw 提供了专用的浏览器沙箱镜像构建脚本（scripts/sandbox-browser-setup.sh），该镜像基于 Chromium 并支持 CDP 协议。配置时需将 agents.defaults.sandbox.browser.enabled 设为 true，并确保 browser 工具未被列入拒绝列表。
容器生命周期管理通过 prune 配置控制。idleHours 参数定义了空闲超时（默认 24 小时），超过此时长的空闲容器会被自动清理；maxAgeDays 参数定义了最大存活天数（默认 7 天），防止容器无限累积。参数设为 0 可禁用对应策略。
多代理场景下的沙箱与工具配置
在需要运行多个代理的场景中，OpenClaw 支持为每个代理配置独立的沙箱参数与工具策略。这种粒度控制使得同一 Gateway 下可以运行不同信任级别的代理：个人代理可拥有完整工具权限，家庭成员代理使用只读工具与只读工作空间，公共代理则完全禁用文件系统与 Shell 工具。
配置通过 agents.list[].sandbox 和 agents.list[].tools 覆盖全局默认值。需要注意的是，当全局 scope 设为 shared 时，代理级别的覆盖将失效，所有会话将共享同一个容器环境。工具策略的继承规则遵循明确优先级：会话级配置覆盖代理级配置，代理级配置覆盖全局配置。
远程 macOS 节点与 Linux Gateway 联动的场景存在特殊考虑。当 Linux Gateway 连接到具备 system.run 能力的 macOS 节点时，OpenClaw 可将 macOS 专属技能视为可用 —— 前提是所需二进制文件存在于该节点上。执行时，代理通过 nodes 工具（通常为 nodes.run）调用节点上的命令，这依赖于节点对命令支持状态的报告以及 system.run 的可用性。
监控与运维要点
运行跨平台 AI 助手需要关注多个监控维度。Gateway 健康状态可通过 openclaw health 命令检查，该命令会验证进程状态、端口可达性以及关键配置的有效性。容器状态可通过 Docker 命令行或 OpenClaw 的 openclaw sandbox 子命令查询，后者还提供了手动重建容器的功能。
会话管理方面，openclaw sessions 子命令支持列出当前会话、查看会话历史、发送消息至其他会话等操作。这些能力在需要协调多个代理协作的场景下尤为实用，例如让专业代理完成特定任务后由主代理汇总结果。
渠道连接状态同样需要监控。OpenClaw 提供了渠道登录与状态查询命令，部分渠道（如 WhatsApp）需要保持登录状态以接收消息。对于断线重连，可配置自动重试策略与超时参数。
沙箱容器异常是常见的运维问题。症状包括工具执行超时、文件访问错误、权限拒绝等。排查时应首先确认容器正在运行（docker ps），然后检查容器日志（docker logs <container_id>），最后验证配置是否与实际运行参数一致。权限问题通常源于挂载目录的所有权不匹配，可通过设置 docker.user 为与挂载目录相同的 UID:GID 解决，或直接修改目录所有权。
资料来源
本文核心信息来源于 OpenClaw 官方 GitHub 仓库（https://github.com/openclaw/openclaw）与官方文档站点（https://docs.openclaw.ai/），涵盖架构设计、Docker 沙箱配置、技能系统规范与节点协议等章节。