在 Ubuntu 全新虚拟机里把 OpenClaw 配成常驻 Agent 网关最常见的翻车点不在 systemd而在 openclaw onboard 的模型选择和 openclaw.json 的提供商字段。TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 提供了统一 Key 方案把原先散落在 ~/.openclaw/.env 的 ZAI_API_KEY、MOONSHOT_API_KEY 等替换成 TAOTOKEN_API_KEY再把模型提供方 baseUrl 指向 https://taotoken.net/api。这样 Gateway 在处理 Telegram/Feishu 消息、多轮会话和 skills 编排时只凭一把 Key 路由到目标大模型。本文按 Ubuntu 虚拟机、普通用户 openclaw、systemd user service 的场景写重点改掉第 7 节 onboard 和第 12 节模型提供商配置里逐个平台申请 Key 的做法。一、原问题与场景OpenClaw Gateway 常驻任务为什么怕多套 KeyOpenClaw 的 Gateway 是常驻核心进程不是一次性脚本。它长期运行在 Ubuntu 虚拟机里负责接收 Telegram、Feishu、Slack、Discord 等渠道消息管理设备认证、会话上下文、日志、skills 和 plugins同时调用你配置好的大模型。只要 Gateway 还在跑模型路由就不能断。问题出在传统模型提供商配置上。原文第 7 节 openclaw onboard 和第 12 节模型提供商配置通常要求你分别去 Z.AI 申请 ZAI_API_KEY去 Moonshot 申请 MOONSHOT_API_KEY去 MiniMax 申请 MINIMAX_API_KEY去 Anthropic 申请 ANTHROPIC_API_KEY。然后这些 Key 被分散写进 ~/.openclaw/.env。短期测试没问题但一旦变成常驻 Agent 网关维护成本会迅速上升第一任何一家平台 Key 失效、额度归零、被限流、写错一个字符Gateway 在路由到对应模型时就会失败。第二agents.defaults.model.fallbacks 如果混用了多个平台主模型失败后切 fallback也可能因为另一个平台的 Key 不可用而连续失败。第三systemd user service 启动时读的是用户服务环境不一定和你 SSH 登录后的交互 shell 一致。你本地测试能通不代表 daemon 能读到 ~/.openclaw/.env 里的所有变量。第四skills 和渠道消息会放大问题。Telegram 消息进来后Gateway 要调度模型、工具、会话状态模型路由失败时表面看是机器人不回复实际可能是某个平台 Key 已经过期。本条场景的目标很明确OpenClaw 继续作为 Ubuntu 虚拟机里的常驻 Agent 网关统一编排长会话、渠道消息和 skills但模型出口不再维护多套平台 Key而是用一把 TaoToken Key 统一接入。这样 openclaw onboard 选择模型时不需要逐个平台申请openclaw.json 里也只保留一个 provider 入口。二、TaoToken 前置创建一把 Key先统一模型出口在改 OpenClaw 配置前先拿到 TAOTOKEN_API_KEY。打开 TaoToken 官网登录后进入 API Keys 页面创建 Key。生成后复制出来本文统一写成 YOUR_API_KEY。这个 Key 后面只放在 ~/.openclaw/.env 里不在 openclaw.json 中明文写死也不把带 UTM 的网址写进 baseUrl。需要特别区分两个地址控制台、Key 管理、文档入口可以带 UTM用于来源统计。OpenClaw 的模型 baseUrl 必须使用纯 API 地址https://taotoken.net/api 。不要追加 /v1不要加任何 UTM 参数。TaoToken 在这里的定位是统一模型接入通道不是替代 OpenClaw也不是替代 Gateway。OpenClaw 仍然负责渠道、会话、工具、skills、插件和 systemd 常驻TaoToken 只负责让模型请求通过同一个入口路由到目标大模型。对 OpenClaw 来说它看到的是一个 OpenAI 兼容风格的 provider名字可以叫 taotokenapiKey 引用 ${TAOTOKEN_API_KEY}baseUrl 指向 https://taotoken.net/api。拿到 Key 后先不要急着把所有渠道和 skills 都配完。最稳的顺序是先让 Gateway 能启动再让 models status 显示模型可用最后接 Telegram 或 Feishu。这样排查时只需要判断是 Key、baseUrl、模型 ID、还是 systemd 环境问题。如果你需要对照字段创建 Key可以从 API Keys 入口进入https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentopenclaw_gateway配置字段不确定时再看接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentopenclaw_gateway三、可复制配置openclaw onboard、~/.openclaw/.env 与 openclaw.json这一节按 Ubuntu 全新虚拟机来写。假设你已经创建了普通用户 openclaw并且所有安装、配置、运行都在这个用户下完成。不要用 root 直接跑 OpenClaw否则后面 skill 依赖、systemd user service、.env 权限都容易出问题。先准备基础环境sudo apt update sudo apt upgrade -y sudo apt install -y curl git build-essential ca-certificates openssh-server jq sudo adduser openclaw sudo usermod -aG sudo openclaw su - openclaw安装 OpenClawcurl -fsSL https://openclaw.ai/install.sh | bash source ~/.bashrc openclaw --version执行首次引导openclaw onboard --install-daemon在 onboard 里Ubuntu 虚拟机建议选择 Local 模式绑定回环地址端口用 18789鉴权用 token。模型提供商这一步不再逐个填写 ZAI_API_KEY、MOONSHOT_API_KEY。你可以先跳过复杂模型项后面直接手写 openclaw.json让所有模型都从 taotoken provider 走。接着写 ~/.openclaw/.env。这里只保留 Gateway token 和 TaoToken Keycat ~/.openclaw/.env ENVFILE OPENCLAW_GATEWAY_TOKENchange-this-token TAOTOKEN_API_KEYYOUR_API_KEY ENVFILE chmod 600 ~/.openclaw/.env chmod 600 ~/.openclaw/openclaw.json 2/dev/null || true如果你之前的 .env 里有 ZAI_API_KEY、MOONSHOT_API_KEY、MINIMAX_API_KEY确认 openclaw.json 不再引用它们之后可以移除或注释掉。否则排查时容易误判你以为请求走了 TaoToken实际 agents.defaults.model 还指向 zai/glm-5 或 moonshot/kimi-k2.5。然后是核心文件 ~/.openclaw/openclaw.json。下面这份配置把模型 provider 统一成 taotokenbaseUrl 使用 https://taotoken.net/api不带 /v1也不加 UTM。PRIMARY_MODEL_ID 和 FALLBACK_MODEL_ID 需要替换成你在 TaoToken 控制台或接入文档中看到的实际模型 ID。{ identity: { name: Clawd, theme: helpful assistant }, gateway: { bind: loopback, port: 18789, auth: { mode: token, token: ${OPENCLAW_GATEWAY_TOKEN} } }, agents: { defaults: { workspace: ~/.openclaw/workspace, model: { primary: taotoken/PRIMARY_MODEL_ID, fallbacks: [ taotoken/FALLBACK_MODEL_ID ] } } }, models: { mode: merge, providers: { taotoken: { baseUrl: https://taotoken.net/api, apiKey: ${TAOTOKEN_API_KEY}, api: openai-completions, models: [ { id: PRIMARY_MODEL_ID, name: Primary via TaoToken }, { id: FALLBACK_MODEL_ID, name: Fallback via TaoToken } ] } } }, tools: { profile: full }, skills: { load: { watch: true } } }如果还要接 Telegram可以在 openclaw.json 里增加 channels 段token 同样从 .env 读取{ channels: { telegram: { enabled: true, token: ${TELEGRAM_BOT_TOKEN}, dmPolicy: pairing } } }Feishu 可以用 openclaw onboard 或 openclaw channels add 增加但建议先让 Gateway 和模型路由跑通再加渠道。配置完成后重启 Gatewayopenclaw gateway restart openclaw doctor openclaw models status如果要让 systemd user service 在退出 SSH 后继续常驻还需要启用 linger并确认服务已安装sudo loginctl enable-linger openclaw openclaw gateway install systemctl --user daemon-reload systemctl --user enable --now openclaw-gateway.service openclaw gateway status四、验证请求与成功结果openclaw doctor、gateway status 与 models status配置写完后不要只看 openclaw.json 是否有语法错误要跑完整验证链路。第一步看 Gateway 状态openclaw gateway status openclaw status成功时应该能看到 Gateway 处于运行状态绑定 127.0.0.1:18789鉴权模式为 token。如果 systemd user service 没起来会显示 stopped 或找不到服务。第二步看模型状态openclaw models status这里重点看 agents.defaults.model.primary 是否显示为 taotoken/PRIMARY_MODEL_ID以及对应 provider 是否有可用标记。如果仍然显示 zai/glm-5、moonshot/kimi-k2.5说明 openclaw.json 没改干净或者你改的文件不是当前运行用户读取的那份。第三步跑诊断openclaw doctor openclaw logs --follow如果模型请求已经走 TaoToken日志里会出现 providertaotoken、modelPRIMARY_MODEL_ID 或类似路由信息。若看到 provider auth failed、missing api key、route failed就回到第五节排查。第四步做真实渠道验证。在 Telegram 或 Feishu 里给机器人发一条普通消息比如“你现在使用哪个模型路由”。如果 Gateway 正常机器人会返回模型回复同时 openclaw logs --follow 里能看到一次完整会话记录。多轮会话场景下再连续发两三条消息确认上下文没有中断。skills 编排也类似当 skill 触发模型调用时请求应该继续走 taotoken provider而不是跳回某个已失效的平台 Key。对于 systemd 常驻服务还可以看journalctl --user -u openclaw-gateway.service -f成功结果可以归结为三点openclaw doctor 不报 provider 认证错误openclaw gateway status 显示 runningopenclaw models status 中 taotoken provider 下目标模型可用。只要这三点稳定OpenClaw 在 Ubuntu 虚拟机里作为常驻 Agent 网关的模型出口就统一了。五、本篇常见错排查TAOTOKEN_API_KEY、baseUrl、.env 权限与 systemd 环境第一个常见错是 openclaw.json 没改模型引用。你在 .env 里写了 TAOTOKEN_API_KEY但 agents.defaults.model.primary 还是 zai/glm-5fallbacks 还是 moonshot/kimi-k2.5。Gateway 启动后仍然去找 ZAI_API_KEY 或 MOONSHOT_API_KEY自然路由失败。排查命令openclaw config get agents.defaults.model.primary或者直接检查 ~/.openclaw/openclaw.json 中 models.providers 和 agents.defaults.model 两处。第二个常见错是 baseUrl 写错。OpenClaw 的 taotoken provider 应该写https://taotoken.net/api不要写成 https://taotoken.net/api/v1也不要把官网带 UTM 的网址粘进去。UTM 适合控制台入口和文档入口不适合作为模型 API baseUrl。baseUrl 一旦混入查询参数模型请求路径可能异常。第三个常见错是 .env 变量名不一致。openclaw.json 里写的是 ${TAOTOKEN_API_KEY}但 .env 里写成了 TAOTOKEN_KEY、TAOTOKEN_API、YOUR_API_KEY 或带引号的值。建议保持完全一致grep TAOTOKEN ~/.openclaw/.env第四个常见错是权限和属主。~/.openclaw/.env 必须让运行 OpenClaw 的普通用户可读。推荐chmod 600 ~/.openclaw/.env chown openclaw:openclaw ~/.openclaw/.env如果你用 root 安装后面又切到 openclaw 用户运行daemon 可能读不到 root 家目录下的配置或者读到的是另一份旧文件。第五个常见错是 systemd user service 环境未刷新。修改 .env 或 openclaw.json 后只执行 openclaw gateway restart 有时不够。可以重新安装用户服务并 reloadopenclaw gateway install systemctl --user daemon-reload systemctl --user restart openclaw-gateway.service openclaw gateway status如果退出 SSH 后 Gateway 停掉检查是否忘了sudo loginctl enable-linger openclaw第六个常见错是 fallbacks 混用不同 provider。主模型已经改成 taotoken/PRIMARY_MODEL_ID但 fallbacks 里还有 moonshot/kimi-k2.5。主模型失败时Gateway 会尝试 fallback而 fallback 又依赖 MOONSHOT_API_KEY于是出现连续认证失败。最省事的做法是 fallback 也走 taotokenfallbacks: [ taotoken/FALLBACK_MODEL_ID ]第七个常见错是模型 ID 不存在。openclaw models status 可能显示 provider 存在但具体模型不可用。此时检查 models.providers.taotoken.models 里定义的 id 是否与 agents.defaults.model.primary 中的 id 一致。PRIMARY_MODEL_ID 只是占位符必须换成真实模型 ID。第八个常见错是 Dashboard 打不开。Gateway 绑定 loopback 是推荐做法不是故障。宿主机访问时用 SSH 隧道ssh -N -L 18789:127.0.0.1:18789 openclawVM_IP然后浏览器打开 http://127.0.0.1:18789/ 。如果要求 token用openclaw config get gateway.auth.token第九个常见错是 skills 装了不生效。它和 Key 路由不是同一类问题但经常同时出现。改完 openclaw.json 或 .env 后没有重启 Gateway或者没有开新 sessionskills 可能仍使用旧环境。先 openclaw gateway restart再看 openclaw logs --follow。六、语义一致 CTA让 OpenClaw 常驻 Agent 只认一把 TaoToken KeyOpenClaw 在 Ubuntu 虚拟机里跑 Gateway 常驻任务核心诉求是稳定渠道消息不断、长会话不断、skills 编排不断。传统做法把 ZAI_API_KEY、MOONSHOT_API_KEY 等分散在 ~/.openclaw/.env等于把 Gateway 的模型路由绑定在多个平台上。本文改成单一 Key 方案后openclaw.json 里只保留 taotoken providerbaseUrl 固定为 https://taotoken.net/apiagents.defaults.model 的 primary 和 fallbacks 都走同一个 provider。这样 openclaw doctor、gateway status、models status 验证通过后Telegram/Feishu 消息和多轮会话都只凭 TAOTOKEN_API_KEY 路由到目标大模型。如果你正在做 OpenClaw 接入和排障先去 TaoToken API Keys 创建 Key再对照接入文档改 openclaw.jsonhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentopenclaw_gatewayhttps://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentopenclaw_gateway如果你把 OpenClaw 当作长期编码、长期 Agent 网关来用可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentopenclaw_gateway需要单独验证目标模型是否可用时用模型对话入口https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentopenclaw_gateway