DeepAI Paper API 中转站,Dify 教程,OpenAI Compatible API,错误排查 Dify 接入 DeepAI API 中转站：OpenAI-Compatible 404、401 与工具调用 400 排查

Dify 接入 DeepAI API 中转站：OpenAI-Compatible 404、401 与工具调用 400 排查

2026年5月31日2026年5月31日| DeepAI Paper 编辑部DeepAI Paper 编辑部| 0 Comment| 下午6:17
Dify 接入 DeepAI API 中转站：OpenAI-Compatible 404、401 与工具调用 400 排查 post thumbnail image
Categories:

Dify 是很多团队搭建 Agent、RAG 知识库和工作流应用的入口。它支持 OpenAI-compatible 模型供应商，所以也很适合接入 DeepAI API 中转站，把不同模型统一到一个 Base URL、一个 API Key 体系和一套调用日志里。但在实际配置时，最常见的问题往往不是模型能力，而是 Base URL、认证格式和工具调用参数没有对齐。

Dify 接入 DeepAI API 中转站时排查 OpenAI-Compatible 404 401 和工具调用 400 错误
Dify 接入 OpenAI-compatible API 时，先确认 Base URL，再检查 API Key、模型验证和工具调用能力。

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。

配置流程：先跑通最小模型验证

  1. 进入 Dify 的模型供应商设置，选择 OpenAI-compatible 或自定义兼容供应商。
  2. Base URL 填写 https://api.deepai.wang/v1，不要带 /chat/completions。
  3. API Key 填写 DeepAI 后台生成的密钥，不需要手动加 Bearer 前缀。
  4. 模型 ID 填写 DeepAI 当前可用的模型名，先选择一个确认支持聊天的模型。
  5. 保存前先通过 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 接入 DeepAI API 中转站时，先记住一个原则：Base URL 填基础地址，不填完整接口路径。OpenAI-compatible 场景推荐使用 https://api.deepai.wang/v1；404 先看路径和模型 ID，401 先看 Key 和 Bearer 认证，工具调用 400 则要检查上游模型服务是否真的支持 tool calling。把这三类问题拆开排查，Dify 的模型接入、知识库和 Agent 工作流会稳定得多。

Related Post