跳转到正文

OpenClaw 入门指南

已上线 9 章 · 还有 11 章即将推出 · 最后更新：March 2026

内容概览

  • ✓OpenClaw vs Claude vs 其他
  • ✓最便宜的 LLM 提供商
  • ✓60+ 托管方案
  • ✓37 个实用提示词
  • ✓25 项核心技能
  • ✓5 个最佳记忆插件

开始阅读！

1

OpenClaw 是什么（以及为什么大家都很兴奋）

你可能在想

我一直听人说 OpenClaw 和 AI 智能体，但我到底能用它做什么？

如果你正处于这个阶段——很好。这正是正确的起点。

简单的理念

OpenClaw 让你运行自己的 AI 助手，并通过常用的与它对话，如 、、、 等——而不是把它困在一个浏览器标签页里。

但渠道只是起点。OpenClaw 还可以通过运行计划性和周期性任务，通过实现主动行为让助手自动检查事务而无需你开口，并将你的手机、笔记本电脑和其他设备作为连接——通过单一让智能体可以使用它们的摄像头、屏幕和本地命令。

你会经常看到“网关”这个词，它的意思很简单：一座桥梁，让你的助手在你日常生活所在的地方触手可及。

OpenClaw 完全——你可以阅读每一行代码、审计安全模型并参与贡献。它在大约四个月内从零成长为 GitHub 上星标最多的项目，这在任何软件项目中都是前所未有的。

这在实践中为什么重要

使用 OpenClaw

触达
遛狗时通过 Telegram 发消息给它
上下文
从上次中断处继续——跨天跨设备
调度
定时任务每天早上为你汇报重要事项
主动性
心跳检查你的收件箱并标记紧急事项
设备
手机摄像头、桌面文件、服务器命令行——全部可达
工具
串联技能：在 Notion 起草、在 Slack 审阅、在 Drive 归档
所有权
你的配置、你的数据、你的规则——运行在你的硬件上

没有 OpenClaw

触达
想起来的时候打开浏览器标签页
上下文
每次都复制粘贴相同的背景信息
调度
设个提醒然后自己做任务
主动性
每次都得你主动开口
设备
只在一个浏览器的一个屏幕上工作
工具
一次性任务，一个接一个
所有权
被锁定在某个供应商的产品路线图中

OpenClaw 不是什么

  • •它不是“最好的模型”。你可以单独选择模型和服务商。
  • •它不仅仅是一个聊天机器人界面。
  • •它不是能取代判断力的魔法自主系统。

把它想象成一种基础设施，让助手变得可用、可迁移、可扩展。

OpenClaw 非常适合的场景

你拥有它

你的配置、你的数据路径、你的规则。

在你的应用中

助手在你已经使用的渠道中随时可用。

你来调整

随着需求增长，可以添加工具、技能和自动化。

社区驱动

不受制于某个应用供应商的产品方向。

OpenClaw 目前不太适合的场景

如果你期望的是以下这些，OpenClaw 可能不太合适：

  • •一个开箱即用、零配置零维护的成品。
  • •一个安装一次就再也不用管的消费级应用。
  • •一个替你做所有决定的东西——模型、安全、渠道——不需要你参与。

这些都不是 OpenClaw 的缺陷——而是适配性问题。如果你想要完全掌控，就需要做一些选择。本指南就是帮你快速、轻松地做出这些选择。

预先设定一个务实的期望

OpenClaw 给你的是杠杆，而不是即时的完美。它的回报是长期的：一旦配置得当，它可以成为真正强大的个人操作层。但首次配置仍然需要做决定（托管、模型服务商、渠道、安全边界）。本指南的目的就是让这些决定变得清晰而快速。

开始之前：安全现实检查

OpenClaw 是强大的、快速迭代的 Alpha 阶段软件。它可以代你执行命令、读取文件、发送消息和访问 API。这种能力伴随着真实的风险。

  • •它处理来自不受信任来源的输入——消息、邮件、网页内容——这使其容易受到提示词注入攻击。
  • •大语言模型可能以意想不到的方式滥用工具，尤其是在权限过宽或模型较弱的情况下。
  • •配置不当可能暴露个人文件、凭证或已连接的服务。

不要急。在授予广泛访问权限之前，请先阅读本指南的安全章节。从最小权限开始，逐步谨慎扩展。你现在花在思考边界上的时间，将来会帮你避免真实的安全事件。

