淘房记OpenClaw 这个词最近在自托管圈子里出现的频率越来越高。简单说，它是一个能“住”在你电脑里的开源个人助理，可以调用本机工具、读写文件、操作浏览器，也能按你的节奏帮你处理日程和邮件。而我要做的这件事，是把它背后那套依赖云端接口的对话引擎，换成完全跑在本地的 Ollama。这样做的直接好处是：没有 API 账单，没有数据出本机，断网也能继续折腾。
这篇文章不是官方文档翻译，而是我自己把 OpenClaw 接到 Ollama 上的一次完整记录。我会把选型逻辑、安装过程、配置细节、踩过的坑和现在的使用习惯全写出来。不管你是第一次接触本地大模型，还是已经在玩 Ollama 但想让一个“带手带脚的助理”接管本机，这篇都能给你一条可复现的路线。
1. 整体思路：为什么要在本地跑一套 OpenClaw
1.1 它到底是个什么东西
OpenClaw 本质上是个“本地优先”的 AI 助理框架。它和那些只能在对话框里聊天的网页助手不一样，它被设计成可以直接操作你电脑上的资源：读文件、改文件、跑命令行、打开网页、管理日历和密码，甚至在授权后帮你点鼠标。你可以把它理解成一个“有权限并使用工具的 AI 外壳”，而它的大脑是可以替换的。
这一点特别关键。因为它没有把自己锁死在某一家大模型厂商上，而是通过一个相对独立的模型层接口去接后端。这个后端可以是云端商业化模型，也可以是本地模型运行时。于是“把大脑换成 Ollama”并不是魔改，而是它本来就支持的接入方式，只是很多人默认用了云端接口，忽略了本地这条路。
1.2 为什么选 Ollama 而不是各家云服务
我最早也试过直接接云服务。但用了一阵之后，几个问题特别明显。首先是隐私：OpenClaw 这类工具经常要读取本机邮件、日历、聊天记录，如果全部发给云端，等于把你整台电脑的生活细节都送了出去。其次是成本：只要开着长会话，token 消耗就像漏水一样，几天不看账单就吓一跳。还有一个被很多人忽略的问题：云端接口只负责“对话”，但 OpenClaw 的核心价值是“工具调用”，它需要模型具备稳定的结构化输出能力，而许多云端免费档模型在这一点上限制很多。
Ollama 解决的是“模型跑在哪里”的问题。它是一个本地的大模型运行时，支持把常见开源模型量化后在个人电脑上跑起来，同时提供一套和业界主流接口兼容的 API 服务。这意味着 OpenClaw 可以像调用远程接口一样去调用本地的 Ollama，但数据全程不走局域网之外。对于一些对隐私敏感的场景，这基本是当前最省心的方案。
1.3 这套方案的边界在哪里
先说清楚，本地化部署不是万能的。没有“既要又要”这回事。用 Ollama 接 OpenClaw，最大的代价是模型能力上限。你在本地能跑得动的开源模型，和云端顶级模型在复杂推理、长文书、代码生成上确实有差距。尤其 OpenClaw 要执行的是一连串“规划-调用工具-观察结果-再规划”的循环，如果模型理解力不够，它可能会拿一个不存在的文件路径去调用工具，或者干脆在错误的目录里翻东西。
所以我的整体思路是：先接受这个边界，再通过模型选型、上下文配置、任务拆解去尽量抹平它。下面的部署和调优全是围绕这个目标来的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备与安装
2.1 硬件配置建议
本地跑大模型，硬件是第一个绕不开的话题。我非常务实地说：想流畅玩 OpenClaw，16GB 内存是起步线，32GB 会更从容。Ollama 支持让模型的一部分权重跑在显存里，但大多数人的电脑显存没那么大，所以内存带宽和容量反而更决定体验。
模型方面，我建议先别盯着几十 B 的大模型。对 OpenClaw 这种需要频繁工具调用的场景，7B 到 8B 级别的量化模型已经能跑出可用的效果。如果你有独立显卡且显存在 8GB 以上，可以试试 13B 或 14B 的量化版本。以 7B 模型为例，量化后体积大约 4GB 到 5GB，加载起来内存占用在 6GB 到 8GB 之间，日常使用不会把机器拖死。
我的主力机器是 32GB 内存外加一块 6GB 显存的旧显卡，实测跑 7B 模型时，Ollama 会把一部分层放到显存，剩下的用内存，整体还能同时开十几个浏览器标签页不觉得卡。但如果你只有 8GB 内存，最好还是先评估一下要不要跑这套。
2.2 安装 Ollama 并准备模型
Ollama 的安装可以说是我见过所有本地模型工具里最省心的。Windows 和 macOS 都有现成的安装包，下载后一路下一步就行。Linux 用户更简单，官方的便利安装脚本一条命令就能搞定：
bash复制curl -fsSL https://ollama.com/install.sh | sh
装完先把服务跑起来，Ollama 在大部分系统上会自动注册成后台服务。如果你是在服务器或者 WSL 里手动管理，可以用：
bash复制ollama serve
默认情况下，服务会监听本机的 11434 端口。这个端口就是之后 OpenClaw 要连接的地方。验证方式很简单，浏览器访问 http://127.0.0.1:11434 如果能看到一句“Ollama is running”之类的话，就说明服务已经就绪。
接下来拉模型。我用的主力模型是 Qwen2.5 的 7B 指令版：
bash复制ollama pull qwen2.5:7b
为什么要选它？因为 OpenClaw 的很多操作依赖模型输出结构化的工具调用结果，而 Qwen 系列在函数调用和指令跟随上的表现，在同尺寸模型里算是有口皆碑。除了它，Llama 3.1 8B 也可以试试，但在复杂工具调用上我个人觉得 Qwen 更听话一些。
2.3 安装 OpenClaw 本体
OpenClaw 本身的安装方式，不同版本差别不小。我以当时实测通过的源码部署为例。你需要先准备好 Node.js 20 以上的运行环境，然后从你信任的渠道把 OpenClaw 的源码包拿到手，或者直接用包管理工具安装发行版。
如果你走源码路线，常见启动方式大致是：
bash复制npm install
npm run dev
如果你用的是二进制分发包，那一般就是解压以后直接执行那个可执行文件。不管哪种方式，装完先跑一个自带的自检命令，看看能不能输出版本号。这一步别跳，很多问题都是环境没装干净，后面排查会特别痛苦。
2.4 连接前的网络与服务检查
OpenClaw 和 Ollama 之间走的是本地 HTTP 请求，不存在公网出入口。但这不代表你不用检查网络。我遇到过最蠢的问题就是 OpenClaw 已经装好，Ollama 也在跑，但 OpenClaw 怎么都连不上，后来发现 Ollama 把服务绑在了 IPv6 的地址上，而 OpenClaw 默认用 IPv4 去连。
所以联调之前，先做两个检查。
第一，确认 Ollama 监听的地址是 0.0.0.0:11434 或者 127.0.0.1:11434。你可以这样看：
bash复制ollama list
只要能列出模型，就说明服务端是通的。
第二，用命令行直接模拟一次模型调用：
bash复制curl -X POST http://127.0.0.1:11434/api/generate -d '{"model": "qwen2.5:7b", "prompt": "你好"}'
能收到一句回复，说明模型加载正常。这一步顺利，再去折腾 OpenClaw 的配置，才不锅锅都是 Ollama 的。
3. 把对话引擎切到本地
3.1 服务配置与端口
OpenClaw 的模型后端默认可能是往云端发请求的，我们需要手工把它指到 Ollama 上。配置方式根据版本不同大致有两种：一种是在启动时用环境变量指定，另一种是改它运行时读取的配置文件。
我用的配置文件长下面这样。字段名你可能因为版本不同看到不一样的名字，但思路是一致的，就是一个“model provider 的 base URL 指向本地，模型名填你在 Ollama 里拉好的名称”：
yaml复制provider: ollama
ollama:
base_url: http://127.0.0.1:11434
model: qwen2.5:7b
api_key: ollama
context: 8192
这里有两个容易忽略的点。第一，有些版本即使接本地 Ollama，也会要求你把 api_key 填一个非空字符串，否则会在鉴权环节直接拒绝你。我填的是一段你没看错、我也没有写任何密钥的占位字符串。第二，context 这个参数不是越大越好。它决定模型能看到多少历史内容，但同时也直接吃掉内存。7B 模型开到 8K 上下文是我实测内存占用和交互流畅度的平衡点，再往上内存会明显吃紧。
3.2 模型选择与上下文长度
很多人会忽略 OLLAMA_KEEP_ALIVE 环境变量，其实它很关键。默认情况下，Ollama 会把加载过的模型一直留在内存里，方便你下次秒回。但如果你机器上不止拉了一个模型，OpenClaw 在调用 A 模型，你又手动去测 B 模型，内存就会被两个模型同时占住。我习惯在 Ollama 的启动环境里加上：
bash复制OLLAMA_KEEP_ALIVE=5m
这样模型空闲 5 分钟就从内存里退出，内存占用会干净很多。代价就是，如果你隔了很久再让 OpenClaw 工作，它要等模型重新加载，首条回复会慢上十几秒甚至半分钟。这算是个防御性的取舍，不强求。
3.3 功能模块的本地化开关
OpenClaw 之所以能“干活”，是因为它可以挂载各种各样的工具模块。但工具模块并不全都适合本地化。某些模块默认会去连第三方服务，比如在线文档同步、云端邮件查询之类的，这些即使你用了 Ollama，也仍然会把数据送到外部。所以本地化部署不只是换个模型接口，还要把工具调用链路上的所有外部依赖都梳理一遍。
我的做法是，先只开放纯本地的模块：文件读写、命令行执行、本地日程文件解析、浏览器自动化。那些需要登录云账户的模块全部关掉。等整条链路跑顺，再按需逐个打开。这也是我非常推荐新手先做的事：不要一上来就贪多，否则出问题都不知道是模型问题还模块配置问题。
3.4 验证一条完整链路
配置完成以后，验证方式绝对不是在聊天窗口问“你好”。OpenClaw 的核心价值是工具调用，所以你必须让它做一个真实的小任务。我当时的测试任务是“在当前目录下新建一个 test.txt，里面放一句话，然后读出来打印给我”。
如果配置正确，你会看到流程大致是这样：OpenClaw 内部先向 Ollama 发请求说明任务，模型返回一个“调用文件系统工具”的结构化指令，OpenClaw 执行完把结果喂回模型，模型再生成一句总结。这个过程如果一步卡住，问题通常集中在三处：模型没有返回工具调用指令、工具执行没有权限、工具输出格式没被模型理解。后两步在本地部署里尤其常见，因为本地文件路径和系统权限比云端复杂得多。
4. 实操中的常见问题与排查
4.1 错误现象与解决办法对照表
这里把我实际遇到过几次的问题整理成了一张表，基本覆盖了我会在社区里看到的新手提问。
| 现象 | 可能原因 | 处理办法 |
|---|---|---|
| OpenClaw 启动后报连不上 11434 | Ollama 服务没有启动 / 绑定地址不对 | 手动执行 ollama serve，检查 netstat 里的监听地址 |
| 对话能回，但工具调用总是失败 | 模型本身不支持稳定的函数调用，或者上下文被截断 | 改用 Qwen 这类工具调用友好的模型；调大 context |
| 第一次回复特别慢，之后正常 | 模型冷启动，权重刚读入内存 | 先 ollama run qwen2.5:7b 预热，或者保持 OLLAMA_KEEP_ALIVE 调长 |
| 长时间挂机后系统变卡 | 模型一直驻留内存 | 把 OLLAMA_KEEP_ALIVE 设为 5m |
| 文件工具执行时报无权限 | 本地系统权限限制 | 检查 OpenClaw 进程是否有当前用户权限，macOS 还需要在辅助功能列表里给它勾选权限 |
| 总生成重复无效的工具调用 | 上下文堆了太多垃圾历史 | 清空会话，或者把 context 调低，减少历史噪声 |
4.2 几个容易被忽略的细节
我在整个折腾过程里，最大的收获不是学会了看日志，而是意识到“本地化不是一个开关，而是一套链路”。
第一是版本匹配。OpenClaw 迭代速度很快，Ollama 也会有模型格式更新，这两个项目之间的接口兼容性偶尔会出现偏差。如果两天前还能用的部署，今天启动却报错，先去看看两边版本是不是都有更新。具体到做法：记录当前跑的版本号，遇到异常先回滚最近一次的版本变动。
第二是 PATH 环境变量。OpenClaw 在调用命令行工具的时候，拿到的其实是一个子进程环境。如果你平常装在系统级目录里的工具，比如 Python、Node，OpenClaw 的子进程访问不到，就会出现“明明文件能读但工具执行失败”这种诡异问题。解决办法是先确认 OpenClaw 能拿到和你当前 shell 一样的 PATH，或者干脆把这个子进程的路径配置写死到绝对路径。
第三是大写小写的路径问题。Windows 下这倒不严重，Linux/macOS 下文件路径区分大小写，而有些模型在生成工具参数时，会把路径里的 /home/user/ 写成 /Home/User/。这种错误模型自己发现不了，你光看日志会无数次怀疑是权限问题。别问我怎么知道的。
4.3 内存和显存不足时的调整手段
如果你机器配置偏低，跑起来明显卡顿，建议按这个顺序调整。
先把模型换成体积更小的量化版，比如从 qwen2.5:7b 换到 qwen2.5:3b，流畅度会立刻提升，代价是理解和规划能力下降。再降低 context，比如从 8192 降到 4096，内存占用能省不少。如果还不行，把 OpenClaw 里所有非必需的工具模块全部关掉，减少模型需要阅读的工具说明文本长度。因为工具越多，模型在每次决策时就要把每个工具的 schema 都过一遍，这部分也是占上下文空间的。
我给一个具体的判断参照：7B 模型、8K 上下文、内存占用大约 8GB；降到 3B 模型、4K 上下文，内存占用可能只有 3GB 到 4GB。想要流畅体验，内存最好留出至少模型的 1.5 倍空间，不然系统交互本身会受影响。
5. 本地化 OpenClaw 的日常使用
5.1 几个真实可复用的场景
完全跑通之后，我开始把 OpenClaw 当作一个“只在本机活动的助手”来用。
第一个场景是整理下载目录。这活儿看起来很粗糙，但实际效果比我预想的好。我每天会下载各种资料，散落得到处都是。我会对 OpenClaw 说“把下载文件夹里最近三天的文件按扩展名分类，重命名并移到对应目录”，它每次都会先把目录列表读一遍，然后逐个执行移动规则。虽然偶尔需要我纠正规则，但省掉的是完全不想做的手工操作。
第二个场景是生成周报草稿。我把一周的工作日志文件喂给它，让它按照某个模板提炼出一份周报。因为数据完全不出本机，我可以放心地把一些内部代号都写进去。它生成的文字质量肯定没法和云端大模型比，但作为草稿已经足够我用。
第三个场景是浏览器自动化。OpenClaw 可以打开网页、模拟点击、提取页面内容。我试过让它每天早上自动查一下天气预报并生成当天的出行建议，全程本机运行。这类小任务对 7B 模型的压力不大，效果也比较可靠。
5.2 权限隔离与隐私注意
我用这套方案最核心的诉求就是隐私，权限隔离就必须要认真做。
我的建议是给 OpenClaw 单独建一个系统用户，或者至少在操作系统中限定它能访问的目录范围。很多助手框架默认有“读取用户主目录”的能力，但这不代表你真要让它全盘可读。我早期图省事给了它全目录权限，结果有次它把一个我根本不想移动的配置文件挪走了。不是它恶意，是它理解错了。从那以后我就只给它指定几个工作目录，比如 Downloads、Documents/OpenClaw、临时目录，其他一律拒绝。
还有一点，OpenClaw 支持的哪些模块需要网络权限，你要心里有数。即便用了 Ollama，模型是在本地，但如果某个工具模块会自发地调用外部服务，数据还是会出去。我在前面提过，默认只开纯本地方工具，就是不想留这个口子。
5.3 后续还能怎么玩
这套部署稳定运行后，可以扩展的方向其实很多。
我接下来准备做的是把 Ollama 同一个模型跑成两个服务，一个给 OpenClaw 用，一个给我自己的日常问答工具。避免两个入口抢同一个模型加载实例。另一个方向是想办法把 OpenClaw 接上本地的邮箱存储和日历文件，做一个完全离线的“个人行程助理”。
如果你想更疯一点，可以试试把多个小模型做成一个路由：简单指令走 3B 模型，复杂任务再用 7B 模型处理。OpenClaw 本身不支持这个，但你可以在它和 Ollama 之间再套一个轻量级网关。这就需要自己写一点点代码了，不过玩法确实多。
最后分享一个小技巧。本地模型在换模型时，容易残留“旧模型的说话习惯”，比如你从 Llama 切到 Qwen，OpenClaw 的行为风格不会立刻切换干净。这时候最简单的方法不是清空配置，而是把会话上下文彻底清一遍，让新模型重新开始。这个动作看起来无害，实际上解决了很多“怎么还这么蠢”的困惑。