GitHub 收藏详解 · 官方资料解读
OpenClaw 详解：Gateway、消息渠道与设备节点如何协作
用途、核心机制、上手路径与使用边界
来源：openclaw/openclaw · openclaw
I
用户问题
定位与适用任务OpenClaw 把个人助手放在自己的设备与常用消息渠道之间。核心不是某一个聊天窗口，而是持续运行的 Gateway：它连接模型、会话、工具和渠道，其他界面围绕它工作。理解这层控制面之后，安装、远程访问、设备配对和工具权限才不会混成同一个问题。
- 让个人助手通过常用消息应用接收任务
- 从多个客户端连接同一个运行环境
- 按设备能力扩展语音、屏幕与本地动作
* * *
II
产品机制
能力与工作方式- Gateway 管理运行状态Gateway 负责会话、事件、工具与渠道连接，Control UI、CLI 和 TUI 是访问入口。架构文档说明客户端通过 WebSocket 请求和订阅事件，便于持续观察执行。 原文
- 渠道是消息适配层渠道把外部消息带入助手，再把结果送回。平台配对和群组权限需要按具体渠道核对；一个可用私聊入口不自动证明其他入口有相同访问规则。 原文
- 节点声明设备能力节点通过同一个 Gateway 协议连接，但带有 node 角色和显式能力。设备身份与配对记录帮助区分哪台设备可以提供相机、屏幕或位置操作。 原文
- 模型、工具与技能可扩展模型与 Agent harness 以可替换插件接入，工具、技能和插件扩展任务能力。状态在本机保存，不代表配置的模型提供方与消息平台不会接收请求。 原文
* * *
III
使用流程
从最小任务开始- 按平台安装选择官方安装器或包管理路径，核对当前 Node 与 npm 条件。已有安装先确认数据和配置位置，再升级。
- 完成 onboarding按向导验证模型、创建工作区并配置 Gateway。包安装路径需要手动运行 onboard，安装器则可能自动打开向导。
- 先在控制台测试检查 gateway status，再打开 dashboard 完成小任务。此时先确认本机执行链路，不同时引入多个消息渠道。
- 逐个接入渠道与设备按文档配对一个渠道或设备，测试允许和未允许的访问，再检查任务结果回到哪里。需要工具隔离时单独配置 sandbox。
以下试用顺序与检查方法是编辑建议；命令入口依据官方文档，本文未运行项目。 原文
官方入口示例
openclaw onboard --install-daemon
openclaw gateway status
openclaw dashboard请先完成上文前置配置；示例不包含真实凭据。
* * *
IV
边界与限制
约束与选用判断| 边界 | 具体含义 | 使用建议 |
|---|---|---|
| 本机执行默认值 | README 说明主会话工具默认在宿主运行，除非另外配置 sandbox。 原文 | 不要把“本地助手”理解成已经隔离的执行环境。 |
| 远程暴露与身份 | 设备配对、渠道发送者与 Gateway 访问是不同层面的身份。 原文 | 对外接入前按安全文档逐项核对。 |
左右滑动查看完整表格
适合希望把持续运行助手连接到多个入口的用户。其收益来自渠道和设备协作，运维与权限配置也因此成为日常使用的一部分。
* * *
V
怎样判断是否值得采用
试用场景与验收可以先在 Control UI 中让助手读取一个练习文件，确认结果，再从已配对的消息渠道请求同样任务。比较工作目录、权限提示和结果接收位置。如果消息能够到达而文件任务失败，应检查工具执行环境；如果根本没有任务记录，则先查渠道与 Gateway 连接。
最小验收包括 Gateway 状态正常、模型能回答、工具按预期执行、渠道结果送达。启用设备节点后，还要确认能力列表与实际设备一致。
资料依据：固定版本 README · 补充官方文档 · 当前仓库。
资料获取时间（UTC）：2026-11-02T07:29:46.515Z；仓库快照提交：b0fdadd6b344。来源日期表示该仓库快照提交时间，并非项目首次发布日期。
* * *
编者评论
这篇文章，如何判断
阅读价值
Gateway、客户端、渠道和节点分工明确，架构文档能解释连接与配对，而不只列出支持平台。
保留意见
本文未部署或做安全审计，不对所有渠道、插件和设备组合提供兼容保证。依赖版本以安装时官方文档为准。 试用案例和验收方法是编辑建议。评级衡量资料参考价值，不是产品性能评分。
可迁移启发
一个助手入口越多，就越需要区分“谁能请求任务”和“任务能操作什么”。身份接入与执行权限应分别设计、分别验收。
原文摘录