怀古游戏宅SIR先说结论：如果你最近在折腾本机智能体，想把 OpenClaw 这类轻量级应用服务器和 Ollama 本地大模型串起来，这套部署组合是目前性价比最高、也最省心的方案之一。我这边刚在一台 Windows 11 工作站上完整走了一遍，中间踩了下载慢、目录占用、旧审批文件不兼容、端口起不来好几个坑。这篇教程不吹概念，只讲实际操作，从环境准备到第一次让本地模型干活，每一步都写清楚我为什么这么做、遇到问题怎么定位。
这篇文章适合三类人：一是想在本机搭一个私有智能体服务、又不想把所有对话数据送到云端的人；二是已经装过 Ollama 但只停留在问答界面，想让它被真正的应用框架调度起来的人；三是准备把整套方案搬到云服务器上做长期服务，需要提前了解目录结构和权限机制的人。下面的内容按我的实际部署顺序走，过程中涉及路径的地方我会同时给 Windows 和 Linux 的写法，方便你对照。
1. 先把架构关系捋清楚：OpenClaw 和 Ollama 分别负责哪一块
1.1 大模型本地化不等于装个聊天窗
很多朋友以为“大模型本地化”就是把 Ollama 装上，然后在命令行里敲几句对话就算完事。这种理解不能说错，但离真正可用还差一大截。因为你的真实需求往往不是“和模型聊天”，而是“让一个智能体去执行任务”——比如读工作区里的文件、调用本机命令、按计划生成文档。聊天窗只能把模型能力暴露成一个问答入口，而真正的任务编排、工具调用、权限审批这些事，它一概不管。
所以我把这套方案拆成两层：底层是 Ollama，它负责模型本身的加载、推断、显存管理，对外提供 API；上层是 OpenClaw，它负责接收任务、拆解步骤、决定要不要执行某些本机操作，然后通过兼容 OpenAI 的接口去调用 Ollama 里的模型。简单说，Ollama 是发动机，OpenClaw 是驾驶舱，两个协同工作才是一台完整的车。
1.2 为什么选 OpenClaw 而不是自己写脚本调度
我自己也试过用 Python 脚本直接请求 Ollama 的 API，写个简单的对吧？但一旦任务复杂度上来，脚本就会变得非常难维护：要自己处理上下文、要管理工具调用的白名单、要记录每次执行的历史、还要想明白哪些指令被允许哪些被拒绝。这些正是 OpenClaw 这种轻量级应用服务器已经解决好的问题。
它有几个设计非常贴合本地部署场景：第一，工作区机制，默认目录类似 c:\users\administrator\.openclaw\workspace，智能体只能在这个范围内读写文件，避免乱动系统目录；第二，exec 审批机制，每当模型想执行一条命令，都会经过一个授权判断，审批规则存在 exec-approvals.json 里；第三，模型提供商配置灵活，既可以直接指向本机 Ollama，也可以指向公司内部的中转网关。对我这种不想被云平台绑死的人来说，这套结构刚好合适。
1.3 部署完成后的目标形态
在开始动手之前，我先把最终要达成的形态列出来，这样后面每一步都知道自己在为什么而做：
| 角色 | 进程/服务 | 默认端口 | 配置与数据位置 |
|---|---|---|---|
| 模型推理引擎 | Ollama | 11434 | Windows 默认在 %USERPROFILE%\.ollama，我改到了 D 盘 |
| 应用服务器/智能体运行时 | OpenClaw | 按安装配置指定 | 用户目录下的 .openclaw，包含 workspace 和审批文件 |
| 模型文件仓库 | 由 Ollama 管理 | - | OLLAMA_MODELS 环境变量指定位置 |
最终效果是：我向 OpenClaw 发起一个任务，OpenClaw 通过 http://127.0.0.1:11434/v1 这个 OpenAI 兼容端点调用 Ollama 里的模型，模型产出计划后，OpenClaw 在工作区内执行文件读写或命令调用，整个过程中模型权重、对话数据、工具执行记录全部留在本机。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备：Windows 11 上最容易出问题的几步
2.1 硬件方面的底线建议
先说硬件，因为很多人卡在“装好了但跑不动”这个环节上。我的主力机是 NVIDIA 显卡、16GB 显存，跑 14B 以下的量化模型很从容。如果你只有 8GB 显存，那就老老实实选 7B/8B 的 Q4 量化版；没有独立显卡也不是完全不能玩，纯 CPU 推理跑 3B/4B 模型可以出结果，就是速度比较“养生”，一句话可能要等十几秒。
我的建议是第一次尝试时先上一个小模型把流程跑通，比如 qwen2.5:3b 或 llama3.2:3b，确认 OpenClaw 能正常调度模型之后，再换 7B 甚至 14B。不要在第一天就拉一个 70B 的模型，光下载就能把人劝退，加载还会把内存和显存直接打满。
2.2 安装前的系统检查清单
在装任何东西之前，先打开命令提示符跑两个命令：
bash复制nvidia-smi
这个命令能看到显卡驱动版本和显存占用情况。如果系统提示找不到 nvidia-smi，说明 NVIDIA 驱动没装好，Ollama 即使装了也只能走 CPU 模式。另外看一下系统盘剩余空间，模型文件动辄 4 到 8GB，别装到一半才发现 C 盘满了。
第二件事是检查虚拟化功能。如果你后面打算用 Docker 方式部署 OpenClaw，Windows 11 需要开启 WSL2。任务管理器 -> 性能选项卡 -> CPU，右下角能看到“虚拟化: 已启用”状态；如果是禁用状态，进 BIOS 打开对应开关。不打算用 Docker 的话，这一步可以跳过。
2.3 准备工作目录：C 盘不是你放模型的地方
这一步强烈建议提前做，不要等 C 盘满了再迁移。我在 D 盘建了一个 D:\ollama 目录，下面分两个子目录：models 放模型文件，tmp 放下载的临时文件。OpenClaw 的数据目录我用了默认的 C:\Users\Administrator\.openclaw，因为它的工作区内容大多数是文本和配置，占不了多少空间，但如果你要让它处理大量文件，后期也要迁移。
Linux 服务器上同理，给模型单独挂一个数据盘，路径比如 /data/ollama/models，这样系统重装或者扩容都不会影响模型文件。
3. Ollama 本地化部署实操：从下载到跑通第一个模型
3.1 安装 Ollama 的几种方式
Windows 上最省事的方式是去官网下载安装包，双击安装。这里有个小细节：安装包默认会装到当前用户目录并且开机自启，个人使用没问题，但如果是在公司统一管理的机器上，建议安装时注意是否有系统级安装选项。
喜欢用包管理器的话，Windows 11 可以这样：
bash复制winget install Ollama.Ollama
Linux 上主流方式是通过官方提供的安装脚本执行，项目仓库的 README 里会给出具体命令。执行完之后验证一下：
bash复制ollama --version
看到版本号输出后，再确认后台服务是否在运行：
bash复制ollama serve
如果看到监听 11434 端口的信息，说明服务起来了。这时候打开另一个终端，请求一下版本接口：
bash复制curl http://localhost:11434/api/version
能拿到 JSON 响应，Ollama 就绪。
3.2 “下载太慢”的缓解办法，我只说合规的路径
先说安装包下载慢的问题。这个没有什么神奇技巧，最实用的办法就是换用支持多线程的下载工具，把安装包下载速度拉满，再校验一下哈希值确认文件完整。不要用浏览器默认的单线程下载去硬等，浪费时间。
然后是模型拉取慢的问题。很多人执行 ollama pull 时发现速度感人，我实际测试下来有几个可行路径。第一个思路是避免拉取默认的 latest 标签，因为某些模型默认标签体积很大，换成一个具体带量化标记的 tag，比如 qwen2.5:7b-instruct-q4_K_M，文件更小，下载自然更快。第二个思路是去 ModelScope 这类国内可直接访问的模型社区，下载 GGUF 格式的模型文件，再用 Ollama 的导入功能转成本地模型。这是我推荐的方式，流程如下：
bash复制# 1. 在 ModelScope 下载好 qwen2.5-7b-instruct 的 GGUF 文件
# 2. 写一个 Modelfile，内容只需要一行，指向本地文件
FROM D:/models/qwen2.5-7b-instruct-q4_k_m.gguf
# 3. 执行导入命令，my-qwen 是导入后的模型名
ollama create my-qwen -f Modelfile
# 4. 确认模型已经出现
ollama list
这样完全不依赖官方模型仓库的下载速度，而且后续 ollama pull 拉不到的老模型也能用这种方式导入。需要提醒的是，GGUF 文件必须和 Modelfile 里的 FROM 路径保持一致，文件放移动硬盘或者网络盘的时候，路径写错了会直接报“file not found”。
3.3 把模型目录改到 D 盘，避免 C 盘爆炸
我一开始没在意模型目录，结果拉了三个模型后 C 盘直接红了。Ollama 默认把模型放在用户目录下的 .ollama\models，这在系统盘上就是个隐形炸弹。迁移步骤很简单：
- 先确认当前没有正在执行的推理任务，运行
ollama list如果能看到模型，记录下来； - 创建目标目录，Windows 上是
D:\ollama\models； - 设置用户环境变量
OLLAMA_MODELS=D:\ollama\models。Windows 上可以打开“系统属性 -> 环境变量”，在用户变量里新建；Linux 上写到~/.bashrc或~/.zshrc； - 重启 Ollama。Windows 上如果托盘的 Ollama 还开着，先退出，再用
ollama serve启动；如果之前注册成了服务，要在系统服务里重启； - 验证：新拉一个模型，看目标目录里有没有文件增长，或者执行
ollama list确认模型还在。
这个操作一定要在下载模型之前做。如果你已经拉了一堆模型，想迁移旧模型，可以直接把 .ollama\models 里的文件移动到新目录，然后重启服务。我实测移动大文件用普通复制也可以，只是时间比较长，期间别断电。
3.4 选哪些模型适合本地化
本地化部署的模型选择有两个原则：一是显存放得下，二是模型支持工具调用或足够听指令。如果你想让 OpenClaw 能够自主规划步骤并执行工具，模型的指令遵循能力非常重要。我整理了一个简易参考表：
| 模型名 | 参数量 | 量化版本 | 显存需求参考 | 适合场景 |
|---|---|---|---|---|
| llama3.2:3b | 3B | Q4_K_M | 约 3GB | 流程验证、轻量问答 |
| qwen2.5:7b-instruct | 7B | Q4_K_M | 约 6GB | 中英文混合任务、工具调用 |
| deepseek-r1:7b | 7B | Q4_K_M | 约 6GB | 带推理链的任务、分析类 |
| qwen2.5:14b | 14B | Q4_K_M | 约 10GB | 复杂指令、长上下文 |
我的建议是先拉 qwen2.5:3b 跑通 OpenClaw 联调，确认整条链路没问题后，直接拉 qwen2.5:7b-instruct 作为主力模型。这个模型在工具调用和中文指令理解上表现稳定，社区反馈也最多，遇到问题容易搜到答案。
4. OpenClaw 轻量级应用服务器部署：拿到一个可以调度的入口
4.1 安装 OpenClaw：Windows 和 Linux 的路径都不一样
OpenClaw 的安装方式以官方仓库 README 的实时说明为准，因为它更新比较频繁，安装脚本的命令行可能会有调整。我当时用的是 PowerShell 在线安装脚本的方式，基本流程是先确认本机有 PowerShell 5.1 以上版本，再执行脚本完成安装。
这里额外说明一下“PowerShell 安装 OpenClaw 能指定目录吗”这个问题。根据我的实际操作，OpenClaw 的数据目录不是由安装位置决定的，而是通过环境变量或者初始化参数来控制。如果你不希望数据放在默认的 C:\Users\Administrator\.openclaw，可以在首次运行前设置一个环境变量指向自己的目录，比如 OPENCLAW_HOME=D:\openclaw-data。设置完之后再启动服务，它会自动在指定位置创建 workspace、exec-approvals.json 等结构。
Linux 服务器上安装更顺手一些，多数情况是一条脚本命令完成，然后用 systemctl 或者直接 nohup 方式跑后台服务。如果是在 CentOS/RHEL 系系统上，注意先确认网络源和基础依赖，curl、git、tar 这些工具得在。
4.2 初识 .openclaw 目录：workspace、approvals、配置文件
装好 OpenClaw 后，第一次启动会在用户目录生成 .openclaw 文件夹。这个目录是整套服务的核心，我逐个说明里面几个关键东西。
第一是 workspace，默认类似于 c:\users\administrator\.openclaw\workspace。OpenClaw 会让模型在这个目录内进行文件操作，相当于给智能体划了一块“自留地”。你交给它的任务产物、它读到的上下文文件，都建议放在这里，避免它跨目录乱翻系统文件。
第二是 exec-approvals.json，这个文件记录了工具的审批规则。例如模型执行某条命令前，系统会检查这条命令是否在批准列表里；如果不在，就会进入待确认状态。我第一次运行看到这个文件时还不太理解它的作用，后来才发现这是 OpenClaw 的安全护栏：大模型生成出来的命令不能无脑执行，必须经过规则或人工确认。
第三是环境配置文件，不同版本的配置格式有差异，核心字段是模型提供商、模型名称、API 地址。这些配置决定 OpenClaw 到底去哪个后端取模型。初次使用建议先通过它的配置向导或生成默认配置，再手动修改。
4.3 配置模型提供商：把 OpenClaw 指向 Ollama
这里就是整篇教程最关键的一步。Ollama 本身提供了 OpenAI 兼容接口，地址是 http://127.0.0.1:11434/v1，所以 OpenClaw 里不需要写复杂的 SDK 对接代码，直接把模型提供商配成兼容 OpenAI 协议即可。配置项大概是这样的逻辑：
| 配置项 | 值 | 说明 |
|---|---|---|
| 模型提供商类型 | openai-compatible 或 custom | 表示使用 OpenAI 兼容协议 |
| base_url | http://127.0.0.1:11434/v1 | Ollama 本地 API 端点 |
| model | qwen2.5:7b-instruct | 指定本地模型名称 |
| api_key | 任意非空字符串 | 本地端点不校验，但兼容格式要求有 |
如果公司内部有统一的中转网关，也就是热词里常说的“自定义中转站”，只要这个中转站也是 OpenAI 兼容协议，那么 base_url 就填网关地址，api_key 填网关下发的密钥，其他不用改。这个设计对我来说非常实用，本机调试用 Ollama，接入团队统一算力时切到中转站，只需要改两行配置。
4.4 Docker 方式部署 OpenClaw 的取舍
官方也支持用 Docker 跑 OpenClaw。我自己的建议是：如果你打算长期稳定运行、或者准备部署到云服务器，用 Docker 是合理的选择；但如果你还在调试验证阶段，先别急着容器化，直接在宿主机上跑进程看日志更直观。
Docker 方式部署时需要注意几个点：一是把本机的 .openclaw 目录挂载进容器，避免容器一删数据全没了；二是容器需要能访问宿主机 Ollama 的 11434 端口，通常在 Docker Desktop 里直接用 host 网络模式或者填宿主机的局域网 IP 就行；三是端口映射要规划好，别把 OpenClaw 界面端口和 Ollama 端口搞混。
5. 联调实战：从服务启动到第一次完整对话
5.1 启动顺序与健康检查
联调最重要的习惯是“按顺序启动、分步验证”。我的启动顺序是：
- 先启动 Ollama 服务，确保
curl http://localhost:11434/api/version能正常返回； - 再启动 OpenClaw，观察启动日志里有没有模型连接相关的报错；
- 最后通过 OpenClaw 的交互入口发起一次最简单的对话任务。
为什么坚持这个顺序？因为 OpenClaw 启动时可能会检查配置的模型提供商是否可用。如果 Ollama 还没起来，它可能会报连接失败，虽然大多数情况下重试能恢复，但会让你分不清到底是 OpenClaw 的问题还是 Ollama 的问题。先保证底层可用，再排查上层，这是排查问题最省力的路径。
5.2 第一个真实任务：让智能体处理工作区文件
服务都起来之后，我给 OpenClaw 发了一个任务，要求是“统计当前工作区里的文件列表，并生成一个 summary.md”。这个任务的特别之处在于它需要模型做两件事：理解文件系统操作意图，并生成一条可执行的命令。
OpenClaw 的处理流程是这样的：它把任务交给模型，模型在对话上下文里决定要调用工具，然后 OpenClaw 检查 exec 审批规则——如果命令在允许列表里，自动执行；如果不在，会请求确认。我在本地跑的时候，看到终端里弹出了审批提示，确认之后命令才真正执行。整个流程下来，工作区里多了一个 summary.md，内容是文件列表的汇总。
这一步跑通，你的整套组合就算真正可用了。从此之后，模型的输出不再局限于聊天框里的文字，而是能转化成实际的文件操作、命令执行和任务产物，这就是应用服务器和裸聊天窗的本质区别。
5.3 常见联调问题：响应慢、工具调用不生效、输出格式乱
联调阶段最容易遇到三个问题。
第一个是响应速度慢。如果模型生成计划要十几秒甚至半分钟，先看是不是模型太大而显存不够，或者 CPU 在硬扛。显存不足时可以通过换更小量化版本解决，同时调整 Ollama 的环境变量 OLLAMA_NUM_PARALLEL，减少并行请求数，把资源集中到单次推理上。
第二个是工具调用不生效。这跟模型本身的能力关系很大，有些模型虽然对话能力尚可，但缺少稳定的工具调用训练，OpenClaw 把函数列表发过去之后，它压根不按格式输出。我的经验是优先选择明确支持工具调用的型号，例如 qwen2.5:7b-instruct；如果你用的模型总是“嘴上说要执行”但输出格式不对，在提示词里加一段“请严格按 JSON 格式输出要调用的工具和参数”会有帮助。
第三个是输出格式乱。这通常是因为模型的指令遵循能力偏弱或上下文窗口不够。可以在 OpenClaw 里调大上下文窗口参数，同时在请求中把任务描述得更具体，拆分成小步骤，效果会明显改善。
6. 部署过程中我踩过的几个坑（排错实录）
6.1 模型下载到一半失败，反复重试没用
我在拉取第一个大模型时遇到了下载中断，ollama pull 显示进度停在某个百分比，然后报错退出。我一开始本能地重新执行 pull，结果每次都在同一个位置附近失败，后来才意识到问题不在于网络抖动，而在于磁盘空间不够了。模型文件的下载是边下边写入临时目录，如果临时目录所在磁盘满了，就会在固定大小附近反复失败。
排查链路建议按这个顺序走：先 du -sh 看一下模型存储位置剩余空间，再用 ollama list 确认没有残留的断点缓存，最后查看 Ollama 的日志。如果是磁盘空间不足，清理临时目录或者换存储位置；如果纯粹是下载源不稳定，直接换 GGUF 导入方案，反而更快。
6.2 升级后报错：“legacy exec approvals exist”
这个坑我一定要单独拿出来说。有一次我更新 OpenClaw 版本后启动服务，终端里弹出了一条提示，大意是检测到旧版本的 exec-approvals 文件存在于 /root/.openclaw/exec-approvals.json，需要处理。当时我一下没反应过来，因为平时只关心模型和端口，压根没想过审批文件还会涉及格式变迁。
实际情况是，新版对审批规则的数据结构做了调整，旧文件不能直接兼容。如果直接删除，我手工配过的审批规则全没了；如果不管，服务可能拒绝启动。正确做法是先把旧文件备份成 exec-approvals.json.bak，再按提示执行迁移或重新初始化。我当时对比了新旧格式的差异，发现新版支持更细粒度的路径和指令匹配规则，干脆重新生成了一份，只把少量手工规则同步进去。这里也提醒各位，升级任何服务之前，先备份整个 .openclaw 目录，成本极低，收益极大。
6.3 端口起不来：防火墙、占用、绑定地址
有次我启动 OpenClaw 时端口一直起不来，用 netstat -ano | findstr <端口号> 一看，发现端口被另一个进程占了。我原计划让 OpenClaw 走默认端口，现在只能改端口或者关掉占用进程。改配置之后还要留意防火墙规则，如果希望同一局域网内的其他机器也能访问，需要放行对应端口；如果只是本机使用，保持默认即可。
等真正部署到云服务器时，这个问题会变成另一副面孔：安全组、防火墙、进程监听地址三者都要对齐。监听地址如果设置成 127.0.0.1，那外网肯定访问不到；必须改成 0.0.0.0，同时靠安全组或防火墙做访问控制。这也是个人本机部署和生产部署之间最容易被忽视的差别。
6.4 显存 OOM 和“看起来一切正常但推理很慢”
显存不足时，Ollama 不一定立刻报错，更常见的表现是模型加载后推理速度骤降，甚至进程被系统 kill 掉。我遇到过一次 OOM，是在还没设置 OLLAMA_MODELS 环境变量、用默认配置硬跑一个 14B 模型时发生的。解决办法是换更小的量化版本，或者减少上下文长度。显存只有 8GB 的情况下，老老实实跑 7B Q4 模型，把 OLLAMA_NUM_CTX 设置在 4096 以内，体验会稳定得多。
如果手头有一张 8 卡 A100 之类的生产级显卡，那就是另一个维度了——可以考虑用更完整的模型服务框架来承接，OpenClaw 侧只需要配置远程模型地址即可。个人开发场景不必追求最大模型，够用、稳定、能出正确结果，比参数数量更重要。
结尾：这套方案还能怎么延伸
部署完成后的这半个月，我一直在用这套本地方案做日常任务测试，最直观的感受是“踏实”——数据不出机器，模型的回答和工具执行记录都留在本地，不用担心第三方接口的隐私问题。如果你也想从零复现，我的建议是先跑通最小链路：一个小模型、一个默认工作区、一个简单任务，让智能体真正完成一次文件操作，再逐步叠加复杂度。
最后再分享一个小技巧：Ollama 的 OpenAI 兼容端点不要只服务于 OpenClaw，任何支持 OpenAI 协议的工具都可以把 base_url 指到 http://127.0.0.1:11434/v1，等于你本地藏了一个统一的大模型入口。后面不管是接 ComfyUI 做 AI 工作流，还是接其他自动化工具，都能复用这条链路，这也是我把 Ollama 放在底层、独立于 OpenClaw 之外的原因。