如何阅读本指南

先阅读第 1 到第 5 节，打好扎实的基础。 §1 → §2 → §3 → §4 → §5

订阅

涵盖托管、模型、渠道、安全等 20 个章节。新章节发布时获取通知。

加入 1,200+ 位运营者，获取指南更新

2

OpenClaw 在当今 AI 助手中的定位

你可能在想

我真的需要 OpenClaw 吗，还是直接用 ChatGPT / Claude / Codex / Copilot / Manus 就行？

这正是该问的问题。这些工具有重叠，但它们并不是在解决完全相同的问题。

大多数人最先感受到的实际差异

第一天最大的差异很简单：这个助手能在你每天使用的应用中找到你，还是主要存在于它自己的官方界面里？

第二个实际差异是内置的主动行为。OpenClaw 可以运行周期性的轮次和精确的，让助手在后台检查事务，只浮现重要的内容。

OpenClaw 对比

OpenClaw

核心优势
原生渠道智能体
渠道覆盖
Telegram、WhatsApp、Discord、Slack 等
可自托管
是（核心特性）
自定义深度
完全（工具、技能、配置）
最适合
长期个人智能体

ChatGPT

核心优势
通用助手
渠道覆盖
自有应用 + API
可自托管
否
自定义深度
有限（GPTs）
最适合
快速问答

Claude

核心优势
编程/办公工作
渠道覆盖
自有应用 + API
可自托管
否
自定义深度
高（技能、钩子）
最适合
复杂任务

Copilot

核心优势
代码助手
渠道覆盖
IDE + GitHub
可自托管
否
自定义深度
扩展
最适合
编程工作流

Manus

核心优势
氛围编程
渠道覆盖
自有应用
可自托管
否
自定义深度
有限
最适合
快速原型

哪个 AI 智能体最好？

这个市场每周都在变。与其假装有一个通用赢家，不如用以下标准来判断适配性。

  • →如果你想最快上手、最少配置，商业智能体通常是正确的第一步。
  • →如果你想要一个可以塑造、路由并在自己的环境和渠道中运行的助手，OpenClaw 通常是更好的长期路径。
  • →混合路径很正常：先用商业智能体追求速度，当控制力和渠道覆盖成为真正的约束时再转向 OpenClaw。

OpenClaw 生态系统势头

322k+

GitHub 星标

62k+

Fork 数

0 → #1

4 个月内 GitHub 排名

1.5k+

关注者

OpenClaw 在 4 个月内成为 GitHub 上最受欢迎的开源项目。上面的数字不能保证它是“最好的”，但它们表明真正的运营者正在类生产环境中对生态系统进行压力测试。

3

部署选择：本地 vs 专用硬件 vs VPS vs Docker

部署的第一个问题不是“什么最简单？”而是： 如果这个被欺骗、行为异常或犯了错误，它能访问什么？

OpenClaw 可以处理外部输入（消息、网页内容、邮件、工具）。这意味着和工具滥用是真实的运营风险，而非边缘情况。因此，你的部署选择本质上是一个决策。

安全优先的思维模型

1

信任边界

哪些数据/系统绝对不能被触达？

2

权限级别

智能体是否应拥有 Shell/文件/网络/工具访问权限？多大程度？

3

暴露面

哪些入站渠道/工具可能输入不受信任的内容？

4

运维承受力

你实际能维护多大的配置/管理负担？

如果跳过这一步直接选“最快安装”，你通常会在以后付出代价。

快速对比（风险视角）

最适合

最小权限下的受控实验

主要风险

意外访问个人文件、令牌、浏览器会话、SSH 密钥

仅在以下情况使用

你有意识地沙盒化/限制工具，隔离用户/工作区，并理解宿主机权限

总结

高便利性，但可能带来高后果

务实的默认建议

  • ✓如果智能体拥有广泛的 Shell/工具访问权限：优先选择专用硬件或隔离的 VPS，而非你的个人笔记本。
  • ✓如果你想走最快路径、降低基础设施负担：考虑托管服务，之后再迁移。
  • ✓如果你仍然选择本地运行：除非严格限制，否则视为高风险。

常见失败模式

  • ✗在定义信任边界之前就授予强大工具
  • ✗在存有敏感数据且拥有广泛 Shell 访问权限的个人机器上运行
  • ✗假设提示词注入只是理论上的风险
  • ✗在加固认证和访问路径之前就暴露网关/网络面
  • ✗把 Docker 等同于安全架构

