Google I/O 2026 这次最有意思的，不是 Google 又端出多少 AI 名字，而是一个还没真正全面摆上桌的产品：Gemini Spark。

它被 Google 描述为“你的个人 AI Agent”，能原生连接 Gmail、Calendar、Drive、Docs、Sheets、Slides、YouTube、Maps。也就是说，它不只是陪你聊天，而是准备进入邮箱、日程、文件、表格和地图里替你办事。

我通常不愿意大写特写还不能亲测、还在 coming soon 的东西。预览版和最终开放给大众的版本，常常不是一回事。但 Spark 例外。它暴露的不是一个功能点，而是 Google 正在把 Agent 从工具推向基础设施。

Spark 卖的不是模型，是权限

Spark 的核心卖点不是“更聪明的 Gemini”。真正的变化是权限范围。

一个 Agent 一旦接入 Gmail、Drive、Calendar，它拿到的就不是公开网页，而是高价值私域数据。邮件、会议、合同、表格、路线、YouTube 记录，都可能成为任务上下文。

把目前能确认的信息压成一张表：

事项Google 已公开的说法真实变量
Gemini Spark个人 AI Agent，可连接 Gmail、Calendar、Drive、Docs、Sheets、Slides、YouTube、Maps它会进入用户最敏感的 Google 数据层
模型与底座FAQ 称 Spark 运行在 Gemini 3.5 Flash 和 Antigravity 上Antigravity 到底是哪一层，公开信息还不清楚
企业安全全托管安全运行时、隔离临时 VM、Agent Gateway、DLP、凭据加密目前主要是厂商承诺，缺少外部验证
CLI 迁移开源 Gemini CLI 将在 6 月 18 日停止支持 AI 订阅计划，改用闭源 Antigravity CLI开发者的可审计性下降，迁移成本上升

最别扭的是 Antigravity。

antigravity.google 现在把它列成好几种形态：桌面应用、Go 写的 CLI agent tool、Antigravity SDK，以及最初的 Antigravity IDE，也就是一个 VS Code fork。Spark FAQ 又说它运行在 Gemini 3.5 Flash 和 Antigravity 上。

这句话很关键，也很不够。

它没有讲清楚 Antigravity 在 Spark 里到底是运行时、工具调用层、CLI 组件，还是某种更底层的 agent 框架。也许 Spark 依赖其中那个 Go binary，但公开材料还不能把内部架构写死。

对普通用户来说，这听起来像命名混乱。对企业安全团队来说，这就是责任边界不清。

模型犯错，谁兜底？运行时越权，谁拦截？网关能不能挡住敏感数据外流？凭据在哪里解密？日志谁能看？这些问题不性感，但每一个都比发布会演示更要命。

Google 把安全押在托管运行时上

Google Cloud 面向企业客户的文章给了目前最完整的安全描述：Spark 运行在 Google Cloud 的全托管安全运行时里；每个任务都会在新的、严格隔离的临时 VM 中执行；所有流量经过 Agent Gateway，并执行 DLP 策略；用户凭据加密，且不会直接暴露给 agent。

这套设计方向是对的。

隔离 VM 是为了减少会话之间的数据重叠。Agent Gateway 和 DLP 是为了拦截敏感信息外流。凭据不直接交给 agent，是为了避免模型或工具链把钥匙拿在手里乱跑。

问题是，方向正确不等于已经可靠。

AI Agent 的难点不是单点防护，而是组合风险。邮件里的一段恶意指令、文档里的隐藏提示、网页里的注入内容，都可能诱导 agent 做错事。Prompt injection 不是科幻问题，恰恰是 Agent 进入真实账户之后最该盯的现实风险。

这里不能断言 Google 一定会出事故。没有证据就不能这么写。

但可以说，Spark 已经具备高风险候选的条件：高权限、深度集成、托管执行、用户凭据、企业数据流。只要其中一层边界没守住，后果就不再是“回答错了”，而可能是越权访问、误发邮件、泄露文件或绕过 DLP。

企业客户现在最实际的动作，不是急着采购，也不是一棍子打死。

更稳的做法是延后进入核心业务场景，先要求 Google 给出更细的安全白皮书、审计材料、日志能力、权限撤销机制和 prompt injection 防护边界。开发者团队则要把 Spark 当成一个高权限平台来评估，而不是当成普通 API。

普通 Google 用户也该更保守一点。等它真正开放后，先从低敏数据和可撤销任务开始。不要一上来就让它处理合同、财务表格、客户邮件和私人日程。

CLI 迁移暴露的是平台控制权

还有一个容易被发布会热闹盖过去的变化：Google 宣布开源 Gemini CLI 将在 6 月 18 日停止支持 AI 订阅计划，替代品是新的闭源 Antigravity CLI。

旧的 Gemini CLI 是 Apache 2.0 许可的 TypeScript 项目。开发者能看代码，能审行为，能围绕它写脚本、接内部流程、做二次封装。

闭源 Antigravity CLI 不等于坏，也不等于不安全。很多企业级安全产品本来就是闭源，靠的是中心化治理、快速更新和统一策略。

但 Agent 工具链不太一样。

它连接模型、文件系统、终端、凭据、云服务和企业数据。越靠近执行层，越需要被审计。越靠近权限层，越需要被质疑。

这就是开发者信任成本的来源。

开源工具换成闭源工具，开发者少了一部分可见性。企业要做内控，也会多一道评估：它到底执行了什么？上传了什么？保留了什么？接口会不会再变？订阅计划和工具链绑定之后，迁移是不是越来越难？

这不是 Google 独有的问题。PC 时代，操作系统靠权限模型吃掉了应用入口；移动互联网时代，应用商店靠审核和分发吃掉了开发者入口。今天 Agent 也在重复类似路径，只是入口从图标和插件，变成了自然语言任务和托管运行时。

不完全一样，但权力结构很像。

“天下熙熙，皆为利来。”放到这里，不是说 Google 只为了收费。更准确地说，AI Agent 的商业利益正在从模型调用费，转向谁控制执行环境、凭据流和开发者入口。

Google 这次做对了一件事：它没有只喊“智能体”，而是把隔离 VM、Agent Gateway、DLP、凭据保护这些硬问题摆出来。

但代价也摆在这里。

Agent 越像轻量操作系统，闭源化的成本越大。不是因为闭源天然有罪，而是因为用户把更多权限交出去之后，平台就必须拿出更多可验证的边界。

接下来真正要看四件事：Spark 何时从 coming soon 进入可用状态；Antigravity 在架构里的边界能不能讲清；Google 是否提供足够细的安全与审计材料；6 月 18 日之后，开发者从 Gemini CLI 迁到 Antigravity CLI 的摩擦有多大。

如果这些问题回答得好，Spark 可能成为 Google Agent 战略里最关键的入口。

如果回答不好，它也会成为最典型的 Agent 安全压力测试：模型看着更强，产品反而更危险，因为权限已经进门了。