Probe Streaming Compatibility Across Vector Engine, Dify, Cursor, and Node.js

When a team connects several tools to the same provider, normal chat completion tests are not enough. A Dify workflow may rely on streaming output, Cursor may show partial responses in its editor panel, and a Node.js service may forward chunks to a browser client. If only one caller breaks, the result can look like a product issue even when the real cause is a different Base URL, stale API Key, or unsupported model name.

This tutorial builds a small streaming probe for Vector Engine. Vector Engine works as an OpenAI-compatible API gateway and can sit in the LLM API provider layer for Dify, Cursor, and Node.js, but every caller still needs the same connection contract.

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

Define the connection contract

Use one shared contract before testing any tool:

Provider: Vector Engine
Base URL: https://api.vectorengine.cn/v1
API Key: stored in VECTOR_ENGINE_API_KEY
model name: gpt-4o-mini
streaming: enabled

Do not paste the API Key into screenshots, tickets, or examples. For this probe, the only useful fact is whether the key exists and whether the same model name is used by each caller.

Create a Node.js streaming probe

Create probe-vector-engine-stream.mjs:

const baseURL = "https://api.vectorengine.cn/v1";
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL || "gpt-4o-mini";

if (!apiKey) {
  throw new Error("VECTOR_ENGINE_API_KEY is missing");
}

const startedAt = Date.now();

const response = await fetch(`${baseURL}/chat/completions`, {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${apiKey}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model,
    stream: true,
    messages: [
      { role: "system", content: "Return a compact engineering checklist." },
      { role: "user", content: "List three checks before connecting Dify and Cursor." }
    ]
  })
});

console.log(JSON.stringify({
  status: response.status,
  contentType: response.headers.get("content-type"),
  model,
  baseURL,
  elapsedMs: Date.now() - startedAt
}, null, 2));

if (!response.ok) {
  const text = await response.text();
  console.error(text.slice(0, 1000));
  process.exit(1);
}

let chunks = 0;
let preview = "";

for await (const chunk of response.body) {
  chunks += 1;
  preview += new TextDecoder().decode(chunk);
  if (preview.length > 500) break;
}

console.log(JSON.stringify({
  chunks,
  preview: preview.slice(0, 300)
}, null, 2));

Run it with:

VECTOR_ENGINE_API_KEY="your-key" \
VECTOR_ENGINE_MODEL="gpt-4o-mini" \
node probe-vector-engine-stream.mjs

The goal is not to test every prompt. The goal is to prove that the Base URL, API Key, model name, and streaming response format work before Dify or Cursor is blamed.

Compare Dify and Cursor settings

Use this table while checking the tools:

Field	Dify	Cursor	Node.js probe
Base URL	https://api.vectorengine.cn/v1	https://api.vectorengine.cn/v1	baseURL constant
API Key	provider credential	editor/provider setting	VECTOR_ENGINE_API_KEY
model name	workflow model	selected model	VECTOR_ENGINE_MODEL
streaming	workflow response mode	editor response mode	stream: true

If Node.js streams correctly but Dify does not, inspect the workflow response mode and model name. If Cursor fails while Dify and Node.js pass, check the editor provider setting and whether the saved model name differs by one character.

Handle model_not_found

For streaming tests, model_not_found usually comes from one of four places:

Signal	Likely cause	Check
HTTP 404 or provider error	model route is not enabled	compare the model name against the Vector Engine route
Node.js passes, Dify fails	workflow uses an old model value	reopen the provider model setting
Dify passes, Cursor fails	editor has a cached provider entry	remove and re-add the provider setting
all callers fail	shared route or key scope changed	check the provider layer change record

Do not rotate keys as the first reaction. A wrong model name and a wrong API Key can look similar from a user complaint, but they need different fixes.

Add one retry only after classification

A small retry wrapper is useful after the error class is clear:

async function runOnce() {
  const res = await fetch("https://api.vectorengine.cn/v1/chat/completions", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.VECTOR_ENGINE_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: process.env.VECTOR_ENGINE_MODEL || "gpt-4o-mini",
      stream: true,
      messages: [{ role: "user", content: "Return OK" }]
    })
  });

  if (res.status === 404) {
    throw new Error("model_not_found: verify the Vector Engine model name before retrying");
  }

  return res;
}

