2026年SN-4.6 对话API调用示例：Python 与 Node.js 两种接法

2026年SN-4.6 对话API调用示例：Python 与 Node.js 两种接法

同一个对话接口，用 Python 和 Node.js 接，踩的坑并不一样：Python 容易忽略超时与状态码，Node.js 容易忘记 await 和响应体读取方式。

下面把 SN-4.6 对话 API 这类基于 /v1/chat/completions 结构的调用，拆成“准备 → 两种接法 → 对照表 → 常见问题”四段来讲。示例中的接口地址与模型名称都需要替换成你自己控制台中显示的值，任何字段的最终解释权都在接口文档，而不是在某篇教程里。

一、动手前先确认三件事

• 接口地址（Base URL）：以控制台显示的地址为准，注意结尾是否已经带 /v1，重复拼接是新手最常见的 404 来源。
• API Key：放进环境变量或密钥管理服务，不要直接提交到代码仓库。
• 模型名称：逐字复制，大小写、连字符、版本号后缀都算数。

这三项确认好，剩下的就是语言层面的写法差异。

Python 接法：requests 直连最直观

不引入额外 SDK 时，直接用 requests 发一次 POST 就能验证链路是否打通：

import os
import requests

BASE_URL = os.getenv('BASE_URL')   # 以控制台显示的接口地址为准
API_KEY = os.getenv('API_KEY')     # 以控制台生成的 Key 为准

resp = requests.post(
    f'{BASE_URL}/v1/chat/completions',
    headers={
        'Authorization': f'Bearer {API_KEY}',
        'Content-Type': 'application/json',
    },
    json={
        'model': '控制台中确认的模型名称',
        'messages': [{'role': 'user', 'content': '用三句话介绍你自己'}],
        'temperature': 0.7,
    },
    timeout=60,
)
resp.raise_for_status()
print(resp.json()['choices'][0]['message']['content'])

这段代码里有三个细节值得保留：timeout 必须设置，否则网络异常时进程可能长时间挂起；raise_for_status() 把 4xx 和 5xx 提前暴露出来，避免后面解析一个错误结构的 JSON 时报出难懂的 KeyError；messages 用列表承载多轮上下文，而不是拼成一整段字符串。

Node.js 接法：用原生 fetch 依赖最少

Node.js 18 之后 fetch 已内置，不需要再装 HTTP 客户端：

const BASE_URL = process.env.BASE_URL;
const API_KEY = process.env.API_KEY;

const res = await fetch(`${BASE_URL}/v1/chat/completions`, {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    model: '控制台中确认的模型名称',
    messages: [{ role: 'user', content: '用三句话介绍你自己' }],
    temperature: 0.7,
  }),
  signal: AbortSignal.timeout(60000),
});

if (!res.ok) {
  throw new Error(`HTTP ${res.status}: ${await res.text()}`);
}

const data = await res.json();
console.log(data.choices[0].message.content);

Node.js 侧有两个高频错误。第一是忘记 await，打印出来是 Promise { <pending> }，看起来像接口没返回，其实是代码没等。第二是错误处理里没有读取响应体，只打印状态码，导致拿不到服务端给出的具体错误信息，排查起来绕远路。

二、两种接法对照表

把差异集中成一张表，迁移或交接时会省不少时间。

三、多轮对话、流式输出与错误处理

把单次调用跑通之后，接下来三件事决定能不能上生产。

1. 多轮上下文。把历史消息按角色依次追加到 messages 数组里，并设置一个长度上限，避免请求体无限增长。超出上限时优先保留系统提示与最近几轮对话。
2. 流式输出。开启流式后，返回的是 SSE 格式的文本流，需要按行解析以 data: 开头的片段，遇到结束标记就停止。前端展示可以边收边渲染，但服务端仍要处理连接中断的兜底逻辑。
3. 错误分类。鉴权类错误不要重试，参数类错误要修正后再发，限流与服务端错误则可以配合指数退避重试，并记录请求标识方便排查。

切换语言或切换 SDK 时，最容易出问题的不是调用逻辑，而是默认值。温度、最大输出长度、超时在两种语言里常常不同，建议把关键参数显式写出来，而不是依赖默认值。

四、多模型场景下的统一接入

真实项目里很少只用一个大模型。做摘要用一个、写代码用另一个、做客服又换一个，时间一长，代码里就会散落多套地址和多个 Key，换模型要改配置，查用量要登好几个后台。

通联AI中转站 提供的是聚合式接入思路：用统一的 Base URL 和 API Key 调用多家厂商模型，兼容 OpenAI 等常见协议方向，在控制台集中管理模型选择、余额与调用情况。对已经按 /v1/chat/completions 结构写好代码的项目来说，迁移时主要是替换地址、Key 和模型名称三项，业务逻辑基本不用动。

具体支持哪些模型、各自的计费方式与协议细节，请到 通联AI中转站 官网查看实时列表，并在配置前核对控制台给出的 Base URL、模型名称与接口路径，再逐步替换线上的调用配置。

两种语言都跑通之后，建议把接口地址、Key 和模型名称统一收敛到一个入口，这样下次换模型只需改一行配置。注册后可在控制台获取 API Key、查看可用模型与接口地址，先用上面这段最短示例验证一次请求，再接入你的业务代码。

进入通联AI中转站，注册后获取 API Key