找到你的部署路径

智能体是否需要 Shell 或工具访问权限？

4

托管选择：托管服务商 vs 原始 VPS

本节帮你在几分钟内选择托管路径。这个选择不仅仅是关于托管——它是控制权与责任的权衡。

托管 vs 原始 VPS：你真正在选择什么

使用托管服务商，你花钱换来运维负担的减少：更快的配置、更少的基础设施任务，通常还有更清爽的管理体验。使用原始 VPS 则让你保留对运行时、升级、安全态势和可移植性的最大控制——但每个错误和每项维护任务都由你负责。

两者没有绝对的优劣。正确的选择取决于你的信任模型、时间预算和对基础设施工作的承受能力。

托管

配置速度
快——通常一键或向导式
运维负担
服务商处理更新、补丁、备份
控制深度
受服务商限制（仅仪表盘或部分 SSH）
安全透明度
因服务商而异——有些不够透明
锁定风险
较高——迁移成本因服务商而异
成本模式
月度订阅（可预测）

原始 VPS

配置速度
较慢——手动配置和加固
运维负担
一切由你负责：更新、备份、监控
控制深度
完全控制：SSH、文件系统、网络、配置
安全透明度
完全可见：运行什么、在哪里运行
锁定风险
较低——标准 OpenClaw 安装，可移植
成本模式
VPS/硬件成本 + 你的时间（可变）

实际的权衡

托管通常更好的情况：

  • +你想快速上线
  • +你不想每天处理 SSH/服务器运维
  • +你更看重捆绑的用户体验/功能而非原始控制

原始 VPS 通常更好的情况：

  • +你需要严格控制安全/网络
  • +你想要可预测的可移植性和低锁定风险
  • +你能自行处理更新/备份/监控
一个实用的判断规则：如果你最大的担忧是“我不想管基础设施”，选托管。如果你最大的担忧是“我无法验证服务商在做什么”，选原始 VPS。

托管服务商目录（管理型）

已收录 103 家服务商

Simen

simen.ai

60 秒部署你的 OpenClaw AI 代理——无需编程，无需服务器。通过 WhatsApp 或 Slack 自动处理邮件、日程等。今天免费开始。

起价 $1/mo访问

Hostinger

hostinger.com

选择 Hostinger，打造完美网站。从共享主机和域名到 VPS 和云方案，满足你在线成功所需的一切。

起价 $1.99/mo访问

xCloud

xcloud.host

解锁 xCloud——新一代 WordPress 和服务器管理托管面板，自动化设置并最大化性能。

起价 $3/mo访问

RunClaw

runclaw.ai

5 分钟部署 SSH 密钥加密的 OpenClaw 机器人。Docker 沙箱隔离、UFW 防火墙、fail2ban 防护、自动更新、全托管。

起价 $3.49/mo访问

OpenClaw Setup

openclaw-setup.me

OpenClaw 托管服务，内置聊天、文件上传、Telegram/Slack/WhatsApp 支持，以及按模型的成本追踪。

起价 $3.9/mo访问

Blink Claw

blink.new

无需 Docker、VPS 或单独的 AI 账号即可运行 OpenClaw。一键部署，内置 200 多个 AI 模型，无限代理，永远在线。

起价 $4/mo访问

KiloClaw

kilo.ai

由 Kilo 管理和保护的你的私人 AI 代理。秒级部署 OpenClaw，500 多个模型，企业级安全，零 DevOps。

起价 $4/mo访问

ClawSimple

clawsimple.com

面向 Telegram 机器人的 OpenClaw 托管服务，所有付费方案支持 BYOK，官方 Telegram 机器人支持，安全的默认运行配置，每台服务器可运行多个代理。

起价 $4.92/mo访问

OpenClaw Cloud (setupopenclaw)

setupopenclaw.com

60 秒内运行 OpenClaw（前身为 Clawdbot/Moltbot）。无需终端，无需 VPS 管理。全托管 AI 助手，免费 LLM，预装 15 个以上技能。

起价 $5/mo访问

EasyClaw Pro

easyclaw.pro

EasyClaw 让 OpenClaw 部署一键完成。连接 Telegram、Discord 或 WhatsApp，选择 Claude、GPT 或 Gemini，不到 1 分钟即可上线。

