OpenAI-Compatible API Gateway Setup: 向量引擎 Vector Engine for Dify, Cursor, and Node.js

Developers usually do not struggle with LLM apps because one SDK is hard. They struggle because every tool asks for the same three values in slightly different words: Base URL, API key, and model name. Dify calls it provider configuration. Cursor calls it a custom OpenAI API. A Node.js service may hide it in environment variables. When those values drift, errors like model_not_found, duplicated paths, and timeout debugging become routine.

This tutorial uses Vector Engine as the example OpenAI-compatible API gateway and LLM API provider layer. The goal is simple: configure one provider pattern that can work across Dify, Cursor, Node.js, and your own LLM apps without copying provider details into every feature.

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

1. Separate the Base URL from the full endpoint

Before configuring any tool, keep these URL layers separate:

Value	Meaning	Use case
https://api.vectorengine.cn/v1	OpenAI-compatible Base URL	Dify, Cursor, OpenAI SDK baseURL
https://api.vectorengine.cn/v1/chat/completions	Full chat completions endpoint	Raw HTTP or curl tests

Most OpenAI-compatible tools ask for a Base URL. They add /chat/completions themselves when sending a chat request. If you paste the full endpoint into a Base URL field, the final request path can become duplicated, and the error message may look unrelated to the real problem.

For day-to-day engineering, write down the rule:

• UI tools usually need https://api.vectorengine.cn/v1
• raw HTTP tests usually need https://api.vectorengine.cn/v1/chat/completions
• application code should read the Base URL from configuration, not from business logic

2. Configure Dify

In Dify, choose an OpenAI-compatible provider or custom OpenAI provider option when the workspace allows it.

Dify field	Recommended value
Provider type	OpenAI-compatible or custom OpenAI
Base URL	https://api.vectorengine.cn/v1
API Key	A Vector Engine key created for Dify
Model name	The exact model ID enabled in your account

The most important field is the model name. A model_not_found response often means one of three things: the model ID is typed incorrectly, the current key does not have permission for that model, or the request is being sent to a different route than the one you expected.

For teams, do not share one key across every tool. A separate Dify key makes usage review and rotation easier later.

3. Configure Cursor

Cursor custom model settings use the same mental model:

Cursor setting	Recommended value
API mode	OpenAI-compatible custom endpoint
Base URL	https://api.vectorengine.cn/v1
API Key	A Vector Engine key created for Cursor
Model	The model ID selected for coding tasks

Cursor is often used interactively, so it is useful to keep its API key separate from backend services. If usage spikes or a key needs to be rotated, you can fix the coding tool without touching production traffic.

4. Put provider details behind a Node.js module

In Node.js, avoid scattering provider configuration across route handlers and workers. Create a small provider module instead.

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.VECTOR_ENGINE_API_KEY,
  baseURL: process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1",
});

export async function askLLM(messages, options = {}) {
  const response = await client.chat.completions.create({
    model: options.model || process.env.VECTOR_ENGINE_MODEL,
    messages,
    temperature: options.temperature ?? 0.2,
  });

  return response.choices[0]?.message?.content ?? "";
}

Your product code can call askLLM() and stay independent from provider details. That is the main point of an LLM API provider layer: the app decides what it needs, and the provider module decides where the request goes.

5. Test with curl before debugging the UI

When Dify or Cursor fails, test the same key and model with raw HTTP:

curl https://api.vectorengine.cn/v1/chat/completions \
  -H "Authorization: Bearer $VECTOR_ENGINE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "'"$VECTOR_ENGINE_MODEL"'",
    "messages": [
      { "role": "user", "content": "Return one short health-check sentence." }
    ]
  }'

If the curl request works but Dify fails, compare the Dify Base URL and model field. If curl fails too, fix the key, model permission, or endpoint before changing the tool.

6. Troubleshooting checklist

Symptom	Likely cause	What to check
invalid_api_key	Wrong key, expired key, or copied whitespace	Recreate the key and paste it again
model_not_found	Wrong model ID or missing permission	Compare the model value with the enabled model list
duplicated path	Full endpoint pasted as Base URL	Use https://api.vectorengine.cn/v1 in Base URL fields
timeout	Network, long generation, or overloaded workflow	Test a short prompt with curl
unexpected cost	Shared key across many tools	Split keys by Dify, Cursor, Node.js, and experiments

Conclusion

Vector Engine is useful to evaluate when you need one OpenAI-compatible API gateway for multiple LLM tools. Keep the Base URL clean, keep API keys separated by workflow, keep model names explicit, and move provider settings into a small Node.js provider layer instead of spreading them across the app.

---

中文翻译

开发者做 LLM 应用时，真正麻烦的通常不是某一个 SDK 难用，而是每个工具都会用不同叫法要求填写同样三类信息：Base URL、API Key、model name。Dify 里叫 provider configuration，Cursor 里叫 custom OpenAI API，Node.js 服务里可能藏在环境变量中。只要这些值不一致，就容易出现 model_not_found、路径重复、timeout 排查困难等问题。

