Windows本地AI助手实战：WSL2上配置OpenClaw与Ollama全指南

1. 项目概述与方案选型思路

1.1 为什么要在 Windows 上折腾这套本地 AI 组合

先说结论：OpenClaw 加 Ollama 这套组合，本质上是在帮你打造一套完全本地化、隐私友好、可自由定制的 AI 助手环境。在 Windows 上做这个事，最直接的动机无非是这三类：不想把数据传上云端、想白嫖自己电脑的显卡算力、想深度定制一套属于自己的 Agent 工作流。

我在实际项目里试过很多种方案组合，最终固定用 OpenClaw + Ollama 的组合也有段时间了。OpenClaw 本身是一个开源智能体框架，它擅长的是把大语言模型的能力接出来，完成各种实际任务——比如处理本地文件、调用命令行、对接外部服务等。而 Ollama 负责的是在本地跑模型，它把 llama.cpp 这一层推理引擎做了很好的封装，让你能像装普通软件一样把 Llama、Qwen、DeepSeek 这些开源模型跑起来。

这两者搭配起来的逻辑其实很直白：OpenClaw 是大脑的神经系统，负责调度和决策；Ollama 是大脑的肉体，负责真正的推理计算。缺了谁都不行。

但 Windows 这个平台有点特殊，它不像 Linux 那样天生适合跑这种东西，所以安装配置过程中会遇到一堆“明明看着没问题但就是跑不起来”的坑。这篇文章的价值就是把我在这些坑里爬出来的经验一次性写清楚，省得你重复踩。

1.2 环境选型：WSL2 还是纯 Windows

我见过不少人在第一步就卡住了，纠结到底是用纯 Windows 环境跑，还是装 WSL2 再跑。我的建议非常明确：直接用 WSL2，不要犹豫。

原因有三点。第一，OpenClaw 它本身对 Linux 环境更友好，它的依赖链里面很多底层的系统调用在 Windows 原生环境下支持得不好。第二，Ollama 官方对 Windows 的支持在早期只提供了 Linux 版本，虽然后来有了 Windows 原生版，但实测下来 WSL2 里的 Linux 版在性能和稳定性上都要好一些。第三，后续你要扩展其他 AI 工具的时候，会发现大部分开源模型工具链都默认你跑在 Linux 上，提前适配好能少很多麻烦。

WSL2 本质上是一个轻量级虚拟机，它和 Windows 共享网络、共享文件系统，你不需要真的装一个双系统去切换。装好之后，你在 Windows 的终端里直接敲wsl就进去了，跟 ssh 到一台远程服务器差不多，但体验上完全无缝。

还有一个容易忽略的理由：WSL2 对 GPU 的支持现在做得很成熟了，NVIDIA 的显卡只要装了对应的 Windows 驱动，就能通过 WSL2 直接调用 CUDA 跑模型推理，性能损失非常小。

1.3 整体架构：消息是怎么流起来的

在动手安装之前，先把整个系统的数据流向搞明白。你看懂了这张链路图，后面配置的时候遇到问题就知道往哪儿排查。

用户输入（终端或客户端） → OpenClaw Agent → 工具调用/任务编排 → Ollama API → 本地模型推理 → 返回结果 → OpenClaw 处理后回传给用户

这个链路里有几个关键点值得提一下。

OpenClaw 和 Ollama 之间走的是 HTTP API，默认地址是http://localhost:11434。这意味着 OpenClaw 本身不需要关心模型是怎么跑起来的，只要 Ollama 在监听这个端口就行。这个解耦设计非常友好——你可以今天用 Ollama 跑 Qwen，明天换了模型，OpenClaw 那边改一行配置就行。

OpenClaw 的角色不只是一个“聊天转发器”，它有自己的 Agent 逻辑，会把你的请求拆解成任务，如果需要调用工具（比如搜索本地文件、执行命令），它会先用模型做一次决策，然后执行，再把结果喂给模型做下一步推理。这个过程需要 OpenAI 兼容的 API 接口，而 Ollama 恰好提供了这个接口，兼容性做得相当好。

最后是模型的选择问题。OpenClaw 本身是模型无关的，但如果你要跑 Agent 任务，我建议至少用 7B 以上参数的模型，14B 效果会更好。因为 Agent 任务比纯对话要复杂得多，模型太小了容易出现指令理解偏差，导致工作流跑不通。

