Gemini可代操作134款App，AI接管手机进入白名单时代

谷歌正在把Gemini从一个回答问题的助手，变成能够替用户打开应用、点击界面并完成任务的手机智能体。

11月13日，据Android Authority最新披露，谷歌服务器维护的Gemini任务自动化目标应用名单已经覆盖134款App。其中，稳定版Android 17 QPR2包含114款应用，Android Canary 2611则在此基础上增加20款测试应用，覆盖外卖、打车、购物、旅行、票务、办公和社交等场景。(androidauthority.com)

Gemini任务自动化是谷歌在Android中提供的一项AI代操作能力，它可以在受控的虚拟屏幕中启动应用，并替用户执行搜索、选择和加入购物车等步骤。

这份名单的曝光意味着，Gemini自动操作手机已经不再停留在几个演示应用上。但134这个数字也很容易制造误解：进入名单只代表应用获得了被系统自动化的资格，并不代表Gemini现在已经能够完成其中的所有任务。

114款进入稳定名单，20款仍在测试

谷歌目前为Gemini自动化设置了稳定名单和Canary测试名单两层范围。

截至11月12日，稳定版Android 17 QPR2的目标应用列表包含114款App，比11月10日Android 17 QPR1中的106款增加了8款。新增应用主要面向澳大利亚和加拿大市场，包括当地版本的麦当劳、肯德基、星巴克、Best Buy Canada和7NOW等。

Android Canary 2611的名单则达到134款，即稳定版的114款，加上20款尚处于测试阶段的应用。这20款包括Reddit、X、LINE、Shopee、Flipkart、Strava、Costco、Domino’s、Mercado Libre、Wolt、MyFitnessPal、Peloton、Picsart和AllTrails等。

从类别看，谷歌的目标已经明显超过首批的叫车和外卖场景。

| 应用类别 | 已进入名单的代表产品 | 当前可用性判断 | |---|---|---| | 外卖与餐饮 | DoorDash、Uber Eats、Zomato、Blinkit、星巴克 | 成熟度最高，部分应用已能完成选购并进入结账页 | | 出行与打车 | Uber、Lyft、DiDi、Bolt、Rapido、Kakao T | 属于谷歌重点支持的日常任务 | | 旅行与住宿 | Airbnb、Booking.com、Expedia、Trip.com、Skyscanner | 名单已覆盖，但复杂预订流程仍依赖后续开放 | | 电商与零售 | Walmart、Target、eBay、Temu、SHEIN、AliExpress | 适合搜索和加购，支付仍需用户确认 | | 办公与协作 | Word、Excel、Outlook、Teams、Slack、Evernote | 已进入名单，但多数编辑和发送操作尚不可用 | | 社交与内容 | Reddit、X、LINE、KakaoTalk | 仅出现在Canary测试名单中 |

从6款首发应用扩展到134款测试目标，Gemini手机自动化的应用覆盖量在约8个月内增加了超过21倍。

Gemini任务自动化在今年3月推出时，只支持Lyft、Uber、Grubhub、DoorDash、Uber Eats和星巴克6款应用；到7月，谷歌宣布支持范围扩大到40多款；如今服务器名单已经达到114款稳定目标和134款测试目标。(androidauthority.com)

不过，名单增长速度快于功能真正落地的速度。它更像谷歌提前铺设的一张兼容性地图，而不是一份可以直接照着使用的功能清单。

Gemini不是直接接管用户桌面

Gemini的手机自动化并不是让AI任意控制整个Android桌面，而是在系统创建的受控虚拟屏幕中运行目标应用。

用户发出诸如“在Zomato上帮我点一份披萨”的指令后，Gemini会打开目标应用，识别页面中的按钮、输入框和商品列表，完成搜索、规格选择以及加入购物车等操作。在进入付款环节之前，系统会暂停任务，并把控制权交还给用户。

Android Authority的实测显示，Gemini可以在印度外卖平台Zomato中搜索餐厅、选择餐品规格并加入购物车，也可以在Blinkit中找到一升装牛奶并进入购物车。面对没有进入名单的Swiggy和Zepto，Gemini则会直接提示该应用不支持自动化。(androidauthority.com)

