企业官网建设流程全解析

OpenClaw 这个项目我从年初一直折腾到现在，中间经历了好几轮版本重写。标题写成“终章”不是说项目没了，而是我想把这一阶段的使用心得收个尾：从 Windows Companion 到 WSL2 环境校验，从 Node.js 安装到 Ollama 本地模型，从 Termux 手机部署到 skill 编写，能踩的坑基本都踩了一遍。如果你正准备入坑，这篇总结应该能直接帮你跳过大部分弯路。

先给还没接触过 OpenClaw 的朋友一句话概括：它是一个开源的个人 AI 助手运行框架。它不是又一个聊天机器人壳子，而是一个能对接聊天平台、能调用本地模型、能通过“技能（skill）”执行实际操作的自动化入口。你可以把它理解成一个自带脚手架的 AI 管家：模型负责理解，OpenClaw 负责行动，skill 负责具体干活。

1. OpenClaw 是什么：它不是又一个聊天机器人壳子

1.1 我对 OpenClaw 的核心定位

第一次看到 OpenClaw 的仓库时，我差点把它当成又一个套壳聊天机器人。真正用下来才发现，它解决的问题不是“怎么聊”，而是“聊完以后怎么落地”。

举个例子。普通的聊天机器人接入大模型 API 后，你问它“上海明天会不会下雨”，它能给你一段文字回复。但 OpenClaw 多了一层执行能力：它可以调用一个 weather skill，去查询天气接口，把结果格式化后发回给你；如果配合日程 skill，它还能根据天气帮你调整明天的出行计划。这个“从文本回复到实际动作”的转变，才是 OpenClaw 真正想做的事情。

所以它更适合的人其实是这么几类：

• 有一定命令行基础，想自己搭建 AI 助手的技术爱好者。
• 希望数据留在本机、不愿意把聊天记录大量上传到云端的人。
• 手里有多条对接渠道（Telegram、群聊、本地终端、手机 Termux），想用一个统一入口管理的人。
• 想给 AI 助手写自定义工具，又不打算从零造轮子的人。

如果你只是想要一个能对话的窗口，OpenClaw 反而有点大材小用。同类图形界面工具能耗更低，体验也更顺滑。OpenClaw 的优势在于“连接”和“自动化”，而不是“聊天 UI”。

1.2 为什么值得折腾

我最初被 OpenClaw 吸引，是因为它的架构思路是“本地优先”。模型可以完全跑在本地，通过 Ollama 加载开源权重，不需要把每一句对话都发到外部 API。这样做有几个非常现实的好处：

• 隐私可控。对话记录、工具调用日志都留在自己的机器里。
• 没有按 token 计费的压力。随便问，问错了也不心疼。
• 离线可用。本地模型加载之后，断网也能跑基础能力。
• 模块化。聊天平台、模型 provider、skill 都是可插拔的。

但也必须说清楚，OpenClaw 不是开箱即用的“傻瓜软件”。它的安装过程涉及 Node.js、WSL2、Ollama、配置文件，还有一堆环境变量。我第一次装的时候就卡在了“OpenClaw 无法安全验证 WSL2 环境”这个提示上，当时还以为是程序坏了，后来发现是 WSL 内核版本太旧。这种问题在官方文档里往往只有一句话，但实际排查要翻不少资料。

正是因为折腾成本不低，我觉得很有必要把这些经验沉淀成一篇总结。下面按部署、实操、技能、排障、评价五个部分来写。

2. 部署方式选型：Windows Companion、WSL2、Termux 与算力来源

2.1 三条主流路线怎么选

OpenClaw 的跨平台能力是它的一大卖点，但“能跑”和“跑得顺”是两回事。我实际测试下来，比较靠谱的路线有三条：

我自己最终的主力方案是 Windows 笔记本 + WSL2 + Ollama。不是因为 Windows 最稳，而是因为 Windows Companion 在系统集成方面确实方便。你如果不关心通知、剪贴板、全局麦克风，直接装 Linux 服务器版本会省掉很多麻烦。

2.2 WSL2 环境与 Node.js 的前提

在 Windows 上跑 OpenClaw，第一个拦路虎就是 WSL2。很多报错都跟它有关。最典型的提示是：