2. 核心细节解析与前置准备

2.1 硬件与系统要求：先别急着装，算明白这笔账

这一步很多人不重视，装到一半发现电脑带不动，再回头查就浪费时间了。先说最核心的：显存就是你的绩效指标。

跑 Ollama 本质上是把模型权重加载到显存里做推理，所以显存大小直接决定了你能跑多大的模型。按我的经验来划一条参考线：

如果你的显卡只有 8GB 显存，那你老老实实跑 7B 级别的模型就好，14B 用 Q4 量化理论上能挤进去，但那个速度会让你怀疑人生。

纯 CPU 推理不是不行，但你要有这个心理准备：7B 模型在 CPU 上大约每秒只能吐 3-5 个 token，一句话能等半分钟。日常体验基本属于“能跑但想砸电脑”的水平。所以我建议：没有 NVIDIA 显卡的，先去搞张显卡再玩这个；AMD 用户也别绝望，Ollama 现在对 AMD 的 ROCm 支持还可以，但配置过程比 NVIDIA 麻烦几个量级，新手不太建议选这条路。

内存方面，WSL2 虚拟机会默认占用你系统内存的 50%（Windows 11 默认配置），你最好在.wslconfig文件里手动限制一下，别让它把所有内存吃光。具体配置在后面章节给到。

2.2 提前安装：WSL2 与显卡驱动

在正式安装 OpenClaw 和 Ollama 之前，有一样东西必须先装好：WSL2 运行环境。

在 Windows 11 上，你只需要以管理员身份打开 PowerShell 或命令提示符，执行一条命令：

wsl --install

这条命令会自动启用 WSL 功能、安装 WSL2 内核、并帮你装好默认的 Ubuntu 发行版。执行完后重启电脑，就完成了一大半。

如果你的系统是 Windows 10 老版本，wsl --install可能不适用，那就需要手动开启“适用于 Linux 的 Windows 子系统”和“虚拟机平台”两个功能，然后从微软官网下载 WSL2 内核更新包。不过现在还在用 Windows 10 的确实越来越少了，这里就不展开讲。

然后就是显卡驱动。NVIDIA 用户注意：你只需要安装 Windows 版驱动，不需要在 WSL2 里面单独装 Linux 驱动，WSL2 会复用 Windows 的驱动去调用 GPU。这个设计让整个体验好了太多。

装完后在 WSL2 终端里验证一下 GPU 可用性：

nvidia-smi

如果能看到显卡信息列表，说明 CUDA 环境已经通了，可以继续往下走。这一步如果报错，多半是 WSL 版本太老或者 NVIDIA 驱动版本太旧，去更新 Windows Update 和 NVIDIA 驱动基本能解决。

2.3 内存分配：.wslconfig 的合理配置

WSL2 默认会吃掉系统 50% 内存，这在你看似“内存很大”的机器上是个坑。比如 32GB 内存的机器，WSL2 可能会分到 16GB，Windows 那边同时开浏览器、IDE、微信，内存压力一下子就上来了。

用.wslconfig文件来约束它。在C:\Users\你的用户名\目录下新建一个文本文件，命名为.wslconfig，填入以下内容：

[wsl2] memory=8GB processors=6 swap=2GB

memory=8GB的意思是给 WSL2 最多 8GB 内存；processors=6限制 CPU 核数，避免虚拟机抢占所有核心；swap=2GB在 WSL2 内存不够时会使用交换文件，防止 OOM 直接崩溃。

这里有一个细节容易踩坑：.wslconfig文件必须放在 Windows 用户主目录下，不是 WSL2 里的~目录。改完后需要重启 WSL 才会生效，命令是：

wsl --shutdown

然后再重新进 WSL2。如果你配置完发现系统内存还是吃紧，多半是没重启 WSL 服务。

3. 实操过程与核心环节：从零到跑通

3.1 Ollama 安装与模型拉取

这里我推荐先装 Ollama，因为 OpenClaw 的配置需要依赖一个已经能用的模型服务。

WSL2 终端里一键安装：

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

这个脚本会自动处理依赖，把 Ollama 安装成 systemd 服务。装完先确认一下版本和服务状态：

ollama --version

然后启动 Ollama 服务（有些版本装完不会自动启动）：

