端侧 AI Agent：Google 如何实现，我们如何落地

上一篇解决的是模型如何进入设备：量化压缩、算子适配和推理加速，让模型在内存、功耗与时延约束下稳定运行。但模型跑起来，只代表设备具备了理解能力；要让用户的一句话真正改变应用状态，还需要一套从意图到执行的 Agent 系统。

先看 Google 已公开的体验：在 Galaxy S26 上，用户让 Gemini“显示三星相册里我家猫的照片”，Gemini 选择三星相册开放的 AppFunction，在设备本地完成检索并返回结果。Google 还提到这些照片可用于后续会话，例如发送给朋友，但没有公开其中的跨应用编排实现。[2]

这个案例证明，应用能力可以被 Agent 发现并调用。但真实任务通常跨越多个应用，例如：

“把今天拍的白板照片发到项目群，再约一个明早十点的复盘会。”

一句话背后包含照片检索、内容授权、群聊匹配、图片发送、时间解析和日程创建。要完成它，需要回答四个问题：

• 01 Agent 怎样发现并访问其他应用的能力？
• 02 谁可以调用这些能力，权限和用户确认放在哪里？
• 03 多个动作如何拆解、排序，并把上一步结果交给下一步？
• 04 端侧模型能力有限时，怎样兼顾速度、成功率与隐私？

Google 模式还有一个现实问题：平台掌握 Gemini 入口和调用准入，应用承担改造、安全与维护成本，双方并不对等。收益不明确时，应用缺少接入意愿，AppFunctions 难以形成完整生态；受限的 UI Automation 也补不齐这一缺口。

因此，我们应借鉴它的 Framework 标准，而不是复制 Gemini 的产品入口和生态关系。下面先看 Google 如何实现，再回答四个工程问题，最后落到我们的实现。

Google 是如何实现的

从公开资料能够确认的链路是：Gemini 接收用户请求，选择三星相册提供的 AppFunction，函数在设备本地执行，再把结果返回 Gemini。Google 没有公开这一体验内部使用的模型位置和 Agent Runtime。

将 Google 已公开的相关能力放在一起，可以抽象出四个角色：模型层负责理解与生成，Agent Runtime 负责规划，AppFunctions 提供结构化应用能力；对部分精选应用，UI Automation 在特定设备和类别中提供受控兼容路径。这些角色并不要求固定串行经过四层。

角色	Google 公开的组件与定位
模型能力	Gemini Nano + AICore / ML Kit GenAI：开发者可用的端侧理解与生成能力
Agent Runtime	Gemini 是产品侧 Agent；ADK for Android 是开发者构建 Agent 的可选框架
结构化能力	AppFunctions：让应用函数可发现、可传参、可返回结果
兼容路径	Gemini UI Automation 预览：在特定设备和类别中操作部分精选应用

这四个角色是工程归纳，不是 Google 发布的固定产品架构。公开案例只确认相册函数在设备本地执行，并未说明意图理解与规划是否由 Gemini Nano 完成，也未表明 Gemini 的内部 Runtime 使用 ADK。

AppFunctions 的机制可以概括为：应用向 Android 注册函数及元数据，Agent 查询能力说明、选择函数并发起结构化调用。它解决“有什么能力、参数是什么、怎样调用”；多步骤规划、业务授权、敏感操作确认和失败恢复仍由 Agent Runtime 与 Provider 负责。

版本边界：本文资料截至 2026 年 9 月 5 日。AppFunctions 支持 Android 16 及以上设备，但 Jetpack API 与 Gemini 端到端集成仍处于实验或受限预览阶段，代码版本应以 AndroidX 发布页为准。[3][8]

问题一：Agent 如何访问其他应用

传统 Android 跨应用协作主要依赖 Intent、Deep Link、ContentProvider、Binder/AIDL 和系统 API。它们解决了进程间调用，却通常缺少专门面向 Agent 的语义描述：模型不知道设备上有哪些能力，也不知道接口参数、约束和返回值。AppFunctions 在这几条路径上增加了“可发现的语义层”。

2.1 应用声明能力

应用首先要把普通业务函数描述成 Agent 可发现、可理解的能力。AppFunction 负责声明函数，结构化 Schema 描述输入输出，KDoc 则帮助 Agent 选择工具和填写参数。

以“创建日程”为例，Provider 只开放标题和开始时间，并返回明确的创建结果：

KSP 在编译阶段生成函数 Schema 和 Service。应用在 Manifest 中注册生成的服务，并以 BIND_APP_FUNCTION_SERVICE 限制绑定；数据库和文件操作则切换到后台 Dispatcher。

2.2 系统建立能力注册表

