每造人工智能之应用者，必有一时焉，初试其技时也。
非其乐事也，非模型显奇技而自矜为智者之时也。乃他时也，子夜一时，对客代码而睹之，乃知其Gemini API密钥，昭然若揭，将束于JavaScript之文，俾凡有浏览器与十刻之暇者，皆可启而观之。
彼时，吾方筑Sambhav——一AI职业平台也，能实时语音转写，有Whisper为之；能析简历，有Gemini为之；能授个性化之导。其应用有Next.js 15之前端，与Flask之后台相接；有Supabase潜于其下，且有多般机件，皆需与LLM有所交涉。
吾最引以为傲之功能：实时模拟面试模式，用户可自然言谈，其言辞为系统转录，复由 Gemini 即时评点。此功能甚为精妙，运行亦佳。
其下之构，实为隐患。
实然之患
吾所陷之式，如是：凡需低时延之调，皆由客户端发之。如实时转写之反馈，若增服务器迂回，则体验滞涩，支离。然自客户端调用Gemini，则API密钥必存于客户端可及之处。
开发者于此常寻之解，皆各有弊。
汝可置钥于环境变量，冀汝之打包器不泄之——然其或泄，且泄之方式甚难稽核。汝可通万物于己之后端——此法可行，然今汝需维持两服务间之会话状态，而汝之Flask服务器唯转发请求、增延迟而已。汝可用短时效之令牌——然则汝需构建令牌生成与刷新之系统，此系统自成一项目。
所虑深远者，此皆不能解配额之困也。纵使隐汝API密钥，有志者犹能截获有效认证令牌，重放之。非为盗取密钥——只为耗尽汝之计费配额。若为私用项目或黑客松演示，此乃烦扰之偶发情形。若为真用户之生产系统，则实为重大威胁。
吾终采代理之法，盖其最可辩护也，然增面试反馈之迟滞，令会话管理大增其繁。Flask之 backend 必须同时持 Whisper 会话之态、Gemini 之境、及认证之层。当有失事——而演示中事必多失——则孰层之败，终不可辨。
Firebase AI 之理实变何在
Firebase AI 之理非新——然 Google 于 I/O 所出，使其异于六月之前，二者之合，恰解前述之弊
一者乃 惟模态也。此架构直白：汝之Gemini提示——系统指令、模型配置、工具定义——存于Firebase之服务器，非在汝之客户端代码。客户端引模板ID。仅此而已。当请求至，Firebase执行服务器端模板。若有人截取客户端请求，欲注入定制系统提示，框架则无视之。无路径自客户端代码至提示之操纵。
若如Sambhav之面试模式，此则意味着评估标准——定义Gemini如何评分候选人回答之提示——当存于其所属之服务器，非与前端捆绑。客户端仅送交记录，得结构化之回应。
其次为App Check回放防护，以一次性令牌为凭。。自本月起，Firebase AI Logic之App Check令牌严限单用。一用即殁。若攻者窃得有效令牌于途，不可重放以作Gemini之续呼。前所言之配额耗尽攻击——纵使API密钥隐秘至极亦技术上可行者——今于基础架构层面已告封闭。
迟滞之权衡，实存且当察之：每请求数新符，增一网络往返。于实时转写之功能，每数秒即唤一Geminic，此耗累积甚巨。启用此于迟滞敏感之途，当先剖析之。
混合推理之部
又有第三之公告，吾以为未为众人所重，盖其言似为性能优化，实则乃架构之决也.
Firebase今已支持跨iOS、Android（配Gemma 4）、——将速至GA——及Web之Chrome以混合推理。模型于设备所能则运行于本地，不可则退回云端之Gemini。
此非止于"速且廉"之故，实在于坚韧。Sambhav乃为极赛之境而设，故需于会场WiFi中运行。会场WiFi实为敌对。面试模式时，或中途顿滞，盖因Gemini通话超时，致体验毁于演示之际。
混合推理者，谓管路轻质之部——如转写之洁、应答之整、简易之判——可于地运行，不假网状之况。繁重之思则委云。网绝而应用犹存。
凡施此技者，所遇实问：于器上之Gemma 4，不得其全质。其能之阙，确凿，须设计其术，使地之径，得生雅降之境，非致崩坏。此乃设之难，非仅调之故。
此意之实
Firebase AI Logic GA非头条之讯，亦无成风之势。然凡开发者，或已推出，或欲推出客户端应用之AI功能，而遇API密钥存于何处、如何护其配额之困者，此I/O之讯，实为至要。
模板模式独用、App Check回放防护、混合推理三者合流，使我为Sambhav所拼凑之安全韧性架构——代理服务器、会话状态管理、手动令牌处理——今成Firebase SDK一等特性。汝无需自建管路，但须配置之。
吾当慎察其入产之要：模板独用之态与重演防护，各解问题之异端，亦具迟滞之殊相。勿使二者皆默认而启于四方。先审迟滞所系之径，察其往返之费所落，而后决取舍之宜。
昔需后端工程之安全架构，今寄于 Firebase 配置三途。此乃实践可行之变，意深且重。