本地电脑安装 OpenClaw 详细教程：Windows 和 Mac 新手安装指南，从安装到实际运用全流程

OpenClaw Series

这篇文章属于重新整理后的 OpenClaw 安装实战篇

如果你想先看当前保留的 OpenClaw 内容入口，可以去专题导航页；如果你更偏好边看边操作，也可以后面再补配手机聊天渠道。

本文按 2026 年 3 月 27 日可查到的 OpenClaw 官方安装、CLI Onboarding、macOS App、Control UI、Windows (WSL2)、Channels、Message 与 Routing 文档整理。由于官方不同页面对 Node 要求写法略有差异，本文采用“把 Node 24 作为保守推荐基线，Windows 优先 WSL2，第一次先跑 Control UI，再谈 Select channel”的稳妥路线。

先说结论：零基础新手最稳的落地路线

如果你只想知道“到底该怎么装，才最不容易翻车”，结论非常简单：

Mac：优先用官方安装脚本 + openclaw onboard --install-daemon
Windows：优先走 WSL2 + Ubuntu，不要把第一次落地押在原生 Windows 上
第一次验证不要先配 Telegram、Discord、Slack，先用 Control UI 在浏览器里跑通
真正进入日常使用，再去配置聊天渠道，也就是你说的 Select channel

这是因为截至 2026 年 3 月 27 日官方文档里已经把路线写得很清楚：

官方当前页面至少把 Node 22+ 视为可用区间，而安装与 onboarding 相关页面又持续把更高版本作为推荐方向；为了避开边界，本文统一按 Node 24 做保守推荐
Windows 仍然明确推荐 WSL2
CLI onboarding 被列为 macOS、Linux、Windows（通过 WSL2）的推荐方案
最快的第一次对话，不需要先配 channel，直接 openclaw dashboard 就能在浏览器里聊天

所以这篇文章不会走“先接一堆渠道、再猜哪里坏了”的路线，而是走真正适合新手的最短闭环：

装好 OpenClaw
跑通 Gateway
打开 Control UI
完成第一次实际对话
再理解并配置 Select channel

这篇教程最终要帮你做到什么

你跟着做完，至少应该达到下面这 5 个结果：

你的本地电脑已经安装好 OpenClaw
Gateway 能正常运行
浏览器可以打开 Control UI，并完成第一次真实对话
你理解 Select channel 在实际运用里到底决定什么
你知道什么时候该用本地浏览器，什么时候该切到 Telegram / Discord 之类的外部 channel

如果你做完还停留在“命令装上了，但不知道下一步干什么”，那就说明这篇文章没完成任务。

为什么最新方案要这样选，而不是别的装法

很多旧教程的问题，不是命令错了，而是路线错了。

1. Node 版本不要再卡最低线

截至 2026 年 3 月 27 日，官方不同页面对 Node 的“最低可用线”和“推荐基线”写法并不完全相同，但共同点很明确：

较新的 Node LTS 才是稳妥路线
新手没必要去踩最低兼容边界

最稳妥的做法只有一个：

让安装器自动处理 Node
或者你自己提前装 Node 24

这样后面出现 sharp、全局 npm 路径、daemon 启动这类问题时，变量会少很多。

2. Windows 新手不要先走原生 Windows

官方 Windows 文档虽然写明原生 Windows 路线在持续改进，但依然明确推荐 WSL2。原因也不复杂：

CLI + Gateway 在 Linux 环境里更稳定
Node、pnpm、skills、二进制工具链的一致性更好
后面安装 daemon、调试日志、扩展 channel 时更少碰平台兼容问题

所以这篇文章里，Windows 部分一律按 WSL2 + Ubuntu 写。

3. 第一次实战不要把安装和 channel 配置绑在一起

官方 Getting Started 与 Onboarding 文档都强调了一点：

最快的第一次对话是 Control UI
先跑浏览器聊天，不需要先配任何 channel

这一步非常关键。

因为如果你一上来就配 Telegram / Discord / WhatsApp：

