1. Dify 接入 OpenAI-Compatible 插件报 model_not_found 的真实场景Dify 的 OpenAI-API-compatible 插件本质上是给任何“长得像 OpenAI 接口”的服务套一层统一外壳。你可以在模型供应商里手动添加自定义模型填上 Base URL、API Key、模型名然后就能在工作流、Agent、Chatflow 里像调用 GPT 一样调用它。适合谁适合手里有自建推理服务、第三方兼容端点、或者公司内部网关的开发者想把这些模型接进 Dify 做编排。但真正让人卡住的往往不是 Key 写错而是model_not_found。这个报错特别有迷惑性它看起来像“模型不存在”于是很多人第一反应是去换模型名、换 Key、甚至怀疑服务挂了。实际上model_not_found只说明一件事——当前请求体里的model字段值不被当前 Base URL 指向的端点接受。它既不代表 Key 失效也不代表 Base URL 一定正确。我试过在一个自建兼容服务上折腾了半天最后发现是 Dify 界面里的 Model Name 填了“我的代码模型”而服务端只认vendor-coder-2026-07这种精确 ID。界面显示名和服务端真实 ID 是两回事插件在endpoint model name为空时会回退用界面名去请求于是必然 404。所以这篇排查清单的核心思路只有两个变量Base URL 的路径对不对以及模型 ID 是否精确对齐。把这两个变量拆开验证model_not_found基本无处遁形。下面按“先确认目录、再确认请求体”的顺序给出可复制的配置片段和最小验证命令。需要先说明适用环境Dify 官方openai_api_compatible插件 0.0.55 的可自定义聊天模型。不同版本字段名可能略有差异但排查逻辑一致。本文验证的是当前官方插件字段对应的排错方法不是“任意第三方服务都已在 Dify 跑通”。2. TaoToken 前置准备Base URL 与 API Key 的获取在动手排查 Dify 之前先把“目标端点”这一侧的信息固定下来。如果你用的是 TaoToken 作为兼容 OpenAI 接口的服务方需要先拿到两样东西API Base URL和API Key。这两样是后续所有验证的基准必须先确认来源一致不能一个来自测试环境、一个来自生产环境。TaoToken 的 API 地址是https://taotoken.net/api注意这个地址不带任何查询参数。API Key 则在控制台的 API Keys 页面创建。创建时建议单独建一个用于 Dify 的 Key方便后续按用途区分和吊销。控制台入口在https://taotoken.net/consoleAPI Keys 页面在https://taotoken.net/api-keys。拿到 Key 之后先不要急着填进 Dify。正确的顺序是先用命令行确认这个 Base URL Key 能列出模型目录。这一步是整个排查的地基。如果/models都拿不到后面填什么模型名都是白搭。这里有个容易踩的坑很多人把 Base URL 填成https://taotoken.net然后疑惑为什么请求 404。OpenAI 兼容接口的路径通常需要带/v1或者服务方指定的前缀。TaoToken 的 API 根是https://taotoken.net/api具体到模型目录和对话补全路径要按服务方文档拼接。所以第一步永远是用 curl 打一次/models看最终命中的路径和返回结构。另外模型 ID 不要凭产品页展示名猜。展示名是给人看的请求体里的model是给服务端路由用的。两者可以不同但发给服务端的必须是后者。TaoToken 支持的模型 ID 以/models返回的data[].id为准或者参考接入文档里的模型列表。文档入口在https://taotoken.net/doc。如果你打算长期在 Dify 里跑编码类或 Agent 类工作流可以考虑 Coding Plan入口在https://taotoken.net/coding-plan。它更适合高频调用场景但前提仍然是先把 Base URL 和模型 ID 对齐。前置准备做到位后面的排查才有意义。3. 可复制配置Dify 插件字段与 JSON 片段现在进入 Dify 侧。在模型供应商区域选择 OpenAI-API-compatible添加自定义模型。当前官方 schema 中与model_not_found直接相关的字段有四个必须逐个对齐字段作用填写要点Model NameDify 界面中的显示名可自定义仅用于识别API Key目标服务凭据与 Base URL 同环境API Base URL请求根地址路径必须精确注意/v1model name for API endpoint服务端真实模型 ID必须与请求体model一致Completion mode补全模式聊天模型选 chat关键点在于当前官方实现会优先使用endpoint_model_name只有它为空时才回退到界面 Model Name。所以如果你只填了界面名“团队代码模型”而服务端只认vendor-coder-2026-07请求就会带着“团队代码模型”发出去结果就是model_not_found。下面给出一份可复制的配置对照。假设/models返回的精确 ID 是vendor-coder-2026-07{ provider: openai_api_compatible, plugin_version: 0.0.55, model_name: 团队代码模型, api_base_url: https://taotoken.net/api, endpoint_model_name: vendor-coder-2026-07, completion_mode: chat, api_key: YOUR_TAOTOKEN_API_KEY }这份 JSON 是字段对照用的不是直接导入文件。实际在 Dify 界面里逐项填写时注意api_base_url的路径部分要和 curl 验证时命中的路径一致。如果你在 curl 里用的是https://taotoken.net/api/v1/models那 Base URL 就要填到能拼出这个路径的层级不要多一个斜杠也不要少一段。如果你用的是 Claude Code 或类似工具做本地调试配置逻辑是一样的三件套Base URL Key Model ID。比如在settings.json或auth.json里Base URL 指向https://taotoken.net/apiModel ID 填/models返回的精确值。Cline MCP 或 CC Switch 场景下也是同样三件套缺一不可。Model ID 写错表现同样是model_not_found。再强调一次界面 Model Name 可以是中文、可以是“团队代码模型”但endpoint model name必须是服务端认识的精确 ID。不要把展示名直接发给服务端也不要删版本后缀、改大小写、或者把另一环境的模型名粘过来。这些操作都会让model_not_found稳定复现。4. 验证请求用最小 Chat Completions 确认连通性配置填完之后不要直接跑包含知识库、工具调用和多节点的工作流。先用最小请求验证模型层是否闭合。验证分两步先确认模型目录再确认对话补全。第一步列出模型目录curl -sS \ -H Authorization: Bearer YOUR_TAOTOKEN_API_KEY \ https://taotoken.net/api/v1/models成功信号是 HTTP 200返回结构类似{ object: list, data: [ {id: vendor-coder-2026-07, object: model} ] }只记录脱敏后的 HTTP 状态、最终路径和data[].id。如果返回 401先处理 Key 或权限返回 404先检查 Base URL 是否少了或重复了/v1返回 HTML 或登录页说明请求命中的不是 API 资源。不要在路径未确认时继续轮换模型名。第二步用同一组 Base URL、Key 和精确模型 ID 发送最小对话请求curl -sS \ -H Authorization: Bearer YOUR_TAOTOKEN_API_KEY \ -H Content-Type: application/json \ https://taotoken.net/api/v1/chat/completions \ -d { model: vendor-coder-2026-07, messages: [{role: user, content: 只回复 DIFY_OK}], max_tokens: 16, stream: false }至少确认四项HTTP 是 200choices[0].message.content可读取返回的model没有意外切到别的 ID响应不是 HTML、登录页或非 JSON 错误。如果/models是 200、错误模型是 404、正确模型是 200模型映射这一层才算闭合。回到 Dify 保存自定义模型后先用最短提示验证比如“只回复 DIFY_OK”。若最小验证仍失败保留以下脱敏信息插件版本、API Base URL 的路径部分、界面 Model Name、endpoint model name、HTTP 状态与错误 type、服务端 request ID如有。不要记录或截图完整 Key。确认模型层成功后再逐步加入流式、工具调用、图片和工作流节点否则新变量会掩盖原始问题。5. 本篇常见错排查401、404、model_not_found 与协议不兼容排查时最忌讳把三类失败混在一起。它们表现相似但根因完全不同处理方式也不一样。Base URL 路径错误。表现通常是 404、HTML 网关页或固定首页内容。检查最终请求是否落到/v1/models和/v1/chat/completions尤其注意 Dify 中已填/v1后服务端文档是否又要求客户端拼一次。不要用增加斜杠的方式盲试一串地址。正确做法是回到 curl看-v输出里实际请求的 URL 是什么。模型 ID 错误。典型表现是 HTTP 404 或错误体中的model_not_found。此时应对比当前端点的模型目录、endpoint model name和请求日志里的model而不是立刻更换 Key。model_not_found不等于 Key 失效也不等于 Base URL 一定正确。它只说明当前请求中的模型值不被当前端点接受。响应协议不兼容。模型请求可能返回 200但缺少choices、message.content或符合当前模式的字段。此时模型名已经不是首要问题应转向响应结构、Chat/Completion mode 和插件支持范围不要继续用model_not_found的办法处理协议错误。还有几个真实报错值得对照。local proxy failed通常出现在本地代理或网络层和模型名无关先确认请求是否真的到达了目标端点。reading choices报错说明响应结构不符合预期可能是服务端返回了非标准 JSON或者 Completion mode 选错了。OAuth 相关报错则说明认证方式不对OpenAI-Compatible 插件用的是 API Key不是 OAuth 流程。如果你在 Claude Code 或 Cline MCP 里遇到类似问题检查顺序一样Base URL 是否指向https://taotoken.net/apiKey 是否有效Model ID 是否与/models返回的精确 ID 一致。三件套里任何一个不对都会报错。Codex 的auth.json场景下同样要确认 Base URL 和 Model ID 对齐。一张检查表收尾插件版本已记录Base URL 来自同一服务环境/models或官方目录给出精确模型 IDendpoint model name与精确 ID 完全一致错误模型能稳定复现 404/model_not_found正确模型最小请求返回 200 和可读正文完整 Key、账户信息和内部地址未进入日志或截图完整 Dify 与线上服务未实测时正文已明确披露6. 语义一致 CTA把模型层闭合后再扩展工作流结论很简单Dify 里的显示名称和服务端真实模型 ID 可以不同。遇到model_not_found时先用当前 Base URL 查目录再把精确 ID 放进endpoint model name并用同一组值发送最小请求。只有这条链路闭合后才值得继续排查工作流、流式和工具调用。如果你还没拿到 Key先去 API Keys 页面创建一个专用 Keyhttps://taotoken.net/api-keys。接入文档和模型列表在https://taotoken.net/doc里面有当前支持的模型 ID 和路径说明。想先在网页里验证模型是否可用可以用模型对话入口https://taotoken.net/chat。长期跑编码类或 Agent 类任务再看 Coding Planhttps://taotoken.net/coding-plan。排查顺序永远是先确认目录再确认请求体里的模型值。把这两个变量拆开model_not_found就不再是玄学。