Android 安装应用时读取生成的 Schema，将函数名、包名、参数、返回值和描述写入系统索引。Agent 不需要扫描 APK 或猜测 Deep Link：元数据发现使用 searchAppFunctions()，运行状态使用 getAppFunctionStates()。两者分开查询，执行时仍要防御状态变化。

2.3 Agent 结构化调用

Agent 把自然语言转换为结构化调用。例如：选择 createEvent，定位目标包，填入标题和开始时间。执行前再按 Schema 校验类型、范围和必填字段。

结构化 Tool 不依赖按钮位置，结果也能继续参与规划。UI Automation 可兼容尚未接入的存量应用，但目前只在特定设备和精选类别中预览，并非普通开发者可直接集成的通用 SDK。[2]

对于自定义 Agent，还需用 Adapter 将 AppFunctions 元数据转换为统一 Tool Schema，并把模型参数编码为真实请求。第 7 节给出实现。

问题二：权限如何落到代码

“模型说可以”不构成授权。一次跨应用执行需要经过四道门。

第一道是调用者门禁。 Agent 在 Manifest 声明 EXECUTE_APP_FUNCTIONS，但跨包发现和执行还必须通过 Android 的运行时 allowlist 或调用者认证；普通应用只声明权限，并不能自动获得完整调用能力。

第二道是服务门禁。 Provider Service 由 signature 级的 BIND_APP_FUNCTION_SERVICE 保护，只允许系统绑定，应用不能再额外暴露一个无保护入口。

第三道是数据门禁。 函数一次只返回任务所需的最小字段与最小条数；URI 单独授予只读权限，并由所有者负责回收。

第四道是行为门禁。 发送、购买、删除、外部分享等副作用不能由模型自行批准，必须在代码层设置用户确认。

权限判断必须落在代码层，而不是模型输出中。发消息、共享照片、购买和删除等外部副作用都要经过明确确认；照片等敏感数据只返回最小结果和只读 URI，任务结束后主动回收授权。[9]

权限设计可以落成一张风险表：

风险与示例	默认策略
只读低风险：查询设备音量、列出公开日程标题	可直接执行，记录审计日志
只读敏感：读取照片、联系人、会议内容	依赖系统授权，只返回最小结果
可撤销写操作：调节音量、创建草稿、创建日程	执行后显示结果，提供撤销入口
外部副作用：发消息、共享文件、购买	执行前展示对象与内容，等待确认
高风险破坏：删除数据、关机、恢复出厂	强确认或禁止 Agent 调用

问题三：一句话里的多个指令怎样编排

AppFunctions 只提供工具，不负责把复杂目标拆成流程。多指令编排发生在 Agent Runtime。

以开头的指令为例，规划结果是一张有依赖关系的图：

规划器要处理五类关系：

• 01 数据依赖：sendImages 需要 searchPhotos 返回的 URI。
• 02 身份消歧：存在多个“项目群”时，必须让用户选择，不能由模型猜一个。
• 03 顺序约束：联系人或群聊 ID 要先查询，再执行发送。
• 04 副作用确认：检索可以直接做，发送要停在确认门前。
• 05 失败策略：消息发送成功、日程创建失败时，保留已完成结果；只有目标 Tool 具备幂等保证，或能确认尚未产生副作用时，才单独重试失败步骤。

前置函数、参数约束和可恢复错误写入 Tool 描述，提高规划命中率；最终顺序仍由代码校验。

生产系统不宜让模型每次都自由生成任意计划。更稳妥的做法是让模型输出受约束的 Plan，再经过确定性验证器：

PolicyRegistry 根据 Tool、参数、数据类型和目标对象重新计算风险，不采信模型自报的等级。模型负责提出计划，确定性验证器负责拒绝越界计划。

问题四：端侧模型能力有限，任务在哪里执行

端侧 Agent 不等于所有推理都必须留在端上。真正需要端侧化的是敏感上下文、低时延决策和设备能力执行；复杂开放域规划是否上云，应由任务风险、模型能力和网络状态共同决定。

固定设备指令，例如“音量调到 30%”，直接走规则 FastPath；步骤固定、只需抽取参数的任务，交给端侧模型；长上下文和开放域规划可以进入云端根 Agent，但照片、联系人等敏感数据仍由本地子任务处理。三条路径最终使用同一份 Tool Schema、权限策略和审计记录。[4][5]

规则可确定： FastPath 直接进入 Tool。

本地可处理： 端侧模型生成受约束 Plan，再进入 Tool。

任务复杂： 云端根 Agent 负责开放域规划，本地子任务保留敏感数据并执行 Tool。

这种分级先判断数据能否离端，再判断端侧模型是否具备足够的规划能力，“能否联网”只是其中一个条件。所有路径共用同一套确定性权限门禁。

Google 模式的问题：不对等的生态为何难以复制

Google 模式用结构化函数替代页面操作，技术路径清晰，但生态机制并不完整。