你分不清问题出在安装、Gateway、认证，还是 channel
你会同时面对 bot token、pairing、allowlist、routing
新手很容易把本来 10 分钟能跑通的事，拖成 2 小时排错

正确顺序永远是：

先本地 UI
再单个 channel
最后多 channel 和路由

开始前准备：你需要先确认这几件事

在正式安装前，先确认下面几项。

电脑环境

macOS，或者 Windows 11
有管理员权限
网络能正常访问 OpenClaw 官方安装脚本与模型厂商 API

模型账号

OpenClaw 本身不是模型厂商，你还需要至少一套模型接入方式。官方 onboarding 支持多种 auth/provider 路线，例如：

Anthropic API Key
OpenAI API Key
OpenAI Codex 订阅 / OAuth
Anthropic Claude CLI / setup-token
Ollama
Cloudflare AI Gateway
Vercel AI Gateway
以及 Custom Provider

对零基础新手来说，第一次最简单的是：

你已经有稳定可用的 API Key
onboarding 时直接填进去
然后把默认模型设成你账号里当前最强、最新一代、且你确实有权限调用的那个

官方 onboarding 文档也明确提醒：如果这个 agent 会运行工具或处理外部输入，优先选择你当前可用栈里“最强的最新一代模型”，这样稳定性和抗 prompt injection 的能力会更好。

旧配置检查

如果你以前装过旧版 OpenClaw，或者这台机器已经有残留配置，先记住这一条：

不要盲删目录
先跑 openclaw doctor

官方 onboarding reference 写得很清楚：如果现有配置无效或含有 legacy keys，wizard 会直接停下来，要求你先修复，而不是带着脏配置继续往下跑。

Mac 安装：零基础最稳妥的完整步骤

第 1 步：执行官方安装脚本

在终端里运行：

1	curl -fsSL https://openclaw.ai/install.sh \| bash

这是官方当前推荐路径。安装脚本会处理这些事情：

检测操作系统
如果缺少合适的 Node，则自动安装
全局安装 OpenClaw CLI
拉起 onboarding

如果你只想先装 CLI，不立即进入 onboarding，也可以用：

1	curl -fsSL https://openclaw.ai/install.sh \| bash -s -- --no-onboard

但对新手来说，我不建议第一次就跳过 onboarding。

第 2 步：如果没有自动进入，就手动启动 onboarding

1	openclaw onboard --install-daemon

对于本地 Mac 新手，推荐你这样选：

选择 QuickStart
选择 Local gateway
选择你已经准备好的 provider/auth
默认 workspace 可以先直接用
Gateway 认证保留 Token
第一次先跳过 channel
允许安装 daemon

这里最关键的几个点要特别说清楚。

QuickStart 还是 Advanced？

第一次安装，选 QuickStart。

因为 QuickStart 的默认值已经很适合本地单机新手：

本地 loopback gateway
默认 workspace
端口 18789
默认生成 gateway token
默认不开 Tailscale 暴露

你后面完全可以再用：

1	openclaw configure

去改更细的参数。

Gateway 认证为什么不要关？

官方现在的推荐已经不是“本地电脑就裸开”，而是：

就算 loopback，也默认生成 token
本地 WS 客户端也要认证

这点很重要。因为一旦你把 auth 关了，本机上任何本地进程都可能连接这个 Gateway。

对零基础新手来说，最好的习惯是：

第一次就保留 token
以后远程接入时也沿用这套思路

第一次为什么先跳过 channel？

因为第一次你要验证的是：

OpenClaw 本体是不是装好了
Gateway 是不是起来了
模型认证是不是通了
Control UI 能不能对话

这些都跑通之后，再进 channel，排错会简单很多。

第 3 步：检查服务状态

安装完成后，先运行：

1 2	openclaw doctor openclaw gateway status

如果你是通过 onboarding 安装的 daemon，Mac 上的 service 目标是每用户的 LaunchAgent。官方 macOS 文档也写明了，app / CLI 走的是 launchd 这条路。