OpenClaw 无法安全验证 WSL2 环境。请在 PowerShell 中运行 wsl --status 以获取详细信息。

这句提示看上去像程序崩溃，其实只是 OpenClaw 的安全检查没通过。它希望确认 WSL2 默认版本正常、内核可用，然后才会让主服务在 Linux 子系统里运行。因为 OpenClaw 很多底层操作依赖 Linux 语义，直接跑在 Windows 原生环境里会碰到文件权限、进程管理和 socket 行为不一致的问题。

所以装 OpenClaw 之前，我建议先把下面这几样确认好：

• Windows 10 21H2 或 Windows 11 以上版本。
• WSL2 已启用，且有可用的 Linux 发行版。
• Node.js LTS 版本已安装，npm 能正常使用。
• 如果打算用本地模型，Ollama 也要装好。

很多人会搜“Node.js 官网下载 OpenClaw”，这其实是个误解。Node.js 官网下载的是 JavaScript 运行时，OpenClaw 是通过 npm 安装的。你真正要装的不是“OpenClaw 一键安装包”，而是“OpenClaw 的 npm 包 + Node.js 运行时 + 一堆配置文件”。

2.3 本地模型还是 API：算力问题的真实答案

很多人问过“OpenClaw 只能用接入 API 的方式使用算力吗”。答案是否定的。OpenClaw 可以接 Ollama 本地模型，也可以接各种在线 API，两者还能混合使用。

我实际测试下来的体会是：

• 如果你的机器有 16GB 内存，跑 7B 或 8B 量化模型基本够用。
• 32GB 内存可以尝试 14B 模型，速度会更慢，但理解能力明显提升。
• 只有集成显卡或纯 CPU，也能跑，只是响应速度到不了“很跟手”的程度。

以我现在用的 qwen2.5:7b 为例，在 WSL2 里分配给 Ollama 的内存足够时，单轮回复大概需要 3 到 6 秒。这个速度对聊天来说已经不错了，对“执行任务”这种场景也完全能接受。

API 方式的优势是模型更强、响应更快，代价是数据出本机、按量计费。如果只是体验 OpenClaw，我建议先用本地模型跑通全流程，再把 API 作为可选增强。这样就算网络波动，核心功能也不会瘫痪。

3. 完整实操记录：从零部署一份可用的 OpenClaw

3.1 准备阶段：先把 WSL2 和 Node.js 弄干净

以下是我的实际操作记录，按顺序来基本不会再踩坑。

第一步，打开 PowerShell，先看 WSL 状态：

wsl --status

正常情况下会看到“默认版本：2”以及内核版本号。如果提示没有安装发行版，或者版本号很老，就先执行：

wsl --update wsl --shutdown wsl --set-default-version 2

较新的 WSL 版本还支持wsl --update --web-download，如果你在公司网络或内网环境，这个参数能避免商店下载失败的问题。

第二步，检查 Node.js：

node -v npm -v

我建议使用 Node.js 20 LTS 或 22 LTS。之前我在旧版本 Node 16 上跑 OpenClaw，npm 装包时反复报错，升级到 LTS 后问题自然消失。如果你没有 Node.js，可以直接去官网下 LTS 安装包，一路下一步即可。

第三步，装好 Git。Windows 下直接用 winget 装最省事：

winget install Git.Git

3.2 安装 OpenClaw 与配置 Windows Companion

确认环境和 Node 版本没问题后，开始安装 OpenClaw：

npm install -g openclaw

然后初始化一个项目目录：

openclaw init myassistant cd myassistant

这个过程会生成 OpenClaw 的配置目录和初始配置文件。不同版本生成的字段名略有差异，但大概思路是一样的。

如果你要用 Windows Companion，注意它并不是 OpenClaw 的主程序，而是负责系统级桥接的辅助进程。它处理通知、剪贴板、全局音频输入这些主服务理论上不该碰的能力。我第一次配置时犯过一个错误：以为 Companion 是独立 App，装好主程序就能直接弹通知。实际上需要在配置文件里把 Companion 开关打开，再启动 companion 进程。

