Firebase 8月更新：AI Logic 安全升级与 CLI Agent 模式详解

Firebase 在 8 月的版本更新中，围绕安全、AI 能力和 Agent 工作流做了一系列关键调整。从 Firestore 安全规则的可视化管理，到 AI Logic 默认开启 App Check，再到专为自动化编码 Agent 设计的 CLI 非交互模式，这次更新的主线非常清晰：让生产环境更安全，让 AI 与自动化流程更顺畅。

Firestore 安全规则进入可视化时代

安全规则本质上是一种基础设施代码（Infrastructure as Code），过去它的管理和排障往往依赖完整的 CI/CD 流水线。这次更新后，标准版和企业版用户都可以直接在 Google Cloud Console 中查看、管理和部署安全规则。

更实用的是新增的可视化时间线（visual timeline）能力。当某次规则变更导致生产环境的客户端查询中断时，你可以并排对比（diff）历史规则集、将其克隆为新草稿，或者立即回滚——无需等待整条 CI/CD 流水线重新部署。这对于线上故障的快速止血极具价值。

此外，Firestore 现已在曼谷区域（asia-southeast3）上线，为东南亚地区用户提供更低的区域延迟。

Cloud Functions 与扩展的迁移倒计时

Cloud Functions SDK 升级至 7.3.0，新增了 secret param 配置选项以及一批新的生命周期钩子（lifecycle hooks），使用这些新特性需要 Firebase CLI 15.24.0 或更高版本。

这些生命周期钩子的一个重要用途是简化 Firebase Extensions 的迁移——因为官方已确认 Extensions 将于 2027 年 3 月 31 日 正式弃用并停止服务。已部署的扩展仍会继续运行，但在该日期之后，你将无法再通过 Console 或 CLI 更新、重新配置或卸载它们。对于当前正在使用或发布扩展的开发者，现在就应查阅官方迁移指南，尽早解耦相关依赖。

生命周期钩子（lifecycle hooks）是 Firebase Extensions 框架中定义的一组标准化回调，允许扩展在被安装、更新、配置变更或卸载时执行自定义逻辑，例如数据迁移、资源清理或版本兼容性检查。Cloud Functions SDK 7.3.0 将类似机制引入普通 Cloud Functions，开发者可以借此在函数部署流程的关键节点插入钩子——这对于将现有扩展逻辑平移为自托管 Cloud Functions 尤为有用，可以在迁移过程中保留原有的安装与升级行为，降低迁移风险。

Firebase AI Logic：新模型加持，安全默认收紧

AI Logic 部分新增了对最新 Gemini 模型的支持，包括 Gemini Flash 系列的多个新版本，以及通过 Gemini Flash TTS preview 实现的客户端文本转语音（TTS）能力。开发者可以直接从客户端 SDK 调用 TTS 模型，既支持 Gemini Developer API，也支持 Agent 平台的 Gemini API。

但这次真正的重头戏是安全。从客户端应用直接调用模型能带来很多强大的可能性，但风险也随之而来：如果处理不当，任何人都可能提取你的密钥并耗尽你的配额。

为此，App Check 现已在所有新项目中默认开启。每个客户端请求在触及你的 Gemini 配额之前，都必须先证明自己来自真实、合法的应用二进制文件。这从架构层面堵住了配额被盗刷的漏洞。

在模型生命周期方面，Gemini 2.5 家族（Pro、Flash、Flash Lite 及 Flash Image）将于今年 10 月退役，建议开发者尽快升级到新版本模型。

App Check 是 Firebase 提供的应用身份验证层，其核心机制是在客户端请求到达后端服务之前，先由设备上的证明提供方（Attestation Provider）生成一个加密令牌，证明请求确实来自未被篡改的、合法发布的应用二进制文件。在 iOS 上默认使用苹果的 DeviceCheck 或 App Attest，在 Android 上使用 Play Integrity API。过去，开发者需要在项目中手动集成并启用 App Check；默认开启意味着新项目从第一行代码开始就处于受保护状态，消除了「先开发后加固」导致的配置遗漏风险。

客户端 SDK 集体大版本升级

本次更新在客户端侧进行了一轮全平台的大版本号跃迁（major version bumps），覆盖 Flutter、JavaScript、Apple、Android、C++ 和 Unity。跨端开发者需要留意各平台的变更日志和发布说明，评估升级带来的破坏性改动。

为 AI Agent 优化的 CLI 非交互模式

这次更新中一个非常贴近实际痛点的改进，是针对 Agent 化工作流的优化。

如果你曾经遇到过自主编码 Agent 或后台 CI 运行器因为 CLI 弹出交互式提问而卡死的情况，就会明白这种死锁有多恼人——Agent 在等待人类输入，而人类根本不在现场。

现在 Firebase CLI 能够检测到 AI Agent 进程正在运行，并自动强制切换到非交互模式，从根本上消除了 Agent 循环卡死的问题。这一改动虽小，却精准反映了 AI 编程 Agent 正在成为主流开发场景的趋势。

App Check 引入 reCAPTCHA Enterprise 行为检测

在安全方向上，App Check 正在扩展其证明（attestation）选项，新增了 reCAPTCHA Enterprise，目前在 Apple 平台、Android 和 Flutter 上以预览形式提供。

这里有一个关键的能力分层：像 Play Integrity 这样的设备证明能告诉你设备未被 root，但它无法判断是否有机器人在自动化发起请求。而 reCAPTCHA 通过无感的行为评分（behavioral scoring）来补足这一缺口——既不需要用户完成验证码，也不引入额外的用户体验摩擦或延迟。

reCAPTCHA Enterprise 的行为评分（behavioral scoring）基于用户与页面或应用的交互模式——鼠标轨迹、触控节奏、操作时序等信号——在后台静默计算出一个 0.0 到 1.0 的风险分值，无需弹出图片验证码。这与传统 reCAPTCHA v2 的「我不是机器人」勾选框有本质区别：前者对真实用户完全无感，后者在高风险场景下会打断操作流程。将 reCAPTCHA Enterprise 作为 App Check 的证明提供方，意味着即便攻击者拿到了合法设备并通过了 Play Integrity 检测，自动化脚本的行为特征仍会被识别出来，形成设备层与行为层的双重防御。

Firebase ML 正式弃用及迁移路径

Firebase ML 已被正式弃用，将于 2027 年 6 月 15 日 关闭，新项目将无法再启用该服务。官方给出了两条迁移路径：

• 端侧 TensorFlow Lite 模型：改为直接通过 Cloud Storage 存储和分发；
• Cloud Vision 功能：改用 Firebase AI Logic，或直接调用 Cloud Vision API。

小结

8 月这一轮更新的重心非常明确：一方面通过 App Check 默认开启、reCAPTCHA Enterprise 引入，把客户端直连模型的安全短板补齐；另一方面通过 CLI 非交互模式适配 AI Agent 工作流。同时，Firebase Extensions（2027年3月）和 Firebase ML（2027年6月）两条弃用时间线也提醒开发者提前规划迁移。对于正在构建 AI 驱动应用的团队来说，这些变化值得尽早纳入技术规划。