起价 $5/mo访问

OpenClaw AI

openclawd.ai

OpenClaw AI——运行在你自己硬件上的开源个人智能系统。部署在 Mac mini、Windows 或 Linux 上。前身为 Clawdbot 和 Moltbot。

起价 $5/mo访问

Klaus

klausai.com

五分钟拥有你的 AI 员工。在云端安全运行 OpenClaw，支持所有模型、数百种集成和你的所有账户。已获数百家企业信赖。

起价 $7/mo访问

从哪里开始？

A

先用托管，之后迁移到原始 VPS

快速起步，了解什么最重要，然后在控制成为约束时迁移。

B

先用原始 VPS，之后迁移到托管

先积累经验，然后在时间成为瓶颈时将运维外包。

无论哪种情况，从第一天起就保持你的 OpenClaw 配置和工作区的可移植性。

5

LLM 服务商策略：成本、可靠性与风险

模型选择不仅仅关乎质量。在 OpenClaw 中，它直接影响运营成本、工具使用的可靠性和安全态势。

获取顶级模型的最低成本路径

对于很多用户来说，运行强模型的最低成本方式是将 OpenClaw 连接到现有订阅，而不是纯按 Token 付费的 API。

订阅连接器（OpenAI/Codex 订阅认证、GitHub Copilot 认证）在运行始终在线的助手时，可以比大量按 Token 付费的用量便宜得多。

重要提醒：订阅连接器受政策约束

将订阅连接器视为高杠杆但非永久保障的选项。服务商的认证流程、速率限制和外部工具政策可能会变化。始终配置一个备用服务商，避免在单一非官方认证路径上构建关键工作流，并每季度重新检查服务商文档。

OpenAI vs Anthropic 立场

OpenAI 目前更明确地支持在 OpenClaw 中的使用。Anthropic 通过 API 密钥可以良好运行，但明确反对在 OpenClaw 中使用。这不是意识形态问题，而是运营层面的观察。请持续验证，因为服务商立场可能会变化。

OpenRouter 和按 Token 付费的聚合器

在模型广度和快速实验方面非常出色，但在纯 Token 计费下，高用量的助手成本可能迅速攀升。

API 密钥直连

成本模式
按 Token 付费
模型广度
单一服务商的模型
成本可预测性
可变——取决于用量
政策风险
低——官方 API 用法
最适合
生产可靠性

订阅连接器

成本模式
固定订阅费
模型广度
单一服务商的模型
成本可预测性
可预测的月度费用
政策风险
中——政策可能变化
最适合
成本敏感的高用量

OpenRouter

成本模式
按 Token 付费（聚合）
模型广度
多服务商、多模型
成本可预测性
可变——高用量时可能飙升
政策风险
低——为外部使用而设计
最适合
探索和模型切换
使用弱模型来省钱可能适得其反：更差的提示词注入抵抗力、更弱的工具判断力、更高的不安全工具调用概率。如果智能体拥有实际的工具/Shell/邮件/网络权限，请使用更强的模型。弱模型/便宜模型仅限于窄范围、低影响的任务。

本地模型：强大但仅适合高级用户

本地 LLM 部署适合能够管理硬件、延迟、上下文限制和模型质量权衡的高级运营者。本地部署可以降低外部 API 成本，但较弱的本地模型可能降低使用工具的智能体的安全性/可靠性。

最简单的本地模型运行器。非常适合快速实验。通过简单的拉取和运行命令支持多种模型。

https://ollama.com/ →

推荐的入门模式

主要路径

订阅连接器（OpenAI/Codex 或 Copilot）

备选方案

API 密钥备选（OpenAI 或 Anthropic）

关键权衡

最便宜的高质量路径，但连接器政策可能变化

6

渠道策略：Telegram vs WhatsApp vs Slack vs Discord

OpenClaw 主要设计为个人智能体（单一受信任运营者边界），默认情况下不是面向多租户的系统。渠道策略首先是安全设计任务，其次才是用户体验决策。

基线安全态势（添加渠道之前）

基线安全态势（添加渠道之前）

已完成 0/5

安全审计命令
openclaw security audit --deep
openclaw security audit --fix

快速适配指南

Telegram

最适合
个人运营者，快速配置
配置难度
简单（Bot Token）
群组支持
群组 + 论坛话题
命令体验
原生支持强
主要注意事项
Bot API 限制

