大部分人在开发过程中都会遇到这样的情况：产品经理提出了一个增加“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 之间是原生粘合的，相比自建方案会有明显优势：
|
|
|
|
|---|---|---|
| 鉴权方式 |
|
access_token / service_role_key / 第三方 JWT，一步到位 |
| 用户级配额 |
|
|
| 审计日志 |
|
|
| 分支与回溯 |
|
|
| 协议生态 |
|
|
| 上线速度 |
|
|
火山引擎 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 编辑器里跑一段：
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
然后写一个函数：用当前登录用户的 access_token 直接调用模型。
// 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 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：完整的按钮点击流程
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：
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 做流式渲染，直接接过来：
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 还有哪些“应当由人来做，但是不应该每个人都要去重头开始”的功能可以集成进来。