OpenClaw 自定义模型调用失败？TaoToken 这样填 provider 和 base_url

OpenClaw 的「拼豆 / 自定义模型」表单里，密钥或 model.id 填错，最直接的表现就是保存后连接指示灯不绿、微信小号发消息没有回复，控制台偶尔只给一句含糊的报错。把这条自定义模型通道换成 TaoToken 时，先去 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content= 注册并创建 Key，再回 OpenClaw 填 provider 和 base_url。原文里第三章在蓝耘MaaS 控制台新建以 sk- 开头的密钥、记下 https://maas-api.lanyun.net/v1 和模型 ID /maas/deepseek-ai/DeepSeek-V3.2，第五章把这些值逐项填进「拼豆 / 自定义模型」。这套动作本身不用推翻，只是密钥来源、Base URL 和模型名要换成新通道给的那一套。

微信通道绑定、人设提示词、暖心陪伴 Agent 的对话逻辑都照原文走，改动的只有自定义模型这一层。下面按原文节奏拆开：先看填错为什么无回复，再去拿 Key，然后回到表单逐项填，最后看指示灯和微信小号测试，仍然不通就按原文章节九查端口与通道掉线。

1. OpenClaw 拼豆表单里，密钥和 model.id 一错就无回复

1.1 原文那套蓝耘MaaS 参数为什么会卡在调用层

原文的链路很清楚：蓝耘MaaS 控制台里新建密钥，记下 base_url 和模型 ID，再把它们填进 OpenClaw 的「拼豆 / 自定义模型」。这种表单看起来字段不多，但每一个都参与了请求组装。密钥决定能不能通过鉴权，base_url 决定请求发到哪个入口，model.id 决定入口后面选哪个模型，api 决定用哪种请求格式。任何一项错位，结果都不是“模型稍微变笨”，而是调用失败、无回复、日志里报错。

原文点名的两个高频坑，正好都落在这一层。一个是密钥复制时带上了空格，或者把别的项目 Key 混进来；另一个是 model.id 填成了上一个平台的路径，比如 /maas/deepseek-ai/DeepSeek-V3.2。只要 model.id 不在当前通道的可用列表里，请求就会在模型选择阶段被拒，OpenClaw 前端往往只表现成“没回”，不会直接告诉你是哪一项错了。

1.2 把“密钥来源”这一步换到新入口

原文第三章让你在蓝耘控制台新建以 sk- 开头的密钥。现在这一步换成打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content= 注册账号并创建 API Key。创建好之后，复制那串 Key，后面在 OpenClaw 里先用 YOUR_API_KEY 占位，真正保存前再替换成刚复制的那把。创建 Key 时页面上会给出可用的模型名，记下它，不要继续沿用 /maas/deepseek-ai/DeepSeek-V3.2。

这一步只改“Key 从哪里来”和“模型名从哪里查”。原文里的微信小号通道、OpenClaw 的监听端口、人设提示词、默认推理模型设置，都还是按那套流程走。换句话说，微信暖心陪伴 Agent 的外壳不动，只把推理请求的出口换到新的兼容通道。

2. 从蓝耘控制台到 TaoToken 控制台：Key、Base URL 和模型名怎么换

2.1 创建 Key 的动作没变，入口变了

打开 TaoToken，登录后进控制台创建 API Key。这里和原文“新建密钥”一样：命名、复制、保存。区别是后面表单里的 api_key 填 YOUR_API_KEY，而 YOUR_API_KEY 要替换成这把 Key。不要把 Key 写进公开仓库，也不要把它贴在聊天记录里；OpenClaw 需要的时候再填进自定义模型表单。

如果你同时保留了原来的蓝耘配置，建议先把旧的自定义模型副本留一份，不要直接覆盖。这样一旦微信通道测试不通，还能判断是模型通道的问题，还是微信通道本来就掉线。Key 的入口和模型广场都在这个控制台里，模型名也以页面当时给出的列表为准。

2.2 Base URL 对照：这次末尾不要 /v1

原文记下的蓝耘 base_url 是 https://maas-api.lanyun.net/v1，末尾带了 /v1。换到当前通道时，OpenClaw 的 base_url 填 https://taotoken.net/api，末尾不要 /v1，也不要加任何 UTM 参数。这里容易混淆：浏览器里打开的官网落地页带查询参数，填进工具里的接口地址不带查询参数。

