Keep Dify, Cursor, and Node.js Aligned with a Vector Engine Route Manifest

Configuration drift is easy to miss when AI tools are added one by one. A Dify workflow may use one model name, Cursor may use another, and a Node.js worker may keep an old environment variable. The system works until a release changes one route and another tool starts returning model_not_found.

This tutorial uses a route manifest to keep Vector Engine configuration explicit across Dify, Cursor, and Node.js. Vector Engine works as an OpenAI-compatible API gateway, but the gateway is only useful when every caller agrees on the same Base URL, API Key boundary, and model name contract.

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

Write the route manifest

Create vector-engine-routes.json:

{
  "provider": "Vector Engine",
  "baseUrl": "https://api.vectorengine.cn/v1",
  "owner": "platform-ai",
  "routes": [
    {
      "name": "daily-assistant",
      "model": "gpt-4o-mini",
      "tools": ["dify", "cursor", "nodejs"],
      "costLabel": "general-ai"
    },
    {
      "name": "support-summary",
      "model": "gpt-4o-mini",
      "tools": ["dify", "nodejs"],
      "costLabel": "support-ops"
    }
  ]
}

The route manifest is not a replacement for provider settings. It is a readable contract for the LLM API provider layer. Tool owners can see which model name they should use before changing a workflow, editor setting, or deployment variable.

Add local tool configuration

Create tool-config.json:

{
  "dify": {
    "baseUrl": "https://api.vectorengine.cn/v1",
    "models": ["gpt-4o-mini"]
  },
  "cursor": {
    "baseUrl": "https://api.vectorengine.cn/v1",
    "models": ["gpt-4o-mini"]
  },
  "nodejs": {
    "baseUrl": "https://api.vectorengine.cn/v1",
    "models": ["gpt-4o-mini"],
    "apiKeyEnv": "VECTOR_ENGINE_API_KEY"
  }
}

Do not store the API Key in this file. The file should confirm that the key has a named environment variable, not the secret value.

Validate the manifest in Node.js

Create check-vector-engine-routes.mjs:

import fs from "node:fs/promises";

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

const failures = [];

for (const [toolName, toolConfig] of Object.entries(tools)) {
  if (toolConfig.baseUrl !== manifest.baseUrl) {
    failures.push(`${toolName}: Base URL differs from the Vector Engine manifest`);
  }
}

for (const route of manifest.routes) {
  for (const toolName of route.tools) {
    const toolConfig = tools[toolName];
    if (!toolConfig) {
      failures.push(`${route.name}: ${toolName} is listed in the manifest but has no local config`);
      continue;
    }

    if (!toolConfig.models.includes(route.model)) {
      failures.push(`${route.name}: ${toolName} does not list model ${route.model}`);
    }
  }
}

if (!process.env.VECTOR_ENGINE_API_KEY) {
  failures.push("nodejs: VECTOR_ENGINE_API_KEY is missing from the runtime environment");
}

if (failures.length) {
  console.error("Vector Engine route manifest check failed:");
  for (const failure of failures) console.error(`- ${failure}`);
  process.exit(1);
}

console.log("Vector Engine route manifest check passed.");

Run it before a tool rollout:

VECTOR_ENGINE_API_KEY="replace-with-your-key" node check-vector-engine-routes.mjs

The script checks static alignment. It will not prove that every model route is currently available, but it catches many mistakes before a request reaches the provider.

Use the manifest during changes

When a model route changes, update the manifest in the same pull request as the tool configuration. The review should answer four questions:

1. Did the Base URL stay pointed at Vector Engine?
2. Did every Dify workflow, Cursor setting, and Node.js service use a listed model name?
3. Is the API Key still scoped to the correct tool or service?
4. If model_not_found appears, who owns the route check?

The route manifest becomes a lightweight review artifact. It gives engineers one place to compare the tool surface with the provider layer.

Add a small CI check

In a repository, run the check during CI:

name: vector-engine-routes
on: [pull_request]
jobs:
  routes:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: node check-vector-engine-routes.mjs
        env:
          VECTOR_ENGINE_API_KEY: present-for-ci

The CI value does not need a real secret if the script only checks presence. For live probes, use a properly scoped test key and keep the output redacted.

Why this pattern works

A route manifest is intentionally small. It does not replace Dify, Cursor, Node.js configuration, or Vector Engine provider settings. It gives the team a shared language:

• Vector Engine is the provider.
• The Base URL is the entry point.
• The API Key has a boundary.
• The model name is a contract.
• model_not_found is a route alignment issue to investigate.

That is often enough to prevent quiet drift from becoming a production incident.

---

用向量引擎路由清单对齐 Dify、Cursor 和 Node.js

当 AI 工具一个接一个接入时，配置漂移很容易被忽略。Dify 工作流可能使用一个 model name，Cursor 可能使用另一个，Node.js worker 可能保留旧环境变量。系统会继续运行，直到某次发布修改了路由，另一个工具开始返回 model_not_found。

这篇教程用 route manifest 显式管理 Dify、Cursor 和 Node.js 的向量引擎配置。向量引擎可以作为 OpenAI 兼容 API 网关使用，但只有当所有调用方都同意同一个 Base URL、API Key 边界和 model name 合同时，这个网关才真正可控。在中文团队语境里，它也常被称为向量引擎API中转站、向量引擎中转站或 API中转站。

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

编写路由清单

可以创建 vector-engine-routes.json，记录 provider、Base URL、owner、route name、model、tools 和 costLabel。

路由清单不是 provider 设置的替代品。它是 LLM API provider layer 的可读合同。工具负责人在修改 Dify workflow、Cursor setting 或部署变量之前，可以先看到应该使用哪个 model name。

添加本地工具配置

tool-config.json 可以记录 Dify、Cursor 和 Node.js 的 Base URL、模型列表以及 Node.js 使用的 API Key 环境变量名。不要把 API Key 存在这个文件里。这个文件只需要确认 key 有明确的环境变量名称，而不是保存 secret value。

用 Node.js 校验清单

Node.js 校验脚本可以读取 route manifest 和 tool config，检查所有工具是否使用同一个向量引擎 Base URL，检查 manifest 中列出的 model name 是否也出现在各工具配置里，并确认 VECTOR_ENGINE_API_KEY 在运行环境中存在。

这个脚本检查静态一致性。它不能证明每条模型路由当前都可用，但能在请求到达 provider 之前拦住很多错误。

在变更中使用清单

当 model route 变化时，把 route manifest 和工具配置放在同一个 pull request 中更新。评审时回答四个问题：

1. Base URL 是否仍然指向向量引擎？
2. 每个 Dify workflow、Cursor setting 和 Node.js service 是否使用清单里的 model name？
3. API Key 是否仍然属于正确工具或服务？
4. 如果出现 model_not_found，谁负责检查路由？

路由清单会成为一个轻量评审材料，让工程师在一个地方比较工具侧和 provider layer。

加入 CI 检查

在仓库里，可以让 CI 在 pull request 中运行 node check-vector-engine-routes.mjs。如果脚本只检查环境变量是否存在，CI 不需要真实密钥。若要做 live probe，则应该使用权限受限的测试 key，并保持输出脱敏。

为什么这个模式有效

route manifest 刻意保持小。它不替代 Dify、Cursor、Node.js 配置，也不替代向量引擎 provider 设置。它只是给团队一个共同语言：

• 向量引擎是 provider。
• Base URL 是入口。
• API Key 有边界。
• model name 是合同。
• model_not_found 是需要排查的路由一致性问题。

这些信息通常足以阻止隐性漂移变成线上事故。