Troubleshoot model_not_found in a Multi-Tool Vector Engine Setup

model_not_found is one of the most common errors in OpenAI-compatible integrations, but it is often investigated in the wrong place. Teams may start by changing prompts, rewriting SDK code, or replacing a workflow node. In many cases, the error is simpler: the model name, Base URL, API Key, or account permission does not match the provider route.

This guide uses Vector Engine as an OpenAI-compatible API gateway for Dify, Cursor, and Node.js. The same workflow also treats Vector Engine as an LLM API provider layer, so every tool can be checked against one provider contract.

Registration URL: https://api.vectorengine.cn/register?aff=Igym

Start with a four-field comparison

Create one small table before changing any code:

Tool	Base URL	API Key owner	model name	Result
Dify	https://api.vectorengine.cn/v1	workflow key	approved model ID	pass or error
Cursor	https://api.vectorengine.cn/v1	coding key	approved model ID	pass or error
Node.js	https://api.vectorengine.cn/v1	service key	approved model ID	pass or error

If all three fail with model_not_found, the shared model name or account permission is the likely issue. If only one tool fails, the provider may be healthy and the local tool mapping is the better place to inspect.

Check Base URL before endpoint paths

Most OpenAI-style SDKs expect the Base URL, not the full chat-completions URL:

Base URL: https://api.vectorengine.cn/v1

Avoid mixing this with a complete endpoint path inside the same field. If a tool asks for Base URL and you paste a full request URL, the final request can contain duplicated path segments.

Verify the model name exactly

Model names are identifiers, not display labels. Copy the enabled model ID from the provider console and keep it in configuration:

VECTOR_ENGINE_MODEL=replace-with-enabled-model-id

Do not store the model ID in three different README snippets. Put it in one deployment variable or one provider settings page per tool.

Dify checks

For Dify, isolate the provider test from the workflow:

Step	What to verify
Provider entry	OpenAI-compatible provider is selected
Base URL	https://api.vectorengine.cn/v1
API Key	A Vector Engine key for Dify
Model	The exact enabled model ID
Test prompt	A short prompt before retrieval or tools

If the test prompt fails, do not debug the whole workflow yet. Fix the provider entry until a minimal prompt works.

Cursor checks

Cursor failures can look like editor problems because they happen during coding assistance. Keep the check mechanical:

Provider type: custom OpenAI-compatible endpoint
Base URL: https://api.vectorengine.cn/v1
API Key: VECTOR_ENGINE_CURSOR_KEY
Model: enabled coding model

If Cursor uses a different key from Dify, confirm that the Cursor key has access to the same model. A key can be valid while the model route is still unavailable.

Node.js checks

In Node.js, log only safe configuration shape, not secret values:

console.log({
  provider: "Vector Engine",
  baseURL: process.env.VECTOR_ENGINE_BASE_URL,
  model: process.env.VECTOR_ENGINE_MODEL,
  hasKey: Boolean(process.env.VECTOR_ENGINE_API_KEY),
});

Then call the SDK through one provider module:

import OpenAI from "openai";

export const client = new OpenAI({
  apiKey: process.env.VECTOR_ENGINE_API_KEY,
  baseURL: process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1",
});

This keeps the provider layer in one place and prevents route handlers from drifting.

Error decision table

Symptom	Likely cause	Next action
All tools return model_not_found	Model ID or permission issue	Confirm enabled model list
Only Dify fails	Provider entry or workflow model mapping	Re-test provider entry
Only Cursor fails	Cursor model setting or key permission	Re-enter Base URL and model
Only Node.js fails	Environment variable or SDK setup	Print safe config shape
One environment fails	Different API Key or stale variable	Compare key owner and deploy config

The important habit is to separate provider verification from application logic. With Vector Engine behind Dify, Cursor, and Node.js, the team can keep one OpenAI-compatible API gateway contract and make model_not_found a short configuration check instead of a long incident.

---

排查多工具向量引擎接入中的 model_not_found

model_not_found 是 OpenAI-compatible 集成中常见的错误之一，但很多团队一开始会排错方向偏离。有人会先改 prompt、重写 SDK 代码、替换 workflow node。实际场景里，问题往往更简单：model name、Base URL、API Key 或账号权限与 provider route 不匹配。