我当时在openclaw.config.json里的写法是这样的：

{ "windowsCompanion": { "enabled": true, "port": 18789, "bind": "127.0.0.1" } }

补充说明一下：这个 IP 绑定很重要。Companion 只监听本地回环地址就够了，不要绑到0.0.0.0，否则局域网内其他设备也能访问你的 Companion 接口，存在安全隐患。

然后启动 Companion：

openclaw companion start

启动后回到主控制台，运行：

openclaw start

如果配置没有报错，OpenClaw 会先检查 WSL2 环境，再加载模型和 skill，最后进入等待对话的状态。

3.3 配置 Ollama 与模型加载

OpenClaw 默认不一定带着 Ollama 集成，需要你在配置里指定 provider。我的做法是先在 WSL2 里装 Ollama：

curl -fsSL https://ollama.com/install.sh | sh

然后拉取模型：

ollama pull qwen2.5:7b

如果 Ollama 和 OpenClaw 跑在同一台机器上，通常保持默认的127.0.0.1:11434就行。只有当你希望手机 Termux 或局域网设备访问这台 Ollama 时，才需要设置：

export OLLAMA_HOST=0.0.0.0

然后在 OpenClaw 配置里填上模型信息。我当时的配置片段类似：

{ "model": { "provider": "ollama", "model": "qwen2.5:7b", "baseUrl": "http://127.0.0.1:11434" } }

启动后如果日志里出现“model loaded”或类似字样，说明模型已经就位。

3.4 第一轮启动与对话验证

我第一次启动时心里很没底，怕卡在某一步。实际完整流程跑通之后，验证只需要两步：

第一步，在 OpenClaw 控制台里发一句话，比如“你好，介绍一下你现在的能力”。如果模型能正常回复，说明基础链路没问题。

第二步，调一个最简单的 skill。OpenClaw 默认会带一些基础技能，你可以在配置里查看技能列表，或者直接问它“你会哪些技能”。如果它能列出来，说明 skill 加载也正常。

这里有一个经验：不要一上来就把 Telegram、Discord、微信群全接上。先把 CLI 模式跑通，再逐步加平台。我见过不少人在第一步就急着接多个平台，结果日志密密麻麻，分不清是模型问题、平台 token 问题还是 skill 问题。

3.5 手机端 Termux 安装补充

很多人搜“Termux 安装 OpenClaw 手机版下载步骤”，其实 OpenClaw 没有专门的“手机版”，它是通过 Termux 在 Android 上跑 Node.js 环境。

我的操作步骤：

pkg update && pkg upgrade -y pkg install nodejs-lts git termux-api npm install -g openclaw openclaw init mobile

Termux 环境下有几点要特别注意：

• 不要用 Google Play 上的旧 Termux，建议从 F-Droid 或 GitHub Release 安装，否则包源会不稳定。
• Android 后台杀进程非常激进，需要把 Termux 加入电池优化白名单，否则跑着跑着就被系统回收。
• 手机本地算力有限，我实测 7B 模型在手机上跑基本不现实。更合理的方案是手机 Termux 作为远端控制端，连接家里或服务器上的 OpenClaw 实例。

如果你想把手机上的通知、位置、摄像头等能力接入 OpenClaw，就装termux-api包。它提供了一组本地 API，OpenClaw 的 skill 可以通过 Termux 的意图接口调用这些能力。

4. 技能（Skill）机制：把助手从“会聊天”变成“能干活”

4.1 Skill 到底长什么样

OpenClaw 最灵活的部分是 skill 机制。你可以把 skill 理解成“给 AI 助手准备的插件”。

一个 skill 通常由两部分组成：

• 一份描述文件，告诉模型这个 skill 什么时候触发、需要什么参数。
• 一段可执行脚本，负责真正完成任务。

我习惯把 skill 放在项目目录下的skills文件夹里，每个 skill 一个子目录。典型结构是这样：

skills/ remind_me/ SKILL.md run.js

SKILL.md的写法有点类似 Markdown 加 frontmatter，核心是让模型知道“你有一个工具可以用”。我当时写的一个简单提醒 skill：

