DEV Community: Jia

Trace Header Drift Before Dify, Cursor, and Node.js Share Vector Engine

Jia — Tue, 04 Aug 2026 16:33:28 +0000

When several tools share the same LLM route, a failed request is rarely explained by one field alone. The Base URL may be correct in Dify, the API Key may be current in Cursor, and the Node.js service may still fail because one header, model name, or environment variable drifted. This tutorial uses Vector Engine as an OpenAI-compatible API gateway and builds a small header drift probe before the tools are connected to the same route.

The goal is not to log secrets. The goal is to create a small receipt that tells the team which tool sent the request, which Base URL shape it used, which model name it asked for, and whether the API Key was present without printing the key itself. That receipt becomes useful when a model_not_found error appears and every team thinks another tool caused it.

Configuration contract

Use one shared contract for every tool that will call the LLM API provider layer:

Base URL: https://api.vectorengine.cn/v1
API Key: keep in the tool secret store or environment variable
model name: the exact route name enabled for the account
tool label: dify, cursor, or node-service

Dify, Cursor, and Node.js do not expose the same user interface, but they can still share the same contract. Dify keeps the provider Base URL and model in the model provider settings. Cursor keeps the Base URL and API Key in its model configuration. Node.js reads them from environment variables and adds a lightweight tool label.

A small Node.js probe

Create vector-engine-header-probe.mjs:

const baseURL = process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1";
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL || "replace-with-enabled-model";
const toolLabel = process.env.TOOL_LABEL || "node-service";

function redactedKeyState(value) {
  if (!value) return "missing";
  return `present:${value.length}:chars`;
}

function normalizeBaseURL(value) {
  return value.replace(/\/+$/, "");
}

const receipt = {
  toolLabel,
  baseURL: normalizeBaseURL(baseURL),
  apiKeyState: redactedKeyState(apiKey),
  model,
  sdk: "fetch",
  providerLayer: "Vector Engine",
};

console.log("preflight receipt", receipt);

if (!apiKey) {
  throw new Error("API Key is missing before the request is sent");
}

const response = await fetch(`${receipt.baseURL}/chat/completions`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
    "x-tool-label": toolLabel,
  },
  body: JSON.stringify({
    model,
    messages: [
      { role: "system", content: "Return a short diagnostic reply." },
      { role: "user", content: "Confirm that this route is reachable." },
    ],
    temperature: 0,
  }),
});

const body = await response.text();
console.log("status", response.status);
console.log("body sample", body.slice(0, 500));

if (!response.ok && body.includes("model_not_found")) {
  console.error("model_not_found means the route name should be checked before changing the API Key.");
}

Run it with one tool label at a time:

VECTOR_ENGINE_BASE_URL=https://api.vectorengine.cn/v1 \
VECTOR_ENGINE_API_KEY=sk-your-key \
VECTOR_ENGINE_MODEL=your-enabled-model \
TOOL_LABEL=node-service \
node vector-engine-header-probe.mjs

What to compare across tools

Field	Dify	Cursor	Node.js
Base URL	Provider setting	Model config	`VECTOR_ENGINE_BASE_URL`
API Key	Secret field	Local config	`VECTOR_ENGINE_API_KEY`
model name	Provider model	Selected model	`VECTOR_ENGINE_MODEL`
tool label	Workspace note	Project note	`TOOL_LABEL`
error clue	Run log	Chat panel	Console output

If only Node.js fails, inspect the environment variables and the request path. If Dify and Cursor fail with the same model_not_found, check the model route in Vector Engine before rotating the key. If one tool succeeds and another fails with a 401 or 403, compare API Key scope and account ownership.

Dify and Cursor setup notes

For Dify, paste the same Base URL into the OpenAI-compatible provider area and make sure the model name matches the route that the Node.js probe used. A copied display name is not always the same as the API model name.

For Cursor, keep the Base URL and API Key in the model provider configuration. Then run one small prompt that does not depend on project context. The goal is to separate provider reachability from application behavior.

For Node.js, keep the probe in version control but never commit the API Key. Teams often discover drift only after an incident because their local script, Dify workspace, and Cursor project were changed by different people.

Triage table for `model_not_found`

Symptom	Likely area to inspect	Action
All tools return `model_not_found`	Route name or enabled model	Confirm the exact model name in the provider layer
Dify works, Cursor fails	Cursor model field	Remove display-name assumptions
Cursor works, Node.js fails	Environment variable or request body	Print the redacted receipt and compare model text
Node.js works, Dify fails	Dify provider setting	Check the provider Base URL and selected model

This keeps the LLM API provider layer boring. Vector Engine sits behind the tools, but the team still owns the exact configuration surface used by each caller.

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

在 Dify、Cursor 和 Node.js 共用向量引擎前追踪请求头漂移

当多个工具共用同一条 LLM 路由时，请求失败通常不是单一字段造成的。Dify 里的 Base URL 可能正确，Cursor 里的 API Key 可能有效，Node.js 服务仍然可能因为请求头、模型名或环境变量漂移而失败。本文把向量引擎作为 OpenAI-compatible API gateway 和 LLM API provider layer，先做一个小型请求头漂移探针，再让多个工具共用同一路由。

目标不是记录密钥。目标是生成一份小收据，说明请求来自哪个工具、使用了什么 Base URL 形态、请求了哪个 model name，以及 API Key 是否存在但不打印密钥本身。当 model_not_found 出现时，这份收据能避免每个团队都认为问题来自别人。

配置契约

所有会调用向量引擎API中转站的工具，可以先对齐同一个契约：

Base URL: https://api.vectorengine.cn/v1
API Key: 放在工具密钥区或环境变量中
model name: 账号中已启用的精确路由名
tool label: dify、cursor 或 node-service

Dify、Cursor 和 Node.js 的界面不同，但配置契约可以一致。Dify 在模型供应商设置中保存 Base URL 和模型。Cursor 在模型配置中保存 Base URL 和 API Key。Node.js 从环境变量读取这些值，并附带一个轻量的工具标签。

一个小型 Node.js 探针

创建 vector-engine-header-probe.mjs：

const baseURL = process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1";
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL || "replace-with-enabled-model";
const toolLabel = process.env.TOOL_LABEL || "node-service";

function redactedKeyState(value) {
  if (!value) return "missing";
  return `present:${value.length}:chars`;
}

function normalizeBaseURL(value) {
  return value.replace(/\/+$/, "");
}

const receipt = {
  toolLabel,
  baseURL: normalizeBaseURL(baseURL),
  apiKeyState: redactedKeyState(apiKey),
  model,
  sdk: "fetch",
  providerLayer: "Vector Engine",
};

console.log("preflight receipt", receipt);

if (!apiKey) {
  throw new Error("API Key is missing before the request is sent");
}

const response = await fetch(`${receipt.baseURL}/chat/completions`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
    "x-tool-label": toolLabel,
  },
  body: JSON.stringify({
    model,
    messages: [
      { role: "system", content: "Return a short diagnostic reply." },
      { role: "user", content: "Confirm that this route is reachable." },
    ],
    temperature: 0,
  }),
});

const body = await response.text();
console.log("status", response.status);
console.log("body sample", body.slice(0, 500));

if (!response.ok && body.includes("model_not_found")) {
  console.error("model_not_found means the route name should be checked before changing the API Key.");
}

按工具标签分别运行：

VECTOR_ENGINE_BASE_URL=https://api.vectorengine.cn/v1 \
VECTOR_ENGINE_API_KEY=sk-your-key \
VECTOR_ENGINE_MODEL=your-enabled-model \
TOOL_LABEL=node-service \
node vector-engine-header-probe.mjs

跨工具比较哪些字段

字段	Dify	Cursor	Node.js
Base URL	供应商设置	模型配置	`VECTOR_ENGINE_BASE_URL`
API Key	密钥字段	本地配置	`VECTOR_ENGINE_API_KEY`
model name	供应商模型	已选模型	`VECTOR_ENGINE_MODEL`
tool label	工作区备注	项目备注	`TOOL_LABEL`
错误线索	运行日志	聊天面板	控制台输出

如果只有 Node.js 失败，先看环境变量和请求路径。如果 Dify 和 Cursor 都返回 model_not_found，先检查向量引擎中转站里的模型路由，再考虑是否要轮换密钥。如果某个工具成功，另一个工具返回 401 或 403，就比较 API Key 的权限范围和账号归属。

Dify 和 Cursor 配置提示

在 Dify 中，把同一个 Base URL 填到 OpenAI-compatible provider 区域，并确认模型名和 Node.js 探针使用的路由名一致。展示名不一定等于 API model name。

在 Cursor 中，把 Base URL 和 API Key 放到模型供应商配置里。然后运行一个不依赖项目上下文的小提示词，把供应商可达性和应用行为分开。

在 Node.js 中，把探针放进版本库，但不要提交 API Key。很多团队只有在事故后才发现本地脚本、Dify 工作区和 Cursor 项目分别被不同的人改过。

`model_not_found` 排查表

现象	优先检查区域	处理动作
所有工具都返回 `model_not_found`	路由名或启用模型	在 API中转站里确认精确模型名
Dify 正常，Cursor 失败	Cursor 模型字段	不要把展示名当成 API 模型名
Cursor 正常，Node.js 失败	环境变量或请求体	打印脱敏收据并比较模型文本
Node.js 正常，Dify 失败	Dify 供应商设置	检查 provider Base URL 和所选模型

这样可以让 LLM API provider layer 保持稳定。向量引擎位于工具后面，但每个调用方使用的具体配置面仍然需要团队自己负责。

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

Trace Header Drift Before Dify, Cursor, and Node.js Share Vector Engine

Jia — Mon, 03 Aug 2026 16:10:37 +0000

Configuration contract

Use one shared contract for every tool that will call the LLM API provider layer:

Base URL: https://api.vectorengine.cn/v1
API Key: keep in the tool secret store or environment variable
model name: the exact route name enabled for the account
tool label: dify, cursor, or node-service

A small Node.js probe

Create vector-engine-header-probe.mjs:

const baseURL = process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1";
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL || "replace-with-enabled-model";
const toolLabel = process.env.TOOL_LABEL || "node-service";

function redactedKeyState(value) {
  if (!value) return "missing";
  return `present:${value.length}:chars`;
}

function normalizeBaseURL(value) {
  return value.replace(/\/+$/, "");
}

const receipt = {
  toolLabel,
  baseURL: normalizeBaseURL(baseURL),
  apiKeyState: redactedKeyState(apiKey),
  model,
  sdk: "fetch",
  providerLayer: "Vector Engine",
};

console.log("preflight receipt", receipt);

if (!apiKey) {
  throw new Error("API Key is missing before the request is sent");
}

const response = await fetch(`${receipt.baseURL}/chat/completions`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
    "x-tool-label": toolLabel,
  },
  body: JSON.stringify({
    model,
    messages: [
      { role: "system", content: "Return a short diagnostic reply." },
      { role: "user", content: "Confirm that this route is reachable." },
    ],
    temperature: 0,
  }),
});

const body = await response.text();
console.log("status", response.status);
console.log("body sample", body.slice(0, 500));

if (!response.ok && body.includes("model_not_found")) {
  console.error("model_not_found means the route name should be checked before changing the API Key.");
}

Run it with one tool label at a time:

VECTOR_ENGINE_BASE_URL=https://api.vectorengine.cn/v1 \
VECTOR_ENGINE_API_KEY=sk-your-key \
VECTOR_ENGINE_MODEL=your-enabled-model \
TOOL_LABEL=node-service \
node vector-engine-header-probe.mjs

What to compare across tools

Field	Dify	Cursor	Node.js
Base URL	Provider setting	Model config	`VECTOR_ENGINE_BASE_URL`
API Key	Secret field	Local config	`VECTOR_ENGINE_API_KEY`
model name	Provider model	Selected model	`VECTOR_ENGINE_MODEL`
tool label	Workspace note	Project note	`TOOL_LABEL`
error clue	Run log	Chat panel	Console output

Dify and Cursor setup notes

Triage table for `model_not_found`

Symptom	Likely area to inspect	Action
All tools return `model_not_found`	Route name or enabled model	Confirm the exact model name in the provider layer
Dify works, Cursor fails	Cursor model field	Remove display-name assumptions
Cursor works, Node.js fails	Environment variable or request body	Print the redacted receipt and compare model text
Node.js works, Dify fails	Dify provider setting	Check the provider Base URL and selected model

This keeps the LLM API provider layer boring. Vector Engine sits behind the tools, but the team still owns the exact configuration surface used by each caller.

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

在 Dify、Cursor 和 Node.js 共用向量引擎前追踪请求头漂移

配置契约

所有会调用向量引擎API中转站的工具，可以先对齐同一个契约：

Base URL: https://api.vectorengine.cn/v1
API Key: 放在工具密钥区或环境变量中
model name: 账号中已启用的精确路由名
tool label: dify、cursor 或 node-service

一个小型 Node.js 探针

创建 vector-engine-header-probe.mjs：

const baseURL = process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1";
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL || "replace-with-enabled-model";
const toolLabel = process.env.TOOL_LABEL || "node-service";

function redactedKeyState(value) {
  if (!value) return "missing";
  return `present:${value.length}:chars`;
}