本文以向量引擎为 Dify、Cursor 和 Node.js 的 OpenAI-compatible API gateway，也就是向量引擎API中转站。整个流程同时把向量引擎当作 LLM API provider layer，让每个工具都能回到同一套 provider contract 上检查。

注册地址：https://api.vectorengine.cn/register?aff=Igym

先做四字段对照

改代码之前，先建一个小表：

工具	Base URL	API Key 归属	model name	结果
Dify	https://api.vectorengine.cn/v1	workflow key	已批准模型 ID	pass 或 error
Cursor	https://api.vectorengine.cn/v1	coding key	已批准模型 ID	pass 或 error
Node.js	https://api.vectorengine.cn/v1	service key	已批准模型 ID	pass 或 error

如果三个工具都返回 model_not_found，优先怀疑共享模型名或账号权限。如果只有一个工具失败，向量引擎中转站可能是正常的，本地工具映射更值得排查。

先确认 Base URL，而不是 endpoint path

大多数 OpenAI-style SDK 需要的是 Base URL，不是完整 chat-completions URL：

Base URL: https://api.vectorengine.cn/v1

不要在同一个字段里混入完整 endpoint path。如果工具要求 Base URL，却填了完整请求 URL，最终请求可能出现重复路径。

精确核对 model name

模型名是 identifier，不是展示标签。应从 provider console 复制已启用模型 ID，并保存在配置里：

VECTOR_ENGINE_MODEL=replace-with-enabled-model-id

不要把模型 ID 散落在三个 README 片段中。每个工具只保留一个部署变量或一个 provider settings 页面。

Dify 检查

Dify 排查时，要把 provider test 和 workflow 分开：

步骤	检查内容
Provider entry	选择 OpenAI-compatible provider
Base URL	https://api.vectorengine.cn/v1
API Key	专供 Dify 使用的向量引擎 Key
Model	精确的已启用模型 ID
Test prompt	在检索或工具调用前先跑短 prompt

如果短 prompt 都失败，不要先调整个 workflow。应先修复 provider entry，直到最小请求可以通过。

Cursor 检查

Cursor 的错误容易被误认为编辑器问题，因为它发生在编码辅助过程中。检查应保持机械化：

Provider type: custom OpenAI-compatible endpoint
Base URL: https://api.vectorengine.cn/v1
API Key: VECTOR_ENGINE_CURSOR_KEY
Model: enabled coding model

如果 Cursor 使用的 Key 不同于 Dify，要确认 Cursor Key 对同一模型也有权限。Key 有效，不代表模型路由一定可用。

Node.js 检查

在 Node.js 中，只打印安全的配置形态，不打印 secret：

console.log({
  provider: "Vector Engine",
  baseURL: process.env.VECTOR_ENGINE_BASE_URL,
  model: process.env.VECTOR_ENGINE_MODEL,
  hasKey: Boolean(process.env.VECTOR_ENGINE_API_KEY),
});

然后通过一个 provider module 调用 SDK：

import OpenAI from "openai";

export const client = new OpenAI({
  apiKey: process.env.VECTOR_ENGINE_API_KEY,
  baseURL: process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1",
});

这样可以把 API中转站配置集中在一个位置，避免不同 route handler 各自漂移。

错误决策表

现象	可能原因	下一步
所有工具都返回 model_not_found	模型 ID 或权限问题	核对已启用模型列表
只有 Dify 失败	Provider entry 或 workflow 模型映射	重新测试 provider entry
只有 Cursor 失败	Cursor 模型设置或 Key 权限	重新填写 Base URL 和模型
只有 Node.js 失败	环境变量或 SDK 设置	打印安全配置形态
只有某环境失败	API Key 不同或变量过期	对比 Key 归属和部署配置

关键习惯是把 provider 验证和应用逻辑分开。当向量引擎连接 Dify、Cursor 和 Node.js 时，团队可以保留一套 OpenAI-compatible API gateway contract，让 model_not_found 成为短配置检查，而不是长故障。