表格里最需要盯住的是两列：base_url 和 model.id。base_url 多了 /v1，请求路径就会错位；model.id 直接抄旧平台的路径，模型选择就会失败。api 这一项仍然保持 chat/completions，和原文一致，不需要改。

2.3 模型名不要直接抄旧路径

/maas/deepseek-ai/DeepSeek-V3.2 是原文蓝耘控制台里的模型 ID，不是当前通道的正式模型名。你在创建 Key 的页面或者模型广场里看到哪个模型名，就把那个完整名称复制到 OpenClaw 的 model.id 字段。不要自己加日期后缀，也不要把 DeepSeek 的旧路径硬塞进去。

如果页面上同时列了多个模型，优先选你已经在微信陪伴 Agent 里测过的同类型模型。选不准就先用列表里最基础、最通用的那个，把链路跑通，再去换更合适的模型。模型名以当时列表为准，不要凭记忆写。

3. OpenClaw 自定义模型表单逐项填：provider、base_url、api、model.id

3.1 打开「拼豆 / 自定义模型」入口

回到原文第五章的位置，在 OpenClaw 里进入「拼豆 / 自定义模型」，新增一个自定义模型。provider 这一栏可以自己起名，建议写成 taotoken，方便和原来的蓝耘配置区分。它只是你本地给这条通道起的标识，不要求跟模型名一样，但不要留空，也不要用中文和空格混排。

新增之后，先把表单里的必填项过一遍。OpenClaw 的自定义模型表单通常会把 base_url、api_key、model.id 放在同一屏，api 格式可能叫“接口协议”或“调用格式”。名称可以按界面叫法变化，值不要变。

3.2 表单字段对照表

provider 写成 taotoken 之后，OpenClaw 内部会把这个名称和 base_url、Key 绑定在一起。以后你切模型时，先确认默认推理模型指向的是这个 provider，而不是旧的蓝耘配置。显示名称可以随你写，但 model.id 必须严格复制页面给出的名称。

3.3 保存并设为默认推理模型

填完后先保存自定义模型，再回到模型列表，把这个新模型设为默认推理模型。这一步和原文一致：不是填完表单就自动生效，还要在 OpenClaw 里把默认推理模型切过去。如果列表里同时存在蓝耘模型和 taotoken 模型，默认项一定要选后者，否则微信小号发消息时走的还是旧通道。

切换后不要马上改人设提示词，也不要动微信通道。先让配置稳定下来，再去测试。很多“无回复”其实是默认模型没切，请求仍然发向已经不可用的旧配置。

3.4 这几个字段不要加官网 UTM

浏览器里打开的 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content= 带有查询参数，这是给人点的落地页。填进 OpenClaw 的 base_url 只写 https://taotoken.net/api，不要在后面拼 ?utm_source，也不要拼 &utm_content。把落地页地址和接口地址混用，是自定义模型配置里很隐蔽的一种错。

api_key 也不要带引号或空格。复制 Key 时前后不要多拿字符，很多表单不会自动 trim。model.id 如果是从页面复制的，注意不要把说明文字一起复制进去。

4. 连接指示灯变绿之后，再用微信小号发一条测试消息

4.1 保存后先看 OpenClaw 的连接指示灯

保存并设为默认推理模型后，回到 OpenClaw 主界面看连接指示灯。指示灯变绿，说明自定义模型的配置至少能被 OpenClaw 识别，并且 base_url 和 Key 没有在本地校验阶段被直接拒绝。如果还是不绿，先别去微信通道找原因，优先检查上表中的四个值：provider、base_url、api_key、model.id。

指示灯不绿时，常见情况是 base_url 末尾多了 /v1，或者 api_key 还是 YOUR_API_KEY 没换。另一种是 model.id 填了旧蓝耘路径。把这几项改回正确值后重新保存，再切一次默认推理模型。

4.2 微信小号测试：看是哪一段没回

连接指示灯变绿后，用微信小号给 OpenClaw 发一条测试消息，比如原文里那种简短问候。观察三个地方：OpenClaw 后端有没有收到微信消息、有没有发出模型请求、请求有没有返回。如果微信消息进来了但模型请求没发出，问题在 OpenClaw 的默认模型或推理调用；如果模型请求发出但没返回，问题在 Key、base_url 或 model.id；如果模型返回了但微信没收到，问题在微信通道和端口。