WhatsApp

最适合
个人日常使用
配置难度
中等（二维码关联）
群组支持
群组（基于 JID）
命令体验
基础
主要注意事项
关联账号（非商业 API）

Discord

最适合
多房间工作流
配置难度
中等（Bot 应用 + Intents）
群组支持
服务器 + 频道 + 话题
命令体验
原生支持强
主要注意事项
权限复杂性

Slack

最适合
工作场所环境
配置难度
较难（应用 + 权限范围 + 配置）
群组支持
频道 + 话题
命令体验
需手动配置斜杠命令
主要注意事项
配置开销最大

配对和访问模型

在主要渠道中，私信默认使用策略：未知发送者会收到一个配对码，消息在获批前不会被处理，配对码会过期（大约 1 小时）。

配对命令
openclaw pairing list <channel>
openclaw pairing approve <channel> <CODE>

共享收件箱的关键风险是跨用户的上下文/数据泄露。默认行为（session.dmScope: "main"）会将多个私信合并到每个智能体的一个主会话中。对于单一受信任运营者来说这是可接受的，但当多人可以给同一智能体发私信时就有风险了。

所有私信共享每个智能体的一个会话。适合单一受信任运营者。多用户场景有风险。

使用场景

你是唯一会给该智能体发私信的人。

上下文膨胀和 Token 消耗

用量监控命令
/usage tokens
/usage full
/usage cost
/status
/context detail
这些是跨平台的网关命令（不仅限于 Telegram）。Telegram 和 Discord 的原生命令体验最好。Slack 需要手动配置斜杠命令，但文本命令仍然有效。

群聊的工作方式

群组会话按聊天 ID 隔离；论坛话题追加 :topic:<id>。支持按话题的 agentId 路由。安全控制：群组白名单、groupPolicy、allowFrom、requireMention。

推荐的上线顺序

1

从一个渠道开始

大多数个人场景选择 Telegram 或 WhatsApp。

2

锁定私信策略 + 白名单

在做其他任何事之前先配置配对和访问控制。

3

显式设置 dmScope

为你的信任边界选择合适的隔离级别。

4

启用用量可视化

运行 /usage tokens 或 /usage full 来尽早监控成本。

5

添加群组/频道访问

仅在权限和提及触发机制验证通过后。

6

添加第二个渠道

仅在第一个渠道的成本和策略行为稳定后。

分步指南：将 OpenClaw 添加到群组

每个渠道都有自己的 Bot/账号身份。你使用平台原生控制将该身份添加到群组。该身份并不总是对应一个智能体——OpenClaw 可以根据绑定和策略将入站消息动态路由到不同的智能体。

1

连接一个渠道身份

通过 BotFather 配置 Bot Token

2

将身份添加到目标群组

将 Bot 添加到群组或超级群组

3

配置访问策略

设置 dmPolicy、groupPolicy、群组白名单、requireMention

4

测试触发规则

当 requireMention: true 时，仅 @提及会触发处理。当 requireMention: false 且发送者已授权时，普通消息会触发。未授权的发送者始终被忽略。

5

验证智能体路由

OpenClaw 使用路由优先级为每条消息解析一个智能体：精确对等匹配，然后父级/话题继承，然后服务器/团队/账号绑定，然后默认智能体回退。

6

验证会话隔离

私信使用 dmScope 设置。群组/频道按渠道 + 群组 ID 隔离。话题获得额外的隔离后缀。

7

确认回复路由

回复确定性地返回到同一入站渠道。模型不会选择出站渠道。

7

套件与封装：裸装 OpenClaw vs 打包方案

你可以自托管 OpenClaw 而无需从零手动构建一切。套件或安装器是围绕 OpenClaw 的社区维护层，预打包了主机加固、配置自动化、预填配置模板、仪表盘和多智能体约定的某些组合。

什么是套件

套件用灵活性换取速度。它们最适合本地专用硬件（Mac mini、树莓派、迷你 PC）、你希望减少手动步骤的裸 VPS 配置，以及需要快速获得运维默认值的团队。如果你从第一天就需要完全自定义的架构，套件的用处就不大了。

三个示例

面向 Debian/Ubuntu 服务器的安全优先自动化。包含防火墙配置、Tailscale/VPN 模式和加固安装流程。