这种产品设计显得既激进又保守。

激进之处在于，Gemini已经跨过了传统语音助手只能提供链接或建议的边界，开始真正执行任务。保守之处在于，谷歌没有允许模型对所有已安装应用进行无差别点击，而是通过应用白名单、签名证书、虚拟屏幕和支付确认等机制，把AI的行动范围限制在系统可以审计的边界内。

这不是技术能力不足，而是一种刻意的产品选择。手机中保存着支付账户、聊天记录、照片、工作文件和身份凭证，一个识别准确率达到99%的智能体，在连续执行100次操作时，仍可能出现至少一次错误。对聊天机器人来说，一次错误答案可能只是重新提问；对手机智能体来说，一次错误点击可能意味着发错消息、订错酒店或买错商品。

进入名单，也不等于可以使用

Gemini自动化名单本质上是一份系统准入名单，而不是功能完成名单。

谷歌下发的每个目标应用条目都包含包名和签名证书信息。只有安装包身份与名单匹配，Android的Computer Control框架才会允许Gemini尝试操作。这意味着第三方修改版、不同渠道签名版本以及未被谷歌列入名单的竞品，即使界面结构相似，也无法直接获得自动化权限。

然而，系统准入只是第一层判断，Gemini是否支持对应任务则是第二层判断。

Microsoft Word、Excel、Outlook、Teams、OneNote以及Slack都已经出现在名单中，但实测发现，Gemini仍无法直接在Word中编辑文档，也不能在Outlook中自动完成邮件操作。要求Gemini创建Word文档时，它可能选择自行生成DOCX文件再交给Word打开；要求发送邮件时，它可能只生成一个邮件撰写链接，而不是进入Outlook逐步操作。(androidauthority.com)

这种差异说明，Gemini的自动化至少存在三道门槛：

1. 设备门槛：手机需要运行支持相关框架的Android版本，并获得Gemini Intelligence能力。
2. 应用门槛：应用包名和签名需要进入谷歌服务器下发的目标名单。
3. 任务门槛：Gemini还必须被允许执行用户要求的具体任务类型。

目前第三道门槛最为严格。谷歌优先开放的是点餐、购物、叫车和预订等流程相对标准化的任务，而不是修改文档、发送工作消息或批量处理数据等高风险办公操作。

因此，开发者不能把“Word已经入选”理解为“Gemini已经能替用户写Word”。更准确的说法是，谷歌已经为未来的办公自动化预留了系统入口。

白名单只是过渡，AppFunctions才是长期路线

AppFunctions是Android提供的一套系统级能力接口，允许应用把搜索、创建、查询和提交等功能声明为可由AI智能体调用的工具。

谷歌今年公布的AppFunctions官方文档将其描述为Android上的本地工具机制。应用可以把“创建笔记”“查找照片”“发送消息”之类的功能注册到系统，获得权限的智能体再根据用户意图发现和执行这些功能。谷歌把它类比为移动端的MCP：MCP主要连接服务器工具，AppFunctions则直接连接设备上的本地应用。(developer.android.com)

这与依赖视觉识别和模拟点击的GUI自动化存在根本区别。

| 技术路线 | 工作方式 | 优点 | 局限 | |---|---|---|---| | GUI自动化 | 识别屏幕内容并模拟用户点击 | 不需要应用专门开发，覆盖速度快 | 容易受界面改版、弹窗和加载状态影响 | | AppFunctions | 应用主动声明可调用的结构化功能 | 执行更快、更稳定，参数和权限更明确 | 需要开发者接入，短期覆盖范围有限 | | 混合模式 | 优先调用结构化功能，缺失时再操作界面 | 兼顾可靠性和覆盖率 | 系统调度、权限和失败恢复更复杂 |

例如，让Gemini在购物应用中寻找一箱矿泉水，GUI自动化需要像人一样打开搜索框、输入关键词、浏览商品卡片，再点击加入购物车；AppFunctions则可以让应用直接暴露“搜索商品”和“加入购物车”两个功能，Gemini传入商品名称、数量和规格即可执行。