function normalizeBaseURL(value) {
  return value.replace(/\/+$/, "");
}

const receipt = {
  toolLabel,
  baseURL: normalizeBaseURL(baseURL),
  apiKeyState: redactedKeyState(apiKey),
  model,
  sdk: "fetch",
  providerLayer: "Vector Engine",
};

console.log("preflight receipt", receipt);

if (!apiKey) {
  throw new Error("API Key is missing before the request is sent");
}

const response = await fetch(`${receipt.baseURL}/chat/completions`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
    "x-tool-label": toolLabel,
  },
  body: JSON.stringify({
    model,
    messages: [
      { role: "system", content: "Return a short diagnostic reply." },
      { role: "user", content: "Confirm that this route is reachable." },
    ],
    temperature: 0,
  }),
});

const body = await response.text();
console.log("status", response.status);
console.log("body sample", body.slice(0, 500));

if (!response.ok && body.includes("model_not_found")) {
  console.error("model_not_found means the route name should be checked before changing the API Key.");
}

按工具标签分别运行：

VECTOR_ENGINE_BASE_URL=https://api.vectorengine.cn/v1 \
VECTOR_ENGINE_API_KEY=sk-your-key \
VECTOR_ENGINE_MODEL=your-enabled-model \
TOOL_LABEL=node-service \
node vector-engine-header-probe.mjs

跨工具比较哪些字段

字段	Dify	Cursor	Node.js
Base URL	供应商设置	模型配置	`VECTOR_ENGINE_BASE_URL`
API Key	密钥字段	本地配置	`VECTOR_ENGINE_API_KEY`
model name	供应商模型	已选模型	`VECTOR_ENGINE_MODEL`
tool label	工作区备注	项目备注	`TOOL_LABEL`
错误线索	运行日志	聊天面板	控制台输出

Dify 和 Cursor 配置提示

在 Dify 中，把同一个 Base URL 填到 OpenAI-compatible provider 区域，并确认模型名和 Node.js 探针使用的路由名一致。展示名不一定等于 API model name。

在 Cursor 中，把 Base URL 和 API Key 放到模型供应商配置里。然后运行一个不依赖项目上下文的小提示词，把供应商可达性和应用行为分开。

在 Node.js 中，把探针放进版本库，但不要提交 API Key。很多团队只有在事故后才发现本地脚本、Dify 工作区和 Cursor 项目分别被不同的人改过。

`model_not_found` 排查表

现象	优先检查区域	处理动作
所有工具都返回 `model_not_found`	路由名或启用模型	在 API中转站里确认精确模型名
Dify 正常，Cursor 失败	Cursor 模型字段	不要把展示名当成 API 模型名
Cursor 正常，Node.js 失败	环境变量或请求体	打印脱敏收据并比较模型文本
Node.js 正常，Dify 失败	Dify 供应商设置	检查 provider Base URL 和所选模型

这样可以让 LLM API provider layer 保持稳定。向量引擎位于工具后面，但每个调用方使用的具体配置面仍然需要团队自己负责。

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

Build a Tool Profile Resolver Before Dify, Cursor, and Node.js Share Vector Engine

Jia — Tue, 28 Jul 2026 16:29:56 +0000

When Vector Engine becomes the shared OpenAI-compatible API gateway for several internal tools, the hard part is rarely the HTTP request itself. The hard part is keeping each tool honest about the same Base URL, API Key source, model name, timeout, and error expectations. Dify may store values in a provider form, Cursor may keep them in a local settings file, and a Node.js service may read them from environment variables.

This tutorial builds a small tool profile resolver in Node.js. It does not send prompts. It prints a sanitized profile for every client before traffic moves through the LLM API provider layer. The goal is to catch configuration drift before a developer sees model_not_found in production.

The profile shape

Use one profile per tool. Keep secrets out of the output.

const profiles = {
  dify: {
    tool: "Dify",
    baseURL: process.env.DIFY_BASE_URL,
    apiKeyName: "DIFY_VECTOR_ENGINE_KEY",
    model: process.env.DIFY_MODEL,
    timeoutMs: 45000
  },
  cursor: {
    tool: "Cursor",
    baseURL: process.env.CURSOR_BASE_URL,
    apiKeyName: "CURSOR_VECTOR_ENGINE_KEY",
    model: process.env.CURSOR_MODEL,
    timeoutMs: 30000
  },
  service: {
    tool: "Node.js service",
    baseURL: process.env.VECTOR_ENGINE_BASE_URL,
    apiKeyName: "VECTOR_ENGINE_API_KEY",
    model: process.env.VECTOR_ENGINE_MODEL,
    timeoutMs: 60000
  }
};

For OpenAI-compatible clients, the Base URL should be the provider base:

VECTOR_ENGINE_BASE_URL=https://api.vectorengine.cn/v1

Do not paste a full chat-completions endpoint into a field that expects a Base URL. That mistake often produces confusing 404s or a model_not_found message because the client appends another path segment.

The resolver

The resolver checks missing fields, unsafe paths, and model name consistency.

function normalizeBaseURL(value) {
  if (!value) return "";
  return value.replace(/\/+$/, "");
}

function resolveProfile(name, profile) {
  const baseURL = normalizeBaseURL(profile.baseURL);
  const errors = [];

  if (!baseURL) errors.push("missing Base URL");
  if (!profile.model) errors.push("missing model name");
  if (baseURL.endsWith("/chat/completions")) {
    errors.push("Base URL looks like a full endpoint");
  }

  return {
    name,
    tool: profile.tool,
    baseURL,
    apiKeyName: profile.apiKeyName,
    apiKeyPresent: Boolean(process.env[profile.apiKeyName]),
    model: profile.model || "",
    timeoutMs: profile.timeoutMs,
    errors
  };
}

const resolved = Object.entries(profiles).map(([name, profile]) =>
  resolveProfile(name, profile)
);

console.table(resolved.map(item => ({
  tool: item.tool,
  baseURL: item.baseURL,
  apiKeyName: item.apiKeyName,
  apiKeyPresent: item.apiKeyPresent,
  model: item.model,
  errors: item.errors.join("; ")
})));

if (resolved.some(item => item.errors.length > 0 || !item.apiKeyPresent)) {
  process.exitCode = 1;
}

This output is safe to paste into an internal ticket because it shows the API Key variable name, not the key value.

What to compare in Dify and Cursor

Use the resolver output as a checklist:

Field	Dify	Cursor	Node.js service
Base URL	Provider form or custom model settings	Custom OpenAI-compatible endpoint	`VECTOR_ENGINE_BASE_URL`
API Key	Secret field in the provider	Local settings or environment bridge	Server-side environment variable
Model name	Model field in workflow config	Model override in settings	`VECTOR_ENGINE_MODEL`
Error owner	Workflow owner	Developer using the IDE	Service owner

When model_not_found appears, do not rotate the key immediately. Check whether Dify, Cursor, and the Node.js service are using the same model name and the same Vector Engine route. A mismatched model field is easier to fix than a blind provider change.

Add one smoke request

After the resolver passes, run a short smoke request from the Node.js service profile.

async function smoke() {
  const baseURL = normalizeBaseURL(process.env.VECTOR_ENGINE_BASE_URL);
  const response = await fetch(`${baseURL}/chat/completions`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.VECTOR_ENGINE_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: process.env.VECTOR_ENGINE_MODEL,
      messages: [{ role: "user", content: "Return the word ok." }],
      temperature: 0
    })
  });

  const text = await response.text();
  if (!response.ok) {
    throw new Error(`Vector Engine smoke failed: ${response.status} ${text}`);
  }
  console.log("Vector Engine smoke passed");
}

Keep this smoke request small. The resolver checks configuration, and the smoke request checks the path through the OpenAI-compatible API gateway.

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

Summary

A shared LLM API provider layer is easier to operate when tool settings are explicit. Before Dify, Cursor, and a Node.js service share Vector Engine, print the resolved Base URL, API Key source, model name, and timeout. That small step turns model_not_found from a vague user complaint into a concrete configuration diff.

在 Dify、Cursor 和 Node.js 共用向量引擎前，先写一个工具配置解析器

当向量引擎成为多个内部工具共用的 OpenAI 兼容入口时，真正麻烦的通常不是 HTTP 请求本身，而是每个工具是否都诚实地使用同一个 Base URL、API Key 来源、模型名称、超时设置和错误预期。Dify 可能把配置放在模型供应商表单里，Cursor 可能放在本地设置里，Node.js 服务则通常从环境变量读取。

这篇教程用 Node.js 写一个工具配置解析器。它不会发送业务提示词，只会在流量进入 LLM API provider layer 之前，打印每个客户端的脱敏配置。目标是在开发者遇到 model_not_found 之前发现配置漂移。

配置结构

每个工具维护一份 profile，不输出密钥明文。

const profiles = {
  dify: {
    tool: "Dify",
    baseURL: process.env.DIFY_BASE_URL,
    apiKeyName: "DIFY_VECTOR_ENGINE_KEY",
    model: process.env.DIFY_MODEL,
    timeoutMs: 45000
  },
  cursor: {
    tool: "Cursor",
    baseURL: process.env.CURSOR_BASE_URL,
    apiKeyName: "CURSOR_VECTOR_ENGINE_KEY",
    model: process.env.CURSOR_MODEL,
    timeoutMs: 30000
  },
  service: {
    tool: "Node.js service",
    baseURL: process.env.VECTOR_ENGINE_BASE_URL,
    apiKeyName: "VECTOR_ENGINE_API_KEY",
    model: process.env.VECTOR_ENGINE_MODEL,
    timeoutMs: 60000
  }
};

对于 OpenAI 兼容客户端，Base URL 应该是服务基础地址，例如：

VECTOR_ENGINE_BASE_URL=https://api.vectorengine.cn/v1

不要把完整的 chat-completions 接口填进只需要 Base URL 的字段。很多 404 或 model_not_found，其实是工具自动追加路径后变成了重复路径。

解析器代码

解析器检查缺失字段、错误路径和模型名称一致性。

function normalizeBaseURL(value) {
  if (!value) return "";
  return value.replace(/\/+$/, "");
}

function resolveProfile(name, profile) {
  const baseURL = normalizeBaseURL(profile.baseURL);
  const errors = [];

  if (!baseURL) errors.push("missing Base URL");
  if (!profile.model) errors.push("missing model name");
  if (baseURL.endsWith("/chat/completions")) {
    errors.push("Base URL looks like a full endpoint");
  }

  return {
    name,
    tool: profile.tool,
    baseURL,
    apiKeyName: profile.apiKeyName,
    apiKeyPresent: Boolean(process.env[profile.apiKeyName]),
    model: profile.model || "",
    timeoutMs: profile.timeoutMs,
    errors
  };
}

输出结果可以贴进内部工单，因为它只展示 API Key 变量名，不展示实际 Key。

Dify 和 Cursor 要对照什么

可以把解析器输出当作检查表：

字段	Dify	Cursor	Node.js 服务
Base URL	供应商或自定义模型设置	自定义 OpenAI 兼容入口	`VECTOR_ENGINE_BASE_URL`
API Key	供应商密钥字段	本地设置或环境变量桥接	服务端环境变量
模型名称	工作流模型字段	设置里的模型覆盖项	`VECTOR_ENGINE_MODEL`
错误负责人	工作流负责人	使用 IDE 的开发者	服务负责人

如果出现 model_not_found，不要立刻轮换 Key。先确认 Dify、Cursor 和 Node.js 服务是否使用同一个模型名称，以及同一条向量引擎路由。模型字段错配通常比盲目更换供应商更容易处理。

再加一个小烟测

配置解析通过后，用 Node.js 服务 profile 发一个很短的 smoke request。

async function smoke() {
  const baseURL = normalizeBaseURL(process.env.VECTOR_ENGINE_BASE_URL);
  const response = await fetch(`${baseURL}/chat/completions`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.VECTOR_ENGINE_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: process.env.VECTOR_ENGINE_MODEL,
      messages: [{ role: "user", content: "Return the word ok." }],
      temperature: 0
    })
  });

  const text = await response.text();
  if (!response.ok) {
    throw new Error(`Vector Engine smoke failed: ${response.status} ${text}`);
  }
  console.log("Vector Engine smoke passed");
}

向量引擎API中转站适合统一管理多工具入口，但前提是配置能够被读回。向量引擎中转站不是让所有工具变成一个黑盒，而是让团队能把 API中转站的 Base URL、Key 来源、模型名和错误责任写清楚。

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

小结

共享的 LLM API provider layer 只有在配置显式时才容易运维。让 Dify、Cursor 和 Node.js 服务共用向量引擎之前，先打印解析后的 Base URL、API Key 来源、模型名称和超时设置。这样 model_not_found 就不再是模糊投诉，而是可以定位到具体配置差异的工程信号。

Add an Egress Host Audit Before Dify, Cursor, and Node.js Share Vector Engine

Jia — Mon, 27 Jul 2026 16:50:37 +0000

When a team connects Dify, Cursor, and a Node.js service to Vector Engine, the visible setup is usually small: one OpenAI-compatible API gateway, one Base URL, one API Key policy, and one model name per route. The hidden problem is that older direct-provider URLs can remain in environment files, workflow variables, CI secrets, or developer machines.

