快速上手

🦞 十分钟内跑起来——先把它装好、跑通，再谈更复杂的频道、工具和自动化。

flowchart LR
  A["快速上手"]
  A --> B["分类：OpenClaw"]
  A --> C["关键词：OpenClaw"]
  A --> D["关键词：安装"]
  A --> E["关键词：Onboarding"]
  A --> F["关键词：Gateway"]

上一篇我们讲清了 OpenClaw 是什么。这一篇不再停留在定位层面，而是直接解决一个更实际的问题：怎么把它可靠地跑起来，并发出第一条可验证的消息。

这里刻意强调“可靠地”而不是“最快地”，因为 OpenClaw 不是一个只打开网页就能用的 SaaS 产品，而是一套长期运行的助手系统。你第一次安装时，真正要建立的不是某个临时会话，而是三样东西：

一个可持续运行的 Gateway
一个明确的工作区与配置目录
一个你之后还能继续扩展的本地运行环境

只要这三样东西起对了，后面再接频道、加 skills、接浏览器和自动化，路径都会顺很多。反过来，如果第一步只是“勉强装上”，后面往往会在权限、路径、版本、服务管理这些基础问题上反复返工。

先说结论：推荐路径是什么

如果你是第一次安装 OpenClaw，最推荐的路径不是手工拼命令，而是：

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

安装脚本会帮你处理 Node 检测、CLI 安装和新手引导；在 Windows 上，官方也提供了 PowerShell 安装脚本。官方安装文档同时明确写到：当前推荐 Node 24，兼容 Node 22.16+；如果系统里没有合适版本，安装脚本会补装 Node 24。(OpenClaw)

如果你已经自己管理 Node 环境，也可以直接走包管理器安装，再执行新手引导：

npm install -g openclaw@latest
openclaw onboard --install-daemon

pnpm 也支持，但它对带构建脚本的包更严格，首次安装后通常还要执行一次 pnpm approve-builds -g。(OpenClaw)

这一点看似只是“安装方式选择”，其实背后有一个工程上的判断：能否接受安装脚本帮你处理环境差异。如果你只是想尽快跑通，安装脚本更稳；如果你已经有成熟的 Node 管理习惯，希望自己掌控版本和全局路径，手工安装更合适。

前置条件：不要只看“能运行”，还要看“后面会不会踩坑”

官方快速开始页面写的是 Node 22 或更新版本；安装页则进一步收紧为：Node 24 推荐，Node 22 LTS 目前要求 22.16+。这两个表述并不冲突：前者是快速开始层面的最低门槛，后者是更准确的当前兼容边界。(OpenClaw)

所以实际操作里，更稳妥的建议是：

新装机器：优先上 Node 24
已有 Node 22 环境：确认至少是 22.16+
Windows：优先使用 WSL2，而不是原生环境硬顶

先检查版本：

node -v

如果你看到的是较老的 22.x，并不一定马上报错，但后续在依赖安装、原生模块构建、运行时兼容性上更容易遇到边角问题。尤其当你后面接入本地工具、浏览器控制或某些原生依赖时，“能装上”和“能长期稳定用”不是一回事。

安装 OpenClaw：为什么官方更推荐安装脚本

方式一：安装脚本（推荐）

macOS / Linux / WSL2：

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

Windows PowerShell：

iwr -useb https://openclaw.ai/install.ps1 | iex

如果你只想安装 CLI，不想立刻进入向导，也可以跳过 onboarding。官方文档给出了对应参数。(OpenClaw)

这一方式的优点，不只是“少打一条命令”，而是它帮你把几件最容易出错的事合并处理了：

检查 Node 版本是否满足要求
安装或更新 CLI
进入推荐的新手引导路径
减少 PATH、全局包目录、版本不匹配造成的错误

对第一次使用的人来说，这种“一步进入正确路径”的价值很大。因为 OpenClaw 后面的复杂度已经够高了，没必要把精力先耗在全局包管理和环境变量上。

方式二：手工安装 CLI

如果你明确知道自己在做什么，可以直接用 npm：

npm install -g openclaw@latest
openclaw onboard --install-daemon

也可以用 pnpm：

pnpm add -g openclaw@latest
pnpm approve-builds -g
openclaw onboard --install-daemon

OpenClaw 官方快速开始页把 npm 和 pnpm 都列为支持路径，但安装文档也特别提醒：pnpm 默认会拦截带构建脚本的包，因此第一次装完如果看到 “Ignored build scripts” 一类提示，不要以为已经完整安装成功。(OpenClaw)

