Google Android App Functions 构建了安全围栏，但大多数 AI 智能体仍在围栏之外

Google 已为 Android 智能体构建了一条进入其他应用的受控通道，但大多数用户仍无法看到、管理或真正使用这条通道。Google Android App Functions 现已定义获批准的助手如何发现并执行跨应用的特定操作。矛盾之处在于，安全架构先于广泛的智能体生态系统到来。

这不只是又一项尚未完善的 Android 功能。Google 正在决定谁能在应用内部执行操作、这些执行者能够发现什么，以及开发者会开放哪些操作。这些选择为未来可创建笔记、查找照片、启动媒体播放或组建购物车的智能体建立了控制平面。

这也使 Google 的方案区别于那些通过理解屏幕并模拟点击来操作手机的智能体。基于屏幕操作的系统无需深度集成应用即可工作，但它们仍容易受到界面布局变化和误导性内容的影响。App Functions 提供了一条更清晰的路径，但只有获得批准的智能体和参与其中的应用才能使用。

Google 已展示过有限的集成案例，包括 Gemini 通过 Samsung Gallery 获取照片。Android 17 进一步扩展了这一框架。不过，普通 Android 用户仍不会看到一个汇集第三方助手和兼容操作的通用智能体控制面板。

这一落差解释了表面上的矛盾。这一围栏并非真的空无一物，但其中的参与者仍然数量有限、受到严格控制，也不便于普通用户查看。Google 在开放周边市场之前，先确保了入口的安全。

Google Android App Functions 改变了智能体进入应用的方式

App Functions 以声明式、结构化的操作取代模拟屏幕控制，让 Android 能够识别并限制这些操作。

应用功能是应用向获批准调用方提供的一项独立操作。笔记应用可以开放“创建笔记”，媒体应用则可以开放“播放歌曲”。智能体发送结构化参数，而不是在应用可见界面中逐步导航。

官方的 App Functions framework 描述了两方角色：提供方应用声明操作，可信智能体发现并执行该操作。Android 通过 AppFunctionManager 及相关服务协调这一交互。

这一架构之所以重要，是因为视觉界面原本是为人类判断而设计的。人会注意到按钮是否移动、收件人是否不对，或者购买总额是否发生变化。自动化系统则可能在误读屏幕内容，或遵循显示内容中嵌入的恶意指令后继续执行。

结构化功能缩小了可执行操作的范围。智能体并不会仅仅因为可以请求应用执行一项操作，就获得无限控制权。提供方定义功能、其输入，以及返回的结果。

Android 还会追踪功能是否处于启用状态。如果功能不存在、无法找到或不可用，执行请求可能失败。这比向智能体授予应用界面的通用访问权限提供了更清晰的边界。

该框架在 API 级别 36、即与 Android 16 对应的版本中进入平台。Google 的文档仍将 App Functions 描述为 beta 或实验性预览功能。Android 17 增加了运行时注册、活动范围功能、更新后的访问级别以及更细致的发现控制。

这些变化表明，Google 正将跨应用智能体能力视为操作系统层面的议题。它并未让每个助手开发者自行发明私有集成层。平台提供了通用标识符、元数据、状态管理、请求、响应和权限检查。

在一个简单的记笔记场景中，这一区别会更清楚。智能体接到指令：“把酒店地址保存到我的旅行笔记。”它会搜索兼容功能、识别目标应用、提供标题与内容，并接收结果。

基于屏幕操作的智能体则需要打开应用、找到按钮、选择笔记本、聚焦文本字段、输入内容并按下保存。每一次视觉状态切换，都会为歧义或操纵进入流程增加一个可能点。

App Functions 并不能保证智能体正确理解了原始请求，也无法证明应用安全地实现了相关操作。它们通过以开发者明确声明的操作取代开放式的界面操作过程，缩小了攻击面。

这是第一个重要变化。Android 现在拥有一套原生词汇，用于描述智能体在应用内部执行操作，而不只是谈论这些应用或启动其界面。