最适合： 希望获得可复现、注重安全的服务器配置的运营者

在 GitHub 上查看 →

Clawdboss

有明确主张的多智能体配置，包含安装向导、模板化工作区、安全态势默认值和可选工具栈。

最适合： 希望快速获得预加固多智能体环境的用户

在 GitHub 上查看 →

AlphaClaw

封装/套壳方案，强调配置体验、运维工具、看门狗/恢复和仪表盘式管理。

最适合： 重视图形化管理和监控的运营者

在 GitHub 上查看 →
这些项目可以节省大量配置时间，但它们由社区管理，可能存在安全风险、过时的假设、与你的威胁模型不匹配的固执默认值，以及隐藏的锁定或迁移阻力。运行前请先评估，尤其是在存有真实凭证或数据的系统上。

评估清单

评估清单

已完成 0/5

AI 辅助评估提示词
I am evaluating this OpenClaw bundle/wrapper for use on a production server.
Repo URL: [paste URL here]

Please provide:
1. Plain-language summary of what this project does
2. Claimed features vs verifiable evidence in the repo
3. Security red flags (network exposure, secrets handling, permissions)
4. Operational lock-in points (migration difficulty, custom formats)
5. Update/maintenance health signals

裸装 OpenClaw vs 套件

裸装 OpenClaw

配置速度
较慢——手动配置
透明度
完全——一切由你配置
灵活性
最大——任何架构
维护
所有更新由你负责
最适合
最大控制、自定义配置

套件

配置速度
较快——自动化/模板化
透明度
部分——需审查其安装内容
灵活性
受限于套件的主张
维护
取决于套件维护者
最适合
快速见效、标准模式
8

OpenClaw 硬件生态

🔒 即将推出

该章节即将推出。

内容预览：

  • •“OpenClaw 硬件”的含义（官方 vs 社区）
  • •硬件优先配置何时有意义
  • •专用硬件选项：迷你 PC、Mac mini、树莓派级别
  • •权衡：可靠性、功耗/网络、维护
  • •购买前评估清单

准备好后获取通知：

9

OpenClaw 工作流：确定性周期自动化

🔒 即将推出

该章节即将推出。

内容预览：

  • •工作流原语：定时任务、心跳循环、钩子、Webhook
  • •确定性流程 vs 智能体流程
  • •周期任务模式（每日简报、收件箱分拣、报告）
  • •工作流的会话设计
  • •周期自动化的成本/安全控制

准备好后获取通知：

10

OpenClaw 节点：单实例中的分布式能力

当你清晰地区分角色时，OpenClaw 最容易理解。

= 控制平面（会话、渠道、路由、策略）。 = 能力宿主（摄像头、画布、屏幕、位置、系统命令）。节点是以 role: node 连接到同一网关 WebSocket 并公布命令声明的伴随设备。

节点存在的原因

节点解决一个实际问题：你最好的助手大脑可能运行在云端，但有用的能力往往在本地设备上。没有节点，VPS 网关只能操作 VPS 本地资源。有了节点，一个网关可以协调本地桌面/浏览器/屏幕能力、手机摄像头/位置/语音能力，以及通过节点宿主执行远程机器命令。

把节点想象成连接到中央大脑的外围设备，而不是迷你网关。

VPS 网关 + 桌面作为节点：它能实现什么

这是对重度用户来说杠杆最高的配置之一。VPS 网关始终在线，负责渠道、记忆和路由。桌面节点宿主在本地运行，按需贡献本地能力。它支持的模式包括：云端智能体触发你桌面上的命令、在主运行时保持在 VPS 的同时使用本地浏览器/画布/摄像头，以及集中策略配合分布式执行面。

Telegram→VPS 网关→桌面节点→本地操作→结果→Telegram
1

消息到达

消息通过 Telegram、WhatsApp、Discord 或其他渠道到达网关。

2

智能体决策

智能体决定调用节点能力。

3

网关转发

网关将 node.invoke 转发到已配对的节点。

4

节点执行

节点在本地执行并将结果返回给网关。

5

回复发送

网关将回复发回原始聊天界面。

这个架构有多安全？

简短回答：经过审慎配置时很强；权限过度时有风险。节点增加了能力，因此也扩大了攻击面。

将配对 + 命令策略 + 执行审批视为分层控制，而非可选附加项。三层都必须正确。

核心控制层