安装阶段一个常见误区

很多人把“openclaw --version 能输出版本号”当作安装成功的标志。这只能说明 CLI 命令已经在 PATH 里，不代表：

Gateway 可以正常运行
配置目录已初始化
服务管理已安装
工作区已创建
本地 provider 或后续渠道一定能用

对 OpenClaw 这种系统来说，安装成功只是第一层，onboarding 成功才是真正起点。

Onboarding：为什么它不是“可选向导”，而是推荐主路径

官方文档写得非常明确：CLI onboarding 是在 macOS、Linux、Windows（强烈建议 WSL2）上配置 OpenClaw 的推荐方式。它会在一个引导流程里处理：

本地 Gateway 或远程 Gateway 连接
channels
skills
workspace 默认值
某些 web search provider 配置项(OpenClaw)

最常见的命令是：

openclaw onboard --install-daemon

如果你只是想先体验一下，也可以先直接运行：

openclaw onboard

但对第一次安装而言，我更建议写进文章里的默认路径仍然是 --install-daemon，因为它会顺手把“长期运行”这件事一起建立起来。官方 CLI 文档也说明了：使用 --install-daemon 时，会先走受管 Gateway 安装路径；不使用它时，你需要自己确保已经有一个本地 Gateway 在运行，例如 openclaw gateway run。(OpenClaw)

这背后的区别很重要：

不用 --install-daemon：更适合临时测试、脚本化配置、你已经清楚服务怎么起
用 --install-daemon：更适合第一次安装，能直接把 OpenClaw 放进“长期可用”的状态

OpenClaw 不是那种“命令执行一次就结束”的 CLI 工具。它的核心是常驻 Gateway，所以把服务安装路径纳入 onboarding，本身就是一种正确使用方式。

QuickStart 和 Advanced：该选哪一个

Onboarding 会先让你在 QuickStart 和 Advanced 之间做选择。官方文档给出的默认 QuickStart 行为大致包括：

本地 loopback Gateway
默认工作区
Gateway 端口 18789
默认启用 token 鉴权并自动生成令牌
某些本地 setup 的默认工具策略与 DM scope 写入配置
Tailscale 暴露默认关闭(OpenClaw)

对于绝大多数第一次安装的人，QuickStart 是更合适的默认选择。原因不是它“更简单”这么表面，而是：

它把容易配错的网络和认证参数收敛到了安全默认值
它更符合“先本机跑通，再逐步暴露远程访问”的顺序
它减少了第一次安装时对 Gateway、认证模式、绑定地址的认知负担

Advanced 更适合这些情况：

你要连远程 Gateway
你明确知道要改端口、绑定地址、认证方式
你在多实例、多 profile 或自动化部署环境中安装
你已经理解 OpenClaw 的控制面暴露风险

一个成熟的快速上手，不应该鼓励所有人一上来就“高级配置拉满”。 第一次安装最重要的是建立一个正确的、可收敛的基线。

启动 Gateway：理解它在整个系统里的角色

完成 onboarding 后，Gateway 通常会作为用户服务持续运行。如果你想手动启动，也可以直接执行：

openclaw gateway --port 18789

官方快速开始页明确把这条命令列为手动启动方式，并说明：完成新手引导后，Gateway 会通过用户服务运行；如果你后来在 npm 安装和 git 安装之间切换，可以跑一次 openclaw doctor 来更新 Gateway 服务入口点。(OpenClaw)

这里有两个很容易被忽略的点。

第一，Gateway 是运行核心，不是附属命令

你后面无论做哪件事：

收消息
发消息
跑 agent
接频道
打开 dashboard
跑 webhook 或自动化

本质上都在依赖 Gateway 这层控制面。所以当第一条消息发不出去时，优先怀疑 Gateway 状态，往往比优先怀疑模型更有效。

第二，手动启动和受管服务不是同一回事

你可以在当前终端里跑一个 openclaw gateway --port 18789，这当然能工作。但它和“由用户服务管理、可持续重启、脱离当前 shell 生命周期”的受管模式，稳定性不是一个级别。

对于文章读者来说，这里的正确心智模型应该是：

openclaw gateway 更像调试入口；--install-daemon 建立的受管服务，才更接近长期使用形态。

第一条消息：先追求“闭环成立”，不要一上来追求复杂场景