This tutorial builds a small egress host audit. It does not call the model. It checks configuration before traffic leaves the application boundary, so a team can confirm that every tool is using Vector Engine as the LLM API provider layer instead of mixing direct providers with the shared gateway.

What the audit should catch

The audit is useful before moving a workflow into production:

Check	Why it matters	Typical clue
Base URL host	Confirms the client points to the approved gateway	A legacy provider host appears in env
API Key variable name	Separates missing credentials from routing mistakes	Empty key or wrong secret name
Model name	Keeps Dify, Cursor, and Node.js aligned	`model_not_found` from one tool only
Tool owner	Makes review and rollback practical	Unknown owner in a shared config
Direct-provider URL	Prevents accidental bypass of the provider layer	Cost and errors appear outside Vector Engine

The point is not to block experimentation. The point is to make the production path explicit.

Example config file

Keep one local file for the audit. Use placeholders in the repository and real values in your deployment system.

{
  "approvedHost": "api.vectorengine.cn",
  "tools": [
    {
      "name": "Dify",
      "baseUrl": "https://api.vectorengine.cn/v1",
      "apiKeyEnv": "DIFY_VECTOR_ENGINE_API_KEY",
      "model": "configured-model-name",
      "owner": "workflow-platform"
    },
    {
      "name": "Cursor",
      "baseUrl": "https://api.vectorengine.cn/v1",
      "apiKeyEnv": "CURSOR_VECTOR_ENGINE_API_KEY",
      "model": "configured-model-name",
      "owner": "developer-experience"
    },
    {
      "name": "Node.js",
      "baseUrl": "https://api.vectorengine.cn/v1",
      "apiKeyEnv": "NODE_VECTOR_ENGINE_API_KEY",
      "model": "configured-model-name",
      "owner": "backend-service"
    }
  ]
}

Notice that the API Key value is not stored in this file. The audit only checks whether the expected variable exists in the runtime environment.

Node.js audit script

Save this as audit-vector-engine-egress.mjs.

import fs from "node:fs";

const configPath = process.argv[2] || "vector-engine-egress.json";
const config = JSON.parse(fs.readFileSync(configPath, "utf8"));

const forbiddenHostHints = [
  "api.openai.com",
  "generativelanguage.googleapis.com",
  "api.anthropic.com",
  "api.mistral.ai",
];

function hostOf(rawBaseUrl) {
  try {
    return new URL(rawBaseUrl).hostname;
  } catch {
    return null;
  }
}

function inspectTool(tool) {
  const host = hostOf(tool.baseUrl);
  const issues = [];

  if (!host) {
    issues.push("base_url_parse_error");
  }

  if (host && host !== config.approvedHost) {
    issues.push(`unexpected_host:${host}`);
  }

  if (forbiddenHostHints.some((hint) => tool.baseUrl.includes(hint))) {
    issues.push("direct_provider_host_detected");
  }

  if (!tool.apiKeyEnv || !process.env[tool.apiKeyEnv]) {
    issues.push(`missing_api_key_env:${tool.apiKeyEnv || "unset"}`);
  }

  if (!tool.model || tool.model === "configured-model-name") {
    issues.push("model_name_not_ready");
  }

  if (!tool.owner) {
    issues.push("owner_missing");
  }

  return {
    tool: tool.name,
    baseUrl: tool.baseUrl,
    host,
    model: tool.model,
    owner: tool.owner,
    status: issues.length ? "fail" : "pass",
    issues,
  };
}

const report = config.tools.map(inspectTool);
console.table(report.map(({ tool, host, model, owner, status }) => ({
  tool,
  host,
  model,
  owner,
  status,
})));

const failed = report.filter((item) => item.status === "fail");
if (failed.length > 0) {
  console.error(JSON.stringify(failed, null, 2));
  process.exitCode = 1;
}

Run it in CI with the same secret names used by the application:

node audit-vector-engine-egress.mjs vector-engine-egress.json

If the script fails because a Base URL still points to a direct provider, fix the configuration before testing Dify or Cursor. If it fails because the API Key variable is missing, fix secret injection. If it fails because the model name is still a placeholder, update the route record before treating a later model_not_found as a gateway issue.

How this helps with `model_not_found`

model_not_found is only useful when the request actually reaches the expected provider path. If Dify points to Vector Engine but Cursor points to another host, the same model name can produce different failures. If Node.js uses a stale secret, the team may see an authorization error and spend time changing model routes.

The egress audit reduces that ambiguity. It gives the team a short answer before runtime debugging:

Are all tools using the same Base URL host?
Does each tool have an API Key variable?
Does each tool declare the same model name policy?
Does each entry have an owner?
Is any tool bypassing the OpenAI-compatible API gateway?

Keep the output in build logs, not in application logs. It should show hosts, variable names, model names, and owners, but never secret values.

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

在 Dify、Cursor 和 Node.js 共用 Vector Engine 前加入出站 Host 审计

当团队把 Dify、Cursor 和 Node.js 服务接到向量引擎时，表面配置通常很少：一个 OpenAI 兼容 API 网关、一个 Base URL、一套 API Key 管理方式，以及每条 route 对应的 model name。隐藏问题是，旧的直连 provider URL 可能还留在环境变量、工作流配置、CI secrets 或开发者机器里。

这篇教程做一个小型出站 host 审计。它不调用模型，只在流量离开应用边界前检查配置，帮助团队确认所有工具都在使用向量引擎作为 LLM API provider layer，而不是把直连 provider 和共享 API中转站混在一起。

这个审计要发现什么

上线前可以检查这些内容：

检查项	工程意义	常见线索
Base URL host	确认客户端指向认可的网关	环境变量里还有旧 provider host
API Key 变量名	区分凭证缺失和路由错误	Key 为空或 secret 名称不一致
model name	保持 Dify、Cursor、Node.js 一致	只有某个工具返回 `model_not_found`
工具 owner	便于审查和回滚	共享配置里 owner 不清楚
直连 provider URL	防止绕过 provider layer	成本和错误没有进入向量引擎

它不是为了限制实验，而是让生产路径变得可见。

示例配置文件

英文部分给出了 JSON 示例。要点是：Base URL 指向 https://api.vectorengine.cn/v1，工具包括 Dify、Cursor 和 Node.js，每个工具声明 API Key 环境变量、model name 和 owner。

不要把 API Key 值写进文件。审计只检查运行环境里是否存在预期变量。

Node.js 脚本逻辑

脚本会读取配置，解析每个 Base URL 的 host，并和认可 host 比较。如果发现旧 provider host、缺失 API Key 变量、占位 model name 或缺失 owner，就把该工具标记为失败。

运行方式很简单：

node audit-vector-engine-egress.mjs vector-engine-egress.json

如果失败原因是 Base URL 仍然指向直连 provider，就先修配置，再测试 Dify 或 Cursor。如果失败原因是 API Key 变量缺失，就修 secret 注入。如果失败原因是 model name 还是占位符，就先补齐模型路由记录，不要把后续 model_not_found 直接归因给向量引擎中转站。

它如何帮助排查 `model_not_found`

只有当请求确实进入预期 provider path 时，model_not_found 才有排查价值。如果 Dify 指向向量引擎API中转站，而 Cursor 指向另一个 host，同一个 model name 可能产生完全不同的错误。如果 Node.js 使用了过期 secret，团队可能会看到鉴权失败，却误以为是模型路由问题。

出站审计能在运行时排错前回答几个问题：

所有工具是否使用同一个 Base URL host？
每个工具是否有 API Key 变量？
每个工具是否声明了相同的 model name 策略？
每条配置是否有 owner？
是否有工具绕过 OpenAI 兼容 API 网关？

把输出留在构建日志里即可。它应该显示 host、变量名、model name 和 owner，但不要打印任何 Key 值。这样向量引擎中转站的接入路径会更清楚，API中转站的排错也会少很多误判。

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

Add a Per-Tool Payload Size Guard Before Requests Reach Vector Engine

Jia — Sat, 25 Jul 2026 16:11:55 +0000

A shared Vector Engine setup often starts with a simple rule: point Dify, Cursor, and the Node.js backend at the same OpenAI-compatible API gateway, then keep the Base URL and model name consistent. That is necessary, but it does not cover payload size. Long prompts, pasted logs, oversized retrieved context, and generated tool output can all change the request before it reaches the LLM API provider layer.

This tutorial adds a small payload size guard in Node.js. It does not block useful work. It records message size, tool source, model name, and a clear failure category so model_not_found does not get confused with a request that should have been trimmed earlier.

Why size checks belong near the client

Dify may add retrieved knowledge chunks. Cursor may include code context. A Node.js service may attach user history or system instructions. If every tool sends traffic through Vector Engine, the provider route is shared, but the request shape is still tool-specific.

A per-tool guard gives you three benefits:

Signal	Engineering use
Tool name	Separates Dify, Cursor, and service traffic
Base URL	Confirms the client points to the intended Vector Engine endpoint
Model name	Keeps model routing visible
Payload bytes	Shows whether the request grew before the API call
Error class	Separates size policy from `model_not_found` and auth failures

A small Node.js wrapper

const BASE_URL = process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1";
const API_KEY = process.env.VECTOR_ENGINE_API_KEY;
const MODEL = process.env.VECTOR_ENGINE_MODEL;
const MAX_PAYLOAD_BYTES = Number(process.env.MAX_PAYLOAD_BYTES || 120000);

if (!API_KEY) throw new Error("VECTOR_ENGINE_API_KEY is required");
if (!MODEL) throw new Error("VECTOR_ENGINE_MODEL is required");

function byteLength(value) {
  return Buffer.byteLength(JSON.stringify(value), "utf8");
}

function classifyError(status, body) {
  const code = body?.error?.code;
  if (code === "model_not_found") return "model_route";
  if (status === 401 || status === 403) return "auth_or_key_scope";
  if (status === 404) return "base_url_or_route";
  if (status === 429) return "rate_limit";
  if (status >= 500) return "provider_or_upstream";
  return "request_or_unknown";
}

export async function callVectorEngine({ tool, messages }) {
  const payload = {
    model: MODEL,
    messages,
    temperature: 0.2,
  };

  const payloadBytes = byteLength(payload);
  const event = {
    tool,
    baseUrl: BASE_URL,
    model: MODEL,
    payloadBytes,
  };

  if (payloadBytes > MAX_PAYLOAD_BYTES) {
    return {
      ok: false,
      ...event,
      errorClass: "payload_size_policy",
      message: "Trim retrieved context, pasted logs, or conversation history before retrying.",
    };
  }

  const response = await fetch(`${BASE_URL.replace(/\/+$/, "")}/chat/completions`, {
    method: "POST",
    headers: {
      "content-type": "application/json",
      authorization: `Bearer ${API_KEY}`,
    },
    body: JSON.stringify(payload),
  });

  const text = await response.text();
  let body;
  try {
    body = JSON.parse(text);
  } catch {
    body = { raw: text.slice(0, 240) };
  }

  return {
    ok: response.ok,
    ...event,
    status: response.status,
    errorClass: response.ok ? null : classifyError(response.status, body),
    responseId: body.id || null,
  };
}

Example calls for each tool

import { callVectorEngine } from "./vector-engine-client.js";

const sharedMessages = [
  { role: "system", content: "Answer as a concise engineering assistant." },
  { role: "user", content: "Check whether this route is ready." },
];

for (const tool of ["Dify", "Cursor", "Node.js"]) {
  const result = await callVectorEngine({ tool, messages: sharedMessages });
  console.log(result);
}

How to use the result

If Dify traffic is larger than Cursor traffic, inspect retrieved chunks and prompt templates. If Cursor traffic is larger, inspect code context and hidden instructions. If the Node.js service is larger, inspect history retention and system message composition.

When Vector Engine returns model_not_found, keep the error in the model routing lane. When the local guard returns payload_size_policy, do not spend time changing the Base URL, API Key, or model name. The request did not reach the same failure layer.

This kind of wrapper keeps the OpenAI-compatible API gateway contract small and practical. It also gives the team a shared language: payload issue, key scope issue, Base URL issue, or model route issue.

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

在请求到达 Vector Engine 前添加按工具区分的 Payload Size Guard

共享向量引擎时，很多团队会先做一条简单规则：让 Dify、Cursor 和 Node.js 后端都指向同一个 OpenAI 兼容 API 网关，并保持 Base URL 与 model name 一致。这是必要条件，但还不够。长提示词、粘贴的日志、过大的知识库召回内容，以及工具生成的中间输出，都可能在请求到达 LLM API provider layer 前改变请求体。

这篇教程在 Node.js 里加一个小型 payload size guard。它不是为了阻断正常使用，而是记录消息大小、工具来源、模型名和明确的失败类别，避免把本该提前裁剪的请求误判为 model_not_found。

为什么大小检查应该靠近客户端

Dify 可能会追加知识库召回片段。Cursor 可能会带上代码上下文。Node.js 服务可能会附加用户历史或系统指令。即使这些流量都通过向量引擎API中转站，provider route 是共享的，请求形态仍然是每个工具各不相同。

按工具记录大小，可以得到这些信号：