1

网关认证

Token/密码/设备认证控制谁能到达控制平面。

2

设备配对

新节点身份会创建待审批的设备请求。

3

节点命令策略

允许/拒绝策略控制节点可以公布哪些命令。

4

执行审批

节点宿主上的 exec-approvals.json 控制本地实际可以运行什么。

5

每智能体工具策略

控制哪些智能体可以调用节点/执行工具。

6

渠道访问策略

控制谁可以通过入站渠道影响智能体。

关键区别：配对门控制设备是否能作为节点连接。执行审批门控制命令是否能在该节点宿主上运行。两者都必须正确。

配对、认证和审批

设备和节点管理
openclaw devices list
openclaw devices approve <requestId>
openclaw devices reject <requestId>
openclaw nodes status

新节点身份会创建待审批的设备请求（role: node）。使用 'openclaw devices list' 查看待审批请求，使用 'openclaw devices approve' 授予访问权限。及时拒绝未知请求。

平台能力

平台支持因命令类别和运行时状态而异。iOS/Android 的摄像头和画布操作仅限前台；后台调用可能失败。system.run 需要节点支持和审批/白名单双重满足。

macOS

进程类型
桌面应用（节点模式）
摄像头访问
是
画布/屏幕
是
system.run
是（执行审批）
限制
需要 OS 权限

iOS

进程类型
移动应用
摄像头访问
仅前台
画布/屏幕
仅前台
system.run
否
限制
后台限制

Android

进程类型
移动应用
摄像头访问
仅前台
画布/屏幕
仅前台
system.run
否
限制
后台 + 权限开关

无头模式

进程类型
CLI (openclaw node run)
摄像头访问
否
画布/屏幕
否
system.run
是（执行审批）
限制
无 GUI 能力
检查节点能力
openclaw nodes status
openclaw nodes describe --node <idOrNameOrIp>
openclaw approvals get --node <idOrNameOrIp>

节点部署的推荐安全态势

节点部署的推荐安全态势

已完成 0/6

VPS + 节点非常适合的场景

  • →始终在线的云端控制平面，负责渠道、记忆和路由
  • →本地设备能力访问（摄像头、屏幕、文件系统、命令）
  • →每层都有运营者明确控制的安全门

如果你想要零运维责任或不愿调整策略，则不适合。

11

技能：最实用的 20 个技能

🔒 即将推出

该章节即将推出。

内容预览：

  • •实用技能的筛选标准
  • •20 个精选技能及描述
  • •技能维护和管理

准备好后获取通知：

12

仪表盘：默认 vs 自定义

🔒 即将推出

该章节即将推出。

内容预览：

  • •默认控制面板的优势
  • •何时值得自定义仪表盘
  • •运营者常用的仪表盘模式

准备好后获取通知：

13

网络指南（实战）

如果你清晰地区分三个角色，OpenClaw 的网络就很容易理解。总体原则：默认保持网关私有，然后有意识地添加远程访问。

= 单一大脑/控制平面（会话、认证、路由、渠道）。客户端 = 连接到网关的人和应用。 = 向网关暴露能力（摄像头、画布、系统）的外围设备。

先建立思维模型（在配置之前）

网关↔客户端↔节点
  • •每个信任边界应有一个权威网关。
  • •消息到达网关（Telegram/WhatsApp/Discord/Slack），而不是节点。
  • •出站路由确定性地返回入站渠道。
  • •会话状态存储在网关宿主上；UI 只是该状态的客户端。
如果网络配置让你感到困惑，通常困惑的根源其实是角色混淆（网关 vs 节点 vs UI）。先理清角色，网络配置就会变得显而易见。

安全默认架构

1

回环绑定

将 gateway.bind 设为 loopback。只有同一台机器上的进程才能直接连接。

2

强认证

设置强网关认证 Token 或密码。永远不要在任何可通过网络访问的实例上留空认证。

3

渠道配对

为入站渠道启用配对和白名单。未知发送者不应被处理。

4

通过隧道远程访问

通过 SSH 隧道或 Tailscale Serve 远程访问，而不是将网关暴露到公网。

安全默认配置
# gateway.yaml
gateway:
  bind: "loopback"
  auth:
    token: "your-strong-token-here"
  channels:
    dmPolicy: "pairing"

远程访问模式

工作原理