如果后面你要重启服务，常见命令是：

1 2	openclaw gateway install openclaw gateway status

第 4 步：打开浏览器 Control UI，完成第一次真实对话

现在不要急着配 Telegram。

先直接运行：

1	openclaw dashboard

然后浏览器里应当能打开：

1	http://127.0.0.1:18789/

如果界面要求认证：

用 onboarding 里生成的 gateway token
或者按 openclaw dashboard 给出的链接和提示操作

官方 Dashboard / Control UI 文档明确提醒：

Control UI 是管理员界面
它不只是聊天页，还能改配置、看日志、管理 exec approvals
不要直接暴露到公网

对新手来说，最稳的访问方式只有这几个：

localhost
Tailscale Serve
SSH tunnel

第一次本地安装，就老老实实用 localhost。

第 5 步：做第一次验收，不要只看页面能不能打开

页面能打开，不等于真的能用。

你至少做这 3 件事：

发一条普通问题
例如：请用三句话说明你现在是否正常工作。
发一条需要工具判断的请求
例如：请先读取当前工作区结构，只做概览，不要改文件。
看 Control UI 里有没有正常的事件流和工具卡片

如果这 3 步都正常，说明你已经不是“安装成功”，而是“能实际用了”。

Mac 用户可选路线：macOS App 什么时候值得用

如果你是 Mac 用户，官方还提供了 macOS companion app 路线。

它适合这类人：

你更喜欢图形引导
你后面要用到 macOS 节点能力
你想把权限申请、通知、菜单栏状态都交给 app 处理

官方 macOS app / onboarding 文档写得很清楚，它能处理这些能力：

菜单栏状态
通知
TCC 权限
Camera / Screen / Automation / Speech Recognition
本机 system.run

但如果你只是第一次本地安装，想尽快落地：

依然建议先把 CLI onboarding 跑通
后面再决定是否加上 macOS app

这样最不容易把“安装问题”和“权限问题”混在一起。

Windows 安装：最新稳妥路线是 WSL2，不是原生 Windows

第 1 步：在 PowerShell 里安装 WSL2 + Ubuntu

以管理员身份打开 PowerShell，执行：

1	wsl --install -d Ubuntu-24.04

如果系统要求重启，就先重启。

重启后打开 Ubuntu 终端，先完成 Linux 用户初始化。

第 2 步：启用 systemd

OpenClaw 在 WSL2 里要稳定跑 daemon，systemd 很关键。

在 Ubuntu 里执行：

sudo tee /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF

然后回到 PowerShell 执行：

1	wsl --shutdown

重新打开 Ubuntu，再验证：

1	systemctl --user status

如果这一关没过，就先别继续装 OpenClaw。

第 3 步：在 WSL2 里执行官方 Linux 安装脚本

这一步不要在 PowerShell 里装。

要在 Ubuntu 终端里执行：

1	curl -fsSL https://openclaw.ai/install.sh \| bash

或者：

1	openclaw onboard --install-daemon

Windows 官方文档虽然也写了原生 Windows 的进展，但截至 2026 年 3 月 27 日，官方仍然把 WSL2 作为推荐路径。

所以对零基础新手来说，最稳的理解方式就是：

Windows 只是宿主系统
OpenClaw 真正跑在 WSL2 里的 Linux 用户空间

第 4 步：按和 Mac 基本相同的 onboarding 逻辑走

WSL2 里 onboarding 的思路和 Mac 很接近：

QuickStart
Local gateway
先填 provider/auth
先跳过 channel
安装 daemon

唯一你需要额外记住的是：

Windows 路线里，官方文档依然把 daemon 的推荐实现放在 Linux/WSL2 user service 这一边
这也是为什么我们前面要先把 systemd 配好

第 5 步：如果你希望 Windows 重启后也尽量稳，做这两个增强

开启 linger

在 WSL 里执行：

1	sudo loginctl enable-linger "$(whoami)"

这是官方 Windows (WSL2) 文档里给出的建议，用来让 user service 在没有图形登录的情况下也尽量能维持。