官方快速开始页提供的测试消息命令是：

openclaw message send --target +15555550123 --message "Hello from OpenClaw"

注意这里的参数是 --target，而不是一些旧教程里常见的 --to。OpenClaw 当前的 message CLI 文档也明确说明：目标参数统一使用 --target；如果配置了多个渠道，则需要显式指定 --channel。(OpenClaw)

因此，更稳妥的写法应该是：

openclaw message send --channel whatsapp --target +1234567890 --message "Hello"

或者如果你只配置了一个渠道，也可以省略 --channel：

openclaw message send --target +1234567890 --message "Hello"

这里的 --target 不是统一的人类可读用户名，而是与渠道相关的目标标识。不同渠道格式不同，例如：

WhatsApp：E.164 电话号码或群组 JID
Telegram：chat ID 或 @username
Slack / Discord：channel:<id> 或 user:<id> 一类格式(OpenClaw)

这也是为什么，快速上手阶段最好的目标不是“覆盖所有渠道”，而是：

先接通一个你最熟悉的渠道
用它成功发出一条可见消息
确认消息路径、账号、目标格式都理解正确

这三步一旦跑通，后面再扩展到第二个、第三个渠道会轻松很多。

如果还不想接真实频道，先用 Dashboard 更合理

官方 onboarding 文档提到一个很实用的点：最快开始第一次聊天的方法，是直接打开 Control UI，也就是运行 openclaw dashboard，无需先设置频道。(OpenClaw)

这条路径非常适合这两类人：

你只想先确认本地安装、Gateway、agent 基础链路是否正常
你还不想马上登录 WhatsApp、Telegram、Slack 等真实账号

命令很简单：

openclaw dashboard

为什么这一步很值得补进正文，而不只是作为一句提示？

因为很多“第一天就卡住”的问题，其实不是 OpenClaw 本身坏了，而是：

渠道登录态有问题
目标格式写错
第三方平台限流或验证流程打断
用户把“模型是否可用”和“消息渠道是否可用”混在一起排查

先用 dashboard 把本地控制链路跑通，能把问题空间迅速缩小。这是一个很典型的工程化快速验证思路。

`openclaw agent`：它不是简单聊天，而是一次显式的 agent 回合

如果你想测试的不是“消息能不能发出去”，而是“agent 能不能跑通”，可以使用：

openclaw agent --message "Ship checklist"

官方工具文档说明，openclaw agent 会运行单个 agent 回合；默认通过 Gateway 运行，如果 Gateway 不可达，CLI 会回退到嵌入式本地运行；也可以显式加 --local 强制本地运行。(OpenClaw)

更完整一点的例子：

openclaw agent --message "Summarize today's notes" --thinking medium

关于 --thinking，当前文档给出的可选值包括：

off
minimal
low
medium
high
xhigh

但文档也同时提示，这类 thinking 级别是和特定模型能力绑定的，并非所有模型都支持同等语义。(OpenClaw)

这里要特别避免一个常见误区： 不要把 openclaw agent 当成“任何情况下都等价于真实入站消息”。

它很适合作为：

本地功能验证
agent 提示词和 workspace 行为测试
在不依赖真实消息渠道时调试模型与工具

但它和“从 WhatsApp/Slack 入站、经过真实渠道路由、再回到对应会话”的路径，仍然不是完全同一个场景。

从工程上看，agent 更像“运行时验证工具”，message send 更像“消息链路验证工具”。两者都重要，但验证目标不同。

从源码构建：什么时候才需要这样做

如果你只是使用 OpenClaw，不需要一上来就从源码构建。官方快速开始页把源码安装明确放在开发路径下，步骤大致是：

git clone https://github.com/openclaw/openclaw.git
cd openclaw
pnpm install
pnpm ui:build
pnpm build
openclaw onboard --install-daemon

如果没有全局安装，也可以在仓库目录里用 pnpm openclaw ... 运行相关命令。(OpenClaw)

从源码构建更适合：

你要读源码
你要改 CLI / Gateway / UI
你要提 PR 或跟踪主分支
你要验证尚未发布到包管理器的修复

不太适合作为普通用户的默认安装路径。因为它引入了额外复杂度：

你要管理 repo 版本状态
你要处理构建依赖
你要理解发布版和当前 main 的差异
后续更新不再只是简单 npm install -g

在“快速上手”这篇里，源码构建应该保留，但不该给人一种它是默认路线的错觉。

