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 指南)。

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

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

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

3.1.4 最小闭环测试用例

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

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

  • 动作:先执行 health,再打开 Dashboard。

  • 预期:health 返回正常;Dashboard 可访问。

测试用例 2:最小交互

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

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

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

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

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

最后更新于