放到 WSL 场景里，这些概念分别对应什么？

前文讲的是抽象概念。

下面把它们放进最常见的实际场景：Windows + WSL2 部署 OpenClaw。

官方 Windows 文档现在明确推荐通过 WSL2 运行 OpenClaw，并说明：CLI 和 Gateway 跑在 Linux 里，这样运行时更一致，工具链兼容性更好；Native Windows 反而可能更麻烦。 同时文档还明确要求，在 WSL 里启用 systemd，这样 Gateway service install 才能正常工作。

这就意味着，在 WSL 方案里：

第一，Gateway 在 Linux 侧。
你启动的那个 openclaw gateway 或 openclaw onboard --install-daemon，本质上都在 WSL 的 Ubuntu 里生效。

第二，浏览器界面可以在 Windows 侧打开，但它连接的还是 WSL 里的 Gateway。
官方 Getting Started 里说直接打开 127.0.0.1:18789 就能看到 Control UI，而 Gateway 默认就绑定在这个地址和端口。

第三，Canvas 也跟着 Gateway 走。
因为 Canvas 本来就是由 Gateway 的 HTTP 服务挂出来的，所以它本质上也属于 WSL 里那套服务能力。

第四，所有 channel 的连接状态也都掌握在 WSL 里的 Gateway 手上。
不是浏览器持有 Telegram/Discord 连接，而是 Gateway 持有。

到这里，你就能理解一个非常经典的现象：

在 WSL 里，网页能打开，不代表 channel 一定正常。

因为网页打开，只能说明：

• Gateway 大概率起来了

• HTTP / WebSocket 大概率能访问

但 Telegram、Discord、Slack 这些 channel 的接入，是另一层事。它们各自还可能涉及 token、bot 权限、平台连接状态、health-monitor 重连、WSL 网络边界等问题。

---

为什么经常会出现“Gateway 起了，但 Channel 不工作”？

这几乎是 OpenClaw 刚上手最典型的问题。

先说结论：

因为“Gateway 在线”只代表总机开机，不代表某条线路真的接通。

官方 Getting Started 里把“Check the Gateway”和“Open the Control UI”作为基本检查步骤；但这套最小闭环默认甚至可以不配置 channel。换句话说，没有 channel，Gateway 也一样能正常启动，Control UI 也一样能打开。

所以当你说“gateway 起了，但 channel 不工作”时，本质上可能是以下几种情况：

1）总机起来了，但线路根本没接好

这类情况最基础，比如：

• channel 没配完整

• token 不对

• bot 权限不对

• 对应平台根本没完成接入

这时 Gateway 当然可以是正常的，因为它是中枢，不依赖某一个 channel 才能启动。

2）线路看起来在跑，但其实没真正连通

这类更隐蔽。
近期 GitHub issue 里可以看到类似现象：健康监控会把某些 channel 判定为 stuck 或 disconnected，然后不断重启；从用户视角看，像是“程序明明在跑，但消息就是不进来”。

这很像现实里的情况：
交换机没断电，但某条网线已经松了。

3）WSL 网络和访问地址用错了

官方 WSL 文档特别提醒：如果别的机器或远程节点要访问 WSL 里的服务，不能继续用 127.0.0.1 这种只对本机有效的地址，而要用可达的 Gateway URL；必要时还要做端口转发。文档还专门写了 portproxy 的配置示例。

所以如果你是这种场景：

• Gateway 在 WSL 里

• 你想让别的机器连它

• 结果还把地址写成 127.0.0.1

那“channel / node / remote client 不工作”就一点都不奇怪。
因为你实际上是把对方指向了它自己本地，而不是你的 WSL Gateway。

---

一个最适合小白记住的区分法

如果你只想记一套最简单的对应关系，可以记下面这组：

Gateway = 总机
负责接入、路由、状态、会话、健康检查。

Channel = 线路
负责把 Telegram、Discord、Slack 这些平台接进来。

Agent = 干活的人
负责理解任务、调用工具、生成回复。

Model = 大脑引擎
负责底层推理能力。

Session = 记忆盒子
负责某段对话的上下文和归属。

Control UI = 后台控制台
管理员自己用来测试和管理 OpenClaw。

Canvas = 动态画布
给 AI 展示或交互用的工作表面。

Plugin = 扩展插槽
给 OpenClaw 增加新能力。

Auth profile = 模型侧凭据档案
管理 API key / OAuth / token 等认证信息。

heartbeat = 心跳
health-monitor = 巡检员。

---

一段总结

如果我要用一段话，给大家做真正的“概念扫盲”，我会这样写：

OpenClaw 最容易让人困惑的地方，在于它不是一个单体程序，而是一套分层系统。Gateway 是总机，Channel 是线路，Agent 是干活的人，Model 是大脑，Control UI 是后台操作台，Canvas 是可视化画布。

尤其在 WSL 部署里，CLI 和 Gateway 实际跑在 Linux 侧，浏览器只是访问它的界面，所以“网页能打开”不等于“聊天渠道已接通”。一旦把这些层次分开，OpenClaw 的日志、启动链路和排错思路就会清晰很多。