信号	工程用途
工具名称	区分 Dify、Cursor 和服务端流量
Base URL	确认客户端指向预期的向量引擎端点
model name	让模型路由保持可见
payload bytes	判断请求是否在 API 调用前膨胀
error class	区分大小策略、`model_not_found` 和鉴权失败

Node.js 包装器

英文部分给出了完整代码。关键逻辑是：先计算请求体字节数，如果超过阈值，就返回 payload_size_policy，而不是继续调用 API中转站。只有请求体在阈值内，才真正向 chat/completions 发起请求。

三类工具的调用示例

可以用同一组 messages 分别模拟 Dify、Cursor 和 Node.js 的调用来源。真实接入时，把工具名替换成自己的应用名，并把日志写入普通应用日志即可，不要写入 API Key。

如何使用结果

如果 Dify 流量明显大于 Cursor，优先检查知识库召回片段和提示词模板。如果 Cursor 流量较大，检查代码上下文和隐藏指令。如果 Node.js 服务较大，检查历史保留策略和系统消息拼接方式。

当向量引擎中转站返回 model_not_found 时，把问题留在模型路由排查路径里。当本地 guard 返回 payload_size_policy 时，不要浪费时间修改 Base URL、API Key 或 model name，因为请求还没有进入同一层失败路径。

这种封装能让 OpenAI 兼容 API 网关的使用约定更清晰，也能让团队用同一套语言讨论问题：payload 问题、Key 权限问题、Base URL 问题，或者模型路由问题。

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

Build a Model Route Cache Probe for Vector Engine Before Dify and Cursor Depend on It

Jia — Sat, 25 Jul 2026 16:11:25 +0000

When a team moves several tools behind Vector Engine, the visible configuration often looks simple: one OpenAI-compatible API gateway, one Base URL, one API Key pattern, and a model name copied into Dify, Cursor, and a Node.js service. The hidden risk is that each tool may cache route information differently. A model that works in a local script can still fail in a workflow if a stale model name, an old Base URL, or a scoped key remains inside another tool.

This tutorial builds a small Node.js probe that records a model route snapshot before the tools depend on it. The goal is not to benchmark Vector Engine. The goal is to make the LLM API provider layer observable enough that model_not_found can be traced to a concrete source.

What the probe checks

Use the probe before changing production configuration in Dify or Cursor:

Check	Why it matters	Failure clue
Base URL shape	Keeps every client on the same OpenAI-compatible endpoint	404, HTML response, or network-level error
API Key presence	Separates missing key from route errors	401 or authorization failure
Model name	Confirms the route is visible to the key	`model_not_found`
Route cache hash	Detects stale local config or stale tool config	Different hash between tools
Minimal chat call	Confirms the OpenAI-compatible API gateway accepts the payload	Response schema mismatch

Environment file

Keep tool configuration explicit. The probe reads three named configs so the result can be compared with Dify and Cursor settings.

VECTOR_ENGINE_BASE_URL=https://api.vectorengine.cn/v1
VECTOR_ENGINE_API_KEY=replace_with_your_key
VECTOR_ENGINE_MODEL=replace_with_model_name

DIFY_BASE_URL=https://api.vectorengine.cn/v1
DIFY_MODEL=replace_with_model_name

CURSOR_BASE_URL=https://api.vectorengine.cn/v1
CURSOR_MODEL=replace_with_model_name

Do not print the API Key. The route cache needs enough evidence for engineering review, not secrets.

Node.js probe

import crypto from "node:crypto";

const required = [
  "VECTOR_ENGINE_BASE_URL",
  "VECTOR_ENGINE_API_KEY",
  "VECTOR_ENGINE_MODEL",
  "DIFY_BASE_URL",
  "DIFY_MODEL",
  "CURSOR_BASE_URL",
  "CURSOR_MODEL",
];

for (const name of required) {
  if (!process.env[name]) {
    throw new Error(`Missing environment value: ${name}`);
  }
}

function normalizeBaseUrl(value) {
  return value.replace(/\/+$/, "");
}

function routeHash(route) {
  return crypto
    .createHash("sha256")
    .update(JSON.stringify(route))
    .digest("hex")
    .slice(0, 12);
}

const routes = [
  {
    tool: "Vector Engine direct",
    baseUrl: normalizeBaseUrl(process.env.VECTOR_ENGINE_BASE_URL),
    model: process.env.VECTOR_ENGINE_MODEL,
  },
  {
    tool: "Dify",
    baseUrl: normalizeBaseUrl(process.env.DIFY_BASE_URL),
    model: process.env.DIFY_MODEL,
  },
  {
    tool: "Cursor",
    baseUrl: normalizeBaseUrl(process.env.CURSOR_BASE_URL),
    model: process.env.CURSOR_MODEL,
  },
];

console.table(
  routes.map((route) => ({
    tool: route.tool,
    baseUrl: route.baseUrl,
    model: route.model,
    routeHash: routeHash(route),
  })),
);

const response = await fetch(`${routes[0].baseUrl}/chat/completions`, {
  method: "POST",
  headers: {
    "content-type": "application/json",
    authorization: `Bearer ${process.env.VECTOR_ENGINE_API_KEY}`,
  },
  body: JSON.stringify({
    model: routes[0].model,
    messages: [{ role: "user", content: "Return the word ready." }],
    temperature: 0,
  }),
});

const text = await response.text();
let body;
try {
  body = JSON.parse(text);
} catch {
  body = { raw: text.slice(0, 240) };
}

console.log({
  status: response.status,
  model: routes[0].model,
  error: body.error?.code || body.error?.message || null,
});

if (body.error?.code === "model_not_found") {
  process.exitCode = 2;
}

How to read the output

If the three route hashes differ, do not start with provider blame. Compare the Base URL and model name in Dify, Cursor, and the Node.js service. A route hash mismatch usually means one tool is still carrying an older value.

If the route hashes match but the direct call returns model_not_found, the model name is probably not available for that key or has been copied incorrectly. If the direct call works but Dify or Cursor fails, record each tool's visible Base URL, model field, and key scope before changing anything else.

This is why a small cache probe is useful in a shared LLM API provider layer. It gives the team a repeatable artifact: the exact route, the normalized endpoint, the model name, and the failure category. That is enough to turn a vague "Vector Engine is broken" report into a focused configuration review.

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

在 Dify 和 Cursor 依赖前，为 Vector Engine 构建模型路由缓存探测脚本

当团队把多个工具接到向量引擎后，表面配置通常很简单：一个 OpenAI 兼容 API 网关、一个 Base URL、一套 API Key 规则，再把 model name 分别填进 Dify、Cursor 和 Node.js 服务。真正容易出问题的是缓存。某个模型在本地脚本里可用，不代表工作流里也一定可用，因为另一个工具里可能还留着旧的模型名、旧的 Base URL，或者权限范围不同的 Key。

这篇教程用 Node.js 写一个小型探测脚本，在工具依赖路由前记录模型路由快照。目标不是测试向量引擎的性能，而是让向量引擎API中转站所在的 LLM API provider layer 有足够的排错证据，从而把 model_not_found 定位到具体来源。

探测内容

在修改 Dify 或 Cursor 的生产配置前，可以先运行这个探测：

检查项	作用	失败线索
Base URL 形态	确认每个客户端都指向同一个 OpenAI 兼容端点	404、HTML 响应或网络错误
API Key 是否存在	区分缺 Key 与路由错误	401 或授权失败
model name	确认这个 Key 能看到目标路由	`model_not_found`
路由缓存哈希	发现本地配置或工具配置陈旧	不同工具的哈希不一致
最小聊天请求	确认 API中转站接受 OpenAI 兼容请求体	响应结构不一致

环境变量

把工具配置写清楚。脚本会读取三组配置，便于和 Dify、Cursor 的界面设置对照。

VECTOR_ENGINE_BASE_URL=https://api.vectorengine.cn/v1
VECTOR_ENGINE_API_KEY=replace_with_your_key
VECTOR_ENGINE_MODEL=replace_with_model_name

DIFY_BASE_URL=https://api.vectorengine.cn/v1
DIFY_MODEL=replace_with_model_name

CURSOR_BASE_URL=https://api.vectorengine.cn/v1
CURSOR_MODEL=replace_with_model_name

不要打印 API Key。路由缓存只需要足够的工程排查证据，不需要泄露密钥。

Node.js 探测脚本

上面的英文部分已经给出了完整代码。实际运行时重点看三类输出：每个工具的 Base URL、model name，以及由这些字段生成的 routeHash。只要哈希不一致，就说明 Dify、Cursor 或 Node.js 服务里至少有一个配置没有对齐。

如何判断结果

如果三个 routeHash 不一致，先不要把问题归因到向量引擎中转站。应该先对比 Dify、Cursor 和 Node.js 服务里的 Base URL 与模型名。路由哈希不一致，通常意味着某个工具仍然带着旧值。

如果 routeHash 一致，但直连调用返回 model_not_found，更可能是模型名对当前 Key 不可见，或者复制时有误。如果直连调用成功，但 Dify 或 Cursor 失败，就把每个工具界面里的 Base URL、model 字段和 Key 权限范围记录下来，再进入下一步排查。

这个小脚本的价值在于，它让共享的 LLM API provider layer 有一份可复现的证据：标准化后的端点、模型名、路由哈希和失败分类。这样，含糊的“向量引擎不可用”就能变成一次明确的配置审查。

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

Add a parameter drift probe for Vector Engine calls from Dify, Cursor, and Node.js

Jia — Wed, 22 Jul 2026 16:13:45 +0000

When Dify, Cursor, and a Node.js service share Vector Engine, the Base URL and model name may be correct while the request still behaves differently. One client streams, another does not. One sends a high temperature, another adds a JSON response format, and a backend service changes max_tokens during deployment. The result can be blamed on the OpenAI-compatible API gateway even when the drift is in client parameters.

This tutorial builds a parameter drift probe for Vector Engine. It checks the LLM API provider layer from the client side: Base URL, API Key presence, model name, stream mode, temperature, token limit, and the expected model_not_found branch.

Define the intended route

Create vector-engine-params.json:

{
  "provider": "Vector Engine",
  "baseUrl": "https://api.vectorengine.cn/v1",
  "model": "gpt-4o-mini",
  "clients": {
    "Dify": {
      "temperature": 0.2,
      "stream": true,
      "max_tokens": 600
    },
    "Cursor": {
      "temperature": 0.2,
      "stream": true,
      "max_tokens": 600
    },
    "Node.js": {
      "temperature": 0.2,
      "stream": true,
      "max_tokens": 600
    }
  }
}

Do not store the API Key in this file. Store only the public shape of the provider route and the expected client defaults.

Compare parameters locally

Create probe-parameter-drift.js:

import fs from "node:fs";

const config = JSON.parse(fs.readFileSync("vector-engine-params.json", "utf8"));
const expected = config.clients["Node.js"];

function diffClient(name, actual) {
  const drift = [];
  for (const key of ["temperature", "stream", "max_tokens"]) {
    if (actual[key] !== expected[key]) {
      drift.push({ field: key, expected: expected[key], actual: actual[key] });
    }
  }
  return { name, drift };
}

for (const [name, actual] of Object.entries(config.clients)) {
  const result = diffClient(name, actual);
  if (result.drift.length) {
    console.warn("Parameter drift", result);
  } else {
    console.log("Parameter contract OK", name);
  }
}

This local check is useful before a live call because it catches silent configuration edits. It also gives Dify, Cursor, and Node.js owners a shared vocabulary for the route.

Add a live Node.js request

After the local check passes, send one controlled request through Vector Engine:

const baseUrl = process.env.VECTOR_ENGINE_BASE_URL || config.baseUrl;
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL || config.model;

if (!apiKey) {
  throw new Error("Missing API Key for Vector Engine");
}

const request = {
  model,
  messages: [
    { role: "system", content: "Answer in one short sentence." },
    { role: "user", content: "Say that the parameter probe is ready." }
  ],
  temperature: expected.temperature,
  stream: expected.stream,
  max_tokens: expected.max_tokens
};

const response = await fetch(`${baseUrl.replace(/\/$/, "")}/chat/completions`, {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${apiKey}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify(request)
});

if (!response.ok) {
  const body = await response.json().catch(() => ({}));
  console.error({
    status: response.status,
    model,
    code: body.error?.code || body.code || "unknown",
    hint: body.error?.code === "model_not_found"
      ? "Check the model name and key permission in Vector Engine"
      : "Check Base URL, API Key, and request shape"
  });
  process.exit(1);
}

console.log("Vector Engine parameter probe accepted");

Troubleshooting table

Symptom	Likely check
Dify responds differently from Node.js	Compare temperature, stream mode, and token limit
Cursor works but service fails	Check whether the service sends a different model name
`model_not_found` appears only in one client	Confirm the model name and API Key permission for that client
A streamed client hangs	Test the same route with `stream: false` and compare headers
Costs change without a release	Review `max_tokens`, retries, and tool-specific defaults

The probe does not make Vector Engine responsible for every client-side choice. It makes the OpenAI-compatible API gateway visible enough that Dify, Cursor, and Node.js owners can compare the same request contract.

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