工作区：别把它当普通配置目录

官方工作区文档对 workspace 的定义非常清楚：它是 agent 的“家”，是文件工具和工作区上下文使用的唯一工作目录；默认路径是 ~/.openclaw/workspace，而配置、凭证和会话则主要存放在 ~/.openclaw/ 下。(OpenClaw)

这意味着你在第一次安装时，至少要分清两个概念：

1. `~/.openclaw/` 是系统状态目录

这里放的是更偏运行时和系统级的内容，例如：

openclaw.json
credentials
sessions
托管 skills 等(OpenClaw)

2. `~/.openclaw/workspace/` 是 agent 的工作区

这里更像 agent 的长期上下文与可编辑家目录。官方文档列出的标准工作区文件包括：

AGENTS.md
SOUL.md
USER.md
IDENTITY.md
TOOLS.md
HEARTBEAT.md
BOOT.md
BOOTSTRAP.md
memory/
skills/
canvas/ 等(OpenClaw)

这一点和很多旧教程只写 AGENTS.md / SOUL.md / TOOLS.md 不太一样。更准确的写法应该是：这三个文件确实很重要，但它们不是全部工作区结构。

同时，官方文档还特别提醒了一点：workspace 是默认 cwd，不是硬性沙箱。如果没有启用 sandbox 隔离，工具虽然默认相对工作区解析路径，但绝对路径仍可能访问主机其他位置。(OpenClaw)

这句话很值得放进正文，因为它直接影响读者对“本地工作区安全边界”的理解。很多人会天然以为“工作区 = 沙箱”，实际上不是。

一个更准确的最小配置认知

很多快速上手文章喜欢给出一个“最小配置 JSON”，这当然能帮助读者建立结构感。但对 OpenClaw 来说，更重要的是理解哪些配置是 onboarding 会帮你写入的，哪些不是你第一天就该手改的。

你可以把 ~/.openclaw/openclaw.json 理解为系统主配置入口，但第一次安装时更推荐：

先用 onboarding 生成默认配置
跑通本地闭环
再去修改 provider、gateway auth、workspace、tools profile、channel 细节

这是因为 OpenClaw 的配置不是一个“只写两个字段就万事大吉”的静态文件。它和：

onboarding 生成逻辑
服务安装路径
凭证引用方式
后续 configure 命令
doctor --repair 修复逻辑

都是耦合在一起的。贸然手写最小配置，反而容易让新手误以为“只要 JSON 格式合法就足够”。

`openclaw doctor`：不要等出大问题才用它

OpenClaw 官方把 doctor 定义为：Gateway 和 channels 的健康检查加快速修复工具。它支持：

openclaw doctor
openclaw doctor --repair
openclaw doctor --deep

文档还提到，--repair（--fix 的别名）会先备份 ~/.openclaw/openclaw.json.bak，然后删除未知配置键并列出清理项。(OpenClaw)

这告诉我们一件事： doctor 不是“最后没办法时的玄学命令”，而是官方认可的维护入口。

我会建议把它放进快速上手的主线里，而不是只放在“故障排查”小节，因为第一次安装成功后，马上跑一次：

openclaw doctor

能帮你确认至少这些层面：

CLI 与 Gateway 的连接是否正常
当前配置是否处于可识别状态
某些常见环境问题是否已被检测到
在安装方式切换后，Gateway 服务入口点是否需要更新(OpenClaw)

对新手来说，这其实比盲看日志更有效。日志适合定位已知问题，doctor 更适合快速判断“系统整体有没有明显偏离正确状态”。

常见首次运行问题：不要只给结论，要知道它为什么会发生

1. `openclaw: command not found`

最常见原因不是“OpenClaw 坏了”，而是：

全局安装没成功
包管理器全局 bin 目录没进 PATH
你安装在一个 Node 版本管理器的隔离环境里，但当前 shell 没加载对应环境

这类问题的本质是 CLI 没被正确暴露到当前终端，不是 OpenClaw 运行时问题。

排查思路

npm bin -g
which openclaw
openclaw --version

如果安装脚本能成功而手工安装不行，通常说明是你自己的 Node / PATH 管理方式有问题。

2. Gateway 连不上

常见原因包括：

你以为 onboarding 已经装好服务，但其实服务没成功注册
当前没有活着的 Gateway 进程
端口冲突
你切换了安装方式后，服务入口点还是旧路径
鉴权 token / password 配置不一致