安装 gateway service

1 2	openclaw gateway install openclaw gateway status

如果你只是个人电脑白天使用，不一定非要追求“Windows 开机前就拉起来”。

但如果你想让它更像后台常驻服务，这一步值得做。

第 6 步：仍然先用 Control UI 验收

不要因为你在 Windows 上，就跳过浏览器验收。

在 WSL 里执行：

1
2
3

openclaw doctor
openclaw gateway status
openclaw dashboard

只要本机浏览器能顺利打开 Control UI，并完成第一次聊天，这条安装链路就算真正闭环了。

第一次实际运用：为什么我强烈建议先用 Control UI

很多人把“实际运用”等同于“我一定要在 Telegram 上给它发消息”。

这其实是误区。

对新手来说，第一次真正落地的最佳入口其实是：

Control UI
或者 macOS / iOS 侧的 WebChat

因为官方文档已经明确说明：

最快的第一次聊天，不需要 channel setup
openclaw dashboard 就能直达浏览器聊天
WebChat / Control UI 走的是 Gateway WebSocket

为什么这一步最关键

因为它能帮你一次性验证下面 4 个核心环节：

Gateway 是活的
认证是通的
模型能回复
工具事件能回传

只要这 4 个都过了，后面就算 Telegram 配置错了，你也知道：

不是 OpenClaw 没装好
而是 channel 自己的问题

这就是为什么我一直强调：

先 Control UI，后 Select channel。

Select channel 实际运用：它到底在决定什么

你提到要“详细介绍 Select channel 实际运用”，这一节我就把它彻底讲清楚。

先说本质：它不是让模型随便挑平台

官方 Routing 文档讲得非常明确：

回复会回到消息进入的那个 channel
模型不会自己决定“这次该回 Telegram 还是 Discord”
路由是确定性的，由 host 配置控制

所以 Select channel 的真实含义不是：

“给模型一个花哨入口”

而是：

你要决定这次会话到底从哪个入口进入
以后 OpenClaw 的回复应该回到哪里
当你有多个 channel / 多个 account / 多个 agent 时，如何避免回错地方

对新手来说，最实用的 3 种 channel 选择

场景	最推荐的 channel	为什么
第一次安装验证	Control UI / WebChat	不需要先配 bot token，问题最少
你自己日常手机聊天	Telegram / WhatsApp DM	随时随地能问，最像私人助理
团队或群组协作	Discord / Slack channel	上下文更适合多人协作与长期沉淀

新手第一阶段该怎么选

我的建议非常明确：

第一天只用 Control UI
跑通后，只再加 1 个你最常用的个人 channel
不要在第一天同时上 Telegram、Discord、Slack

因为一旦你第一天就开多个 channel，你会同时面对：

不同 token
不同 target 格式
不同 pairing / allowlist 逻辑
多个 account 的默认路由问题

这对零基础用户完全没有必要。

Select channel 在实际运用里最重要的 4 条规则

规则 1：从哪里进，就回哪里

如果你是在：

Control UI 发起对话
那么回复就回 Control UI / WebChat
Telegram 发起对话
那么回复就回 Telegram
Discord 某个 channel 发起对话
那么回复就回那个 Discord channel

这也是为什么官方会把 routing 定义成 deterministic routing。

规则 2：群组 / 频道上下文是隔离的

官方 routing 文档还说明了：

DM 会进入主会话或按规则隔离
群组 / 频道则保持各自独立的 session key

这意味着：

你在 Telegram 私聊里的上下文
不会和 Discord 某个群组频道自动混在一起

对日常使用来说，这反而是好事，因为上下文不会乱。

规则 3：当你配置了多个 channel，出站命令要显式指定 channel

官方 openclaw message 文档说得很直接：

如果只配置了一个 channel，它可以作为默认
如果配置了多个 channel，那么 --channel 就必须明确指定

所以你真正进入多 channel 阶段后，推荐你养成这个习惯：

