今天凌晨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 SDK），Spark的架构可以分为三层：
Layer 1：Agent 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; } List<Task> 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 2：Orchestration 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 job），Anthropic的Claude Code是"在terminal里陪你pair programming"（类似REPL），而Spark是"后台一直转着的daemon"。三者对应了三种完全不同的Agent运行模型。
Layer 3：MCP Gateway（工具连接层）
这层负责和外部世界对话。Spark原生支持Google全家桶（Gmail/Calendar/Drive/Docs/Sheets/Slides），同时通过**MCP（Model 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 Spark（Google）
运行模型：Cloud VM上的永续daemon
生命周期：天级（7×24运行）
交互方式：异步（做完了通知你）
能力边界：Google生态全打通 + MCP第三方
定价：$100/月 (AI Ultra订阅)
Claude Code（Anthropic）
运行模型：Terminal内的REPL Agent
生命周期：会话级（关terminal就没了）
交互方式：同步（实时pair programming）
能力边界：文件系统 + shell + MCP
定价：按token计费
ChatGPT Operator（OpenAI）
运行模型：浏览器沙箱内的操作者
生命周期：任务级（完成就结束）
交互方式：半同步（需要用户在旁监督）
能力边界：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发明了MCP，Google拥抱了MCP，OpenAI也在跟进。如果你在做任何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帮他转钱。攻击面比传统产品大了几个数量级。
"全天候"的paradox：Agent越智能、越自主，用户就越不关注它在做什么。但一旦它犯了错（比如误判一封促销邮件为"重要账单"并自动付款），用户可能很长时间都不会发现。"低打扰"和"安全监督"之间的张力是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的平台，那套声明式安全策略的设计思路都值得借鉴。
觉得有收获？转发给你的工程师朋友。下期见。