--- name: remind_me description: 设置一个定时提醒 arguments: content: type: string description: 提醒内容 minutes: type: integer description: 多少分钟后提醒 --- 你正在执行提醒设置任务，请把 content 和 minutes 传给脚本，由脚本创建系统提醒。

然后run.js负责实现具体逻辑，比如写入一个提醒队列或调用系统通知。实际项目里，你可能还想让 skill 能读取日历、查询天气、操作文件，甚至调用外部接口。

4.2 写一个自己的 Skill

很多人第一次写 skill 会搞错一个点：模型本身不执行代码，它只是根据描述生成参数，然后交给 skill 脚本来执行。所以描述文件的质量，直接决定这个技能好不好用。

我写 skill 的经验可以概括成三点：

• 描述要具体。不要写“处理提醒”，要写“在用户要求设置提醒时，提取提醒内容和分钟数”。
• 参数要明确。写清楚每个参数的类型和含义，能让大模型少犯很多错。
• 脚本要容错。模型生成的参数有时候会格式不规范，脚本里要做校验和兜底。

以天气查询为例，不要让模型自己编天气数据，而是让 skill 脚本去调天气接口。OpenClaw 的价值就在这：把不可控的模型输出，转化为可控的函数调用。

4.3 权限与安全边界

Skill 能执行代码，就意味着它拥有你这台机器的权限。这是 OpenClaw 最强大的地方，也是最需要谨慎的地方。

我给自己立了几条规矩：

• 不用 root 或管理员账户跑 OpenClaw，除非有绝对必要。
• 每个 skill 只给最小权限，不写“万能执行”脚本。
• 外部 API 的 token 单独管理，不写死在 skill 源码里。
• 定期看日志，确认模型没有莫名其妙触发危险 skill。

你可以把 skill 想象成一个外包员工：你告诉它任务目标，它自己决定流程。但如果不设好权限边界，这个员工可能做出你完全没预料到的事。所以“能用”和“安全地用”之间，差了配置、测试和日志这几道功夫。

5. 常见问题与排查技巧实录

5.1 WSL2 环境校验失败的根源与修复

“OpenClaw 无法安全验证 WSL2 环境，请在 PowerShell 中运行 wsl --status”这个话题被搜得最多，我也卡过。这个报错通常有三个原因：

• WSL2 没启用或默认版本不是 2。
• WSL 内核太旧，OpenClaw 检查到的内核信息不完整。
• 系统版本太老，比如 Windows 10 初版，WSL2 支持不完整。

修复路径也很固定。先运行：

wsl --status wsl --version

如果发现内核版本过旧，就：

wsl --update wsl --shutdown

如果wsl --status显示默认版本是 1，就执行：

wsl --set-default-version 2

做完这些，再重新启动 OpenClaw。绝大多数 WSL2 相关报错都能在这几步内解决。

5.2 Node.js 版本坑

OpenClaw 是 Node.js 项目，所以 Node 版本直接决定能否安装和启动。我遇到的几类问题：

我踩得最多的坑是：npm 包已经装了，但控制台里运行openclaw提示找不到命令。这往往不是包没装上，而是 npm 全局 bin 目录不在 PATH 里。用npm config get prefix看一眼，再手动把目录加进 PATH 基本就好。

5.3 Ollama 连接不上

OpenClaw 配置了 Ollama provider 后，如果日志提示模型连接失败，先别急着改配置，用下面这条命令直接确认 Ollama 是否活着：

curl http://127.0.0.1:11434/api/tags

如果这个地址能看到模型列表，说明 Ollama 正常，问题大概率出在 OpenClaw 配置里的baseUrl写错了。如果连接不通，再检查 Ollama 服务是否启动、监听地址是否改过。

还有一个容易被忽略的点：WSL2 里访问 Windows 宿主机服务，不能直接用localhost。反过来，Windows 访问 WSL2 里的服务也要确认 IP。OpenClaw 和 Ollama 都跑在 WSL2 内部时，用127.0.0.1最省心。一个在 Windows 原生，一个在 WSL2 内，才会遇到网络互通问题。

5.4 端口、防火墙与局域网访问

