安装 OpenClaw
一篇务实的 OpenClaw 安装指南，覆盖推荐的 onboarding 路径、平台选择、首轮验证，以及安装完成后该先做什么。
最快的受支持安装路径
如果你现在只想用最短路径把 OpenClaw 装起来，顺序其实很简单：
- 先装 CLI
- 运行
openclaw onboard --install-daemon - 验证 Gateway
- 打开 Control UI
- 确认基础链路正常后，再去加渠道和额外能力
关键点在于，OpenClaw 现在把 onboarding wizard 当成正式安装路径的一部分，而不是可有可无的附加工具。官方 README 和文档都已经把 openclaw onboard 放在安装流程中心。
什么才算“安装成功”
真正的安装成功，不是“命令跑完了”。
你至少要确认四件事：
openclawCLI 可以用- Gateway 能启动，并且能稳定运行
- workspace 已创建且可写
- 你至少有一种真实可用的对话入口
最后一点很重要。第一次可用聊天，最快通常不是 Telegram，也不是 WhatsApp，而是浏览器里的 Control UI。官方文档之所以强调 dashboard，就是为了把“渠道配置”从首轮验证中拿掉。
开始之前，先选对安装路线
macOS
对大多数单人操作者来说，macOS 仍然是最干净的第一条路线。它最容易帮你先验证本地运行、onboarding 流程，以及基本 operator loop 是否成立。
如果你走这条路线，继续看：
Docker
Docker 适合你已经明确想要环境隔离，或者你本来就准备往服务化部署方向走。它不一定是最适合每个人的第一步。
如果你走这条路线，继续看：
Windows
OpenClaw 在 Windows 上目前最合理的理解方式，是 通过 WSL2 安装，而不是把它当作原生 Windows 优先运行时。官方平台文档对这一点写得很明确。如果你的主力机器是 Windows，最稳的心理模型就是“在 Windows 里跑 Linux”。
VPS 或远程主机
只有当你真的需要长期在线时，VPS 才更合适。它会额外引入认证、暴露方式、节点、备份和远程访问这些问题。如果你现在还不需要 always-on，先本地安装通常更划算。
安装前置条件
开始之前，先确认这些前提成立：
- 已经有 Node 22 或更高版本
- 准备以 Node 作为主运行时
- 如果你在 Windows 上，愿意走 WSL2
- 至少已经想好一条模型或 provider 路径
官方平台文档也明确提到，Bun 不是推荐的 Gateway 运行时。这不代表 Bun 一无是处，但如果你的目标是稳定完成第一次安装，就不要一开始就偏离默认运行时。
先安装 CLI
当前官方 Getting Started 给出的入口是：
macOS / Linux
curl -fsSL https://openclaw.ai/install.sh | bashWindows PowerShell
iwr -useb https://openclaw.ai/install.ps1 | iex但如果你在 Windows 上，更好的实际顺序仍然是：
- 先安装 WSL2
- 在 WSL 里的 Ubuntu 终端中操作
- 把 OpenClaw 当作 Linux 安装来跑
如果你是为了贡献源码而不是普通使用者安装，那是另一条流程。这篇 /install 页面应该优先服务正常用户安装路径。
运行 onboarding wizard
真正的安装核心是这一步：
openclaw onboard --install-daemon它不是一个简单的便利命令，而是在帮你一次性解决最容易漏掉的安装环节：
- 模型与认证配置
- workspace 路径
- Gateway 端口与认证方式
- 可选渠道
- daemon 或 service 安装
- 健康检查
- 可选 skills
如果你是第一次安装，先用默认流程。QuickStart 不是给初学者“阉割功能”，而是在帮你绕开很多没必要的早期歧路。
wizard 实际帮你做了什么
当 openclaw onboard --install-daemon 正常完成时，它解决的不只是一个问题。
它会创建一个可用 workspace
OpenClaw 不是只有一个二进制文件。它需要真实的工作区。官方文档描述的 workspace 里会有 AGENTS.md、SOUL.md、USER.md 以及可选的 memory 文件，所以安装和后续运维状态从第一天就是连在一起的。
它会安装 Gateway 服务
服务形式取决于系统：
- macOS 使用 LaunchAgent
- Linux / WSL2 使用 systemd user service
这也是 --install-daemon 重要的原因。第一次安装时，Gateway 能被稳定重启、稳定检查，比“只在某个终端窗口里跑起来过一次”重要得多。
它把安装顺序收敛到正确轨道上
wizard 的默认顺序其实很合理：
- 先本地 Gateway
- 先一个 workspace
- 先把 auth 配好
- 先让一条对话路径跑通
这不是保守，而是运维上正确。
先验证 Gateway，再做别的
不要在“安装命令刚跑完”之后，立刻跳去调渠道、群组路由或公网接入。
先做基础检查：
openclaw gateway status
openclaw status
openclaw doctor这一阶段你想看到的是很无聊的结果：
- Gateway 是可达的
- 配置基本正常
- 运行时和认证没有明显缺口
- 自检没有指出基础依赖缺失
如果这些检查都没过，你遇到的仍然是安装问题。不要过早把它误判成 Telegram 问题或模型问题。
用 Control UI 做第一次真实验证
官方文档明确把 dashboard 当成最快的第一次聊天路径：
openclaw dashboard必要时你也可以直接访问本地 Gateway URL。重点不是入口形式，而是先证明这条最基础的闭环已经成立：
- Gateway 在运行
- UI 能连上
- assistant 能回复
这比一上来调渠道配置要干净得多。
第一次启动之后，正确的下一步顺序
当 dashboard 已经能正常工作时，后续动作仍然应该保持收敛。
1. 先确认一条模型路径
不要在第一天把所有 provider 都配满。先确认一条你信任的路径确实能工作。
需要参考时看这里：
2. 只加一个渠道
通常 Telegram 是最适合作为第一个渠道的，因为它比很多更重的通信面更容易排查。
3. 在开放访问前先看安全
官方文档对这点写得非常明确：所有入站消息面本质上都是不可信输入。安装成功不等于安全上线。
常见安装错误
一开始同时动太多系统
安装、认证、渠道、模型、远程节点，本来就是不同问题。如果你一次全改，你就失去了清晰排查的能力。
把 Docker 当成默认“专业方案”
Docker 很有用，但不等于更简单。如果你的真实目标只是确认 OpenClaw 是否适合你，本地 onboarding 往往是更好的第一步。
在 Windows 上无视 WSL2
官方 Windows 文档并没有把原生 Windows 当作推荐路径。如果你一上来就和这个建议对着干，就是在主动给自己加难度。
跳过 service 安装和健康检查
前台跑起来一次，不等于装好了。只有当 Gateway 能被检查、能被重启、能被稳定理解时，安装才算完成。
混淆本地和远程假设
很多人会把这几种状态混在一起：
- Gateway 跑在本地
- Gateway 跑在远程
- 浏览器控制在另一台机器上
- node 也在别处
你离开 local-first 默认值越远，就越需要明确“哪一部分到底跑在哪里”。
到底该选哪条路线？
如果你还不确定，可以用这条简单规则：
- 想走最干净的本地优先路线，就选
macOS - 主力机器是 Windows，就选
Windows via WSL2 - 已经明确要容器化部署，就选
Docker - 只有当长期在线比简单性更重要时，才优先
VPS
这比问“哪条路线看起来更高级”有用得多。
FAQ
安装 OpenClaw 的推荐方式是什么？
先安装 CLI，再运行 openclaw onboard --install-daemon，然后验证 Gateway，最后通过 Control UI 完成第一次可用聊天。
我必须买一台 Mac mini 才能跑 OpenClaw 吗？
不用。macOS 只是一个很方便的路线，不是硬门槛。Windows via WSL2 和 Linux 路线也都支持。
Windows 支持吗？
支持，但推荐路径是 WSL2。把它理解成“在 Windows 里跑 Linux”会更接近当前真实体验。
我应该一开始就用 Docker 吗？
只有当你本来就明确需要 Docker 的隔离或部署方式时才这样做。否则，本地 onboarding 通常是更好的第一步。
安装完后我第一件事该做什么？
先验证 Gateway，打开 dashboard，确认一条模型路径正常，再去加一个渠道并检查安全配置。