先说结论:如果你最近在折腾本机智能体,想把 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。不要在第一天就拉一个 7
