OpenClaw Skill 按需读 SKILL.md模型调用还走默认通道TaoToken 这样改 openclaw.yml把weather/SKILL.md放进~/.openclaw/skills/requires.bins里的curl也装好了发一句「帮我查一下上海今天的天气」OpenClaw 却卡在最后一步——LLM 推理请求发不出去。这不是 Skill 系统的问题渐进式披露、资格过滤、read工具加载 SKILL.md 这些活 OpenClaw 自己干得很干净真正断掉的是 skill 被选中之后那一次模型调用provider 的 Base URL 和 Key 没配或者配错了地方。这篇就只处理这一跳用 TaoToken 的兼容通道把openclaw.yml里的模型 provider 接上让/weather 上海这条链路能完整跑通。TaoToken 官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后创建 Key 即可它在这里只提供 Key 和兼容通道不接管 Skill 的任何决策逻辑。一、原问题与场景Skill 选完了模型通道从哪来原文把 OpenClaw 的 Skill 系统拆得很细SKILL.md用 YAML frontmatter 把name、description、location塞进系统提示正文等 LLM 决策后再用read工具加载gh没装时requires.bins会把 github skill 整个从列表剔除/weather 上海可以直接显式触发。但通篇没有交代模型通道从哪来——读者照着把 weather 的 SKILL.md 放好、把 curl 依赖装齐仍然会卡在 LLM 推理请求这一跳。具体卡点有三个第一openclaw.yml里模型 provider 的baseUrl没填或填成了带/v1的地址请求直接 404。第二Key 填的是别处的或者干脆是占位符401 直接返回。第三把「声明了command-dispatch: tool的 skill」和「走模型的 skill」混为一谈——前者是绕过 LLM 的确定性分发那条路径本来就不产生 Token 消耗配不配模型通道都不影响它执行但/weather 上海默认走的是模式一经过 LLM必须要有可用的模型通道。所以本篇的改写点落在原文的实验准备步骤先去 TaoToken 注册并创建 Key再打开openclaw.yml把模型 provider 的 Base URL 填https://taotoken.net/api不带/v1、不加任何参数Key 填刚复制的那一串。配完照原文链路复现一遍发/weather 上海看 LLM 是否先扫available_skills里的 description再read ~/.openclaw/skills/weather/SKILL.md最后执行curl wttr.in/Shanghai?format3。二、TaoToken 前置注册、建 Key、确认通道形态在动openclaw.yml之前先把 TaoToken 这一侧准备好。打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册账号进入控制台创建 API Key。Key 只在创建时完整显示一次复制后先存到本地安全位置后面要填进openclaw.yml。这里要明确 TaoToken 在整条链路里的位置它只提供 Key 和兼容通道。OpenClaw 的渐进式披露、资格过滤、read工具加载 SKILL.md、/weather命令注册这些活仍然是 OpenClaw 自己在做。TaoToken 不参与 skill 的发现、过滤、决策也不改写系统提示里的available_skills摘要。它做的事只有一件当 LLM 决定要用 weather skill、准备发起推理请求时这个请求能通过兼容通道发出去并拿到回复。通道地址是https://taotoken.net/api注意不带/v1也不加任何查询参数。这一点和很多 OpenAI 兼容客户端的习惯不同——不少工具默认会自己在 baseUrl 后面拼/v1/chat/completions如果你填了带/v1的地址最终路径会变成/v1/v1/chat/completions直接 404。OpenClaw 的 provider 配置里baseUrl 就填到/api为止。Key 的形态是一串字符填进配置时不要带引号以外的多余空格也不要在前后加Bearer前缀——OpenClaw 的 provider 层会自己处理鉴权头。如果你是从别的地方复制过来的 Key先确认没有把换行符一起带进去这是后面 401 排查里最常见的一个原因。三、可复制配置openclaw.yml 里改哪几行打开openclaw.yml找到模型 provider 的配置段。不同版本的 OpenClaw 字段名可能略有差异但核心就两个baseUrl和apiKey。下面是一份可直接对照的配置片段# openclaw.yml model: provider: baseUrl: https://taotoken.net/api apiKey: YOUR_API_KEY model: your-model-id三个字段逐一说明baseUrl填https://taotoken.net/api结尾不要加/不要加/v1不要加任何 query 参数。如果你之前填的是https://taotoken.net/api/v1改成不带/v1的版本。apiKey填你在 TaoToken 控制台创建的那一串 Key。注意 YAML 里字符串建议加引号避免 Key 里出现特殊字符时被解析成别的类型。如果你用的是环境变量注入确认变量名和 OpenClaw 读取的字段一致别出现「变量设了但配置里写的是字面量」这种情况。model填你要用的模型 ID。这个 ID 要和 TaoToken 通道支持的模型对应填错会返回模型不存在的错误。如果你不确定该填哪个先去模型对话页面确认可用模型列表再回来填。改完保存重启 OpenClaw 让配置生效。如果你是用 CLI 方式启动的确认启动命令没有用别的参数覆盖掉openclaw.yml里的 provider 配置——有些启动脚本会从环境变量读OPENCLAW_MODEL_BASE_URL之类的变量优先级高于配置文件这种情况要一并检查。另外提醒一点openclaw.yml里可能还有skills.load.extraDirs之类的 skill 相关配置那些不用动。本篇只改模型 provider 这一段skill 的发现、过滤、加载逻辑保持原样。四、验证请求/weather 上海 走一遍完整链路配置改完发/weather 上海观察 OpenClaw 的执行过程。正常情况下你会看到这样一条链路第一步LLM 扫描系统提示里的available_skills逐条看description。weather skill 的 description 里写了「Use when: user asks about weather, temperature, or forecasts for any location」匹配上了。第二步LLM 调用read工具读取location字段指向的路径也就是~/.openclaw/skills/weather/SKILL.md。这一步是渐进式披露的关键——正文只在 LLM 决定使用这个 skill 之后才加载进上下文。第三步LLM 读完 SKILL.md 正文按照里面的命令模板执行curl wttr.in/Shanghai?format3拿到天气数据组织成自然语言回复。如果这条链路在第一步或第二步就断了说明模型通道没通——LLM 根本没收到请求或者收到了但返回了错误。如果前两步正常、第三步的 curl 没执行那问题在 skill 正文或工具权限不在模型通道。验证模型通道是否真的通了可以做一个最小化测试在 OpenClaw 里发一句不触发任何 skill 的普通对话比如「你好」。如果这句能正常回复说明模型通道是通的/weather 上海卡住就是 skill 侧的问题如果这句也报错那就是 provider 配置的问题回到上一节检查baseUrl和apiKey。还有一个容易混淆的点原文第六节提到声明了command-dispatch: tool的 skill 是绕过 LLM 的确定性分发。如果你给 weather skill 的 frontmatter 里加了command-dispatch: tool command-tool: exec command-arg-mode: raw那么/weather 上海会直接调用exec工具args 原样传「上海」完全不经过 LLM。这条路径不产生 Token 消耗也不依赖模型通道。所以如果你测的是这条路径模型通道配没配都不影响它执行——别把两条路径的排查混在一起。默认情况下 weather skill 走的是模式一经过 LLM需要模型通道。五、本篇常见错排查错误一baseUrl 带了 /v1请求 404。这是最高频的一个。OpenClaw 的 provider 层会在 baseUrl 后面拼具体的 API 路径如果你填的是https://taotoken.net/api/v1最终请求路径会多一层/v1。改成https://taotoken.net/api即可。错误二Key 前后有空格或换行401。从控制台复制 Key 时容易把行尾的换行符一起复制进去。填进 YAML 后Key 字符串末尾多一个\n鉴权头就不对了。检查方法是把 Key 单独拿出来做一次请求测试确认能通再填回配置。错误三模型 ID 填错返回模型不存在。model字段要和 TaoToken 通道支持的模型对应。如果你从别处复制了一个模型名先确认它在当前通道下可用。不确定就先去模型对话页面发一条测试消息确认模型可用再填进openclaw.yml。错误四环境变量覆盖了配置文件。有些启动方式会从环境变量读 provider 配置优先级高于openclaw.yml。如果你改了配置文件但没生效检查一下启动脚本里有没有export OPENCLAW_MODEL_BASE_URL...之类的语句或者.env文件里有没有同名变量。错误五把 command-dispatch 路径当成模型路径排查。如果你的 skill 声明了command-dispatch: tool/weather 上海根本不经过 LLM模型通道配不配都不影响它。这种情况下你去查 provider 配置是白费功夫应该去查exec工具的权限和参数传递。错误六skill 被资格过滤剔除了误以为是模型通道问题。如果curl没装requires.bins: [curl]检查失败weather skill 会从available_skills里整个消失LLM 根本看不到它自然不会发起模型调用。这种情况下你看到的现象是「LLM 回复说不知道怎么查天气」而不是请求报错。先确认curl在 PATH 里再排查模型通道。错误七read 工具读不到 SKILL.md链路断在第二步。如果location里的路径和实际文件路径不一致LLM 调用read会失败。检查~/.openclaw/skills/weather/SKILL.md是否真实存在以及路径里的~是否被正确展开。沙箱环境下还要注意 skill 是否同步进了容器。六、语义一致Skill 决策归 OpenClaw模型通道归 TaoToken把这条链路拆清楚之后职责边界就很明确了Skill 的发现、资格过滤、渐进式披露、read工具加载 SKILL.md、/weather命令注册这些全部是 OpenClaw 自己在做TaoToken 不参与。TaoToken 只负责一件事——当 LLM 决定使用某个 skill、准备发起推理请求时这个请求能通过兼容通道发出去并拿到回复。所以openclaw.yml里你只需要改模型 provider 的baseUrl和apiKey两个字段skill 相关的配置一行都不用动。配完之后/weather 上海的完整链路是LLM 扫available_skills摘要 → 匹配 weather 的 description →read加载 SKILL.md 正文 → 执行curl wttr.in/Shanghai?format3→ 组织回复。这条链路里OpenClaw 管决策和工具执行TaoToken 管模型调用通道各司其职。如果你在配置过程中遇到 provider 报错、Key 鉴权失败、模型 ID 不识别这类问题去 API Keys 页面和接入文档对照排查如果你想先确认模型通道本身是否可用去模型对话页面发一条测试消息如果你打算长期用 OpenClaw 跑编码类 Agent 任务可以了解 Coding Plan 的额度形态。三个入口按需选择不用只盯着首页。