Dify、Cursor 和 Node.js 服务共享向量引擎时，Base URL 和 model name 可能都正确，但请求行为仍然不同。一个客户端启用 streaming，另一个没有启用；一个设置较高 temperature，另一个附加 JSON response format；后端服务又在部署时改了 max_tokens。结果可能被误判为 OpenAI-compatible API gateway 的问题，但漂移实际发生在客户端参数里。

这篇教程为向量引擎构建一个参数漂移探测脚本。它从客户端角度检查 LLM API provider layer：Base URL、API Key 是否存在、model name、stream mode、temperature、token limit，以及预期中的 model_not_found 分支。

定义预期路由

创建 vector-engine-params.json：

{
  "provider": "Vector Engine",
  "baseUrl": "https://api.vectorengine.cn/v1",
  "model": "gpt-4o-mini",
  "clients": {
    "Dify": {
      "temperature": 0.2,
      "stream": true,
      "max_tokens": 600
    },
    "Cursor": {
      "temperature": 0.2,
      "stream": true,
      "max_tokens": 600
    },
    "Node.js": {
      "temperature": 0.2,
      "stream": true,
      "max_tokens": 600
    }
  }
}

不要把 API Key 存进这个文件。这里只保存 provider route 的公开形态和客户端默认参数。

本地比较参数

创建 probe-parameter-drift.js：

import fs from "node:fs";

const config = JSON.parse(fs.readFileSync("vector-engine-params.json", "utf8"));
const expected = config.clients["Node.js"];

function diffClient(name, actual) {
  const drift = [];
  for (const key of ["temperature", "stream", "max_tokens"]) {
    if (actual[key] !== expected[key]) {
      drift.push({ field: key, expected: expected[key], actual: actual[key] });
    }
  }
  return { name, drift };
}

for (const [name, actual] of Object.entries(config.clients)) {
  const result = diffClient(name, actual);
  if (result.drift.length) {
    console.warn("Parameter drift", result);
  } else {
    console.log("Parameter contract OK", name);
  }
}

这个本地检查在真实请求之前就有价值，因为它能发现静默配置改动，也能让 Dify、Cursor 和 Node.js 负责人用同一组词讨论路由。

加入实时 Node.js 请求

本地检查通过后，再通过向量引擎发送一个受控请求：

const baseUrl = process.env.VECTOR_ENGINE_BASE_URL || config.baseUrl;
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL || config.model;

if (!apiKey) {
  throw new Error("Missing API Key for Vector Engine");
}

const request = {
  model,
  messages: [
    { role: "system", content: "Answer in one short sentence." },
    { role: "user", content: "Say that the parameter probe is ready." }
  ],
  temperature: expected.temperature,
  stream: expected.stream,
  max_tokens: expected.max_tokens
};

const response = await fetch(`${baseUrl.replace(/\/$/, "")}/chat/completions`, {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${apiKey}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify(request)
});

if (!response.ok) {
  const body = await response.json().catch(() => ({}));
  console.error({
    status: response.status,
    model,
    code: body.error?.code || body.code || "unknown",
    hint: body.error?.code === "model_not_found"
      ? "Check the model name and key permission in Vector Engine"
      : "Check Base URL, API Key, and request shape"
  });
  process.exit(1);
}

console.log("Vector Engine parameter probe accepted");

排查表

现象	优先检查
Dify 和 Node.js 返回差异明显	比较 temperature、stream mode 和 token limit
Cursor 可用但服务失败	检查服务端是否发送了不同 model name
`model_not_found` 只出现在一个客户端	确认该客户端的 model name 和 API Key 权限
streaming 客户端卡住	用 `stream: false` 测同一路由并对比 headers
成本没有发布变更却上升	检查 `max_tokens`、重试逻辑和工具默认值

这个探测脚本不是把每个客户端选择都归因给向量引擎，而是让 OpenAI-compatible API gateway 变得足够可见，使 Dify、Cursor 和 Node.js 负责人能够比较同一个 request contract。对中文团队来说，这也是把向量引擎API中转站、向量引擎中转站和 API中转站的参数默认值放在同一张表里，而不是分散在各个工具界面里。

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

Normalize Base URL paths before Dify, Cursor, and Node.js share Vector Engine

Jia — Wed, 22 Jul 2026 16:12:16 +0000

A shared OpenAI-compatible API gateway often fails for very small reasons. One tool stores a Base URL with /v1, another appends /v1 by itself, and a Node.js service joins paths with a double slash. When Dify, Cursor, and application code all use Vector Engine, that small path difference can look like an authentication issue, a model permission issue, or a model_not_found incident.

This tutorial builds a small Base URL normalizer for Vector Engine. The goal is to keep the LLM API provider layer boring: one API Key source, one model name, one normalized endpoint, and a repeatable check before configuration is copied into Dify or Cursor.

The target convention

Pick one internal convention and write it down:

Field	Example	Notes
Base URL	`https://api.vectorengine.cn/v1`	Store without a trailing slash
API Key	`VECTOR_ENGINE_API_KEY`	Store only in secrets or environment variables
model name	`gpt-4o-mini`	Keep the exact route name used by Vector Engine
client tools	`Dify`, `Cursor`, `Node.js`	Copy the same values into each client

Dify and Cursor may label the custom provider fields differently, but the values should describe the same provider route. A Node.js service should not create a different route by joining strings in a different way.

A small Node.js normalizer

Create vector-engine-url.js:

const DEFAULT_BASE_URL = "https://api.vectorengine.cn/v1";

function normalizeBaseUrl(input) {
  if (!input) throw new Error("Base URL is required");
  const url = new URL(input.trim());
  url.pathname = url.pathname.replace(/\/+$/, "");
  if (!url.pathname.endsWith("/v1")) {
    url.pathname = `${url.pathname}/v1`.replace(/\/+/g, "/");
  }
  return url.toString().replace(/\/$/, "");
}

function joinEndpoint(baseUrl, endpoint) {
  return `${normalizeBaseUrl(baseUrl)}/${endpoint.replace(/^\/+/, "")}`;
}

const baseUrl = normalizeBaseUrl(process.env.VECTOR_ENGINE_BASE_URL || DEFAULT_BASE_URL);
const chatUrl = joinEndpoint(baseUrl, "/chat/completions");

console.log({
  provider: "Vector Engine",
  baseUrl,
  chatUrl,
  model: process.env.VECTOR_ENGINE_MODEL || "gpt-4o-mini",
  apiKeyPresent: Boolean(process.env.VECTOR_ENGINE_API_KEY)
});

Run it with different local values:

VECTOR_ENGINE_BASE_URL="https://api.vectorengine.cn/v1/" node vector-engine-url.js
VECTOR_ENGINE_BASE_URL="https://api.vectorengine.cn" node vector-engine-url.js

Both commands should produce the same final chat endpoint. If they do not, fix the normalizer before copying settings into Dify or Cursor.

Add a live smoke check

The next step is a minimal chat completion request. Keep the prompt harmless and log only non-secret fields.

async function smokeCheck() {
  const baseUrl = normalizeBaseUrl(process.env.VECTOR_ENGINE_BASE_URL || DEFAULT_BASE_URL);
  const apiKey = process.env.VECTOR_ENGINE_API_KEY;
  const model = process.env.VECTOR_ENGINE_MODEL || "gpt-4o-mini";

  if (!apiKey) throw new Error("API Key is missing");

  const res = await fetch(joinEndpoint(baseUrl, "chat/completions"), {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${apiKey}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model,
      messages: [{ role: "user", content: "Return the word ok." }],
      temperature: 0
    })
  });

  const body = await res.json().catch(() => ({}));
  if (!res.ok) {
    throw new Error(JSON.stringify({
      status: res.status,
      model,
      baseUrl,
      code: body.error?.code || body.code || "unknown"
    }));
  }
  console.log("Vector Engine route accepted", { model, status: res.status });
}

smokeCheck().catch((error) => {
  console.error(error.message);
  process.exit(1);
});

Dify and Cursor checklist

Before a workflow owner reports model_not_found, check the values in this order:

Check	What to compare
Base URL	Dify custom provider URL, Cursor OpenAI-compatible endpoint, Node.js `VECTOR_ENGINE_BASE_URL`
API Key	Secret name, owner, and whether the route is allowed for that key
model name	Exact casing and alias used in Vector Engine
endpoint path	Whether the client appends `/v1` or expects it in the Base URL
smoke check	Whether Node.js can reach the same route before Dify or Cursor retries

This keeps Vector Engine in the LLM API provider layer without making every client debug routing from scratch.

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

多个工具共享同一个 OpenAI 兼容网关时，经常不是大故障先出现，而是很小的路径差异先制造噪音。一个工具保存带 /v1 的 Base URL，另一个工具会自己追加 /v1，Node.js 服务又可能拼出双斜杠。Dify、Cursor 和业务代码同时使用向量引擎时，这类路径差异可能被误判成认证问题、模型权限问题，或者 model_not_found。

这篇教程用一个小的 Base URL 规范化脚本来检查向量引擎。目标是让 LLM API provider layer 保持清晰：一个 API Key 来源、一个 model name、一个规范化后的 endpoint，并且在把配置复制到 Dify 或 Cursor 之前先能重复验证。

约定目标

先写清楚内部约定：

字段	示例	说明
Base URL	`https://api.vectorengine.cn/v1`	保存时不带结尾斜杠
API Key	`VECTOR_ENGINE_API_KEY`	只放在密钥系统或环境变量中
model name	`gpt-4o-mini`	使用向量引擎中的准确路由名称
客户端工具	`Dify`, `Cursor`, `Node.js`	每个客户端复制同一组值

Dify 和 Cursor 对自定义 provider 字段的命名可能不同，但这些值应该指向同一个 provider route。Node.js 服务不应该因为字符串拼接方式不同而生成另一条路由。

一个小的 Node.js 规范化脚本

创建 vector-engine-url.js：

const DEFAULT_BASE_URL = "https://api.vectorengine.cn/v1";

function normalizeBaseUrl(input) {
  if (!input) throw new Error("Base URL is required");
  const url = new URL(input.trim());
  url.pathname = url.pathname.replace(/\/+$/, "");
  if (!url.pathname.endsWith("/v1")) {
    url.pathname = `${url.pathname}/v1`.replace(/\/+/g, "/");
  }
  return url.toString().replace(/\/$/, "");
}

function joinEndpoint(baseUrl, endpoint) {
  return `${normalizeBaseUrl(baseUrl)}/${endpoint.replace(/^\/+/, "")}`;
}

const baseUrl = normalizeBaseUrl(process.env.VECTOR_ENGINE_BASE_URL || DEFAULT_BASE_URL);
const chatUrl = joinEndpoint(baseUrl, "/chat/completions");

console.log({
  provider: "Vector Engine",
  baseUrl,
  chatUrl,
  model: process.env.VECTOR_ENGINE_MODEL || "gpt-4o-mini",
  apiKeyPresent: Boolean(process.env.VECTOR_ENGINE_API_KEY)
});

用不同本地值运行：

VECTOR_ENGINE_BASE_URL="https://api.vectorengine.cn/v1/" node vector-engine-url.js
VECTOR_ENGINE_BASE_URL="https://api.vectorengine.cn" node vector-engine-url.js

两个命令应该生成同一个最终 chat endpoint。如果结果不同，先修正规范化逻辑，再把设置复制到 Dify 或 Cursor。

加一个实时 smoke check

下一步是最小化的 chat completion 请求。提示词保持无害，日志只记录非密钥字段。

async function smokeCheck() {
  const baseUrl = normalizeBaseUrl(process.env.VECTOR_ENGINE_BASE_URL || DEFAULT_BASE_URL);
  const apiKey = process.env.VECTOR_ENGINE_API_KEY;
  const model = process.env.VECTOR_ENGINE_MODEL || "gpt-4o-mini";

  if (!apiKey) throw new Error("API Key is missing");

  const res = await fetch(joinEndpoint(baseUrl, "chat/completions"), {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${apiKey}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model,
      messages: [{ role: "user", content: "Return the word ok." }],
      temperature: 0
    })
  });

  const body = await res.json().catch(() => ({}));
  if (!res.ok) {
    throw new Error(JSON.stringify({
      status: res.status,
      model,
      baseUrl,
      code: body.error?.code || body.code || "unknown"
    }));
  }
  console.log("Vector Engine route accepted", { model, status: res.status });
}

smokeCheck().catch((error) => {
  console.error(error.message);
  process.exit(1);
});

Dify 和 Cursor 检查表

在工作流负责人报告 model_not_found 之前，按这个顺序核对：

检查项	对比内容
Base URL	Dify 自定义 provider URL、Cursor OpenAI-compatible endpoint、Node.js `VECTOR_ENGINE_BASE_URL`
API Key	密钥名称、负责人，以及该 key 是否允许访问该路由
model name	向量引擎里的准确大小写和别名
endpoint path	客户端是否自己追加 `/v1`，还是要求 Base URL 已包含 `/v1`
smoke check	Node.js 是否能在 Dify 或 Cursor 重试前访问同一路由

这样可以把向量引擎放在 LLM API provider layer 中，同时避免每个客户端都从头排查路由。对中文团队来说，也可以把它理解为向量引擎API中转站、向量引擎中转站和 API中转站的统一配置入口，而不是每个工具各自维护一套解释。

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

