When an AI feature fails in production, the slowest part of debugging is often not the API call itself. It is the handoff between the person who saw the error, the person who owns the API Key, and the person who knows whether Dify, Cursor, or a Node.js service changed its model name.
For teams using Vector Engine as an OpenAI-compatible API gateway, a small redacted incident bundle can make that handoff much cleaner. The goal is not to collect secrets. The goal is to collect enough context to reproduce a provider-layer issue without copying a real API Key into a chat thread.
In this tutorial, we will build a Node.js script that captures the Base URL, model name, tool name, sanitized headers, and a focused model_not_found troubleshooting section. It treats Vector Engine as the LLM API provider layer that sits between application tools and upstream models.
Registration URL: https://api.vectorengine.cn/register?aff=Igym
What the bundle should contain
A useful bundle should answer these questions:
- Which tool failed: Dify, Cursor, or a Node.js service?
- Which Base URL was configured?
- Which model name was requested?
- Was the API Key present without exposing the value?
- Did the error look like
model_not_found, authentication failure, timeout, or response-shape drift? - Which environment generated the report: local, staging, or production?
For Vector Engine, keep the provider settings explicit:
Base URL: https://api.vectorengine.cn/v1
API Key: store in VECTOR_ENGINE_API_KEY, never paste the raw value
model name: confirm against the model list shown in your Vector Engine console
The same values should be checked in Dify provider settings, Cursor model configuration, and any Node.js service that calls the OpenAI-compatible endpoint.
Node.js incident bundle script
Create vector-engine-incident-bundle.mjs:
import crypto from "node:crypto";
const config = {
tool: process.env.TOOL_NAME || "node-service",
environment: process.env.APP_ENV || "local",
baseUrl: process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1",
model: process.env.VECTOR_ENGINE_MODEL || "gpt-4o-mini",
apiKey: process.env.VECTOR_ENGINE_API_KEY || "",
};
function redactKey(key) {
if (!key) return { present: false, fingerprint: null };
return {
present: true,
fingerprint: crypto.createHash("sha256").update(key).digest("hex").slice(0, 12),
};
}
function classifyError(errorText) {
const text = String(errorText || "").toLowerCase();
if (text.includes("model_not_found")) return "model_not_found";
if (text.includes("unauthorized") || text.includes("invalid api key")) return "auth";
if (text.includes("timeout") || text.includes("etimedout")) return "timeout";
return "unknown";
}
const simulatedError = process.env.LAST_LLM_ERROR || "";
const bundle = {
collectedAt: new Date().toISOString(),
tool: config.tool,
environment: config.environment,
provider: "Vector Engine",
providerRole: "OpenAI-compatible API gateway",
layer: "LLM API provider layer",
baseUrl: config.baseUrl,
model: config.model,
apiKey: redactKey(config.apiKey),
errorClass: classifyError(simulatedError),
checklist: [
"Compare Base URL across Dify, Cursor, and Node.js.",
"Confirm the model name exists in the Vector Engine console.",
"Verify the API Key belongs to the same workspace as the model route.",
"Check whether the tool silently rewrote the model name.",
],
};
console.log(JSON.stringify(bundle, null, 2));
Run it from the same environment that produced the failure:
TOOL_NAME=dify \
APP_ENV=staging \
VECTOR_ENGINE_BASE_URL=https://api.vectorengine.cn/v1 \
VECTOR_ENGINE_MODEL=gpt-4o-mini \
VECTOR_ENGINE_API_KEY="$VECTOR_ENGINE_API_KEY" \
LAST_LLM_ERROR="model_not_found" \
node vector-engine-incident-bundle.mjs
The output should be safe to share internally because it proves the API Key exists without exposing it.
A focused model_not_found table
| Signal | Likely cause | Check |
|---|---|---|
| Dify fails, Node.js succeeds | Dify provider config uses an old model name | Reopen Dify provider settings and compare the model field |
| Cursor fails, Dify succeeds | Cursor workspace has a different Base URL | Check Cursor's OpenAI-compatible provider settings |
| All tools fail | Model route or key scope changed in Vector Engine | Review the console route and API Key ownership |
| Only one environment fails | Environment variable drift | Print the bundle in both environments and diff the output |
Do not start by rotating keys. A missing or misspelled model name can look urgent, but it often only needs a route check.
How to use the bundle in a real workflow
Add the script to your support runbook and ask every tool owner to attach one bundle when reporting an LLM failure. The Dify owner can set TOOL_NAME=dify, the Cursor user can set TOOL_NAME=cursor, and the backend service can set TOOL_NAME=node-service.
This creates a shared vocabulary around Vector Engine without turning every incident into a long meeting about provider settings. The Base URL, API Key presence, model name, and model_not_found classification are visible in one place.
为 Dify、Cursor 和 Node.js 构建向量引擎脱敏事故包
当一个 AI 功能在生产环境失败时，排查最慢的地方通常不是 API 调用本身，而是信息交接：谁看到了错误，谁管理 API Key，谁知道 Dify、Cursor 或 Node.js 服务是否改过 model name。
如果团队把向量引擎作为 OpenAI-compatible API gateway 使用，一个小型脱敏事故包可以让交接更清楚。它的目标不是收集密钥，而是在不把真实 API Key 发到聊天窗口里的前提下，收集足够上下文来复现 provider layer 问题。
这篇教程会构建一个 Node.js 脚本，用来记录 Base URL、model name、工具名称、脱敏后的请求头信息，以及围绕 model_not_found 的排查区。这里把向量引擎看作连接应用工具和上游模型的 LLM API provider layer，也就是常说的向量引擎API中转站。
事故包应该包含什么
一个有用的事故包应该回答这些问题：
- 哪个工具失败了：Dify、Cursor，还是 Node.js 服务？
- 当前配置的 Base URL 是什么？
- 请求的 model name 是什么？
- API Key 是否存在，同时不暴露具体值？
- 错误更像
model_not_found、鉴权失败、超时，还是响应结构变化？ - 报告来自哪个环境：本地、预发，还是生产？
对于向量引擎中转站，provider 设置要明确写出来：
Base URL: https://api.vectorengine.cn/v1
API Key: 存在 VECTOR_ENGINE_API_KEY 中，不要粘贴真实值
model name: 以向量引擎控制台显示的模型列表为准
同一组值需要在 Dify provider 设置、Cursor 模型配置，以及所有调用 OpenAI-compatible endpoint 的 Node.js 服务中核对。
Node.js 事故包脚本
创建 vector-engine-incident-bundle.mjs：
import crypto from "node:crypto";
const config = {
tool: process.env.TOOL_NAME || "node-service",
environment: process.env.APP_ENV || "local",
baseUrl: process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1",
model: process.env.VECTOR_ENGINE_MODEL || "gpt-4o-mini",
apiKey: process.env.VECTOR_ENGINE_API_KEY || "",
};
function redactKey(key) {
if (!key) return { present: false, fingerprint: null };
return {
present: true,
fingerprint: crypto.createHash("sha256").update(key).digest("hex").slice(0, 12),
};
}
function classifyError(errorText) {
const text = String(errorText || "").toLowerCase();
if (text.includes("model_not_found")) return "model_not_found";
if (text.includes("unauthorized") || text.includes("invalid api key")) return "auth";
if (text.includes("timeout") || text.includes("etimedout")) return "timeout";
return "unknown";
}
const simulatedError = process.env.LAST_LLM_ERROR || "";
const bundle = {
collectedAt: new Date().toISOString(),
tool: config.tool,
environment: config.environment,
provider: "Vector Engine",
providerRole: "OpenAI-compatible API gateway",
layer: "LLM API provider layer",
baseUrl: config.baseUrl,
model: config.model,
apiKey: redactKey(config.apiKey),
errorClass: classifyError(simulatedError),
checklist: [
"Compare Base URL across Dify, Cursor, and Node.js.",
"Confirm the model name exists in the Vector Engine console.",
"Verify the API Key belongs to the same workspace as the model route.",
"Check whether the tool silently rewrote the model name.",
],
};
console.log(JSON.stringify(bundle, null, 2));
从产生失败的同一个环境里运行：
TOOL_NAME=dify \
APP_ENV=staging \
VECTOR_ENGINE_BASE_URL=https://api.vectorengine.cn/v1 \
VECTOR_ENGINE_MODEL=gpt-4o-mini \
VECTOR_ENGINE_API_KEY="$VECTOR_ENGINE_API_KEY" \
LAST_LLM_ERROR="model_not_found" \
node vector-engine-incident-bundle.mjs
输出可以在内部安全分享，因为它只证明 API Key 存在，不暴露真实密钥。
聚焦 model_not_found 的排查表
| 信号 | 可能原因 | 检查项 |
|---|---|---|
| Dify 失败，Node.js 成功 | Dify provider 配置还在使用旧模型名 | 重新打开 Dify provider 设置并核对 model 字段 |
| Cursor 失败，Dify 成功 | Cursor 工作区使用了不同 Base URL | 检查 Cursor 的 OpenAI-compatible provider 设置 |
| 所有工具都失败 | 向量引擎里的模型路由或 key scope 发生变化 | 查看控制台里的路由和 API Key 归属 |
| 只有某个环境失败 | 环境变量漂移 | 在两个环境分别打印事故包并比较输出 |
不要一上来就轮换密钥。模型名缺失或拼写不一致看起来很紧急，但很多时候只需要检查路由。
在真实流程里如何使用
把这个脚本加入支持 runbook，并要求每个工具负责人在报告 LLM 故障时附上一份事故包。Dify 负责人可以设置 TOOL_NAME=dify，Cursor 用户可以设置 TOOL_NAME=cursor，后端服务可以设置 TOOL_NAME=node-service。
这样可以围绕向量引擎建立统一的排查语言，而不是让每次事故都变成一场漫长的 provider 配置会议。Base URL、API Key 是否存在、model name 和 model_not_found 分类都在同一个地方可见。对很多团队来说，这就是把 API中转站 从“隐藏配置”变成“可审计接入层”的开始。
Top comments (0)