官方 CLI 文档还特别提醒：如果你曾经用 launchctl setenv OPENCLAW_GATEWAY_TOKEN ... 或类似方式设置过环境变量，它们可能覆盖配置文件，导致持续的未授权错误。(OpenClaw)

这类问题说明一个很典型的工程事实： 控制面错误经常不是“服务没启动”，而是“启动了，但你和它说话的方式不一致”。

3. 发消息失败

这类问题通常不是一个单一故障，而是三层里的某一层出了问题：

渠道层：没有登录、登录过期、账号不对
目标层：--target 格式不对、频道 ID 写错、发到了不支持的对象
控制层：Gateway 没接上该渠道，或你指定了错误的 --channel

快速开始阶段最有效的办法不是“多试几次”，而是把问题拆开：

先确认 channels login 是否成功
再确认该渠道的 target 格式
最后再看消息发送命令本身

4. `agent` 有输出问题，或行为不符合预期

这不一定是模型坏了。常见原因包括：

provider 凭证没配好
当前模型不支持你指定的 thinking 级别
Gateway 不可达时回退到本地运行，导致行为和你预期不一致
workspace 引导文件过旧或内容冲突
你把“测试消息发送”和“测试 agent 推理”混成一个问题

更稳妥的做法是分别验证：

openclaw doctor
openclaw dashboard
openclaw agent --message "test"

把消息链路、控制链路、agent 运行链路拆开看。

5. 工作区或权限问题

这类问题很容易被低估。因为 OpenClaw 会写：

配置
凭证
会话
工作区引导文件
某些服务元数据

如果你把 ~/.openclaw/ 放在一个权限奇怪、同步延迟高、或有额外安全软件干预的目录上，问题会很隐蔽。它未必立刻报错，但会表现为：

配置似乎写入了又没生效
登录态无法持久化
服务重启后行为不一致
某些自动生成文件缺失

所以“能创建目录”并不等于“适合做 OpenClaw 的状态目录”。

多实例与环境变量：什么时候该关心

官方快速开始页给出了多实例快速开始示例，使用：

OPENCLAW_CONFIG_PATH
OPENCLAW_STATE_DIR

来切换配置与状态目录。(OpenClaw)

示例大致像这样：

OPENCLAW_CONFIG_PATH=~/.openclaw/a.json \
OPENCLAW_STATE_DIR=~/.openclaw-a \
openclaw gateway --port 19001

这一能力很有用，但不应该在第一次安装时过早展开。它更适合这些情况：

你要同时跑多个 profile / 实例
你想把测试环境和生产环境分开
你在脚本化部署或 CI 场景里运行
你需要隔离不同 Gateway 的状态目录

对第一次上手的人来说，最重要的是知道：OpenClaw 是支持多实例的，但你没必要第一天就把自己带进多实例复杂度里。

一个更成熟的“十分钟跑起来”心智模型

“十分钟跑起来”这句话没问题，但更成熟的写法不该让读者误以为这意味着：

十分钟内一定能接好任何渠道
十分钟内一定能完成所有 provider 配置
十分钟内就进入稳定生产状态

更准确的说法应该是：

十分钟足够建立一个可验证的本地闭环：安装 CLI、完成 onboarding、启动或确认 Gateway、打开 dashboard 或跑一次 agent / message 测试。

从工程上看，这一篇真正的目标不是“把 OpenClaw 的所有能力都摸一遍”，而是：

建立正确安装路径
建立正确的 Gateway 心智模型
建立工作区与配置目录的基本认识
跑通第一条验证链路
学会用 doctor 做基础排查

这才叫“快速上手”，而不是“快速堆命令”。

建议你现在就做的三件事

完成本文后，最值得马上做的不是继续看配置表，而是：

1. 跑一次 dashboard

openclaw dashboard

确认本地控制链路工作正常。

2. 跑一次 `doctor`

openclaw doctor

确认系统没有明显配置漂移和服务入口问题。

3. 用一种方式完成“第一条验证”

二选一即可：

openclaw agent --message "Summarize my setup"

或：

openclaw message send --target <your-target> --message "Hello from OpenClaw"

只要这一步成功，说明你已经从“装了一个 CLI”跨过了最关键的一步： 你已经有了一个真正能工作的 OpenClaw 基线。

小结