sudo systemctl start ollama sudo systemctl enable ollama # 设置开机自启

接下来拉取一个模型。我的建议是首次尝试选 7B 级别的小模型，先把链路跑通，再考虑上更大的。这里以 Qwen2.5 7B 为例：

ollama pull qwen2.5:7b

这个命令会从模型仓库拉取文件，大约 4.7GB。下载速度取决于网络情况，如果卡住了，可能是网络波动问题，用Ctrl+C停掉重新执行就好。

拉完后测试一下能不能正常出结果：

ollama run qwen2.5:7b "你好，请用一句话介绍你自己"

看到正常回复就说明 Ollama 已经跑通了。

还有一步非常关键：确认 Ollama 的 API 端口。默认监听在localhost:11434，但你从 Windows 侧访问的时候，WSL2 的 localhost 是能直接转发到 WSL2 内部的，所以不需要额外配置。测试命令：

curl http://localhost:11434/api/tags

如果返回一段 JSON 格式的模型列表，说明 API 服务没问题。

注意：如果你的 WSL2 里发现 Ollama 服务一直起不来，多半是 systemd 没启用。老版本 WSL 默认不开 systemd，需要先在/etc/wsl.conf里加[boot] systemd=true，再重启 WSL。

3.2 OpenClaw 安装：Node 环境配置

Ollama 装好后，接下来装 OpenClaw。整个过程中最容易出问题的一步就是这了。

首先需要确认 WSL2 里 Node.js 环境。OpenClaw 是 Node 写的，依赖 Node 18 及以上版本。

检查当前环境：

node --version npm --version

如果版本太低或者没装，推荐用 nvm（Node 版本管理器）来安装：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # 重新加载 shell 配置后 nvm install 20 nvm use 20

Node 版本这里我强调一下，不要装最新的 Node 22 或更高版本，实测 OpenClaw 对 Node 20 的兼容性最好。装太新的版本反而会有莫名其妙的依赖编译问题。

接着安装 pnpm。OpenClaw 官方推荐用 pnpm 管理和运行：

npm install -g pnpm

确认 pnpm 版本：

pnpm --version

然后拉取 OpenClaw 的代码仓库：

git clone https://github.com/openclaw/openclaw.git cd openclaw

这里有个小提示：如果服务器上拉代码超时或者很慢，就配置镜像源或者挂代理。这不是 OpenClaw 本身的问题，是网络环境的问题。

安装依赖：

pnpm install

这个过程会去拉大量依赖包，时间长短完全取决于网络和机器性能。正常情况下 3-5 分钟能完成。如果出现某些原生模块编译失败（常见的是bufferutil、utf-8-validate这类），需要先装编译工具链：

sudo apt update sudo apt install -y build-essential python3

3.3 配置 OpenClaw 对接 Ollama

依赖装完后，主要的配置工作集中在环境变量文件里。

OpenClaw 的配置我认为是它做得比较舒服的地方——用.env文件，极其直观，你不需要去翻一堆代码找配置项。

在 OpenClaw 项目根目录下：

cp .env.example .env

然后编辑.env文件，找到和模型相关的配置段。这里以nano .env为例：

nano .env

核心配置如下（具体键名以你版本里的 .env.example 为准，不同版本可能有轻微差异）：

LLM_PROVIDER=ollama OLLAMA_BASE_URL=http://localhost:11434 LLM_MODEL=qwen2.5:7b LLM_TEMPERATURE=0.7 MAX_TOKENS=4096

这些配置的含义逐个说一下：

• LLM_PROVIDER=ollama告诉 OpenClaw 你用的是哪个模型服务商。它支持很多家，我们明确指定走 Ollama。
• OLLAMA_BASE_URL是 Ollama API 地址。因为 OpenClaw 也跑在 WSL2 里，所以localhost就直接通到宿主机。
• LLM_MODEL指定具体用哪个模型。要跟你用ollama pull拉下来的名字完全一致，写错一个字都会报错。
• LLM_TEMPERATURE控制生成内容的随机性，0.7 是比较平衡的默认值。Agent 任务如果想更老实地执行指令，可以调到 0.3。

还有一个关键配置建议你提前改掉：

OPENCLAW_WORKSPACE_DIR=~/openclaw-workspace

