本地AI助手实战：openclaw + ollama 离线部署与优化指南-育师

最近我在折腾个人AI助手，目标很简单：把它完全装进自己电脑里，不依赖任何外部接口，数据不出本机。折腾下来最顺手的一套组合就是openclaw + ollama（本地）：openclaw负责做智能体执行框架，ollama负责跑开源大模型。日常让它写脚本、整理文件、翻译段落、按关键词搜索并汇总资料，基本都能在断网状态下完成。这套方案尤其适合对隐私有硬要求、又不想每个月交一堆API账单的人。

如果你也在纠结"openclaw是不是必须要接云端API才能跑""Windows下到底怎么搭""下载模型慢到想砸电脑"这些问题，这篇文章就是把我的踩坑和最终方案一次性讲清楚。

1. 为什么我坚持把openclaw的推理切成本地ollama

1.1 openclaw到底解决了什么问题

先聊清楚openclaw是什么。它本质上是一个开源的个人智能体框架，和单纯聊天机器人最大的区别是：它不只跟你对话，它会真的去执行任务。你可以让它查一个文件、批量重命名、调用命令行工具、访问浏览器、操作你授权过的系统能力，像一个"长了手"的AI助手。

早期这类Agent框架重度依赖云端模型，因为工具调用的指令遵循能力、上下文理解能力都要靠大模型支撑。openclaw也很自然地支持各家云端API，这导致很多人一上来就以为它离不开外部算力。相关搜索里很多人问"openclaw只能用接入api的方式使用算力吗"，我可以明确说：不是。openclaw本身对模型提供方做了抽象，只要模型服务暴露OpenAI兼容的接口，它就能接。而在这一点上，ollama几乎天生契合。

1.2 云端API和本地算力的取舍

我在做这个项目之前，先盘了一下自己的需求：

每天要处理大量本地文档、邮件草稿、脚本片段，这些内容不适合发到外部服务；
希望就算出差在高铁上断网，AI助手依然能处理简单任务；
不想按token付费，尤其是一些重复性工具调用，一天跑几十次，累积起来并不便宜。

于是对比就很清晰了：

对比项	云端API	本地ollama
数据私密性	内容过外部服务，有泄露面	模型和上下文都在本机
成本	按token计费	一次性搞定，电费可忽略
断网可用性	基本不可用	完全可用
模型上限	取决于服务商，闭源模型为主	取决于自己显卡，开源模型为主
部署复杂度	零，注册就有Key	装环境、下模型、做配置

对我这种场景，本地推理的优势完全压过云端。你可能担心本地模型不够聪明，确实，如果直接拿3B模型做复杂推理，效果和GPT-4级别差距明显。但Agent类任务里很多是"调用工具、读结果、再调用工具"的循环，模型只要能把意图解析对，小模型也能完成大部分任务。真正复杂的分析型工作，可以单独换大参数模型。

1.3 "openclaw只能用API接入算力"的误解从哪来的

我猜很多人产生这个误解，是因为看了默认配置。openclaw安装好之后，默认配置指向某个云端模型服务，改起来不熟悉的人会以为这是唯一写法。再加上一开始它确实不支持本地运行时，只有OpenAI兼容API这个通用接口。

但ollama出现之后，局面完全变了——它在本地起了一个完全兼容OpenAI的API服务，默认监听你机器的11434端口。你访问http://localhost:11434/v1，拿到的东西和访问远程OpenAI接口长得一模一样。所以openclaw那头不用想什么特殊协议，只需要在配置里写"我要用openai兼容方式，地址是本地，Key随便填一个"就行。前面还有一层"net/相关"的切割逻辑，ollama就是那个把"云端模型"替换成"本地模型"的中间层。

搞清楚这一点之后，整个搭建思路就非常顺了。

2. 搭建前最好自查的三件套：WSL2、Node.js、模型存放位置

2.1 "openclaw无法安全验证sl2环境"是怎么来的