第二个变化则不那么显眼。Android 将跨应用执行置于普通应用无法自行假定拥有的权限之后。这一决定使 App Functions 不仅是一项便利 API，更成为了一套访问控制系统。

权限模型让 Google 和设备制造商掌握控制权

安全优势来自限制具备能力的调用方，但同样的限制也让独立 Android 智能体被挡在门外。

应用无需特殊授权即可执行自身功能。跨包执行则不同。AppFunctionManager 要求调用智能体持有 Android 授权的权限，才能发现或执行其他应用中的功能。

最初的 Android 框架工作将 EXECUTE_APP_FUNCTIONS 分配给预装或系统应用中持有助手角色的应用。一项相关的受信任权限则服务于受到严格控制的系统智能组件。permission history 显示，Android 如何明确地将智能体执行权限绑定到特权角色。

当前框架正朝着更细粒度的访问级别演进。开发者可以将功能标记为仅供应用自身、系统调用方或经 Android 认证的调用方使用。不过，认证并不等同于任何下载的助手在显示提示后都能获得的普通运行时权限。

这一区别解释了为何该功能在普通手机上仿佛并不存在。用户熟悉批准相机、麦克风、通讯录和位置访问权限，但他们未必能从标准设置页面安装任意助手，并授予其广泛的 App Functions 权限。

Google 正在防止危险的逐底竞争。如果任何应用都能在一次模糊的同意提示后调用所有开放功能，激进的助手就会寻求广泛授权。用户可能会在不理解有多少重要操作因此变得可用的情况下批准它。

跨应用智能体带来的风险不同于被动式聊天机器人。错误回答只是不便，错误操作则可能向错误的人发送消息、泄露私密文件、修改记录，或发起一笔交易。

提示注入让这一区别更加明显。智能体在阅读网页、消息、文档或图像时，可能遇到旨在覆盖用户意图的文本。近期的 mobile-agent research 专门研究了 Android 无障碍服务驱动的智能体如何暴露于间接提示注入风险之中。

权限边界无法让模型免受操纵，但可以限制哪些应用能够充当智能体，以及这些智能体能够调用哪些功能。它还为提供方应用提供了一条明确的执行路径，使其可以验证参数并应用自身检查。

不过，集中控制也带来了另一个问题。Google 和 Android 设备制造商实际上成为决定哪些助手可获得一等访问权限的仲裁者。独立智能体即使打造出复杂的规划能力，仍可能缺乏通过官方框架编排第三方应用的权限。

这种压力落在三类群体身上。

首先，助手开发者必须获得 Android 可信路径的资格，或依赖更间接的技术。他们可以通过深层链接进入应用、使用现有 intents、借助无障碍服务操作，或通过开发工具模拟交互。没有一种方式能提供同等的标准化访问。

其次，应用开发者必须决定哪些功能值得开放。每项功能都需要实现、测试、输入验证、生命周期处理和兼容性工作。小型应用团队可能会犹豫，直到足够多的用户拥有能够调用这些功能的智能体。

第三，用户必须信任交易的双方。他们既需要确信助手正确理解了请求，也需要确信提供方应用不会执行范围出乎意料地广泛的操作。

这形成了一个熟悉的平台冷启动问题。智能体需要实用功能才能吸引使用；应用开发者则需要活跃智能体，集成才值得投入工程时间。Google 可以借助 Gemini 和重要合作伙伴打破这一循环，但独立参与者仍受制于其访问政策。

因此，这一设计既是安全围栏，也是分发闸门。限制执行可减少即时滥用，而认证与平台特权则塑造了谁有资格构建有意义的 Android 自动化能力。

Google 的安全优先设计与采用难题相冲突

核心取舍很简单：更严格的控制让 Android 智能体部署起来更安全，而更慢的访问开放速度则使该框架在今天的实用性较低。

Google 在 2026 年 2 月让 App Functions 不再只是晦涩的 API 参考资料。其 Android 开发团队称这些能力仍处于早期阶段，并将隐私和安全描述为基础设计优先事项。