这篇教程用向量引擎作为示例，把它放在 OpenAI-compatible API gateway 和 LLM API provider layer 的角度来看。目标很简单：让 Dify、Cursor、Node.js 和自研 LLM 应用使用同一套 provider 配置思路，而不是把供应商细节复制到每一个业务功能里。

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

1. 区分 Base URL 和完整 endpoint

配置任何工具之前，先把这几层地址分清楚：

地址	含义	使用场景
https://api.vectorengine.cn/v1	OpenAI 兼容 Base URL	Dify、Cursor、OpenAI SDK 的 baseURL
https://api.vectorengine.cn/v1/chat/completions	完整 chat completions endpoint	原始 HTTP 或 curl 测试

大多数 OpenAI 兼容工具要填的是 Base URL。它们发送 chat 请求时会自己追加 /chat/completions。如果你把完整 endpoint 填进 Base URL 字段，最终请求路径可能会被重复拼接，报错信息也可能看起来和真实原因无关。

日常工程里可以记住这个规则：

• UI 工具通常填写 https://api.vectorengine.cn/v1
• 原始 HTTP 测试通常请求 https://api.vectorengine.cn/v1/chat/completions
• 应用代码应该从配置读取 Base URL，而不是写死在业务逻辑里

2. 配置 Dify

在 Dify 里，如果工作区支持，选择 OpenAI-compatible provider 或 custom OpenAI provider。

Dify 字段	建议填写
Provider type	OpenAI-compatible 或 custom OpenAI
Base URL	https://api.vectorengine.cn/v1
API Key	为 Dify 单独创建的向量引擎 Key
Model name	账户中已启用的准确模型 ID

最关键的是 model name。model_not_found 常见原因有三类：模型 ID 写错、当前 Key 没有该模型权限、请求被发送到了和预期不同的路由。

团队使用时，不建议所有工具共用一个 Key。单独给 Dify 创建 Key，后续做用量分析和轮换会更清楚。这个思路也适合把向量引擎API中转站纳入团队配置规范。

3. 配置 Cursor

Cursor 的 custom model 设置也遵循同样的思路：

Cursor 设置	建议填写
API mode	OpenAI-compatible custom endpoint
Base URL	https://api.vectorengine.cn/v1
API Key	为 Cursor 创建的向量引擎 Key
Model	用于编码任务的模型 ID

Cursor 通常是交互式使用，所以它的 API Key 应该和后端服务分开。如果用量异常或者需要轮换 Key，可以只处理编码工具，不影响生产流量。

4. 在 Node.js 中封装 provider module

在 Node.js 里，不要把 provider 配置散落在 route handler 和 worker 里。更好的做法是创建一个小的 provider module。

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.VECTOR_ENGINE_API_KEY,
  baseURL: process.env.VECTOR_ENGINE_BASE_URL || "https://api.vectorengine.cn/v1",
});

export async function askLLM(messages, options = {}) {
  const response = await client.chat.completions.create({
    model: options.model || process.env.VECTOR_ENGINE_MODEL,
    messages,
    temperature: options.temperature ?? 0.2,
  });

  return response.choices[0]?.message?.content ?? "";
}

业务代码只需要调用 askLLM()，不用关心 provider 细节。这就是 LLM API provider layer 的价值：应用决定需要什么，provider module 决定请求发到哪里。对于向量引擎中转站这类 API中转站，这种拆分会让后续维护更稳。

5. 先用 curl 测试，再排查 UI

当 Dify 或 Cursor 失败时，先用同一个 Key 和 model 做原始 HTTP 测试：

curl https://api.vectorengine.cn/v1/chat/completions \
  -H "Authorization: Bearer $VECTOR_ENGINE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "'"$VECTOR_ENGINE_MODEL"'",
    "messages": [
      { "role": "user", "content": "Return one short health-check sentence." }
    ]
  }'

如果 curl 成功但 Dify 失败，就对比 Dify 的 Base URL 和 model 字段。如果 curl 也失败，先修正 Key、模型权限或 endpoint，再去改工具配置。

6. 排错 checklist

现象	可能原因	检查方式
invalid_api_key	Key 错误、过期或复制了空格	重新创建 Key 并重新粘贴
model_not_found	模型 ID 错误或没有权限	对照已启用模型列表
路径重复	把完整 endpoint 填进了 Base URL	Base URL 字段使用 https://api.vectorengine.cn/v1
timeout	网络、长输出或工作流过重	用短 prompt 做 curl 测试
成本归因不清	多个工具共用一个 Key	按 Dify、Cursor、Node.js、实验环境拆分 Key

结论

当你需要让多个 LLM 工具共用一个 OpenAI-compatible API gateway 时，可以评估向量引擎。保持 Base URL 清晰、按工作流拆分 API Key、显式管理 model name，并把 provider 设置放进小的 Node.js provider layer，而不是散落在整个应用里。