技能介绍

要解决的问题

OpenClaw 在真实环境里出的问题，往往不是单一故障：网关崩了会导致所有渠道同时断线；多用户远程访问时直接暴露端口，容易变成安全事故；dmPolicy 或配对模式配置不当，会让本该隔离的会话变成公开入口；macOS 与 Linux 的守护进程管理方式不同，装完才发现没设自启动。这类排查需要同时理解运行时、网络拓扑、权限策略和渠道依赖，靠零散搜索很容易漏掉前置条件。

它如何工作

这个技能的核心是一套先判断再给命令的工作方式：

平台与运行时前置检查：先确认操作系统和 Node.js 版本，Node.js ≥22 是安装的前置条件，不满足时先引导 nvm install 22 && nvm use 22。
部署范围分流：单用户本地默认 loopback；多用户或远程访问优先走 Tailscale Funnel，而不是端口转发或 public bind。
渠道类型识别：区分云端渠道（Telegram、Slack）和设备依赖型渠道（iMessage、Signal），后者要求设备在线且完成配对。
安全姿态判断：默认 DM pairing，开放模式是明确 opt-in；修改 dmPolicy 前需确认可信网络或 Tailscale 范围。
诊断优先于猜测：先跑 openclaw gateway --verbose 拿到日志，再谈配置修改。
可执行输出：给出可复制粘贴的 CLI 命令、带真实键名的 ~/.openclaw/openclaw.json JSON/YAML 片段，并按 macOS 的 launchd 与 Linux 的 systemd 分别给出路径。每个配置变更都附带回滚方法。

关键步骤：确认平台与 Node 版本 → 判断部署范围与渠道类型 → 检查安全策略 → 用 verbose 日志定位 → 给出平台分支命令与回滚方案。

适用边界

适合安装升级 OpenClaw、配置 Gateway 端口与 bind 地址、接入或排查 Telegram、Slack、Discord、iMessage 等渠道、设置配对码和访问控制、管理 ClawHub skills、配置 OpenAI、Anthropic 或本地 Ollama 模型端点、诊断守护进程崩溃与鉴权失败。

不适用于开发自定义 OpenClaw skill/plugin（应使用 backend-developer）、Kubernetes/Terraform 等通用云基础设施（应使用 devops-engineer）、模型微调或训练（应使用 ai-ml-engineer），以及从零开发 Telegram bot 这类平台 API 工作。§10 的常见陷阱、§11 的跨技能组合（DevOps、Security、Prompt Engineer）和 §14 的验证清单提供了更细的约束。