1. WSL2 里跑 OpenClaw Ollama 的真实痛点Key 分散、端点乱、QQ 机器人老掉线如果你正在 WSL2 里折腾 OpenClaw 搭配 Ollama 本地模型还想让它驱动一个 QQ 机器人那你大概率已经踩过这几个坑Ollama 的 11434 端口在 WSL 里监听、OpenClaw 的配置文件散落在~/.openclaw/下、QQ 机器人插件装到一半 npm 报错、模型一换就得改一堆 Base URL。更麻烦的是当你既想用本地 qwen 模型、又想临时切到云端大模型做复杂推理时Key 和端点会分散在好几个地方改一次配置重启一次服务调试成本极高。这篇记录就是围绕这个场景展开的在 Windows 11 WSL2Ubuntu环境里用 OpenClaw 作为 Agent 框架Ollama 提供本地模型QQ 机器人作为消息入口同时把多模型调用的 Key 和端点统一收敛到 TaoToken 的 API 通道上。核心目标只有一个——让「本地模型 云端模型」的切换不再靠手改配置文件而是通过一个统一的 Base URL 和一把 Key 完成。先说清楚这套组合各自负责什么。Ollama 是本地模型运行时负责把 qwen 这类模型跑在你的显卡上WSL2 里通过http://localhost:11434暴露 OpenAI 兼容接口。OpenClaw 是 Agent 编排层它读取~/.openclaw/下的配置决定每次对话调用哪个模型、走哪个端点。QQ 机器人是消息通道用户在 QQ 里发一句话机器人把消息转给 OpenClawOpenClaw 再决定是走本地 Ollama 还是走云端 API。问题就出在「走云端 API」这一步。OpenClaw 默认的模型配置里每个 provider 都要单独填 Base URL 和 API Key。你如果同时接了 Ollama、某个云端模型、再加一个备用模型配置文件里就会出现三套端点、三把 Key。一旦某把 Key 额度用完或者端点变动你得挨个改。而 TaoToken 的作用就是把这些云端模型的调用统一到一个入口一把 Key、一个 Base URL模型通过 Model ID 区分。这样 OpenClaw 里只需要维护一份云端配置本地 Ollama 那份保持不动切换时改 Model ID 就行。适合谁看已经在 WSL2 里装好 Ollama、能跑通ollama run的人想让 QQ 机器人接入本地模型但被 Key 管理搞烦的人以及想用 OpenClaw 做长期 Agent 任务、需要稳定端点的人。如果你还没装 WSL2建议先把 Ubuntu 跑起来后面的步骤才有意义。2. TaoToken 前置准备统一 Key 与 API 通道怎么拿、怎么放在动 OpenClaw 配置之前先把 TaoToken 这边的准备工作做完。这一步不复杂但顺序别搞反否则后面 auth.json 填错会一直报 401。首先明确 TaoToken 在这套架构里的位置。它提供的是 OpenAI 兼容的 API 通道也就是说任何支持自定义 Base URL 的客户端都可以把请求打到 TaoToken 的端点上由它转发到对应的模型。对 OpenClaw 来说这意味着你不需要为每个云端模型单独配置 provider只需要在配置里写一个 providerBase URL 指向 TaoTokenModel ID 写你要用的模型名即可。第一步拿到 API Key。访问 TaoToken 的 API Keys 管理页面deep linkhttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite登录后创建一个新的 Key。建议按用途命名比如openclaw-wsl2方便后面排查是哪个客户端在用。创建后立刻复制页面刷新后就看不到了。第二步确认 Base URL。TaoToken 的 API 端点是https://taotoken.net/api注意这里不带任何路径后缀OpenClaw 或 OpenAI SDK 会自动拼接/v1/chat/completions这类路径。如果你在配置里看到有人写https://taotoken.net/api/v1那多半是重复拼接了会导致 404。第三步确认你要用的 Model ID。TaoToken 支持的模型列表可以在模型对话页面deep linkhttps://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite查看。常见的有 claude 系列、gpt 系列等。记下你打算在 OpenClaw 里用的那个 Model ID后面 auth.json 和 OpenClaw 配置里都要填一致。第四步理解「统一 Key」的含义。以前你可能在 OpenClaw 里配了三个 provider每个都有自己的 Key。现在改成只保留一个指向 TaoToken 的 providerKey 用刚才创建的那把Model ID 按需切换。本地 Ollama 的 provider 保持独立因为它走的是http://localhost:11434不经过 TaoToken。这样你的配置里最多两套端点一套本地、一套云端统一入口。这里有个容易忽略的点WSL2 里的网络环境和 Windows 主机是隔离的但localhost在 WSL2 里默认指向 WSL 自己。所以 Ollama 跑在 WSL 里时OpenClaw 用http://localhost:11434是通的但如果你把 Ollama 装在 Windows 主机上WSL 里就要用主机的 IP。这篇记录默认 Ollama 装在 WSL 里和 OpenClaw 同环境省去网络转发的麻烦。准备工作做完后你手里应该有三样东西一把 TaoToken API Key、一个 Base URLhttps://taotoken.net/api、一个确定的 Model ID。接下来进入配置环节。3. 可复制配置auth.json、OpenClaw provider 与 Ollama 端点对照这一节是整篇的核心所有配置片段都可以直接复制但路径和字段名要和你本地的实际情况对齐。OpenClaw 的配置目录在 WSL 里是~/.openclaw/其中auth.json负责存凭证config.toml或settings.json负责存 provider 和模型路由。不同版本的 OpenClaw 配置文件格式可能略有差异下面以常见的 auth.json config 分离结构为例。先看~/.openclaw/auth.json。这个文件存的是各个 provider 的 API Key格式是 JSON。你要做的是把 TaoToken 的 Key 加进去同时保留 Ollama 的本地配置Ollama 通常不需要 Key但有些版本要求占位{ providers: { taotoken: { api_key: sk-你的TaoTokenKey, base_url: https://taotoken.net/api }, ollama: { api_key: ollama, base_url: http://localhost:11434/v1 } } }注意 Ollama 的 base_url 后面带了/v1因为 Ollama 的 OpenAI 兼容接口路径是/v1/chat/completions。而 TaoToken 的 base_url 不带/v1由客户端自动拼接。这两个不要写混写混了就是 404 或 401。接下来是 OpenClaw 的模型路由配置。假设你的配置文件是~/.openclaw/config.toml那么 provider 和 model 的映射大概长这样[providers.taotoken] type openai base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY [providers.ollama] type openai base_url http://localhost:11434/v1 api_key ollama [models.local_qwen] provider ollama model_id qwen3.5:27b context_window 32768 [models.cloud_reasoning] provider taotoken model_id claude-3-5-sonnet context_window 200000 [agent] default_model local_qwen fallback_model cloud_reasoning这里的关键设计是本地模型和云端模型各占一个 model 条目但它们指向不同的 provider。local_qwen走 Ollamacloud_reasoning走 TaoToken。当你想切换时只需要改default_model的值或者用 OpenClaw 的/model指令临时切换不用动 Key 和 Base URL。如果你用的是settings.json格式结构类似只是语法变成 JSON{ providers: { taotoken: { type: openai, baseUrl: https://taotoken.net/api, apiKey: sk-你的TaoTokenKey }, ollama: { type: openai, baseUrl: http://localhost:11434/v1, apiKey: ollama } }, models: { local_qwen: { provider: ollama, modelId: qwen3.5:27b }, cloud_reasoning: { provider: taotoken, modelId: claude-3-5-sonnet } }, agent: { defaultModel: local_qwen } }配置写完后建议用openclaw config validate检查一遍语法。如果 OpenClaw 版本没有这个命令就直接启动服务看日志。启动命令通常是openclaw onboard --install-daemon或者openclaw start具体看你安装时的提示。还有一个细节环境变量。如果你不想把 Key 明文写在 auth.json 里可以用api_key_env字段引用环境变量。在 WSL 的~/.bashrc里加一行export TAOTOKEN_API_KEYsk-你的Key然后source ~/.bashrc。这样 auth.json 里只写变量名Key 不落盘。对长期运行的机器人来说这个做法更安全。配置完成后你的 OpenClaw 应该能同时看到local_qwen和cloud_reasoning两个模型。下一步就是验证请求是否真的通了。4. 验证请求与成功结果QQ 机器人收发消息、模型切换实测配置写完不代表通了必须实际发一条消息验证。这一节给出具体的验证动作和预期返回你照着做就能判断哪一环出了问题。先验证 Ollama 本地模型是否正常。在 WSL 终端里执行curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3.5:27b, messages: [{role: user, content: 用一句话介绍你自己}] }预期返回是一个 JSONchoices[0].message.content里有模型生成的文本。如果返回model not found说明模型名写错了用ollama list确认实际拉取的模型名。如果返回连接拒绝说明 Ollama 服务没起来执行ollama serve或检查 systemd 状态。再验证 TaoToken 通道是否正常。同样用 curlcurl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoTokenKey \ -H Content-Type: application/json \ -d { model: claude-3-5-sonnet, messages: [{role: user, content: 回复 OK 两个字母}] }预期返回里choices[0].message.content包含OK。如果返回 401说明 Key 错了或者没带Bearer前缀。如果返回 404检查 Base URL 是不是多写了/v1。如果返回model not found说明 Model ID 不在 TaoToken 的支持列表里回模型对话页面确认。两个通道都通了之后启动 OpenClaw 服务然后在 QQ 里给机器人发消息。第一次发消息时OpenClaw 会用default_model指定的模型回复也就是local_qwen。你可以在 QQ 里发一句「你现在用的是什么模型」如果 OpenClaw 的 system prompt 里带了模型信息它会告诉你。更可靠的方式是看 OpenClaw 的日志日志里会打印每次请求走的 provider 和 model。切换模型测试在 QQ 里发送/model cloud_reasoning然后再发一条需要推理的问题比如「帮我分析一下这段代码的时间复杂度」。观察日志里 provider 是否变成了taotoken以及返回速度是否比本地模型慢云端通常有网络延迟。如果切换后报错大概率是 auth.json 里 TaoToken 的 Key 没被正确读取检查环境变量是否 source 了。QQ 机器人插件这块安装时最容易卡在 npm 依赖上。如果你遇到npm install failed按顺序执行这几条sudo apt update sudo apt install -y build-essential python3 sudo apt install -y git gnutls-bin sudo apt update sudo apt install --reinstall ca-certificates sudo update-ca-certificates这几条的作用是补齐编译工具链和证书很多 npm 原生模块编译失败都是因为缺 python3 或 build-essential。执行完再重新安装 QQ 机器人插件成功率会高很多。验证成功的标志有三个QQ 里能收到机器人回复、OpenClaw 日志里能看到 provider 切换记录、curl 直接打 TaoToken 端点能返回内容。三个都满足说明整条链路通了。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 对照这一节把我在配置过程中遇到的和社区里高频出现的报错集中列一下每个都给出原因和修法。你遇到报错时可以直接对照。401 Unauthorized。这是最常见的。原因通常有三个Key 复制时带了空格、auth.json 里字段名写错比如把api_key写成apikey、环境变量没生效。排查方法先用 curl 直接打 TaoToken 端点如果 curl 也 401说明 Key 本身有问题回 API Keys 页面重新创建一把。如果 curl 通了但 OpenClaw 报 401说明 OpenClaw 没读到正确的 Key检查 auth.json 路径是否是~/.openclaw/auth.json以及环境变量是否在启动 OpenClaw 的同一个 shell 里 source 过。local proxy failed。这个报错通常出现在 OpenClaw 尝试通过本地代理转发请求时。原因可能是 OpenClaw 配置里开了 proxy 选项但代理地址不可达。修法检查 config 里有没有proxy或http_proxy相关字段如果有确认代理服务是否在运行。如果你没有用代理直接删掉这些字段。另外WSL2 里的localhost和 Windows 主机的localhost不是一回事如果代理跑在 Windows 上WSL 里要用主机 IP。reading choices 报错。完整报错通常是error reading choices: unexpected end of JSON input或类似。这说明 OpenClaw 收到了响应但响应体不是合法的 JSON。常见原因是 Base URL 写错导致返回了 HTML 错误页或者模型返回了流式响应但客户端按非流式解析。修法确认 Base URL 是https://taotoken.net/api而不是带/v1的版本确认 OpenClaw 的 stream 配置和模型能力匹配。如果用的是 Ollama确认/v1/chat/completions路径正确。OAuth 相关报错。如果你在配置 QQ 机器人时看到 OAuth 字样通常是机器人的鉴权流程没走完。QQ 机器人的创建和绑定需要在 QQ 开放平台完成把网页提供的指令依次输入终端。如果中途断了重新走一遍绑定流程。注意 OAuth token 有有效期过期后需要重新授权。Ollama 内存不足。报错类似model requires more system memory (19.2 GiB) than is available (18.2 GiB)。这是 WSL2 默认内存分配不够。修法在 Windows 用户目录下创建.wslconfig文件写入[wsl2] memory24GB processors8然后wsl --shutdown重启 WSL。内存大小根据你主机实际内存调整建议给 WSL 分配不超过主机内存的 70%。模型切换后没生效。如果你在 QQ 里发了/model cloud_reasoning但日志里还是走本地模型检查 OpenClaw 的会话是否持久化了模型选择。有些版本的/model指令只对当前会话生效新会话会回到 default_model。另外确认cloud_reasoning这个 model 名在 config 里拼写一致大小写敏感。QQ 机器人插件安装失败。除了前面提到的 build-essential 和证书问题还有一个常见原因是 npm 源的问题。可以尝试npm config set registry https://registry.npmmirror.com切换镜像源再重新安装。如果还是失败看具体报错是哪个包编译不过单独装那个包的依赖。排查的核心思路是分层先确认 Ollama 本地通、再确认 TaoToken 云端通、最后确认 OpenClaw 能读到配置。每一层都用 curl 或日志验证不要跳步。6. 长期跑 Agent 的配置建议与统一 Key 的接入入口如果你只是临时玩一下前面的配置够用了。但如果你打算让这个 QQ 机器人长期跑着做日常的 Agent 任务有几个地方值得再优化一下。第一把 Key 从明文改成环境变量。前面提过api_key_env的用法长期运行时建议所有云端 Key 都走环境变量auth.json 里只留变量名。这样即使配置文件被误传Key 也不会泄露。WSL 里可以把 export 写进~/.bashrc但注意 OpenClaw 如果以 daemon 方式启动可能不会加载.bashrc需要在 systemd service 文件里显式声明Environment。第二给模型切换加个默认回退。OpenClaw 的fallback_model字段可以在主模型不可用时自动切换。比如你默认用本地 qwen但本地模型因为显存不足挂了fallback 到 TaoToken 的云端模型机器人不会直接失联。这个配置在长期运行场景下很实用。第三定期检查 TaoToken 的额度。统一 Key 的好处是管理方便但坏处是一把 Key 挂了所有云端模型都不能用。建议在 TaoToken 控制台设置额度提醒或者用 API 定期查余额。控制台入口在https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite。第四如果你后面要接更多模型比如想在 QQ 机器人里同时支持代码生成和日常对话可以按用途拆多个 model 条目但都指向同一个 TaoToken provider。这样 Key 还是一把只是 Model ID 不同。OpenClaw 的/model指令可以让你在 QQ 里直接切换不用重启服务。第五关于 Coding Plan。如果你用 OpenClaw 做的是长期编码类 Agent 任务比如自动改代码、跑测试、提交 PR那可以考虑 TaoToken 的 Coding Plandeep linkhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite。它针对高频编码场景做了额度优化比按量计费更适合长期跑。接入方式和普通 API 一样Base URL 和 Key 不变只是计费模式不同。最后说一个实际经验WSL2 的休眠和恢复有时会导致 Ollama 服务断掉表现为 QQ 机器人突然不回消息。可以在 WSL 里加一个简单的健康检查脚本定时 curl 一下http://localhost:11434/v1/models不通就重启 Ollama。这个脚本用 cron 或 systemd timer 跑都行几行 bash 就够。整套配置的核心思路就是「本地归本地、云端归云端、云端统一入口」。Ollama 负责本地推理TaoToken 负责云端模型的统一 Key 和端点OpenClaw 负责路由QQ 机器人负责消息通道。四者各司其职切换模型时只改 Model ID不动 Key 和 Base URL。这样你后面无论加多少模型配置复杂度都不会线性增长。