OpenWork 接自定义模型，Custom Provider 的 Base URL 填 TaoToken

OpenWork 接自定义模型Custom Provider 的 Base URL 填 TaoTokenOpenWork 的 Custom Provider 面板只有一个 Base URL 输入框填错一个字符OpenCode 引擎就会在执行时间轴上给你留下一条失败记录。本文开头先把要用的东西交代清楚TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册完成后创建一把 Key回到 OpenWork 新增或编辑 Custom Provider把接口 Base URL 填成 https://taotoken.net/apiKey 填刚刚创建的那把。整篇不讲 OpenWork 的架构有多优雅只解决一件具体的事把散落在 OpenAI、Anthropic、DeepSeek、Qwen 之间的多套凭证收敛成一条通道同时不动你已经跑通的 MCP 集成、技能包和工作区授权。如果你正卡在「Custom Provider 保存了但任务跑不起来」或者正准备照着「50 模型自由切换」那一段一个个去接厂商这篇可以直接照做。一、OpenWork 的 Custom Provider 为什么会变成配置噩梦先把 OpenWork 的分层捋清楚才知道 Key 到底被谁消耗。界面层是 Electron 桌面端负责渲染和交互真正干活的是第 2 层引擎 OpenCode会话管理、工具执行、权限处理、SSE 事件流推送全部发生在这一层再往上是 Orchestrator 守护进程管理多个工作区生命周期最下面是集成层对接 LLM 提供商、MCP 服务器和本地文件系统。也就是说你在设置界面里填的 Base URL 和 Key最终是交给 OpenCode 引擎去发请求的时间轴上每一个模型调用节点背后都是一次真实的 API 请求。问题就出在集成层。「50 模型自由切换」这件事听起来很美落地时却是另一回事想用 OpenAI 得配 OpenAI 的地址和 Key想用 Anthropic 得配 Anthropic 的DeepSeek 一把、Qwen 一把每家的 Base URL 拼法不一样额度、限流、账单各看各的。团队里几个人共用一台机器做工作流Key 换一次就要通知一圈人。而原文里「连接本地 Ollama完全离线」那一段解决的是另一个问题——它是在 Custom/Ollama Provider 里填 http://localhost:11434走本地模型适合数据不出机的场景但它替代不了云端模型的统一接入。更麻烦的是复现。你按原文的方法把工作流通过 MCP 暴露出去让用 Cursor、Claude Code 的同事拉起来跑一遍对方第一句话往往是「模型配置发我一份」。配置一旦分散在多个 Provider 条目里分享成本就变得很高。统一通道的价值在这里Base URL 只有一个Key 只有一把谁复现都填同一个地址。这也是本文选择把它填成 TaoToken 的原因而不是继续给每个厂商建一个 Provider。二、先拿 KeyTaoToken 侧的准备接入之前只有两步准备工作顺序别搞反。第一步去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 完成注册。这一步不需要在 OpenWork 里做任何操作先把账号建好。第二步进入控制台的 API Keys 页面创建一把 Key地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keys 。创建后立刻复制很多平台的 Key 只在创建时完整展示一次。本文后续所有示例里这把 Key 都用占位符 YOUR_API_KEY 表示你替换成自己那把即可不要把它贴进任何公开的仓库或截图。这里有两个地址要分清楚混了就会踩坑注册入口是带查询参数的官网首页给人点开用的不要当成接口地址填进 OpenWork。接口 Base URL 是 https://taotoken.net/api 。它不带 /v1 后缀也不带任何 UTM 参数。OpenWork 的 Custom Provider 会在这个 Base URL 后面自行拼接具体的路径你多写一段拼接结果就会多一段。把这两个地址抄准后面的配置基本不会出错。三、可复制配置OpenWork 新增 Custom Provider 的完整填写项打开 OpenWork 桌面端进入设置里的模型提供商区域找到 Custom Provider 的新增或编辑入口。如果你之前按原文的方法建过一个指向 http://localhost:11434 的 Ollama Provider不要删它本地模型和统一通道可以并存只是要确认默认使用的那一个是你想要的。新增条目时按下面的值填提供商名称自定义一个便于识别的名字例如 taotoken。这个名字只影响你在界面上看到什么不影响请求。Base URLhttps://taotoken.net/apiAPI KeyYOUR_API_KEY替换为你自己创建的那把模型 ID从 TaoToken 控制台的模型列表里复制标识不要手打也不要填界面上的展示名称。保存之后把当前工作区的默认提供商切到这个新建的条目上。OpenWork 的工作区设置和 Allowed Folders 不需要重新配置之前授权过的目录保持不变也不需要重建工作区。如果你更习惯直接改引擎层的配置文件OpenCode 侧对应的结构大致如下桌面端界面里保存后效果是等价的两者选一种维护即可不要一处改一处不改造成互相覆盖{ provider: { taotoken: { name: TaoToken, options: { baseURL: https://taotoken.net/api, apiKey: YOUR_API_KEY }, models: { 在此填入控制台复制的模型标识: {} } } } }需要特别强调的是原文里的另外几步这次完全不用动。MCP 集成保持原样codex mcp add openwork --url https://api.openworklabs.com/mcp/agentclaude mcp add --transport http openwork https://api.openworklabs.com/mcp/agent用 OpenPackage 装技能包的那几条命令也保持原样opkg install openpackage://essentials也就是说这次改动只发生在模型提供商这一层工具链、技能包、MCP 连接、工作区授权都不受影响。很多人接完之后觉得「是不是哪里没配全」其实是因为把不该动的地方也动了。四、验证请求用可视化执行时间轴确认流量真的走了这把 Key配置保存成功不代表请求成功OpenWork 恰好提供了很好的验证手段就是原文提到的可视化执行时间轴。随便发一条轻量任务比如让它列一下当前工作区根目录下的文件然后盯着时间轴看。你需要确认三件事任务规划节点是否正常出现每一次模型调用节点是否在合理时间内返回而不是长时间挂起或者直接标红工具执行节点是否按预期推进。如果时间轴上每个模型调用都拿到了返回说明 OpenCode 引擎确实在用这把 Key 发请求。第二步是到 TaoToken 控制台核对用量。任务跑完后去看额度消耗是否有新增记录这一步能确认请求确实打到了你创建的这把 Key 上而不是引擎回退到了某个旧 Provider。如果时间轴正常但控制台没有消耗记录说明当前工作区用的还是别的提供商回到设置里检查默认提供商有没有切换。如果只想单独确认这把 Key 和某个模型是否可用可以打开 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel-chat 发一条测试消息绕开 OpenWork 的链路单独验证这样排查时能快速区分是 Key 的问题还是引擎配置的问题。验证通过之后把工作流分享给用 Cursor 或 Claude Code 的同事复现时让对方同样把接口 Base URL 指到 https://taotoken.net/api 就行。地址统一了复现说明可以短到一句话不用再逐家厂商交代参数。五、本篇常见错排查Base URL、opencode.json 与工作区权限下面这些是本篇场景里出现频率最高的几类问题按报错现象对照排查。第一类Base URL 写法错误。最典型的是写成 https://taotoken.net/api/v1Custom Provider 会在后面继续拼接路径结果变成一个不存在的地址通常表现为 404。正确写法是 https://taotoken.net/api不带版本后缀。第二类把官网首页地址当成接口地址。有些人顺手就从浏览器地址栏复制了带查询参数的那一长串填进去之后参数会被当作路径的一部分请求自然失败。记住官网是给人看的接口地址只有 https://taotoken.net/api 这一个。第三类Key 无效。复制时带上了首尾空格或换行是最常见的原因表现为 401 或鉴权失败。重新复制一次粘贴后检查首尾。另外要确认用的是刚创建的那把而不是别处复制来的旧 Key。第四类模型标识写错。填了界面上的展示名称而不是实际标识通常会返回模型不存在的错误。处理方式是从控制台的模型列表里整段复制不要手打。第五类配置生效位置不对。桌面上改了 Custom Provider但工作区默认提供商没切过去时间轴上看到的还是原来的模型名。反过来如果你在 opencode.json 里改了配置桌面端界面里又有另一份设置两边不一致也会让人误判。统一在一处维护。第六类误改无关配置。有人为了让统一通道生效顺手把 MCP 那两条命令重配了一遍或者重新授权了 Allowed Folders。这两步都不需要。工作区目录权限和模型提供商是两件独立的事改动前者只会引入新的变量。第七类本地 Ollama 与统一通道混用。如果你同时保留了指向 http://localhost:11434 的 Ollama Provider注意别把本地地址错填进新建的统一通道条目里两个条目的字段是分开的。想跑本地模型就切到 Ollama 那条想走云端统一入口就切到统一通道那条。第八类长任务在时间轴上中途中断。这类问题一般不在模型配置本身先看是不是任务链路过长导致单次请求超时再确认网络链路稳定。可以先在模型对话页面单独跑一次长一点的请求看是否是同一位置失败。六、把统一通道固化下来这次改动本身很小但它的意义在于把 OpenWork 的模型接入从「每加一个厂商就多配一套」变成「所有云端模型共用一个入口」。OpenCode 引擎、MCP 集成、技能包、工作区授权这些你之前已经调通的部分全部保持原样改动只落在 Custom Provider 的那两个字段上。如果你只是在这一次配置中需要确认 Key 和权限直接去 API Keys 页面创建与管理https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keys 接口路径、鉴权方式和兼容协议的细节看接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc 。如果你打算让 OpenWork 常驻跑 Agent 工作流长时间、多任务地消耗模型建议了解一下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan 比按次零散调用更好规划。配置完成后不要急着把工作流铺开先按第四节的验证方法跑一条轻任务确认时间轴上每一次模型调用都正常返回、控制台用量也有对应记录再把工作流分享给同事。统一地址这件事真正的收益就是在别人复现你的工作流时你只需要说一句Base URL 填 https://taotoken.net/api。