今天凌晨1点Google I/O 2026开幕。整场发布会信息量爆炸但如果只让我选一个最值得工程师深挖的产品我会毫不犹豫地选Gemini Spark。不是因为它最酷炫——Omni的视频生成显然更有视觉冲击力。而是因为Spark代表了一个根本性的架构范式转移AI助手从请求-响应模式进化为持续运行的后台Agent。这意味着什么意味着你的AI不再是一个被动的命令行工具而是一个7×24小时运行在云端VM上的数字员工。作为一个正在折腾各种Agent框架的工程师看到这个架构设计我是既兴奋又恐惧的——兴奋是因为终于有大厂把永续Agent这件事工程化落地了恐惧是因为……它暴露的架构复杂度简直是一座冰山。今天就来从工程视角一层层拆开这个产品。从Stateless到Stateful一次范式级跃迁先说一个直觉上的对比。过去的Gemini Assistant包括ChatGPT、Claude本质上都是无状态的你发一条消息模型生成一个回复这次会话就结束了。Extensions和Function Calling让它能在对话中调用工具但每次交互仍然受限于一个请求生命周期——用完即释放。Spark打破了这个模型。它的核心特征用一句话概括一个持久化运行在Google Cloud VM上的Agent进程维护跨小时/天的目标状态自主执行异步任务。普通的API调用生命周期是秒级。Spark的生命周期是天级。这个gap就是整个产品。用个类比过去的AI助手是你叫了一辆出租车——上车说目的地、到了下车、司机走人。Spark是你雇了一个全职司机——他24小时在车库待命你没上车的时候他也在帮你洗车加油检查路况。架构拆解Spark的三层设计根据Google I/O上披露的信息和开发者文档Antigravity 2.0 SDKSpark的架构可以分为三层Layer 1Agent Harness代理容器这是Spark的操作系统。负责•Goal Persistence目标状态持久化。你说帮我追踪下周二那个面试的所有准备材料这个目标不会因为你合上笔记本就消失。•Task Decomposition把一个大目标拆成可执行的子任务序列。•Tool Orchestration按序或并行调用外部工具Gmail、Calendar、Drive等。•Safety Constraints边界控制——哪些操作可以自主执行哪些必须征求用户同意。•State Recovery崩溃恢复。VM挂了怎么办任务执行到一半断了怎么办从工程角度看这就是一个经典的有状态长时任务调度器。如果你做过消息队列或者workflow engine比如Temporal/Cadence会觉得这套东西很眼熟。本质上是// 伪代码Spark Agent的核心循环 while (agent.isAlive()) { Goal goal goalStore.getNext(); if (goal null) { // 没有主动目标时进入监控模式 monitorInbox(); monitorCalendar(); checkTriggers(); sleep(POLL_INTERVAL); continue; } ListTask tasks decompose(goal); for (Task task : tasks) { if (task.requiresApproval()) { requestUserConfirmation(task); continue; // 等用户回复 } Result result execute(task); goalStore.updateProgress(goal, result); checkpoint(); // 持久化状态 } }注意那个checkpoint()——这是永续Agent最关键的设计点。没有它VM一重启你的Agent就失忆了。有了它即使宿主机器挂了新VM拉起来能从上次的checkpoint继续执行。Layer 2Orchestration Layer编排层Antigravity 2.0的新能力多Agent并行编排。你可以同时起多个Agent给它们分配不同目标它们之间通过共享状态存储协调。Google给的例子是策划社区派对• Agent A 负责追踪邀请回复 → 操作Gmail• Agent B 负责生成宣传物料 → 操作Slides• Agent C 负责维护物品清单 → 操作Sheets• 主Agent协调三者进度汇总报告给用户在Antigravity的runtime内部每个Agent跑在独立的goroutine上没错Google用Go写的这套基础设施Agent间通信走内部消息传递而非HTTP延迟极低。这让我想到一个有意思的对比OpenAI的Codex是一次性干完一件大事类似batch jobAnthropic的Claude Code是在terminal里陪你pair programming类似REPL而Spark是后台一直转着的daemon。三者对应了三种完全不同的Agent运行模型。Layer 3MCP Gateway工具连接层这层负责和外部世界对话。Spark原生支持Google全家桶Gmail/Calendar/Drive/Docs/Sheets/Slides同时通过**MCPModel Context Protocol**连接第三方服务。MCP是Anthropic去年底开源的协议Google现在正式拥抱了它。Antigravity 2.0的manifest配置长这样# Antigravity 2.0 Agent Manifest name: pr-review-agent model: gemini-3.5-flash persistence: cloud tools: mcp_servers: - endpoint: https://github.mcp.io auth: oauth - endpoint: https://notion.mcp.io auth: bearer_token - endpoint: http://localhost:3001 auth: none goals: - name: daily-pr-digest trigger: cron(0 9 * * 1-5) task: | Review all PRs opened since yesterday. Summarize findings and post to Slack. safety: max_tool_calls_per_goal: 50 require_user_confirm: - git_push - send_email - payment_*几个值得注意的设计决策•声明式安全策略不是在代码里写if-else判断这个操作危不危险而是在manifest里声明哪些工具调用需要人工确认。这是对Agent失控风险的工程化管理。•MCP作为统一协议不管后面接的是GitHub还是你自己的内部API对Agent来说都是一个MCP endpoint。这极大降低了工具集成的复杂度。•Cron触发器Agent不仅响应用户指令还能按时间表自主执行。这就是全天候的工程实现。Gemini 3.5 Flash为Agent场景优化的模型Spark跑的底座模型是今天同步发布的Gemini 3.5 Flash。这不是巧合——Google明确说这个模型是为Agent任务优化的。关键指标输出token速度是其他前沿模型的4倍。为什么Agent场景对速度这么敏感因为一个永续Agent的工作模式是这样的接收触发信号↓模型推理分析上下文 决策下一步↓调用工具 → 等待响应↓模型推理解析结果 决策下一步↓调用下一个工具…↓ (循环多次)完成目标 / 产出结果一个Agent任务里模型可能要推理5-20次每次工具调用前后各一次决策。如果每次推理要3秒串行下来就是30-60秒的延迟。但如果推理速度提升4倍每次0.75秒总延迟就降到7-15秒。对于帮我检查收件箱有没有紧急邮件这种任务15秒和60秒的体验天差地别。这也是为什么Google选了Flash而不是Pro来跑Spark——Agent场景需要的是又快又便宜的推理而不是单次最强的推理能力。一个7×24小时在线的Agent每天可能要执行成百上千次推理成本控制是生死线。安全设计Agent权限的边界在哪一个能读你邮件、改你日历、替你下单的Agent安全设计不到位就是灾难。Spark在这块做了几层防护分级授权Tiered Permissions不是一股脑把所有权限给Agent而是分三档•自主执行读取类操作看邮件/查日历/搜Drive不需要确认•通知后执行低风险写入草拟邮件/创建文档先做再告诉你•必须确认高风险操作发送邮件/金额交易/删除数据必须等用户点确认每目标工具调用上限Manifest里的max_tool_calls_per_goal: 50是一个硬限制。防止Agent进入死循环或者被恶意prompt注入后无限调用API。一个goal最多调50次工具超了就停下来报告。通配符拦截require_user_confirm: [payment_*]——任何以payment_开头的工具调用都需要确认。这种设计很工程化你不需要枚举每个支付接口的名字用pattern matching覆盖整类操作。但问题来了当Agent被设计为尽量不打扰用户的时候过多确认弹窗会破坏产品体验。这是一个本质矛盾——安全和便利的trade-off永远存在Spark选择了把这个决策权交给用户自己配置。对比Spark vs Claude Code vs ChatGPT Operator现在市面上有三种主流的Agent形态它们代表了三种完全不同的技术路线Gemini SparkGoogle运行模型Cloud VM上的永续daemon生命周期天级7×24运行交互方式异步做完了通知你能力边界Google生态全打通 MCP第三方定价$100/月 (AI Ultra订阅)Claude CodeAnthropic运行模型Terminal内的REPL Agent生命周期会话级关terminal就没了交互方式同步实时pair programming能力边界文件系统 shell MCP定价按token计费ChatGPT OperatorOpenAI运行模型浏览器沙箱内的操作者生命周期任务级完成就结束交互方式半同步需要用户在旁监督能力边界Web界面操作定价$200/月 (Pro订阅)三者的核心差异在于Agent的活跃时间窗口• Operator只在你盯着的时候干活像监工实习生的关系• Claude Code在你开着Terminal的时候陪你干活像pair partner• Spark在你睡觉的时候还在干活像全职员工从工程复杂度来说Spark是量级最高的。你要解决的问题包括但不限于状态持久化、故障恢复、长上下文管理跨天的对话记忆怎么压缩、资源调度一台VM跑一个Agent还是多个Agent共享、安全隔离Agent A的数据不能泄露给Agent B……Google选择了最难的路线。但它也有做这件事的独特优势它拥有用户的Gmail、Calendar、Drive等核心数据源。Spark不需要像Operator那样通过笨拙的浏览器操作来获取信息——它能直接读API。这是基础设施级的护城河。工程师视角这意味着什么对于我们做应用开发的人来说Spark的出现意味着几件事MCP成了事实标准Anthropic发明了MCPGoogle拥抱了MCPOpenAI也在跟进。如果你在做任何2B的SaaS产品现在就该考虑暴露一个MCP endpoint了。未来用户可能不再亲自打开你的App——他们的Spark会帮他们调你的API完成操作。永续Agent的基础设施正在成熟之前自己搭一个7×24的Agent你需要操心进程管理、状态存储、故障恢复、安全隔离……现在Antigravity 2.0把这些全包了。就像Docker简化了部署一样Antigravity可能会简化Agent的运维。新的应用分发逻辑App Store时代用户安装App → 用户打开App → 用户操作App。Agent时代Agent发现服务 → Agent代替用户操作 → 用户看结果。如果这个趋势成真用户获取的逻辑会被彻底颠覆。你不再是在争夺用户的注意力而是在争夺Agent的信任度——让Agent在需要订酒店的时候优先想到你的服务。我的几个观察和疑问最后说几个不那么乐观的思考成本问题$100/月的定价背后是一台一直在跑的Cloud VM 每天成百上千次模型推理。Google目前肯定是亏钱推的。但用户一旦习惯了24小时在线的AI管家想涨价就难了。这是个经典的习惯绑定 → 变现策略。隐私风险Spark要持续访问你的邮件、位置、浏览记录、购物习惯。这些数据集中在Google的一台VM上。一旦账号被攻破损失不只是读了你的邮件——攻击者可以直接让Agent帮他转钱。攻击面比传统产品大了几个数量级。全天候的paradoxAgent越智能、越自主用户就越不关注它在做什么。但一旦它犯了错比如误判一封促销邮件为重要账单并自动付款用户可能很长时间都不会发现。低打扰和安全监督之间的张力是Spark最大的设计挑战。Antigravity开放度现在SDK刚发布生态还是空的。Google能不能像当年Android那样吸引开发者来构建Agent生态还是会像Google一样雷声大雨点小这取决于Antigravity的DX开发者体验和MCP生态的成熟速度。写在最后Gemini Spark让我想起2007年的iPhone。当时所有人都在做更好的功能手机苹果直接把电脑塞进了口袋里。现在所有AI公司都在做更好的聊天机器人Google直接给AI一台云服务器让它7×24自己转着。这可能是AI产品从工具进化为代理的真正起点。不是那种PPT里的概念而是有VM、有cron job、有状态持久化、有安全策略的工程现实。当然能不能成还得看落地效果。发布会Demo永远是完美的。但至少从架构设计上Spark给出了一个永续Agent应该长什么样的高质量答案。如果你也在做Agent相关的项目建议现在就去看Antigravity 2.0的文档特别是MCP Gateway那部分。不管你最终用不用Google的平台那套声明式安全策略的设计思路都值得借鉴。觉得有收获转发给你的工程师朋友。下期见。
Gemini Spark深度拆解：Google给AI一台永不关机的云服务器
今天凌晨1点Google I/O 2026开幕。整场发布会信息量爆炸但如果只让我选一个最值得工程师深挖的产品我会毫不犹豫地选Gemini Spark。不是因为它最酷炫——Omni的视频生成显然更有视觉冲击力。而是因为Spark代表了一个根本性的架构范式转移AI助手从请求-响应模式进化为持续运行的后台Agent。这意味着什么意味着你的AI不再是一个被动的命令行工具而是一个7×24小时运行在云端VM上的数字员工。作为一个正在折腾各种Agent框架的工程师看到这个架构设计我是既兴奋又恐惧的——兴奋是因为终于有大厂把永续Agent这件事工程化落地了恐惧是因为……它暴露的架构复杂度简直是一座冰山。今天就来从工程视角一层层拆开这个产品。从Stateless到Stateful一次范式级跃迁先说一个直觉上的对比。过去的Gemini Assistant包括ChatGPT、Claude本质上都是无状态的你发一条消息模型生成一个回复这次会话就结束了。Extensions和Function Calling让它能在对话中调用工具但每次交互仍然受限于一个请求生命周期——用完即释放。Spark打破了这个模型。它的核心特征用一句话概括一个持久化运行在Google Cloud VM上的Agent进程维护跨小时/天的目标状态自主执行异步任务。普通的API调用生命周期是秒级。Spark的生命周期是天级。这个gap就是整个产品。用个类比过去的AI助手是你叫了一辆出租车——上车说目的地、到了下车、司机走人。Spark是你雇了一个全职司机——他24小时在车库待命你没上车的时候他也在帮你洗车加油检查路况。架构拆解Spark的三层设计根据Google I/O上披露的信息和开发者文档Antigravity 2.0 SDKSpark的架构可以分为三层Layer 1Agent Harness代理容器这是Spark的操作系统。负责•Goal Persistence目标状态持久化。你说帮我追踪下周二那个面试的所有准备材料这个目标不会因为你合上笔记本就消失。•Task Decomposition把一个大目标拆成可执行的子任务序列。•Tool Orchestration按序或并行调用外部工具Gmail、Calendar、Drive等。•Safety Constraints边界控制——哪些操作可以自主执行哪些必须征求用户同意。•State Recovery崩溃恢复。VM挂了怎么办任务执行到一半断了怎么办从工程角度看这就是一个经典的有状态长时任务调度器。如果你做过消息队列或者workflow engine比如Temporal/Cadence会觉得这套东西很眼熟。本质上是// 伪代码Spark Agent的核心循环 while (agent.isAlive()) { Goal goal goalStore.getNext(); if (goal null) { // 没有主动目标时进入监控模式 monitorInbox(); monitorCalendar(); checkTriggers(); sleep(POLL_INTERVAL); continue; } ListTask tasks decompose(goal); for (Task task : tasks) { if (task.requiresApproval()) { requestUserConfirmation(task); continue; // 等用户回复 } Result result execute(task); goalStore.updateProgress(goal, result); checkpoint(); // 持久化状态 } }注意那个checkpoint()——这是永续Agent最关键的设计点。没有它VM一重启你的Agent就失忆了。有了它即使宿主机器挂了新VM拉起来能从上次的checkpoint继续执行。Layer 2Orchestration Layer编排层Antigravity 2.0的新能力多Agent并行编排。你可以同时起多个Agent给它们分配不同目标它们之间通过共享状态存储协调。Google给的例子是策划社区派对• Agent A 负责追踪邀请回复 → 操作Gmail• Agent B 负责生成宣传物料 → 操作Slides• Agent C 负责维护物品清单 → 操作Sheets• 主Agent协调三者进度汇总报告给用户在Antigravity的runtime内部每个Agent跑在独立的goroutine上没错Google用Go写的这套基础设施Agent间通信走内部消息传递而非HTTP延迟极低。这让我想到一个有意思的对比OpenAI的Codex是一次性干完一件大事类似batch jobAnthropic的Claude Code是在terminal里陪你pair programming类似REPL而Spark是后台一直转着的daemon。三者对应了三种完全不同的Agent运行模型。Layer 3MCP Gateway工具连接层这层负责和外部世界对话。Spark原生支持Google全家桶Gmail/Calendar/Drive/Docs/Sheets/Slides同时通过**MCPModel Context Protocol**连接第三方服务。MCP是Anthropic去年底开源的协议Google现在正式拥抱了它。Antigravity 2.0的manifest配置长这样# Antigravity 2.0 Agent Manifest name: pr-review-agent model: gemini-3.5-flash persistence: cloud tools: mcp_servers: - endpoint: https://github.mcp.io auth: oauth - endpoint: https://notion.mcp.io auth: bearer_token - endpoint: http://localhost:3001 auth: none goals: - name: daily-pr-digest trigger: cron(0 9 * * 1-5) task: | Review all PRs opened since yesterday. Summarize findings and post to Slack. safety: max_tool_calls_per_goal: 50 require_user_confirm: - git_push - send_email - payment_*几个值得注意的设计决策•声明式安全策略不是在代码里写if-else判断这个操作危不危险而是在manifest里声明哪些工具调用需要人工确认。这是对Agent失控风险的工程化管理。•MCP作为统一协议不管后面接的是GitHub还是你自己的内部API对Agent来说都是一个MCP endpoint。这极大降低了工具集成的复杂度。•Cron触发器Agent不仅响应用户指令还能按时间表自主执行。这就是全天候的工程实现。Gemini 3.5 Flash为Agent场景优化的模型Spark跑的底座模型是今天同步发布的Gemini 3.5 Flash。这不是巧合——Google明确说这个模型是为Agent任务优化的。关键指标输出token速度是其他前沿模型的4倍。为什么Agent场景对速度这么敏感因为一个永续Agent的工作模式是这样的接收触发信号↓模型推理分析上下文 决策下一步↓调用工具 → 等待响应↓模型推理解析结果 决策下一步↓调用下一个工具…↓ (循环多次)完成目标 / 产出结果一个Agent任务里模型可能要推理5-20次每次工具调用前后各一次决策。如果每次推理要3秒串行下来就是30-60秒的延迟。但如果推理速度提升4倍每次0.75秒总延迟就降到7-15秒。对于帮我检查收件箱有没有紧急邮件这种任务15秒和60秒的体验天差地别。这也是为什么Google选了Flash而不是Pro来跑Spark——Agent场景需要的是又快又便宜的推理而不是单次最强的推理能力。一个7×24小时在线的Agent每天可能要执行成百上千次推理成本控制是生死线。安全设计Agent权限的边界在哪一个能读你邮件、改你日历、替你下单的Agent安全设计不到位就是灾难。Spark在这块做了几层防护分级授权Tiered Permissions不是一股脑把所有权限给Agent而是分三档•自主执行读取类操作看邮件/查日历/搜Drive不需要确认•通知后执行低风险写入草拟邮件/创建文档先做再告诉你•必须确认高风险操作发送邮件/金额交易/删除数据必须等用户点确认每目标工具调用上限Manifest里的max_tool_calls_per_goal: 50是一个硬限制。防止Agent进入死循环或者被恶意prompt注入后无限调用API。一个goal最多调50次工具超了就停下来报告。通配符拦截require_user_confirm: [payment_*]——任何以payment_开头的工具调用都需要确认。这种设计很工程化你不需要枚举每个支付接口的名字用pattern matching覆盖整类操作。但问题来了当Agent被设计为尽量不打扰用户的时候过多确认弹窗会破坏产品体验。这是一个本质矛盾——安全和便利的trade-off永远存在Spark选择了把这个决策权交给用户自己配置。对比Spark vs Claude Code vs ChatGPT Operator现在市面上有三种主流的Agent形态它们代表了三种完全不同的技术路线Gemini SparkGoogle运行模型Cloud VM上的永续daemon生命周期天级7×24运行交互方式异步做完了通知你能力边界Google生态全打通 MCP第三方定价$100/月 (AI Ultra订阅)Claude CodeAnthropic运行模型Terminal内的REPL Agent生命周期会话级关terminal就没了交互方式同步实时pair programming能力边界文件系统 shell MCP定价按token计费ChatGPT OperatorOpenAI运行模型浏览器沙箱内的操作者生命周期任务级完成就结束交互方式半同步需要用户在旁监督能力边界Web界面操作定价$200/月 (Pro订阅)三者的核心差异在于Agent的活跃时间窗口• Operator只在你盯着的时候干活像监工实习生的关系• Claude Code在你开着Terminal的时候陪你干活像pair partner• Spark在你睡觉的时候还在干活像全职员工从工程复杂度来说Spark是量级最高的。你要解决的问题包括但不限于状态持久化、故障恢复、长上下文管理跨天的对话记忆怎么压缩、资源调度一台VM跑一个Agent还是多个Agent共享、安全隔离Agent A的数据不能泄露给Agent B……Google选择了最难的路线。但它也有做这件事的独特优势它拥有用户的Gmail、Calendar、Drive等核心数据源。Spark不需要像Operator那样通过笨拙的浏览器操作来获取信息——它能直接读API。这是基础设施级的护城河。工程师视角这意味着什么对于我们做应用开发的人来说Spark的出现意味着几件事MCP成了事实标准Anthropic发明了MCPGoogle拥抱了MCPOpenAI也在跟进。如果你在做任何2B的SaaS产品现在就该考虑暴露一个MCP endpoint了。未来用户可能不再亲自打开你的App——他们的Spark会帮他们调你的API完成操作。永续Agent的基础设施正在成熟之前自己搭一个7×24的Agent你需要操心进程管理、状态存储、故障恢复、安全隔离……现在Antigravity 2.0把这些全包了。就像Docker简化了部署一样Antigravity可能会简化Agent的运维。新的应用分发逻辑App Store时代用户安装App → 用户打开App → 用户操作App。Agent时代Agent发现服务 → Agent代替用户操作 → 用户看结果。如果这个趋势成真用户获取的逻辑会被彻底颠覆。你不再是在争夺用户的注意力而是在争夺Agent的信任度——让Agent在需要订酒店的时候优先想到你的服务。我的几个观察和疑问最后说几个不那么乐观的思考成本问题$100/月的定价背后是一台一直在跑的Cloud VM 每天成百上千次模型推理。Google目前肯定是亏钱推的。但用户一旦习惯了24小时在线的AI管家想涨价就难了。这是个经典的习惯绑定 → 变现策略。隐私风险Spark要持续访问你的邮件、位置、浏览记录、购物习惯。这些数据集中在Google的一台VM上。一旦账号被攻破损失不只是读了你的邮件——攻击者可以直接让Agent帮他转钱。攻击面比传统产品大了几个数量级。全天候的paradoxAgent越智能、越自主用户就越不关注它在做什么。但一旦它犯了错比如误判一封促销邮件为重要账单并自动付款用户可能很长时间都不会发现。低打扰和安全监督之间的张力是Spark最大的设计挑战。Antigravity开放度现在SDK刚发布生态还是空的。Google能不能像当年Android那样吸引开发者来构建Agent生态还是会像Google一样雷声大雨点小这取决于Antigravity的DX开发者体验和MCP生态的成熟速度。写在最后Gemini Spark让我想起2007年的iPhone。当时所有人都在做更好的功能手机苹果直接把电脑塞进了口袋里。现在所有AI公司都在做更好的聊天机器人Google直接给AI一台云服务器让它7×24自己转着。这可能是AI产品从工具进化为代理的真正起点。不是那种PPT里的概念而是有VM、有cron job、有状态持久化、有安全策略的工程现实。当然能不能成还得看落地效果。发布会Demo永远是完美的。但至少从架构设计上Spark给出了一个永续Agent应该长什么样的高质量答案。如果你也在做Agent相关的项目建议现在就去看Antigravity 2.0的文档特别是MCP Gateway那部分。不管你最终用不用Google的平台那套声明式安全策略的设计思路都值得借鉴。觉得有收获转发给你的工程师朋友。下期见。