1	openclaw message send --channel telegram --target @your_username --message "OpenClaw 已上线"

不要偷懒省掉 --channel。

规则 4：同一个 channel 下如果有多个账号，要设默认账号

官方 channel routing 文档提到一个非常容易忽略的点：

如果同一个 channel 配了多个 account
最好显式设置 channels.<channel>.defaultAccount
否则 fallback 可能挑到第一个规范化账号

这就是很多人后期“明明配了两个 bot，怎么总是从错误账号发出去”的根源。

如果你到了这一步，建议在配置里把默认 account 写明。

思路示意：

{
  "channels": {
    "telegram": {
      "defaultAccount": "personal-bot"
    }
  }
}

这类配置属于“多账号长期使用”阶段，不是第一天必须做，但你必须知道它的存在。

Select channel 的最实用落地方式：按这个顺序来

场景 A：本地浏览器先跑通

先执行：

1	openclaw dashboard

浏览器打开 Control UI 后，先完成第一次聊天。

这是你的“零号 channel”。

你可以把它理解成：

本地调试 channel
最安全的初始入口
所有后续扩展前的基线

场景 B：加一个个人聊天 channel

例如你想以后用 Telegram 跟它聊天。

先加 channel：

1 2	openclaw channels add --channel telegram --token <your-bot-token> openclaw channels status

然后做一条主动消息测试：

1	openclaw message send --channel telegram --target @your_username --message "Hello from OpenClaw"

这里有一个很容易写错、也很容易踩坑的细节，我单独说清楚：

如果你是通过 QuickStart onboarding 去接 Telegram / WhatsApp，wizard 往往会帮你写出更偏“个人自用”的基线，例如 allowlist / 自己账号优先的配置
如果你是像上面这样手工执行 openclaw channels add，那就要按 channel 的通用安全默认值来理解，首次 DM 更可能走 pairing 审批链

也就是说，如果你在 wizard 里看到它直接开始问“你自己的账号是谁”“你的号码或用户名是什么”，不要惊讶，这正是 QuickStart 想帮你减少 day 0 风险的设计。

所以如果你明明 channel 配好了，却发现第一次 DM 没按预期继续，优先检查这两件事：

是不是还在等 pairing approve
或者你的 allowlist / 自己账号规则根本没有匹配上

场景 C：以后你再扩展 Discord / Slack

到了第二阶段，你可以再加：

Discord
Slack
或其他 plugin channel

这时就别再用“模糊描述”了，而是明确写目标。

例如 Discord：

1	openclaw message send --channel discord --target channel:1234567890 --message "今天的部署已完成"

如果你需要先确认一个 channel 有没有足够能力，也可以用官方 CLI 做 capability probe：

1	openclaw channels capabilities --channel discord --target channel:1234567890

这在真正落地时非常实用，因为你可以先确认：

权限有没有开够
目标是不是有效
某个动作到底支不支持

场景 D：你在 Control UI 里聊天时，到底算不算一个 channel？

算，但要分清楚它的性质。

官方当前 routing 文档把 webchat 定义为内部 WebChat / Control UI 通道，它参与会话和路由，但不是你平时通过 openclaw message send --channel ... 手工选择的那类外部聊天渠道。

这对新手非常重要，因为很多人会误以为：

既然我在浏览器里能聊天
那我是不是也可以写 --channel webchat

这通常不是你该走的路。

对新手最稳的理解方式是：

Control UI 是本地管理和验证入口
Telegram / Discord / Slack 才是你后续要显式选择的外部 channel
所以“先用浏览器跑通”不等于“以后出站命令默认都走 webchat”

也就是说，Select channel 的第一层实际运用，不是选一个最炫的平台，而是先把“本地验证入口”和“外部生产入口”区分开。

场景 E：Telegram 私聊自己，做个人助理

这是零基础用户最常见、也最实用的落地方式。

适用情况：

你想把 OpenClaw 当成手机里的私人助理
你希望随时随地发一句话，让它回你
你不需要群组协作，只需要个人对话

