Moving Dify, Cursor, and a Node.js service to a shared provider layer should not be a blind switch. A practical migration path is to send a small shadow request to Vector Engine, compare the response shape, and only then move real workloads to the OpenAI-compatible API gateway.
This tutorial builds a lightweight Node.js harness. It checks Base URL formatting, API Key presence, model name availability, and the common model_not_found response. It treats Vector Engine as the LLM API provider layer and keeps application logic outside the test.
Configuration
Use environment variables so the script can run in local development and CI:
export VECTOR_ENGINE_BASE_URL="https://api.vectorengine.cn/v1"
export VECTOR_ENGINE_API_KEY="replace-with-your-api-key"
export VECTOR_ENGINE_MODEL="gpt-4o-mini"
Registration URL: https://api.vectorengine.cn/register?aff=Igym
For Dify and Cursor, the same Base URL should be configured in the tool settings. The API Key should belong to the right environment, not a personal experiment key.
Shadow request script
Create shadow-vector-engine.mjs:
const baseUrl = process.env.VECTOR_ENGINE_BASE_URL;
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL;
function requireValue(name, value) {
if (!value) throw new Error(`${name} is required`);
}
requireValue("VECTOR_ENGINE_BASE_URL", baseUrl);
requireValue("VECTOR_ENGINE_API_KEY", apiKey);
requireValue("VECTOR_ENGINE_MODEL", model);
if (!baseUrl.endsWith("/v1")) {
throw new Error("Base URL should end with /v1 for OpenAI-compatible clients.");
}
const started = Date.now();
const response = await fetch(`${baseUrl}/chat/completions`, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
model,
messages: [
{
role: "user",
content: "Reply with one sentence confirming the gateway is reachable."
}
],
temperature: 0
})
});
const elapsedMs = Date.now() - started;
const text = await response.text();
if (!response.ok) {
if (text.includes("model_not_found")) {
throw new Error(
`model_not_found: verify the model name in Vector Engine, Dify, Cursor, and Node.js. Raw response: ${text}`
);
}
throw new Error(`Request failed with ${response.status}: ${text}`);
}
console.log(JSON.stringify({ ok: true, elapsedMs, model }, null, 2));
Run it:
node shadow-vector-engine.mjs
Add a Dify check
Before changing a production Dify workflow, create a test provider entry:
| Setting | Value |
|---|---|
| Provider type | OpenAI-compatible |
| Base URL | https://api.vectorengine.cn/v1 |
| API Key | Key from the intended environment |
| model name | Same as VECTOR_ENGINE_MODEL
|
If the Node.js shadow request succeeds but Dify fails, compare the exact model string and whether Dify appended a duplicate path.
Add a Cursor check
In Cursor, use the same Base URL and model name. If Cursor works while Dify fails, the provider layer is probably reachable and the issue sits in the Dify configuration. If both fail with model_not_found, check whether the model is enabled for that API Key.
What to log
The harness should log:
- model name
- response status
- elapsed time
- client name
- environment name
It should not log the API Key. A shared LLM API provider layer is useful only if the operational data is readable without leaking secrets.
Promotion rule
Use a simple rule:
- Node.js shadow request passes.
- Dify test workflow passes with the same model name.
- Cursor test prompt passes with the same Base URL.
-
model_not_foundis either absent or traced to a known disabled model.
After these checks pass, moving more traffic to Vector Engine is a controlled change instead of a blind provider swap.
在切换生产工具前为 Vector Engine 建立影子请求脚本
把 Dify、Cursor 和 Node.js 服务迁移到共享供应商层时,不应该直接盲切。更稳妥的做法是先向向量引擎发送一个小型影子请求,比较响应形态,然后再把真实工作负载迁移到 OpenAI 兼容 API 网关。
这篇教程构建一个轻量 Node.js 脚本,用来检查 Base URL 格式、API Key 是否存在、模型名是否可用,以及常见的 model_not_found 响应。这里把向量引擎作为 LLM API provider layer,应用业务逻辑不放进测试脚本。
配置
使用环境变量,便于本地和 CI 复用:
export VECTOR_ENGINE_BASE_URL="https://api.vectorengine.cn/v1"
export VECTOR_ENGINE_API_KEY="replace-with-your-api-key"
export VECTOR_ENGINE_MODEL="gpt-4o-mini"
注册地址:https://api.vectorengine.cn/register?aff=Igym
对 Dify 和 Cursor,也应该在工具设置中填写同一个 Base URL。API Key 要来自正确环境,而不是个人测试 Key。
影子请求脚本
创建 shadow-vector-engine.mjs:
const baseUrl = process.env.VECTOR_ENGINE_BASE_URL;
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL;
function requireValue(name, value) {
if (!value) throw new Error(`${name} is required`);
}
requireValue("VECTOR_ENGINE_BASE_URL", baseUrl);
requireValue("VECTOR_ENGINE_API_KEY", apiKey);
requireValue("VECTOR_ENGINE_MODEL", model);
if (!baseUrl.endsWith("/v1")) {
throw new Error("OpenAI 兼容客户端的 Base URL 通常应以 /v1 结尾。");
}
const started = Date.now();
const response = await fetch(`${baseUrl}/chat/completions`, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
model,
messages: [
{
role: "user",
content: "Reply with one sentence confirming the gateway is reachable."
}
],
temperature: 0
})
});
const elapsedMs = Date.now() - started;
const text = await response.text();
if (!response.ok) {
if (text.includes("model_not_found")) {
throw new Error(
`model_not_found: 请核对向量引擎、Dify、Cursor 和 Node.js 中的模型名。原始响应: ${text}`
);
}
throw new Error(`请求失败 ${response.status}: ${text}`);
}
console.log(JSON.stringify({ ok: true, elapsedMs, model }, null, 2));
运行:
node shadow-vector-engine.mjs
增加 Dify 检查
在修改生产 Dify 工作流前,先创建测试供应商配置:
| 设置 | 值 |
|---|---|
| Provider type | OpenAI-compatible |
| Base URL | https://api.vectorengine.cn/v1 |
| API Key | 目标环境的 Key |
| model name | 与 VECTOR_ENGINE_MODEL 一致 |
如果 Node.js 影子请求成功但 Dify 失败,重点比较模型字符串是否完全一致,以及 Dify 是否拼出了重复路径。
增加 Cursor 检查
在 Cursor 中使用同一个 Base URL 和模型名。如果 Cursor 正常而 Dify 失败,说明向量引擎中转站大概率可达,问题更可能在 Dify 配置里。如果二者都返回 model_not_found,检查该 API Key 是否启用了对应模型。
应该记录什么
脚本应记录:
- model name
- response status
- elapsed time
- client name
- environment name
不要记录 API Key。共享 API中转站 的价值在于可排查,同时不能泄露密钥。
晋级规则
使用简单规则:
- Node.js 影子请求通过。
- Dify 测试工作流用同一模型名通过。
- Cursor 测试提示词用同一 Base URL 通过。
-
model_not_found不出现,或已经定位为已知未启用模型。
通过这些检查后,再把更多流量迁移到向量引擎API中转站。这样迁移是可控变更,而不是盲目替换供应商。
Top comments (0)