最近逛社区发现，OpenClaw 这个话题又热起来了。好几个群里都在问同一个问题：Windows 上到底能不能原生装？我其实从 1.x 版本就一直在折腾这个项目，中间试过 WSL、试过 Docker、也试过直接在 Windows 命令行里跑，前前后后重装过不下五遍。最后我得出的结论很直接：如果你想在 Windows 上把它当成日常工具用，原生安装反而是最省心的一条路。
先说清楚 OpenClaw 是什么。它不是一个普通的聊天客户端，而是一个 AI 代理框架。简单的理解方式是：普通聊天是你问一句、它答一句，OpenClaw 则是你给它一个目标，它会自己拆解步骤、调用工具、查资料、跑脚本，最后把结果交给你。对经常要在本机做文件整理、批量处理日志、写自动化脚本的人来说，这个价值是实实在在的。而"中国版"这里要澄清一下，它不是官方搞的独立分支，而是社区维护的一套中文开箱即用配置包，内置了国内模型 API 的兼容配置、中文技能包、以及一些下载源加速方案。装上就能用，不用自己去翻文档拼配置，这才是它最吸引人的地方。
这篇文章按照从零开始的顺序写，适合三类人：完全没装过的小白、在 WSL 里装了但想转回原生环境的老手、以及只是想对比一下原生和虚拟环境差异的观望者。如果你已经是一个深度 Linux 用户，前面的基础章节可以跳过，直接看模型配置和踩坑部分就行。
1. 先说清楚：OpenClaw 到底解决什么问题
1.1 我和这个项目的初遇
我最早注意到 OpenClaw，是因为被一个群友的演示刺激到了。他让代理帮他把一个文件夹里三百多张图片按内容分类重命名，前后也就几分钟，代理自己写了脚本、跑了一遍、还顺手生成了一个分类汇总的表格。我当时的反应是：这不就是我一直想要的"能干活"的 AI 吗？
后来我自己入手，第一周几乎是劝退的体验。原因很简单：文档虽然全，但都是面向 Linux 和 Mac 写的，Windows 相关的内容要么没有，要么只是简单提一句"建议用 WSL"。这对于用 Windows 干活的人来说太难受了，每一步都得自己去试错。我走了不少弯路，所以现在想把这些经验整理出来。
1.2 为什么强调"中国版"
这块我得先纠正一个容易踩的误区。你在网上搜"OpenClaw 中国版"，搜出来的可能是五花八门的东西。有的确实良心，把模型 API 地址、技能仓库、甚至是 PowerShell 脚本都给你准备好；但也有的就是换个壳，甚至塞了恶意脚本进去。我个人的建议是：别去下载那种打包成 exe 的"一键安装版"，就用官方原版，再配合社区的中文配置方案。
我做这套教程的基准，基于 2025 年下半年比较流行的社区配置方案，核心思路有三条：第一，模型接入层默认兼容国内可以直连的 API 服务，比如 DeepSeek、通义千问、智谱这些；第二，技能仓库有国内镜像，下载不至于卡死；第三，配置文件中文化，日志输出默认调整为更容易看懂的中文。这样做的好处是：你不必因为网络原因绕来绕去，装上之后把 API 填进去就能跑。
1.3 这篇内容适合谁、不适合谁
如果你满足下面任何一个条件，可以放心往下看：电脑是 Windows 10 22H2 或 Windows 11，想在本地跑一个 AI 代理工具；装过 Node.js 但没怎么用过，愿意按步骤复制命令；之前试过 Docker 或 WSL 但被绕晕了，想回到原生环境。
相反，如果你是要部署到服务器上给几十个人用，或者你本来就在 Linux 管道里玩得很溜，那这篇文章的前半部分对你来说节奏太慢了，直接跳到第四章看模型接入，第五章看故障排查就够了。
2. 装之前必须搞明白的三件事
2.1 Windows 原生还是 WSL 2：别一上来就选错
这是我在群里被问得最多的一个问题。聊结论之前，先摆两张图让你看清差异。
| 对比维度 | Windows 原生 | WSL 2 |
|---|---|---|
| 安装门槛 | 低，装两个软件就行 | 中，需要开启虚拟机平台，部分旧电脑会卡住 |
| 文件读写性能 | 高，直接在 NTFS 上跑 | 中，跨文件系统读写有明显延迟 |
| 网络与端口 | 直接用主机端口 | localhost 映射偶尔抽风，127.0.0.1 访问出问题很常见 |
| 依赖兼容性 | 大部分现代组件可用 | 最接近 Linux 服务器，兼容性最好 |
| 适合场景 | 个人日常自动化、写脚本、跑轻服务 | 打算把配置原封不动搬上云服务器 |
我之前在 WSL 里装过 OpenClaw，最让我崩溃的点是：WSL 里启动后的服务，Windows 这边的浏览器偶尔访问不到，得手动搞定端口转发。而且 WSL 的文件 IO 确实慢，尤其是对 Windows 分区下的文件做批量处理时，那个速度差距非常体感明显。原生安装唯一的劣势，是某些为 Linux 设计的工具链在 Windows 上要额外配置，但 OpenClaw 的核心组件对 Windows 支持得很好，所以我不推荐一上来就上 WSL。
2.2 前置环境清单（照着准备就行）
原生安装前，你需要确认这几样东西在不在：
- Windows 10 22H2 或者 Windows 11，最好是 64 位
- PowerShell 5.1 以上，推荐 PowerShell 7（后面会讲为什么）
- Node.js 18 或更高版本，推荐 20 LTS
- Git for Windows，2.40 以上
- 稳定的网络连接（能正常访问 npm 官方源就行，后面会教怎么换国内镜像）
这些条件里最容易忽略的是 PowerShell 版本。Windows 自带的 Windows PowerShell 5.1 其实也能跑，但有个麻烦：5.1 默认执行策略是 Restricted，你不改策略连脚本都跑不了。后面我会给出具体命令。
2.3 大模型从哪来：本地 Ollama 还是云端 API
OpenClaw 本身不产出模型，它像一个调度中枢，得接上"大脑"才能干活。脑子的来源有两条路：
一条是本地部署模型，典型方案是 Ollama。你把模型文件下载到本地，用显卡或 CPU 跑推理。好处是隐私性强、不依赖网络、不产生 API 费用；坏处是笔记本扛不住大模型，跑 7B 的模型如果没独显，速度和效果都只能说"能跑"。
另一条是云端 API，你只需要一个密钥，把请求发到服务商那里，它帮你出结果。国内直连比较方便的有 DeepSeek、通义千问、智谱 GLM 这几家，OpenAI 兼容接口格式，OpenClaw 接入起来几乎是无缝的。好处是效果稳定、不吃本地硬件；坏处是每调用一次都要花钱，而且数据要出本机。
我自己的配置是双通道：重要任务走 DeepSeek API，图省事或者调试技能时切到本地 Ollama。这个切换在 OpenClaw 里就是改一行配置的事，后面有详细例子。
3. 保姆级安装步骤（Windows 原生方案）
3.1 安装 Node.js 和 Git
第一步，去 Node.js 官网下载 LTS 版本，注意不是 Current 最新版，是那个标记着 LTS 的版本。我吃过这个亏：用 Current 版本装完，有个依赖包编译直接报错，换回 LTS 就安静了。安装时一路 Next，但要注意安装向导里有个 "Add to PATH" 选项，默认是勾上的，必须确认它是勾选状态，这个决定你能不能直接在 PowerShell 里敲 node 命令。
装完打开 PowerShell（切记不是 CMD），输入：
node -v npm -v能正常输出版本号就说明 Node.js 装好了。然后装 Git，从官网下载 Git for Windows，安装向导里大部分默认选项不用动，遇到 "Adjusting your PATH environment" 那一页，选择中间项 "Git from the command line and also from 3rd-party software"，其他默认。装完同样验证一下：
git --version3.2 安装 OpenClaw 主程序
现在到了核心环节。OpenClaw 的安装方式取决于你拿到的版本。官方主程序目前主要是通过 npm 分发的。在 PowerShell 里执行：
npm install -g @openclaw/cli如果你用的是社区整合配置包，可能包名会带-china后缀，但底层命令行入口是一样的。安装完执行：
openclaw --version如果这一步输出了版本号，恭喜，主程序已经装好了。但如果你看到openclaw 不是内部或外部命令，那八成是 npm 的全局目录没有加入 PATH。解决办法是找到 npm 全局路径，手动加进系统环境变量。执行：
npm config get prefix把输出的路径加到 PATH 里，然后重新开一个 PowerShell 窗口再试一次。
3.3 初始化工作目录
OpenClaw 需要一个目录来存放配置、技能和日志。我建议不要放在 C 盘的系统目录下，更不要放在 OneDrive 同步目录里。我之前就把工作目录放在 OneDrive 下，结果代理每次重启要同步文件，把目录结构搞乱过一次。
找个你喜欢的位置，比如D:\openclaw，执行：
mkdir D:\openclaw cd D:\openclaw openclaw init初始化过程会问你几个问题：工作目录确认、默认语言、默认模型供应商。这里有一个关键点：如果你打算用社区中文配置包，初始化时选择语言zh-CN就对了。初始化完成后，目录下会多出一个openclaw.config.json文件，这就是后面所有配置的核心。
3.4 第一次启动验证
装完先别急着接模型，裸启动一次，确认框架本身没有问题。执行：
openclaw start正常情况你会看到终端里出现日志输出，类似 "OpenClaw is running"，然后提示一个本地控制台地址。如果这里直接报错，大概率就是第五章要讲的坑之一。先别慌，对照后面的排查表处理就行。
验证完按Ctrl + C停掉，我们进入真正的配置环节。
4. 配置实战：接入本地 Ollama 与国内云 API
4.1 本地 Ollama：免费但要有心理准备
先去 Ollama 官网下载 Windows 安装包，装完后 Ollama 会自动注册成后台服务。然后在 PowerShell 里拉一个适合新手跑的中文模型：
ollama pull qwen2.5:7b这个模型 7B 参数，纯 CPU 跑也能响应，就是速度慢一点；如果你的电脑有 NVIDIA 显卡，体验会好很多。拉取完成后测试一下模型本身是否正常：
ollama run qwen2.5:7b "你好，介绍一下你自己"能正常回复，说明本地模型这条路通了。接下来需要把它接进 OpenClaw。编辑openclaw.config.json，找到模型配置这一段，改成类似这样：
{ "model": { "provider": "openclaw", "base_url": "http://127.0.0.1:11434", "model": "qwen2.5:7b", "api_key": "local", "params": { "temperature": 0.7 } } }注意base_url必须是127.0.0.1而不是localhost。这是因为在某些 Windows 环境下，localhost会被解析成 IPv6 地址::1，而 Ollama 默认监听的是 IPv4 的127.0.0.1，一旦解析错就报连接失败。这是个非常隐蔽的坑。
4.2 接入 DeepSeek / 通义千问等云端 API
云端 API 的好处不用多说，效果稳定、不吃本地硬件。以 DeepSeek 为例，你需要先去平台注册账号，创建 API Key，充一点额度。然后修改配置：
{ "model": { "provider": "deepseek", "base_url": "https://api.deepseek.com/v1", "model": "deepseek-chat", "api_key": "sk-你的密钥放这里" } }如果你是通义千问的用户，base_url换成兼容地址，模型名换成qwen-plus类似的名字就行。OpenClaw 底层走的是 OpenAI 兼容协议，所以这些服务商的接入方式大同小异。
这里提醒一句：API Key 是敏感信息，别硬编码在配置文件里，尤其是如果你的 openclaw 目录会被同步到网盘或上传到 Git 仓库。建议设置成环境变量，在 PowerShell 里执行：
[Environment]::SetEnvironmentVariable("OPENCLAW_API_KEY", "sk-你的密钥", "User")然后配置里写"api_key": "${OPENCLAW_API_KEY}"，这样既安全又方便切换。
4.3 技能（Skills）的安装与使用
OpenClaw 最核心的扩展能力就是技能。技能可以理解为给代理配的工具包，比如：读取 PDF、整理文件、调用浏览器搜索、生成图表等等。把技能装进去，代理才能真的"动手干活"。
安装技能的命令一般是：
openclaw skill add file-organizer openclaw skill add web-search openclaw skill add pdf-parse装完后用openclaw skill list查看已安装的技能。如果你想自己写一个技能，可以直接在技能目录下新建一个 JSON 描述文件加一段执行逻辑，官方文档里有模板。我的体会是：先在官方技能仓库里泡几天，用熟练了再开始写自己的，不然容易一上来就被目录结构搞晕。
5. 我在 Windows 上踩过的坑（附排查表）
5.1 "openclaw 无法安全验证 sl2 环境"这类 WSL 报错
这个标题可能让不少人不解，因为我这篇是原生安装教程，为什么还要讲 WSL？原因很简单：不少社区的安装脚本会在 Windows 环境检测阶段顺手检查 WSL 状态，导致你明明没用 WSL，也会收到类似"请在 PowerShell 中运行 wsl --status"的提示。
我第一次看到这个提示也愣了一下，以为是必须装 WSL，结果折腾一晚上没解决问题。后来才搞清楚，它只是检测wsl.exe不存在或者虚拟化平台没开启时的友好提示，跟你 OpenClaw 能不能原生跑没有半点关系。处理方法很简单：如果你确实不用 WSL，直接在配置里关闭相关检测项，或者忽略这条警告即可；如果你日后打算用 WSL，再启用"虚拟机平台"功能，然后运行一次wsl --status确认内核状态。
5.2 端口占用与守护进程启动失败
启动时如果报错说端口被占用，最常见的两个元凶是：边车进程没退干净，或者别的程序占用了同样的端口。排查端口占用用这条命令：
netstat -ano | findstr :11434拿到进程 PID 之后，在任务管理器里找到对应进程，确认确实是残留的 ollama 或者其他无关程序后，再结束它。还有一种情况是报error: start the windows daemon from a non-elevated terminal，意思是你用管理员权限开了终端但环境变量路径不一致。解决办法很奇葩：不要用"以管理员身份运行"打开 PowerShell，直接用普通权限运行。这个错误我之前百思不得其解，后来发现项目检测的是当前 shell 的 elevation 状态，而它期望的是"非提升"状态。
5.3 模型下载和依赖安装卡死
这是在国内环境最常见的痛点。模型文件动辄几个 GB，从海外源下载经常卡在 99%。解决方案是换国内源。以 Ollama 为例，你可以设置镜像地址后再拉模型：
$env:OLLAMA_HOST = "127.0.0.1:11434" $env:OLLAMA_MODELS = "D:\ollama\models"镜像加速可以配置OLLAMA_REGISTRY之类的环境变量，具体地址以你找到的可用镜像为准。npm 依赖安装卡住也一样，配置镜像源：
npm config set registry https://registry.npmmirror.com然后再重新执行npm install，速度会快很多。
5.4 常见问题速查表
我把自己遇到的、以及群里高频出现的问题整理成了一张表，照着查就行。
| 症状 | 根本原因 | 解决方法 |
|---|---|---|
| openclaw 不是内部或外部命令 | npm 全局目录未加入 PATH | npm config get prefix，把路径加进系统 PATH 后重开终端 |
| 启动报 localhost 连接失败 | localhost 解析成 IPv6 而服务监听 IPv4 | 配置里的地址改为127.0.0.1 |
| Port 11434 already in use | 上一个 Ollama 进程残留 | netstat -ano找到 PID，结束进程或切换端口 |
| 提示需要 WSL 环境 | 安装脚本的 WSL 检测项 | 关闭检测项或忽略警告，不影响原生运行 |
| 依赖安装卡进度 | 默认 npm 源访问慢 | 将 registry 切到国内镜像 |
| 模型下载到一半失败 | 网络源不稳定 | 切国内镜像源后重新拉取 |
| 运行报 PowerShell 脚本被禁止 | 执行策略为 Restricted | 以管理员运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser |
| 日志输出中文乱码 | 终端编码为 GBK | PowerShell 里执行$OutputEncoding = [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 |
5.5 几个容易被忽略的细节
第一，路径里不要有空格和中文。虽然现代工具链大部分能处理，但 OpenClaw 在调用某些外部脚本时用的是空格分隔参数，路径一旦有空格极容易出莫名其妙的错。第二，杀毒软件可能拦截代理执行脚本，尤其是开脚本扫描的杀软。我建议把 OpenClaw 工作目录加进杀软信任区。第三，Windows 的"快速启动"会影响代理服务的唤醒，如果你发现第二天早上代理状态不对，可以在电源设置里关掉快速启动试试。
6. 从"跑起来"到"用得好"的进阶建议
6.1 配置桌面端 Companion
OpenClaw 有个 Windows 桌面端 Companion，它的作用是让你不用一直盯着终端窗口，任务状态会出现在系统托盘区域。配置方式并不复杂：先保证主程序已启动，然后在 Companion 里指向同一个工作目录，它会自动识别当前会话。配好之后，你在桌面端提交任务和查看日志都会方便很多。
我当时配完 Companion 之后最大的感受是：它终于像一个"正经软件"了，而不是一个黑乎乎的终端窗口。但要注意，Companion 和主程序的版本要尽量保持一致，大版本不一致的时候很容易出现连接不上的问题。
6.2 和自动化任务结合
OpenClaw 真正的威力，在于把它接进你的自动化流水线。我举一个自己的例子：每天上班前，让代理检查某个日志目录，把最近一次报错的关键段落抽取出来，按严重程度排序生成摘要，顺手写进当日晨会文档。整个过程不需要我手动干预，全靠一个定时任务触发。
Windows 上做定时任务可以直接用"任务计划程序"，触发条件设成"用户登录时"或"每天指定时间"，操作指向一个.bat或 PowerShell 脚本，脚本里调用openclaw run加上指定任务名。这里有个经验：任务计划程序里一定要把"使用最高权限运行"选项关掉，否则又会触发我们前面说的 non-elevated terminal 检测问题。这个坑我踩过不止一次。
6.3 资源控制与日常维护
本地跑模型时，内存和显存占用是绕不开的话题。Ollama 默认会把模型常驻内存，如果不做限制，小内存机器可能直接被拖死。可以在 Ollama 的服务配置里设置并发请求数量，或者指定更小的上下文长度。OpenClaw 这边也可以限制代理同时运行的步骤数和并发任务数，避免一次派活太多导致整机卡顿。
日常维护方面，我要强调日志管理。OpenClaw 默认日志会一直写，时间长了会占几个 GB。我建议每隔一段时间清一次日志，或者配置日志轮转。方法不复杂，在配置文件里加一个日志策略，按天数滚动保留即可。另外，升级版本前一定要先备份openclaw.config.json和技能目录，因为跨版本升级时偶尔会有配置结构变化，没备份的话只能从头配。
我个人在实际操作中的体会是：Windows 原生安装 OpenClaw 并不难，难的是那些藏在水面下的环境细节。WSL 里跑不通的问题，切回原生环境大多能解决，但前提是你得先跨过"检查 WSL 状态"这个迷惑性报错、适配好模型来源、管理好端口和权限。上面这些坑，几乎都是我一夜又一夜试出来的。
最后再分享一个小技巧给已经跑通的朋友：当你配好了本地 Ollama 和云端 API 双通道后，可以先在日常任务中用云端 API 跑复杂任务，用本地模型处理简单、私密的信息摘要类任务。一方面省了 API 费用，另一方面也不会因为网络波动影响简单任务。这个搭配我用了大半个月，整体体感非常稳，算是真正把 OpenClaw 用成了生产力工具。
如果你也在 Windows 上折腾 OpenClaw，遇上了上面没提到的报错，不妨先从配置文件和工作目录权限入手排查，这两处占了 Windows 环境七成以上的奇怪问题。跑通之后，记得把好用的技能和工作流记录下来，回头发到社区里，大概率有人在等你这份现成的经验。