这个报错几乎只在Windows上出现。openclaw很多底层工具依赖Linux环境，Windows下它需要借助WSL2来跑这套生态。如果你的机器没有正确安装WSL2，首次启动openclaw时会直接提示类似"无法安全验证sl2环境"的报错，有些版本还会给出引导：让你在PowerShell里运行wsl --status去检查环境。

我遇到的情况就是这样，打开PowerShell执行：

wsl --status

如果输出里能看到"默认版本：2"，说明WSL2基本就绪；如果提示没有已安装的发行版，或者内核组件缺失，走下面几步：

wsl --install

安装完成之后按提示重启系统。如果系统已经比较老，可能需要单独补一下Linux内核更新包，然后再执行：

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

还有一个小坑：WSL2依赖CPU虚拟化，如果BIOS里把虚拟化关了，装半天也起不来。可以在任务管理器"性能"页里看一眼"虚拟化：已启用"，如果不是，进BIOS找Intel VT-x或者AMD SVM打开。

想更省事的伙伴可以直接在WSL2里装一个Ubuntu发行版，把openclaw装进Linux子系统，日常使用反而更贴近官方支持环境，报错也更少。不过我个人还是选择了Windows原生加WSL2配合的方式，主要是不想来回切换终端窗口。

2.2 Node.js安装与npm全局工具链

openclaw本身是Node.js生态的项目，安装依赖npm。我用的Node是20 LTS版本，实测下来比18稳定，至少没遇到TS语法层面的兼容报错。

到Node官网下LTS版，下一步下一步装完，然后在命令行验证：

node -v npm -v

接着直接全局安装openclaw：

npm install -g openclaw

如果你在Linux或者WSL2里装，有时候会遇到EACCES: permission denied的全局权限问题，那是因为npm默认全局目录对当前用户不可写。最快的办法不是去改目录权限，而是用nvm装Node，这样npm全局目录就在用户目录下，整个安装过程基本不会碰权限问题。

Ubuntu下还有一个细节：装完openclaw之后，命令入口可能不在PATH里。通过nvm安装的用户一般没问题，如果是apt装的Node，可能要手动把/usr/bin下的软链检查一遍。看到bash: openclaw: command not found时不用慌，先去看npm config的global prefix是不是出了偏差。

2.3 ollama模型别一股脑堆C盘

ollama安装相对简单，但有一个问题特别容易忽视：模型文件默认存储在用户目录下，在Windows一般是：

C:\Users\你的用户名\.ollama\models

如果你打算跑7B甚至14B的模型，一个文件动辄4GB、8GB，再多拉几个模型，C盘很快就红了。我会强烈建议在装模型之前先把模型目录迁走。

Windows下修改方式：

在"系统属性 -> 环境变量"里为当前用户新建一个变量；
变量名OLLAMA_MODELS，变量值填你想放模型的位置，例如D:\ollama-models；
保存后完全退出ollama进程，再重新启动。

然后下载一个新模型试试，用ollama list看模型信息，或者直接去目标文件夹看有没有生成models目录。如果文件出现在新位置，说明环境变量生效了。

这里有个容易踩的坑：如果你之前已经下载过模型，改完环境变量后旧路径里的模型不会被自动迁移。我迁移的时候是手动把C:\Users\xxx\.ollama\models整个复制到新盘，再改环境变量，这样就不用重新下载那几十个G。

另外说一个安全提醒：有些第三方网站提供"ollama加速下载"，却要求你填手机号注册。官方ollama下载页面根本不需要填电话，凡是有这个环节的，我建议直接关掉页面，老老实实走官方渠道或者用离线模型文件导入，具体方法下一章讲。

3. 三分钟跑通：openclaw对接ollama的完整链路

3.1 配置指向：ollama就是本地版OpenAI API

整个对接的核心就一句话：让openclaw认为自己在连一个OpenAI兼容的API服务，只不过这个服务跑在你自己的机器上。

先启动ollama服务。Windows桌面上装了ollama之后它会常驻后台；命令行里也可以手动确认：

ollama serve

