Automation

OpenClaw 是什么？安装、渠道能力与安全清单

系统了解 OpenClaw 是什么、它如何作为自托管 Agent Gateway 工作、支持哪些渠道，以及 2026 年更稳妥的部署方式。

OpenClaw 最近很热，并不是因为它只是又一个 AI 聊天壳子，而是因为它踩中了一个更现实的需求：团队需要一个可自托管、可接渠道、可接浏览器、可做技能复用的 Agent 运行层。

到 2026 年，很多团队已经不再只问“用哪个模型”，而是开始问“如何把 Agent 真正跑进渠道、远程主机、浏览器操作和内部工作流里”。OpenClaw 之所以被反复提起，就是因为它试图把这些能力收敛到同一个 Gateway 和 Control UI 上。

这篇文章会直接回答几个高意图问题：OpenClaw 是什么、它怎么工作、为什么最近热、适合什么场景、不适合什么场景，以及部署时最该先做的安全控制。

OpenClaw 是什么？

OpenClaw 可以理解为一个自托管、Agent 原生、多渠道的运行平台。官方文档的核心描述不是“网站聊天机器人”，而是一个围绕 Gateway、会话路由、渠道接入、浏览器控制和技能复用构建出来的系统。

从官方文档当前公开的信息看，OpenClaw 的核心能力主要包括：

  • 一个统一的 Gateway，负责会话、路由和渠道连接
  • 多渠道接入，包括 WhatsApp、Telegram、Discord、Slack、Signal、iMessage、Google Chat、Microsoft Teams 等
  • 浏览器里的 Control UI
  • iOS 和 Android 的 mobile nodes
  • 按 agent、workspace、sender 隔离会话
  • 图片、音频、文档等媒体处理能力
  • 通过 ClawHub 分发和复用 skills

所以更准确的理解是：OpenClaw 不是单点聊天工具，而是 Agent 工作流的运行层。

为什么 OpenClaw 最近这么热？

它热，不是因为“AI 圈又有新词”，而是因为它的组合刚好击中几个正在升温的需求。

1. 自托管

越来越多团队希望把 Agent 系统跑在自己的机器、自己的网络和自己的控制边界里。

2. 渠道优先

很多产品只重视网页聊天，但真实业务常常发生在 WhatsApp、Telegram、Discord、Teams 这些渠道上。

3. 一个 Gateway 承接多个表面

OpenClaw 把渠道、Control UI、远程访问、浏览器工作流放在同一条主线里，这比拼凑多个小工具更像一个系统。

4. Skill 复用能力

ClawHub 让 OpenClaw 具备了一定的“工作流资产复用”能力，这对持续运营 Agent 的团队很重要。

5. 本地优先的安全思路比较明确

官方文档反复强调默认应该优先 loopback、SSH、Tailscale Serve，而不是一上来就暴露公网入口。这一点比很多“先跑起来再说”的 Agent 工具更成熟。

OpenClaw 怎么工作？

从结构上看，可以把 OpenClaw 分成四层。

1. Gateway

Gateway 是控制平面，负责会话、路由、渠道连接和整体运行状态。

2. Control UI

Control UI 是 Gateway 提供的浏览器控制界面，默认通常在：

http://127.0.0.1:18789/

它和 Gateway 走同一个端口，并通过 WebSocket 握手进行认证。

3. Channels

官方 CLI 文档列出的渠道包括：

  • WhatsApp
  • Telegram
  • Discord
  • Google Chat
  • Slack
  • Mattermost（插件）
  • Signal
  • iMessage
  • Microsoft Teams

4. Nodes 与浏览器/设备操作

OpenClaw 不只处理聊天，还支持 mobile nodes、设备配对、浏览器相关工作流和远程控制模式。

这也是它和很多“聊天即产品”的工具最大区别之一：它更像一个能承接 Agent 运维和多端执行的底座。

官方快速安装路径

根据我在 2026 年 3 月 8 日 检查的官方文档，最短路径如下。

前置要求

  • Node.js 22 或更高
  • 你计划接入的模型 / provider API key
  • 一台适合运行常驻服务的机器

安装

官方文档给出的安装方式包括：

npm install -g openclaw@latest

或者 macOS / Linux 的安装脚本：

curl -fsSL https://openclaw.ai/install.sh | bash

运行 onboarding 并安装 daemon

openclaw onboard --install-daemon

这是官方推荐路径，因为它会把认证、gateway 配置和可选渠道一起初始化。

检查 Gateway

openclaw gateway status

打开 Control UI

openclaw dashboard

或者直接打开：

http://127.0.0.1:18789/

如需接渠道

openclaw channels login
openclaw gateway --port 18789

配置文件位置

默认配置在：

~/.openclaw/openclaw.json

OpenClaw 适合什么场景？

多渠道 Agent 工作流