该公司还展示了一个具体部署案例。Gemini 可以理解请求、触发 Samsung Gallery 中的 App Function，并在 Gemini 界面内返回选定照片。根据 Samsung integration，这一体验始于 Galaxy S26 系列，并计划扩展到更多 Samsung 设备。

这个例子证明，该框架并非空洞的代码外壳，但也揭示了当前推广范围的有限性。演示涉及 Google 的助手、一家主要 Android 制造商、一款第一方图库应用，以及部分指定设备。

广泛的生态系统应当呈现不同面貌。用户可以在合格智能体之间进行选择；数千款应用会开放有文档说明的操作；Android 会显示哪个智能体调用了哪个功能、传输了哪些数据，以及哪些操作需要确认。

现有框架提供了这类未来体验的若干组成部分，却尚未提供完整的公共体验。开发者可以定义元数据、发布功能、观察状态并处理执行请求。Android 17 还引入了更多动态注册和活动特定行为。

Google 的 Android 17 update 包含一个测试智能体应用和用于开发的 ADB 命令。ADB，即 Android Debug Bridge，是用于控制和检查设备的开发者接口。这些工具帮助程序员在消费级智能体广泛支持相关功能前验证它们。

测试支持是必要条件，但不等于采用。开发者可以证明“创建笔记”会返回预期响应，却无法知道有多少真实助手会调用它。兼容功能可能在数百万台设备上始终处于闲置状态。

该框架还需要共享的 schema。两个笔记应用可能提供相似的操作，但名称、参数和结果格式各不相同。如果每个提供方都自行定义接口契约，智能体就必须理解日益庞杂的专有接口集合。

标准 schema 让智能体能够按能力搜索，而非记住每个应用。Android 的元数据模型支持 schema 信息，但真正可用的互操作性仍取决于开发者围绕一致的定义达成共识。

用户控制则构成另一层尚未解决的问题。应用可以维护其功能的启用状态，较新的元数据也能表达不同的访问级别。然而，普通用户需要一套易于理解的模型，以回答实际问题。

Gemini 可以创建笔记但不能删除吗？另一款通过认证的智能体能否搜索照片而不将其对外共享？审批是一次性适用、按应用适用、按功能适用，还是针对每次敏感请求？发生问题后，用户能否查看操作历史？

Google 必须在这些控制与使用阻力之间取得平衡。对每个无害操作都要求确认，会抵消智能体带来的便利。批准宽泛类别则可能掩盖风险。一个有用的系统应让常规操作快速完成，同时在不可逆或敏感步骤之前暂停。

这个问题类似于权限设计，但智能体的意图会在任务过程中变化。相机权限授予的是对已知传感器的访问权。智能体可能先读取一个列表，推断出若干子任务，调用多个应用，再提出购买建议。关键的影响边界会在工作流进行到一半时才出现。

这使得策略比单一权限更重要。Android 必须综合调用方身份、功能范围、提供方规则、用户偏好、交易敏感度以及当前上下文。

“笼子”的比喻只捕捉到了这一设计的一部分。Android 并非将一个不受信任的进程隔离在盒子中，而是通过狭窄开放的门协调受信任的调用方，并让每个应用继续对其门后发生的事情负责。

对开发者而言，眼下的判断仍不明朗。支持 Google Android App Functions 能让应用进入未来的智能体工作流。但这也意味着要投入一个仍处于 beta 阶段的接口，其分发、认证和用户需求仍在发展中。

屏幕驱动型智能体更易推出，也更难信任

Google 面临的主要对手并非另一个移动平台；而是让智能体像人一样操作屏幕这条捷径。

屏幕驱动型智能体只需更少的合作即可起步。它读取像素或无障碍树，判断交互位置，并生成点击、滑动和文本输入。只要人类能通过界面完成任务，智能体就可以尝试走同一条路径。

这种通用性很有吸引力。开发者无需让每个目标应用都发布一个功能。研究人员可以在现有软件中测试智能体，初创公司也能在协商集成前展示广泛覆盖能力。

