Dify 是很多团队搭建 Agent、RAG 知识库和工作流应用的入口。它支持 OpenAI-compatible 模型供应商，所以也很适合接入 DeepAI API 中转站，把不同模型统一到一个 Base URL、一个 API Key 体系和一套调用日志里。但在实际配置时，最常见的问题往往不是模型能力，而是 Base URL、认证格式和工具调用参数没有对齐。
GitHub Issue 背景：URL 填到 /chat/completions 导致 404
在 Dify 的 GitHub 仓库中，有一个已关闭的 Issue：用户在 Dify Cloud 1.13.0 添加 OpenAI-API-compatible 模型时，把 URL 填成了以 /chat/completions 结尾的完整接口地址，随后 Dify 返回 Credentials validation failed with status code 404。评论中的排查结论很直接：Dify 在模型验证时会自动追加聊天接口路径，因此用户只应该填写基础地址。
这类问题在 API 中转站接入里非常典型。很多用户习惯从 curl 示例里复制完整接口，例如 https://example.com/v1/chat/completions，但 Dify 的模型供应商配置并不需要完整请求路径。它需要的是 OpenAI-compatible 的 Base URL。
Dify 接入 DeepAI 的推荐 Base URL
在 Dify 的 OpenAI-compatible 模型供应商里，DeepAI API 中转站推荐填写：
https://api.deepai.wang/v1
不要填写：
https://api.deepai.wang/v1/chat/completions
原因很简单：Dify 会根据模型类型、验证动作和调用场景自行拼接后续路径。如果你把 /chat/completions 提前写进 Base URL，最终请求就可能变成重复路径，从而出现 404 或 Not Found。
配置流程：先跑通最小模型验证
- 进入 Dify 的模型供应商设置，选择 OpenAI-compatible 或自定义兼容供应商。
- Base URL 填写
https://api.deepai.wang/v1，不要带/chat/completions。 - API Key 填写 DeepAI 后台生成的密钥，不需要手动加
Bearer前缀。 - 模型 ID 填写 DeepAI 当前可用的模型名，先选择一个确认支持聊天的模型。
- 保存前先通过 Dify 的凭据验证；验证成功后，再把模型用于 Chatflow、Workflow 或知识库。
如果你是团队部署，建议先用一个测试工作区和一个专用 Key 完成验证。等普通聊天可用后，再逐步接入知识库、工具、联网搜索和生产工作流。
404：优先检查 Base URL 和模型路径
Dify 中的 404 不一定代表模型不存在，也可能是路径拼错。排查时先看这几个点：
- Base URL 是否只到
/v1，没有写入/chat/completions。 - 模型 ID 是否和 DeepAI API 中转站后台显示的一致。
- 当前模型类型是否选对：聊天模型、Embedding 模型、Rerank 模型不能混用。
- 自托管 Dify 是否能从容器内部访问 DeepAI API 中转站域名。
最稳的办法，是在服务器或容器里先测试 /models 或最小聊天请求。网络可达、Key 可用、模型存在之后，再回到 Dify UI 保存配置。
401：确认 Dify 发送的是 Bearer Token
同一个 GitHub Issue 里，用户去掉 /chat/completions 后又遇到 401，并出现类似 JWT 格式不正确的提示。这个细节很有价值：Dify 的 OpenAI-compatible 插件通常会把你填写的 API Key 作为标准 Bearer Token 发送，也就是 Authorization: Bearer {api_key}。
如果某个上游要求 JWT，而你填的是普通 API Key，就会认证失败。接入 DeepAI API 中转站时，应使用 DeepAI 后台生成的标准 API Key；不要把登录密码、JWT、临时会话令牌或其他平台的非兼容凭据混进来。
- 不要在 Dify 的 Key 输入框里额外写
Bearer。 - 复制 Key 后检查首尾空格和换行。
- 确认 Key 没有过期、没有被禁用，也有目标模型权限。
- 多人共用时，优先给 Dify 单独生成一个 Key，便于日志和额度管理。
工具调用 400：vLLM 需要开启 tool choice 参数
该 Issue 后续还提到一个和搜索工具相关的 400："auto" tool choice requires --enable-auto-tool-choice and --tool-call-parser。这类错误通常不是 Dify 的基础配置问题，而是上游兼容服务没有开启工具调用能力。尤其是使用 vLLM 部署本地模型时，需要在启动服务时明确打开自动工具选择，并配置适配当前模型的 tool-call parser。
python3 -m vllm.entrypoints.openai.api_server --model "/path/to/model" --enable-auto-tool-choice --tool-call-parser qwen3_coder
不同模型需要的 parser 不一样，例如 Hermes、Qwen、Llama 系列可能各有格式约定。对于 DeepAI API 中转站用户来说，如果你调用的是托管模型，通常不需要自己处理 vLLM 启动参数；但如果 DeepAI 后面接的是自部署兼容服务，就要确认上游本身已经支持 function calling / tool calling。
Dify 知识库和 Embedding 也要单独验证
Dify 的 RAG 知识库链路不只依赖聊天模型，还依赖 Embedding 模型、分段策略、向量库和召回配置。不要用聊天模型的成功来推断知识库一定成功。建议把模型分成三类分别验证：LLM、Embedding、Rerank。DeepAI API 中转站如果提供多类模型入口，也应在 Dify 里按模型类型分别配置。
推荐排查顺序
- 第一步：只验证 OpenAI-compatible 聊天模型，Base URL 到
/v1。 - 第二步：用一个短提示词测试普通 Chatflow。
- 第三步：再配置 Embedding 和知识库，不要混用模型类型。
- 第四步：最后开启工具调用、联网搜索和复杂 Workflow。
- 第五步：把 Dify 错误码和 DeepAI API 中转站后台日志对照，确认请求是否真的到达中转站。
参考资料
- Dify GitHub 仓库
- Dify Issue #33151：Credentials validation 404 与 /chat/completions 配置问题
- DeepAI API 中转站教程导航
- Dify 教程合集
总结
Dify 接入 DeepAI API 中转站时，先记住一个原则：Base URL 填基础地址，不填完整接口路径。OpenAI-compatible 场景推荐使用 https://api.deepai.wang/v1；404 先看路径和模型 ID，401 先看 Key 和 Bearer 认证，工具调用 400 则要检查上游模型服务是否真的支持 tool calling。把这三类问题拆开排查，Dify 的模型接入、知识库和 Agent 工作流会稳定得多。
