1. WSL 里跑 OpenClaw，为什么 settings.json 和 Key 配置总让人绕晕
OpenClaw 在 Windows 上的官方推荐路径是 WSL2，这件事本身不难理解：CLI 和 Gateway 都跑在 Linux 侧，工具链一致、依赖冲突少，比硬扛原生 Windows 省心得多。但真正上手之后，很多人会卡在同一个地方——settings.json到底该写在哪、模型 Key 该配在哪一层、为什么 Gateway 起来了 Control UI 也能打开，可一发消息就报认证失败或者模型无响应。
这个问题的根源在于 OpenClaw 是分层系统。Gateway 是总机，负责接入、路由、会话和健康检查；Channel 是线路，把 Telegram、Discord、Slack 这些平台接进来；Agent 是干活的人；Model 是底层推理引擎；而 Auth profile 则是模型侧的凭据档案，管理 API key、OAuth、token 这些认证信息。你在 WSL 里敲的openclaw gateway或openclaw onboard --install-daemon，生效范围都在 WSL 的 Ubuntu 里，浏览器只是从 Windows 侧访问127.0.0.1:18789的 Control UI，它连的还是 WSL 里的 Gateway。
所以当模型调用失败时，问题往往不在 Gateway 本身，而在 Auth profile 这一层——也就是你的模型 Key 有没有正确落到 OpenClaw 能读到的地方。这篇就围绕 WSL 场景，把settings.json的骨架和 TaoToken 统一 Key 的接入步骤讲清楚，让你启动 OpenClaw 后能确认请求确实经统一通道发出、配置真正生效。适合已经在 WSL2 里装好 OpenClaw、但模型侧还没跑通的开发者。
2. 前置准备：WSL 环境检查与 TaoToken 统一 Key 获取
在动settings.json之前，先把 WSL 侧的基础条件确认一遍。OpenClaw 的 Gateway service install 依赖 systemd，如果你的 WSL 还没启用，先处理这个。
2.1 确认 WSL2 与 systemd 状态
打开 WSL 终端，执行：
wsl --version在 Windows PowerShell 里能看到 WSL 版本号即可。接着进 WSL 内部确认 systemd：
systemctl is-system-running如果返回running或degraded，说明 systemd 已启用。若报错说 systemd 未运行，需要在/etc/wsl.conf里加上：
[boot] systemd=true然后回到 PowerShell 执行wsl --shutdown再重新进入。这一步不做，后面openclaw onboard --install-daemon会直接失败。
2.2 获取 TaoToken 统一 Key
TaoToken 的作用是把模型侧的认证收敛到一个统一通道，你不需要在 OpenClaw 里为每个模型单独维护一套凭据。获取 Key 的入口在控制台：
https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=wsl_openclaw_settings&utm_campaign=rewrite登录后在 API Keys 页面创建一个新 Key，复制出来备用。这个 Key 就是后面要写进 OpenClaw Auth profile 的凭据。API 通道的基础地址是：
https://taotoken.net/api注意这个地址不带任何查询参数，直接作为 base URL 使用。如果你后续要接 Claude Code 这类工具，Anthropic 兼容端点也走同一个通道，具体路径在接入文档里有说明：
https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=wsl_openclaw_settings&utm_campaign=rewriteKey 拿到后先别急着写配置，下面先把settings.json的结构理清楚。
3. 可复制配置：settings.json 骨架与 TaoToken 接入
OpenClaw 的配置文件在 WSL 里的位置通常是~/.config/openclaw/settings.json，具体路径可以用openclaw config path确认。下面给一份可直接改用的骨架，重点看auth和models两段。
3.1 settings.json 完整骨架
{ "gateway": { "host": "127.0.0.1", "port": 18789, "logLevel": "info" }, "auth": { "profiles": { "taotoken-unified": { "type": "api_key", "provider": "openai-compatible", "apiKey": "sk-你的TaoTokenKey", "baseUrl": "https://taotoken.net/api" } }, "defaultProfile": "taotoken-unified" }, "models": { "default": "gpt-4o-mini", "fallback": ["claude-3-5-sonnet"], "provider": "taotoken-unified" }, "channels": { "telegram": { "enabled": false } } }几个关键点说明一下。auth.profiles里定义了一个名为taotoken-unified的凭据档案，type是api_key，provider用openai-compatible是因为 TaoToken 的 API 通道兼容 OpenAI 的请求格式。baseUrl填https://taotoken.net/api，不要带尾部斜杠。models.provider指向这个 profile 名字，这样模型调用就会走统一通道。
3.2 用环境变量替代明文 Key
把 Key 明文写在settings.json里不太安全，尤其是 WSL 和 Windows 之间有文件共享时。更稳妥的做法是用环境变量，在~/.bashrc或~/.zshrc里加：
export TAOTOKEN_API_KEY="sk-你的TaoTokenKey"然后settings.json里改成引用：
{ "auth": { "profiles": { "taotoken-unified": { "type": "api_key", "provider": "openai-compatible", "apiKeyEnv": "TAOTOKEN_API_KEY", "baseUrl": "https://taotoken.net/api" } }, "defaultProfile": "taotoken-unified" } }改完执行source ~/.bashrc让变量生效。OpenClaw 启动时会读取这个环境变量，Key 就不会出现在配置文件里。
3.3 参数对照表
| 字段 | 作用 | 建议值 |
|---|---|---|
gateway.host | Gateway 绑定地址 | 127.0.0.1，仅本机访问 |
gateway.port | Control UI 端口 | 18789，与官方默认一致 |
auth.profiles.*.type | 凭据类型 | api_key |
auth.profiles.*.provider | 请求协议 | openai-compatible |
auth.profiles.*.baseUrl | API 通道地址 | https://taotoken.net/api |
auth.defaultProfile | 默认凭据档案 | 与 profiles 里的键名一致 |
models.provider | 模型走哪个档案 | 同上 |
配置写完后，先别急着启动 Gateway，用下面的命令做一次配置校验。
4. 验证请求：确认 OpenClaw 经统一通道发出
配置生效与否，不能只看 Gateway 有没有起来。网页能打开只说明 Gateway 大概率在线、HTTP/WebSocket 能访问，但模型调用走没走统一通道是另一回事。下面分三步验证。
4.1 配置语法与档案加载检查
openclaw config validate如果返回配置合法，再查 Auth profile 是否被正确加载：
openclaw auth list正常输出里应该能看到taotoken-unified这个档案，并且标记为 default。如果这里看不到，说明settings.json路径不对或者 JSON 语法有误，回头检查openclaw config path指向的文件。
4.2 发一条测试请求
用 OpenClaw 自带的测试命令直接打模型：
openclaw model test --prompt "reply with ok"这条命令会走models.provider指定的档案，也就是taotoken-unified。如果返回ok或类似响应，说明请求已经经 TaoToken 统一通道发出并成功返回。如果报 401，多半是 Key 无效或环境变量没生效；报 404 则检查baseUrl是否写成了带路径的形式。
4.3 从日志确认通道地址
想更确定请求确实走了统一通道，可以看 Gateway 日志：
openclaw gateway logs --follow在另一个终端再发一次openclaw model test，日志里会出现请求的目标地址。确认它指向taotoken.net/api而不是其他默认端点，就说明配置真正生效了。这一步做完，模型侧的最小闭环就算跑通了。
5. 本篇常见错排查：WSL 下 OpenClaw 配置的坑
即使按上面步骤走，WSL 场景还是有几个高频问题。下面按现象列出来，方便对照。
5.1 Gateway 起了但模型调用失败
这是最典型的。Gateway 在线只代表总机开机，不代表模型线路接通。先跑openclaw auth list确认档案加载，再跑openclaw model test看具体报错。如果档案在但测试失败，重点查 Key 和环境变量。WSL 里export的变量在非交互式 shell 里可能读不到，建议写进~/.profile而不是只写~/.bashrc。
5.2 远程访问时地址写成 127.0.0.1
如果你想让别的机器或远程节点访问 WSL 里的 Gateway，不能继续用127.0.0.1，因为那指向的是对方自己。需要改成 WSL 可达的地址，必要时在 Windows 侧做端口转发。官方 WSL 文档里有 portproxy 的配置示例，核心思路是把 Windows 主机的某个端口转发到 WSL 的18789。这一步不做，远程客户端连不上是必然的。
5.3 Channel 不工作与模型配置无关
Telegram、Discord 这些 channel 的接入是独立一层，涉及各自的 token、bot 权限和平台连接状态。Gateway 正常启动不依赖任何 channel，所以「网页能打开但 channel 不工作」不代表模型配置有问题。排查 channel 要看 health-monitor 日志里有没有 stuck 或 disconnected 的重连记录，以及对应平台的 bot 权限是否配全。
5.4 配置文件路径混淆
WSL 里 OpenClaw 读的是 Linux 侧路径，不是 Windows 的C:\Users\...。如果你在 Windows 编辑器里改了配置但没同步到 WSL 文件系统，OpenClaw 读到的还是旧文件。用openclaw config path确认实际路径，直接在 WSL 里用nano或vim改最稳妥。
6. 统一 Key 之后：模型对话与长期编码的接入选择
模型侧跑通之后，接下来看你的使用场景。如果只是想验证模型是否正常、偶尔对话测试，可以直接用模型对话入口：
https://taotoken.net/model-chat?utm_source=taotoken_aicg_blog_end&utm_content=wsl_openclaw_settings&utm_campaign=rewrite如果你打算在 WSL 里长期跑编码任务或 Agent 工作流，Coding Plan 更适合，它针对持续调用做了额度优化：
https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=wsl_openclaw_settings&utm_campaign=rewrite需要管理多个 Key 或查看调用量，回控制台的 API Keys 页面：
https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=wsl_openclaw_settings&utm_campaign=rewrite接入细节和兼容端点说明都在文档里：
https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=wsl_openclaw_settings&utm_campaign=rewriteWSL 场景下 OpenClaw 的配置核心就一句话：Gateway 在 Linux 侧，模型凭据走 Auth profile，统一 Key 落到settings.json的auth.profiles里，用openclaw model test验证请求确实经统一通道发出。把这几层分清楚，后面 channel 和 Agent 的排错就不会再和模型配置混在一起。
