半年过去了,再来装 OpenClaw,先用一条 Ship checklist 测通消息链路

第一次装 OpenClaw，最容易踩的坑不是命令不会敲，而是太早把它接进正式消息入口。2026 年 7 月 8 日再看这个项目，GitHub 上已经有约 382k stars，README 里给的推荐安装路径也很明确：npm install -g openclaw@latest 之后，先跑 openclaw onboard --install-daemon。但这还不够，真正决定你要不要继续用的，是第一条测试消息能不能按顺序走完。

这篇不谈“它看起来很强”，只谈第一次装完以后怎么做一轮低风险首测。目标很简单：本机装好、gateway 活着、只接一个测试渠道、发出一条普通消息、再让 agent 回你一份 checklist。只要这条链路跑通，你再考虑群聊、自动化、长期常驻，才不容易把自己送进一个难排查的大坑。

OpenClaw 第一次该替你接哪一步

OpenClaw 不是“再来一个聊天框”，而是把 agent 接到你已经在用的消息入口里。README 说得很直白，它可以回在 WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage、Microsoft Teams、WebChat 这些渠道里。

第一次不要贪多。最合适的首测任务不是“帮我管理工作流”，而是一个可逆、可验证、失败了也没损失的小任务。README 的 TL;DR 里已经给了一个很好的例子：Ship checklist。因为它正好能测三件事：

• agent 能不能真的被叫起来
• 模型能不能返回结构化结果
• 这条结果能不能顺利回到你指定的消息入口

前置条件先卡死，别边装边猜

1. 机器别选共享主机

README 要求运行时至少是 Node 22。第一次尽量装在你自己能完全控制的机器上，不要一上来就放公司跳板机、多人共用开发机，或者已经接正式业务权限的主机。

原因很现实。README 后面专门提醒了一件事：Gateway host 默认会跑 exec tool 和 channel connections。换句话说，你如果没想清楚权限边界，就等于先把“能执行命令的入口”装到了真环境上。

2. 首测渠道只选一个

不要第一次同时接 Telegram、Discord、微信、Slack。第一次只接一个渠道，你才知道问题到底出在安装、模型、渠道认证，还是消息路由。

如果你手里已经有 Telegram bot token，那 Telegram 最适合做首测。README 写得很具体：

• 可以设环境变量 TELEGRAM_BOT_TOKEN
• 或者在配置里填 channels.telegram.botToken

如果你更熟 Discord，也可以只接 Discord：

• 设 DISCORD_BOT_TOKEN
• 或者填 channels.discord.token

第一次别碰正式客户群，别碰正式销售号，也别碰已经在收真实消息的工作频道。

3. 首测任务只选一条可逆消息

今天这轮测试，不是让 OpenClaw 替你接管工作，而是让它证明“消息能进、结果能回、权限没失控”。最稳妥的首测任务只有两种：

• 纯通道测试：发一条 Hello from OpenClaw
• agent 测试：回一份 Ship checklist

先把这两条测通，再谈别的。

正确的首测顺序，不要自己乱改

第一步：安装后先走官方 onboarding

README 给的推荐路径不是自己拼一堆配置，而是先走向导：

--install-daemon 的意义不是“更高级”，而是让 Gateway 以用户级服务方式常驻。你后面测消息入口、测 agent、测 pairing，都是围着这个 Gateway 转。第一步就跳过它，后面你看到的很多报错都不稳定。

第二步：先看 Gateway 是不是活着

向导跑完以后，不要急着发消息，先看状态：

如果这里状态不正常，再用 README 给的方式手动拉起并看日志：

第一次装的时候，你要先确认的是“服务有没有起来”，不是“AI 会不会回答”。Gateway 没起，后面任何渠道测试都没有意义。

第三步：只连一个测试渠道

这一步只做一件事：把一个测试渠道接进来。

如果你走 Telegram，就只管 Telegram 的 token 有没有配好；如果你走 Discord，就只管 Discord 的 token 有没有配好。不要因为 README 支持很多渠道，就在第一轮把它们一起配上。那样一旦消息不回，你根本不知道是哪一层坏了。

这一步的目标也要收窄：不是“让它全面工作”，而是“让它具备收发一条测试消息的条件”。

第四步：先测通道，不先测 agent

