把大模型一键接进你的 App，火山引擎 Supabase 上线 AI-Gateway

大部分人在开发过程中都会遇到这样的情况：产品经理提出了一个增加"AI助手"的功能需求，这看起来也只是增加一个新入口，但是打开 IDE 之后就得考虑后续一系列的技术难题：API Key 不能暴露在前端，因此需要有一个后端网关进行转发；用户不能无限制地请求，因此需要有配额以及计数；调用过程需要被记录下来以便日后查询或者审计，限流、Fallback、成本核算等问题也是不可避免。

算下来，这个看起来很"简单"的 AI 入口可能要花两三周的时间。

现在，火山引擎 Supabase 正式上线了 AI-Gateway（大模型访问）能力， 它与 Supabase Auth 无缝粘合：复用 Supabase 的登录态，在前端无需暴露模型 Key 的情况下调用大模型；而配额、审计、观测、模型切换等操作都放到控制台里处理。这样就省去了很多原先需要自己补的工作。

这篇文章你会看到：

AI-Gateway 是什么？它可以做什么？
和自己搭一层 AI 中转服务有什么本质区别？
Demo 手把手可粘贴：前端 30 行代码 + 一个"AI 待办助手"
你在上线前避免踩坑的指南

一、AI-Gateway 是啥：从"数据库"到"AI 原生 BaaS"的那块拼图

火山 Supabase 是基于火山云数据库 PostgreSQL Serverless 版打造的 AI 原生 BaaS（Backend-as-a-Service） ：数据库、Auth、Storage、Edge Functions、Realtime......做 AI 应用时，很多常用能力不用再分别搭建、维护，一键接入即可使用。

用户登录 Supabase，获取 access_token，前端拿着这个 token 直接以 OpenAI 兼容协议调用 ${SUPABASE_URL}/v1/chat/completions------鉴权、限流、审计、计费，这些全都可以通过火山 Supabase 一站式解决。

一句话总结：原本需要开发者自行搭建的 AI 中转层，现已被火山 Supabase 纳入 BaaS 能力体系。

核心原理如下：

鉴权复用 Supabase Auth： 前端不需要获取任何模型 API Key，只需用 session.access_token（或 service_role_key / 第三方 JWT）就能调模型；火山 Supabase AI-Gateway 帮你识别"这是谁在调"。
协议兼容 OpenAI： 请求地址为 ${SUPABASE_URL}/v1，格式和 OpenAI Chat Completions 完全一致，使用OpenAI SDK、Vercel AI SDK、cURL 都能直接连。
运维套件内置： 每次调用均自动进入配额扣减、审计日志、观测指标，控制台可视、可查、可导出。

目前 AI-Gateway 上线支持字节跳动豆包（Doubao）系列，包括 Doubao-Seedance-2.0全系列、 Doubao-Seedream-5.0全系列、Doubao-Seed-2.0-Pro、Doubao-Seed-2.0-Code、Doubao-Seed-2.0-Lite、Doubao-Seed-2.0-Mini，它覆盖了视频生成、图片生成、通用推理、代码、轻量对话等组合。具体的模型清单以控制台为准。

二、它到底解决了什么问题：三个真实场景

以下是三个由真实开发者所碰到问题，以此来感受一下火山 Supabase AI-Gateway 带来的便捷之处。

场景一：一家 SaaS 软件想要增加一个"AI 客服"，但是又不愿意为其单独新建一个后端。

背景：你开发一个 ToB SaaS 产品，在前端使用 React，在后端已使用 Supabase 完成认证以及数据库相关工作。产品经理提出"是否可以增加AI客服功能？"

如果没有 AI-Gateway，你要做如下这些事：

一个新 Node/Python 服务用于保存模型 API Key；
校验用户登录状态（一般需要考虑如何使用户登录状态与JWT保持一致）；
做用户级限流（防止有人一顿刷把你 Key 用爆）；
记日志、做监控、加告警；
部署、上线、写 CI/CD。

现在有了火山 Supabase AI-Gateway，这些都不需要关心 。在前端拿着已经有的 session.access_token，直接调 ${SUPABASE_URL}/v1/chat/completions，就是完整的鉴权 + 限流 + 日志。

场景二：个人开发者做 AI 应用，担心 API Key 暴露在前端