如果你需要同一套 Agent 逻辑同时接 WhatsApp、Telegram、Discord 或 Teams，OpenClaw 比网站型聊天工具更相关。

自托管控制面

如果你想自己掌控运行方式、会话、远程访问和路由，而不是完全依赖托管 SaaS，OpenClaw 的定位是成立的。

浏览器与设备协同

当工作流需要浏览器控制、远程健康检查、设备节点或消息渠道一起工作时，OpenClaw 的价值会更明显。

技能复用

如果你希望团队把工作流沉淀成可复用 skills，而不是每次重新写 prompt，ClawHub 这层就会更有意义。

OpenClaw 不适合什么场景？

你只想做网站客服机器人

如果只是做 FAQ、小型客服机器人或网页 lead capture，很多 no-code 工具会更轻。

团队不想自己运维

OpenClaw 的价值一半来自自托管，代价也是自托管。没有运维纪律时，它很容易从“灵活”变成“难控”。

权限治理很弱

Agent 能接渠道、能控浏览器、能远程访问，这些能力一旦治理差，就会放大风险。

你追求的是零配置的企业 SaaS 体验

OpenClaw 更像一个快速演化中的技术平台，而不是高度封装的企业成品。

部署前必须先做的安全清单

这是最重要的一段。

官方文档反复强调：如果没有非常明确的理由，Gateway 应该优先保持 loopback-only。 这是默认安全姿势，不是可选项。

1. 优先 loopback，不要一开始就暴露公网

优先使用这些模式：

  • SSH tunnel
  • Tailscale Serve
  • macOS app 的 Remote over SSH

这比直接绑定到 LAN 或公网安全得多。

2. 从第一天就启用认证

Control UI 连接依赖 token 或 password。官方 onboarding 默认会生成 gateway token，应该立即用上。

3. 把浏览器控制当成运维权限，而不是普通前台功能

浏览器控制、本地节点、远程设备访问，本质上都属于高权限面。

4. 保留首次配对审批

官方文档说明新浏览器或新设备连接时需要一次性 pairing approval，即使在更友好的远程模式下也是如此。这层不要图省事去绕开。

5. 先做 sender allowlist

官方文档明确建议先从 channels.whatsapp.allowFrom 和群组 mention 规则开始收缩权限范围。

文档给出的方向性配置类似这样：

{
  "channels": {
    "whatsapp": {
      "allowFrom": ["+15555550123"],
      "groups": {
        "*": { "requireMention": true }
      }
    }
  },
  "messages": {
    "groupChat": {
      "mentionPatterns": ["@openclaw"]
    }
  }
}

6. 使用专用浏览器 profile

官方浏览器登录文档明确建议使用 OpenClaw 专用浏览器 profile，并推荐敏感站点优先人工登录。不要把账号密码直接交给模型。

7. 区分本地模式和远程模式

官方文档把 local、remote over SSH、remote direct 拆得很清楚。大多数团队应优先用 loopback + SSH / Tailscale 这种更窄的访问面。

一个更合理的 OpenClaw 起步方式

更稳妥的落地方式通常是：

  • 一台受控的 Mac、桌面机或小型服务器跑 Gateway
  • 默认只绑 loopback
  • 通过本地 Control UI 或 SSH / Tailscale Serve 访问
  • 先接 1 到 2 个渠道，不要一次性全开
  • 用 allowlist 限定可信发送者
  • 先固定一套模型和预算边界
  • 浏览器工作流使用专用 profile

这套方式能先验证它到底有没有给团队带来真正的运营增益，而不是一上来就把系统复杂度拉满。

FAQ

OpenClaw 是开源的吗？

官方文档将 OpenClaw 描述为 open source，并标注为 MIT license。

OpenClaw 是聊天机器人平台吗？

不只是。更准确地说，它是一个自托管的 Agent Gateway 和运行层，聊天只是其中一个表面。

OpenClaw 支持哪些渠道？

官方文档和 CLI 参考里列出了 WhatsApp、Telegram、Discord、Google Chat、Slack、Mattermost（插件）、Signal、iMessage 和 Microsoft Teams。

必须上公网服务器吗？

不需要。官方文档多次给出本地或 loopback-first 的方案，很多情况下这反而是更安全的默认值。

最快、也最安全的试用方式是什么？

安装 OpenClaw、跑 onboarding、保持 Gateway 只在本机、通过 127.0.0.1 打开 Control UI，然后在做好认证和 allowlist 之前不要扩大暴露面。

结论

OpenClaw 值得关注，不是因为它“又一个 AI 新工具”，而是因为它试图解决一个更难、也更实际的问题：如何把 Agent 运行在渠道、浏览器、远程访问和运维控制之间，并且仍然保留自托管控制权。

它的优势不是“最简单”，而是“更像基础设施”。把它当成运维级系统来部署、先做安全收缩、先跑窄工作流验证，才更可能把 OpenClaw 变成真实产能，而不是新的复杂度来源。

Related guides