OpenClaw 本地部署入门:先跑通 Gateway,再给 AI 最小权限

安装一个能聊天的 AI 应用不难，难的是克制住“一次把模型、聊天渠道、浏览器、文件、邮件和几十个 Skills 全部装上”的冲动。

OpenClaw 和普通聊天网页的差别，正在于它能连接本地命令、文件、浏览器和外部平台。这些连接让它能做事，也让错误的权限配置可以从“回答错了”升级为“操作错了”。

所以最稳的入门路线不是功能最多，而是每增加一层能力，都有一个可验收的停顿点。

先纠正一个概念：自托管不等于所有数据都不出机器

OpenClaw 的 Gateway、配置和工作区可以运行在你控制的电脑或服务器上，但如果你在 onboarding 中选择了云端模型提供商，相关提示、上下文和模型请求仍会离开本机。

因此，部署前应该先回答两个问题：

• 哪些文件和对话允许送到模型提供商？
• 哪些任务允许 AI 直接操作，哪些必须在执行前让人确认？

这两个边界比“装多少技能”更重要。

最小可用系统只有四层

OpenClaw 的首次部署可以先只保留四层：安装器、onboarding、Gateway 和 Control UI。

1. 安装器
   负责准备 CLI 和运行环境。
2. Onboarding
    选择模型提供商、完成认证并初始化 Gateway。
3. Gateway
    管理会话、连接、工具和配置。
4. Control UI
    提供浏览器中的首次聊天和后续设置入口。

等这四层验收通过，再加 Telegram、飞书、Slack 等 Channels，以及真正需要的 Skills。

第一步：按官方前置准备环境

根据 2026-08-20 核验的 Getting Started，当前支持的 Node.js 组合是 22.22.3+、24.15+ 或 25.9+，官方推荐 Node 26。你还需要一个可用的模型提供商认证方式或 API key。

不要从过去文章里复制一个固定 Node 安装包。先执行：

node --version

然后与官方文档当前要求比对。Windows 用户也不必默认把自己塞进一篇旧 WSL2 教程：当前文档把原生 Windows Hub 应用作为最简单的桌面路径，同时仍支持 PowerShell 安装器和 WSL2 Gateway。

第二步：安装后先跑完 onboarding

macOS 和 Linux 的官方快速安装命令是：

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

PowerShell 路径是：

iwr -useb https://openclaw.ai/install.ps1 | iex

通过管道执行网络脚本前，可以先在浏览器中打开脚本 URL 检查来源；在管理员账号或重要服务器上，应优先选择下载后审阅再执行。

安装器会自动进入 onboarding。首轮只配置模型认证和 Gateway，其他项能跳就跳。官方也明确说明，可选步骤后续可用 openclaw configure 补充。

图：较早版本的真实 onboarding 截图。菜单可能变化，但“先跳过渠道、后续再配”的策略仍与当前官方文档一致。

第三步：用三个结果验收，不要只看安装命令退出码

先查 Gateway：

openclaw gateway status

官方文档的预期是 Gateway 监听在 18789。然后打开 Control UI：

openclaw dashboard

最后在聊天界面发送一个不需要工具的简单问题。只有同时满足以下三项，核心链路才算可用：

• Gateway 状态正常；
• Dashboard 可以打开；
• 聊天能收到模型回复。

第一次就测浏览器、邮件或文件删改，会把模型认证、Gateway、工具权限和第三方服务四类问题混在一起，排查成本反而更高。

第四步：先选权限模式，再给工具

OpenClaw 当前的 host exec 模式包括 deny、allowlist、ask、auto 和 full。它们决定主机命令在什么情况下可直接运行，什么情况下需要评审或人工确认。权限模式文档

一个实用的选择方法是：

full 会跳过提示。除非你能解释这个会话为什么值得获得完整主机权限，否则不应把它当成“少点几次确认”的便利开关。

第一轮不要装满

外部聊天渠道会引入 bot token、账号权限、群聊访问和公网回调等新边界。首次部署跳过它们，不会影响 Control UI 里的核心聊天。

等本地链路稳定后，一次只增加一个渠道，并限定谁能给 agent 发消息、群聊中是否需要 @、哪些工具在该渠道可用。

Skills 从工作区开始，不要直接全局化

OpenClaw 会按优先级发现不同位置的 Skills。工作区下的 <workspace>/skills 优先级最高，共享和内置目录低于它。官方 Skills 文档

这意味着首次试用一个 Skill 时，最小风险做法是把它放在专用测试工作区，而不是立即使用 --global 让所有本地 agent 都能看到。

图：较早版本安装界面会列出 Skills 的就绪、缺少依赖和不支持状态；当前界面可能变化，但依赖与权限仍需逐项核对。

还要注意，“agent 能看到这个 Skill”不等于“它只能执行这个 Skill 里写的命令”。如果同一个 agent 拥有宽松的 shell 权限，仍需通过沙箱、系统账号、命令允许列表和独立凭证继续收紧。

第一个任务要低风险、可回滚、可验收

不要用“把我的邮箱整理干净”作为首个自动化任务。选一个只读输入、只写测试目录、结果能人工快速检查的任务，例如：

读取测试工作区中的三份 Markdown，只在 output/ 目录新建一份索引，列出文件名、一句话摘要和无法解析的项目。不修改原文，不访问其他目录，不发送网络请求。

验收时检查三件事：原文没有变，输出只在指定目录，摘要与原文一致。通过后再增加网络、浏览器或消息渠道。

排查问题时，按链路顺序查

• Dashboard 打不开：
   先看 Gateway 状态和端口，不要先重装 Skills。
• Dashboard 能打开但模型不回复：
   检查模型认证、提供商配置和网络。
• 聊天正常但命令被拒绝：
   查有效 exec policy，不要用 full 掩盖未理解的配置。
• Skill 看不到：
   查它的目录、SKILL.md 和 agent 允许列表。
• Skill 可见但执行失败：
   再查依赖、凭证、宿主位置与 shell 授权。

这样排查的好处是，每次只面对一个失败边界。

结语

OpenClaw 的入门门槛不在“会不会把所有选项配满”，而在“能不能说清每一层能力带来了什么新风险”。

先让 Gateway 和 Control UI 稳定工作，再收紧 exec policy，然后只为一个明确任务增加一个渠道或 Skill。这条路线看起来比“一键全装”慢，却能让你在出错时知道哪一层该撤回。