背景：假设你是一个独立开发者，希望快速上线一个 AI 阅读助手产品。"纯前端 + Supabase"是最简单的方式，但是有一个无法避免问题：模型 API Key 不能直接放在浏览器里，否则用户随便打开 F12会看到这个Key。

传统做法一般是再起一个后端，或者用 Serverless Function 做一层中转。这样虽然能解决 Key 暴露的问题，但严格意义上来说已经不是纯前端方案了。

有了火山 Supabase AI-Gateway。前端拿到用户登录的 access_token，就能安全调模型。没有任何模型 Key 需要出现在浏览器里，因为你要的不是模型 Key，而是"这个用户登录了 Supabase"这件事本身。

场景三：团队要给每个内部用户"限量"用大模型，控成本

背景：公司在内部希望所有员工都能使用AI提高效率，但是公司的资金有限，不可能给每个团队配置一个共享Key，也无法知道每个员工消耗了多少 Token。

火山 Supabase AI-Gateway 天然带用户级 Token 限额：

全局默认限额，可以一键给所有用户设一个"每日 Token 上限"；
单用户可自定义限额，重点用户可以给高，试点用户给低；
控制台里能看到每个用户今日消耗、历史消耗、加入时间；

其实之前要实现这个功能，你得自己写库、自己写页面、自己写扣费逻辑。现在它就是火山 Supabase 实例里的一组配置项。

三、它跟"自己起个后端转发"到底有什么不一样

行内人可能会问：这不就是个 AI 网关吗？我也能写一个。

答案是： "能做"和"值得为它单独做"是两回事。火山 Supabase AI-Gateway 给人带来的最大不同之处在于它是与 Supabase Auth、DB、Branch、Workspace 之间是原生粘合的，相比自建方案会有明显优势：

火山引擎 Supabase 的分支能力，可对"数据库 + 配额"一起做分支。比如你创建一个 feature 分支来测试新功能，其 Token 用量会被单独统计，不会混到生产环境里；如果测试过程中发现问题，也可以把分支回滚到某个时间点，相关配额配置也能跟着回到当时的状态。

四、手把手 Demo：30 行代码做一个"AI 待办助手"

接下来用一个能实际跑通的例子串起来看。我们先做一个 AI 待办助手：用户登录后，输入一个大任务，AI 会把它拆成多个更容易执行的小任务，并写进 Supabase 数据库，再由前端读取和展示。

这套流程里，不需要额外自研后端，模型 Key 也不会出现在前端；同时还能保留用户登录态，并接上限额和日志能力。

Step 0：准备一个 Workspace 并打开 AI-Gateway 配额

进入火山 Supabase 控制台，创建 Workspace，或者复用已有的。然后完成一件关键但容易疏忽的事：

⚠️ 新 Workspace 默认用户 Token 配额是 0------不改的话，调用大模型一定会报错： 报错体形如 {"error":{"message":"no quota configured for user","type":"quota_exceeded"}}。

在控制台"限额管理"里，把"全局默认每日 Token 限额"设置成一个非 0 的数（比如 200000），或者给测试账号单独配额，再重试即可。

顺手记下两个东西：

SUPABASE_URL：形如 https://br-xxx.supabase.aidap.cn-beijing.volces.com
SUPABASE_ANON_KEY：从项目设置里拿到，是前端初始化 Supabase 客户端用的

Step 1：建一张 todos 表

在 Supabase SQL 编辑器里跑一段：

sql 复制代码

create table if not exists todos (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users(id) on delete cascade,
  title text not null,
  done boolean not null default false,
  created_at timestamptz not null default now()
);

alter table todos enable row level security;

create policy "own todos" on todos
  for all using (auth.uid() = user_id) with check (auth.uid() = user_id);

熟悉 Supabase 的同学都知道这就是标准的"每人只能看自己的数据"。火山 Supabase AI-Gateway 会复用同一套 Auth，后面 AI 的调用也天然带用户身份。

Step 2：初始化前端 & 登录

前端用最普通的 React + Supabase JS SDK。

javascript 复制代码

// supabase.ts
import { createClient } from '@supabase/supabase-js'

export const supabase = createClient(
  'https://br-xxx.supabase.aidap.cn-beijing.volces.com',
  'your-supabase-anon-key'
)

登录部分可以直接用 Supabase 提供的 Auth UI，或者自己写邮箱密码登录，这里省略。

