三大安卓智能体方案横评：官方技能库、端侧框架、GUI 执行器

2026 年的安卓开发圈正在经历一轮"Agent 化"的集中爆发：Google 一边推出面向大模型优化的 Android CLI 与官方技能库，一边把 AppFunctions、LiteRT、ML Kit GenAI Prompt API 这些"设备端智能"能力沉底到系统与 Jetpack 层；开源社区则从另一条路线发力——PalmClaw、KnowAct-GUIClaw、X-OmniClaw 等框架试图用 GUI 操作 + 自进化记忆的方式，让手机自己"跨应用办事"。三条路线都在解决"智能体如何与安卓系统交互"这个核心问题，但它们在正确性来源、隐私边界、泛化能力上的取舍截然不同。本文以官方 Android skills 仓库源码为主线，结合社区实践与开源框架情报，拆解三条路线的技术骨架与适用边界。

官方技能库：以开发场景为中心的封闭正确性

Google 将「Android skills」定义为面向 AI 优化的模块化指令仓库——每个 skill 是一个遵循开放标准的 SKILL.md 文件，负责把 LLM 在特定领域表现不佳的工作流"接地"到权威最佳实践上。仓库 README.md 中明确写道：技能开发聚焦于"评测显示 LLM 表现不佳的用例和工作流"，而不去覆盖 LLM 已经熟练的基础领域（如基本的 Jetpack Compose 写法）。这是一个值得玩味的定位：官方技能库不是给 LLM"补常识"，而是给它在踩坑概率最高的工程环节提供封闭的、可验证的操作规程。

这套体系的运转靠一个关键载体：Android CLI。其核心技能文档位于 devtools/android-cli/SKILL.md，命令面覆盖 create（模板建项目）、sdk（SDK 管理）、emulator（虚拟设备管理）、layout/screen（UI 布局与截屏检查）、run（构建部署）、docs（官方知识库检索）以及 skills（技能的安装、查找、更新）。安装一个技能只需一行命令：

android skills add r8-analyzer --project=.
android skills add --all

值得注意的设计是技能即知识库的边界：CLI 里 docs 命令封装了"实时权威文档"的检索，而 SKILL.md 则把那些用文档搜不到、只有踩坑才能总结出来的执行纪律固化下来。以 devtools/android-cli/references/interact.md 为例，它规定了智能体与真机交互的"操作协议"：layout 返回扁平 JSON 树，包含 text、resourceId、interactions、bounds、center 等字段；遇到 WebView 或动画导致 dump 失败时，回退到 screen capture --annotate 做视觉定位，再通过 screen resolve 把标注编号换算成坐标后执行 adb shell input。它甚至要求"进入文本前必须确认字段 state 里有 focused""滚动必须放慢 swipe 时长""操作后等待数秒再 layout --diff"。这些规则不是提示词技巧，而是把 UI 自动化工具链的使用经验编码成了可重复执行的验收标准。

这套"封闭正确性"在 devtools/android-cli/references/journeys.md 的 Journey 测试中体现得最彻底：一次 journey 由一串 <action> 组成，智能体必须逐字执行步骤、以 XML 为唯一事实来源，应用与 journey 冲突即判应用失败。例如：

<journey name="My Journey">
  <description>A sample journey to illustrate the format</description>
  <actions>
    <action>Tap the "Home" icon</action>
    <action>Verify that the app is on its Home screen</action>
  </actions>
</journey>

对官方体系而言，智能体的价值不在"自由发挥"，而在对开发工作流执行纪律的忠实还原。社区对这条路线的主流评价也印证了这一点：多篇中文技术文章提到 Android CLI "通过标准化接口降低 LLM 令牌消耗约 70%、任务执行速度提升 3 倍"，Android Studio 配套技能将典型开发效率提升 40% 以上。同时也有开发者提醒"千万别误用 Android Skills"——把 skill 当成普通提示词堆进上下文，恰恰违背了它"少而精、按需激活"的设计初衷。这条路线擅长的是开发/构建/测试等可枚举的工程场景，一旦超出知识库覆盖范围，正确性就无从谈起。

端侧框架：本地部署与隐私可控的代价

如果说官方技能库解决的是"智能体该按什么流程做事"，端侧框架回答的则是"智能体的大脑与手脚放在哪里"。这一层的代表是仓库 device-ai 目录下的三组能力：AppFunctions（把应用能力以函数形式暴露给系统智能体）、LiteRT（端侧推理运行时）、ML Kit GenAI Prompt API（端侧大模型调用）。