Retries help with temporary network failures. They do not fix a bad model route. That distinction is the reason the probe prints status, content type, model name, and Base URL before reading chunks.

What to keep in the runbook

Store these fields in the team runbook:

• Vector Engine provider name
• Base URL used by Dify, Cursor, and Node.js
• API Key environment variable name, not the secret
• model name used by each caller
• streaming enabled or disabled
• owner for model_not_found review

Once those fields are stable, the streaming probe becomes a quick check before release, not a long debugging session after users report broken partial output.

---

在 Vector Engine、Dify、Cursor 和 Node.js 之间探测流式兼容性

当团队把多个工具接到同一个 provider 时，普通的 chat completion 测试还不够。Dify 工作流可能依赖流式输出，Cursor 可能在编辑器面板中展示部分响应，Node.js 服务也可能把 chunk 转发给浏览器客户端。只要其中一个调用方出问题，就容易被误判成产品问题，而真实原因可能只是 Base URL、API Key 或 model name 不一致。

这篇教程会构建一个很小的向量引擎流式探针。向量引擎可以作为 OpenAI-compatible API gateway，也可以放在 Dify、Cursor 和 Node.js 共享的 LLM API provider layer 中；从中文视角看，它也常被团队称为向量引擎API中转站、向量引擎中转站或 API中转站。但每个调用方仍然要遵守同一份连接契约。

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

定义连接契约

先统一一份契约，再测试任何工具：

Provider: Vector Engine
Base URL: https://api.vectorengine.cn/v1
API Key: stored in VECTOR_ENGINE_API_KEY
model name: gpt-4o-mini
streaming: enabled

不要把 API Key 粘贴进截图、工单或示例。对这个探针来说，真正有价值的信息是 key 是否存在，以及每个调用方是否使用了相同的 model name。

创建 Node.js 流式探针

创建 probe-vector-engine-stream.mjs：

const baseURL = "https://api.vectorengine.cn/v1";
const apiKey = process.env.VECTOR_ENGINE_API_KEY;
const model = process.env.VECTOR_ENGINE_MODEL || "gpt-4o-mini";

if (!apiKey) {
  throw new Error("VECTOR_ENGINE_API_KEY is missing");
}

const response = await fetch(`${baseURL}/chat/completions`, {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${apiKey}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model,
    stream: true,
    messages: [{ role: "user", content: "Return three rollout checks." }]
  })
});

console.log(response.status, response.headers.get("content-type"));

这个测试不是为了覆盖所有 prompt，而是为了证明 Base URL、API Key、model name 和流式响应格式在进入 Dify 或 Cursor 前就是可用的。

对照 Dify 和 Cursor 配置

排查时用这张表：

字段	Dify	Cursor	Node.js 探针
Base URL	https://api.vectorengine.cn/v1	https://api.vectorengine.cn/v1	baseURL 常量
API Key	provider credential	editor/provider setting	VECTOR_ENGINE_API_KEY
model name	workflow model	selected model	VECTOR_ENGINE_MODEL
streaming	workflow response mode	editor response mode	stream: true

如果 Node.js 能正常流式输出而 Dify 不行，就检查工作流响应模式和 model name。如果 Cursor 失败但 Dify 与 Node.js 都通过，就检查编辑器 provider 设置，以及保存的 model name 是否有拼写差异。

处理 model_not_found

在流式测试中，model_not_found 常见于四类情况：

信号	可能原因	检查方式
HTTP 404 或 provider error	模型路由未启用	对照向量引擎路由中的 model name
Node.js 通过，Dify 失败	工作流还在用旧模型值	重新打开 provider model 设置
Dify 通过，Cursor 失败	编辑器缓存了旧 provider 项	删除并重新添加 provider 设置
所有调用方都失败	共享路由或 key scope 变更	查看 provider layer 变更记录

不要把轮换 key 当成默认反应。错误的 model name 和错误的 API Key 在用户反馈里可能很像，但修复路径完全不同。

Runbook 应该保留什么

在团队 runbook 中保留这些字段：

• 向量引擎 provider 名称
• Dify、Cursor 和 Node.js 使用的 Base URL
• API Key 环境变量名，而不是密钥本身
• 每个调用方使用的 model name
• 是否启用 streaming
• model_not_found 的排查负责人

当这些字段稳定后，流式探针就会变成发布前的快速检查，而不是用户报告流式输出异常后的漫长排查。