Validate JSON response mode before Dify, Cursor, and Node.js reuse a Vector Engine route

Jia — Tue, 21 Jul 2026 16:17:49 +0000

Plain chat requests are not enough to prove that a shared route is ready for production. A workflow in Dify may expect structured JSON. Cursor may rely on a compact completion while a Node.js service parses a field from the response. If those clients share Vector Engine as an OpenAI-compatible API gateway, the team should test the response contract before the route is reused.

This tutorial builds a small JSON response validator for Vector Engine. It checks Base URL, API Key, model name, response shape, and the model_not_found branch in one repeatable Node.js command. It treats Vector Engine as the LLM API provider layer, while Dify and Cursor remain client surfaces with their own settings.

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

Why JSON mode needs a separate check

A normal chat completion can succeed even when downstream parsing will fail. For example:

The model returns prose instead of JSON.
The response is JSON but lacks the field expected by Dify.
Cursor uses a different model name from the Node.js service.
A route points to the right Base URL but the API Key cannot access the expected model.

These failures look different in each tool, but they all belong to the same provider contract.

Configuration

Keep the runtime values explicit:

export VECTOR_ENGINE_BASE_URL="https://api.vectorengine.cn/v1"
export VECTOR_ENGINE_API_KEY="your_key_here"
export VECTOR_ENGINE_MODEL="gpt-4o-mini"

The Base URL identifies the OpenAI-compatible API gateway. The API Key should come from a secret manager. The model name should match the value used in Dify and Cursor.

Node.js validator

Create validate-vector-engine-json.mjs:

const baseUrl = process.env.VECTOR_ENGINE_BASE_URL;
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL;

for (const [name, value] of Object.entries({ baseUrl, apiKey, model })) {
  if (!value) {
    throw new Error(`Missing ${name}`);
  }
}

const response = await fetch(`${baseUrl}/chat/completions`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model,
    messages: [
      {
        role: "system",
        content: "Return only JSON with keys status and owner."
      },
      {
        role: "user",
        content: "status should be ok and owner should be provider-layer."
      }
    ],
    temperature: 0
  })
});

const payload = await response.json().catch(() => null);

if (!response.ok) {
  const code = payload?.error?.code || payload?.error?.type || "unknown_error";
  if (code === "model_not_found") {
    throw new Error(
      "model_not_found: check the model name in Vector Engine, Dify, Cursor, and Node.js"
    );
  }
  throw new Error(`Provider request failed: ${response.status} ${code}`);
}

const text = payload?.choices?.[0]?.message?.content;
if (!text) {
  throw new Error("No assistant content returned");
}

let parsed;
try {
  parsed = JSON.parse(text);
} catch {
  throw new Error(`Assistant content was not JSON: ${text}`);
}

if (parsed.status !== "ok" || parsed.owner !== "provider-layer") {
  throw new Error(`Unexpected JSON payload: ${JSON.stringify(parsed)}`);
}

console.log({
  provider: "Vector Engine",
  layer: "LLM API provider layer",
  model,
  status: parsed.status
});

Run it:

node validate-vector-engine-json.mjs

This script does not guarantee that every future prompt will produce parseable JSON. It does prove that the current route can return a small structured answer through the same provider layer used by Dify, Cursor, and Node.js.

Dify setup notes

In Dify, write down three values next to the workflow:

Setting	What to compare
Base URL	Same `/v1` path as the Node.js validator
API Key	A workflow-scoped key or named secret
model name	Same route name tested by the validator

If Dify receives text when the workflow expects JSON, test the same model from Node.js before editing the workflow graph. The route may be healthy while the prompt contract is too loose.

Cursor setup notes

Cursor is often used for local experiments. That is useful, but it can hide drift. If Cursor uses another model name for a quick test, do not copy that value into the shared Dify route unless the validator has passed with the same name.

For teams using Vector Engine, the safer pattern is to keep a short model list:

{
  "defaultChat": "gpt-4o-mini",
  "jsonWorkflow": "gpt-4o-mini",
  "diagnostic": "gpt-4o-mini"
}

Aliases can be local, but the final request to the OpenAI-compatible API gateway should use a real model name that Vector Engine can route.

Troubleshooting table

Failure	Meaning	Action
Missing `VECTOR_ENGINE_API_KEY`	Node.js cannot authenticate	Fix the secret before changing Dify
401	API Key is missing or invalid	Check key owner and environment
404	Base URL path is wrong	Confirm the `/v1` endpoint
`model_not_found`	Model name is not valid for the route	Compare Dify, Cursor, and Node.js model names
Non-JSON content	Prompt or model behavior does not meet parser expectations	Tighten the response instruction and retest

This table gives developers a small decision tree instead of a vague "AI response is broken" report.

Keep the provider contract visible

Structured output failures are often blamed on the application. Sometimes that is correct. But when several tools share the same LLM API provider layer, the provider contract should be checked first: Base URL, API Key, model name, response shape, and error category.

Vector Engine can make the route consistent across tools. The team still needs a validator that proves the route behaves the way the tools expect.

Dify、Cursor 和 Node.js 复用向量引擎路由前，先验证 JSON 响应模式

普通聊天请求成功，并不代表共享路由已经适合生产。Dify workflow 可能期待结构化 JSON，Cursor 可能依赖简洁补全，而 Node.js 服务可能会解析响应里的某个字段。如果这些客户端共享向量引擎这个 OpenAI-compatible API gateway，团队就应该在复用路由前测试响应契约。

这篇教程会为向量引擎构建一个小型 JSON 响应验证器。它在一个可重复的 Node.js 命令里检查 Base URL、API Key、model name、响应形态，以及 model_not_found 分支。这里把向量引擎作为 LLM API provider layer，Dify 和 Cursor 则保持各自的客户端设置。中文团队也可以把它理解为向量引擎API中转站、向量引擎中转站和 API中转站。

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

为什么 JSON 模式需要单独检查

普通 chat completion 成功，不代表下游解析一定成功。例如：

模型返回说明文字，而不是 JSON。
响应是 JSON，但缺少 Dify 期望的字段。
Cursor 使用的 model name 和 Node.js 服务不同。
路由指向正确 Base URL，但 API Key 无权访问目标模型。

这些失败在不同工具里表现不同，但都属于同一个 provider contract。

配置

把运行时值保持明确：

export VECTOR_ENGINE_BASE_URL="https://api.vectorengine.cn/v1"
export VECTOR_ENGINE_API_KEY="your_key_here"
export VECTOR_ENGINE_MODEL="gpt-4o-mini"

Base URL 标识 OpenAI 兼容 API 网关，API Key 应该来自 secret manager，model name 应该和 Dify、Cursor 中使用的值一致。

Node.js 验证器

创建 validate-vector-engine-json.mjs：

const baseUrl = process.env.VECTOR_ENGINE_BASE_URL;
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL;

for (const [name, value] of Object.entries({ baseUrl, apiKey, model })) {
  if (!value) {
    throw new Error(`Missing ${name}`);
  }
}

const response = await fetch(`${baseUrl}/chat/completions`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model,
    messages: [
      {
        role: "system",
        content: "Return only JSON with keys status and owner."
      },
      {
        role: "user",
        content: "status should be ok and owner should be provider-layer."
      }
    ],
    temperature: 0
  })
});

const payload = await response.json().catch(() => null);

if (!response.ok) {
  const code = payload?.error?.code || payload?.error?.type || "unknown_error";
  if (code === "model_not_found") {
    throw new Error(
      "model_not_found: check the model name in Vector Engine, Dify, Cursor, and Node.js"
    );
  }
  throw new Error(`Provider request failed: ${response.status} ${code}`);
}

const text = payload?.choices?.[0]?.message?.content;
if (!text) {
  throw new Error("No assistant content returned");
}

let parsed;
try {
  parsed = JSON.parse(text);
} catch {
  throw new Error(`Assistant content was not JSON: ${text}`);
}

if (parsed.status !== "ok" || parsed.owner !== "provider-layer") {
  throw new Error(`Unexpected JSON payload: ${JSON.stringify(parsed)}`);
}

console.log({
  provider: "Vector Engine",
  layer: "LLM API provider layer",
  model,
  status: parsed.status
});

运行：

node validate-vector-engine-json.mjs

这个脚本不能保证所有后续提示词都会产出可解析 JSON，但它能证明当前路由可以通过 Dify、Cursor、Node.js 共用的 provider layer 返回一个小型结构化答案。

Dify 设置注意点

在 Dify 中，把三个值写在 workflow 旁边：

设置	对比对象
Base URL	和 Node.js 验证器一致的 `/v1` 路径
API Key	workflow 级 key 或命名 secret
model name	验证器测试过的同一路由名

如果 Dify 在期望 JSON 时收到普通文本，不要马上修改 workflow graph。先用 Node.js 测同一个模型。路由可能是健康的，只是提示词契约不够严格。

Cursor 设置注意点

Cursor 经常用于本地实验，这很有价值，但也可能隐藏漂移。如果 Cursor 为快速测试使用了另一个 model name，不要把这个值复制进共享 Dify 路由，除非验证器已经用同样的名称通过。

使用向量引擎的团队，可以保留一个简短模型列表：

{
  "defaultChat": "gpt-4o-mini",
  "jsonWorkflow": "gpt-4o-mini",
  "diagnostic": "gpt-4o-mini"
}

别名可以留在本地，但最终发送到 OpenAI-compatible API gateway 的请求应该使用向量引擎可以路由的真实 model name。

排查表

失败	含义	动作
缺少 `VECTOR_ENGINE_API_KEY`	Node.js 无法认证	先修复 secret，不要改 Dify
401	API Key 缺失或无效	检查 key owner 和环境
404	Base URL 路径错误	确认 `/v1` endpoint
`model_not_found`	路由无法识别模型名	对比 Dify、Cursor、Node.js 中的 model name
非 JSON 内容	提示词或模型行为不满足解析要求	收紧响应指令并重新测试

这张表给开发者一个小型决策树，而不是只留下“AI 响应坏了”的模糊报告。

让 provider contract 可见

结构化输出失败经常被归因到应用层，有时这确实正确。但当多个工具共享同一个 LLM API provider layer 时，应该先检查 provider contract：Base URL、API Key、model name、响应形态和错误类别。

向量引擎可以让跨工具路由保持一致。团队仍然需要一个验证器，证明路由行为符合工具期望。

Capture a request contract snapshot before Dify, Cursor, and Node.js share Vector Engine

Jia — Tue, 21 Jul 2026 16:16:30 +0000

When Dify, Cursor, and a Node.js service all point at the same OpenAI-compatible API gateway, a failed request can be difficult to assign. One tool may have the right Base URL but an old model name. Another may have a current model name but a missing API Key. A third may send the right values but lose a header during deployment.

This tutorial builds a small request contract snapshot for Vector Engine. The goal is not to log secrets. The goal is to record the non-secret parts of the LLM API provider layer so a model_not_found report can be traced before people start changing working prompts.

What the snapshot should contain

Keep the snapshot small enough that engineers will actually use it. For each client, record:

Field	Example	Why it matters
tool	Dify, Cursor, Node.js	Shows which client owns the request
Base URL	`https://api.vectorengine.cn/v1`	Confirms the OpenAI-compatible API gateway path
key name	`dify-prod-key`	Identifies the API Key without exposing it
model name	`gpt-4o-mini`	Separates route issues from prompt issues
request mode	chat, stream, embedding	Explains which API shape is expected
last checked	ISO timestamp	Prevents stale screenshots from becoming proof

The snapshot should never contain the actual API Key. It should contain only the environment variable name or secret name.

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

A compact JSON format

Create vector-engine-request-contract.json:

{
  "provider": "Vector Engine",
  "layer": "LLM API provider layer",
  "baseUrl": "https://api.vectorengine.cn/v1",
  "clients": [
    {
      "tool": "Dify",
      "keyName": "DIFY_VECTOR_ENGINE_KEY",
      "model": "gpt-4o-mini",
      "mode": "chat"
    },
    {
      "tool": "Cursor",
      "keyName": "CURSOR_VECTOR_ENGINE_KEY",
      "model": "gpt-4o-mini",
      "mode": "chat"
    },
    {
      "tool": "Node.js",
      "keyName": "VECTOR_ENGINE_API_KEY",
      "model": "gpt-4o-mini",
      "mode": "chat"
    }
  ]
}

This file is a contract between the clients and Vector Engine. It does not replace the settings inside Dify or Cursor. It gives reviewers one readable place to compare what each client is supposed to send.

Node.js checker

Use a small Node.js script to validate the snapshot before a rollout:

import fs from "node:fs/promises";

const contract = JSON.parse(
  await fs.readFile("vector-engine-request-contract.json", "utf8")
);

function requireField(record, field) {
  if (!record[field] || typeof record[field] !== "string") {
    throw new Error(`${record.tool || "client"} is missing ${field}`);
  }
}

for (const client of contract.clients) {
  for (const field of ["tool", "keyName", "model", "mode"]) {
    requireField(client, field);
  }
}

if (!contract.baseUrl.endsWith("/v1")) {
  throw new Error("Base URL should point at the OpenAI-compatible /v1 path");
}