激励不对等。 Google / OEM 掌握 Gemini 入口、调用准入和用户触点；应用承担改造、安全、兼容和维护成本。如果流量归因、用户关系和商业回报不清晰，接入动力就会不足。

生态有冷启动。 接入应用少，Agent 能完成的任务就少；用户价值不足，又进一步削弱应用意愿。UI Automation 依赖界面结构，只能临时补位，不能替代稳定接口。

底座能力不完整。 AppFunctions 面向新版 Android，Session、Memory、策略、恢复、评测和跨设备协作仍需自建；存量设备和其他系统环境也需要新的适配器。

阶段结论： Google 的思路更适合作为 AIOS Framework 的建设标准：用 AppFunctions 定义应用能力契约，由系统 Runtime 统一发现、权限和调用。但在生态协作上，Gemini 掌握入口与准入，应用承担接入成本，双方明显不对等。

因此，自定义 OS 可以分阶段建设：第一阶段借鉴这套标准，完成端内能力框架；第二阶段通过 A2A 连接不同终端、应用 Agent 与外部算力，完成跨端、跨应用协作。

Gemini 是 Google 的，我们的 Agent 如何实现

面向自定义 OS，我们的范围比 Android 手机助手更广：需要建设一套覆盖多种设备形态和系统环境的通用 OS Agent。目标能力包括模型替换、用户授权范围内的持续环境感知，以及行业 Tool 和 Memory 的热插拔。这里描述的是目标态，不代表所有模块已经完成。

目标架构可以归纳为四组能力：

• 感知与推理： Context & Session 对授权数据做最小化采集，Model Router 在规则、端侧模型、企业算力和云端模型之间路由。
• 规划与控制： Planner 生成受约束 Plan，Capability Registry 提供自定义 OS 内部统一 ToolSpec，Policy Gate 做确定性裁决。
• 执行与恢复： Executor 调用 Adapter，State Store 负责 Checkpoint、幂等、重试、补偿和审计。
• 记忆与协作： Memory Service 管理行业知识、用户记忆和生命周期；A2A Gateway 负责独立 Agent 的发现、任务委派与结果交换。

Adapter 将 AppFunctions、MCP、CLI 和 Device API 统一为 ToolSpec，Planner 不直接依赖原始协议。CLI 只允许固定命令和参数 Schema，Device API 负责鉴权与版本适配。

MCP 连接 Agent 与工具服务；A2A 连接独立 Agent，负责能力发现、任务委派和结果交换。身份认证、超时、取消、幂等和远端确认统一由 Runtime 管理。

7.1 AppFunctions Adapter 怎样落到代码

以 Android 为例，Adapter 先把 AppFunctions 元数据转换为 ToolSpec；执行时再把参数编码为 AppFunctionData，构造真实请求：

AppFunctionCatalog、SchemaMapper 和 ArgumentsEncoder 是自定义封装；Tool ID 使用“包名/函数标识”，避免同名冲突。

一次任务的实际路径是：Context 形成任务输入，Model Router 选择模型，Planner 结合 Registry 与 Memory 生成 Plan，Policy Gate 完成裁决，Executor 调用对应 Adapter，最后由 State Store 保存结果。

自定义 Agent：一句话如何驱动三个应用

下面通过一个 Android 单机 Demo，验证自定义 Agent 的最小执行闭环：发现三个应用开放的 AppFunctions，将一句话拆解为有依赖关系的步骤，并完成跨应用的数据传递与顺序执行。

找到今天拍摄的白板照片，发送到“端侧 AI 项目群”，并创建明天上午 10 点的复盘日程。

为了展示跨应用协作，Demo 包含一个自定义 Runtime 和三个 Provider：

GalleryProvider：searchPhotos 查找白板照片，releasePhotoAccess 回收原始 URI 授权。

ChatProvider：searchConversations 找到目标群，sendImages 执行图片发送。

CalendarProvider：createEvent 创建复盘日程。

自定义 Agent Runtime： 负责规划、确认和执行，通过自研 Tool Adapter 接入 AppFunctions，并获得平台调用准入。

8.1 Provider 定义

GalleryProvider 使用预置标签的测试数据，CalendarProvider 写入测试仓库。接入系统媒体或日历时，Provider 仍要申请对应的数据权限；AppFunctions 的跨包调用权限不会代替业务授权。示例基于 appfunctions:1.0.0-alpha11，复制代码前应核对最新版本。[8][9]

相册侧函数保持只读，并限制最大返回数量：

GalleryProvider 同时提供 releasePhotoAccess。grantId 必须随机、短期、一次性，只能回收本次登记的 URI。

关键边界是：相册授予 Agent 的读取权不会自动传给 ChatProvider。Agent 需要复制到自己的临时缓存，再显式授予 ChatProvider 只读权限；完成后立即撤销并清理。

