Build a Per-Tool Header Audit for Vector Engine Across Dify, Cursor, and Node.js

When a team moves several tools behind Vector Engine, the confusing failures are rarely caused by the HTTP request alone. The same OpenAI-compatible API gateway can be called by Dify, Cursor, and a custom Node.js service, but each tool may hide a different Base URL, API Key source, model name, or retry setting. A small header audit makes the LLM API provider layer easier to operate without exposing secrets.

This tutorial builds a Node.js middleware that records safe request metadata before a request reaches Vector Engine. It does not log prompts, API Key values, or response text. It only captures the fields that help a developer tell whether a failure came from configuration drift, a missing route, or a real provider-side error such as model_not_found.

What the audit should answer

The audit should make these questions easy to answer during a rollout:

Question	Safe signal to record	What to avoid
Which tool sent the request?	x-tool-origin: dify, cursor, or node-service	User prompt content
Which route was expected?	Normalized model name	Raw API Key
Which endpoint was used?	Base URL host label or environment name	Full secret-bearing URL
Is the caller configured?	Boolean API Key presence	API Key value
How did the gateway respond?	Status code and error code	Completion output

The point is not to turn Vector Engine into a logging product. The point is to keep a small operational trail when Dify, Cursor, and Node.js all use the same provider layer.

Configuration contract

Use explicit names for the settings that matter:

VECTOR_ENGINE_BASE_URL=https://your-vector-engine-base-url/v1
VECTOR_ENGINE_API_KEY=replace-with-your-key
VECTOR_ENGINE_MODEL=gpt-4.1-mini
TOOL_ORIGIN=node-service

In Dify, keep the same Base URL and model name in the provider settings. In Cursor, keep the Base URL and API Key in the model provider configuration. In Node.js, read them from environment variables so the service can be checked during deployment.

Node.js audit middleware

The example below uses plain fetch so it can fit into Express, Fastify, a worker, or a command-line probe.

const baseUrl = process.env.VECTOR_ENGINE_BASE_URL;
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL;
const toolOrigin = process.env.TOOL_ORIGIN || "node-service";

function auditRecord({ status, errorCode }) {
  return {
    time: new Date().toISOString(),
    provider: "Vector Engine",
    gatewayRole: "OpenAI-compatible API gateway",
    toolOrigin,
    baseUrlConfigured: Boolean(baseUrl),
    apiKeyPresent: Boolean(apiKey),
    model,
    status,
    errorCode
  };
}

async function callVectorEngine(messages) {
  if (!baseUrl || !apiKey || !model) {
    console.error(auditRecord({ status: "not_sent", errorCode: "local_config_missing" }));
    throw new Error("Vector Engine configuration is incomplete");
  }

  const response = await fetch(`${baseUrl}/chat/completions`, {
    method: "POST",
    headers: {
      "content-type": "application/json",
      "authorization": `Bearer ${apiKey}`,
      "x-tool-origin": toolOrigin
    },
    body: JSON.stringify({
      model,
      messages,
      temperature: 0.2
    })
  });

  const payload = await response.json().catch(() => ({}));
  const errorCode = payload?.error?.code || payload?.code || null;
  console.error(auditRecord({ status: response.status, errorCode }));

  if (!response.ok) {
    throw new Error(`Vector Engine request failed: ${errorCode || response.status}`);
  }

  return payload;
}

How to use it with Dify and Cursor

For Dify, add a short workflow note that names the expected Base URL, model name, and owner of the API Key. If Dify returns an error after a provider change, compare the workflow configuration with the Node.js audit record before changing the model again.

For Cursor, keep a simple table in the repository:

| Tool | Base URL owner | API Key owner | Model name | Expected origin |
| --- | --- | --- | --- | --- |
| Dify | Platform team | Workflow owner | gpt-4.1-mini | dify |
| Cursor | Engineering lead | Individual user | gpt-4.1-mini | cursor |
| Node.js service | Service owner | Secret manager | gpt-4.1-mini | node-service |

This gives developers a shared language when the same Vector Engine route behaves differently across tools.

model_not_found triage

When the error code is model_not_found, check these items in order:

Check	Why it matters
Model spelling	Dify, Cursor, and Node.js may use slightly different aliases
Base URL environment	A staging Base URL may not expose the same route as production
API Key scope	A key can be valid but not allowed to call a specific model
Route owner	The model may have been retired or renamed inside the provider layer

If all four checks pass, escalate with the audit record, request time, and model name. Do not include the API Key or prompt.

Registration

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

Closing note

A per-tool header audit is small, but it removes a lot of guessing. Vector Engine can serve as the LLM API provider layer for multiple tools, while each team still keeps enough evidence to debug routing, API Key scope, Base URL drift, and model_not_found without leaking sensitive content.

---

为 Dify、Cursor 和 Node.js 构建向量引擎按工具请求头审计

当一个团队把多个工具接入向量引擎时，最难排查的故障通常不只来自 HTTP 请求本身。同一个 OpenAI-compatible API gateway 可以被 Dify、Cursor 和自定义 Node.js 服务调用，但每个工具可能隐藏了不同的 Base URL、API Key 来源、model name 或重试设置。一个小型请求头审计，可以让 LLM API provider layer 更容易运维，同时不暴露密钥。