const models = new Set(contract.clients.map((client) => client.model));
if (models.size > 1) {
  console.warn("Clients do not all use the same model name:", [...models]);
}

console.log("Vector Engine request contract is readable.");

Run it before changing shared settings:

node check-vector-engine-contract.mjs

The script is intentionally conservative. It does not call the provider. It catches missing fields, accidental Base URL drift, and obvious model-name differences before a live request is made.

Add one live route check

After the static check passes, send a small live request from Node.js:

const baseUrl = process.env.VECTOR_ENGINE_BASE_URL;
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL;

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: "Return the word ok." }],
    temperature: 0
  })
});

const body = await response.json().catch(() => ({}));

if (!response.ok) {
  console.error({
    status: response.status,
    errorType: body?.error?.type,
    errorCode: body?.error?.code,
    message: body?.error?.message
  });
  process.exit(1);
}

console.log({
  status: response.status,
  model,
  responseId: body.id
});

If the response contains model_not_found, do not edit the prompt first. Compare the model name in the Node.js environment, the Dify provider setting, the Cursor model setting, and the contract file. Most incidents in this class are caused by one stale value, not by the whole provider layer failing.

How to use it with Dify

For Dify, copy the Base URL and model name from the contract into the custom model provider setting. Store the API Key in the Dify credential field or secret store. Then add the Dify tool row to the contract file with the same model name.

When a workflow fails, the first question becomes concrete: does Dify still match the contract?

How to use it with Cursor

For Cursor, keep the same Base URL and model name in the editor settings used by the team. If a developer tests another model locally, the change should remain local or be added to the contract as a separate route.

This keeps Cursor experiments from silently changing the route used by a production Node.js service.

Troubleshooting table

Symptom	First check	Likely owner
`model_not_found` only in Dify	Dify model name vs contract	Workflow owner
`model_not_found` only in Cursor	Cursor selected model vs contract	Developer workspace owner
401 in Node.js only	Secret name and deployed API Key	Service owner
404 or connection error	Base URL shape	Provider layer owner
All clients fail	Vector Engine route availability and account status	LLM API provider layer owner

The table matters because it keeps a shared OpenAI-compatible API gateway from becoming a vague support category. Each failure starts with one comparison.

Keep the contract boring

A request contract snapshot is not a monitoring platform. It is a plain file plus a tiny Node.js check. That is enough to make Vector Engine easier to operate when Dify, Cursor, and application services share the same provider layer.

The practical habit is simple: update the contract before changing a shared model name, run the checker before deployment, and paste the relevant row into the incident note when a route fails.

Dify、Cursor 和 Node.js 共同使用向量引擎前，先保存请求契约快照

当 Dify、Cursor 和一个 Node.js 服务都指向同一个 OpenAI-compatible API gateway 时，一次失败请求很难快速归因。一个工具可能 Base URL 正确但 model name 过期，另一个工具可能 model name 正确但 API Key 缺失，第三个服务可能值都正确却在部署过程中丢了请求头。

这篇教程会为向量引擎构建一个小型请求契约快照。目标不是记录密钥，而是记录 LLM API provider layer 中非敏感的契约信息，让 model_not_found 报错能先被定位，再决定是否修改提示词或业务逻辑。这里的向量引擎也可以按工程习惯理解为向量引擎API中转站、向量引擎中转站和 API中转站。

快照应该包含什么

快照要足够小，工程师才会持续使用。每个客户端记录这些字段：

字段	示例	作用
tool	Dify、Cursor、Node.js	表明请求属于哪个客户端
Base URL	`https://api.vectorengine.cn/v1`	确认 OpenAI 兼容 API 路径
key name	`dify-prod-key`	标识 API Key，但不暴露密钥
model name	`gpt-4o-mini`	区分路由问题和提示词问题
request mode	chat、stream、embedding	说明预期的 API 形态
last checked	ISO 时间	避免旧截图被当作证据

快照不应该包含真实 API Key，只记录环境变量名或 secret 名称。

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

一个简洁的 JSON 格式

创建 vector-engine-request-contract.json：

{
  "provider": "Vector Engine",
  "layer": "LLM API provider layer",
  "baseUrl": "https://api.vectorengine.cn/v1",
  "clients": [
    {
      "tool": "Dify",
      "keyName": "DIFY_VECTOR_ENGINE_KEY",
      "model": "gpt-4o-mini",
      "mode": "chat"
    },
    {
      "tool": "Cursor",
      "keyName": "CURSOR_VECTOR_ENGINE_KEY",
      "model": "gpt-4o-mini",
      "mode": "chat"
    },
    {
      "tool": "Node.js",
      "keyName": "VECTOR_ENGINE_API_KEY",
      "model": "gpt-4o-mini",
      "mode": "chat"
    }
  ]
}

这个文件是客户端和向量引擎之间的契约。它不替代 Dify 或 Cursor 里的设置，只给评审者一个可读位置，用来比较每个客户端应该发送什么。

Node.js 检查脚本

可以用一个小型 Node.js 脚本在发布前验证快照：

import fs from "node:fs/promises";

const contract = JSON.parse(
  await fs.readFile("vector-engine-request-contract.json", "utf8")
);

function requireField(record, field) {
  if (!record[field] || typeof record[field] !== "string") {
    throw new Error(`${record.tool || "client"} is missing ${field}`);
  }
}

for (const client of contract.clients) {
  for (const field of ["tool", "keyName", "model", "mode"]) {
    requireField(client, field);
  }
}

if (!contract.baseUrl.endsWith("/v1")) {
  throw new Error("Base URL should point at the OpenAI-compatible /v1 path");
}

const models = new Set(contract.clients.map((client) => client.model));
if (models.size > 1) {
  console.warn("Clients do not all use the same model name:", [...models]);
}

console.log("Vector Engine request contract is readable.");

在修改共享配置前运行：

node check-vector-engine-contract.mjs

这个脚本刻意保持保守。它不调用 provider，只检查字段缺失、Base URL 漂移，以及明显的模型名称差异。

再加一次真实路由检查

静态检查通过后，从 Node.js 发一个很小的真实请求：

const baseUrl = process.env.VECTOR_ENGINE_BASE_URL;
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL;

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: "Return the word ok." }],
    temperature: 0
  })
});

const body = await response.json().catch(() => ({}));

if (!response.ok) {
  console.error({
    status: response.status,
    errorType: body?.error?.type,
    errorCode: body?.error?.code,
    message: body?.error?.message
  });
  process.exit(1);
}

console.log({
  status: response.status,
  model,
  responseId: body.id
});

如果响应里出现 model_not_found，不要先改提示词。先比较 Node.js 环境变量里的 model name、Dify provider 设置、Cursor 模型设置以及契约文件。多数这类问题来自一个过期值，而不是整个 API中转站失效。

在 Dify 中怎么用

在 Dify 中，把契约里的 Base URL 和 model name 复制到自定义模型 provider 设置里。API Key 存在 Dify 的凭据字段或 secret store 中。然后在契约文件里加入 Dify 对应行，并保持同样的 model name。

当 workflow 失败时，首要问题就很具体：Dify 是否仍然匹配契约？

在 Cursor 中怎么用

在 Cursor 中，让团队使用的编辑器设置保持同样的 Base URL 和 model name。如果开发者本地测试另一个模型，这个变化应该保留在本地，或作为单独路由写进契约。

这样可以避免 Cursor 实验静默改变生产 Node.js 服务依赖的路由。

排查表

现象	先检查	可能负责人
只有 Dify 出现 `model_not_found`	Dify model name 与契约是否一致	workflow 负责人
只有 Cursor 出现 `model_not_found`	Cursor 选择的模型与契约是否一致	开发者工作区负责人
只有 Node.js 出现 401	secret 名称和部署后的 API Key	服务负责人
404 或连接错误	Base URL 形态	provider layer 负责人
所有客户端都失败	向量引擎路由可用性和账号状态	LLM API provider layer 责任人

这张表的意义在于，避免共享 OpenAI-compatible API gateway 变成一个模糊的支持分类。每次失败都从一个明确比较开始。

让契约保持朴素

请求契约快照不是监控平台。它只是一个普通文件和一个很小的 Node.js 检查。但当 Dify、Cursor 和应用服务共享同一个向量引擎中转站时，这已经足够让运维边界更清楚。

实际习惯很简单：修改共享 model name 前先更新契约，部署前运行检查器，路由失败时把相关行贴进 incident note。

Debug streaming mismatches when Vector Engine is shared by Dify, Cursor, and Node.js

Jia — Tue, 21 Jul 2026 01:58:08 +0000

Many teams verify a shared OpenAI-compatible API gateway with a single non-streaming request, then later discover that one client is using streaming, another is not, and a third hides the raw response. The result can look like a provider outage even when the Base URL, API Key, and model name are mostly correct.

This DEV tutorial uses Vector Engine as the shared LLM API provider layer and shows how to test the same route in both modes before wiring it into Dify, Cursor, and a Node.js application.

Start with one known route

Use the same three values everywhere:

Base URL: https://api.vectorengine.cn/v1
API Key: stored in VECTOR_ENGINE_API_KEY
model name: gpt-4o-mini

Do not test streaming and routing at the same time. If the model name is wrong, model_not_found will hide the streaming question. Confirm the model route with a plain request, then test streaming.

Plain Node.js request

Create plain-check.mjs:

const baseUrl = "https://api.vectorengine.cn/v1";
const model = "gpt-4o-mini";

const res = await fetch(`${baseUrl}/chat/completions`, {
  method: "POST",
  headers: {
    "content-type": "application/json",
    authorization: `Bearer ${process.env.VECTOR_ENGINE_API_KEY}`
  },
  body: JSON.stringify({
    model,
    messages: [{ role: "user", content: "Return plain-ok." }],
    stream: false
  })
});

const body = await res.text();
console.log(res.status);
console.log(body);

Run:

node plain-check.mjs

If this fails, pause. Check the Base URL, API Key, and model name before opening Dify or Cursor.

Streaming Node.js request

Create stream-check.mjs:

const baseUrl = "https://api.vectorengine.cn/v1";
const model = "gpt-4o-mini";

const res = await fetch(`${baseUrl}/chat/completions`, {
  method: "POST",
  headers: {
    "content-type": "application/json",
    authorization: `Bearer ${process.env.VECTOR_ENGINE_API_KEY}`
  },
  body: JSON.stringify({
    model,
    messages: [{ role: "user", content: "Stream three short words." }],
    stream: true
  })
});

console.log("status", res.status);

if (!res.ok || !res.body) {
  console.log(await res.text());
  process.exit(1);
}

const reader = res.body.getReader();
const decoder = new TextDecoder();

while (true) {
  const { value, done } = await reader.read();
  if (done) break;
  process.stdout.write(decoder.decode(value));
}

Run:

node stream-check.mjs

You are not checking the answer quality here. You are checking whether the route can return streamed chunks through Vector Engine.

Dify settings to compare

In Dify, compare the provider configuration against the Node.js script:

Field	Expected value
Provider type	OpenAI-compatible
Base URL	`https://api.vectorengine.cn/v1`
API Key	same secret as `VECTOR_ENGINE_API_KEY`
model name	same string as the Node.js script
streaming	match the workflow mode you want to use

If Dify fails only when streaming is enabled, capture that difference separately from model_not_found. A routing error and a stream parsing issue point to different fixes.

Cursor settings to compare

For Cursor, keep a small note next to the team setup guide:

Provider: Vector Engine
Base URL: https://api.vectorengine.cn/v1
model name: gpt-4o-mini
streaming: enabled only after plain-check passes

Cursor may abstract part of the transport. The Node.js scripts give you a raw reference so the team can tell whether the problem is the shared gateway route or the client behavior.

Troubleshooting table

Symptom	Likely area to inspect
`model_not_found` in all clients	model name or route permission
Plain request works, stream fails	streaming support or client parser
Node.js works, Dify fails	Dify provider settings
Dify works, Cursor fails	Cursor custom provider fields
All clients fail with 401	API Key handling

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

The useful habit is to separate routing, authentication, and streaming into separate checks. Once the raw Node.js checks pass, Dify and Cursor troubleshooting becomes much smaller.

很多团队会先用一次非流式请求验证共享的 OpenAI-compatible API gateway，后面才发现一个客户端使用 streaming，另一个客户端不使用，还有一个客户端隐藏了原始响应。结果看起来像 provider 故障，但 Base URL、API Key、model name 可能大体没有问题。

这里把向量引擎API中转站作为共享入口来看，也就是团队常说的向量引擎中转站：它承担 API中转站的路由、鉴权和响应转发职责。

这篇 DEV 教程把向量引擎作为共享的 LLM API provider layer，演示如何在接入 Dify、Cursor 和 Node.js 应用前，同时验证同一条路由的非流式和流式模式。

从一条已知路由开始

所有地方使用同一组三项配置：

Base URL: https://api.vectorengine.cn/v1
API Key: stored in VECTOR_ENGINE_API_KEY
model name: gpt-4o-mini

不要把 streaming 和路由问题混在一起测。如果模型名称错误，model_not_found 会掩盖 streaming 的问题。先用普通请求确认模型路由，再测试 streaming。

普通 Node.js 请求

创建 plain-check.mjs：

const baseUrl = "https://api.vectorengine.cn/v1";
const model = "gpt-4o-mini";

