Persistent Agent Layer: Gemini Spark 让我重新看后台代理

后台代理从演示走到日常#

今天我想写的不是“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 正在从前台问答，进入后台托管。模型公司、云厂商、办公套件、浏览器都会往这里挤。最后留下来的，不一定是最会聊天的助手，而是那个能在我关掉电脑之后，还可靠地替我维护一小部分数字生活的人机协作层。