stageWithCleanup 负责异常时清理部分缓存。发送前，ChatProvider 根据真实接收方和图片摘要签发一次性确认 Token；Token 与会话、内容摘要和有效期绑定，不能由模型生成。Tool 描述还要声明“先搜索群 ID、歧义时由用户选择”，但 Provider 仍需再次校验。

8.2 从 Plan 到执行

Provider 能被调用之后，还需要一个确定性执行循环，把模型给出的 Plan 变成按依赖执行的 Tool Call：

8.3 观察执行轨迹

Demo 把每一步打印成 Trace：

Trace 记录工具选择、参数来源、确认节点和执行结果，是定位失败与恢复任务的主要证据。

8.4 验证方式

Provider 安装后，先验证系统注册表，再绕过自然语言直接验证单个函数的 Schema 和业务实现：

单函数通过后，再用 Google Testing Agent 验证发现与调用，并单独测试我们的 Adapter、规划器和权限策略。[10] Testing Agent 可能使用云端模型，不能据此证明 Gemini Nano 完成了端侧规划。当前 Demo 验证的是 Provider、单函数与编排链路，不代表普通三方应用已获得生产级跨应用调用资格。

从 Demo 到产品：建立四项工程门禁

AppFunctions 定义能力如何被发现和调用，生产可靠性仍由 Agent Runtime 负责。Demo 进入产品前，至少需要建立四项工程门禁：

执行预算： 为步骤数、总时长、重规划次数和副作用调用设置上限；锁定 Tool Schema 与策略版本，版本变化时终止当前计划并重新规划。

状态恢复： 为每次 Tool Call 记录任务 ID、步骤 ID、输入摘要、执行状态、结果和错误码；通过 Checkpoint 从安全位置继续，只重试无副作用或具备幂等保证的步骤。

幂等补偿： 写操作携带 idempotencyKey；可撤销动作提供补偿 Tool，不可撤销动作提升确认等级并禁止自动重试。

评测观测： 建立固定回归任务集，持续统计 Tool 选择准确率、参数有效率、任务完成率、越权拦截率、重复副作用、端到端耗时和恢复成功率。

端侧 Agent 建设的落点

Google 的价值在于给出 AIOS Framework 的建设标准：应用能力如何声明，系统如何发现、授权和调用；它的局限则是不对等的生态协作模式。

因此自定义 OS 的路线可以分为两阶段。先完成模型路由、Session、能力目录、Tool Adapter、权限门禁、执行状态与 Memory，建立端内 Framework；再通过 A2A 连接不同终端和应用 Agent，实现跨端、跨应用的任务协作。我们借鉴的是 Framework 标准，而不是依赖 Gemini 的产品入口。

参考资料

• 01 Android AppFunctions 概览
• 02 Android：The Intelligent OS
• 03 在应用中接入 AppFunctions
• 04 ADK for Android
• 05 Gemini Nano 与 AICore
• 06 AppFunction KDoc 优化指南
• 07 Google AppFunctions Jetpacker 示例
• 08 AndroidX AppFunctions 版本说明
• 09 AppFunctionUriGrant API
• 10 Google AppFunctions Testing Agent

JOTO 企业落地观察

• 端侧 Agent 的落地成败高度依赖应用能力的标准化暴露。AppFunctions 提供了一种契约式能力声明机制，对企业部署而言，这意味着必须推动业务系统提供符合 Schema 的函数接口，而非仅支持 UI 自动化或私有 API。缺乏统一契约将导致 Agent Runtime 难以规模化接入异构系统，增加定制化 Adapter 开发成本。
• 多指令编排中的‘身份消歧’和‘顺序约束’要求 Agent Runtime 具备确定性校验能力，而非完全依赖模型生成。这对企业智能体工程意味着：生产环境必须引入 Plan 验证器与 Policy Registry，将权限、数据流向和副作用确认等逻辑固化为可审计的代码门禁，避免将安全与一致性责任交由不可控的模型输出。
• 端云协同执行策略揭示了一个关键取舍：敏感数据必须本地处理，但开放域规划可上云。这对 RAG 知识工程提出新要求——企业需构建双模态知识管道：端侧缓存脱敏后的结构化实体（如联系人摘要、日程片段），云端处理需上下文关联的复杂推理，二者通过统一 Tool Schema 与审计日志对齐，确保数据主权不因计算迁移而旁落。
• Google 模式暴露的生态激励失衡，对企业 AI 安全治理具有警示意义：当平台方掌控调用准入与用户触点，而应用方承担全部安全与维护成本时，合规性将难以横向拉通。企业需在自建 Agent 框架中，将权限策略、审计溯源与失败恢复机制作为基础设施强制嵌入，而非依赖下游应用自主实现。