前者像让AI坐在手机前操作鼠标，后者则像应用给AI开放了一组经过权限检查的按钮。

谷歌在2月发布的Android开发者文章中明确表示，AppFunctions负责提供结构化、可控的应用能力，UI自动化框架则用于覆盖尚未完成专门集成的通用场景。换句话说，当前曝光的134款名单更像一座桥：先依靠屏幕操作快速扩大覆盖，再逐步把高频任务迁移到结构化接口。(developer.android.com)

对开发者而言，App的入口正在被重新分配

AI代操作正在把移动应用的竞争重点，从争夺打开次数转向争夺任务完成权。

过去，应用希望用户看到图标、点击通知并进入首页，因此首页推荐、搜索排序和活动弹窗都是核心流量入口。智能体成为入口之后，用户可能只说一句“帮我订明早去机场的车”，随后由Gemini决定调用哪款应用、选择哪种车型，并把最终确认页面交给用户。

这会产生三个直接变化。

第一，应用品牌的可见度可能下降。用户不再主动进入Uber、Lyft或其他平台，而是把需求交给Gemini，应用可能退化为后台履约能力。

第二，结构化能力将影响智能体推荐。价格、库存、配送时间、取消规则和会员权益如果不能被系统稳定读取，应用即使拥有更好的服务，也可能在智能体决策中处于劣势。

第三，开发文档将直接影响产品流量。AppFunctions官方文档指出，开发者提供的函数描述和KDoc内容会被系统用于理解功能、参数和限制；描述越清楚，智能体越容易选对工具。过去写给工程师看的接口说明，未来可能同时决定AI是否愿意调用这款应用。(developer.android.com)

这也是134款名单最值得开发者关注的部分。它不只是“Gemini又多支持了一批App”，而是谷歌正在建立Android智能体时代的新分发规则：谁可以被操作、什么任务可以执行、何时必须交还控制权，都由操作系统层统一管理。

安全边界比支持数量更重要

Gemini自动化能否普及，最终取决于用户是否敢把真实账户和真实任务交给它。

谷歌目前采取的策略包括限制目标应用、校验应用签名、在虚拟环境中展示操作过程、允许用户随时中断，以及在支付等关键步骤前要求人工确认。谷歌还计划提供按应用控制自动化权限的设置，并在Android隐私面板中记录AI助手何时访问过哪些应用。(blog.google)

这套机制牺牲了一部分“万能助手”的想象力，却更接近能够大规模上线的现实产品。

名单制度也会带来新的平台治理问题。谷歌需要解释应用如何进入名单、竞品是否获得平等机会、智能体如何在多个可用服务之间排序，以及平台是否会优先选择自有业务。如果这些规则缺乏透明度，AI助手就可能成为比应用商店推荐位更强势的新入口。

现阶段，134款App的意义不在于用户明天就能让Gemini完成134种任务，而在于Android已经形成了智能体操作应用的基本技术栈：底层由系统提供权限和审计，中间层同时支持GUI自动化与AppFunctions，上层再由Gemini理解意图并编排任务。

我们的判断是，Gemini这次扩容是手机智能体从演示阶段进入平台化阶段的标志，但距离真正“代替用户操作手机”仍有明显距离。

外卖、购物和叫车等低风险、高重复任务，会最先变成稳定能力；文档编辑、企业通信和跨应用工作流则需要更细的权限控制、操作回滚和责任界定。对于开发者来说，现在更值得做的不是等待Gemini开放全部名单，而是提前梳理应用中哪些功能适合被智能体调用，以及这些功能是否能够以清晰、可验证和可撤销的方式暴露给系统。

134款只是开始。谷歌真正想做的，是把Android从“运行应用的操作系统”，变成“替用户调度应用的智能系统”。

参考来源

• IT之家：AI接管手机迈出关键一步，Gemini自动化应用名单曝光 —— 汇总稳定版与Canary名单数量、应用类别及实测结果。
• IT之家移动版：谷歌Gemini自动化应用名单当前共计134款 —— 同一报道的移动页面，便于手机端阅读。