Google 自己的 Android 研究也帮助确立了这种方法。Android in the Wild 数据集包含 715,000 个操作片段，覆盖多个 Android 版本和设备类型上的 30,000 条指令。它反映了训练或评估能够通过多样界面执行操作的系统所需的规模。

然而，广泛的视觉控制是以显式契约换取推断能力。智能体必须判断每个屏幕的含义、内容是否可信，以及一次交互是否产生了预期结果。

应用更新后，按钮标签可能变化。对话框可能遮挡预期目标。恶意页面可能将指令放在模型会读取的位置。结账流程也可能在最终确认前添加费用或更改商品。

人类在这些情形中同样会犯错，但智能体可以更快、更大规模地重复这些错误。它们可能在后台运行，跨应用持续操作，并处理用户从未直接审阅的信息。

App Functions 将解释工作转移到了另一层。智能体仍需理解用户请求，但不必推断每个屏幕的操作机制。它选择已声明的操作，并提供类型明确的信息。

这类似于使用应用程序接口与通过浏览器自动化网站之间的区别。API 通常提供更高的稳定性和更清晰的输入。浏览器自动化可以触达没有 API 的服务，但必须处理布局、会话和内容变化。

结构化路径也提高了可追责性。Android 可以识别调用包、目标功能、请求和结果。提供方应用可以拒绝无效参数，或要求自身的确认。平台策略可以对敏感功能与普通功能区别对待。

这些措施都无法消除模型层面的防御需求。被攻陷的智能体可能因错误原因调用获准功能。粗心的提供方可能暴露验证薄弱的操作。受信任的调用方仍可能误解含糊的指令。

结构化操作也可能让有害操作更可靠。能够调用“发送付款”功能的恶意智能体，无需再穿过令人困惑的界面。其安全价值取决于限制访问、核验意图，以及在正确时机要求确认。

这正是为何过度开放 EXECUTE_APP_FUNCTIONS 会抹去大部分架构优势。Google 不能只是把该权限放进标准对话框，就认为问题已经解决。平台需要用户能够理解的资格规则和可观察行为。

与此同时，维持有限访问会形成使用屏幕自动化的压力。独立助手会选择能让它们发布产品的路径。如果官方入口始终无法使用，一些开发者就会重新采用无障碍服务、基于 ADB 的工具或设备自动化。

结果形成了一种政策悖论。Google 希望智能体走更安全的结构化路径，但必须让这条路径足够可达，才能取代风险更高的替代方案。

竞争对手和开源项目可以利用这一缺口，提供在现有应用中看起来能力更强的智能体。由于无需等待提供方集成，它们的演示可以覆盖更多任务。Google 的系统反而可能因为执行边界而显得受限。

消费者不会通过 API 文档评估这些架构。他们会注意智能体能否完成请求。如果一个屏幕驱动型竞争产品可处理十个应用，而 Gemini 的结构化路径只支持两个，在购买决策中，能力可能胜过抽象的安全性。

开发者在设计 AI 工作流时也面临同样的张力。可靠的自动化依赖于可预测的输入、受控的操作和清晰可见的审查节点。通用界面控制提供覆盖范围，而结构化功能则提供更明确的保障。

Google 必须弥合这种能力差距，同时不能将 Android 智能体变成不受限制的远程控制工具。App Functions 提供了机制，但采用情况与访问策略决定开发者是否真正使用它。

真正的考验在于，这个笼子能否成为一个市场

下一阶段取决于应用参与、智能体访问和用户可见的控制，而不是更多框架类。

第一个值得关注的信号，是公开 App Functions 的生产应用在数量和类型上的增长。Samsung Gallery 是一个有用的示范，因为照片检索涉及个人数据，也对应一项易于识别的用户任务。但它并不能证明通信、生产力、金融、购物、旅行和媒体等领域已获得广泛支持。

主流应用需要开放的不只是宣传性演示操作。重复出现且实用的工作流将证明该框架是否为用户节省了有意义的时间。创建笔记、定位特定照片、播放歌单以及将商品加入购物车，都是早期测试。