推荐做法：

先在 Control UI 跑通第一次真实对话
再只新增一个 Telegram bot / account
先做一次主动发送测试
再从 Telegram 反向给它发一条消息

命令可以这样做：

1
2
3

openclaw channels add --channel telegram --token <your-bot-token>
openclaw channels status
openclaw message send --channel telegram --target @your_username --message "Hello from OpenClaw"

这里 @your_username 更适合个人自测；如果你手里已经拿到明确的聊天 ID，也可以直接用 chat id。

这一类场景下，Select channel 的含义是：

把“个人助理”这条工作流固定到 Telegram
以后从 Telegram 发起的问题，都回 Telegram
你在浏览器里调试的上下文，不会自动和 Telegram 私聊上下文混成一锅

实际运用建议：

适合每日随手提问、待办提醒、轻量记录
不适合一上来就承担团队共享知识库
第一天先别再加 Discord 或 Slack

场景 F：Telegram 超级群 / 论坛主题里，只想把上下文锁在某个 topic

这是很多人后面会碰到、但新手教程经常不写清楚的一种情况。

如果你把 OpenClaw 放进 Telegram 超级群，群里又启用了 forum topics，那么“同一个群里的不同 topic”不是同一个上下文。

官方 routing 文档当前明确写到：

Telegram forum topic 会把 topicId 写进 session key
也就是说，同一个群里的不同 topic，上下文是隔离的

这意味着你在实际运用里可以这样理解：

VPS 排错 topic 只保存运维上下文
内容选题 topic 只保存内容策划上下文
两个 topic 不会自动串台

如果你需要主动向某个 topic 发消息，当前 CLI 支持 Telegram 的 --thread-id：

openclaw message send \
  --channel telegram \
  --target -1001234567890 \
  --thread-id 42 \
  --message "今天开始整理 VPS 线路测试结果"

这个案例里，Select channel 不只是选 Telegram，而是进一步选到：

Telegram
哪个群
群里的哪个 topic

这才是真正的“把工作流落到具体位置”。

场景 G：Discord 里发到频道，和发到线程，是两件不同的事

如果你后面把 OpenClaw 用在团队协作里，Discord 是很典型的例子。

在 Discord 里，下面三种目标要分开理解：

发到公共频道
回复某条消息
在某个线程里继续讨论

发到频道：

1	openclaw message send --channel discord --target channel:1234567890 --message "今天的部署已完成"

回复频道里的某条消息：

openclaw message send \
  --channel discord \
  --target channel:1234567890 \
  --message "这个问题我已经复现" \
  --reply-to 456789

在线程里继续回复：

openclaw message thread reply \
  --channel discord \
  --target 9876543210 \
  --message "我把排错结论补到线程里了"

这三个动作看起来都像“发一条消息”，但实际运用完全不同：

发到频道：适合公告、广播、正式同步
回复消息：适合针对某一条问题继续跟进
线程回复：适合把长讨论收在局部上下文里，不污染主频道

所以你在 Discord 场景里选 channel，其实是在选“发到频道主流”还是“继续某个线程上下文”。

场景 H：Slack 里最容易选错的不是 channel，而是 thread

Slack 常见的坑不是“发不到”，而是“发对了频道，却没进对线程”。

官方 openclaw message 文档当前明确列了：

Slack 支持 --thread-id
--reply-to 也会使用同一个线程字段

如果你只是想往频道发一条消息：

1	openclaw message send --channel slack --target channel:C12345678 --message "日报已经更新"

如果你是要接在某条线程里继续回复：

openclaw message send \
  --channel slack \
  --target channel:C12345678 \
  --thread-id 1743084000.123456 \
  --message "我把日志定位结果补在这个线程里"

对团队使用来说，这个差别很大：

发到频道会打扰所有人
发到线程更适合持续排错、设计讨论和 PR 跟进

所以当你说“Select channel”，在 Slack 里通常还要连带确认：

是哪个 workspace/team
是哪个频道
是不是某个线程