保持网关仅绑定回环地址。通过 SSH 将本地端口隧道到远程网关端口。所有流量通过 SSH 连接加密。

适用场景

通用备选方案。当你需要明确的、低魔法的访问控制时最佳。SSH 可用的地方它就可用。

风险级别

低——无公网暴露，需要 SSH 密钥访问

SSH 隧道
ssh -L 18789:127.0.0.1:18789 user@your-vps

节点和网络边界

节点不是迷你网关；它们是附属的执行面。配对节点与授予执行审批是分开的。网关认证控制谁能到达控制平面。节点审批/白名单控制该节点上可以运行什么。云端网关 + 家庭节点是有效且常见的配置，但会扩大边界面。

将每个新节点视为额外的风险面，而不仅仅是新能力。网关认证 + 节点配对 + 执行审批必须全部正确。

发现和传输注意事项

  • •本地发现（Bonjour/mDNS）提高了便利性，但可能隐藏对可达性的错误假设。
  • •Tailnet/LAN 寻址与 localhost 行为不同。
  • •“本地正常，远程失败”通常意味着绑定/认证/隧道不匹配，而非模型问题。
  • •使用显式 --url 进行远程 CLI 调用时，也要传递显式凭证。

Docker/网络现实

Docker 对于 OpenClaw 网关部署是可选的。在 Docker 中运行网关会增加网络/卷的复杂性；出于可复现性而使用，而非条件反射。沙盒化可以使用 Docker 而无需整个网关在 Docker 中运行。在 VPS/公网主机上，防火墙策略比容器选择更重要。

常见故障模式

症状

连接已建立，但所有请求返回 401/403 或被静默丢弃。

可能原因

Token/密码不匹配、缺少配对审批或认证模式配置错误。

修复

验证客户端和网关配置中的认证 Token 一致。使用 'openclaw pairing list' 检查配对状态。确保认证模式一致。

实用网络上线顺序

1

从回环开始

从仅绑定回环的网关 + 一个渠道开始。先在本地验证一切正常。

2

验证配对

在本地场景中验证私信配对和 /status。确认认证正常工作。

3

添加远程访问

通过 SSH 隧道或 Tailscale Serve 添加远程访问。从另一台设备测试。

4

添加群组策略

添加群组策略和提及触发机制。用真实群组消息测试。

5

添加节点

仅在网关认证 + 路由稳定后添加节点。有意识地配对。

6

重新验证

每次拓扑变更后重新运行网络/安全检查。使用 openclaw security audit --deep。

上线验证

已完成 0/7

14

安全加固指南

🔒 即将推出

该章节即将推出。

内容预览：

  • •首先要锁定的关键 OpenClaw 设置
  • •技能/工具权限管理
  • •提示词注入防御模式
  • •工具/应用边界安全（含 KeepAI）

准备好后获取通知：

15

鲁棒性模式

🔒 即将推出

该章节即将推出。

内容预览：

  • •防循环控制
  • •防上下文爆炸模式
  • •重试/超时/故障处理
  • •基础运维手册清单

准备好后获取通知：

16

记忆、计划和工作区组织

🔒 即将推出

该章节即将推出。

内容预览：

  • •记忆层次和使用模式
  • •计划文件（QMD/清单/笔记）
  • •可扩展的工作区结构

准备好后获取通知：

17

多智能体模式

🔒 即将推出

该章节即将推出。

内容预览：

  • •多智能体何时有帮助（何时有害）
  • •角色划分和交接约定
  • •共享记忆和协调陷阱

准备好后获取通知：

18

推荐的入门蓝图

🔒 即将推出

该章节即将推出。

内容预览：

  • •初学者蓝图
  • •构建者蓝图
  • •团队/运维蓝图

准备好后获取通知：

19

生态系统变体和分叉

🔒 即将推出

该章节即将推出。

内容预览：

  • •如何不被炒作影响地评估变体
  • •可移植性和锁定检查
  • •安全/更新归属检查
  • •封装 vs 分叉 vs 换皮：实际区别

准备好后获取通知：

20

7 天实施清单

🔒 即将推出

该章节即将推出。

内容预览：

  • •逐日上线计划
  • •里程碑和成功标准

准备好后获取通知：

附录

🔒 即将推出

该章节即将推出。

内容预览：

  • •完整可搜索术语表
  • •官方文档链接
  • •故障排除索引

准备好后获取通知：