Step 3：让 AI 帮用户拆任务（重点来了）

安装一下 OpenAI SDK：

复制代码

npm install openai

然后写一个函数：用当前登录用户的 access_token 直接调用模型。

php 复制代码

// aiPlanner.ts
import OpenAI from 'openai'
import { supabase } from './supabase'

const SUPABASE_URL = 'https://br-xxx.supabase.aidap.cn-beijing.volces.com'

export async function planTasks(goal: string) {
  // 1) 拿到当前用户的登录态
  const { data: { session } } = await supabase.auth.getSession()
  if (!session) throw new Error('请先登录')

  // 2) 把 access_token 当作 API Key 传给 OpenAI SDK
  const openai = new OpenAI({
    baseURL: SUPABASE_URL + '/v1',
    apiKey: session.access_token,
    dangerouslyAllowBrowser: true, // 关键：允许在浏览器里用
  })

  // 3) 调用 Doubao 模型
  const stream = await openai.chat.completions.create({
    model: 'bytedance/doubao-seed-2.0-pro',
    stream: true,
    messages: [
      {
        role: 'system',
        content: '你是一个任务拆解助手。请把用户的目标拆成 3-6 个可执行的小任务，每行一条，不要加编号。',
      },
      { role: 'user', content: goal },
    ],
  })

  const tasks: string[] = []
  let buffer = ''
  for await (const chunk of stream) {
    const delta = chunk.choices[0]?.delta?.content ?? ''
    buffer += delta
    // 边流边解析
    const lines = buffer.split('\n')
    buffer = lines.pop() ?? ''
    for (const line of lines) {
      const t = line.trim()
      if (t) tasks.push(t)
    }
  }
  if (buffer.trim()) tasks.push(buffer.trim())
  return tasks
}

注意这里发生的事：

前端全程不知道模型 API Key，用的是用户自己的登录 token；
不需要任何后端 ，OpenAI SDK 直接指向 Supabase 接入地址的 /v1；
模型可换 ：model 字段改成 doubao-seed-2.0-lite，成本降一个数量级，代码不变。

Step 4：把 AI 拆好的任务写进数据库

vbnet 复制代码

export async function saveTasks(userId: string, tasks: string[]) {
  const rows = tasks.map(t => ({ user_id: userId, title: t }))
  const { error } = await supabase.from('todos').insert(rows)
  if (error) throw error
}

由于 RLS 策略里限定了 user_id = auth.uid()，即便有人拿走 anon key 想写别人的 todos 也写不进去。Auth 一次配置，AI 调用和数据库写入两边都受益。

Step 5：完整的按钮点击流程

csharp 复制代码

async function onGeneratePlan(goal: string) {
  const tasks = await planTasks(goal)              // AI 拆解
  const { data: { user } } = await supabase.auth.getUser()
  await saveTasks(user!.id, tasks)                 // 写库
  // 触发列表刷新
}

一个"输入目标 → AI 拆解 → 存表 → 展示"的完整闭环，前端加起来不到 60 行代码，没有后端。

Step 6：想要在 Node 后端跑？用 service_role_key

如果你的场景是"后端定时任务批量"，比如夜里跑一批文档摘要，那不适合用用户 access_token（用户不在线），改用 service_role_key：

ini 复制代码

import os
from openai import OpenAI

supabase_url = 'https://br-xxx.supabase.aidap.cn-beijing.volces.com'
service_role_key = os.environ['SUPABASE_SERVICE_ROLE_KEY']

client = OpenAI(
    base_url=supabase_url + '/v1',
    api_key=service_role_key,
)

resp = client.chat.completions.create(
    model='bytedance/doubao-seed-2.0-pro',
    messages=[{'role': 'user', 'content': '用一句话解释什么是任务拆解功能'}],
)
print(resp.choices[0].message.content)

⚠️ service_role_key 绝对不能出现在前端代码、浏览器、公开仓库里。 它只能在你可控的后端环境变量里存在。前端场景一律用 session.access_token。

Step 7：对于采用 Vercel AI SDK 的应用，仅需调整两行调用配置。

如果你已经在用 Vercel AI SDK 做流式渲染，直接接过来：

php 复制代码

import { createOpenAICompatible } from '@ai-sdk/openai-compatible'
import { streamText } from 'ai'

