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

大部分人在开发过程中都会遇到这样的情况：产品经理提了一个“加个AI助手”的需求，听起来不过是多一个入口，可一打开IDE，后续的技术难题就排着队来了——API Key不能暴露在前端，得有个后端网关做转发；用户不能无限制调用，需要配额和计数；调用过程得记录下来，方便日后查询或审计，限流、熔断、成本核算这些也一个都跑不掉。

算下来，这个看起来“简单”的AI入口，可能得花上两三周的时间。

现在，

。它和Supabase Auth无缝粘合：复用Supabase的登录态，前端无需暴露模型Key就能调用大模型；而配额、审计、观测、模型切换这些操作，全都在控制台里处理。这样一来，省去了很多原本需要自己补的工作。

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

---

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

火山Supabase是基于火山云数据库PostgreSQL Serverless版打造的

：数据库、Auth、Storage、Edge Functions、Realtime……做AI应用时，很多常用能力不用再分别搭建、维护，一键接入即可使用。

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

一句话总结：

1. 鉴权复用Supabase Auth：
   前端不需要获取任何模型API Key，只需用session.access_token（或service_role_key / 第三方JWT）就能调模型；火山Supabase AI-Gateway帮你识别“这是谁在调”。

2. 协议兼容OpenAI：
   请求地址为${SUPABASE_URL}/v1，格式和OpenAI Chat Completions完全一致，使用OpenAI SDK、Vercel AI SDK、cURL都能直接连。

3. 运维套件内置：
   每次调用均自动进入配额扣减、审计日志、观测指标，控制台可视、可查、可导出。

目前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，而是“这个用户登录了Supabase”这件事本身。

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

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

火山Supabase AI-Gateway天然带

：

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

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

---

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

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

答案是：

。火山Supabase AI-Gateway带来的最大不同，在于它与Supabase Auth、DB、Branch、Workspace之间是原生粘合的，相比自建方案有明显优势：

能力维度	自己搭一层AI中转	Supabase AI-Gateway
鉴权方式	需要自己解析Supabase JWT，或者搞一套额外的Key管理	原生识别access_token / service_role_key / 第三方JWT，一步到位
用户级配额	自己读写表，查余额、写扣减，需考虑并发和原子性	内置全局配额+单用户配额管理，支持API和控制台修改
审计日志	自己接日志系统、自己写查询页	控制台Logs & Analytics → Collection里选AI-Gateway即可看
分支与回溯	基本无解；很难做到“这个feature分支上的AI用量单独算”	创建子分支时配额从父分支继承，用量归零；恢复分支时配额跟着时间点回滚
协议生态	自己确定：可以不支持协议兼容，但客户端需随协议更换；或者自己实现协议兼容，工作量大	OpenAI兼容，OpenAI SDK / Vercel AI SDK / cURL全部可用
上线速度	视复杂度，从几天到几周	从“创建Workspace”到“第一次调通应用”通常在10分钟内

火山引擎Supabase的

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

---

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

接下来用一个能实际跑通的例子串起来看。我们先做一个

：用户登录后，输入一个大任务，AI会把它拆成多个更容易执行的小任务，并写进Supabase数据库，再由前端读取和展示。

这套流程里，不需要额外

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

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

报错体形如{"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编辑器里跑一段：

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。

// 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

然后写一个函数：

。

// 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拆好的任务写进数据库

export async function sa veTasks(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也写不进去。

。

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

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

一个“输入目标 → AI拆解 → 存表 → 展示”的完整闭环，

。

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

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

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)

它只能在你可控的后端环境变量里存在。前端场景一律用session.access_token。

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

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

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用量会在调用后进行统计和校对，因此实际消耗可能会略微超过设定配额。配额更适合作为日常预算管理手段，而不应被理解为实时

。如果业务场景对成本或调用次数有严格限制，建议在业务侧增加一层限流或熔断。

前端 = 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还有哪些“应当由人来做，但是不应该每个人都要去重头开始”的功能可以集成进来。