这个工作目录是 OpenClaw 执行文件读写、临时任务时的工作空间。建议单独建一个目录，不要放在 OpenClaw 项目里面，不然它会去扫描管理自己的源码目录，容易出问题。

3.4 启动与验证全链路

一切配置完成后，在 WSL2 终端启动 OpenClaw：

pnpm start

首次启动会有一个初始化的过程，它可能会要求你设置一些 Agent 的名称和行为偏好。中等内存的机器上，第一次冷启动大概需要 20-30 秒，因为要加载模型到显存。

启动成功后，你在另一个终端窗口里试一下：

curl http://localhost:11434/api/generate -d "{\"model\": \"qwen2.5:7b\", \"prompt\": \"你好\"}"

这条命令是直接测 Ollama 的，排除模型层问题。如果正常返回内容，那么用 OpenClaw 的交互界面发一条消息试试。

如果你在 OpenClaw 终端里输入消息后迟迟没有回复，先检查几个地方：第一，Ollama 服务是否还在运行（curl http://localhost:11434/api/tags）；第二，.env里的模型名跟 Ollama 里拉取的是否一致；第三，系统日志有没有报错信息。

3.5 配置 OpenClaw 的完整界面与客户端

跑通命令行交互之后，如果你想更舒服地使用，OpenClaw 还自带了网页界面。启动后访问：

http://localhost:3000

这个网页界面支持日常聊天模式、Agent 对话模式、以及任务执行的历史记录查看。我在实际使用中更喜欢用网页界面，因为看任务执行过程的时候带日志输出，能直观看到 OpenClaw 每一步在干什么。

不过有一点要提醒：如果端口被 Windows 防火墙拦截了，需要手动放行。处理方法是在 Windows 防火墙里添加一条入站规则，允许 TCP 3000 端口。这一步有些人会漏掉，导致在宿主机上访问不到。

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

4.1 端口访问不通：从 Windows 访问不到 WSL2 里的服务

这是我在折腾过程中遇到最多的一个问题。症状很直接：在 WSL2 里面curl localhost:11434完全正常，但回到 Windows 的浏览器里访问localhost:3000就是连不上。

这个问题的根源要分两层排查。

第一层是 WSL2 的 localhost 转发机制。WSL2 本身设计了一条“localhost 自动转发”的通道，Windows 侧访问 localhost 时会把请求转发给 WSL2。这个机制通常默认开启，但在某些 Windows 版本上，可能因为网络配置差异导致失效。

第二层是防火墙问题。即使 localhost 转发是通的，Windows Defender 防火墙的入站规则也可能拦截对 WSL2 虚拟网卡访问。

排查建议按这个顺序来：

先在 WSL2 里确认监听地址，光监听 IPv6 的::1地址有时候会造成 Windows 侧转发失败，需要改成监听0.0.0.0：

# 检查端口监听情况 ss -tlnp | grep 11434

如果看到的是127.0.0.1:11434，在 Ollama 的系统服务配置文件里加上环境变量：

sudo systemctl edit ollama

在打开的文件里写上：

