嘿bro从有朋友问“能不能让微信里的AI助手不依赖任何云服务的token额度”开始，我花了大半个月折腾，最后把整套链路都在本地跑通了：模型推理用Ollama，Agent编排用OpenClaw，微信端通过企业微信的官方通道接入，每月的云API成本直接归零。这篇文章就是我这次本地化部署的完整记录，包括环境准备、模型下载、OpenClaw配置、微信接入，以及我在调试过程中踩过的那些坑。如果你也想把OpenClaw和Ollama部署在自己的机器上，实现一个不烧token、不依赖云端API的微信AI助手，这篇文章应该能帮你省下不少弯路。
1. 为什么我最终选择了OpenClaw + Ollama这套组合
1.1 一个很现实的需求：让微信里的AI助手不再依赖云端token
先说需求背景。我之前在微信上跑过一个AI助手，用的方案是OpenClaw作为Agent框架，模型侧接的是云端API。功能本身没问题，OpenClaw对消息的处理、工具调用的编排能力都很成熟，但有一个绕不过去的痛点：每个月都要盯着token用量。高峰期随便聊几百轮，再加上OpenClaw在做任务拆分时可能产生多轮模型调用，token消耗比你想象中快得多。充值倒不是付不起，而是这种“按量计费”的方式让每一轮对话都有心理负担，不敢放开了调优，也不敢给朋友随便测试。
后来我意识到，如果只为了日常对话、任务编排、少量工具调用，本地模型的能力已经够用了。于是整条改造路线就变得很清晰：把OpenClaw背后的模型推理从云端换成本地的Ollama服务。Ollama负责跑模型推理，OpenClaw负责Agent调度、工具调用、消息路由，微信只当一个聊天窗口。整条链路不产生任何云端API费用，也不受token失效、额度耗尽、服务商限流这些破事影响。
1.2 方案对比：云API、本地模型、混合模式的取舍
很多人会问：直接接云API不就行了，为什么要折腾本地部署？我简单列一下我当时的对比维度：
| 维度 | 云端API方案 | 本地Ollama方案 | 混合方案 |
|---|---|---|---|
| 单次对话成本 | 按token计费 | 仅电费 | 低 |
| 隐私数据 | 上传云端 | 完全本地 | 敏感数据走本地 |
| 响应速度 | 依赖网络 | 本地推理 | 看路由策略 |
| 模型能力上限 | 可跑超大模型 | 受硬件限制 | 折中 |
| 需要维护的内容 | API密钥、配额 | 磁盘空间、服务进程 | 两套都要 |
我的结论是：纯聊天和多数工具类任务，本地模型完全够用。OpenClaw对模型提供者做了抽象，你可以在配置里把默认模型指向Ollama，也可以随时切换。我实际用下来，Qwen系的中文能力、DeepSeek的推理能力在14B这个规模上，已经能应付绝大部分微信场景。
另外提一句，如果你用的是Mac mini这类功耗低的设备，通过Docker部署OpenClaw和Ollama也很方便，后面我会把Docker方式和直接二进制方式都讲一下。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 部署前的准备工作：软硬件清单与网络要点
2.1 硬件要求与系统环境
先说硬性条件。Ollama跑模型主要吃内存和显存，CPU也能跑但速度感人。我的主力机是一台32GB内存的Linux工作站，显卡是NVIDIA的，跑7B到14B参数的模型比较舒服；另外在一台Mac mini上也试过纯CPU运行，能跑，但14B模型回答速度会明显慢，需要调低并发。
如果你想开箱即用，建议内存至少16GB起步，32GB比较稳。显卡看情况——有NVIDIA显卡就开启CUDA加速，速度提升非常明显；没有独显的话，选7B甚至更小的模型，CPU也能凑合跑。
操作系统方面，Ubuntu 22.04 / Debian 12 / macOS / Windows（通过WSL2）都没问题。OpenClaw本身对Linux和macOS支持最好，Windows建议直接用WSL2来做，省得到处碰路径权限的坑。
2.2 Ollama国内下载慢的解决方案
这里先插一个几乎人人都会遇到的坑：Ollama官方安装脚本在国内下载速度很慢，经常卡在几KB每秒。我一开始直接用官网的 install.sh，等了一个多小时还没装完，后来果断换国内镜像源。
我当时的做法是配置国内镜像源后重新安装，核心思路是让脚本从镜像地址拉取。如果你不想改镜像源，也可以手动下载Ollama的二进制包再放到PATH里。我个人建议优先用镜像源方式，后续升级也方便。
还有一点容易被忽略：Ollama默认从 ollama.com/library 拉取模型，这个地址在国内同样很慢，尤其是几个GB的大模型，经常下到一半断掉。解决办法是设置 OLLAMA_HOST 和镜像源相关的环境变量，具体配置我放在下一节详细讲。
2.3 OpenClaw的安装途径选择
OpenClaw目前提供两种主流安装方式：命令行脚本安装和Docker部署。首次部署我强烈建议用脚本安装，因为Docker里还要处理GPU透传、日志挂载这些附加问题，不如直接二进制方便。
脚本安装一般是执行它官方提供的一键命令 curl -fsSL https://openclaw.com/install | bash，装好后会生成 claw 之类的全局命令。装完之后先确认一下版本号，再往下走配置。
如果你打算跑在NAS、Mac mini这种长期开机的设备上，Docker方式更干净。我后来把OpenClaw迁移到了Docker容器里，和宿主机上的Ollama服务通过 host.docker.internal 或 172.17.0.1 互通。细节放后面。
3. Ollama本地模型服务的安装与调优
3.1 Ollama安装与环境变量配置
Ollama的安装本身不难，难点在下载速度。我的建议是先把环境变量准备好，再执行安装脚本。以Linux为例，在 /etc/profile.d/ollama.sh 里写入：
bash复制export OLLAMA_HOST="0.0.0.0:11434"
export OLLAMA_MODELS="/data/ollama/models"
export OLLAMA_NUM_PARALLEL="4"
OLLAMA_HOST设为0.0.0.0:11434是为了让局域网内的其他设备（包括Docker容器）也能访问Ollama服务。如果只在本机用，127.0.0.1:11434就够。OLLAMA_MODELS指定模型存储目录，我单独挂了一块数据盘，避免模型占满系统盘。OLLAMA_NUM_PARALLEL表示并行处理的请求数，调到4后多个微信消息同时进来时不会排队太久。但要注意，并行数越高内存占用越猛，OpenClaw默认也可能有多路消息并发，这里需要自己掂量。
设置好后重新加载环境变量，再执行安装脚本。安装完成后运行 ollama list 看到空列表，说明服务正常。
3.2 模型选择与下载：从Qwen到DeepSeek的取舍
Ollama装好后的第一件事是选模型。我在微信场景下主要试过三款：
| 模型 | 参数量 | 中文能力 | 推理能力 | 显存占用（约） |
|---|---|---|---|---|
| qwen2.5:14b | 14B | 强 | 中等 | 10-12GB |
| deepseek-r1:14b | 14B | 强 | 强 | 12GB |
| qwen2.5:7b | 7B | 较好 | 中等偏弱 | 6-8GB |
如果你主要用于日常聊天、写作、总结，qwen2.5:14b 是最稳的选择，中文表达自然，长文本处理能力也好。如果经常让AI做逻辑推理、代码生成，deepseek-r1 更合适，但它偏“思考型”，有时候回复前会多几秒推理过程。
拉取命令很简单：
bash复制ollama pull qwen2.5:14b
ollama pull deepseek-r1:14b
下载慢的问题，我是在环境变量里加了Ollama镜像源相关的配置（具体根据你所在的网络环境搜“ollama国内镜像”就能找到合适地址），之后下载速度从几十KB/s提升到了几MB/s。建议先用小模型跑通流程再下载大的，不然一上来就拉14B，万一网络断了重头再来，挺崩溃的。
3.3 GPU加速与AMD环境下的注意事项
如果你有NVIDIA显卡，安装好驱动后Ollama会自动使用CUDA。你可以用 ollama run qwen2.5:7b 跑一句对话，再开另一个终端执行 nvidia-smi，看GPU进程里有没有ollama，就能确认加速是否生效。
AMD显卡的情况比较特殊。如果你用的是AMD GPU，比如Ryzen AI系列CPU自带的核显或独显，Ollama在Windows和Linux下的支持还在持续完善中。网上有人通过安装ROCm版Ollama来启用AMD加速，但步骤比NVIDIA复杂不少。我当时在AMD核显的机器上测试，最终还是用CPU跑的7B模型，速度可以接受。如果你也遇到“AMD如何让Ollama使用GPU”这个问题，建议直接去Ollama官方文档查最新的平台支持列表，不同版本的社区支持和稳定性差别很大。
4. OpenClaw的安装与核心配置
4.1 OpenClaw到底解决什么问题
简单理解，OpenClaw是一个开源的个人AI助手编排框架。它做的事情是：接收来自不同渠道的消息（微信、Telegram、Discord等），把消息交给大模型处理，根据模型判断是否调用工具或执行动作，再把结果返回到原渠道。它本身不提供模型推理能力，模型推理是交给后端的LLM服务完成的。
所以整个架构里，OpenClaw是“大脑皮层”，负责思考调度；Ollama是“神经元底层”，负责实际的语义理解。OpenClaw可以对接OpenAI、Anthropic这些云端服务，自然也可以对接本地Ollama——因为它暴露的接口是OpenAI兼容的。这就是“无需token”的核心：不调用云API，不消耗云端token，所有推理都在本地完成。
4.2 OpenClaw安装步骤与目录结构
我用脚本方式安装OpenClaw后，主要文件在 ~/.openclaw/ 目录下。首次运行时会自动生成一个配置向导，会问你几个关键问题：接入哪个渠道、使用哪个模型提供者、模型名称是什么。如果安装时只是默认跑了一遍，后面可以手动改配置文件。
配置核心是 config.yaml（具体文件名以你安装版本的实际输出为准），里面有几段关键内容：
yaml复制providers:
default: ollama
models:
- name: qwen2.5:14b
provider: ollama
channels:
wechat:
enabled: true
type: wecom
这段配置的意思是：默认提供者设为 ollama，模型用 qwen2.5:14b，微信渠道启用，类型是 wecom（企业微信）。OpenClaw会通过这些配置把渠道消息路由到模型，并把结果回传。
这里有个容易搞混的点：OpenClaw在安装向导里会让你填模型提供者的API Key和Base URL。对于Ollama，Base URL填 http://127.0.0.1:11434/v1 即可，API Key随意填一个占位符——因为Ollama本地不校验。也就是说，配置里必须有一个Key的字段，但这个Key不会真的被验证。
4.3 用Docker部署OpenClaw时如何通Ollama
如果你用的是Docker方式部署OpenClaw，容器内不能直接访问宿主机的 127.0.0.1。在Linux上，可以用 172.17.0.1 访问宿主机；在Mac和Windows的Docker Desktop上，用 host.docker.internal。Ollama那边需要把 OLLAMA_HOST 设为 0.0.0.0:11434，确保监听在宿主机所有网卡上。
举个例子，我的OpenClaw容器配置里，Ollama的Base URL是这样写的：
yaml复制base_url: http://172.17.0.1:11434/v1
在Mac mini上Docker部署时，则改成：
yaml复制base_url: http://host.docker.internal:11434/v1
这一步不搞清楚，后面启动OpenClaw时会出现连接Ollama失败的报错，而且报错信息里不一定直接写明“Ollama连不上”，容易被误导。我当时在容器里跑了半天，最后用 curl http://172.17.0.1:11434/v1/models 测通了才反应过来是网络地址的问题。
5. 微信接入的完整配置流程
5.1 为什么优先走企业微信通道
标题里的“接入微信”，这里必须说清楚一个边界：OpenClaw官方支持最好的是通过企业微信的API通道。个人微信的自动回复、自动聊天涉及非官方协议，有封号风险，我不推荐也不建议你折腾。企业微信是腾讯官方提供的接口，合规且稳定。
微信普通用户的聊天界面里能搜到企业微信应用吗？可以。企业微信应用的消息可以推送到个人微信上，用户在微信里就能直接和企业微信应用对话，看起来就像在和一个“微信里的AI助手”聊天。体验上和第三方微信机器人几乎没区别，但底层全是官方API。
5.2 创建企业微信应用：拿到corp_id、agent_id和secret
接入过程分三步：创建应用、配置接收消息URL、在OpenClaw里启用渠道。
先去企业微信管理后台（work.weixin.qq.com）注册一个企业，不需要认证也能用。注册后进入管理后台，在“应用管理”里创建一个自建应用。创建完成后，你会看到两个关键信息：AgentId 和 Secret。这两个信息加上你的企业ID（CorpId），就是OpenClaw接入企业微信需要的三要素。
然后进入应用的“接收消息”设置，配置一个回调URL。OpenClaw启动后会给一个webhook地址，或者你自己在OpenClaw配置里指定 wecom_webhook_path 之类的路径，把外网可访问的地址填到企业微信后台。同时要填一个Token和一个EncodingAESKey，这两个值用来做消息体加密签名校验。我在OpenClaw的配置里生成了一组随机字符串，填到企业微信后台，同时在OpenClaw的 wecom_token 和 wecom_aes_key 字段里填一模一样的内容，两边保持一致才能通过校验。
5.3 OpenClaw中企业微信渠道的配置实操
配置片段大致长这样：
yaml复制channels:
wechat:
enabled: true
type: wecom
wecom_corp_id: "ww1234567890abcdef"
wecom_agent_id: "1000002"
wecom_secret: "your_secret_here"
wecom_token: "your_callback_token"
wecom_aes_key: "your_encoding_aes_key"
填完之后重启OpenClaw，观察日志里有没有 wecom channel started 类似的输出。然后用微信扫码关注该企业微信应用（或者在微信里搜索企业名称进入应用），发一句“你好”过去，看OpenClaw是否会调用Ollama模型回复。
我第一次配置时就是在这里卡了很久：我这边OpenClaw日志显示有新消息进来，但回复发不出去，后来发现是 wecom_aes_key 填错了一个字符，导致消息解密失败。这种“消息接收正常但回复失败”的情况，优先检查回调配置的加密参数。
6. 调试过程中踩过的坑，帮你少走弯路
6.1 token exchange failed：API Token失效与本地Token的混淆排查
网络热词里有一个很典型的报错：sign-in could not be completed token exchange failed: token endpoint returned error。这个报错我在部署中确实见过，但要分清两个概念：
一个是指云API服务商的Token失效。如果你之前配置过云端模型提供者，并且Token过期了，OpenClaw启动时可能会去刷新Token，刷新失败就会出现类似报错。解决办法是在配置里把模型提供者切到Ollama，或者把旧的云API配置整个删掉。
另一个是企业微信回调里的Token校验。企业微信在回调时会对请求参数做签名校验，如果签名不对，同样会报Token相关的错误，这是因为 wecom_token 和 wecom_aes_key 不匹配导致的。
我当时调试的思路是，先看OpenClaw日志，如果日志里是 token endpoint returned 403 之类的，多半是企业微信回调的加密参数问题；如果是 401 或网络超时，再去查云API配置。加一行日志输出能帮你快速定位到底卡在哪一层。
6.2 Ollama服务启动但没有响应：模型挂起与内存分配问题
本地模型最常见的问题不是“装不上”，而是“跑着跑着不吱声了”。有一次Ollama服务看起来正常，但微信消息发过去后一直“已接收未回复”。检查方法：
bash复制curl http://127.0.0.1:11434/v1/models
如果能正常返回模型列表，说明Ollama没问题，问题出在OpenClaw到Ollama的连接上。如果这个命令卡住，多半是模型推理线程被占满或内存不足，用 ollama ps 查看当前加载的模型和内存占用。
还有一种情况是，模型加载后首次推理极慢，尤其是14B模型在CPU模式下，可能要几十秒才出第一个字。这会让人误以为没响应。解决方法是调低并行数，或者换用更小的模型。另外可以设置模型预加载，在Ollama里把常用模型保持常驻，避免每次冷启动。
6.3 微信消息没进入OpenClaw：回调地址可达性排查
如果OpenClaw日志里完全看不到微信消息，说明消息根本没推过来。企业微信回调要求你的回调地址必须公网可达，而且必须是HTTPS（企业微信后台强制要求）。本地开发环境下，我当时是用了内网穿透类工具把本地端口映射到公网，然后再去企业微信后台配置回调地址。
这一环有另一个容易踩的坑：企业微信后台配置回调URL后，会先发一个验证请求，只有你的服务正确响应了加密挑战才会保存成功。如果保存失败，先确认你的公网地址确实能访问到OpenClaw的webhook路径，再确认加密参数是否完全一致。我见过太多人在这里反复保存失败，最后发现是公网地址里带了路径，而OpenClaw的webhook路径又是另一回事，两者拼接出错。
6.4 部署完模型就能写小说？OpenClaw的多轮记忆与工具调用体验
网上有条热搜叫“openclaw 写小说”，我实测下来确实可以。因为OpenClaw支持多轮对话记忆和长上下文管理，你可以让它记住前面的情节设定、人物关系，然后持续输出章节。在本地模型下，我用qwen2.5:14b配合OpenClaw，让它写一段3000字的短篇，质量比我预期高不少，尤其是中文叙事的连贯性很在线。
但注意一点：写长文时Memory和Context会占用大量上下文窗口，本地的上下文长度受限。如果模型窗口只有8K，写两三千字之后就快到极限了，需要开启OpenClaw的上下文压缩或摘要功能。这一点在云端模型上不敏感，因为云端窗口大都128K起步，本地模型就要精打细算。
7. 稳定性保障与后续扩展方向
7.1 开机自启与守护进程：让服务跑得更省心
本地部署最大的优势是低成本，但代价是服务稳定性要自己维护。我最终部署在一台长期开机的Linux主机上，做了三件事保证服务不挂：
- Ollama和OpenClaw都注册成systemd服务，开机自启、崩溃自动重启。
- 用定时任务监控关键端口：每5分钟检查一次
11434和OpenClaw的webhook端口，如果进程不在就直接拉起。 - 日志按大小轮转，避免长时间运行导致磁盘被日志塞满。
systemd的Unit文件里，我特别设置了 Restart=always 和 RestartSec=5。这样即使模型推理把进程搞崩了，5秒后也会自动恢复，基本不影响微信端体验。
7.2 资源监控与模型热切换：从7B到14B的演进
上线稳定后，我开始考虑体验优化。微信消息的峰值时段通常集中在午休和晚上，这个时段并发高，模型推理压力大。我做了个简单的热切换脚本，通过修改OpenClaw配置文件中的模型名称并重启服务，就能在 qwen2.5:7b 和 qwen2.5:14b 之间切换。高峰期用7B保证响应速度，闲时切回14B提高回答质量。
如果服务器内存够大，还可以同时预加载多个模型。Ollama支持在显存/内存中同时保持多个模型，但每个模型都会占资源，要留意 ollama ps 的输出，防止内存叠加超限导致整机卡死。
写在最后的个人体会
如果你以前没有做过本地模型部署，第一次跑通OpenClaw + Ollama + 企业微信链路可能会觉得步骤不少，但一旦整个链路跑通，后面维护起来非常轻松。我最大的体会是，部署的首要目标不是“跑起来”，而是“能排查”。所有看似离奇的报错，最终都能通过一层层拆解找到根因：先确认Ollama在线，再确认OpenClaw能调到Ollama，最后确认企业微信回调能推到OpenClaw。三条链路分别验证完，整个系统就是稳的。
另外一个小建议：如果机器性能一般，不要一上来就追求大模型。7B模型跑通全流程后，再慢慢升级到14B甚至更大的模型，哪个参数跑得动、哪个响应速度能接受，用数据说话，而不是凭感觉。这个项目后续还有很大的扩展空间，比如给OpenClaw挂上联网搜索工具、让它定时推送天气或新闻，都是在现有架构上再加一个工具函数的事。本地部署的魅力就在这里：模型、工具、数据全在你手里，想怎么折腾都行。