AppFunctions 的定位非常微妙：它不是让智能体去"操作 UI"，而是让应用主动声明一批语义化、参数化、不依赖界面导航的能力，供系统智能体发现与调用。其技能文档 device-ai/appfunctions/SKILL.md 定义了四步工作流：发现候选功能 → 生成 Kotlin 实现 → 打磨 KDoc 供 LLM/MCP 理解 → 用 ADB 本地验证。典型实现长这样（implementation-configuration.md）：

@RequiresApi(36)
@AndroidEntryPoint
@AppFunctionServiceEntryPoint(
    serviceName = "TaskAppFunctionService",
    appFunctionXmlFileName = "task_app_function_service",
)
abstract class BaseTaskAppFunctionService : AppFunctionService() {
    @Inject internal lateinit var taskRepository: TaskRepository

    @AppFunction(isDescribedByKDoc = true)
    suspend fun createTask(
        createTaskParams: CreateTaskParams,
    ): Task = withContext(Dispatchers.IO) {
        if (createTaskParams.title == null && createTaskParams.content == null) {
            throw AppFunctionInvalidArgumentException("Title or content should be non-null")
        }
        val id = taskRepository.createTask(createTaskParams.title, createTaskParams.content)
        return@withContext taskRepository.getTask(id)?.toTask()
            ?: throw AppFunctionElementNotFoundException("Task not found for ID = $id")
    }
}

这套体系有三个显著特点。其一，函数即文档：KDoc 不是注释而是智能体的"使用手册"，kdoc-refinement-optimization.md 要求描述以祈使动词开头、显式声明"Required workflow: Call 'Function A' first"，并在 app_metadata.xml 里记录跨函数依赖与操作模式（例如"优先使用 batch_update 而非多次 update 以降低延迟"）。其二，编译期元数据：从 1.0.0-alpha10 起，@AppFunctionServiceEntryPoint 注解配合 KSP 在编译期生成 service 子类与 XML schema，取代了早期手写 AppFunctionConfiguration.Provider 的繁琐配置，迁移文档见 migrate-to-service-entry-point.md。其三，隐私边界内置在 API 形态里：只有 targetSdk 36 以上的应用才能接入，安全约束明确禁止暴露原始凭据、金融秘密与不可逆的破坏性操作。

推理侧则是 LiteRT 与 Prompt API 的组合。LiteRT（.tflite 的新一代运行时）技能文档 device-ai/litert/litert-runtime/SKILL.md 给出了一个"教科书级"的端侧推理落地范式：CompiledModel 必须由单一后台线程独占（创建、推理、关闭同线程）、TensorBuffer 一次性分配并跨推理复用、init 块内做一次 warm-up 以预编译 GPU 着色器、GPU 失败时回退 CPU：

class Classifier(context: Context, accelerator: Accelerator) : AutoCloseable {
    private val model = CompiledModel.create(
        context.assets, "model.tflite",
        CompiledModel.Options(accelerator), environment
    )
    init {
        try {
            inputs += model.createInputBuffers()
            outputs += model.createOutputBuffers()
            infer(FloatArray(INPUT_SIZE))   // warm-up
        } catch (e: Exception) { close(); throw e }
    }
    fun infer(input: FloatArray): FloatArray {
        inputs[0].writeFloat(input)
        model.run(inputs, outputs)
        return outputs[0].readFloat()
    }
}

而 device-ai/ml-kit-genai-prompt-api/SKILL.md 展示了另一层端侧智能：Gemini Nano 通过 ML Kit Prompt API 在设备上做自然语言生成，配合 Structured Output API 用 @Generable/@Guide 注解定义输出 schema，让模型直接返回强类型的 Kotlin 对象而非脆弱的 JSON 字符串；超过 200 词的提示词还要接 prefix caching 优化。

端侧路线的代价是显而易见的：模型体积、硬件门槛（Gemini Nano 依赖 AICore 与设备能力）、推理配额，以及——比这些都更根本的——能力供给侧的结构性缺口。AppFunctions 目前仍处于 1.0.0-alpha 阶段，仓库中反复出现的 targetSdk 36、@RequiresApi(36)、KSP 版本锁定都说明它尚在快速演进期。社区情报也印证了这一点：PalmClaw 这类开源端侧框架强调"将推理循环完全本地化、隐私可控、部署门槛低"，但其代价是模型能力上限即系统上限——本地小模型的意图理解、复杂任务拆解能力与云端大模型仍有代差。端侧换来的是隐私主权与离线可用，让渡的是上限与生态成熟度。

GUI 执行器：跨应用办事与自进化记忆的路线

