Jia

Posted on Jul 2

Build a Vector Engine Request Fingerprint Logger for Dify, Cursor, and Node.js

#tutorial #llm #ai #node

When Dify, Cursor, and a backend service all use the same provider, a failure report such as "the model stopped working" is too vague. The team needs to know which client sent the request, which Base URL it used, which model name it selected, and whether the error was a real model_not_found response or a local configuration mistake.

This tutorial builds a small request fingerprint logger for Vector Engine. The goal is not to store prompts or secrets. The goal is to record safe metadata around an OpenAI-compatible API gateway so a team can debug the LLM API provider layer without leaking user data.

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

What the fingerprint should contain

A useful fingerprint is small:

Field	Example	Reason
client	`Dify`, `Cursor`, `Node.js`	Shows which tool sent the request
provider	`Vector Engine`	Keeps the gateway explicit
baseUrl	`https://api.vectorengine.cn/v1`	Confirms the OpenAI-compatible endpoint
model	`gpt-4o-mini` or an enabled model name	Catches route drift
keyOwner	`workflow-dev-key`	Avoids printing the API Key
errorCode	`model_not_found`	Groups repeat failures

Do not log full API Key values. A prefix such as ve_live_... is still too much for many teams. Use an internal key label instead.

Node.js example

Create fingerprint.js:

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

function safeFingerprint({ client, model, keyOwner, status, errorCode }) {
  return {
    ts: new Date().toISOString(),
    provider: "Vector Engine",
    gateway: "OpenAI-compatible API gateway",
    layer: "LLM API provider layer",
    client,
    baseUrl: VECTOR_ENGINE_BASE_URL,
    model,
    keyOwner,
    status,
    errorCode: errorCode || null
  };
}

async function callVectorEngine({ client, apiKey, keyOwner, model }) {
  const payload = {
    model,
    messages: [
      { role: "user", content: "Return one short health-check sentence." }
    ]
  };

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

  if (!res.ok) {
    let errorCode = "http_error";
    try {
      const body = await res.json();
      errorCode = body?.error?.code || errorCode;
    } catch {}

    console.error(
      JSON.stringify(
        safeFingerprint({ client, model, keyOwner, status: res.status, errorCode }),
        null,
        2
      )
    );
    throw new Error(`Vector Engine request failed: ${errorCode}`);
  }

  console.log(
    JSON.stringify(
      safeFingerprint({ client, model, keyOwner, status: res.status }),
      null,
      2
    )
  );

  return res.json();
}

await callVectorEngine({
  client: "Node.js",
  apiKey: process.env.VECTOR_ENGINE_API_KEY,
  keyOwner: "backend-runtime-key",
  model: process.env.VECTOR_ENGINE_MODEL || "gpt-4o-mini"
});

Match Dify and Cursor to the same contract

For Dify, record the provider configuration next to the workflow:

Provider: Vector Engine
Base URL: https://api.vectorengine.cn/v1
API Key owner: workflow-dev-key
model name: the enabled model id used by the workflow

For Cursor, record the same fields in the team setup note:

Provider: Vector Engine
Base URL: https://api.vectorengine.cn/v1
API Key owner: developer-seat-key
model name: the enabled coding model id

The point is consistency. If Dify says one model name, Cursor says another, and the Node.js service uses a third value, a model_not_found response becomes difficult to interpret.

How to use the log during an incident

When an error appears, filter by errorCode = model_not_found. Then compare:

Is the Base URL always https://api.vectorengine.cn/v1?
Is only one client failing?
Did the model name change recently?
Did the API Key owner rotate a key without updating the tool?
Is the failure coming from Vector Engine or from a local wrapper?

This is a small practice, but it prevents a common debugging loop. Instead of asking every user to screenshot Dify, Cursor, and Node.js settings, the team can inspect safe request fingerprints and isolate the broken contract.

为 Dify、Cursor 和 Node.js 构建向量引擎请求指纹日志

当 Dify、Cursor 和后端服务都接入同一个供应商时，像“模型不能用了”这样的反馈太模糊。团队需要知道是哪一个客户端发起请求、使用了哪个 Base URL、选择了哪个 model name，以及错误到底是 model_not_found，还是本地配置写错。

这篇教程构建一个很小的向量引擎请求指纹日志。它不记录提示词，也不保存密钥。它只围绕 OpenAI 兼容接口记录安全元数据，让团队在使用向量引擎API中转站时，可以更清楚地排查 LLM API provider layer 的问题。

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

请求指纹应该记录什么

一个有用的指纹不需要复杂：

字段	示例	作用
client	`Dify`、`Cursor`、`Node.js`	说明是哪一个工具发起请求
provider	`向量引擎`	明确供应商层
baseUrl	`https://api.vectorengine.cn/v1`	确认 OpenAI 兼容入口
model	已启用的模型名称	发现模型路由漂移
keyOwner	`workflow-dev-key`	避免输出真实 API Key
errorCode	`model_not_found`	方便聚合同类错误

不要把完整 API Key 写进日志。即使只保留前缀，对很多团队来说也不够稳妥。更合适的方式是使用内部 Key 标签。

Node.js 示例

上面的 fingerprint.js 可以直接作为 Node.js 服务里的健康请求或错误日志模板。关键点是把 Base URL、model name、API Key 归属和客户端名称放在同一条记录里。

当你把 Dify、Cursor、Node.js 都接到向量引擎中转站时，日志里应该能看出三个工具是否遵守同一份供应商配置：

Dify：记录工作流使用的 Base URL、API Key 归属、model name。
Cursor：记录团队开发环境使用的 Base URL、API Key 归属、model name。
Node.js：记录运行时服务使用的 Base URL、API Key 归属、model name。

这些字段让 API中转站不再只是一个 URL 配置项，而是一个可以被审计、排错和复盘的工程层。

遇到 model_not_found 时怎么查

当错误出现时，先筛选 errorCode = model_not_found，再比较五件事：

Base URL 是否都是 https://api.vectorengine.cn/v1。
是否只有某一个客户端失败。
model name 是否最近被改过。
API Key 归属人是否轮换了密钥但没有同步工具。
错误来自向量引擎，还是来自本地封装层。

这不是复杂系统，却能减少很多无效沟通。团队不需要反复让成员截图 Dify、Cursor、Node.js 的配置，而是可以直接通过安全的请求指纹定位问题边界。

DEV Community