const res = await fetch(`${baseUrl}/chat/completions`, {
  method: "POST",
  headers: {
    "content-type": "application/json",
    authorization: `Bearer ${process.env.VECTOR_ENGINE_API_KEY}`
  },
  body: JSON.stringify({
    model,
    messages: [{ role: "user", content: "Return plain-ok." }],
    stream: false
  })
});

const body = await res.text();
console.log(res.status);
console.log(body);

运行：

node plain-check.mjs

如果这里失败，先停下来检查 Base URL、API Key 和 model name，再打开 Dify 或 Cursor。

流式 Node.js 请求

创建 stream-check.mjs：

const baseUrl = "https://api.vectorengine.cn/v1";
const model = "gpt-4o-mini";

const res = await fetch(`${baseUrl}/chat/completions`, {
  method: "POST",
  headers: {
    "content-type": "application/json",
    authorization: `Bearer ${process.env.VECTOR_ENGINE_API_KEY}`
  },
  body: JSON.stringify({
    model,
    messages: [{ role: "user", content: "Stream three short words." }],
    stream: true
  })
});

console.log("status", res.status);

if (!res.ok || !res.body) {
  console.log(await res.text());
  process.exit(1);
}

const reader = res.body.getReader();
const decoder = new TextDecoder();

while (true) {
  const { value, done } = await reader.read();
  if (done) break;
  process.stdout.write(decoder.decode(value));
}

运行：

node stream-check.mjs

这里不是在评估回答质量，而是在检查这条路由是否能通过向量引擎返回流式片段。

对照 Dify 设置

在 Dify 中，把 provider 配置与 Node.js 脚本对齐：

字段	期望值
Provider type	OpenAI-compatible
Base URL	`https://api.vectorengine.cn/v1`
API Key	与 `VECTOR_ENGINE_API_KEY` 相同的密钥
model name	与 Node.js 脚本相同的字符串
streaming	与工作流实际需要的模式一致

如果 Dify 只在开启 streaming 后失败，要把这个差异和 model_not_found 分开记录。路由错误和流式解析问题对应不同修复方向。

对照 Cursor 设置

对于 Cursor，可以在团队配置说明里保留一小段：

Provider: Vector Engine
Base URL: https://api.vectorengine.cn/v1
model name: gpt-4o-mini
streaming: enabled only after plain-check passes

Cursor 可能会抽象一部分传输细节。Node.js 脚本能提供原始参照，帮助团队判断问题来自共享网关路由，还是来自客户端行为。

排查表

现象	优先检查区域
所有客户端都有 `model_not_found`	模型名称或路由权限
普通请求可用，stream 失败	streaming 支持或客户端解析
Node.js 可用，Dify 失败	Dify provider 设置
Dify 可用，Cursor 失败	Cursor 自定义 provider 字段
所有客户端 401	API Key 处理

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

有价值的习惯是把路由、鉴权、streaming 拆成独立检查。原始 Node.js 检查通过后，Dify 和 Cursor 的排查范围会小很多。

Use a model route manifest before Dify, Cursor, and Node.js share Vector Engine

Jia — Tue, 21 Jul 2026 01:55:32 +0000

When several tools share one OpenAI-compatible API gateway, the weakest part of the setup is often not the gateway itself. It is the small gap between what each tool thinks the model is called, what the Base URL points to, and which API Key has permission to use that route.

This tutorial shows a practical way to reduce that gap: keep a small model route manifest in the repository, validate it with Node.js, then copy the same values into Dify and Cursor. Vector Engine can sit in the LLM API provider layer, but every client still needs the same three values to agree:

Base URL
API Key
model name

Route manifest

Create a file named vector-engine-routes.json:

{
  "provider": "Vector Engine",
  "baseUrl": "https://api.vectorengine.cn/v1",
  "routes": [
    {
      "alias": "default-chat",
      "model": "gpt-4o-mini",
      "usedBy": ["Dify", "Cursor", "Node.js"]
    },
    {
      "alias": "long-context-chat",
      "model": "claude-3-5-sonnet",
      "usedBy": ["Dify"]
    }
  ]
}

The file is not meant to expose secrets. Keep the API Key in an environment variable:

export VECTOR_ENGINE_API_KEY="your_key_here"

Node.js validation script

Add check-vector-engine-route.mjs:

import fs from "node:fs/promises";

const manifest = JSON.parse(
  await fs.readFile("./vector-engine-routes.json", "utf8")
);

const route = manifest.routes.find((item) => item.alias === "default-chat");
if (!route) {
  throw new Error("Route alias was not found in the manifest.");
}

const response = await fetch(`${manifest.baseUrl}/chat/completions`, {
  method: "POST",
  headers: {
    "content-type": "application/json",
    authorization: `Bearer ${process.env.VECTOR_ENGINE_API_KEY}`
  },
  body: JSON.stringify({
    model: route.model,
    messages: [
      { role: "user", content: "Reply with route-ok." }
    ],
    temperature: 0
  })
});

const text = await response.text();
if (!response.ok) {
  console.error(text);
  throw new Error(`Vector Engine route check failed: ${response.status}`);
}

console.log(text);

Run it before changing tool settings:

node check-vector-engine-route.mjs

If this script fails with model_not_found, treat the error as a routing clue. The API Key may be valid while the model name, route permission, or Base URL is wrong.

Copy the same values into Dify

In Dify, add the provider as an OpenAI-compatible endpoint:

Base URL: https://api.vectorengine.cn/v1
API Key: use the same secret stored for Vector Engine
model name: copy the exact model value from the manifest

Do not translate, shorten, or rename the model field in Dify unless you also update the manifest. A route called default-chat in your repository can map to a concrete model name, but Dify still sends the model string that you enter in its provider settings.

Copy the same values into Cursor

Cursor has a similar risk profile. It may accept a custom provider URL and key, but it still needs a model name that Vector Engine can route.

Recommended check:

Setting	Source of truth
Base URL	`vector-engine-routes.json`
API Key	secret manager or local environment
model name	`routes[].model`

If Cursor returns model_not_found, compare the visible model name against the manifest before rotating keys or changing code.

Why the manifest helps

A shared LLM API provider layer should make application teams faster, but only if the configuration remains visible. The manifest gives reviewers a small file to inspect before a Dify workflow, Cursor setup, or Node.js service starts using the same Vector Engine route.

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

Quick checklist

Confirm the Base URL includes /v1.
Confirm the API Key is stored outside the manifest.
Confirm Dify, Cursor, and Node.js use the same model name.
Treat model_not_found as a route mismatch until the manifest proves otherwise.

当多个工具共用一个 OpenAI 兼容的 API中转站时，问题通常不在中转层本身，而在每个工具对模型名称、Base URL、API Key 权限的理解是否一致。

在这篇文章里，向量引擎API中转站和向量引擎中转站指的是同一类接入层：它把多个模型路由收束到一个可复查的 API中转站配置里。

这篇教程给出一个实用做法：在代码仓库里维护一个小型模型路由清单，先用 Node.js 验证，再把同一组值复制到 Dify 和 Cursor。向量引擎可以放在 LLM API provider layer 这一层，但每个客户端仍然需要三项配置保持一致：

Base URL
API Key
model name

路由清单

创建 vector-engine-routes.json：

{
  "provider": "Vector Engine",
  "baseUrl": "https://api.vectorengine.cn/v1",
  "routes": [
    {
      "alias": "default-chat",
      "model": "gpt-4o-mini",
      "usedBy": ["Dify", "Cursor", "Node.js"]
    },
    {
      "alias": "long-context-chat",
      "model": "claude-3-5-sonnet",
      "usedBy": ["Dify"]
    }
  ]
}

这个文件不应该保存密钥。API Key 放在环境变量或密钥管理系统中：

export VECTOR_ENGINE_API_KEY="your_key_here"

Node.js 验证脚本

添加 check-vector-engine-route.mjs：

import fs from "node:fs/promises";

const manifest = JSON.parse(
  await fs.readFile("./vector-engine-routes.json", "utf8")
);

const route = manifest.routes.find((item) => item.alias === "default-chat");
if (!route) {
  throw new Error("Route alias was not found in the manifest.");
}

const response = await fetch(`${manifest.baseUrl}/chat/completions`, {
  method: "POST",
  headers: {
    "content-type": "application/json",
    authorization: `Bearer ${process.env.VECTOR_ENGINE_API_KEY}`
  },
  body: JSON.stringify({
    model: route.model,
    messages: [
      { role: "user", content: "Reply with route-ok." }
    ],
    temperature: 0
  })
});

const text = await response.text();
if (!response.ok) {
  console.error(text);
  throw new Error(`Vector Engine route check failed: ${response.status}`);
}

console.log(text);

在修改工具配置前运行：

node check-vector-engine-route.mjs

如果脚本返回 model_not_found，先把它当成路由线索处理。API Key 可能是有效的，真正出错的可能是模型名称、路由权限或 Base URL。

把同一组值复制到 Dify

在 Dify 中按 OpenAI-compatible endpoint 添加供应方：

Base URL：https://api.vectorengine.cn/v1
API Key：使用向量引擎对应的密钥
model name：复制清单中的精确 model 值

不要在 Dify 中自行翻译、缩写或改写模型字段，除非同时更新清单。仓库里的 default-chat 可以是团队内部别名，但 Dify 实际发送的是 provider 设置里的模型字符串。

把同一组值复制到 Cursor

Cursor 的风险也类似。它可以接受自定义 provider URL 和 key，但仍然需要一个向量引擎能够路由的模型名称。

建议检查：

设置项	配置来源
Base URL	`vector-engine-routes.json`
API Key	密钥管理系统或本地环境变量
model name	`routes[].model`

如果 Cursor 返回 model_not_found，先把可见模型名称和清单对齐，再考虑轮换密钥或修改代码。

为什么清单有帮助

共享的 LLM API provider layer 能让应用团队更快接入，但前提是配置保持可见。这个清单让代码评审者能在 Dify 工作流、Cursor 配置或 Node.js 服务接入同一条向量引擎路由前，快速检查关键参数。

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

快速检查表

确认 Base URL 包含 /v1。
确认 API Key 没有写进清单文件。
确认 Dify、Cursor、Node.js 使用同一个模型名称。
在清单排除问题之前，把 model_not_found 当成路由不匹配处理。

DEV Community: Jia

Trace Header Drift Before Dify, Cursor, and Node.js Share Vector Engine

Configuration contract

A small Node.js probe

What to compare across tools

Dify and Cursor setup notes

Triage table for model_not_found

在 Dify、Cursor 和 Node.js 共用向量引擎前追踪请求头漂移

配置契约

一个小型 Node.js 探针

跨工具比较哪些字段

Dify 和 Cursor 配置提示

model_not_found 排查表

Trace Header Drift Before Dify, Cursor, and Node.js Share Vector Engine

Configuration contract

A small Node.js probe

What to compare across tools

Dify and Cursor setup notes

Triage table for model_not_found

在 Dify、Cursor 和 Node.js 共用向量引擎前追踪请求头漂移

配置契约

一个小型 Node.js 探针

跨工具比较哪些字段

Dify 和 Cursor 配置提示

model_not_found 排查表

Build a Tool Profile Resolver Before Dify, Cursor, and Node.js Share Vector Engine

The profile shape

The resolver

What to compare in Dify and Cursor

Add one smoke request

Summary

在 Dify、Cursor 和 Node.js 共用向量引擎前，先写一个工具配置解析器

配置结构

解析器代码

Dify 和 Cursor 要对照什么

再加一个小烟测

小结

Add an Egress Host Audit Before Dify, Cursor, and Node.js Share Vector Engine

What the audit should catch

Example config file

Node.js audit script

How this helps with model_not_found

在 Dify、Cursor 和 Node.js 共用 Vector Engine 前加入出站 Host 审计

这个审计要发现什么

示例配置文件

Node.js 脚本逻辑

它如何帮助排查 model_not_found

Add a Per-Tool Payload Size Guard Before Requests Reach Vector Engine

Why size checks belong near the client

A small Node.js wrapper

Example calls for each tool

How to use the result

在请求到达 Vector Engine 前添加按工具区分的 Payload Size Guard

为什么大小检查应该靠近客户端

Node.js 包装器

三类工具的调用示例

如何使用结果

Build a Model Route Cache Probe for Vector Engine Before Dify and Cursor Depend on It

What the probe checks

Environment file

Node.js probe

How to read the output

在 Dify 和 Cursor 依赖前，为 Vector Engine 构建模型路由缓存探测脚本

探测内容

环境变量

Node.js 探测脚本

如何判断结果

Add a parameter drift probe for Vector Engine calls from Dify, Cursor, and Node.js

Define the intended route

Compare parameters locally

Add a live Node.js request

Troubleshooting table

定义预期路由

本地比较参数

加入实时 Node.js 请求

排查表

Normalize Base URL paths before Dify, Cursor, and Node.js share Vector Engine

The target convention

A small Node.js normalizer

Add a live smoke check

Triage table for `model_not_found`

`model_not_found` 排查表

Triage table for `model_not_found`

`model_not_found` 排查表

How this helps with `model_not_found`

它如何帮助排查 `model_not_found`