AI手机的分水岭来了：豆包、千问、Gemini走出了三条路

在上月底举办的三星 Galaxy S26 发布会上，三星和谷歌官宣将在 Galaxy S26 上首发基于 Gemini 的 Screen Automation（屏幕自动化）的能力。

简单来说，就是 Gemini 可以直接在手机屏幕上操作应用：打开 APP、识别屏幕、点击滑动、输入文字……完成一连串 UI 操作，最后再把确认步骤交给用户。

图片来源：三星

没错，听起来就和努比亚 M153（坊间俗称「豆包手机」）上的豆包手机助手一样，都是能替代人类在手机上进行「代理」操作，实现一句话点外卖、叫车、网购等需求。

从海外媒体和论坛的反馈来看，这项功能终于在最近的测试版更新中上线了。

不过我们也发现，谷歌并没有全盘学习豆包手机助手的做法。虽然在技术实现路径上同样基于 GUI 的 Agent，但 Gemini 会基于 Android 开启一个本地的虚拟沙盒，同时还主动限制了首批开放 Gemini「操作」的 APP，仅限少数一批应用。

这种处理方式与国内厂商显然不太一样。甚至可以对比字节的豆包手机助手和阿里的千问，谷歌选择了一条看起来既激进、又保守的路线。

让 AI 操作系统，而不是接管手机

只看功能表面，Gemini 的「屏幕自动化」很容易被理解为另一种「豆包手机助手」。它同样可以替你点外卖、叫车、下单，看起来也像一个能替人操作手机的 AI 代理。

但如果把视角往下再挖一层，就会发现谷歌的方案其实完全不是一回事。

豆包手机助手的逻辑很简单：AI 读取屏幕像素，像人眼一样识别按钮和输入框，然后模拟手指点击。这种方式最大的优点就是通用——理论上任何 APP 都能操作，因为 AI 看到的只是屏幕。

Gemini 明显更「保守」。在实际执行任务时，Gemini 并不会直接在你的手机桌面上操作应用，而是会在 Android 系统里开启一个本地的虚拟沙盒窗口，让 AI 在这个环境里运行目标 APP。

整个过程是可见的，用户可以随时终止任务，也可以在任何一步接管操作。

图片来源：Android Central

简单来说，Gemini「屏幕自动化」在产品定位上并不是一个可以随意操控手机的万能代理，而是一个被系统严格约束的自动化能力。

谷歌还主动限制了第一批支持自动化的应用数量。目前开放的主要是打车、外卖和餐饮类服务，仅支持 Lyft、Uber、GrubHub、DoorDash、Uber Eats 和星巴克。

也限制了「用户范围」。目前除了三星 Galaxy S26 系列已经可以在测试版中体验，谷歌也仅规划了 Pixel 10 系列支持，同时 Gemini 免费用户每天仅有 5 次使用额度、Plus 会员 12 次、Pro 会员 20 次、Ultra 会员 120 次。

这里既有算力的考量，也在于用户对 AI「乱动手机」的担忧，尤其是在欧美市场。所以谷歌做了权限隔离、关键步骤必须要用户手动操作、可以实时中断 AI 操作等。

但说到底，这只是过渡阶段，谷歌的野心绝不止是让 Gemini 仅仅能够操作几个特定 APP。

图片来源：谷歌

很多人注意到 Gemini 的 GUI 操作能力，却忽略了 Android 在系统层面正在发生的一件事情。

就在三星 Galaxy S26 系列发布会前夕，谷歌官方发布了一篇博文名为《智能操作系统：让 AI 代理对安卓应用更有帮助》，并正式推出了一套新的应用能力接口体系——AppFunctions，允许 APP 主动向系统声明自己可以被 AI 调用的功能。

举个例子，一个外卖 APP 可以告诉系统：支持搜索餐厅、添加商品、提交订单这些能力。当用户对 Gemini 说「帮我点一份披萨」时，AI 并不一定需要逐步点击界面，它可以直接调用这些能力完成任务。

如果把这套机制理解成 AI 的「函数调用」，事情就变得非常清晰了。在谷歌的设计里，AI 代理其实有两条路径可以执行任务，一种是通过系统接口直接调用应用能力，另一种才是通过识别屏幕界面来进行 GUI 自动化。

前者效率更高、稳定性更好；后者则是为了兼容那些没有适配新接口的应用。

这意味着 Gemini 未来的设备自动化能力，本质上并不是单纯的「AI 看屏幕操作手机」，而是一种系统 API 与 GUI 混合的架构。

AppFunctions 的应用示例，图片来源：雷科技

