Persistent Agent Layer: Gemini Spark 让我重新看后台代理
我把 Gemini Spark 看成一个信号:AI 正在从前台问答进入后台托管,真正的竞争会落到权限、日志、调度和可中断执行。
后台代理从演示走到日常#
今天我想写的不是“Google 又发了一个 AI 功能”,而是一个更具体的变化:个人 AI 代理开始从聊天窗口,挪到一个可以常驻、可调度、能接 Workspace 和浏览器的后台运行层。
近 24 小时里,Gemini Spark 的早期体验和美国 AI Ultra rollout 开始出来。TechCrunch 在 5 月 30 日发了实测,9to5Google 在 5 月 29 日写到它已经面向美国 Google AI Ultra 用户开放。官方页面给出的产品定义更直接:Spark 是一个正在扩展访问的个人 AI agent,运行在 Gemini 3.5 Flash 和 Antigravity 上,可以连接 Gmail、Calendar、Drive、Docs、Sheets、Slides、YouTube 和 Maps;核心抽象是 Tasks、Skills、Schedules。
我觉得这件事值得单独记一笔,因为它把“agent”这个词从模型能力,推到了产品操作系统。
以前的 agent 像临时工#
过去一年我自己用 coding agent、research agent、browser agent 的体验,大多还是“开一个任务,盯一段输出,等它停下来”。即使任务很长,它也像一段会话里的临时工:上下文、权限、运行环境、验收点,都跟当前窗口绑在一起。
Spark 这种形态不太一样。它把任务拆成三个一眼能懂的对象:
- Task:我要完成什么。
- Schedule:什么时候或在什么条件下自动跑。
- Skill:用什么方法、上下文和工具去跑。
这三个词不新,但它们组合在一个消费级产品里,意义就变了。用户不再是在“提示一个模型”,而是在给自己的数字生活注册后台作业。
这也是我最近越来越在意的一层:AI 产品竞争不只是模型谁更强,而是谁能把模型放进一个稳定的执行账本里。任务要能复跑,权限要能撤销,进度要能观察,失败要能接管,结果要能落到真实应用里。
Google 的优势不是模型,是入口密度#
OpenAI 和 Anthropic 做 agent 时,我经常会先想它们的执行环境:电脑使用、代码沙箱、浏览器、MCP、企业 API。Google 做 Spark 时,第一反应却是另一个问题:它已经站在 Gmail、Calendar、Drive、Docs、Sheets、Slides 的入口旁边。
这不是小差异。
个人 agent 最大的瓶颈,不一定是“能不能推理”,而是“它有没有足够多的低摩擦上下文”。邮件里有发票、会议、航班、确认函、订阅、孩子学校通知;日历里有时间约束;Drive 里有文档资产;Sheets 里有表格状态。这些东西如果还要用户手动复制给模型,agent 的价值会被输入成本吃掉一半。
Spark 的方向是把这些入口变成可授权的工作面。官方 FAQ 里也强调连接默认关闭,用户到设置里开启。这个细节很重要,因为后台代理不是一个“更聪明的搜索框”,它天然涉及持续访问和持续行动。越有用,越需要权限边界。
真正的新 UI 是可中断的后台作业#
我更关心的不是它能不能帮我找周末活动,或者能不能整理购物清单。那些 demo 很生活化,但技术趋势藏在更无聊的地方:任务线程、工作面板、计划步骤、当前步骤、完成步骤、远程浏览器接管。
这说明 agent 产品正在长出一个新的 UI 契约:
- 用户不是等一段文本,而是看一个工作流状态。
- 系统不是一次性回答,而是后台推进。
- 人不是全程操作员,而是在关键动作前审批、打断、接管。
- 应用不是被动承载结果,而是 agent 可以读写的执行场。
这套契约如果成立,未来很多个人自动化都不会先出现在 Zapier 风格的流程图里,而会出现在“我跟我的 agent 说一句,然后它给我建了一个可持续运行的 schedule”里。
这也是为什么我不太想把 Spark 看成“Google 版 ChatGPT agent”。它更像一个面向普通人的 cron,加上一层可以读懂自然语言、能跨应用操作、会在云端持续运行的执行器。
但常驻代理的风险也更硬#
我对这类产品的态度是谨慎乐观。谨慎不是因为它没用,而是因为它太可能有用。
TechCrunch 的实测里有一些很典型的小失败:优惠码不对、链接重定向出问题、请求五篇文章却返回四篇、某些 Google 自己的应用还没打通。这些问题单看都不致命,但它们提醒我:当 agent 从“回答”升级到“行动”,小误差会进入真实世界。
后台运行还会放大另一个问题:错误不再只发生在用户盯着屏幕的时候。一个每周五自动总结邮件的任务,如果摘要漏掉重要链接,只是烦;一个持续监控价格、订阅、日程、账单的任务,如果条件判断错了,可能就会变成成本。
所以我会用三条线去评价这类常驻代理:
第一,权限是不是按任务最小化,而不是一次性打开一大包访问。
第二,行动是不是有分级:读、写草稿、发出、付款、删除,不能是同一种确认模型。
第三,日志是不是够具体。不是一句“Spark 完成了任务”,而是它读了哪些来源、跳过了什么、为什么认为结果可以交付。
没有这三条,后台代理越能干,越难放心交给它。
我会怎么改自己的工作流#
如果我现在能拿到 Spark,我不会先让它“管理生活”。我会从低风险、高重复、可验收的任务开始:
- 每天早上读固定来源,生成一份 AI runtime / agent 产品变更摘要。
- 每周整理订阅邮件,把值得深读的链接放进一个文档。
- 监控账单和订阅邮件,只标出异常,不自动取消。
- 把旅行、会议、报销这类多邮件线程整理成结构化清单。
这些任务的共同点是:读多、写少;建议多、最终动作少;结果容易人工扫一眼。它们很适合作为后台代理的冷启动场景。
我不急着让 agent 直接“替我完成生活”,但我很愿意让它先替我维护几个信息雷达。因为真正消耗人的不是一次大任务,而是那些反复打开邮箱、翻聊天记录、查日历、复制链接、整理表格的小动作。
趋势判断#
我对 Gemini Spark 的判断是:它未必会以当前品牌形态成为一个独立大入口,但它代表的后台代理层会留下来。
未来 AI 产品的分水岭,可能不再是“谁的聊天窗口更强”,而是:
- 谁有可持续运行的 agent runtime;
- 谁有足够密的个人或企业数据入口;
- 谁能把权限、日志、审批做成用户愿意长期信任的产品能力;
- 谁能让 agent 的失败成本小到可以日常试用。
这也是我觉得 2026 年很值得盯的一条线:AI 正在从前台问答,进入后台托管。模型公司、云厂商、办公套件、浏览器都会往这里挤。最后留下来的,不一定是最会聊天的助手,而是那个能在我关掉电脑之后,还可靠地替我维护一小部分数字生活的人机协作层。