OpenClaw 的 Web 管理界面和 Companion 都有自己的端口。默认端口如果被占用，启动时会报 address in use。解决方法是换端口，或者在配置文件里明确指定端口。

如果你想让同一局域网的其他设备访问 OpenClaw，要注意防火墙。Windows 默认会在首次监听时弹窗询问是否允许，选“取消”以后，局域网设备就会一直连不上。这时候得去防火墙里手动放行对应端口，或者直接改绑定的 IP。

但我的建议是：除非确实需要，否则不要把 OpenClaw 的调试端口暴露到局域网。手机 Termux 需要远程访问的话，用带认证的反向通道比裸奔端口安全得多。

5.5 Termux 上的常见问题

Termux 上最容易出问题的地方不是 OpenClaw 本身，而是系统权限和包源。

• 如果pkg install很慢，可以先pkg update，再换一个更快的镜像源。
• 如果 OpenClaw 启动后无法读剪贴板或通知，多半是termux-api没装，或者 Termux 没有在前台运行权限。
• 如果进程被杀，参考前面说的，把 Termux 加入电池优化白名单。

还有一个信息要同步：OpenClaw 目前没有官方中文版。网上搜到的“OpenClaw 中文版”大多是社区汉化或非官方打包。我的建议是直接用英文原版。这个项目迭代速度很快，汉化版很有可能落后好几个版本，导致配置项对不上。

6. 个人评价与后续建议

6.1 我满意的部分

OpenClaw 最打动我的是它的“本地优先 + 可编程”思路。它不像很多 AI 产品那样把用户锁在自家生态里，而是把模型、平台、技能都抽象成可替换的模块。我可以在本机用 Ollama，也可以临时切到 API；我可以只做 CLI 部署，也可以接一堆消息平台。这种自由度在商业产品里基本见不到。

另一个让我坚持用下来的原因是 skill 机制。刚开始我总觉得 AI 助手“没有灵魂”，后来发现不是模型不够聪明，而是缺少把对话转成动作的桥梁。写了一个真正的 skill 并且跑通之后，你会明显感受到“助手”和“聊天机器人”的区别。

6.2 仍然不够好的地方

客观说，OpenClaw 目前还是偏“技术爱好者玩具”。

首先是文档和配置碎片化。同一个功能，不同版本里可能有不同写法，经常需要对照 GitHub issue 才能搞清楚。其次是 Windows 原生支持还不完美。WSL2 环境校验这种问题，对不了解 WSL 的新手来说门槛很高。第三是没有像样的图形化配置界面，一切靠改配置文件，这对纯小白很不友好。

安全方面也还有提升空间。skill 可以执行代码，但官方对权限隔离、容器化运行这些企业级能力支持得还不够深。如果只是自用问题不大，如果要跑在公网服务器上，必须自己做额外的加固。

6.3 给后来者的配置建议

如果你决定入坑，我建议按这个顺序来：

• 第一步，先在 Windows/Linux 上用 CLI 模式跑通 Ollama 本地模型。
• 第二步，写一个最简单的 skill，比如定时提醒或文件整理。
• 第三步，再接一个消息平台，比如 Telegram 或群聊。
• 第四步，把配置文件和 skill 目录用 Git 管理起来，方便回滚。
• 第五步，再考虑 Windows Companion、手机 Termux、局域网访问这些进阶能力。

我最后一次重装时，由于有配置备份和 skill 备份，整个环境从零搭起来只用了不到半小时。没有备份之前，我每次折腾都担心把环境搞坏。所以，配置文件的版本管理一定要从第一天就做。

最后再分享一个小技巧：OpenClaw 的日志信息量很大，别只盯着红色错误看。遇到启动失败，先把日志里第一条警告找出来，往往那才是根因。比如 WSL2 校验失败、模型加载失败、端口占用，这些问题的第一条日志都在很前面的位置，而不是最后几条。这个习惯帮我避开了很多“反复重启但不知道错在哪”的无用功。

OpenClaw 现在还称不上完美，但它的方向是对的。如果你愿意花时间折腾，它能让你拥有一个真正属于自己、能干活、能不断扩展的 AI 助手。这篇终章就当是给这一阶段画个句号，也希望这些经验能陪你少踩几个坑。