这个差异听起来有点技术化，但它背后的产品逻辑其实非常简单。相比豆包手机助手让 AI 像人一样使用手机，谷歌想做的事情是让 AI 像系统一样调度应用。

当 AI 只是读取屏幕像素时，它始终站在系统之外，只能模仿人的操作逻辑；但一旦 AI 被放进操作系统内部，它就可以直接协调应用之间的能力。

从这个角度看，Gemini Screen Automation 的真正目标或许并不是点外卖、叫车这些场景。谷歌真正想建立的，是一种新的 Android 运行逻辑和生态。从这里出发，我们也能在一定程度上明白，为什么谷歌要和高通联手推动「安卓电脑」（非 Chromebook）。

也解释了为什么 Gemini 的方案看起来既激进又保守。

激进的地方在于，它试图把 AI 变成 Android 的调度中心；保守在于，谷歌并不打算让 AI 随意接管整个手机，而是通过系统接口、权限控制和应用白名单，一步一步推进这种变化。

相比「万能 AI 代理」的想象，这种路线显然更慢，也更克制。但对于一个拥有数十亿设备的操作系统来说，谷歌可能也没有太多激进试错的空间。

豆包向左，千问向右，Gemini 走中间

相比谷歌在手机上的做法，去年底亮相的豆包手机助手选择了最简单、也最激进的一种方式：让 AI 像人一样使用手机。

在这套方案里，AI 读取屏幕像素，识别按钮、输入框和页面结构，然后模拟手指点击完成操作。无论是点外卖、比价购物还是下单支付，AI 都是在手机界面上一步步执行。

这种方式最大的优势就是通用。因为 AI 看到的只是屏幕，它不需要任何 APP 的接口支持，也不需要平台授权。理论上，只要是人能操作的应用，AI 都可以完成同样的操作。

这也是为什么很多人第一次体验豆包手机助手时，会觉得它像一种「真正的 AI 手机」。

图片来源：豆包

但问题也同样明显。当 AI 可以读取整个屏幕并操作所有应用时，权限和安全问题就不可避免。同时，很多互联网平台也并不欢迎这种自动化行为，因为它绕过了平台自身的入口和推荐体系。

简单说，豆包的路线技术上非常直接，但也天然会和应用生态产生摩擦。

相比之下，阿里的千问走的是另一条思路，利用阿里自己的服务生态，让 AI 成为一个调度中心。在这套体系里，用户的一句话会被拆解成具体任务，然后分别调用淘宝、支付宝、高德、飞猪等服务来完成。

比如搜索商品、下单支付、规划路线，都是直接调用真实业务能力，而不是模拟界面操作。因为所有操作都发生在生态内部，AI 不需要绕过应用权限，也不会触发平台风控，又因为直接调用服务接口，执行效率往往也更高。

图片来源：雷科技

但问题同样清晰：生态边界。千问能够调度的服务，本质上还是阿里系应用。一旦用户需求涉及其他平台，能力就会明显下降。

从这个角度看，豆包和千问其实代表了两种非常典型的 AI 代理路径。前者试图让 AI 接管手机本身，追求的是通用能力；后者则通过生态整合，让 AI 接管服务流程，追求的是业务深度。

而谷歌的 Gemini，某种程度上站在二者之间。在当前阶段，Gemini 依然保留了 GUI 自动化能力，这意味着它在必要时也可以像豆包一样，通过识别界面来操作应用。但与此同时，谷歌又在 Android 系统里引入了新的应用能力接口，让 APP 主动向系统开放可以被 AI 调用的功能。

如果应用支持这些接口，Gemini 就不需要再逐步点击界面，而是可以直接调用应用能力完成任务。换句话说，谷歌的方案其实是一种混合路径：

系统接口优先，GUI 自动化兜底。

从短期来看，这种方式显然没有豆包那样惊艳，也不像千问那样能够迅速整合成熟生态。但它的好处在于，既避免了和应用生态的正面冲突，又保留了足够的通用性。

写在最后

把视角再拉远一点，其实不难理解三种路线为什么会分化成现在这样。

字节没有操作系统，也没有本地生活生态，所以只能让 AI 直接接管手机；阿里拥有庞大的服务体系，于是让 AI 去调度自己的业务网络；而谷歌真正拥有的，则是 Android 这个覆盖数十亿设备的操作系统。

因此，Gemini 的目标从一开始就不是做一个更强的手机助手，而是把 AI 变成系统的一部分，让 Android 从「运行应用的平台」慢慢变成「调度应用的智能系统」。从这个角度看，Gemini 的克制并不是保守，而更像是一种平台级公司的必然选择。