腾讯云OpenCloudOS部署OpenClaw并接入Kimi_API全流程教程

[1. 为什么在 OpenCloudOS 上部署 OpenClaw](#1. 为什么在 OpenCloudOS 上部署 OpenClaw)
[2. OpenClaw 的定位与运行形态](#2. OpenClaw 的定位与运行形态)
[3. 为什么选择云服务器而不是本地常驻](#3. 为什么选择云服务器而不是本地常驻)
[4. 为什么偏偏选 OpenCloudOS，而不是随便一个 Linux](#4. 为什么偏偏选 OpenCloudOS，而不是随便一个 Linux)
[5. OpenClaw 的运行原理：Gateway、模型提供商、通道、Skills 分别是什么](#5. OpenClaw 的运行原理：Gateway、模型提供商、通道、Skills 分别是什么)
[6. 本文采用的真实部署方案](#6. 本文采用的真实部署方案)
[7. 开始前的准备工作](#7. 开始前的准备工作)
[8. 第一步：登录腾讯云 OpenCloudOS 并完成基础初始化](#8. 第一步：登录腾讯云 OpenCloudOS 并完成基础初始化)
[9. 第二步：安装 Node.js 运行时与常用工具](#9. 第二步：安装 Node.js 运行时与常用工具)
[10. 第三步：安装 OpenClaw 本体](#10. 第三步：安装 OpenClaw 本体)
[11. 第四步：为什么 OpenClaw 的官方推荐入口是 openclaw onboard](#11. 第四步：为什么 OpenClaw 的官方推荐入口是 openclaw onboard)
[12. 第五步：用 Kimi 作为 OpenClaw 的模型提供商](#12. 第五步：用 Kimi 作为 OpenClaw 的模型提供商)
[13. 第六步：理解 Kimi API 的关键配置项](#13. 第六步：理解 Kimi API 的关键配置项)
[14. 第七步：运行 OpenClaw Onboarding 向导](#14. 第七步：运行 OpenClaw Onboarding 向导)
[15. 第八步：如果你想手动检查配置文件](#15. 第八步：如果你想手动检查配置文件)
[16. 第九步：验证 Kimi 模型是否真的接通](#16. 第九步：验证 Kimi 模型是否真的接通)
[17. 第十步：让 OpenClaw 在服务器上长期在线](#17. 第十步：让 OpenClaw 在服务器上长期在线)
[18. 第十一步：部署完成后，你实际获得了什么能力](#18. 第十一步：部署完成后，你实际获得了什么能力)
[19. 常见问题与排错建议](#19. 常见问题与排错建议)
[20. 全文复盘](#20. 全文复盘)
参考资料

1. 为什么在 OpenCloudOS 上部署 OpenClaw

1.1 问题背景

之所以要在 OpenCloudOS 上部署 OpenClaw，不是因为：

OpenCloudOS 会让模型更聪明；
服务器会让 Kimi 回答更准确；
Linux 会直接提高模型质量。

更接近实际的原因是：

OpenClaw 不是一个临时脚本，而是一个需要 长期在线、持续接收消息、持续运行自动化能力 的个人 AI 助手网关。

而云服务器上的 Linux 系统，尤其是适合服务器运行的 OpenCloudOS，更适合承载这种"持续在线的智能体基础设施"。

1.2 OpenClaw 的运行特征决定了部署方式

OpenClaw 官方对自己的定位不是"一个聊天网页"，而是：

一个运行在本地或远端设备上的 personal AI assistant / gateway。

从这个定义出发，OpenClaw 的核心并不是某个前端页面，而是持续运行的控制平面。它承担的工作包括：

接收来自消息通道的输入；
调用模型提供商；
管理会话、记忆、技能；
必要时执行动作、触发自动化；
在你不盯着终端的时候仍然继续运行。

这意味着它更接近下面这种软件形态：

一个长期运行的服务；
一个用户级或系统级守护进程；
一个长期驻留的个人 AI 网关。

它和一次性聊天 Demo 的运行要求并不相同。

1.3 本地运行与云端部署的区别

如果使用场景只是：

想试一下 OpenClaw；
临时体验一下命令行；
不需要长期维持消息通道；

那本地跑完全没问题。

如果目标变成下面这些：

让 OpenClaw 长时间在线；
让它持续挂在 Telegram、飞书、Slack、Discord 等通道上；
让它在你关掉笔记本后还能工作；
让它承担个人 AI 助理或自动化网关的角色；

那么本地机器通常会出现下面这些限制：

电脑会休眠；
家庭网络不稳定；
IP 变化难管理；
服务断了你未必第一时间知道；
本机开发环境容易和日常使用互相污染。

因此，OpenClaw 这类常驻型智能体更适合部署在持续在线的服务器环境中。

1.4 OpenCloudOS 在这里扮演的真实角色

OpenCloudOS 的角色，不是"提升智能"，而是"提供稳定运行土壤"。

在这套架构中，它主要承担的是：

稳定的 Linux 运行环境；
标准的 systemd 服务管理；
适合安装 Node.js 与 OpenClaw CLI 的系统基础；
更适合长期运行守护进程的服务器环境。

这也是本文部署方案成立的前提。

2. OpenClaw 的定位与运行形态

2.1 OpenClaw 不是简单的网页聊天壳

根据 OpenClaw 官方 README，OpenClaw 是一个 personal AI assistant，运行在你自己的设备上，可以接入你已经在使用的消息渠道，并通过一个 Gateway 作为控制平面来工作。

从这段官方描述里，可以提炼出三个要点：

它本身就是一个完整产品/框架，不是你必须从零手搓的后端；
它强调的是"你自己的设备、自托管、长期在线"；
它的核心是 Gateway + Provider + Channel + Skills 的组合，而不是一个网页聊天框。

2.2 OpenClaw 更接近什么类型的系统

更准确地说，OpenClaw 更接近下面几类系统能力的组合：

消息总入口；
个人 AI 智能体网关；
模型调度与调用层；
技能/工具执行框架；
常驻在线的个人助理底座。

如果只是实现下面这种流程：

浏览器输入问题；
后端请求 Kimi API；
返回文本；

那么得到的是一个调用 API 的聊天 Demo，而不是 OpenClaw 本体。

2.3 为什么要先明确这个边界

部署目标不同，安装路径和运维重点也会完全不同：

如果你部署的是"自写聊天 Demo"，重点会是 FastAPI、Nginx、前端页面；
如果你部署的是"OpenClaw 本体"，重点会是 Node.js、openclaw onboard、模型提供商配置、通道配置、守护运行。

本文讨论的是后者，即 OpenClaw 本体的部署与模型接入。

3. 为什么选择云服务器而不是本地常驻

这一节讨论 OpenClaw 在实际使用中为什么更适合部署在云服务器上。

3.1 对 OpenClaw 而言，持续在线比"能启动"更重要

OpenClaw 的核心价值不在于能否运行一条命令，而在于：

它能不能持续在线；
它能不能稳定响应；
它能不能长期维持消息通道连接；
它能不能在你不操作终端的时候继续工作。

在本地电脑上长期常驻时，常见问题包括：

电脑关机，它停；
笔记本合盖，它停；
网络切换，它可能断；
本地网络被限制，它可能收不到外部连接。

3.2 云服务器的价值主要体现在可用性

对接 Kimi 这类 API 型模型调用 的 OpenClaw 来说，关键指标并不是本地算力，而是：

长期在线；
网络稳定；
运行环境固定；
易于守护和排错。

因为模型推理大头发生在 Kimi 的云端，不在你的 OpenCloudOS 机器上。

3.3 在服务器场景下，OpenClaw 更接近完整的运行基础设施

部署到云端以后，OpenClaw 的系统角色会更清晰：

它不再依赖你的本地机器是否开机；
它更容易长期接入消息平台；
它更适合做"随时可达"的个人 AI 助理；
它的运行状态更容易被 systemd 管理。

这时，它更像一套持续运行的智能体系统，而不是临时演示环境。

4. 为什么偏偏选 OpenCloudOS，而不是随便一个 Linux

这里先说明一个边界：

OpenClaw 并不是只能跑在 OpenCloudOS 上。

官方文档给出的广义支持对象是 Linux、macOS 和 Windows/WSL2。

所以这里不应该把 OpenCloudOS 神化成"唯一正确答案"。

4.1 选择 OpenCloudOS 的现实原因

如果你的服务器本来就在腾讯云，那么选 OpenCloudOS 往往有几个现实优点：

上云路径自然，系统镜像现成；
面向服务器场景，长期运行服务更合理；
dnf、systemd、curl、git 这些常规基础设施完整；
和 RHEL 系列 Linux 的运维思路接近。

4.2 OpenCloudOS 自身有哪些可验证的系统优势

如果只写"腾讯云自己的系统，所以更适合腾讯云"，说服力是不够的。

真正应该写清楚的，是 OpenCloudOS 官方文档中那些能够落到工程实践的系统特性。

第一，系统定位就是面向服务器和云场景

OpenCloudOS 官方安装文档与发行说明都把它定位为服务器操作系统，而不是桌面发行版。

这意味着它的设计重点天然偏向：

长期运行服务；
稳定的系统组件；
适合云端节点管理；
更标准的守护进程与资源管理方式。

而 OpenClaw 的运行形态恰好也是：

持续在线；
需要后台守护；
可能长期接收外部消息；
更接近网关，而不是一次性脚本。

所以两者在"系统目标"这一层是对齐的。

第二，OpenCloudOS 9 强调独立演进

这是 OpenCloudOS 一个很值得写进文章里的点。

根据官方 OpenCloudOS 9 文档，其内核与用户态软件是独立演进、自主选择和维护的，不再依赖其他发行版。

这个说法对部署者的意义不是"情怀"，而是：

版本路线更清晰；
对云与服务器场景的优化更主动；
不只是被动跟随别的发行版节奏。

对于长期运行的 OpenClaw 节点来说，这种系统演进方式比"仅仅能装软件"更重要。

第三，底层系统组件比较现代

官方 v9.2 发行说明里可以看到几项非常关键的基础能力：

Kernel 6.1
systemd 251
更完整的 cgroup v2 支持
io_uring
MGLRU
Maple Tree
分层内存支持

这里要注意，文章里不要把这些点写成"用了 OpenCloudOS，OpenClaw 就会性能翻倍"。

更准确的写法是：

这些现代内核与系统组件能力，为长期在线服务、资源隔离、容器场景和稳定运行提供了更好的底座。

也就是说，它们的价值主要体现在系统运行质量与可扩展性上，而不是直接提高大模型回答质量。

第四，云原生与容器相关能力更适合后续扩展

OpenCloudOS 官方发行说明明确强调对云原生基础能力的支持，包括 cgroup v2、容器资源隔离等方向。

如果你现在只是部署最基础的 OpenClaw，这些能力也许还没有立刻"显性体现"；

但如果后面你继续扩展：

接更多消息通道；
跑更多 Skills；
加数据库或附属服务；
对不同组件做资源限制；

那么 OpenCloudOS 这种偏服务器和云原生的底座就会更有优势。

第五，多架构支持有现实成本价值

根据 OpenCloudOS 9 安装文档，系统支持：

AMD / Intel 64 位
ARM 64 位

这对 OpenClaw 这种 API 型架构尤其有意义。

因为当你使用 Kimi 这类云端模型时，服务器本身不承担大模型主推理，而主要承担：

网关控制；
通道连接；
配置管理；
日志与守护；
Skills 调度。

这类任务通常不要求极高算力，因此你完全可以根据云上实例价格来选择更合适的平台，比如更便宜的 ARM 实例，以更低成本维持 OpenClaw 长期在线。

第六，迁移与兼容性思路更适合真实运维环境

OpenCloudOS 官方长期提供 CentOS 迁移相关文档，也在文档中强调兼容性保障、软硬件适配和迁移流程。

这对单机学习用户也许感受不明显，但对真实运维场景很重要，因为它意味着：

团队更容易迁移已有 Linux 经验；
现有软件栈更容易平滑迁移；
系统更新、迁移、兼容性评估有官方资料支撑。

换句话说，OpenCloudOS 的优势不只是"能装起来"，而是"适合纳入长期维护体系"。

4.3 这些优势对 OpenClaw 有什么直接帮助

把上面的系统特性换成 OpenClaw 视角，真正有帮助的点主要有下面几个。

第一，适合做长期在线服务

OpenClaw 的推荐安装路径会把 Gateway 守护化。

而 OpenCloudOS 作为标准服务器 Linux，非常适合长期运行用户级或系统级服务。

这意味着你更容易实现：

开机后自动恢复；
SSH 退出后继续运行；
日志集中查看；
服务状态统一管理。

第二，适合命令行与自动化

OpenClaw 官方推荐的核心入口就是：

bash 复制代码

openclaw onboard --install-daemon

这种基于 CLI 的安装和配置模式，本来就和 Linux 服务器最匹配。

在 OpenCloudOS 上，这套链路和常规运维动作是一致的，不需要额外绕很多弯路。

第三，适合云端消息网关场景

如果你希望 OpenClaw 承载：

机器人接入；
远程自动化；
长期连接的助手网关；
后续扩展的个人智能体能力；

那么服务器操作系统比个人桌面系统更合适。

OpenCloudOS 在这里的价值，是让 OpenClaw 更像一套稳定运行的"个人 AI 基础设施"，而不是临时演示项目。

第四，适合后续扩展和资源治理

随着 OpenClaw 功能变多，你可能会遇到这些需求：

想把某些附属组件单独隔离；
想做容器化；
想限制某些任务资源使用；
想让日志、守护、资源管理更规范。

这些需求本质上都在考验操作系统底座。

OpenCloudOS 在云原生和服务器场景上的能力，会让这些扩展更顺手。

4.4 如何充分利用 OpenCloudOS，而不是只把它当成"能装 Node.js 的 Linux"

很多部署文章最大的问题，是把系统只当成安装介质。

如果你真的想把 OpenCloudOS 用起来，而不是"随便装一下"，建议至少做下面几件事。

第一，用 `systemd` 真正把 OpenClaw 守护起来

OpenClaw 不是前台跑一次就结束的程序，而是常驻型网关。

所以一定要把长期在线当成一等需求来处理。

这也是为什么：

bash 复制代码

openclaw onboard --install-daemon

在这篇教程里不是一个"可选项"，而是核心动作。

第二，启用 lingering，让用户级服务在退出 SSH 后继续运行

如果后续你使用用户级 systemd 服务来运行 OpenClaw，那么可以考虑：

bash 复制代码

sudo loginctl enable-linger $USER

它的意义是：即使用户退出 SSH，会话结束，用户级守护服务仍然可以继续运行。

对于 OpenClaw 这类"人不在线，但助手要在线"的场景非常实用。

第三，用 `journalctl` 和系统日志体系做排障

不要把 OpenClaw 只当成一个命令行程序看待。

一旦它进入长期运行阶段，你应该像维护常规服务器服务一样去看它：

看服务状态；
看日志；
看失败原因；
看重启情况。

这时 OpenCloudOS 提供的标准 Linux 运维工具链就能派上用场。

第四，把 OpenCloudOS 的多架构优势转成成本优势

如果你的模型能力主要来自 Kimi 这类远程 API，那么服务器的主要职责就是控制平面，而不是本地推理。

这意味着你可以优先考虑：

更便宜的实例规格；
更适合长期在线的低成本节点；
合适的 ARM 机型。

这就是把"多架构支持"真正转成部署收益。

第五，后续扩展时优先按"基础设施"思路规划

当你后面给 OpenClaw 继续加：

数据库；
附属服务；
Web 管理层；
外部消息通道；
容器化组件；

建议从一开始就把 OpenCloudOS 当成一层可持续扩展的服务器底座来使用，而不是一次性实验环境。

这样后续增长时不会反复推倒重来。

4.5 本节结论

准确说法不是：

OpenCloudOS 最适合大模型。

而应该是：

OpenCloudOS 很适合承载 OpenClaw 这种需要长期在线的自托管 AI 助手网关。

这两句话差别很大。

前者容易误导，后者才是工程上的真实结论。

5. OpenClaw 的运行原理：Gateway、模型提供商、通道、Skills 分别是什么

如果这一节没有建立清楚，后面配置 Kimi Provider 时就很容易把网关、模型和通道这几个层次混在一起。

5.1 Gateway 是什么

Gateway 可以理解成 OpenClaw 的控制中枢。

它负责：

接收消息；
把消息转给对应的智能体；
调用模型；
再把结果发回通道；
管理运行状态。

所以，Gateway 不是模型本身，而是"模型与外界之间的运行层"。

5.2 模型提供商是什么

模型提供商就是给 OpenClaw 提供 LLM 能力的后端来源。

例如：

OpenAI
Anthropic
Ollama
Moonshot / Kimi

OpenClaw 自己不是大模型。

它只是把不同模型提供商接入进来，再统一编排和调用。

5.3 通道是什么

通道就是用户与 OpenClaw 交互的外部入口，比如：

Telegram
Slack
Discord
飞书
WebChat

通道层负责"消息从哪里进来、结果发到哪里去"。

5.4 Skills 是什么

Skills 可以理解成扩展能力模块。

它们让 OpenClaw 不只是会聊天，而是能做更多事。

所以，OpenClaw 的完整逻辑是：

text 复制代码

用户消息 -> Channel -> Gateway -> 模型提供商 / Skills -> Gateway -> Channel

你一旦理解这一层，就会知道：

Kimi 在这里的角色，是 模型提供商，不是整个 OpenClaw 系统本身。

6. 本文采用的真实部署方案

本文采用的是下面这套部署方案：

系统：腾讯云 OpenCloudOS
运行时：Node.js 24（官方推荐）或 Node.js 22.16+
安装方式：官方推荐的 npm install -g openclaw@latest
初始化方式：官方推荐的 openclaw onboard --install-daemon
模型提供商：Moonshot AI (Kimi)
示例模型：moonshot/kimi-k2.6

这套方案的特点是：

符合 OpenClaw 官方推荐安装路径；
不自己另造一个"伪 OpenClaw"；
Kimi 作为 Provider 接入逻辑清晰；
适合做真正能长期在线的 OpenClaw 部署。

7. 开始前的准备工作

你至少需要准备下面几样东西：

7.1 一台腾讯云服务器

建议：

2 核 CPU
4 GB 内存
40 GB 以上磁盘
OpenCloudOS 9.x

如果只是学习和测试，这个配置够用了。

7.2 服务器公网访问能力

因为你至少要：

安装 Node.js；
安装 OpenClaw；
访问模型提供商接口；
可能后续还要接入消息通道。

7.3 一个 Kimi / Moonshot Open Platform 的 API Key

这里需要提前准备好 API Key。

OpenClaw 负责网关与编排，实际的 LLM 推理由模型提供商完成。

7.4 基本命令行能力

至少要知道：

如何 SSH 登录；
如何编辑文本文件；
如何查看日志。

即使命令行经验不多，也可以按后续步骤逐项完成。

7.5 建议你先确认的三件事

实际安装过程中，前置条件往往比 OpenClaw 本身更容易出问题。

开始安装前，建议先确认下面三件事。

第一，先检查安全组和防火墙

至少要确保：

22 端口允许你当前公网 IP 进行 SSH；
服务器可以访问公网下载依赖；
如果后面要接外部消息通道，再按需开放对应入口。

如果这一步没处理好，后面最典型的问题就是：

SSH 一会儿能登，一会儿不能登；
dnf 能更新一半然后超时；
npm install 卡住；
Provider 测试阶段出现网络超时。

第二，确定你是用 `root` 还是普通用户安装

这篇教程兼容两种方式：

root 直接安装；
普通用户 + sudo 安装。

但更建议使用"普通用户 + sudo"的方式，原因有两点：

后续用户级 systemd 服务更自然；
降低长期直接使用 root 的风险。

如果当前使用的是 root，后面看到 $USER、systemctl --user 这类命令时，需要注意它们与当前登录用户绑定。

第三，提前准备一个能复制粘贴长文本的终端

后面会涉及：

复制 API Key；
粘贴命令；
编辑配置文件；
查看日志输出。

如果你使用的终端工具对复制粘贴支持很差，体验会很痛苦。

在 Windows 上，建议至少使用：

Windows Terminal；
PowerShell + OpenSSH；
或带复制粘贴支持较好的 SSH 客户端。

7.6 本文默认约定

为避免后面命令解释混乱，先统一几个约定：

服务器系统：OpenCloudOS 9.x
当前登录用户：默认记作"当前用户"
需要管理员权限的命令：使用 sudo
代码块中的 你的公网IP、你的Key 都需要替换成你自己的真实值

如果是第一次操作远程 Linux 服务器，建议先记住一条原则：

先确认命令中的固定部分和变量部分，再执行。

8. 第一步：登录腾讯云 OpenCloudOS 并完成基础初始化

通过 SSH 登录服务器：

bash 复制代码

ssh root@你的公网IP

如果你使用的是普通用户加 sudo，也可以：

bash 复制代码

ssh your_user@你的公网IP

如果是第一次接触云服务器，可以把这一步理解成：

你在本地电脑上打开一个远程终端；
这个终端连接到了腾讯云上的 OpenCloudOS；
后面所有安装动作，都是在这台云服务器里执行。

8.0 本节完成后，你应该达到什么状态

在继续下一节之前，请确认你已经做到：

能稳定登录服务器；
知道自己当前是 root 还是普通用户；
系统能正常联网；
能执行 sudo 命令（如果你不是 root）。

8.1 确认系统信息

bash 复制代码

cat /etc/os-release
uname -r

你应该能看到 OpenCloudOS 相关版本信息。

例如，你重点看的是：

/etc/os-release 里是否出现 OpenCloudOS
uname -r 是否能正常输出内核版本

如果这里显示的根本不是 OpenCloudOS，那么整篇教程里关于 dnf、系统行为和运维方式的描述都可能要调整。

8.2 更新软件包索引与系统组件

bash 复制代码

sudo dnf update -y

为什么先更新？

避免仓库元数据过旧；
避免 Node.js 安装过程中依赖冲突；
后续安装 curl、git 等工具更顺畅。

如果执行过程中你遇到：

仓库连接超时；
DNS 解析失败；
某个镜像源连接失败；

不要急着继续后面的 Node 安装。

因为这通常说明服务器联网环境本身就还没有准备好。

8.3 安装基础工具

bash 复制代码

sudo dnf install -y curl git tar xz

这些工具分别用于：

curl：下载脚本和检查接口
git：源码与版本管理相关操作
tar / xz：解压缩工具，很多安装流程会间接使用

建议顺手再执行一条命令确认工具已经安装成功：

bash 复制代码

curl --version
git --version

如果这些命令都能正常输出版本号，说明基础环境已经就绪。

9. 第二步：安装 Node.js 运行时与常用工具

根据 OpenClaw 官方安装文档，推荐使用 Node 24，兼容下限为 Node 22.16+。

9.1 为什么这里必须是 Node.js，而不是 Python

因为 OpenClaw 本体是 Node 生态下的 CLI/网关程序。

它不是我们自己用 Python 现写一个后端。

也就是说：

你接入 Kimi 并不意味着你要写 Python；
你部署 OpenClaw，本质上是在部署一个 Node 应用。

9.2 安装 Node.js

如果你希望按最透明的方式手动安装，可以这样做：

bash 复制代码

curl -fsSL https://rpm.nodesource.com/setup_24.x | sudo bash -
sudo dnf install -y nodejs

这两条命令的作用并不相同。

第 1 条命令做了什么

bash 复制代码

curl -fsSL https://rpm.nodesource.com/setup_24.x | sudo bash -

它的作用是：

从 NodeSource 拉取 Node 24 的仓库配置脚本；
在系统里注册对应的软件源；
让后续 dnf install nodejs 能安装到符合要求的 Node 版本。

这里的 | sudo bash - 表示把前面下载到的脚本直接交给 bash 执行。

第 2 条命令做了什么

bash 复制代码

sudo dnf install -y nodejs

这一步才是真正安装：

node
npm
以及它们所需的相关组件

前一条负责配置软件源，后一条负责安装 Node.js。

安装完成后检查版本：

bash 复制代码

node -v
npm -v

预期是：

node 为 v24.x 左右，或者至少 22.16+
npm 正常输出版本号

9.3 如果这里安装失败，通常是哪一类问题

最常见的是下面三类：

第一，网络问题

表现通常是：

curl 卡住；
setup_24.x 拉取失败；
dnf install 超时。

这类问题通常与 OpenClaw 无关，而是服务器访问外部仓库存在异常。

第二，系统源或依赖冲突

如果你的机器不是很干净，或者之前装过别的 Node 版本，可能会出现包冲突。

这时建议先确认：

bash 复制代码

node -v
which node
rpm -qa | grep node

先看系统里是否已经存在旧版 Node。

第三，版本虽然装上了，但 PATH 不对

如果安装完成后 node -v 仍然提示找不到命令，说明要么安装没成功，要么可执行文件不在当前 PATH 里。

9.4 为什么不直接跳过这一步

因为 OpenClaw 的官方安装本质上就是：

bash 复制代码

npm install -g openclaw@latest

没有合适的 Node 运行时，后面就无从谈起。

9.5 到这一节结束时，你应该检查什么

继续之前，请至少确认以下命令都能正常执行：

bash 复制代码

node -v
npm -v
which node
which npm

只有当这四项都没有问题，后面的 OpenClaw 安装才值得继续。

10. 第三步：安装 OpenClaw 本体

这里我们采用官方 README 里给出的推荐安装方式。

bash 复制代码

sudo npm install -g openclaw@latest

这里的几个关键词需要先理解：

npm：Node 包管理器
install -g：全局安装，安装后命令对整个系统当前用户环境可用
openclaw@latest：安装 OpenClaw 的最新版本

对初学者来说，可以把这一步理解成：

不是下载源码自己编译；
也不是手工拼环境变量；
而是用官方发布的 npm 包，直接把 OpenClaw CLI 安装到系统里。

安装完以后，先确认命令是否存在：

bash 复制代码

openclaw --version

如果能输出版本号，说明 OpenClaw CLI 已经安装成功。

10.1 安装时为什么很多教程前面都带 `sudo`

因为 npm install -g 默认会写入全局目录。

在很多 Linux 发行版中，这个目录需要管理员权限，所以前面常带 sudo。

这也意味着你要有一个清晰认识：

用 sudo npm install -g 安装的是系统级全局命令；
后面如果普通用户找不到命令，通常是 PATH、权限或安装目录问题，而不是 OpenClaw "没装上"。

10.2 安装成功后建议立刻做的三项检查

除了 openclaw --version，建议再执行：

bash 复制代码

which openclaw
npm list -g --depth=0 | grep openclaw

你需要确认三件事：

openclaw 命令是否在 PATH 中；
npm 全局包里是否真的出现了 openclaw；
当前 shell 调用到的是不是刚刚装上的那个版本。

10.3 为什么这里是"安装 OpenClaw 本体"

因为从这一刻开始，你机器上装的不是某个自写的聊天后端，而是真正的 OpenClaw CLI 和 Gateway 相关能力。

安装完成后，后续配置都应围绕官方 CLI 展开，而不是额外再写一套运行框架。

10.4 如果这里报错，先看哪几个方向

常见错误包括：

权限不足；
npm 仓库访问失败；
Node 版本过低；
全局安装目录不可写。

优先检查：

bash 复制代码

node -v
npm -v
npm config get prefix

这三项检查通常足以先区分"运行时问题"和"npm 全局安装问题"。

11. 第四步：为什么 OpenClaw 的官方推荐入口是 `openclaw onboard`

OpenClaw 官方 README 与安装文档都反复强调一个命令：

bash 复制代码

openclaw onboard --install-daemon

这个命令的重要性远远高于单纯的"安装包"。

11.1 `onboard` 不是普通 setup，它是配置编排入口

它之所以重要，是因为 OpenClaw 不是一个只有单一配置项的小工具。

它至少涉及这些维度：

Gateway 初始化；
模型提供商选择；
身份认证；
默认模型配置；
工作区与运行目录；
通道与技能初始化；
守护进程安装。

如果你把这些都拆开手动配置，复杂度会很高。

所以官方把它收束到 onboard 这个统一入口。

11.2 `--install-daemon` 是什么意思

这个参数的含义不是"多装一个功能"，而是：

在初始化时顺手把 Gateway 守护化，让它可以作为后台服务长期运行。

这正对应了 OpenClaw 的部署目标：

它不是一次性脚本，而是需要长期在线运行的智能体网关。

因此，--install-daemon 就是把"长期在线能力"落地的关键一步。

11.3 为什么本教程不建议你一上来就手改所有配置

对熟悉 Linux 和 OpenClaw 的用户来说，手工改配置文件当然可行。

但对小白而言，直接手改通常会同时引入三类风险：

不知道配置文件真正生效的位置；
不知道配置项之间有没有依赖关系；
改完以后不知道该如何验证。

而 openclaw onboard 的价值就在于：

用统一向导生成初始配置；
尽量减少漏项；
顺手把守护服务装好；
让你先获得一个可运行的初始系统，再逐步精调。

12. 第五步：用 Kimi 作为 OpenClaw 的模型提供商

这一部分的作用是明确 OpenClaw 与 Kimi 在系统中的职责边界。

12.1 先把术语分清

在 OpenClaw 的语境里：

OpenClaw 是智能体网关；
Kimi / Moonshot 是模型提供商；
Kimi API Key 是认证材料；
moonshot/kimi-k2.6 这种字符串是模型引用。

所以准确说法不是：

我在部署 Kimi。

而是：

我在 OpenClaw 中选择 Moonshot 作为 Provider，并把 Kimi 模型配置为默认模型。

12.2 为什么这里要写 Moonshot 而不是随便写 Kimi

根据 OpenClaw 官方 docs/providers/moonshot.md，Moonshot Open Platform 提供的是 Kimi API 的 OpenAI-compatible endpoint，官方推荐模型引用写法是：

text 复制代码

moonshot/kimi-k2.6

并且官方文档明确区分了：

Moonshot Provider
Kimi Coding Provider

二者：

Key 不互通；
Endpoint 不同；
Model ref 不同。

因此，这里不能简单理解为"填一个 Kimi Key 就完成配置"。

如果 Provider 这一层没有区分清楚，后面的配置就容易出错。

12.3 国际端点与国内端点

官方 Moonshot 文档还给出了两类端点：

国际端点：

text 复制代码

https://api.moonshot.ai/v1

中国端点：

text 复制代码

https://api.moonshot.cn/v1

如果你用的是国际 Open Platform，就按国际端点；

如果你明确在中国区对应端点获取和使用 Key，就按中国端点。

这里一定要记住：

Key、端点、Provider 选择必须匹配。

12.4 一个最容易犯错的地方：把品牌名、平台名和 Provider 名混为一谈

实践中常见的混淆点主要在下面几个层级：

Kimi：你感知到的模型品牌
Moonshot Open Platform：你申请 API Key 的平台
moonshot：OpenClaw 里的 Provider 名
moonshot/kimi-k2.6：最终调用时的模型引用

这四层一旦混掉，配置时就会出现"我明明填了 Kimi Key，为什么还是不通"的错觉。

实际上，错往往不在 Key 本身，而在于：

Provider 选错；
端点选错；
模型引用写错；
账号区域和平台不匹配。

13. 第六步：理解 Kimi API 的关键配置项

这一节说明 Kimi API 在 OpenClaw 架构中的位置，以及为什么配置工作不止于填写 Key。

13.1 API Key 的作用是什么

API Key 的本质是访问凭证。

它告诉 Moonshot：

你是谁；
你有权访问哪些模型；
当前调用应该记到哪个账户下。

所以，API Key 不是"模型本身"，只是进入模型服务的门票。

13.2 Base URL 为什么重要

很多人只记住要填 Key，却忽略了：

请求往哪发；
发给哪个 Provider；
使用哪个 endpoint。

这就是 base_url 的意义。

如果 base_url 和 Key 所属平台不匹配，结果通常就是：

401
404
model not found
provider auth failed

13.3 Model Ref 为什么不能乱写

在 OpenClaw 里，模型不是只写个裸名字，而是 Provider-aware 的引用格式，例如：

text 复制代码

moonshot/kimi-k2.6

这是一种"提供商/模型"的复合标识。

它告诉 OpenClaw：

要用哪个 Provider；
要请求哪个模型。

所以模型引用写错，本质上不是"拼写问题"，而是调度路径错了。

13.4 为什么说这一步体现了"引擎搭建"

因为 OpenClaw 不是直接把"用户问题"扔给 Kimi。

它实际做的是：

读取本地配置；
判断默认 Provider；
判断默认模型；
取环境变量或配置里的 API Key；
组织请求；
调用模型；
再把结果返回给 Gateway 或通道。

这就是"应用引擎层"的意义。

OpenClaw 在这里承担的是 模型编排与运行框架 的角色。

13.5 这一节结束后，你应该建立的正确理解

读到这里，最好能建立下面这条调用链路：

text 复制代码

OpenClaw -> 读取本地配置 -> 识别 moonshot Provider -> 使用正确端点 -> 携带 MOONSHOT_API_KEY -> 调用 kimi 模型

把这条链路理顺之后，后面的向导配置和排错会清晰很多。

14. 第七步：运行 OpenClaw Onboarding 向导

现在开始正式初始化。

运行：

bash 复制代码

openclaw onboard --install-daemon

第一次运行时，可以把这一步视为初始化向导。

它负责把"机器上已有 OpenClaw CLI"推进到"系统已经具备可工作的初始环境"。

根据 OpenClaw 官方文档，向导会一步步引导你完成：

Gateway 配置；
Workspace 初始化；
模型提供商配置；
身份认证；
守护安装。

14.0 运行前的建议

执行命令前，建议先准备好：

你的 Moonshot / Kimi API Key；
你准备使用的端点类型（.ai 还是 .cn）；
你希望默认使用的模型名；
一个稳定的 SSH 会话，不要在中途断开。

14.1 如果你明确要用 Moonshot/Kimi

你可以优先选择 Moonshot 相关 auth choice。

根据官方 Moonshot 文档，常见的是：

国际端点：moonshot-api-key
中国端点：moonshot-api-key-cn

例如国际端点可以这样走：

bash 复制代码

openclaw onboard --auth-choice moonshot-api-key

如果是中国端点：

bash 复制代码

openclaw onboard --auth-choice moonshot-api-key-cn

14.2 向导过程中你大概会配置什么

你需要关注这些关键项：

第一，模型提供商

选择 Moonshot。

第二，API Key

填入你的真实 Moonshot / Kimi Open Platform Key。

第三，默认模型

优先选择：

text 复制代码

moonshot/kimi-k2.6

第四，是否安装守护进程

建议保留 --install-daemon 路径，让 OpenClaw 以后台服务方式运行。

14.3 小白视角下，向导里每一类问题你应该怎么理解

为了便于理解交互提示，这里把常见问题按类别拆开说明。

第一类：工作区或目录相关

它本质上是在问：

配置和运行数据放在哪；
这个 OpenClaw 实例以哪个目录为家。

如果你没有特殊需求，通常保持默认即可。

第二类：认证方式相关

它本质上是在问：

你打算接哪个模型平台；
这个平台使用哪种认证方式；
你现在准备用哪个 Key。

如果你的目标非常明确就是 Kimi，那么就优先围绕 moonshot 相关 auth choice 走。

第三类：默认模型相关

它本质上是在问：

后续不额外指定模型时，系统默认用谁。

如果你填的是：

text 复制代码

moonshot/kimi-k2.6

那么后面很多默认测试都会自动落到这个模型上。

第四类：守护安装相关

它本质上是在问：

你希望 OpenClaw 只在当前 shell 里运行；
还是作为长期后台服务运行。

对云服务器部署来说，答案通常应该是后者。

14.4 跑完向导后，你应该立刻确认什么

不要一跑完就直接关 SSH。

建议先确认：

向导有没有报错；
Provider 配置是否写入成功；
默认模型是否是你预期的 Kimi 模型；
守护服务是否真的被安装。

15. 第八步：如果你想手动检查配置文件

即使你已经跑完了向导，也建议理解一下配置层长什么样。

OpenClaw 官方文档中给出的 Moonshot 示例配置思路大致类似：

json5 复制代码

{
  env: {
    MOONSHOT_API_KEY: "sk-..."
  },
  agents: {
    defaults: {
      model: {
        primary: "moonshot/kimi-k2.6"
      }
    }
  }
}

这里展示的是示意结构，不要求逐字照抄到固定路径。

重点在于理解：OpenClaw 的配置通常至少会把"凭证"和"默认模型"这两层绑定起来。

你要从这个例子里读出三层意思：

15.1 `env` 层

这里代表运行时需要的环境变量。

最关键的是：

text 复制代码

MOONSHOT_API_KEY

15.2 `agents.defaults.model.primary`

这里是在告诉 OpenClaw：

默认主模型用哪一个。

所以如果这里写成：

text 复制代码

moonshot/kimi-k2.6

那 OpenClaw 的默认推理入口就会落到 Kimi K2.6。

15.3 配置的本质是什么

配置不是"死记格式"，而是把三件事绑定起来：

用哪个 Provider；
Provider 的凭证是什么；
默认模型是什么。

因此，API 配置并不是"复制一个 Key 粘贴一下"那么简单。

15.4 手动检查时建议你采用什么思路

手动查看配置时，不必先记忆完整格式。

更实用的做法是按下面的顺序检查：

有没有 MOONSHOT_API_KEY
默认模型是不是 moonshot/kimi-k2.6
Provider 层是不是明确指向 moonshot
修改后有没有重新让 OpenClaw 读取到新配置

这样排查问题会比死记配置结构更高效。

16. 第九步：验证 Kimi 模型是否真的接通

完成配置后，必须进行连通性验证。

16.1 列出 Moonshot Provider 下可用模型

官方文档给出的检查方式是：

bash 复制代码

openclaw models list --provider moonshot

如果配置成功，你应该能看到类似：

moonshot/kimi-k2.6
moonshot/kimi-k2.5
moonshot/kimi-k2-thinking

这样的模型引用。

16.2 做一个最小消息测试

你可以直接用 OpenClaw CLI 让它发起一次模型调用，例如：

bash 复制代码

openclaw agent --message "请只回复：KIMI_OK" --thinking off

如果返回正常内容，说明至少：

OpenClaw CLI 正常；
Provider 认证正常；
模型配置正常；
调用链路通了。

这里需要区分两件事：

"命令执行了"并不等于"模型已经接通"。

你要看的不是命令有没有输出，而是：

有没有真正返回模型回答；
有没有明显的 Provider 错误；
有没有鉴权错误；
返回的 Provider / Model 是否符合预期。

16.3 如果你想更严格一点

Moonshot 文档里还给了 JSON 模式的 live smoke test 思路。

你也可以用更可检验的方式做测试：

bash 复制代码

openclaw agent --local --session-id kimi-smoke --message "Reply exactly: KIMI_LIVE_OK" --thinking off --json

你重点看两件事：

返回内容是否正常；
输出里 Provider/Model 是否落在 moonshot / kimi-k2.6。

16.4 如果测试失败，优先按什么顺序排查

建议按下面顺序排查，不要同时改动多个变量：

openclaw --version 是否正常
openclaw models list --provider moonshot 是否正常
API Key 是否正确
端点和区域是否匹配
默认模型名是否正确

这个顺序的好处是：从"本地 CLI 是否正常"一路排到"远端 Provider 是否正常"，思路更清楚。

17. 第十步：让 OpenClaw 在服务器上长期在线

这一节对应的是本文部署目标中的"长期在线"部分。

17.1 `--install-daemon` 做了什么

根据官方 README，openclaw onboard --install-daemon 会安装 Gateway daemon。

在 Linux 上，本质上就是用户级 systemd 服务。

这意味着它可以脱离你当前 shell 持续运行。

17.2 为什么用户级 systemd 服务适合这个场景

因为它很好地匹配了 OpenClaw 的运行特征：

长时间在线；
不依赖你手工盯着一个终端；
有日志；
有重启与状态管理能力。

17.3 如何检查服务有没有装上

因为不同版本和安装方式下具体 unit 名称可能演进，最稳妥的检查方式是先列出相关用户服务：

bash 复制代码

systemctl --user list-units | grep openclaw

如果你想看用户级日志：

bash 复制代码

journalctl --user -f | grep openclaw

你可以把这两条命令理解成两种观察视角：

systemctl --user list-units | grep openclaw：看"服务在不在"
journalctl --user -f | grep openclaw：看"服务现在在干什么"

前者偏状态，后者偏过程。

17.4 为什么在云服务器上要考虑 lingering

用户级 systemd 服务在 Linux 上通常和用户会话有关。

如果你希望它在没有交互登录会话时也长期运行，可以启用 lingering：

bash 复制代码

sudo loginctl enable-linger $USER

这个命令的意义是：

即使你退出 SSH，会话结束，用户级 systemd 也能继续保活相关服务。

这一点非常适合 OpenClaw 这种"你人不在线，但助手要在线"的场景。

17.5 建议你在这一节最后做一次完整闭环验证

最稳妥的方式是：

确认服务存在
看一眼实时日志
退出 SSH
重新登录
再次检查服务和日志

如果重新登录后服务仍在、日志仍正常，说明长期在线运行已经生效。

17.6 安全防护：OpenClaw 部署时真正需要注意什么

到这里还需要补上一层现实问题：

OpenClaw + 云服务器 + 外部模型 API + 消息通道 这种组合，本身就属于"持续在线的自托管网关"场景。

网络上有人说这类系统"不安全"，通常不是指某一个命令本身危险，而是指下面这些风险如果不控制，整套系统就会暴露出比较大的攻击面。

17.6.1 风险到底来自哪里

在这个部署模型里，风险主要来自五个方向：

服务器暴露面
包括 SSH 暴露、开放了不必要端口、弱口令、长期使用 root 等。
API Key 泄露
一旦 Moonshot / Kimi 的 Key 被泄露，最直接的后果通常是额度被盗刷，严重时还会造成调用记录和业务数据泄露。
消息通道接入风险
如果后续接入 Telegram、Discord、Slack、飞书等通道，攻击面会从"单台服务器"扩展到"公网消息入口"。
技能或工具调用风险
任何具备文件访问、命令执行、网络访问能力的技能，都会扩大系统权限边界。
运维松散导致的长期风险
例如系统长期不更新、日志不看、密钥不轮换、服务异常后无人发现。

因此，问题并不在于"OpenClaw 天生不安全"，而在于这类系统属于持续在线的自动化网关，安全要求天然高于普通静态网站或一次性脚本。

17.6.2 最重要的一条原则：最小暴露面

对大多数个人或轻量部署场景来说，最有效的安全策略不是一开始堆很多复杂组件，而是先把暴露面缩到最小。

建议按下面的原则执行：

只开放必须的端口
- 通常只保留 SSH 所需端口；
- 如果暂时没有公网 Web 面板需求，就不要额外开放 HTTP/HTTPS；
- 如果后面要接 webhook，再按需单独开放对应端口和路径。
没有必要就不要对公网暴露 OpenClaw 内部服务
- 很多组件完全可以只在本机回环地址 127.0.0.1 上监听；
- 外部访问必须经过明确的反向代理或受控入口。
先做出站调用，再考虑入站接入
- OpenClaw 调 Kimi API 属于出站访问；
- 出站本身风险相对更可控；
- 一旦引入公网入站接口，安全要求会显著提高。

这条原则的核心思想很简单：

能不暴露就不暴露，能少暴露就少暴露。

17.6.3 SSH 与服务器登录安全

这是最基础也是最容易被忽略的一层。

建议至少做到下面几项：

优先使用 SSH 密钥登录，不要长期依赖密码登录
尽量不用 root 直接长期运维
限制安全组来源 IP
- 最好只允许你自己的固定公网 IP 访问 SSH；
- 如果必须临时放开，操作结束后再收紧。
修改默认 SSH 端口不是核心安全措施
- 改端口只能降低扫描噪声，不能替代密钥认证和来源 IP 限制；
- 真正有效的是认证方式和访问控制。

如果希望进一步收紧，可以考虑检查 SSH 配置中的这些方向：

是否禁用密码登录；
是否禁止 root 直接远程登录；
是否限制可登录用户；
是否启用失败登录监控。

17.6.4 API Key 的保护方式

Kimi API Key 是这套系统里最敏感的秘密之一。

保护不当时，最先出问题的通常不是服务器被拿下，而是 Key 被复制、滥用、刷额度。

建议采用下面的做法：

不要把真实 API Key 写进公开仓库
不要把 API Key 直接写进博客截图、终端截图或演示视频
不要把 Key 写死在前端代码里
尽量放在环境变量或受控配置文件中
控制配置文件权限
- 如果配置文件中包含密钥，建议只有当前运行用户可读。

如果需要排查问题，也不要把完整 Key 打到日志里。

日志里最多保留前后几位用于识别，完整值不要输出。

17.6.5 运行用户与权限边界

从部署角度看，最容易出事的一种情况是：

服务长期以高权限运行，同时又能接收外部输入。

因此，建议：

尽量用普通用户运行 OpenClaw
仅在安装依赖时使用 sudo
不要让 OpenClaw 默认拥有不必要的系统级写权限
如果后续增加技能，优先评估它是否真的需要文件写入、命令执行或网络访问权限

这一条和"不要长期直接使用 root"是同一个思路：

即使出现问题，也尽量把影响范围限制在当前服务用户的权限边界内。

17.6.6 通道、Webhook 与公网入口的防护

如果后续只是用 OpenClaw 调用 Kimi API，而不接入任何公网消息通道，那么安全复杂度其实还比较可控。

真正的风险上升，通常发生在接入这些能力之后：

Telegram Bot
Discord Bot
Slack App
飞书机器人
Webhook 回调接口

一旦引入这些入口，建议同步考虑：

请求来源校验；
回调签名验证；
路径最小暴露；
速率限制；
明确的日志审计。

如果某个通道官方支持签名校验或 token 验证，建议默认开启，不要省略。

17.6.7 OpenCloudOS 上可以利用哪些系统能力做防护

OpenCloudOS 作为服务器系统，本身就提供了不少可利用的安全基础设施。

在这篇教程对应的场景里，最实用的是下面几类。

第一，安全组和系统防火墙

腾讯云安全组负责最外层入口控制；
系统防火墙负责主机内的进一步收口；
两层配合比只依赖其中一层更稳妥。

第二，用户级 systemd

用普通用户运行服务，本身就是一种权限收敛；
服务状态、重启和日志更清晰；
不需要为了"长期在线"把所有东西都跑成 root 进程。

第三，journalctl 日志体系

方便排查异常调用；
可以识别是否存在频繁失败重试；
可以观察是否有异常 Provider 调用或服务崩溃循环。

第四，SELinux（如果你的部署策略允许）

如果你对 Linux 安全策略比较熟悉，可以进一步研究 SELinux 的约束能力。

不过对于初次部署者来说，优先级更高的仍然是：

先控制暴露面；
再控制权限；
最后再考虑更细粒度的强制访问控制。

17.6.8 最实用的上线前检查清单

如果准备把这套服务长期放在云端，建议在正式使用前至少检查下面这些项目：

17.6.9 一句话总结这一节

对 OpenClaw 这类系统来说，安全防护的重点并不是"某一个神奇参数"，而是四件事：

入口收紧；
权限最小；
密钥保护；
持续运维。

把这四件事做好，风险会比"把服务直接扔到公网然后长期不管"低很多。

完成前面的步骤后，系统已经不再是单纯的 API 调用示例，而是一套具备持续运行能力的个人 AI 助手底座：

18.1 你得到的是一个常驻网关

它可以长期在线，不依赖本地电脑开机。

18.2 你得到的是一个可切换模型提供商的智能体框架

今天你用 Kimi，明天你完全可以换 OpenAI、Anthropic、Ollama。

OpenClaw 的价值之一就是把 Provider 层抽象出来了。

18.3 你得到的是一个可以继续长大的个人 AI 助手底座

后面你可以继续加：

飞书 / Telegram / Discord 通道；
Skills；
记忆；
自动化任务；
定时提醒；
更复杂的代理行为。

18.4 你得到的是比"调 API"更完整的工程结构

"调 API"只是最里面的一层。

进入实际使用阶段后，还需要下面这些层次：

运行时；
配置层；
网关层；
守护层；
通道层；
Provider 层。

OpenClaw 把这些部分组合起来，才形成完整的个人 AI 助手系统。

19. 常见问题与排错建议

19.1 `openclaw: command not found`

说明全局安装路径没进当前 shell 的 PATH，或者 npm 全局安装失败。

优先检查：

bash 复制代码

npm prefix -g
npm root -g
which openclaw

19.2 Node 版本不符合要求

如果 node -v 太低，OpenClaw 可能安装后也无法正常运行。

优先回到第 9 节，把 Node 提升到官方推荐版本。

19.3 Kimi Key 配了，但模型还是调用失败

优先检查下面三件事是否匹配：

Key 是否来自 Moonshot Open Platform；
你选的是 moonshot Provider 还是别的 Provider；
端点到底应该是 .ai 还是 .cn。

19.4 `model not found`

大概率是：

模型 ref 写错；
Provider 不匹配；
当前账号或区域不支持该模型。

先用：

bash 复制代码

openclaw models list --provider moonshot

确认当前实际可用模型。

19.5 为什么我感觉"装完了但还没看到界面"

因为 OpenClaw 的核心不是"网页聊天框"，而是 Gateway + 通道 + Provider。

它首先是一个智能体运行框架，而不是先给你一个固定的 Web 面板。

如果你期待的是"打开浏览器就有聊天网页"，那是另一类产品形态；

而 OpenClaw 的核心优势在于：

接入现有消息渠道；
作为长期在线的个人 AI 网关运行。

19.6 什么时候不建议上云部署

如果你只是：

临时试验；
本地玩玩；
不想让它长期在线；
不需要消息通道；

那本地安装更简单。

云部署真正适合的是"长期在线 + 稳定运行 + 远程接入"的场景。

20. 全文复盘

把全文梳理一遍，可以归纳为下面四层：

第一层：为什么要用 OpenCloudOS

不是为了让模型更聪明，而是为了让 OpenClaw 这个长期在线的 AI 助手网关更稳定、更适合长期运行。

第二层：为什么不是自己手写一个聊天后端

因为 OpenClaw 本身就是一个完整的开源个人 AI 助手框架。

如果你要部署 OpenClaw，就应该围绕它自己的官方安装路径和运行方式来做。

第三层：Kimi 在这里扮演什么角色

Kimi 不是整个系统，而是 OpenClaw 的模型提供商之一。

它通过 Moonshot Provider 接入，典型模型引用是：

text 复制代码

moonshot/kimi-k2.6

第四层：为什么这件事适合放到服务器上

因为 OpenClaw 的真实价值在于：

长期在线；
常驻守护；
接入消息通道；
成为你的个人 AI 网关。

而这正是云上 OpenCloudOS 擅长承载的场景。

所以，更准确的一句话总结全文应该是：

在腾讯云 OpenCloudOS 上部署 OpenClaw，目的不是简单包装一次 Kimi 调用，而是把一个自托管、可长期在线的个人 AI 助手网关部署到稳定的服务器环境中，再由 Kimi API 提供模型能力。

参考资料

OpenClaw 官方 README

https://github.com/openclaw/openclaw/blob/main/README.md
OpenClaw 安装文档

https://github.com/openclaw/openclaw/blob/main/docs/install/index.md
OpenClaw 安装器说明

https://github.com/openclaw/openclaw/blob/main/docs/install/installer.md
OpenClaw Moonshot / Kimi Provider 文档

https://github.com/openclaw/openclaw/blob/main/docs/providers/moonshot.md
OpenCloudOS 官方安装文档

https://docs.opencloudos.org/en/OC9/install/V9_install/

腾讯云OpenCloudOS部署OpenClaw并接入Kimi_API全流程教程

目录

1. 为什么在 OpenCloudOS 上部署 OpenClaw

1.1 问题背景

1.2 OpenClaw 的运行特征决定了部署方式

1.3 本地运行与云端部署的区别

1.4 OpenCloudOS 在这里扮演的真实角色

2. OpenClaw 的定位与运行形态

2.1 OpenClaw 不是简单的网页聊天壳

2.2 OpenClaw 更接近什么类型的系统

2.3 为什么要先明确这个边界

3. 为什么选择云服务器而不是本地常驻

3.1 对 OpenClaw 而言，持续在线比"能启动"更重要

3.2 云服务器的价值主要体现在可用性

3.3 在服务器场景下，OpenClaw 更接近完整的运行基础设施

4. 为什么偏偏选 OpenCloudOS，而不是随便一个 Linux

4.1 选择 OpenCloudOS 的现实原因

4.2 OpenCloudOS 自身有哪些可验证的系统优势

第一，系统定位就是面向服务器和云场景

第二，OpenCloudOS 9 强调独立演进

第三，底层系统组件比较现代

第四，云原生与容器相关能力更适合后续扩展

第五，多架构支持有现实成本价值

第六，迁移与兼容性思路更适合真实运维环境

4.3 这些优势对 OpenClaw 有什么直接帮助

第一，适合做长期在线服务

第二，适合命令行与自动化

第三，适合云端消息网关场景

第四，适合后续扩展和资源治理

4.4 如何充分利用 OpenCloudOS，而不是只把它当成"能装 Node.js 的 Linux"

第一，用 systemd 真正把 OpenClaw 守护起来

第二，启用 lingering，让用户级服务在退出 SSH 后继续运行

第三，用 journalctl 和系统日志体系做排障

第四，把 OpenCloudOS 的多架构优势转成成本优势

第五，后续扩展时优先按"基础设施"思路规划

4.5 本节结论

5. OpenClaw 的运行原理：Gateway、模型提供商、通道、Skills 分别是什么

5.1 Gateway 是什么

5.2 模型提供商是什么

5.3 通道是什么

5.4 Skills 是什么

6. 本文采用的真实部署方案

7. 开始前的准备工作

7.1 一台腾讯云服务器

7.2 服务器公网访问能力

7.3 一个 Kimi / Moonshot Open Platform 的 API Key

7.4 基本命令行能力

7.5 建议你先确认的三件事

第一，先检查安全组和防火墙

第二，确定你是用 root 还是普通用户安装

第三，提前准备一个能复制粘贴长文本的终端

7.6 本文默认约定

8. 第一步：登录腾讯云 OpenCloudOS 并完成基础初始化

8.0 本节完成后，你应该达到什么状态

8.1 确认系统信息

8.2 更新软件包索引与系统组件

8.3 安装基础工具

9. 第二步：安装 Node.js 运行时与常用工具

9.1 为什么这里必须是 Node.js，而不是 Python

9.2 安装 Node.js

第 1 条命令做了什么

第 2 条命令做了什么

9.3 如果这里安装失败，通常是哪一类问题

第一，网络问题

第二，系统源或依赖冲突

第三，版本虽然装上了，但 PATH 不对

9.4 为什么不直接跳过这一步

9.5 到这一节结束时，你应该检查什么

10. 第三步：安装 OpenClaw 本体

10.1 安装时为什么很多教程前面都带 sudo

10.2 安装成功后建议立刻做的三项检查

10.3 为什么这里是"安装 OpenClaw 本体"

10.4 如果这里报错，先看哪几个方向

11. 第四步：为什么 OpenClaw 的官方推荐入口是 openclaw onboard

11.1 onboard 不是普通 setup，它是配置编排入口

11.2 --install-daemon 是什么意思

11.3 为什么本教程不建议你一上来就手改所有配置

12. 第五步：用 Kimi 作为 OpenClaw 的模型提供商

12.1 先把术语分清

12.2 为什么这里要写 Moonshot 而不是随便写 Kimi

第一，用 `systemd` 真正把 OpenClaw 守护起来

第三，用 `journalctl` 和系统日志体系做排障

第二，确定你是用 `root` 还是普通用户安装

10.1 安装时为什么很多教程前面都带 `sudo`

11. 第四步：为什么 OpenClaw 的官方推荐入口是 `openclaw onboard`

11.1 `onboard` 不是普通 setup，它是配置编排入口

11.2 `--install-daemon` 是什么意思

15.1 `env` 层

15.2 `agents.defaults.model.primary`

17.1 `--install-daemon` 做了什么

19.1 `openclaw: command not found`

19.4 `model not found`