如果你是从上篇一路跟过来的，现在 WSL2 + Ubuntu 这个底子应该已经搭好，OpenClaw 也顺利装上了。但我知道，装完只是第一步，真正让大多数人卡住的是第二步：配置。启动软件容易，让它开口说话难。OpenClaw 说到底是个壳，所有智能都来自背后接的模型服务——这一步不打通，终端里永远只有一堆英文报错和自我介绍的输出。
这篇（下）就把最关键的半截补完：OpenClaw 的核心配置到底在管什么、云端模型和本地模型分别怎么对接，以及在 WSL2 这个特殊环境下，那些"连不上、验证失败、找不到模型"的坑到底怎么来的、怎么排。全程基于我实际在 Win10/Win11 + WSL2 环境里反复折腾过的经验，适合刚装好 OpenClaw 但还没成功让模型回复的读者，也适合想从云端模型切到本地模型的人参考。
1. 从"能启动"到"能对话"：配置文件到底在管什么
1.1 先纠正一个认知：OpenClaw 本身不带模型
我第一次接触这类工具时有个错觉：装完就自带 AI，输入一句话就能得到回答。实际上 OpenClaw 更像个调度器，它负责把你的指令整理成对话上下文、选择模型、调用接口、再把结果以合适的方式呈现给你。模型在哪里？要么是云端 API，要么是本地推理服务。所以配置文件的全部意义，就是回答三个问题：用哪个模型、去哪调用它、用什么身份调用。
想明白这一点，后面看任何配置项都不会晕。什么 temperature、max_tokens 都是送给模型的附加参数，而 provider、baseURL、apiKey、model 这四个字段才是命门——任何一个填错，结果都是"连上了但聊不起来"，或者干脆连不上。
1.2 装完后的目录里藏着什么
OpenClaw 是 Node.js 生态的工具，一般通过 npm 全局安装。装完后，它会在你的用户目录下生成一个配置目录，常见的位置是~/.openclaw/或~/.config/openclaw/（具体路径因版本而异，以你安装版本的 README 为准）。这个目录里一般会有：
- 一个主配置文件，YAML 或 JSON 格式，负责描述模型接入方式；
- 一个
.env类似的密钥文件，用来存放 API Key，避免密钥直接写进配置再被同步到 Git； - 一个 logs 目录，运行时日志都写在这里，排错时最有用。
我见过不少人把时间花在找"魔法配置项"上，其实核心就这几样。你把配置目录翻一遍，先分清哪个文件管什么，比到处抄配置片段要靠谱得多。
1.3 核心字段逐一拆解
用一个典型的模型配置片段来解释：
model: provider: "openai" base_url: "https://dashscope.aliyuncs.com/compatible-mode/v1" api_key: "${DASHSCOPE_API_KEY}" model: "qwen-plus" temperature: 0.7| 配置项 | 管什么 | 最容易踩的坑 |
|---|---|---|
| provider | 协议方言，告诉 OpenClaw 用哪种格式说话 | 不是"品牌"，别填成阿里、百度 |
| baseURL | 请求发到哪个地址 | 漏掉结尾的/v1或拼错路径 |
| apiKey | 身份凭证 | 硬编码在配置文件里，提交后泄露 |
| model | 具体的模型名 | 大小写、连字符、版本号必须和服务商完全一致 |
| temperature | 回答的随机性 | 调太高容易胡说八道，调太低太死板 |
api_key那行写的是${DASHSCOPE_API_KEY}，意思是从环境变量里读取。这是密钥管理的通用实践，别把 key 直接写死在配置文件里。具体做法是在~/.bashrc或.env文件里先导出变量，OpenClaw 启动时自动加载。我用的是.env文件方式，好处是换模型服务商时不用改主配置，只换环境变量。
2. 云端模型对接：用一条通义千问 API 把 OpenClaw 喊醒
2.1 为什么建议先从通义千问这类国内服务开始
在 WSL2 环境下接云端模型，我首选阿里云百炼上的通义千问。原因很实际：访问稳定、控制台操作门槛低、新用户通常有免费额度可以试跑，而且 DashScope 提供了 OpenAI 兼容模式——这意味着你不用折腾任何格式转换，OpenClaw 那边按 OpenAI 的标准写法填地址，国内模型就能直接跑起来。你搜"qwen2.5-3b 关联到 openclaw"能找到一堆问题，但绝大多数都是配置细节没对齐，协议本身反而是最顺的一环。
2.2 开通服务、拿 Key，三步搞定
具体操作流程如下：
- 打开阿里云百炼控制台，找到模型服务开通页面，把通义千问系列模型的服务开通。新用户一般能看到免费额度提示，先领了再说，跑通链路后再决定要不要付费。
- 在控制台左侧找到 API-KEY 管理，创建一个新的 Key，记得先复制保存。这个 Key 只在创建时完整显示一次，丢了只能重新建。
- 在 WSL2 的 Ubuntu 里，把 Key 写进环境变量：
echo 'export DASHSCOPE_API_KEY="你的Key"' >> ~/.bashrc source ~/.bashrc如果你用了.env文件方案，格式也一样，就是少个 export 前缀。
2.3 先别启动 OpenClaw，用 curl 验证 Key 有没有效
这是我最想强调的习惯：接任何模型服务，先绕开 OpenClaw，直接用 curl 打一次接口。这样能把问题分层——curl 通不通代表网络和 Key 对不对，curl 通了而 OpenClaw 不通，才轮到查 OpenClaw 自己的配置。
curl https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions \ -H "Authorization: Bearer $DASHSCOPE_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"qwen-plus","messages":[{"role":"user","content":"你好"}]}'如果返回一段带choices字段的 JSON，说明 Key 有效、网络通畅。如果返回 401 或 InvalidApiKey，先去控制台核对 Key 是不是复制完整了。这一步多花两分钟，后面能省两小时。
2.4 为什么 "provider: openai" 反而能接国内模型
很多人看到配置示例里写provider: openai，以为就只能接 OpenAI 的模型。其实是 OpenAI 兼容协议已经成了行业事实标准——国内主流模型服务商几乎都提供一套"兼容模式"端点，把自家模型包装成 OpenAI 的请求格式。你可以类比成：大家都说普通话，只是口音不同，兼容模式就是让服务商切换成标准口音，OpenClaw 只要会用一种方式说话，就能跟所有说普通话的服务商沟通。
所以对接通义千问时，DashScope 的兼容模式地址是：
https://dashscope.aliyuncs.com/compatible-mode/v1这里的/v1不能丢，OpenClaw 内部会在 baseURL 后面拼接具体的接口路径。填错地址最常见的表现是 404 或者 "Connection refused"。
把第 2.3 步的 curl 验证通过之后，再启动 OpenClaw，正常情况下就能得到第一个来自云端模型的回复了。如果还有问题，多半是 model 名写错了——服务商每个模型的 ID 都有固定写法，比如qwen-plus、qwen-turbo、qwen2.5-72b-instruct，多一个少一个字母都查无此模型。
3. 本地模型路线：Ollama 拉起 Qwen2.5-3B，再喂给 OpenClaw
3.1 什么时候该考虑本地模型
云端模型优点很多，但有些场景真不合适：数据敏感不想出内网、临时断网想继续调试、或者你只是想高频试 OpenClaw 的功能又不想一直烧 token。本地模型的价值就在这——东西跑在自己机器上，随便折腾不心疼。
代价也直接：吃内存吃算力。3B 级别的模型还能靠 CPU 硬扛，再大的体量就建议有 GPU 了。好在 WSL2 在这方面做得不错，只要你 Windows 侧装了较新的 NVIDIA 驱动，WSL2 里就能直接调用 GPU 做推理，Linux 内不需要再装一遍显卡驱动。很多人搜"wsl2 英伟达驱动生效吗"，答案是生效的，前提是 Windows 驱动版本足够新。
3.2 Ollama 的安装与模型拉取
本地推理我推荐 Ollama，理由就一条：把复杂的东西全包了。模型下载、量化、内存管理、OpenAI 兼容接口，它都内置好了。安装和拉取模型：
curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:3b拉下来的模型虽然叫 3B，实际占用磁盘大概 2GB 上下，这个体量在 WSL2 里比较可控。拉完启动服务：
ollama serve3.3 验证本地接口，再配置 OpenClaw
Ollama 启动后默认监听127.0.0.1:11434，而且自带 OpenAI 兼容端点。先验证：
curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"qwen2.5:3b","messages":[{"role":"user","content":"你好"}]}'然后 OpenClaw 侧配置就很简单了：
model: provider: "openai" base_url: "http://localhost:11434/v1" api_key: "ollama" # 本地服务不校验，占位即可 model: "qwen2.5:3b"注意model名里的冒号，qwen2.5:3b是 Ollama 的标签体系，表示 "qwen2.5 这个模型的 3B 量化版本"。填错标签，Ollama 会直接报 model not found。
3.4 WSL2 下跑本地模型，三个注意点
内存限制要提前配好。WSL2 默认最多使用宿主机约一半内存，3B 模型平时还好，但如果你同时开浏览器、IDE 和 Ollama，很容易触发 OOM。建议在 Windows 用户目录下建一个.wslconfig文件，手动分配：
[wsl2] memory=8GB processors=4改完执行wsl --shutdown再重启 WSL2 生效。
Ollama 长时间运行会缓存多个模型。如果机器内存不大，可以限制同时加载的模型数，比如设置环境变量OLLAMA_MAX_LOADED_MODELS=1，避免加载多个大模型直接把内存吃满。
从 Windows 访问 WSL2 里的服务，绝大多数情况用 localhost 就行。新版 WSL2 会自动把 Windows 的 localhost 转发到 WSL2 实例。但如果你想让局域网里其他设备访问 Ollama，就得把监听地址改成0.0.0.0：
export OLLAMA_HOST=0.0.0.0否则服务只在本机可见，外部设备会一直连不上。
4. 连不上的排错实录：验证失败、端口黑洞与 DNS 失踪
4.1 看到报错先分层，别急着改配置
OpenClaw 报"连不上模型"，绝大多数可以分成三层：网络层、鉴权层、配置层。我的习惯是先用 curl 复现一次同一个请求（云端和本地模型都可以这么做），然后看结果：
| 现象 | 问题层 | 下一步 |
|---|---|---|
| curl 超时或 connection refused | 网络层 | 查服务是否启动、地址端口是否可通 |
| curl 返回 401/403 | 鉴权层 | 核对 Key、账号开通状态 |
| curl 返回 404/model not found | 配置层 | 查模型名和 baseURL 路径 |
| curl 返回 429/限流 | 资源层 | 查额度、冷却等待 |
| curl 正常但 OpenClaw 报错 | 配置层 | 查 OpenClaw 配置文件、环境变量 |
curl 是唯一能一锤定音的工具。跳过它直接改配置，就像不看体温计就吃退烧药，全凭猜。
4.2 "OpenClaw 无法安全验证"到底在验证什么
这个报错我见过太多次了，但它背后至少有三种不同的真凶，必须逐一排除。
真凶一：WSL2 时钟漂移导致 TLS 证书校验失败。WSL2 本质是个轻量虚拟机，宿主机休眠唤醒后，它的内部时钟可能漂移几分钟。而 HTTPS 证书校验依赖客户端时间在有效期内，时间不对，OpenClaw 就会认为"无法安全验证"。典型特征是 curl 报SSL certificate problem。修起来很快：
sudo hwclock -s把 WSL2 的时钟同步到硬件时钟，再重试 curl 就正常了。如果你经常休眠，建议研究一下怎么给 WSL2 配时间和宿主机自动同步，不然这问题会反复出现。
真凶二：环境里存在代理变量，TLS 链路被干扰。WSL2 会继承 Windows 的环境变量，如果你在 Windows 上配置过 HTTP_PROXY，WSL2 里也可能带着这些变量跑。OpenClaw 走代理去连模型服务时，代理证书链一旦不完整，也会报验证失败。排查命令：
env | grep -i proxy如果有输出，临时清掉再试。但我不展开这个方向，因为它跟每个人的网络环境绑定太深，先确认是不是自己的代理设置导致的最重要。
真凶三：API Key 无效，OpenClaw 把 401 包装成了"验证失败"。这种情况 curl 会直接返回 401，但 OpenClaw 的报错信息有时很含糊，把鉴权失败也归进"无法安全验证"。所以回到第 4.1 节的分层思路，先用 curl 确认到底哪一层出错，再对症下药。
4.3 端口黑洞：为什么 Windows 访问不到 WSL2 里的本地模型
如果你配置了本地模型，Windows 上的 OpenClaw 却连不上 localhost，往往是 WSL2 网络模式的坑。WSL2 默认是 NAT 网络，WSL2 里的服务对 Windows 来说在另一台"虚拟机"里。新版 WSL2 提供了 localhost 自动转发，但有两个前提：
- 服务必须监听在
127.0.0.1上； - WSL 版本足够新，且没有其他组件抢占了转发规则。
如果服务监听在0.0.0.0，Windows 访问 localhost 有时反而抓不到，因为转发只针对 loopback。这种情况要么把监听地址改回127.0.0.1，要么用wsl hostname -I拿到 WSL2 的 IP，从 Windows 直接用那个 IP 访问。
还有个一劳永逸的办法：在.wslconfig里开启 mirrored 网络模式：
[wsl2] networkingMode=mirrored开启后 WSL2 和宿主机共享网络栈，localhost 概念完全一致，端口黑洞直接消失。我只提醒两点：这个模式需要较新的 Windows 11 版本；如果你装了某些会和网络栈打架的虚拟网卡类软件，可能引入新问题。没有特殊需求的话，直接开就行。
4.4 模型有反应但质量不对，检查顺序是什么
能连上但回答不对劲，比如答非所问、一直重复、超时中断，这个阶段的排错顺序我固定为：
- 先确认 config 里的 model 名和服务商文档完全一致，包括大小写和分隔符；
- 查上下文超长问题。本地小模型上下文窗口有限，你一次性贴一大段代码进去，它可能崩掉或截断；
- 看日志。OpenClaw 的日志位置通常在配置目录下的 logs 文件里，里面有请求耗时、状态码、响应片段，比终端输出的信息全得多；
- 如果本地模型回答明显退化，考虑是不是内存不够导致 Ollama 把模型换到了 CPU 推理，看
ollama ps能确认当前模型在 GPU 还是 CPU 上跑。
5. 配置落定后，我建议你长期保留的几条操作习惯
5.1 多模型切换不要反复改配置
我在本地模型和云端模型之间反复切换过很多次，最开始的笨办法是每次编辑配置文件。后来发现更好的方式：用环境变量控制模型选择，主配置文件保持简洁，只通过MODEL_BASE_URL、MODEL_NAME这类变量切换。比如想要快就切 qwen-turbo，想要本地离线就切http://localhost:11434/v1加qwen2.5:3b。OpenClaw 支持从环境变量读配置的话，这样收益最大，你只需要维护一套配置，切换只改一行。
5.2 密钥文件永远不要进 Git
很多人把整个配置目录直接推到 GitHub，Key 也随之公开。正确的做法是只把.env.example提交到仓库，里面放占位符，真正的.env写进.gitignore。换个新机器时，复制.env.example再填自己的 Key 就行。这是成本最低的安全投资。
5.3 "先用 curl 打通，再让 OpenClaw 接管"这个习惯救了我无数次
每次升级 OpenClaw、换模型服务商、或者重装 WSL2 之后，我的固定动作都是先跑一轮 curl 验证，确认服务端没问题，再启动 OpenClaw。别小看这一步，它能直接把故障范围砍掉一半。很多"为什么连不上"的问题，最后都发现不是 OpenClaw 的锅，而是模型服务本身还没就绪。
5.4 顺手提一句 C 盘空间问题
如果你用的 WSL2 发行版把数据全放在 C 盘，配置和模型文件越来越多之后，C 盘会告急。这时候不用重装系统，用wsl --export导出、wsl --import导入到 D 盘就能整体迁移。迁移之后再改.wslconfig里的路径即可，OpenClaw 的配置和各种环境变量不受影响。这个操作属于环境维护，跟模型对接关系不大，但你迟早用得上。
配置和模型对接这一关过了之后，OpenClaw 才算真正能用起来。我最初花最多的时间并不是在某个高深配置项上，而是反复在不读报错信息、不拆分层、跳步乱改配置的习惯上。如果你也卡在同样的位置，别急着删配置重装，先回到 curl 这一步，把"哪一层出了问题"搞清楚，多半问题就已经解决了一半。有了稳定能跑的模型底座，后面再折腾什么自动化、插件、多智能体编排，才有个靠谱的地基。
