1. 三件套串联时Key 到底该放在哪一层Dify、new api、open webUI 这三个工具单独用都不难难的是把它们串成一条链open webUI 当聊天前端Dify 当编排和工作流引擎new api 当统一网关最后所有模型请求都从同一个出口出去。我见过太多人卡在同一个地方——每个工具都填了一遍 Key结果请求打到哪一层、用的是哪个 Key、账单算在谁头上全是一笔糊涂账。这篇要解决的就是这个用 TaoToken 的统一 Key 作为唯一上游凭证让 new api 做转发中枢Dify 和 open webUI 都只认 new api 的地址和 Key。这样你只需要维护一份上游 Key三件套之间的调用链可追踪、可复现换模型或换供应商时只改 new api 一处。适合谁看已经在本地或内网跑起了 Dify、new api、open webUI但被多份 Key 和多个 Base URL 搞晕的开发者或者正准备搭一套自建 AI 工作流想一开始就把通道设计对的人。下面按“先讲清楚每层职责再给可复制配置最后端到端验证”的顺序来配置骨架会给出 config.toml 和 settings.json 的关键字段。先说结论性的分层open webUI 是前端它只需要知道 new api 的地址和一把 new api 生成的 KeyDify 是编排层它调用模型时也走 new apinew api 是唯一持有 TaoToken 上游 Key 的地方。这样任何一次请求的路径都是“前端/编排 → new api → TaoToken → 模型”排查问题时只需要看 new api 的日志。2. 前置准备TaoToken 统一 Key 与 new api 通道在动 Dify 和 open webUI 之前先把上游通道打通。TaoToken 在这里扮演的是统一入口的角色你拿到一把 Key后面所有工具都通过 new api 间接使用它而不是各自去填。第一步是拿到统一 Key。访问官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后进入控制台在 API Keys 页面创建一把 Key。这个页面地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keys 创建时建议按用途命名比如newapi-upstream方便以后区分。第二步是确认 API 基址。TaoToken 的 API 入口是 https://taotoken.net/api 注意这个地址不带任何查询参数在 new api 里配置渠道时填的就是它。如果你用的是兼容 OpenAI 协议的方式接入Base URL 通常填到/api这一层具体路径以 new api 渠道类型为准。第三步是在 new api 里新建一个渠道。登录 new api 管理后台进入“渠道”页面新增一个 OpenAI 兼容渠道把上一步的 TaoToken Key 填进密钥字段Base URL 填 https://taotoken.net/api 。保存后建议先点一下渠道的“测试”按钮确认能通。这一步通了说明上游通道没问题后面 Dify 和 open webUI 的报错就基本与上游无关了。这里有个容易忽略的点new api 自己也需要生成一把给下游用的 Key。在“令牌”页面新建一个令牌这就是后面 Dify 和 open webUI 要填的那把 Key。它和 TaoToken 的 Key 是两回事别混。上游 Key 只在 new api 渠道里出现一次下游 Key 可以按工具分别建方便追踪。3. 可复制配置config.toml 与 settings.json 骨架这一节给的是骨架字段名以你实际版本为准重点是理解每个字段指向哪一层。先看 new api 侧。它本身是 Web 管理但如果你用 docker-compose 部署环境变量里要确认数据库和端口。真正需要手写配置的是 Dify 和 open webUI。Dify 的模型供应商配置如果你走环境变量方式核心是让它把 OpenAI 兼容接口指向 new api。在 Dify 的.env或 docker-compose 环境里关键项类似这样# Dify 侧把 OpenAI 兼容供应商指向 new api OPENAI_API_BASEhttps://your-newapi-host/v1 OPENAI_API_KEYsk-你的newapi下游令牌如果你用的是 Dify 的config.toml风格配置文件部分部署方式会用到骨架如下[model_providers.openai_compatible] base_url https://your-newapi-host/v1 api_key sk-你的newapi下游令牌 model gpt-4o-mini timeout 60注意base_url指向的是 new api 的地址不是 TaoToken 的地址。这是整个链路里最容易填错的地方——Dify 不该直接知道 TaoToken它只知道 new api。再看 open webUI 的settings.json骨架。open webUI 的配置可以通过环境变量或持久化目录里的配置文件管理核心是 OpenAI 连接部分{ openai: { api_base_url: https://your-newapi-host/v1, api_key: sk-你的newapi下游令牌, models: [gpt-4o-mini, claude-3-5-sonnet] } }如果你用 docker 启动 open webUI对应的环境变量写法是docker run -d -p 3001:8080 \ -e OPENAI_API_BASE_URLhttps://your-newapi-host/v1 \ -e OPENAI_API_KEYsk-你的newapi下游令牌 \ -v /your/path/open-webui:/app/backend/data \ --name open-webui --restart always \ ghcr.nju.edu.cn/open-webui/open-webui:main这里OPENAI_API_BASE_URL同样指向 new api。open webUI 里那个“管理 OpenAI API 连接”的界面填的也是这个地址和这把下游 Key。填完之后模型列表会从 new api 拉取你能看到 new api 里配置的模型。三层配置对照一下就很清楚层级填什么地址填什么 KeyTaoToken上游https://taotoken.net/apiTaoToken 控制台创建的 Keynew api中枢渠道里填 TaoToken 地址渠道用上游 Key令牌页生成下游 KeyDify / open webUI下游指向 new api 地址用 new api 生成的下游 Key4. 端到端验证一次请求走通三件套配置填完不代表通了必须做一次端到端验证。我建议从 open webUI 发起因为它是链路最前端能一次性暴露所有环节的问题。第一步在 open webUI 里新建对话选一个你在 new api 里配置过的模型发一句简单的话比如“回复 ok”。如果返回正常说明 open webUI → new api → TaoToken → 模型这条链是通的。第二步去 new api 后台看“日志”页面。你应该能看到刚才那次请求的记录包含模型名、消耗的 token、使用的渠道。这一步很关键——它证明请求确实经过了 new api而不是 open webUI 直连了别的地方。如果日志里没有记录说明 open webUI 的 Base URL 填错了可能还指向了默认地址。第三步验证 Dify。在 Dify 里创建一个最简单的对话应用或工作流模型选同一个发一条测试消息。然后回到 new api 日志确认多了一条来自 Dify 的请求记录。两条记录都在说明 Dify 和 open webUI 都正确走了 new api。第四步做一次可复现性检查。把 new api 里那个渠道临时禁用再分别从 open webUI 和 Dify 发请求两边都应该报错。然后重新启用请求恢复。这个动作能确认两个下游工具确实依赖同一个上游通道而不是各自有隐藏的直连配置。如果你想让验证更彻底可以在 new api 的渠道里开启详细日志观察请求头里的来源标识。有些版本支持按令牌区分调用方你可以给 Dify 和 open webUI 分别建不同的下游令牌这样日志里一眼就能看出是谁发的请求追踪起来非常方便。5. 本篇常见错排查报错一open webUI 里模型列表为空。最常见原因是 Base URL 填成了 TaoToken 地址而不是 new api 地址或者 new api 里没有配置任何可用渠道。先确认 new api 渠道测试通过再确认 open webUI 的OPENAI_API_BASE_URL指向 new api 的/v1路径。报错二Dify 报 401 或 invalid api key。检查 Dify 里填的是不是 new api 生成的下游令牌而不是 TaoToken 的 Key。下游令牌在 new api 的“令牌”页面创建格式通常也是sk-开头容易和上游 Key 混淆。报错三请求超时或 502。如果 new api 渠道测试能通但下游调用超时多半是网络路径问题。确认 new api 所在主机能访问 https://taotoken.net/api 以及 Dify、open webUI 能访问 new api 的地址。内网部署时注意端口和防火墙。报错四new api 日志里看不到请求。说明请求根本没到 new api。回到下游工具的配置确认 Base URL 没有多余斜杠、没有指向 localhost 而实际服务在另一台机器。open webUI 在 docker 里跑时localhost指的是容器本身要用宿主机的实际 IP 或容器网络别名。报错五模型名对不上。new api 里配置的模型名要和下游填写的模型名一致。如果 TaoToken 侧用的是某个模型标识new api 渠道里要做映射下游再按映射后的名字调用。三层模型名不一致是很多“能连上但报模型不存在”的根因。6. 把 Key 收敛到一层链路才可控三件套串联的核心思路就一句话让 new api 成为唯一持有上游凭证的地方Dify 和 open webUI 都只认 new api。这样你换模型、换供应商、查账单、排故障都只需要看一个地方。如果你还在逐个工具填 Key 的阶段建议现在就动手把 Dify 和 open webUI 的配置改成指向 new api。改完之后做一次上面说的端到端验证尤其是禁用渠道再恢复那一步能帮你确认链路没有隐藏的直连。后续如果要长期跑编码类或 Agent 类任务可以关注 Coding Plan 相关的接入方式地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 它更适合高频、长会话的场景。接入过程中遇到通道配置问题接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有各工具的 Base URL 和参数说明。需要单独验证某个模型是否可用时直接用模型对话页面 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 发一条消息就能确认不用每次都走完整链路。