如果多家独立应用开发者宣布已上线的集成，采用将增强 Google 的方法。若支持仍集中于 Google 软件、设备制造商应用和少数首发合作伙伴，这一案例就会被削弱。

第二个信号是非 Google 智能体的访问权限。Android 的较新元数据提到由 Android 认证的调用方，暗示这条路径可能不止面向一款第一方助手。决定性问题在于认证需要什么，以及合格的第三方智能体能否在合理条件下竞争。

一个可信的计划需要公开标准、安全义务、撤销程序和可预测的审核。开发者应了解智能体如何获得访问权，以及哪些行为会导致其失去访问权。

缺少这些细节，权限系统就可能沦为 Gemini 的私有分发优势。Google 可以主张严格访问保护用户，而竞争对手也可以主张同一套规则保护了 Google 作为 Android 默认智能体的地位。

多个获得认证的智能体将为“安全优先”的解读提供有力证据。持续的第一方独占则会强化“设卡把关”的解读。该框架的正当性取决于能否区分信任要求与偏好性访问。

第三个信号是面向用户的控制和审计体验。Google 更广泛的 Gemini Intelligence 推出计划承诺在手机及其他设备上实现主动自动化。更多后台操作让可见性愈发重要。

用户需要看到有哪些功能存在、哪些智能体可以调用它们，以及哪些权限仍处于激活状态。他们还需要一份历史记录，说明智能体请求了什么，以及每个应用返回了什么。

有用的控制界面应将低风险便利与具有重要后果的权限区分开来。播放一首歌不应与发送消息或提交订单承受同样的阻力。平台应在错误发生前就传达这种区别。

确认设计将是最困难的部分。过多提示会让用户习惯性地全部批准。过少提示则会让用户对并非自己本意的操作感到意外。情境化审批必须保持清晰，不能将每个工作流变成一连串中断。

Google 还应解释处理发生在哪里。一些功能可以针对本地应用状态执行，而助手的推理可能涉及云服务。用户需要了解其数据何时离开设备，以及由哪一方接收。

该框架的状态控制可支持紧急撤销。如果智能体行为异常，用户应能禁用其跨应用权限，而无需在各个应用中逐一查找。提供方应用也应能快速暂停敏感功能。

开发者也将寻找运营工具。他们需要用于失败调用的日志、schema 验证、兼容性测试、滥用报告，以及跨 Android 版本的明确行为。只有当团队能够在生产环境中支持它时，框架才会成为生态系统。

Google 的分阶段推出是可以辩护的。在控制机制就绪前发布不受限制的跨应用智能体能力，会招致可预见的失败。该公司转而在启用普遍访问前，先构建权限检查、提供方契约、测试工具和不断扩展的平台 API。

怀疑论观点同样站得住脚。一个可调用功能寥寥无几的安全框架，并不能带来多少消费者价值。一条受到严密控制的路径，也可能将独立开发者推向该框架原本旨在取代的屏幕自动化。

因此，Google Android App Functions 正处于一个重要但尚未完成的过渡阶段。Android 现在拥有让智能体发现并执行受限操作的原生机制，但该平台尚未证明这一机制能够支撑一个开放、竞争且被广泛采用的智能体市场。

未来几个月，应关注是否出现超出首发合作伙伴范围的生产级集成、面向外部智能体公开的访问规则，以及用户可见的权限历史记录。这些信号将共同揭示：Google 构建的是共享基础设施，还是为 Gemini 保留的专属通道。

对 Android 用户而言，实际问题并非 AI 智能体能否点击屏幕——实验性系统早已证明它可以。问题在于，Android 能否让智能体在个人应用之间采取行动，同时又不要求用户交出实质性的控制权。

对开发者来说，这项决策来得更早。他们必须找出值得以结构化方式开放的安全且有用的操作，并界定应在何处要求确认。等待可以避免近期的工作量，但当用户开始委托任务而非打开界面时，也可能让应用变得不可见。

Google 已经搭好了门口，也装上了锁。现在，它必须证明：可信智能体、独立开发者和普通用户都能获得正确的钥匙。