简单来说，就是 Gemini 可以直接在手机屏幕上操作应用：打开 APP、识别屏幕、点击滑动、输入文字……完成一连串 UI 操作，最后再把确认步骤交给用户。 没错，听起来就和努比亚 M153（坊间俗称「豆包手机」）上的豆包手机助手一样，都是能替代人类在手机上进行「代理」操作，实现一句话点外卖、叫车、网购等需求。 不过我们也发现，谷歌并没有全盘学习豆包手机助手的做法。虽然在技术实现路径上同样基于 GUI 的 Agent，但 Gemini 会基于 Android 开启一个本地的虚拟沙盒，同时还主动限制了首批开放 Gemini「操作」的 APP，仅限少数一批应用。 这种处理方式与国内厂商显然不太一样。甚至可以对比字节的豆包手机助手和阿里的千问，谷歌选择了一条看起来既激进、又保守的路线。 只看功能表面，Gemini 的「屏幕自动化」很容易被理解为另一种「豆包手机助手」。它同样可以替你点外卖、叫车、下单，看起来也像一个能替人操作手机的 AI 代理。 豆包手机助手的逻辑很简单：AI 读取屏幕像素，像人眼一样识别按钮和输入框，然后模拟手指点击。这种方式最大的优点就是通用——理论上任何 APP 都能操作，因为 AI 看到的只是屏幕。 Gemini 明显更「保守」。在实际执行任务时，Gemini 并不会直接在你的手机桌面上操作应用，而是会在 Android 系统里开启一个本地的虚拟沙盒窗口，让 AI 在这个环境里运行目标 APP。 简单来说，Gemini「屏幕自动化」在产品定位上并不是一个可以随意操控手机的万能代理，而是一个被系统严格约束的自动化能力。 也限制了「用户范围」。目前除了三星 Galaxy S26 系列已经可以在测试版中体验，谷歌也仅规划了 Pixel 10 系列支持，同时 Gemini 免费用户每天仅有 5 次使用额度、Plus 会员 12 次、Pro 会员 20 次、Ultra 会员 120 次。 这里既有算力的考量，也在于用户对 AI「乱动手机」的担忧，尤其是在欧美市场。所以谷歌做了权限隔离、关键步骤必须要用户手动操作、可以实时中断 AI 操作等。 就在三星 Galaxy S26 系列发布会前夕，谷歌官方发布了一篇博文名为《智能操作系统：让 AI 代理对安卓应用更有帮助》，并正式推出了一套新的应用能力接口体系——AppFunctions，允许 APP 主动向系统声明自己可以被 AI 调用的功能。 举个例子，一个外卖 APP 可以告诉系统：支持搜索餐厅、添加商品、提交订单这些能力。当用户对 Gemini 说「帮我点一份披萨」时，AI 并不一定需要逐步点击界面，它可以直接调用这些能力完成任务。 如果把这套机制理解成 AI 的「函数调用」，事情就变得非常清晰了。在谷歌的设计里，AI 代理其实有两条路径可以执行任务，一种是通过系统接口直接调用应用能力，另一种才是通过识别屏幕界面来进行 GUI 自动化。 这个差异听起来有点技术化，但它背后的产品逻辑其实非常简单。相比豆包手机助手让 AI 像人一样使用手机，谷歌想做的事情是让 AI 像系统一样调度应用。 当 AI 只是读取屏幕像素时，它始终站在系统之外，只能模仿人的操作逻辑；但一旦 AI 被放进操作系统内部，它就可以直接协调应用之间的能力。 从这个角度看，Gemini Screen Automation 的真正目标或许并不是点外卖、叫车这些场景。谷歌真正想建立的，是一种新的 Android 运行逻辑和生态。从这里出发，我们也能在一定程度上明白，为什么谷歌要和高通联手推动「安卓电脑」（非 Chromebook）。 激进的地方在于，它试图把 AI 变成 Android 的调度中心；保守在于，谷歌并不打算让 AI 随意接管整个手机，而是通过系统接口、权限控制和应用白名单，一步一步推进这种变化。 相比「万能 AI 代理」的想象，这种路线显然更慢，也更克制。但对于一个拥有数十亿设备的操作系统来说，谷歌可能也没有太多激进试错的空间。 在这套方案里，AI 读取屏幕像素，识别按钮、输入框和页面结构，然后模拟手指点击完成操作。无论是点外卖、比价购物还是下单支付，AI 都是在手机界面上一步步执行。 这种方式最大的优势就是通用。因为 AI 看到的只是屏幕，它不需要任何 APP 的接口支持，也不需要平台授权。理论上，只要是人能操作的应用，AI 都可以完成同样的操作。 但问题也同样明显。当 AI 可以读取整个屏幕并操作所有应用时，权限和安全问题就不可避免。同时，很多互联网平台也并不欢迎这种自动化行为，因为它绕过了平台自身的入口和推荐体系。 相比之下，阿里的千问走的是另一条思路，利用阿里自己的服务生态，让 AI 成为一个调度中心。在这套体系里，用户的一句话会被拆解成具体任务，然后分别调用淘宝、支付宝、高德、飞猪等服务来完成。 比如搜索商品、下单支付、规划路线，都是直接调用真实业务能力，而不是模拟界面操作。因为所有操作都发生在生态内部，AI 不需要绕过应用权限，也不会触发平台风控，又因为直接调用服务接口，执行效率往往也更高。 但问题同样清晰：生态边界。千问能够调度的服务，本质上还是阿里系应用。一旦用户需求涉及其他平台，能力就会明显下降。 从这个角度看，豆包和千问其实代表了两种非常典型的 AI 代理路径。前者试图让 AI 接管手机本身，追求的是通用能力；后者则通过生态整合，让 AI 接管服务流程，追求的是业务深度。 而谷歌的 Gemini，某种程度上站在二者之间。在当前阶段，Gemini 依然保留了 GUI 自动化能力，这意味着它在必要时也可以像豆包一样，通过识别界面来操作应用。但与此同时，谷歌又在 Android 系统里引入了新的应用能力接口，让 APP 主动向系统开放可以被 AI 调用的功能。 如果应用支持这些接口，Gemini 就不需要再逐步点击界面，而是可以直接调用应用能力完成任务。换句话说，谷歌的方案其实是一种混合路径： 从短期来看，这种方式显然没有豆包那样惊艳，也不像千问那样能够迅速整合成熟生态。但它的好处在于，既避免了和应用生态的正面冲突，又保留了足够的通用性。 字节没有操作系统，也没有本地生活生态，所以只能让 AI 直接接管手机；阿里拥有庞大的服务体系，于是让 AI 去调度自己的业务网络；而谷歌真正拥有的，则是 Android 这个覆盖数十亿设备的操作系统。 因此，Gemini 的目标从一开始就不是做一个更强的手机助手，而是把 AI 变成系统的一部分，让 Android 从「运行应用的平台」慢慢变成「调度应用的智能系统」。从这个角度看，Gemini 的克制并不是保守，而更像是一种平台级公司的必然选择。
京公网安备11010202000001号
