1. 为什么 RemoteBridgeCore 实验会卡在模型通道上1.1 原文实验的真实前提原文第六节用 RemoteBridgeCore 连远程开发服务器和 Raspberry Pi。connect 负责握手、密钥交换和心跳send 负责序列化、加密和传输。这套代码单独看是完整的但实验还缺一层Claude Code 需要真实可用的模型通道否则 bridge.send 之后的语义判断和错误分类都没有模型兜底。TaoToken 正好补这一层打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并创建 API Key再把 Claude Code 的 Base URL 指到 https://taotoken.net/api末尾不要加 /v1。我在这里卡过两次。第一次是模型通道没配好send 返回type: error让我误以为是 Bridge 源码的问题第二次才意识到该先解决模型接入。TaoToken 是统一 API 兼容通道它不替代 Bridge只保证模型请求能被应答并被用量账单记录Bridge 的 connect、心跳和消息传递仍由src/bridge/源码完成。所以你接下来会看到一条很直白的实验路径先配模型通道再跑 bridge.send最后回控制台核对 Token 消耗。1.2 Bridge 与 TaoToken 各管一层Bridge 是 Claude Code 与远程设备之间的桥它维护持久连接、推送消息、管理会话状态。TaoToken 是模型调用层的统一入口它接收 Claude Code 发来的模型请求按你在官网选定的模型 ID 转发再把响应原样送回。两者之间没有重叠。设备侧的 JWT、信任设备公钥、HMAC 消息签名都在src/bridge/下完成模型侧的 API Key 鉴权才走 TaoToken。你可以把 TaoToken 的 Key 写进 Claude Code 的配置文件但不要写进bridge.connect的auth字段那个位置只放设备信任凭证。1.3 本次实验要验证的目标按原文顺序本次实验做三件事。第一去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 API Key。第二把 Claude Code 的模型设置指向 https://taotoken.net/api。第三回到原文 6.1 的bridge.send({ type: exec, command: ls -la })示例看返回的是result还是error。如果返回result说明模型请求已通过 TaoToken 正常消耗 Token同时 Bridge 的远程控制链路也没有被改动如果返回error再按第 5 章的对照表排查。2. 先到 TaoToken 创建 Key再把 Claude Code 指到统一入口2.1 打开官网创建 Key模型 ID 以模型广场为准准备阶段只有两步。打开 TaoToken 注册账号进入控制台的 API Keys 页面创建一个新 Key复制后保存为YOUR_API_KEY。接着去同一网站的模型广场找到当前可用的模型 ID。这里要特别说明模型 ID 不要猜也不要套用别处的旧名字以模型广场当时列表为准。你选中的模型 ID 会用于后面 Claude Code 的ANTHROPIC_MODEL配置。2.2 用 ~/.claude/settings.json 固定模型配置Claude Code 读取~/.claude/settings.json里的env字段作为运行时环境变量。我建议把 Base URL、Token 和模型 ID 都写进这个文件避免每次启动终端都要手动 export。配置如下{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }ANTHROPIC_BASE_URL的值是 https://taotoken.net/api末尾不要加 /v1也不要加 UTM 参数。ANTHROPIC_AUTH_TOKEN填你从 TaoToken 控制台复制的 Key不要保留占位符。ANTHROPIC_MODEL填模型广场上真实存在的模型 ID。保存后重启 Claude Code让它重新加载配置。提示如果你在 shell 里已经导出了ANTHROPIC_BASE_URLsettings.json 里的env会优先。这个行为与 Bridge 里「外部环境变量覆盖配置文件」的顺序相反注意别混。2.3 环境变量方式的对照如果你不想改 settings.json也可以在 shell 里临时导出三行环境变量再启动 claudeexport ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELYOUR_MODEL_ID claude这种方式适合临时切换缺点是多个终端都要设置。长期写代码我更建议用 2.2 的 settings.json让 Claude Code 一启动就带上统一配置。注意别让外部变量和 settings.json 同时存在两套不同的 Base URL否则排查问题时很难判断 Claude Code 到底走了哪个地址。2.4 配置加载流程与 src/bridge/bridgeConfig.ts 的对照原文 2.3 节讲了 Bridge 的配置加载顺序读取bridge.json合并环境变量验证合法性最后初始化 Bridge 实例。Claude Code 的模型通道配置也类似先读 settings.json然后接受环境变量覆盖校验 Base URL 是否能连通最后建立会话。关键差异在职责边界Bridge 的配置加载发生在 CLI 与远程设备之间TaoToken 的配置加载发生在 CLI 与模型服务之间。两者通过 Claude Code 的进程串联起来互不读写对方的配置文件。3. 消息传递机制exec、result、error 到底在传什么3.1 bridgeMessaging.ts 的消息类型原文 3.1 节列出了四种消息类型这里用一张表整理它们的用途并标出本次实验里的判断依据。消息类型含义本次实验里的用途exec执行一条命令bridge.send的入参例如ls -laresult命令执行成功并返回数据远程设备返回结果表示链路正常error命令执行失败或连接异常区分设备侧问题还是模型通道问题event设备主动上报的事件心跳、状态变化等异步通知MessageQueue用 FIFO 顺序处理这些消息避免乱序。远程控制场景里exec和result通常是一问一答event则可能随时插入。你判断 Token 是否被消耗关键是看result是否出现出现result意味着 Claude Code 发出的模型请求已经走完一轮完整应答。3.2 消息队列和传输层原文 3.3 节提到传输层支持 WebSocket、HTTP 长轮询和 stdio。远程设备控制一般选 WebSocket因为它延迟低、支持双向推送。HTTP 长轮询适合防火墙严格的网络stdio 则用于本地父子进程通信。这些传输层代码都在src/bridge/下和模型 API 的 HTTPS 请求没有关系。TaoToken 只处理 Claude Code 到模型服务的那一段 HTTPS 调用不介入设备与 CLI 之间的 WebSocket 通道。所以你在配置 TaoToken 时不需要改动 Bridge 的传输层代码也不需要重新编译src/bridge/replBridgeTransport.ts。3.3 这些消息和「模型调用返回」的分工这里回答原文章节的思考题之一Bridge 偏向「连接」MCP 偏向「扩展」TaoToken 是模型 API 的统一接入点。Claude Code 向 TaoToken 发起一次模型请求拿到文本响应随后 Claude Code 可能把这段文本解释成一次bridge.send去连接远程设备。也就是说exec和result发生在 Bridge 层而「这段语义从哪来」由模型层决定。两者通过 Claude Code 的运行时衔接但不共用连接。实验时不要把MessageQueue的 FIFO 顺序和模型请求的响应顺序混为一谈一个是设备消息的时序一个是模型 API 的问答时序。4. 回到原文 6.1用 RemoteBridgeCore 连开发服务器与 Raspberry Pi4.1 连接远程开发服务器先跑 ls -la配置好 Claude Code 的模型通道后回到原文第六节。连接远程开发服务器的代码可以这样写import { RemoteBridgeCore } from ./src/bridge/remoteBridgeCore const bridge new RemoteBridgeCore() await bridge.connect({ host: dev-server.example.com, port: 8080, protocol: wss, auth: { type: jwt, token: process.env.BRIDGE_TOKEN } }) const result await bridge.send({ type: exec, command: ls -la })BRIDGE_TOKEN是设备侧信任凭证从环境变量process.env.BRIDGE_TOKEN读入避免写死在源码里。这个字段和 TaoToken 的 API Key 是两个东西不要混用。ls -la在远程服务器上执行结果通过result消息返回给 Claude Code。这里的wss表示 WebSocket over TLS如果设备在局域网内也可以改用ws。4.2 对照 6.2 的 Raspberry Pi 控制场景原文 6.2 是控制 Raspberry Pi 的示例。连接到pi.local后发送 GPIO 写指令const piBridge await bridge.connect({ host: pi.local, port: 8080, protocol: ws }) await piBridge.send({ type: exec, command: gpio write 17 1 })这里的gpio write 17 1是给 GPIO 引脚写高电平的指令。实际使用时请先确认你的 Pi 用户有对应引脚的写权限再在本地实验环境里执行。Claude Code 负责生成或解释这段命令TaoToken 负责把模型请求送过去拿到语义分析结果真正执行命令的是远程设备上的 Bridge 对端。不要在没接设备的情况下硬跑这条命令否则你会得到一个command not found之类完全与模型通道无关的 error。4.3 通过 result/error 判断 Token 是否已消耗这次实验的关键验证点是返回类型。当bridge.send({ type: exec, command: ls -la })返回{ type: result, data: [...] }说明远程命令成功同时也是一个间接信号Claude Code 能调用模型来解释这次交互模型请求已经通过 TaoToken 正常消耗 Token。反之如果返回{ type: error, error: ... }先不要急着怀疑 TaoToken多数时候是远程主机不可达、认证失败或命令不存在。判断位置很简单看到result再核对用量账单看到error先翻 Bridge 的错误日志。4.4 安全机制JWT、信任设备只属于 Bridge原文第五节的安全机制在这个实验里依然有效。jwtUtils.ts负责签发和校验 JWTtrustedDevice.ts管理首次确认的公钥消息还会做 HMAC 签名。这些机制和设备到 CLI 的连接有关不参与 Claude Code 到 TaoToken 的模型调用。所以你在配置 TaoToken 时不需要改动src/bridge/下的任何安全代码只需要保证ANTHROPIC_AUTH_TOKEN是 TaoToken 的 Key而不是设备侧的 JWT。简单说设备信任走trustedDevice.ts模型鉴权走 TaoToken两条链路的凭证分开管理。5. 排障401、404 与 type: error 的常见对照5.1 401Key 复制错或没到官网创建如果 Claude Code 启动时直接报 401绝大多数情况是ANTHROPIC_AUTH_TOKEN还是占位符或者复制时多了空格。回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的控制台重新复制一次YOUR_API_KEY替换 settings.json 里的旧值。注意不要用设备侧的BRIDGE_TOKEN去填ANTHROPIC_AUTH_TOKEN两者的生成位置完全不同。替换后重启 Claude Code再发一条测试消息基本能解决。5.2 404Base URL 多加了 /v1或模型 ID 猜了名字404 通常有两个来源。第一个是 Base URL 写成了https://taotoken.net/api/v1但 TaoToken 的接口地址是https://taotoken.net/api末尾不带 /v1。第二个是模型 ID 不存在比如凭记忆填了某个旧 ID。正确做法是打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的模型广场看当前列表里有什么就填什么不要编造版本号。模型广场里的 ID 会随模型上下架变化所以每次换模型时都回到这里再确认一次。5.3 type: error 时先别怪模型通道type: error来自 Bridge 消息协议它标识的是「设备端命令执行失败」或「连接中断」不一定代表 TaoToken 有问题。遇到它先看error字段里的具体文本如果是command not found去查远程环境如果是timeout去查心跳和重连配置如果是 401/404 开头的文本才回到前两小节排查模型通道。如果你需要更细的 Bridge 日志原文第七节提到可以打开BRIDGE_DEBUG开关或者在src/bridge/bridgeDebug.ts里看连接状态和消息历史。把设备侧日志和 TaoToken 用量页分开看排障会快很多。6. 验证用量与下一步6.1 回到控制台核对这一次调用实验跑通后打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 查看用量记录。你会看到刚才那次ls -la的语义解析过程在模型调用侧留下了一笔消耗记录这就是「通过 TaoToken 正常消耗 Token」的最直观证据。用量页面的具体字段以当时页面为准重点是确认有新增记录而不是停留在零请求状态。另外你可以在 TaoToken 的模型对话页面用同一把 Key 发一条带中文长上下文的测试消息验证模型 ID 是否真的选对。这个动作和用量页结合起来能确认两件事模型 ID 是否正确以及 Key 是否还有足够覆盖。对长时间跑 Bridge 实验来说提前确认这两点比临时断线再排查更省事。6.2 后续实验的两种衔接方式第一种衔接是继续读原文的源码你可以接着研究src/bridge/sessionRunner.ts的会话迁移或者按照原文章节的顺序进入 Voice Mode。第二种衔接是把模型通道固定下来。你可以在 TaoToken 模型对话 里用同一把 Key 发一条测试消息确认模型 ID 和 Base URL 没填错长期写代码可以打开 Coding Plan 看套餐是否够用Key 的管理始终在 控制台 API KeysClaude Code 环境变量对照见 TaoToken 接入文档。我建议你把「Bridge 实验」和「模型通道配置」分开记账设备侧的错误写进 Bridge 的日志模型侧的消耗写进 TaoToken 的用量页。这样下次再遇到type: error你能一眼看出问题出在桥的哪一端。
Claude Code 连上 TaoToken 后，能照着 Bridge 桥接系统源码做远程设备控制实验
1. 为什么 RemoteBridgeCore 实验会卡在模型通道上1.1 原文实验的真实前提原文第六节用 RemoteBridgeCore 连远程开发服务器和 Raspberry Pi。connect 负责握手、密钥交换和心跳send 负责序列化、加密和传输。这套代码单独看是完整的但实验还缺一层Claude Code 需要真实可用的模型通道否则 bridge.send 之后的语义判断和错误分类都没有模型兜底。TaoToken 正好补这一层打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并创建 API Key再把 Claude Code 的 Base URL 指到 https://taotoken.net/api末尾不要加 /v1。我在这里卡过两次。第一次是模型通道没配好send 返回type: error让我误以为是 Bridge 源码的问题第二次才意识到该先解决模型接入。TaoToken 是统一 API 兼容通道它不替代 Bridge只保证模型请求能被应答并被用量账单记录Bridge 的 connect、心跳和消息传递仍由src/bridge/源码完成。所以你接下来会看到一条很直白的实验路径先配模型通道再跑 bridge.send最后回控制台核对 Token 消耗。1.2 Bridge 与 TaoToken 各管一层Bridge 是 Claude Code 与远程设备之间的桥它维护持久连接、推送消息、管理会话状态。TaoToken 是模型调用层的统一入口它接收 Claude Code 发来的模型请求按你在官网选定的模型 ID 转发再把响应原样送回。两者之间没有重叠。设备侧的 JWT、信任设备公钥、HMAC 消息签名都在src/bridge/下完成模型侧的 API Key 鉴权才走 TaoToken。你可以把 TaoToken 的 Key 写进 Claude Code 的配置文件但不要写进bridge.connect的auth字段那个位置只放设备信任凭证。1.3 本次实验要验证的目标按原文顺序本次实验做三件事。第一去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 API Key。第二把 Claude Code 的模型设置指向 https://taotoken.net/api。第三回到原文 6.1 的bridge.send({ type: exec, command: ls -la })示例看返回的是result还是error。如果返回result说明模型请求已通过 TaoToken 正常消耗 Token同时 Bridge 的远程控制链路也没有被改动如果返回error再按第 5 章的对照表排查。2. 先到 TaoToken 创建 Key再把 Claude Code 指到统一入口2.1 打开官网创建 Key模型 ID 以模型广场为准准备阶段只有两步。打开 TaoToken 注册账号进入控制台的 API Keys 页面创建一个新 Key复制后保存为YOUR_API_KEY。接着去同一网站的模型广场找到当前可用的模型 ID。这里要特别说明模型 ID 不要猜也不要套用别处的旧名字以模型广场当时列表为准。你选中的模型 ID 会用于后面 Claude Code 的ANTHROPIC_MODEL配置。2.2 用 ~/.claude/settings.json 固定模型配置Claude Code 读取~/.claude/settings.json里的env字段作为运行时环境变量。我建议把 Base URL、Token 和模型 ID 都写进这个文件避免每次启动终端都要手动 export。配置如下{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }ANTHROPIC_BASE_URL的值是 https://taotoken.net/api末尾不要加 /v1也不要加 UTM 参数。ANTHROPIC_AUTH_TOKEN填你从 TaoToken 控制台复制的 Key不要保留占位符。ANTHROPIC_MODEL填模型广场上真实存在的模型 ID。保存后重启 Claude Code让它重新加载配置。提示如果你在 shell 里已经导出了ANTHROPIC_BASE_URLsettings.json 里的env会优先。这个行为与 Bridge 里「外部环境变量覆盖配置文件」的顺序相反注意别混。2.3 环境变量方式的对照如果你不想改 settings.json也可以在 shell 里临时导出三行环境变量再启动 claudeexport ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELYOUR_MODEL_ID claude这种方式适合临时切换缺点是多个终端都要设置。长期写代码我更建议用 2.2 的 settings.json让 Claude Code 一启动就带上统一配置。注意别让外部变量和 settings.json 同时存在两套不同的 Base URL否则排查问题时很难判断 Claude Code 到底走了哪个地址。2.4 配置加载流程与 src/bridge/bridgeConfig.ts 的对照原文 2.3 节讲了 Bridge 的配置加载顺序读取bridge.json合并环境变量验证合法性最后初始化 Bridge 实例。Claude Code 的模型通道配置也类似先读 settings.json然后接受环境变量覆盖校验 Base URL 是否能连通最后建立会话。关键差异在职责边界Bridge 的配置加载发生在 CLI 与远程设备之间TaoToken 的配置加载发生在 CLI 与模型服务之间。两者通过 Claude Code 的进程串联起来互不读写对方的配置文件。3. 消息传递机制exec、result、error 到底在传什么3.1 bridgeMessaging.ts 的消息类型原文 3.1 节列出了四种消息类型这里用一张表整理它们的用途并标出本次实验里的判断依据。消息类型含义本次实验里的用途exec执行一条命令bridge.send的入参例如ls -laresult命令执行成功并返回数据远程设备返回结果表示链路正常error命令执行失败或连接异常区分设备侧问题还是模型通道问题event设备主动上报的事件心跳、状态变化等异步通知MessageQueue用 FIFO 顺序处理这些消息避免乱序。远程控制场景里exec和result通常是一问一答event则可能随时插入。你判断 Token 是否被消耗关键是看result是否出现出现result意味着 Claude Code 发出的模型请求已经走完一轮完整应答。3.2 消息队列和传输层原文 3.3 节提到传输层支持 WebSocket、HTTP 长轮询和 stdio。远程设备控制一般选 WebSocket因为它延迟低、支持双向推送。HTTP 长轮询适合防火墙严格的网络stdio 则用于本地父子进程通信。这些传输层代码都在src/bridge/下和模型 API 的 HTTPS 请求没有关系。TaoToken 只处理 Claude Code 到模型服务的那一段 HTTPS 调用不介入设备与 CLI 之间的 WebSocket 通道。所以你在配置 TaoToken 时不需要改动 Bridge 的传输层代码也不需要重新编译src/bridge/replBridgeTransport.ts。3.3 这些消息和「模型调用返回」的分工这里回答原文章节的思考题之一Bridge 偏向「连接」MCP 偏向「扩展」TaoToken 是模型 API 的统一接入点。Claude Code 向 TaoToken 发起一次模型请求拿到文本响应随后 Claude Code 可能把这段文本解释成一次bridge.send去连接远程设备。也就是说exec和result发生在 Bridge 层而「这段语义从哪来」由模型层决定。两者通过 Claude Code 的运行时衔接但不共用连接。实验时不要把MessageQueue的 FIFO 顺序和模型请求的响应顺序混为一谈一个是设备消息的时序一个是模型 API 的问答时序。4. 回到原文 6.1用 RemoteBridgeCore 连开发服务器与 Raspberry Pi4.1 连接远程开发服务器先跑 ls -la配置好 Claude Code 的模型通道后回到原文第六节。连接远程开发服务器的代码可以这样写import { RemoteBridgeCore } from ./src/bridge/remoteBridgeCore const bridge new RemoteBridgeCore() await bridge.connect({ host: dev-server.example.com, port: 8080, protocol: wss, auth: { type: jwt, token: process.env.BRIDGE_TOKEN } }) const result await bridge.send({ type: exec, command: ls -la })BRIDGE_TOKEN是设备侧信任凭证从环境变量process.env.BRIDGE_TOKEN读入避免写死在源码里。这个字段和 TaoToken 的 API Key 是两个东西不要混用。ls -la在远程服务器上执行结果通过result消息返回给 Claude Code。这里的wss表示 WebSocket over TLS如果设备在局域网内也可以改用ws。4.2 对照 6.2 的 Raspberry Pi 控制场景原文 6.2 是控制 Raspberry Pi 的示例。连接到pi.local后发送 GPIO 写指令const piBridge await bridge.connect({ host: pi.local, port: 8080, protocol: ws }) await piBridge.send({ type: exec, command: gpio write 17 1 })这里的gpio write 17 1是给 GPIO 引脚写高电平的指令。实际使用时请先确认你的 Pi 用户有对应引脚的写权限再在本地实验环境里执行。Claude Code 负责生成或解释这段命令TaoToken 负责把模型请求送过去拿到语义分析结果真正执行命令的是远程设备上的 Bridge 对端。不要在没接设备的情况下硬跑这条命令否则你会得到一个command not found之类完全与模型通道无关的 error。4.3 通过 result/error 判断 Token 是否已消耗这次实验的关键验证点是返回类型。当bridge.send({ type: exec, command: ls -la })返回{ type: result, data: [...] }说明远程命令成功同时也是一个间接信号Claude Code 能调用模型来解释这次交互模型请求已经通过 TaoToken 正常消耗 Token。反之如果返回{ type: error, error: ... }先不要急着怀疑 TaoToken多数时候是远程主机不可达、认证失败或命令不存在。判断位置很简单看到result再核对用量账单看到error先翻 Bridge 的错误日志。4.4 安全机制JWT、信任设备只属于 Bridge原文第五节的安全机制在这个实验里依然有效。jwtUtils.ts负责签发和校验 JWTtrustedDevice.ts管理首次确认的公钥消息还会做 HMAC 签名。这些机制和设备到 CLI 的连接有关不参与 Claude Code 到 TaoToken 的模型调用。所以你在配置 TaoToken 时不需要改动src/bridge/下的任何安全代码只需要保证ANTHROPIC_AUTH_TOKEN是 TaoToken 的 Key而不是设备侧的 JWT。简单说设备信任走trustedDevice.ts模型鉴权走 TaoToken两条链路的凭证分开管理。5. 排障401、404 与 type: error 的常见对照5.1 401Key 复制错或没到官网创建如果 Claude Code 启动时直接报 401绝大多数情况是ANTHROPIC_AUTH_TOKEN还是占位符或者复制时多了空格。回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的控制台重新复制一次YOUR_API_KEY替换 settings.json 里的旧值。注意不要用设备侧的BRIDGE_TOKEN去填ANTHROPIC_AUTH_TOKEN两者的生成位置完全不同。替换后重启 Claude Code再发一条测试消息基本能解决。5.2 404Base URL 多加了 /v1或模型 ID 猜了名字404 通常有两个来源。第一个是 Base URL 写成了https://taotoken.net/api/v1但 TaoToken 的接口地址是https://taotoken.net/api末尾不带 /v1。第二个是模型 ID 不存在比如凭记忆填了某个旧 ID。正确做法是打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的模型广场看当前列表里有什么就填什么不要编造版本号。模型广场里的 ID 会随模型上下架变化所以每次换模型时都回到这里再确认一次。5.3 type: error 时先别怪模型通道type: error来自 Bridge 消息协议它标识的是「设备端命令执行失败」或「连接中断」不一定代表 TaoToken 有问题。遇到它先看error字段里的具体文本如果是command not found去查远程环境如果是timeout去查心跳和重连配置如果是 401/404 开头的文本才回到前两小节排查模型通道。如果你需要更细的 Bridge 日志原文第七节提到可以打开BRIDGE_DEBUG开关或者在src/bridge/bridgeDebug.ts里看连接状态和消息历史。把设备侧日志和 TaoToken 用量页分开看排障会快很多。6. 验证用量与下一步6.1 回到控制台核对这一次调用实验跑通后打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 查看用量记录。你会看到刚才那次ls -la的语义解析过程在模型调用侧留下了一笔消耗记录这就是「通过 TaoToken 正常消耗 Token」的最直观证据。用量页面的具体字段以当时页面为准重点是确认有新增记录而不是停留在零请求状态。另外你可以在 TaoToken 的模型对话页面用同一把 Key 发一条带中文长上下文的测试消息验证模型 ID 是否真的选对。这个动作和用量页结合起来能确认两件事模型 ID 是否正确以及 Key 是否还有足够覆盖。对长时间跑 Bridge 实验来说提前确认这两点比临时断线再排查更省事。6.2 后续实验的两种衔接方式第一种衔接是继续读原文的源码你可以接着研究src/bridge/sessionRunner.ts的会话迁移或者按照原文章节的顺序进入 Voice Mode。第二种衔接是把模型通道固定下来。你可以在 TaoToken 模型对话 里用同一把 Key 发一条测试消息确认模型 ID 和 Base URL 没填错长期写代码可以打开 Coding Plan 看套餐是否够用Key 的管理始终在 控制台 API KeysClaude Code 环境变量对照见 TaoToken 接入文档。我建议你把「Bridge 实验」和「模型通道配置」分开记账设备侧的错误写进 Bridge 的日志模型侧的消耗写进 TaoToken 的用量页。这样下次再遇到type: error你能一眼看出问题出在桥的哪一端。