OpenClaw 的「拼豆 / 自定义模型」表单里密钥或 model.id 填错最直接的表现就是保存后连接指示灯不绿、微信小号发消息没有回复控制台偶尔只给一句含糊的报错。把这条自定义模型通道换成 TaoToken 时先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_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_sourcetaotoken_aicg_blog_endutm_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 参数。这里容易混淆浏览器里打开的官网落地页带查询参数填进工具里的接口地址不带查询参数。项目原文蓝耘MaaS当前 OpenClaw 要填Base URLhttps://maas-api.lanyun.net/v1https://taotoken.net/api末尾 /v1有不要API 格式chat/completionschat/completionsmodel.id/maas/deepseek-ai/DeepSeek-V3.2以模型广场或创建 Key 页面为准api_key蓝耘 sk- 密钥YOUR_API_KEY从官网创建后替换表格里最需要盯住的是两列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.id3.1 打开「拼豆 / 自定义模型」入口回到原文第五章的位置在 OpenClaw 里进入「拼豆 / 自定义模型」新增一个自定义模型。provider 这一栏可以自己起名建议写成 taotoken方便和原来的蓝耘配置区分。它只是你本地给这条通道起的标识不要求跟模型名一样但不要留空也不要用中文和空格混排。新增之后先把表单里的必填项过一遍。OpenClaw 的自定义模型表单通常会把 base_url、api_key、model.id 放在同一屏api 格式可能叫“接口协议”或“调用格式”。名称可以按界面叫法变化值不要变。3.2 表单字段对照表字段填什么说明providertaotoken自己起名用来区分旧通道base_urlhttps://taotoken.net/api末尾不要 /v1不要加 UTMapichat/completions和原文保持一致api_keyYOUR_API_KEY先占位保存前换成刚创建的 Keymodel.idYOUR_MODEL_ID以模型广场或创建 Key 页面给出的模型名为准显示名称微信暖心陪伴只影响列表里怎么显示默认推理模型保存后再设为默认不要和旧蓝耘模型同时抢默认provider 写成 taotoken 之后OpenClaw 内部会把这个名称和 base_url、Key 绑定在一起。以后你切模型时先确认默认推理模型指向的是这个 provider而不是旧的蓝耘配置。显示名称可以随你写但 model.id 必须严格复制页面给出的名称。3.3 保存并设为默认推理模型填完后先保存自定义模型再回到模型列表把这个新模型设为默认推理模型。这一步和原文一致不是填完表单就自动生效还要在 OpenClaw 里把默认推理模型切过去。如果列表里同时存在蓝耘模型和 taotoken 模型默认项一定要选后者否则微信小号发消息时走的还是旧通道。切换后不要马上改人设提示词也不要动微信通道。先让配置稳定下来再去测试。很多“无回复”其实是默认模型没切请求仍然发向已经不可用的旧配置。3.4 这几个字段不要加官网 UTM浏览器里打开的 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_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_sourcetaotoken_aicg_blog_endutm_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_sourcetaotoken_aicg_blog_endutm_content 看这次测试有没有对应的调用记录。有记录但微信无回复说明请求已经打到模型通道问题在返回链或微信发送链没有记录说明请求根本没出 OpenClaw。这样能把“模型配置错”和“微信通道掉线”分开不会在两边同时乱改。6. 把这条 OpenClaw 通道固定下来继续跑微信暖心陪伴 Agent6.1 记录一份自己的参数快照链路跑通后把这次可用的参数记在本地笔记里provider 写 taotokenbase_url 写 https://taotoken.net/apiapi 写 chat/completionsapi_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 接入文档。