10. Gateway：常驻控制平面怎么工作

这篇解决什么问题

OpenClaw 的 Gateway 是常驻控制平面。

它不是模型，也不是某个平台 bot。它负责把外部消息、CLI 请求、本地节点和 Agent Runtime 串起来。

Gateway 解决什么

可以先理解成：

接收消息
识别 channel/account/sender
处理 pairing 和 allowlist
找到目标 agent/session
调用 Agent Runtime
把结果投递回原渠道或目标渠道
维护状态和日志

所以 Gateway 是“入口和路由层”。

相关目录

src/gateway/
src/cli/gateway-cli/
src/commands/gateway-status/
src/daemon/
src/channels/
src/pairing/

CLI 里 openclaw gateway status 这类命令，会走 gateway 相关命令和状态检查。

daemon 模式和前台模式

推荐安装方式：

openclaw onboard --install-daemon

这会把 Gateway 作为常驻服务安装。

调试时可以前台跑：

openclaw gateway stop
openclaw gateway --port 18789 --verbose

前台模式适合看日志、定位 channel 和 provider 问题。

Gateway 不应该承担什么

Gateway 不应该实现具体 Agent 推理逻辑。

如果你看到模型、tool、session 细节，通常已经进入 src/agents/。

如果你看到 Telegram、Feishu、Slack 这些平台细节，通常进入 src/channels/ 或 extensions/。

Gateway 的核心是调度和路由。

常见问题定位

Gateway 没运行

openclaw gateway status

消息进不来

看 channel 凭证、webhook、allowlist、pairing。

消息进来了但 Agent 不回

看 runtime、provider、auth profile、tool policy。

Agent 有结果但没投递

看 delivery、channel 发送权限、平台限制。

实践：Gateway 链路检查

准备两个终端：一个观察 Gateway 状态或日志，另一个发送消息。

先记录发送前状态，再发一条带唯一标记的消息，例如：

openclaw gateway status
openclaw agent --message "gateway-check-2026：只原样返回这段标记" --thinking low

你要观察的不是回复内容本身，而是这条消息是否完成了完整闭环。

完成标准

• 发送前 Gateway 正常运行；
• 请求进入 Gateway；
• Gateway 把请求交给 Agent Runtime；
• Agent 生成结果；
• 结果回到发起请求的入口；
• 再次检查时 Gateway 仍然正常。

如果失败，按下面的边界定位，而不是一次重配全部系统：

消息没进入        → Gateway / Channel / pairing
进入但没有结果    → Runtime / provider / auth
有结果但没有返回  → delivery / Channel 权限

多走一步

通过一个已经接入的远程 Channel 发送另一段唯一标记，确认回复回到原渠道，而不是只在本地 CLI 可见。

下一篇看什么

下一篇看 Channels。