北京
一个Angular项目想接Gemini，摆在面前的路通常只有两条：要么在AI Studio里拿一个裸API key直接塞进前端，要么自己搭一套Node或Python代理，再负责它的安全和运维。前者省事但把密钥暴露在浏览器里，后者稳妥但多出一整条要自己维护的后端链路。 Firebase AI Logic想站的位置，恰好在这两者中间。Gemini依然从浏览器里的Angular应用发起调用，但请求走的是Firebase托管的那条路径，而不是一个你自己搭、自己守的后端。它在2025年5月接替了原先的Vertex AI in Firebase，名字换了，API也换了。 **它到底帮你省掉了什么** 按官方给出的定位，这套方案在Web端适合几类场景：购物助手、客服对话、页面内的copilot；需要多轮对话和函数调用的功能，也就是让模型去调用你已有的Angular服务；以及对延迟敏感的功能——推理从客户端直接开始，不用先绕一圈服务器。 换句话说，它省掉的是"自己维护一个代理层"这件事，而不是省掉安全本身。请求仍然经过Firebase的托管路径，密钥和配置由控制台侧管理，而不是硬编码在前端代码里。 **什么时候它不该上场** 官方文档同样划出了边界，有三类情况更适合放到服务端： - 涉及敏感提示词或密钥的场景，应该留在服务端，用Genkit或Cloud Functions处理 - 需要对私有语料做重度RAG的场景，服务端检索通常更安全也更灵活 - 需要在边缘做计费和滥用控制的场景，要把App Check的强制校验和Firebase控制台监控结合起来，高风险操作再加一道服务端闸门 这三条不是"以后再说"的补充说明，而是选型时就要先过一遍的判断条件。客户端推理的便利，和把敏感逻辑放在浏览器里的风险，是同一枚硬币的两面。 **一个具体的用法长什么样** 素材里提到的ByteWise是个可以参考的例子：agent读取库存、通过函数调用更新购物车，AI Logic依然跑在客户端，业务逻辑则放在Angular服务里。这个分工的关键在于，模型负责理解和触发，真正碰数据的部分仍然由你自己的服务掌控。 从工程结构上看，一个标准的Angular应用之外，只需要新增两个Firebase相关的文件：一个放凭据的配置文件，一个负责初始化应用、接入App Check并拿到AI provider。其余的改动都很小——在应用配置里注册一次provider，在index.html里做点调整，再写一个服务。 整个链路是这样串起来的：Firebase控制台负责AI Logic、App Check和API key；配置文件承接凭据；初始化文件完成应用启动和provider获取；应用配置只注册一次；最后由服务注入并调用generateContent()。 **动手前要先做完的事** 环境上有几个硬性前提：Angular 18以上，使用standalone和ApplicationConfig风格；Node.js用LTS版本；一个Google账号和Firebase项目；firebase包版本不低于12.19.0，这是当前Gemini和App Check行为所要求的。 控制台的操作要在写代码之前完成。先建项目和Web应用，把firebaseConfig对象复制出来备用；然后尽早启用Firebase AI Logic——在AI Services里进入AI Logic，选择Gemini Developer API并走完设置向导，同时把推荐的API和AI monitoring一并开启。之后需要等待5到10分钟，再去Google Cloud控制台继续后续配置。 顺序在这里不是形式问题。控制台没配好就写前端代码，后面大概率要回头返工。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