const gateway = createOpenAICompatible({
  baseURL: SUPABASE_URL + '/v1',
  apiKey: session.access_token,
  name: 'supabase-ai-gateway',
})

const result = streamText({
  model: gateway('bytedance/doubao-seed-2.0-pro'),
  prompt: '帮我写一段任务拆解的开场白',
})

协议兼容的意义： 应用在切换 Gateway 时仅需调整baseURL 和 apiKey，无需改动原有业务逻辑。

Step 8：去 Logs 看一眼刚才发生了什么

在火山 Supabase Dashboard 中进入 Logs 页面，将 Collection 选择为 AI-Gateway，即可查看此前调用过程中产生的相关日志信息，包括请求时间、调用用户、使用模型、Token 消耗以及状态码等内容。平台同时支持按照时间范围、Severity 和 Module 等维度进行筛选，并可根据需要导出日志数据。

通过这一能力，诸如"某个用户为何无法正常调用 AI"或"本周 AI 调用成本是多少"这类问题，都可以直接通过日志进行排查和分析，无需额外接入独立的观测系统。

五、上线前一定要知道的三件小事

Demo 跑通真上线之前有三点要注意：

① 提前配置好配额

新 Workspace 中每个用户默认配额为 0。如果首次调用时出现连接失败或 quota_exceeded 报错，通常并不是服务本身异常，而是配额尚未设置。上线前应先配置全局默认配额，并针对重点用户设置更高的自定义配额。

② 配额是后置统计

用户 Token 用量会在调用后进行统计和校对，因此实际消耗可能会略微超过设定配额。配额更适合作为日常预算管理手段，而不应被理解为实时熔断机制。如果业务场景对成本或调用次数有严格限制，建议在业务侧增加一层限流或熔断。

③ Key 分场景，别混用

前端 = session.access_token；后端定时任务 = service_role_key；接了 Auth0/Firebase/自有 IdP = 第三方 JWT。三种 Key 有各自的适用面，请注意写错就是一次事故。

另外几件"建议但不强制"的实践：

模型选型分层：高质量对话采用 Doubao-Seed-2.0-Pro，代码相关使用 Doubao-Seed-2.0-Code，聊天气泡以及意图识别等采用 lite/mini，降低成本数倍。
分支预算隔离：试验新功能创建一个子分支，在该子分支中使用AI配额由其父分支分配但是从零开始计算，如果出现问题回退也十分方便。
审计日志留存：在一些特殊场合（如客服、法务、医疗等应用），可将 Logs 中的 AI-Gateway 相关日志接入到您自有的符合要求的日志管理系统中，可使用官方提供的导出方式。

六、写在最后：AI 应用的"最短路径"

回到最初的那个场景，在产品说"加一个 AI 助手"的时候，有经验的开发者都会首先想到一连串的问题：是否需要一个服务，key 如何存储，如何进行限流，日志以及审计如何添加等。而现在火山 Supabase AI-Gateway 上线后，我们开发就变得十分简便：在火山控制台中配置相应额度，在前端可以直接使用/v1/chat/completions 来发起请求。

其实它并不是一种全新的 AI 应用开发方式。它只是把AI应用中最复杂、最繁琐、也是最无用的部分，在 Supabase 中提前进行了整合。这样可以让开发者有更多的时间去优化 Prompt，设计产品的流程，与用户沟通需要解决的问题等，而不必花费大量精力在转发服务、Key 管理、调用次数等方面。

如果你手上正好有个没落地的 AI 想法，不妨从这里开始尝试一下：

打开火山 Supabase 控制台，在30秒内创建一个 Supabase Workspace;
查看官方文档模型使用、限额管理以及 APP/Agent 如何通过 AI-Gateway 访问 AI 模型，运行上面示例代码。
在研发任务列表中删除你要写的"花几周开发AI转发后端"。

AI-Gateway 对火山 Supabase 而言只是一小步，但是对 AI 应用落地却是缩短一条通往"从想法到可运行"的距离。如果你有在开发 AI 应用、Agent，或者是需要"用户 → 模型"，都可以试一试这条更加便捷的道路。同时我们也非常愿意听到大家的意见，在评论中讨论 Supabase 还有哪些"应当由人来做，但是不应该每个人都要去重头开始"的功能可以集成进来。