正常情况下这个命令会一直挂着，监听11434端口。确认没问题后，再拉一个模型，比如：

ollama pull qwen2.5:3b

然后去openclaw的配置文件里，把模型提供方改成openai兼容模式。不同版本的openclaw配置项名字可能不太一样，但大致结构是这样（我这里以我实际用的配置为例）：

{ "modelProvider": "openai", "model": "qwen2.5:3b", "openaiUrl": "http://localhost:11434/v1", "openaiKey": "ollama" }

其中openaiKey填什么都无所谓，Ollama本地服务默认不校验Key，随便填一个"ollama"就能过。如果你用的是新版openclaw，它也可能用的是llmProvider之类字段，以官方文档为准，原理都一样。

配置保存后重启openclaw会话。如果配置正确，它启动时会去检查模型列表是否可用。我之前遇到的坑是在这一步直接报连接失败，十有八九是ollama没启动，或者端口被别的进程占了。

3.2 模型名怎么填才不翻车

openclaw配置里的model字段必须和ollama里的标签完全一致，不能自己发挥。ollama里模型标签的格式是模型名:参数规格，比如：

qwen2.5:3b代表Qwen2.5 3B版本
qwen2.5:7b代表7B版本
llama3.1:8b类似

想确认自己到底装了哪些模型，运行：

ollama list

输出里的"NAME"列就是你能用的合法标签。很多人不知道怎么把qwen2.5-3b关联到openclaw，其实就是去ollama list里抄对应的名字，填进配置，没有第二个坑。

如果要按任务分工来配模型，我自己的经验是：工具调用和脚本生成这类任务用3B/4B级模型，响应快，基本指令也够用；需要长文本理解、复杂代码分析的时候，切到7B甚至14B模型。openclaw支持在不同场景下指定不同模型，初期配置不必贪多，先跑通一个再慢慢加。

3.3 验证链路：确认openclaw是真的在用本地模型

配置完了怎么确认它没偷偷连外部服务？两个办法。

第一个，看ollama的活跃模型加载情况。给openclaw发一个任务，同时在命令行执行：

ollama ps

如果看到"模型名"下面有正在运行的进程，说明openclaw刚才确实把请求发到本地ollama了。

第二个，更硬核一点，把网络断掉再让openclaw干活。我测过直接把无线网卡禁用，然后让它执行一个简单的文件整理任务，它依然能正常完成。这基本可以说明整个链路是完全本地的。

如果你在Windows上用Windows Companion来管理openclaw，还得多一步：在配套面板里把系统授权打开，包括文件访问、终端执行、麦克风等。有些能力openclaw不会默认申请，只有在授权之后才会出现在工具列表里。配好授权之后建议重启一次会话，让工具列表重新加载。

4. 翻车重灾区：从下载慢到serve段错误的修复记录

4.1 ollama拉模型太慢：离线GGUF导入是最稳的绕行方案

ollama官方模型仓库下载速度不稳定这个问题，很多人一上来就撞到。下载到一半断开重来，重来又慢，非常折磨。针对这个事我试过几条路，最后稳定下来的是离线GGUF导入法。

先说原理：ollama模型本质上也可以从GGUF文件构建。社区里大量模型会以GGUF格式发布，你完全可以绕过ollama官方下载通道，从网盘、ModelScope或者Git镜像站把模型文件拿到本地，再用ollama导入。

具体步骤：

下载对应模型的GGUF文件，比如Qwen2.5 7B的某个量化版本，文件名通常是qwen2.5-7b-instruct-q4_k_m.gguf；
在本地建一个目录，把GGUF文件放进去，并在同目录下创建Modelfile：

FROM ./qwen2.5-7b-instruct-q4_k_m.gguf

执行导入命令：

ollama create qwen2.5-7b -f Modelfile

跑起来验证：

ollama run qwen2.5-7b

这个方法的好处是，只要你能把GGUF文件搞到手，导入基本没有网络压力。要注意一点：GGUF的量化版本决定了工具调用时的回复质量，Q4_K_M在体积和效果之间比较均衡，资源特别紧张再考虑Q3，否则不建议。