[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"

保存后重启服务：

sudo systemctl daemon-reload sudo systemctl restart ollama

这一步几乎是必踩的坑，建议安装完直接就改掉。

4.2 显存不足导致模型加载失败

跑模型的时候最怕的就是CUDA out of memory或类似的显存溢出错误。这个问题的解决办法就是换小模型或用更激进的量化方式。

Ollama 拉取的模型默认带好几档量化版本，你用ollama pull qwen2.5:7b其实拉的是 Q4_K_M 档位。如果你显卡只有 4GB 显存，那 Q4 都有些吃紧，可以考虑用带后缀的版本：

# 拉取 2-bit 量化版 ollama pull qwen2.5:7b-q2_K # 或者手动指定更小的上下文长度运行 ollama run qwen2.5:7b --num-ctx 2048

--num-ctx控制上下文窗口大小，默认是 4096，调低到 2048 能显著减少显存占用。这个是运行参数，不是拉取参数，每次运行都得带。

另外还有一个比较容易忽视的变量：WSL2 的显存分配。WSL2 默认会用掉 Windows 所有可用的显存，这在只有一个 GPU 的情况下没问题。但如果你的机器同时插了独显和核显，WSL 可能默认选择核显，导致完全跑不动模型。解决方法是把独显设为 WSL 的首选 GPU 设备，这个可以在 Windows 的图形设置里调整。

4.3 OpenClaw 任务执行超时

OpenClaw 在执行复杂任务时可能会遇到命令超时。比如它调用一个脚本跑数据，正常情况下 5 秒完成，但模型推理加上脚本执行可能耗到 20 秒，OpenClaw 默认的超时设置可能就在这种场景下让你看到 Task timeout 的报错。

在.env里把超时时间调大：

EXEC_TIMEOUT=60000

这个值是毫秒单位，60000 就是 60 秒。根据自己的任务复杂度去调，不用设得太短。

还有一个与超时相关的坑：OpenClaw 在交互终端里回复消息如果用了非 UTF-8 编码，或者带了特殊转义字符，终端显示可能乱码，但不影响实际执行。遇到这种现象不用慌，是终端显示层的问题，不是框架的 bug。

4.4 pnpm 安装依赖时报错

如果你在执行pnpm install时遇到一大堆红色报错，仔细看到底是网络问题还是编译问题。

网络超类报错一般长这样：request failed、fetch failed、ETIMEDOUT。解决办法就是在项目根目录加一个.npmrc文件，配置镜像源：

registry=https://registry.npmmirror.com

编译类报错通常是：node-gyp rebuild失败、某个头文件找不到。这种需要装编译工具链：

sudo apt update sudo apt install -y python3 make g++

其实pnpm install最常见的坑是 Node 版本太新导致的。如果你用的是 Node 22+，建议先用 nvm 切回 Node 20，再重装依赖。

实操心得：卡在依赖安装这一步超过 15 分钟的时候，不要反复重试同一个命令，先把 Node 版本换对、镜像源配好，再一次性重装。反复重试不仅浪费时间，还可能因为装了一半的缓存导致更诡异的问题。

5. 扩展玩法与实测心得

5.1 让 OpenClaw 调用多个模型

OpenClaw 的好处是你不一定绑定一个模型。在.env里可以配置多模型路由，具体方式要看项目文档，不同版本的配置名可能不一样。但主旨是一个：你可以让简单的对话走小模型（比如 3B 的轻量模型，快、省资源），复杂的 Agent 任务走大模型（比如 14B 或 32B），这样体验最舒服、资源最节约。

我在实际配置中就是用 qiwen 3B 处理闲聊，用 14B 处理代码和文档任务，效果很理想。小模型聊天快，大模型干活准，各司其职。

5.2 局域网内手机访问

如果你想把 OpenClaw 的网页界面开放给局域网里的手机或者其他电脑，光监听 localhost 是不够的。需要做两步：

第一步，改服务器监听地址。找到 OpenClaw 启动配置里的 host 参数，设置成0.0.0.0，然后重启。

第二步，Windows 防火墙放行对应端口（TCP 3000）。同时确保两台设备在同一个局域网。

手机浏览器直接访问http://你电脑的局域网IP:3000就能打开界面。这样你在客厅沙发上也能跟家里的 AI 助手聊天，不用蹲在电脑前。

5.3 性能调优实测数据

我自己测过几组数据，贴在下面供参考（测试硬件是某中端独显 8GB 显存 + 16GB 内存的笔记本）：

重点是：显存和上下文是硬资源，不要贪多；温度本质上是控制模型生成策略的“系统参数”，Agent 类任务不建议设太高，否则模型会“发挥太多”。

6. 收尾：这套组合后续还能怎么玩

在 Windows 上搭好 OpenClaw + Ollama 只是起点。我后续试着把它接到一些日常工具上后，才真正体会到这套组合的价值。

比如可以让 OpenClaw 定时抓取某些网页内容，总结后推送到手机；让它监控你指定目录下的文件变化，自动做分类整理；甚至写一个简单的定时任务，每天早上让它根据你的日历生成当天的待办清单。它本质上是一个“带手”的大模型，你只需要给 Ollama 提供一个脑子，剩下的协作逻辑都由 OpenClaw 编排。

最后分享一个个人经验：配置过程中如果一遇到报错就重头开始，很容易在同一个坑里反复消耗时间。更好的做法是把每次修改的配置都用git commit记录一下，出错的时候可以直接对比配置差异，定位问题会快很多。这套组合的配置项不算多，但每个都对运行结果有直接影响，保持配置变更可追溯是提高排查效率最有效的手段。