这一步不要只看微信有没有弹回复。无回复只是最终现象，真正要区分的是“消息有没有进 OpenClaw”和“调用有没有出 OpenClaw”。把日志打开，对照时间点看。

4.3 去控制台对一次调用记录

测试消息发出后，回到 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content= 看控制台里的调用记录或用量变化。如果这次调用被记上，说明请求已经到达通道，微信侧的问题更大；如果完全没有记录，说明 OpenClaw 的请求没有发出来，或者发出时就被本地配置拦住了。这里也能顺便核对 model.id 是否和页面列表一致。

控制台里看到的模型名、调用时间、Key 名称，和 OpenClaw 表单里的值对得上，再继续调微信通道。对不上就先改自定义模型，不要急着改人设提示词。

5. 仍然无回复：按原文章节九排查端口与通道掉线

5.1 先分清模型通道和微信通道

连接指示灯不绿，优先查模型通道；指示灯绿但微信小号没回复，优先查微信通道。原文第九章讲的是端口与通道掉线，这个顺序不要反过来。模型通道的错通常集中在 base_url、api_key、model.id；微信通道的错通常集中在监听端口、登录态、进程存活、默认推理模型是否切换。

如果控制台里看不到任何调用记录，而指示灯又是绿的，也有可能是 OpenClaw 没有把微信消息路由到默认模型。检查模型列表里默认推理模型是不是刚刚新增的 taotoken 项，而不是旧模型。

5.2 四个高频填错点

第一，api_key 还是 YOUR_API_KEY 占位符，没有替换成创建好的 Key。第二，base_url 写成了 https://taotoken.net/api/v1，末尾多了 /v1。第三，model.id 填了原文里的 /maas/deepseek-ai/DeepSeek-V3.2，而不是模型广场给出的名称。第四，api 格式没有保持 chat/completions，或者被误改成别的协议。

这四项里，第二项和第三项最容易被忽略，因为它们在表单里看起来都像“路径”。base_url 是通道入口，model.id 是模型名称，两者层级不同。入口对了，模型名错了，照样无回复。

5.3 端口与通道掉线对照原文第九章

按原文第九章逐项排查端口与通道掉线：OpenClaw 进程是否还在、监听端口有没有被其他程序占用、微信通道是否掉线后没有重新登录、小号发的消息是否被其他规则拦截。你可以在本地终端查看 OpenClaw 日志，确认微信消息有没有进来，再把报错贴回对话里分析。不要直接把生产库或生产机器接到对话里执行操作，OpenClaw 只负责生成、解释和对照，实际命令仍由你在本地跑。

如果日志显示微信通道正常，但模型调用一直超时，回到自定义模型表单重新核对 base_url 和 Key。改完保存后，重新设一次默认推理模型，再用微信小号发消息。

5.4 回控制台看请求有没有到达

再一次打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content= ，看这次测试有没有对应的调用记录。有记录但微信无回复，说明请求已经打到模型通道，问题在返回链或微信发送链；没有记录，说明请求根本没出 OpenClaw。这样能把“模型配置错”和“微信通道掉线”分开，不会在两边同时乱改。

6. 把这条 OpenClaw 通道固定下来，继续跑微信暖心陪伴 Agent

6.1 记录一份自己的参数快照

链路跑通后，把这次可用的参数记在本地笔记里：provider 写 taotoken，base_url 写 https://taotoken.net/api，api 写 chat/completions，api_key 只记“已保存在本机”，model.id 写当时可用的名称。不要把 Key 提交到 Git，也不要写进公开的配置文件。以后换模型时，只需要改 model.id，不要重新动 provider 和 base_url。

如果 OpenClaw 支持导出配置，导出后检查一遍有没有把 UTM 参数带进 base_url。落地页链接和接口地址分开保存，省得下次复制串行。

6.2 下一步：模型对话、创建 Key、Coding Plan

微信小号测试通过后，先在 TaoToken 模型对话 里用同一把 Key 发一条消息，确认模型名和 Base URL 在另一个入口下也能正常工作。长期跑陪伴 Agent 的话，可以打开 Coding Plan 看套餐是否够用；需要重新创建或管理 Key 时，到 控制台 API Keys 处理。以后如果还要在 Claude Code 里复用这把 Key，环境变量和接入文件对照见 Claude Code 接入文档。