4.2 ollama serve段错误：先看日志再动环境变量

ollama serve出现段错误，是我在Windows上遇到比较头疼的问题之一。现象是服务一启动就崩，或者跑着跑着进程消失，日志里出现segmentation fault相关字样。

我的排查顺序是：

先看ollama日志。Windows下日志一般在%LOCALAPPDATA%\ollama\logs，看启动阶段有没有明确报错；
如果日志指向GPU相关，十有八九是显卡驱动太旧，或者显存不够加载模型层；
更新NVIDIA驱动之后问题依旧，再尝试限制GPU参与度：
- 设置环境变量OLLAMA_NUM_GPU=0强制CPU推理，验证是否GPU相关；
- 如果CPU模式正常，说明问题出在GPU推理链路，可以考虑只加载少量层到GPU，比如OLLAMA_GPU_LAYERS=1；
机器显存偏小的话，再加一个OLLAMA_MAX_LOADED_MODELS=1，避免多个模型轮换加载把显存挤爆。

这类段错误有个规律：绝大多数不是配置语法问题，而是GPU资源分配和驱动兼容问题。我自己最后是用"更新驱动+限制GPU层数"解决的，如果你也卡在这，优先顺着这个方向查，成功率很高。

4.3 让gemma3/gemma这系列模型别再"想太多"

有不少人看到搜索里"如何关闭ollama里gemma4的思考过程"，这个需求本质上是：有些带推理能力的模型，回答之前会先输出一大段内部思考内容，在openclaw这种不断调用工具的场景里，这些思考会拖慢响应，有时候还会混进工具调用参数里，导致解析出错。

处理方法有三个：

最简单：换标签。在ollama模型库中，同一个模型常分"带思考"和"不带思考"的版本，你拉的时候看清楚标签，不带it或thinking字样的版本就没有默认思考过程。
如果已经拉成了带思考的版本，可以在提示词里明确要求"直接输出结果，不要展示思考过程"，实测对多数模型有效。
如果接口层支持关闭推理开关，直接关掉更干净。但ollama不同版本支持度不一样，没有统一开关，我是以"换标签"为主。

多嘴一句代价：关掉思考过程之后，模型回答的深度会下降一些，尤其是数学逻辑和长文分析不那么严谨。但对openclaw这种以工具调用为主的任务，响应速度的价值大于深度思考，该关就关。

4.4 卸载openclaw的正确姿势

有人装完发现环境不对想重来，或者干脆不想要了。卸载分几步：

如果你是用npm全局安装的，先执行：

npm uninstall -g openclaw

然后手动删除用户目录下的配置文件夹，通常叫.openclaw，里面包含了配置、历史会话、skills等数据。Windows下路径一般是C:\Users\你的用户名\.openclaw，Linux下在~/.openclaw。
如果你的openclaw注册了系统服务或者计划任务，比如Windows Companion相关的后台进程，去"服务"管理器把对应服务停用并删除。这一步常被遗漏，导致卸载之后开机还有一个残留进程。
想保留聊天历史再卸载的话，先把.openclaw目录备份一份，之后重装还能接着用。

5. 本地Agent不止对话：RAG、反代和手机端的扩展

5.1 给ollama配一个简易本地RAG知识库

openclaw跑起来之后，很多人第二个需求就是"让它能回答我私人文档里的内容"，这就绕不开本地RAG。RAG全称是检索增强生成，说白了就是把文档切块、向量化、存起来，用户提问时先找出最相关的几段，把内容拼到提示词里让模型回答。

ollama做这件事很方便，因为它本身就提供embedding模型。我常用的是nomic-embed-text或者bge-m3，拉取命令：

ollama pull nomic-embed-text

然后写脚本调用Ollama的/api/embeddings接口，把文档段落转成向量。不需要上重型向量数据库，小项目直接存成JSON或SQLite都够用。查询时同样转向量，计算余弦相似度取出Top-K段落，拼进system prompt再发给模型。

