operator 入口更稳的升级梯子：先看 UI，再下沉协议和 API

OpenClaw 现在前台入口很多：

• Dashboard
• WebChat
• HTTP API
• Gateway WebSocket

对团队来说，最常见的问题不是“入口不够”，而是：

• 一出问题就切得太深

这会让原本可以在控制面解释清的事，过早变成协议或集成问题。

第一层：先用 Dashboard 看控制面是否健康

如果你现在还没回答清楚这些问题，就不急着往下切：

• Gateway 是否可达
• auth 是否正常
• 当前 agent / sessions / approvals 是否能看见

这时候更适合先开：

• openclaw dashboard

因为 Dashboard 最擅长回答的是：

• 控制面入口还在不在

第二层：再用 WebChat 判断“聊天链路”是不是问题本身

如果 Dashboard 正常，但问题更像：

• 某个会话为什么这样回复
• history 展示是不是和 transcript 一致
• abort partial 是不是 UI 现象

这时更适合切到：

• WebChat

因为它更接近：

• Gateway 上的真实聊天会话面

而不是管理面。

第三层：需要编程集成时，再进 HTTP API

很多团队会过早切到 API，只因为：

• UI 上看起来有点怪

但如果问题还没证明是“程序调用链”本身，更稳的做法是先别跳。
HTTP API 更适合回答的是：

• 外部系统怎么调用
• 兼容 OpenAI 风格的接入怎么做
• 自动化系统怎样集成

它不是第一排障面。

第四层：协议和实时控制问题，再下沉到 Gateway WebSocket

只有当问题已经明显涉及：

• 握手
• role / scopes
• 实时事件流
• node / operator transport

时，才值得直接看：

• Gateway WebSocket protocol

因为这已经不是“哪个页面更合适”，而是：

• 控制面连接本身怎么被声明和授权

一个更稳的升级顺序

长期来看，更推荐这条顺序：

1. Dashboard 看入口和 auth
2. WebChat 看会话和回复表现
3. HTTP API 看集成调用
4. WebSocket 看协议与实时控制

这样做的好处是：

• 更容易缩小问题范围
• 不会一开始就把所有现象解释成协议故障
• operator 之间更容易交接

什么情况下该跳层

也有少数情况可以直接跳层：

• 你已经明确在做 SDK / API 接入
• node 或 operator 连接握手直接失败
• 你要验证的是 role / scopes / transport 行为

这时直接看更深入口反而更省时间。

推荐延伸阅读

• Gateway WebSocket 的 role 和 scope 应该怎么理解
• Control UI 的 Tools 面板为什么更像运行时目录，不是静态配置页
• HTTP API、Gateway WebSocket 和 SDK 应该怎么分工