很多人会直接跑 agent 命令，但更稳的顺序是先验证通道能不能发消息。README 的 TL;DR 里给了最小例子：

你可以把它理解成“先测喇叭，再测大脑”。如果这条普通消息都发不出去，问题多半还在渠道配置、目标地址、凭证或路由层，不在 agent 本身。

只有当普通消息能出去，你再做下一步才有意义。

第五步：再测 agent 的最小任务

README 给的首测命令就是：

这一步不要改成复杂任务。第一次你要看的是它能不能稳定回你一份清单，而不是它会不会替你做完一个完整项目。

如果你担心这个提示词太抽象，可以把它换成同样低风险、同样可判断成败的版本，比如：

• “给我一份今天发版前的 5 项检查清单”
• “把明天上线前最容易漏的 3 件事列出来”

任务可以换，但标准别变：要短、可逆、结果一眼能判断。

第一次装时，最该盯的不是答案质量，而是这三个关口

1. DM pairing 有没有真的拦住陌生人

README 对默认安全策略写得很清楚：Telegram、WhatsApp、Signal、iMessage、Microsoft Teams、Discord、Google Chat、Slack 这些渠道，默认是 dmPolicy="pairing"。

这代表什么？陌生发送者不会直接触发执行，而是先收到一个 pairing code。只有你批准后，它才进入本地 allowlist。

批准命令是：

第一次装的时候，这一步必须自己看一遍。因为它决定了你装的是“有门禁的 agent”，还是“谁来私聊都能碰你工具链的 agent”。

2. 主机会不会直接跑命令

README 还有一个很关键但很多人会漏掉的点：默认情况下，main 会话的工具是跑在宿主机上的。也就是说，你在主会话里测得越像真任务，它越可能直接碰到真实环境。

所以第一次首测，不要给它正式文件、正式目录、正式账号。你现在只需要一条 checklist，不需要让它操作真实资产。

3. 群聊和频道会不会越权

如果你后面准备把它放到群里，README 建议把 agents.defaults.sandbox.mode 设成 non-main，让非主会话在每个 session 的 Docker sandbox 里运行。

这件事第一轮不用马上改，但你要知道它是下一步真正该看的安全阀。因为单人主会话和群聊/频道的风险，不是一个量级。

看到这些结果，才算首测通过

成功判断

• openclaw gateway status
  
   正常，或者你手动拉起后服务稳定不掉
• 你接入的那个测试渠道，能收到普通测试消息
• openclaw agent --message "Ship checklist" --thinking high
  
   能回一份像样的清单
• 陌生 DM 没有直接执行，而是先进入 pairing
• 你能说清楚这条消息是“哪一个渠道进、哪一个命令发、哪一步回来的”

这五条里少一条，都不建议继续加量。

出现这些情况就先停，不要硬推

1. 你准备跳过测试号，直接接正式消息入口

这不是效率高，这是把排障成本放大。第一次装，正式账号和正式群都不该进场。

2. 普通消息都发不出去，你却先怀疑模型

openclaw message send 这一层没通，别先讨论 prompt 和思考强度。先查渠道配置、token、目标地址和 gateway 状态。

3. 你还没看懂 pairing，就想把 DM 放开

README 明确说了，公开 inbound DMs 需要显式 opt-in。第一次首测阶段，不要急着改成 dmPolicy="open"，更不要随手把 allowlist 放成 "*"。

4. 你已经想让它碰正式文件或正式命令

一旦你还没搞清“exec 跑在 Gateway host”“群聊怎么 sandbox”“哪些会话是 main”，就不要把真实工作环境交给它。

首测通过以后，下一步只加一个变量

如果今天这轮测通了，下一步也别一下子扩太多。你只加一个变量就够了：

• 要么从“回 checklist”升级到“整理一条明天要跟进的清单”
• 要么从“一个测试渠道”增加到“第二个测试渠道”
• 要么开始检查 non-main sandbox，准备群聊场景

不要同时加任务复杂度、渠道数量和权限范围。

第一次装 OpenClaw，真正有价值的不是它能展示多少能力，而是你能不能用一条低风险消息，把“安装完成、渠道可用、agent 可回、陌生人进不来、正式环境没被误碰”这五件事一起确认掉。Ship checklist 这种小任务看起来不炫，但它正好能把第一轮最该确认的链路，测得很干净。