3.1 控制台与 WebChat 快速上手

本节以官方 Web 端为准建立最小闭环：先用 CLI 确认网关健康，再用 Dashboard 打开 WebChat 做一次最小交互验证，并把“新设备访问需要批准”这类常见拦截纳入排障路径。目标是让渠道接入之前就具备一条稳定、可复验的本地基准线。

3.1.1 为什么先从 Dashboard 与 WebChat 开始

外部渠道接入会引入大量外部变量：平台限流、回调重试、网络抖动、群聊噪声等。先用本地 Dashboard 与 WebChat 验证主链路，有两个直接收益。

• 把问题分层：如果本地 WebChat 能跑通，外部渠道失败更可能是渠道配置或平台侧问题。

• 建立证据链：本地交互更容易复现，日志与 trace 更完整。

官方建议的桌面端入口是 Dashboard，通常运行在 http://127.0.0.1:18789/ 等本地地址。

3.1.2 打开 Dashboard：端口、入口与常见拦截

操作步骤建议如下。

1. 先确认服务健康。

openclaw health --json

1. 打开 Dashboard。

openclaw dashboard

# 或直接在网关机器上打开：
# http://127.0.0.1:18789/

默认情况下，Dashboard 运行在 http://127.0.0.1:18789/。

常见拦截：新浏览器或新设备首次访问需要批准。若 Dashboard 提示设备待批准，可按官方流程列出并批准设备（命令与字段以实际版本为准，参考 onboarding 指南）。

openclaw devices list
openclaw devices approve <ID>

3.1.3 WebChat 的交互与流式：看得见的过程更容易排障

WebChat 的关键价值在于把过程暴露出来：模型请求是否发出、工具是否被提议与执行、输出是否在流式返回。对排障而言，最重要的是把每次交互与日志里的 trace 对齐。

操作建议：开启结构化日志并保持可见。

openclaw logs --follow --json

3.1.4 最小闭环测试用例

建议用可复验的测试用例验证最小闭环，而不是随意发问。

测试用例 1：健康链路确认

• 动作：先执行 health，再打开 Dashboard。

• 预期：health 返回正常；Dashboard 可访问。

测试用例 2：最小交互

• 动作：在 WebChat 输入“请只输出一个 JSON：{"pong": true}”。

• 预期：能返回合法 JSON；日志中能看到对应的请求与响应事件。

测试用例 3：长输出可解释

• 动作：输入“请分 5 步输出一个排障计划，每步不超过 20 字”。

• 预期：输出按步展开；若出现明显延迟，可在日志中定位停在模型还是工具。