OpenClaw 的快速上手，真正难的从来不是“打一条安装命令”，而是建立一个正确的起点：让 Gateway 以合适方式运行，让 workspace 和状态目录清晰分工，让第一条验证链路尽可能短、尽可能确定。

因此，这一篇最重要的结论不是某个具体命令，而是这条顺序：

先用推荐路径安装
再用 onboarding 建立受管 Gateway
先验证本地控制面，再验证真实消息链路
用 doctor 做基础健康检查
把工作区当长期上下文，而不是临时缓存目录

有了这个基线，后面无论你是接 WhatsApp、配置 provider、定制 agent，还是引入 browser、Cron、Webhook、skills，都会顺很多。

快速上手

快速上手

先说结论：推荐路径是什么

前置条件：不要只看“能运行”，还要看“后面会不会踩坑”

安装 OpenClaw：为什么官方更推荐安装脚本

方式一：安装脚本（推荐）

方式二：手工安装 CLI

安装阶段一个常见误区

Onboarding：为什么它不是“可选向导”，而是推荐主路径

QuickStart 和 Advanced：该选哪一个

启动 Gateway：理解它在整个系统里的角色

第一，Gateway 是运行核心，不是附属命令

第二，手动启动和受管服务不是同一回事

第一条消息：先追求“闭环成立”，不要一上来追求复杂场景

如果还不想接真实频道，先用 Dashboard 更合理

`openclaw agent`：它不是简单聊天，而是一次显式的 agent 回合

推荐的最小跑通路径

路径 A：最稳的本地闭环

路径 B：最快的真实消息闭环

路径 C：CLI 层验证 agent 运行

从源码构建：什么时候才需要这样做

工作区：别把它当普通配置目录

1. `~/.openclaw/` 是系统状态目录

2. `~/.openclaw/workspace/` 是 agent 的工作区

一个更准确的最小配置认知

`openclaw doctor`：不要等出大问题才用它

常见首次运行问题：不要只给结论，要知道它为什么会发生

1. `openclaw: command not found`

排查思路

2. Gateway 连不上

3. 发消息失败

4. `agent` 有输出问题，或行为不符合预期

5. 工作区或权限问题

多实例与环境变量：什么时候该关心

一个更成熟的“十分钟跑起来”心智模型

建议你现在就做的三件事

1. 跑一次 dashboard

2. 跑一次 `doctor`

3. 用一种方式完成“第一条验证”

小结

快速上手

先说结论：推荐路径是什么

前置条件：不要只看“能运行”，还要看“后面会不会踩坑”

安装 OpenClaw：为什么官方更推荐安装脚本

方式一：安装脚本（推荐）

方式二：手工安装 CLI

安装阶段一个常见误区

Onboarding：为什么它不是“可选向导”，而是推荐主路径

QuickStart 和 Advanced：该选哪一个

启动 Gateway：理解它在整个系统里的角色

第一，Gateway 是运行核心，不是附属命令

第二，手动启动和受管服务不是同一回事

第一条消息：先追求“闭环成立”，不要一上来追求复杂场景

如果还不想接真实频道，先用 Dashboard 更合理

openclaw agent：它不是简单聊天，而是一次显式的 agent 回合

推荐的最小跑通路径

路径 A：最稳的本地闭环

路径 B：最快的真实消息闭环

路径 C：CLI 层验证 agent 运行

从源码构建：什么时候才需要这样做

工作区：别把它当普通配置目录

1. ~/.openclaw/ 是系统状态目录

2. ~/.openclaw/workspace/ 是 agent 的工作区

一个更准确的最小配置认知

openclaw doctor：不要等出大问题才用它

常见首次运行问题：不要只给结论，要知道它为什么会发生

1. openclaw: command not found

排查思路

2. Gateway 连不上

3. 发消息失败

4. agent 有输出问题，或行为不符合预期

5. 工作区或权限问题

多实例与环境变量：什么时候该关心

一个更成熟的“十分钟跑起来”心智模型

建议你现在就做的三件事

1. 跑一次 dashboard

2. 跑一次 doctor

3. 用一种方式完成“第一条验证”

小结

`openclaw agent`：它不是简单聊天，而是一次显式的 agent 回合

1. `~/.openclaw/` 是系统状态目录

2. `~/.openclaw/workspace/` 是 agent 的工作区

`openclaw doctor`：不要等出大问题才用它

1. `openclaw: command not found`

4. `agent` 有输出问题，或行为不符合预期

2. 跑一次 `doctor`