在pnpm openclaw onboard的交互流程里，走到「选择 AI 模型」这一步最容易停住：前面消息渠道选 Easemob，orgName、appName、clientId、clientSecret、accountId 一路填得很顺，到了模型凭据却要你先有一个模型服务商账号，注册、拿 API Key、再确认模型 ID。这段通道其实可以走 TaoToken，先在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 注册并创建一把 Key，再回到 onboard 把模型环节补完，环信那边的助手账号就不用干等着了。要提前说清楚的是，TaoToken 在这条链路里只负责模型通道和 Key 这一件事：环信的 OrgName、Client Secret 还是得按 5.3 节填，5.6 节的 Webhook/webhooks/easemob也照旧挂在你自己的服务上，两者不要混成一个东西来理解。
这篇按「接入配置」的视角走一遍：先备 Key，再在 onboard 里把 Easemob 渠道和模型凭据分开填，然后回来检查配置文件有没有被多补/v1，最后起 gateway 用 WebIM Demo 发一句「你好」，看消息回调进来之后到底有没有命中模型请求。
1. onboard 停在「选择 AI 模型」，先把 TaoToken 的 Key 备好
1.1 环信侧填得再完整，也替代不了模型凭据
很多人的第一反应是：环信应用建好了，orgName、appName、clientId、clientSecret、accountId 都拿到了，助手账号my_ai_assistant也建了，为什么 onboard 还是不走完。原因是这两套东西根本不在一层：环信那五个字段解决的是「消息怎么进来、回调打到哪」，模型凭据解决的是「助手拿什么生成一句话回出去」。前者是通道，后者是大脑，缺一个都跑不通。
OpenClaw 收到环信推过来的消息之后，要做的事是拼一段上下文、按模型配置发一次请求、再把返回的文本回写到会话里。这一次请求会消耗 Token，消耗的是模型通道那边的额度，跟环信的账号套餐没有关系。所以 onboard 到模型那一步不是形式主义，它是在问你：请求发到哪个 Base URL、用哪把 Key、默认用哪个模型 ID。
1.2 在 TaoToken 创建 Key，顺手确认模型 ID
打开 TaoToken，注册登录后进控制台创建一把 API Key，后面在 onboard 的模型凭据环节直接粘进去。Key 只展示一次的情况很常见，复制完先存到自己的密码管理器里，不要顺手贴进群聊，也不要写进会提交到 Git 的示例文件。
接着看一眼模型广场当时列出的可用模型，把打算用的模型 ID 记下来。这里特别提醒：模型 ID 一律以 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 模型广场当时的列表为准，别照抄某篇旧文章里带日期后缀的名字。模型上下架和命名会变，抄错了报错信息通常还挺含糊，排查起来很费时间。
1.3 四个值、两个来源，别记混
配置前先把下面这张表在心里过一遍，后面每一步都能对上号：
| 要填的值 | 从哪来 | 填到哪 |
|---|---|---|
| 模型 Base URL | 固定填https://taotoken.net/api | OpenClaw 的模型地址 |
| API Key | TaoToken 控制台创建的 Key | OpenClaw 的模型凭据 |
| 模型 ID | 模型广场当时列表 | OpenClaw 的默认模型 |
| orgName / appName / clientId / clientSecret / accountId | 环信应用后台 | onboard 的 Easemob 渠道段 |
| Webhook 路径 | 5.6 节约定 | 环信后台的回调地址 |
注意 Base URL 这一格写的是https://taotoken.net/api，末尾不带/v1，也不带任何查询参数。这是本篇最容易出错的地方，后面还会专门讲一次。
2. onboard 里 Easemob 凭据和模型凭据分开填
2.1 消息渠道仍然选 Easemob，五个字段按 5.3 节来
重新跑pnpm openclaw onboard，或者接着上次没走完的流程往下走，消息渠道这一步不要改，还是选 Easemob。orgName、appName、clientId、clientSecret、accountId 这五个字段从环信应用后台复制，accountId一般就是你那个助手账号的标识，比如my_ai_assistant。这一步跟 TaoToken 没任何关系，别把手里的模型 Key 填到 clientSecret 那一栏，两个都是长字符串，看错一次够查半小时。
2.2 模型凭据环节：Base URL 填https://taotoken.net/api
走到模型配置时，如果 onboard 让你选模型提供方，优先选「OpenAI 兼容」或允许自定义 Base URL 的那一项，然后把地址填成https://taotoken.net/api。交互过程大致是下面这个节奏，字段名可能随版本略有差异，但三项核心内容是一致的：
pnpm openclaw onboard ? 选择消息渠道 › Easemob ? orgName: YOUR_EASEMOB_ORG ? appName: YOUR_EASEMOB_APP ? clientId: YOUR_EASEMOB_CLIENT_ID ? clientSecret: YOUR_EASEMOB_CLIENT_SECRET ? accountId: my_ai_assistant ? 选择模型提供方 › 自定义 / OpenAI 兼容 ? Base URL: https://taotoken.net/api ? API Key: YOUR_API_KEY ? 模型 ID: YOUR_MODEL_IDAPI Key 这里填的就是 1.2 节创建的那把，占位符写作YOUR_API_KEY只是示意，实际以你复制到的为准。模型 ID 那格填模型广场里确认过的名字，不要凭印象写一个。填完之后 onboard 一般会做一次连通性检查，如果它直接报鉴权失败，先别怀疑环信，回到 Key 和 Base URL 这两个字段上核对。
2.3 Webhook 还是/webhooks/easemob，不要指望模型通道代劳
5.6 节讲的 Webhook 是环信把用户消息推给 OpenClaw 的入口，路径就是/webhooks/easemob，它跟模型通道是完全独立的两段。有的读者配完 TaoToken 之后发现消息根本不进来，就以为是 Base URL 填错了，其实问题出在环信后台的回调地址没配、或者服务没暴露到环信能访问的地方。判断方法很简单：看pnpm openclaw gateway --verbose的日志里有没有出现消息回调的记录。有回调没回复，才是模型这一段的问题；连回调都没有，先回去查 5.6 节。
3. onboard 跑完回头检查配置，别让/v1混进去
3.1 找到 OpenClaw 落盘的那份配置
onboard 交互走完之后，配置通常会被写到用户目录下的 OpenClaw 配置文件里。不同版本的目录名和文件名可能不完全一样，用 onboard 结束时提示的路径为准。找到之后，重点看两处：一处是消息渠道里的 Easemob 段，确认五个字段都在；另一处是模型段，确认base_url、api_key、model三个值跟你刚才填的一致。
如果配置文件里已经有内容，改之前先备份一份，例如复制成.bak后缀。后面排查问题时这份备份能省很多事，尤其是你打算同时试两个 Base URL 的时候。
3.2/v1是这次最常见的自伤
https://taotoken.net/api是完整的 Base URL，末尾不要补/v1。有些模型的官方地址习惯写成带/v1的形式，于是手一滑就照着补了，结果请求打到不存在的路径上，日志里通常表现为 404 或者「找不到该路径」。
检查方法就一句话：在配置文件或 onboard 的输入里搜一次taotoken.net/api，看它后面是不是干净的结尾。如果看到https://taotoken.net/api/v1这种写法，改回https://taotoken.net/api再重启 gateway。这里也不要给 Base URL 加任何查询参数，它跟官网落地页的地址是两种用途，不要互相粘贴。
4. 起 gateway 看日志：向my_ai_assistant发一句「你好」
4.1pnpm openclaw gateway --verbose该盯哪几行
配置保存之后，把 gateway 起起来，并且保持前台运行：
pnpm openclaw gateway --verbose--verbose的意义在于把消息进来、模型请求出去、回复写回这几段都打出来。启动之后先看它有没有正常拉起 Easemob 渠道，如果这里就报凭据错误，还是环信那五个字段的问题。渠道正常之后，日志会安静下来等消息，这时候再去客户端发消息。
4.2 用 WebIM Demo 发消息，判断有没有命中模型请求
打开环信 WebIM Demo，登录之后向my_ai_assistant发一句「你好」。操作完成后回头看 gateway 的前台输出，理想情况下能看到三段：收到消息回调、发起一次模型请求、收到模型返回并回写会话。
判断标准不是「界面上有没有回你」，而是日志里有没有那次模型请求。因为如果模型请求失败，OpenClaw 也可能在会话里回一句错误提示，看起来像回了消息，实际上链路没通。反过来，如果日志里压根没有模型请求这一段，那说明消息没走到模型环节，跟 Base URL 填得对不对无关。
5. 回消息失败时按链路分段排查
5.1 鉴权失败：先查 Key，再查是不是填错了位置
日志里出现 401 或者「invalid api key」这类字眼，第一件事是回 TaoToken 控制台确认这把 Key 还在、没有被删掉或重置。第二件事是核对它到底填在了哪个字段：模型凭据里的 Key 和环信渠道里的 clientSecret 是两个完全不同的东西，长度和形态也可能很像。如果 Key 确认没问题，再检查有没有多余空格，从控制台复制时最容易带上首尾空白。
5.2 404 或模型不存在：查模型 ID，也查 Base URL 后缀
404 一般有两个来源。一是模型 ID 写错了，用了模型广场列表里没有的名字；二是 Base URL 多了一段/v1。先改回https://taotoken.net/api再试一次，如果还不行，就把模型 ID 换成模型广场里明确列出的名字。这两个检查点加起来不超过两分钟，比反复看日志快得多。
5.3 日志里连回调都没有：这是环信侧的问题
如果 gateway 前台完全没有消息进来的痕迹，那不是模型通道的事。回去检查环信应用后台的回调配置，确认 Webhook 路径写成 5.6 节的/webhooks/easemob，确认你的 OpenClaw 服务地址环信能访问到。这一步和 TaoToken 无关，别在 Base URL 上反复折腾。
5.4 有回调、有模型请求，但没有回复
这种相对少见，通常卡在回复写回会话那一段。先看日志里模型请求有没有返回内容，如果返回是空的，换一个模型 ID 试试；如果返回有内容但没写回，检查 Easemob 渠道的应用凭据是不是配对了应用，别把测试应用和正式应用的 clientId 混着用。
6. 链路通了之后，去对一下这次调用
看到「你好」被正常回复、日志里那次模型请求也走完了，说明 OpenClaw 在环信 IM 渠道里的 AI 回复链路已经配通。接下来建议做两件小事：一是再去 TaoToken 模型对话 里用同一把 Key 发一条消息，确认模型 ID 和 Base URL 没填错；二是回 控制台 API Keys 看一眼这次的调用有没有记上，顺手把 Key 的备注写清楚，方便以后区分「环信助手用」和别的项目。
如果这条链路准备长期跑，去 Coding Plan 看下套餐够不够用；Key 统一在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 创建和管理，模型 ID 依旧以模型广场当时的列表为准。别忘了环信那五个字段和/webhooks/easemob不在 TaoToken 的管辖范围内，它们出问题时，控制台里看不出任何异常，只能回去查环信后台。