第三条路线的假设与官方体系截然相反：与其要求应用主动暴露能力，不如让智能体直接"看屏幕、点屏幕"。这也是 PalmClaw、KnowAct-GUIClaw、X-OmniClaw 等开源框架的共识。

这类框架的技术栈可以拆成三层。第一层是视觉感知与坐标操作——这与官方技能库意外地共享了同一套底层语言。官方 interact.md 中 adb shell input tap 152 23 这类"读布局 → 算坐标 → 注入输入"的范式，正是 GUI 智能体的最小单元；KnowAct-GUIClaw 在此基础上加入了"知-路-行-思"四步闭环与主控/执行双智能体架构，用黑板机制在多个 App 之间传递中间信息，宣称在 MobileWorld 基准上以开源模型超越闭源大模型。第二层是无障碍服务与系统权限：社区中被广泛传播的 Open Minis 支持 Android 10+，靠无障碍服务做控件级操作、Shizuku 拿系统级权限，并支持 SKILL.md 自定义技能与 MCP 协议扩展；"一台吃灰安卓机改造成 AI 智能体"的高流量文章（14 万+ 阅读）则展示了 Termux + OpenClaw + 无线 ADB 的低门槛组合拳。第三层是自进化记忆：KnowAct-GUIClaw 的双轨记忆机制（经验记忆 + 技能库）允许知识跨模型迁移——这是 GUI 路线对"正确性"问题的独特回答：既然无法像官方技能库那样预置正确规程，那就让智能体在试错中把"怎么做成功"沉淀为可复用的技能。

GUI 路线的价值在跨应用、跨生态的场景中最大：KnowAct-GUIClaw 宣称验证覆盖 Android、HarmonyOS 与 Windows 三平台，X-OmniClaw 作为多模态 Agent 更进一步把摄像头、麦克风等设备感知纳入闭环。但其风险同样突出：UI 结构变化会导致坐标失效、无障碍节点缺失时只能盲点、跨应用状态一致性难以保证——社区也如实记录了 GUI 智能体在"短信发送中按钮定位"这类琐碎交互上的翻车案例。相比官方 AppFunctions 的结构性正确（能力即函数、schema 即契约），GUI 执行器的正确性是统计性的：靠模型推理 + 记忆积累逼近成功，但永远存在不可控的失败面。

按场景选型：三条路线不是替代关系

把三条路线放在一起看，本质是"智能体能力暴露方式"的三种策略：

维度	官方技能库（Android CLI/Skills）	端侧框架（AppFunctions/LiteRT/Prompt API）	GUI 执行器（PalmClaw/KnowAct-GUIClaw 等）
正确性来源	封闭的权威规程（SKILL.md + journeys）	结构化 API 契约（schema + KDoc）	视觉推理 + 自进化记忆
典型场景	开发、构建、测试、审查	系统级助手、离线任务、隐私敏感场景	跨 App 办事、多平台自动化
隐私边界	全本地 CLI	全端侧推理，能力由应用显式声明	本地执行 + 记忆，但依赖系统权限
主要代价	覆盖范围限于官方知识库	依赖 API 成熟度与硬件能力	失败面不可控、UI 变更敏感

选型建议可以浓缩为三句话：

• 做开发工具/CI 自动化：直接走官方技能库路线。android skills add --all 把 devtools/android-cli/SKILL.md、performance/r8-analyzer/SKILL.md 这类经过评测筛选的技能装进智能体，配合 journey 测试获得可复现的正确性——这是当前唯一"正确性有官方兜底"的方案。
• 做产品内的系统级智能体：优先押注 AppFunctions + 端侧推理的组合。应用主动把 createTask、sendMessage 这类原子能力声明为函数，模型只在函数空间里做决策，天然规避了 GUI 操作的脆弱性；隐私敏感数据不出设备，正好契合端侧框架的定位。
• 做跨应用、跨平台的通用助手：GUI 执行器目前是唯一现实选项，但要接受其工程代价——需要为 UI 变更做容错、为权限做分级管控、为记忆做持久化设计。社区实践中的经验（如 PalmClaw 的参数/权限/工作目录三层执行边界校验）值得直接借鉴，而 X-OmniClaw 的多模态感知则代表了这条路线下一阶段的想象空间。

值得强调的是，三条路线并非互斥。官方体系与 GUI 路线共享 adb shell input 这套操作语法，AppFunctions 的"函数即接口"理念与 MCP 协议同构，自进化记忆最终沉淀出的"技能"在形态上也正在向 SKILL.md 靠拢。智能体在安卓上的终局，大概率不是某条路线的独胜，而是结构化能力声明与通用 GUI 操作在系统层合流——到那时，"让手机替你办事"才真正从 Demo 变成默认。