我实测下来，这种轻量RAG对几百个文档片段以内的场景非常实用，不需要额外起服务。注意一点：embedding模型和文本生成模型（如qwen2.5:7b）是两回事，别用一个生成模型去当embedding用，维度对不上，效果也差。

5.2 用FastAPI给ollama套一层可控的封装

如果ollama只在自己本机用，直接连11434就行。但你要是家里有几台设备，想让手机、笔记本都能调用，裸连11434又不太放心。我就在中间加了一层FastAPI服务，做统一鉴权和日志。

核心逻辑很简单：FastAPI收到请求后，再转发到ollama的/v1/chat/completions。给一个最小参考：

import os from fastapi import FastAPI, Header, HTTPException import httpx app = FastAPI() OLLAMA_URL = "http://127.0.0.1:11434/v1/chat/completions" MY_API_KEY = "your-local-key" @app.post("/v1/chat/completions") async def chat(conversation: dict, authorization: str = Header(...)): if authorization != f"Bearer {MY_API_KEY}": raise HTTPException(status_code=401, detail="bad key") async with httpx.AsyncClient() as client: resp = await client.post(OLLAMA_URL, json=conversation, timeout=120) return resp.json()

之后openclaw的外部访问地址改成你自己的FastAPI地址，Key也改成你自己定义的那个。这样做的好处是：即便以后你想在网关前加一层权限控制、请求计数、或者把某些请求导到云端大模型做兜底，都有统一入口。

5.3 nginx反代ollama并加API Key

有不少人问过"nginx代理ollama设置apikey"这个事。其实核心就两步：给ollama本身开启API Key校验，再用nginx做反向代理。

ollama较新版本支持通过环境变量OLLAMA_API_KEY开启Bearer鉴权。设置之后，所有请求必须带Authorization: Bearer xxx，否则拒绝。

nginx侧配置大致如下：

server { listen 11435; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header Authorization $http_authorization; } }

这样外部设备只访问nginx的11435端口，而ollama的11434可以继续只监听本机，减少暴露面。

这里我特别要提醒一句：不要把ollama裸奔到公网，如果没有鉴权保护，等于把你的显卡资源免费共享给整个互联网。就算加了Key，也要注意Key的传输安全，尽量只在可信局域网内暴露。

5.4 Termux手机端：能跑，但别期待太高

很多人想用手机装openclaw，相关搜索里还有"termux安装openclaw手机版下载步骤"。这个我可以明确给出结论：能装，但本地模型推理体验比较局限。

Termux是Android上一个终端模拟器，可以装Node.js和npm，所以跑openclaw这个Node项目本身没有大障碍：

pkg install nodejs-lts npm install -g openclaw

但是ollama没有官方Android版本，在手机上跑本地模型通常要靠Termux里的Linux容器方案，对处理器、内存、调度策略都有很高要求。实测3B模型勉强能跑，7B以上基本是PPT级速度，输出一个字等半天。所以我一般建议：手机端装openclaw更适合当"远程遥控器"，真正推理还是交给家里或办公室那台有显卡的电脑。openclaw本身支持连接远程模型服务，你把地址指向局域网里的ollama网关，手机就变成了一个移动控制端。

另外说一点，如果你的手机性能确实很强，比如8GB以上内存的旗舰机，装一个4B模型做简单角色聊天、外语翻译问题不大，但要驱动Agent一次次调用工具，体验大概率会让你失望。别指望手机端成为主力算力来源。

做完这一整套之后，我最大的体会是：本地Agent能不能用得爽，其实主要被拖后腿的从来不是"模型聪不聪明"，而是链路稳不稳。所以我的建议也很简单——先用一个3B或4B小模型把openclaw跑通，确认工具调用、模型加载、会话恢复这些流程都正常，再慢慢加参数量、加RAG、加远程访问层。先让流程顺手，再谈模型聪明，这套组合才能真正代替你每天重复的琐事。