场景 I：多个 channel 都配好了以后，先 resolve，再 capabilities，再 send

很多人进入第二阶段后，会直接上来就发消息。其实更稳的顺序是：

openclaw channels status
openclaw channels resolve --channel slack "#general" "@jane"
openclaw channels capabilities --channel slack --target channel:C12345678
openclaw message send --channel slack --target channel:C12345678 --message "测试消息"

为什么这个顺序更稳？

status：先看 Gateway 看到没有这个 channel，账号状态是否正常
resolve：把名字解析成真正的 ID，避免你凭肉眼猜错
capabilities：先确认这个目标到底支持哪些动作
send：最后再真正发消息

这套顺序特别适合：

Discord 频道很多
Slack 里频道名和显示名混杂
团队里一个人同时维护多个群组 / workspace

对新手来说，最容易踩的坑不是“不会配”，而是“以为名字对了，其实 target 格式写错了”。

场景 J：一个 channel 下配了多个账号时，`Select channel` 还不够，得再选 account

这一步通常不是第一天会遇到，但一旦做团队项目，很快就会出现。

例如同样都是 Telegram，你可能同时有：

一个私人 bot
一个团队 bot

这时候只写：

1	openclaw message send --channel telegram --target @your_username --message "hello"

就可能不够清楚，因为它还要决定“到底用哪个 account 发出去”。

官方 channels 文档当前写得很明确：

同一个 channel 增加非默认账号时，会迁移到多账号配置形态
非交互式 channels add 不会自动替你改绑定
交互式流程可以选择现在就把配置好的 channel 账号绑定到 agent

所以进入多账号阶段后，推荐你这样理解 Select channel：

第一层：选 Telegram / Discord / Slack 哪个平台
第二层：选这个平台里的哪个 account
第三层：必要时再选具体 target 或 thread

也就是说，多账号以后你不只是“选平台”，而是在选“平台上的哪个身份”。

一个真正能照着执行的 Select channel 排错顺序

如果你已经把 channel 配好了，但还是觉得“我不知道现在到底该选什么”，请按下面这个顺序查，不要乱猜。

先确认这是本地验证，还是外部生产入口
本地验证就先回 Control UI，不要立刻怀疑 Telegram / Discord 配置。
再确认这次到底是 DM、群组、频道，还是线程 / topic
同平台下，不同上下文的路由和 session key 可能完全不同。
多 channel 时显式写 --channel
不要依赖默认值。
多账号时显式确认默认账号或绑定关系
否则你可能是“发出去了，但不是从你想要的那个身份发出去”。
先 resolve 和 capabilities，再真正 send
这样能减少 80% 以上“其实只是 target 写错了”的低级坑。

从安装到实际运用，最推荐的新手闭环

如果你想要一个真正可执行、而不是只停留在“看懂文档”的落地顺序，就按这个做。

第 1 天

安装 OpenClaw
跑 openclaw onboard --install-daemon
跑 openclaw doctor
跑 openclaw gateway status
跑 openclaw dashboard
在 Control UI 完成第一次聊天

第 2 天

只新增 1 个你最常用的 personal channel
用 openclaw channels status 检查状态
用 openclaw message send 做第一条主动消息测试
从手机或目标平台再反向发一条消息回来
完成 pairing / allowlist

第 3 天以后

再考虑第二个 channel
再考虑多账号 defaultAccount
再考虑多 agent bindings

这才是新手最不容易翻车的节奏。

这些坑一定要提前避开，不然后面会反复出问题

1. 用旧 Node 版本凑合跑

不建议。

官方文档至少把较新的 Node LTS 视为推荐方向。为了避免踩兼容边界，这篇文章统一按 Node 24 作为保守推荐基线。

2. Windows 第一次就强行走原生 Windows

官方虽然在持续改善 native Windows CLI，但推荐路线仍然是 WSL2。

如果你是零基础新手，第一遍别逆着官方推荐走。

3. Control UI 还没跑通，就急着上 Telegram / Discord

这是最常见的错误顺序。