这篇教程会构建一个 Node.js 中间件，在请求到达 Vector Engine 之前记录安全的请求元数据。它不会记录提示词、API Key 值或响应正文，只记录能帮助开发者判断故障来源的字段：配置漂移、缺少路由，或真实的提供方错误，例如 model_not_found。

审计应该回答什么问题

审计要让这些问题在上线期间更容易回答：

问题	可以记录的安全信号	应避免记录
哪个工具发出了请求？	x-tool-origin：dify、cursor 或 node-service	用户提示词内容
期望调用哪条路由？	规范化后的模型名称	原始 API Key
使用了哪个入口？	Base URL 环境标签或主机标签	带密钥的完整 URL
调用方是否配置完整？	API Key 是否存在的布尔值	API Key 值
网关如何响应？	状态码和错误码	模型输出内容

这里的目标不是把向量引擎变成日志系统，而是在 Dify、Cursor 和 Node.js 同时使用同一个提供方层时，保留一条小而清晰的运维线索。

配置契约

关键设置要用明确的变量名：

VECTOR_ENGINE_BASE_URL=https://your-vector-engine-base-url/v1
VECTOR_ENGINE_API_KEY=replace-with-your-key
VECTOR_ENGINE_MODEL=gpt-4.1-mini
TOOL_ORIGIN=node-service

在 Dify 中，把相同的 Base URL 和模型名称放到提供方设置里。在 Cursor 中，把 Base URL 和 API Key 放到模型提供方配置里。在 Node.js 中，从环境变量读取这些值，便于服务在部署阶段被检查。

Node.js 审计中间件

下面的例子使用原生 fetch，可以放进 Express、Fastify、worker 或命令行探针。

const baseUrl = process.env.VECTOR_ENGINE_BASE_URL;
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL;
const toolOrigin = process.env.TOOL_ORIGIN || "node-service";

function auditRecord({ status, errorCode }) {
  return {
    time: new Date().toISOString(),
    provider: "Vector Engine",
    gatewayRole: "OpenAI-compatible API gateway",
    toolOrigin,
    baseUrlConfigured: Boolean(baseUrl),
    apiKeyPresent: Boolean(apiKey),
    model,
    status,
    errorCode
  };
}

async function callVectorEngine(messages) {
  if (!baseUrl || !apiKey || !model) {
    console.error(auditRecord({ status: "not_sent", errorCode: "local_config_missing" }));
    throw new Error("Vector Engine configuration is incomplete");
  }

  const response = await fetch(`${baseUrl}/chat/completions`, {
    method: "POST",
    headers: {
      "content-type": "application/json",
      "authorization": `Bearer ${apiKey}`,
      "x-tool-origin": toolOrigin
    },
    body: JSON.stringify({
      model,
      messages,
      temperature: 0.2
    })
  });

  const payload = await response.json().catch(() => ({}));
  const errorCode = payload?.error?.code || payload?.code || null;
  console.error(auditRecord({ status: response.status, errorCode }));

  if (!response.ok) {
    throw new Error(`Vector Engine request failed: ${errorCode || response.status}`);
  }

  return payload;
}

如何配合 Dify 和 Cursor 使用

对 Dify，可以在工作流说明里写清楚预期的 Base URL、模型名称和 API Key 负责人。如果提供方变更后 Dify 返回错误，先把工作流配置和 Node.js 审计记录对齐，再决定是否调整模型。

对 Cursor，可以在仓库中保留一张简单表格：

| 工具 | Base URL 负责人 | API Key 负责人 | 模型名称 | 预期来源 |
| --- | --- | --- | --- | --- |
| Dify | 平台团队 | 工作流负责人 | gpt-4.1-mini | dify |
| Cursor | 工程负责人 | 个人用户 | gpt-4.1-mini | cursor |
| Node.js 服务 | 服务负责人 | 密钥管理系统 | gpt-4.1-mini | node-service |

这能让开发者在同一条向量引擎路由于不同工具中表现不一致时，有一套共同语言。

model_not_found 排查

当错误码是 model_not_found 时，按下面顺序检查：

检查项	为什么重要
模型拼写	Dify、Cursor 和 Node.js 可能使用了略有差异的别名
Base URL 环境	测试环境入口可能没有开放与生产一致的路由
API Key 范围	Key 本身有效，但可能无权调用某个模型
路由负责人	模型可能已在提供方层被下线或改名

如果四项都通过，再带上审计记录、请求时间和模型名称升级处理。不要包含 API Key 或提示词。

注册

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

结语

按工具请求头审计很小，但能减少大量猜测。向量引擎可以作为多个工具共享的 LLM API provider layer，而每个团队仍然能保留足够证据，去排查路由、API Key 范围、Base URL 漂移和 model_not_found，同时避免泄露敏感内容。向量引擎API中转站、向量引擎中转站和 API中转站 的价值，只有在这些边界被记录清楚之后，才会在真实工程协作中体现出来。