手机端智能体横评：官方技能库、端侧框架、云端 GUI 谁更务实

在 2026 年的 Android 生态里，"智能体"已经不再是一个停留在发布会 PPT 上的概念。Google 在 Android Studio 与 Android CLI 里批量下发"技能"（Skills）；端侧推理框架把 Gemini Nano、LiteRT 模型直接塞进手机芯片；与此同时，一批基于屏幕截图 + 坐标点击的云端 GUI 智能体也在跨应用"办事"。三条技术路线都在抢同一个问题的答案——手机上的 AI 到底该以什么方式帮人干活？

本文不站队，只做"横评"：以本仓库（README.md）中的官方技能库为原点，结合社区公开的 PalmClaw、KnowAct-GUIClaw 等真实系统数据，从开发场景覆盖、隐私边界、资源门槛、成本与延迟四个维度，拆解三条路线的真实适用边界，最后给出一张按场景落地的决策表。

官方技能库：开发场景强，通用场景受限

Google 官方技能的定位很直白：用 Markdown 指令让 LLM 在特定领域"补课"。README.md 明确写道，仓库只覆盖"评测中 LLM 表现不佳的工作流"，而不是已有的成熟领域——这是一个非常克制的取舍。

技能库的载体是两件套：android CLI + 各类 SKILL.md。安装即用：

android skills add r8-analyzer --project=.
android skills add --all
android skills update wear-compose-m3

为什么开发场景"强"

CLI 把 LLM 不擅长的"摸黑操作"全部变成了结构化接口。devtools/android-cli/SKILL.md 暴露了整套命令体系：create 建项目、sdk 管依赖、layout 输出 UI 树 JSON、screen 截图并标注坐标、docs 检索官方知识库、skills 增删技能。社区实测数据是"令牌消耗降低 70%、任务执行速度提升 3 倍"——逻辑不难理解：模型不再需要用自然语言猜"这个按钮在哪"，而是直接拿到 {"bounds": "[138,9][167,38]", "center": "[152,23]"} 这样的结构化输入。

交互层也做了极致的确定性约束。devtools/android-cli/references/interact.md 里写满了硬规则："输入文本前必须确认 focused 状态""滚动必须用 swipe 并控制时长""点击必须用 adb shell input tap <x> <y>"——把 LLM 的随机性压缩到最小。配合 --diff 只输出变化节点，上下文窗口开销也被压到极低。

技能内容是"对症下药"的：edge-to-edge 迁移（system/edge-to-edge/SKILL.md）、R8 冗余规则分析（performance/r8-analyzer/SKILL.md）这类 LLM 容易答错、又高频出现的活，都被固化成可重复执行的检查清单与报告格式。

为什么通用场景"受限"

这套体系的服务对象是开发者，不是最终用户。CLI 的 docs 检索的是 Android 开发者文档，layout/screen 服务于工程调试，技能库覆盖范围从相机（camera/camerax/SKILL.md）到导航（navigation/navigation-3/SKILL.md），几乎全是"写代码"的垂直领域。

换句话说：它解决的是"AI 帮人写 App"，而不是"AI 替人用 App"。如果你想让它帮你点外卖、跨 App 传文件、管理日程——官方技能库没有、也不打算提供这类"面向用户的操作技能"。它的强项恰恰是它的天花板：领域收敛、指令确定、面向工程。

端侧框架：隐私强，资源门槛高

如果说技能库是"教 LLM 干活"，端侧框架就是"把干活的本事直接装进手机"——包括能力暴露、推理运行、模型分发三块，本仓库恰好各有一个代表性样本。

能力暴露：AppFunctions

AppFunctions 把"App 的原子能力"注册为系统可发现、可调用的函数。device-ai/appfunctions/SKILL.md 描述的流程是四步：发现工作流 → 生成 Kotlin 实现 → 精修 KDoc 供 LLM 理解 → 用 ADB 测试。一个典型的"发消息"函数长这样：

@RequiresApi(36)
@AndroidEntryPoint
@AppFunctionServiceEntryPoint(
    serviceName = "MessagingAppFunctionService",
    appFunctionXmlFileName = "messaging_app_function_service",
)
abstract class MessagingAppFunctionService : AppFunctionService() {
    @AppFunction(isDescribedByKDoc = true)
    suspend fun send(endpointValue: String, messageBody: String): SendResult =
        withContext(Dispatchers.IO) { /* ... */ }
}

关键在设计约束：device-ai/appfunctions/references/feature-discovery-analysis.md 要求优先暴露"写操作与富查询"，因为"纯信息展示"类函数与系统既有动作冗余；device-ai/appfunctions/references/implementation-configuration.md 则明确禁止暴露密码、金融密钥与不可逆的破坏性操作。测试链路同样系统化：adb shell cmd app_function list-app-functions 列出注册函数，execute-app-function 直接以 JSON 参数调用——全程不需要打开 App 界面。

这条路线的意义在于：它绕开了 GUI 模拟，让智能体走"服务调用"而非"屏幕点击"，这与 PalmClaw 论文中"终端原生智能体已证明标准化工具调用优于纯界面操作"的结论互相印证。

推理运行：LiteRT 与 ML Kit GenAI

推理层有两套分工：LiteRT 跑传统模型（图像分类、嵌入、音频），ML Kit GenAI Prompt API 跑 Gemini Nano 生成式模型。

device-ai/litert/litert-runtime/SKILL.md 展示了端侧推理的工程严谨度：CompiledModel 必须单线程持有、TensorBuffer 必须复用、GPU 编译失败要自动回退 CPU，甚至要处理 Bitmap.Config.HARDWARE 导致 getPixels 读不了这种隐藏坑。这些约束全部来自真实生产教训——它说明端侧推理是"可以跑，但跑好需要纪律"。

生成式端侧则给出了一份很有说服力的性能账。ML Kit Prompt API 的 prefix caching（device-ai/ml-kit-genai-prompt-api/references/prefix-caching.md）在 Pixel 9 上的实测数据：

场景	无前缀缓存	命中缓存
300-token 固定前缀 + 50-token 动态后缀	0.82 秒	0.45 秒
1000-token 固定前缀 + 100-token 动态后缀	2.11 秒	0.5 秒

1000-token 前缀场景下延迟降低约 76%，说明"把静态指令固化在设备上"这条路是走得通的。同时device-ai/ml-kit-genai-prompt-api/references/get-started.md 也老实交代了边界：输入上限 4000 token、AICore 按 App 配给推理配额——端侧不是无限算力。

模型分发：AI Pack

大模型怎么装进手机？device-ai/litert/litert-runtime/references/android/google/play/on-device-ai.md 给出的答案是 Play for On-device AI 的 AI Pack：单个包压缩后可达 1.5GB，累计上限 4GB，支持安装时、快速跟进、按需三种交付模式，还能按 SoC、RAM、机型做设备定向分发。这是一套完整的"模型供应链"。

但资源门槛是真实存在的

端侧路线的痛点全部写在仓库里：AppFunctions 要求 targetSdk 36/compileSdk 37（Android 16 起步）；LiteRT 要求 minSdk 24 且 GPU 加速器要单独打一个 AAR；Gemini Nano 需要特定 SoC + 机型 + 下载模型 + 配额。对用户是"隐私留在本地"，对开发者却是一堆机型碎片化与包体膨胀的代价。PalmClaw 的论文数据（成功率相对提升 11.5%、平均耗时降低 94.9%）很漂亮，但那是"任务成功率"，前提同样是目标设备跑得动端侧模型——这恰恰是它在海量中低端安卓机上最大的不确定性。

云端 GUI：能力大，成本与延迟不可控

第三条路线是社区里最热闹的：把手机屏幕截图给云端大模型，模型推理出"点击哪个坐标"，再通过 ADB/无障碍服务执行。本仓库的 devtools/android-cli/references/interact.md 里 screen capture --annotate + screen resolve 把标注框换算成 tap #34 坐标的做法，本质上就是 GUI 智能体在开发侧的雏形。

这条路线"能力大"是真实的：Open Minis、KnowAct-GUIClaw 这类系统能跨 App 办事、能读屏幕上的图片内容（WebView 内容在 UI dump 里缺失，只能靠截图）、能用无障碍服务操作几乎任何 App——通用性远胜端侧。KnowAct-GUIClaw 的"知-路-行-思"四步闭环与黑板机制，正是为了处理"多 App 之间信息传递"这类 GUI 路线的老大难问题。

但代价同样真实，且基本都来自不可控性：

• 延迟与成本不可控：每一步"看屏幕-想-点"都是一次云端推理。多步任务的 token 消耗线性膨胀，网络抖动直接导致操作链断裂——这正是 devtools/android-cli/references/interact.md 反复强调"先看截图再做任何操作"的原因，因为模型在 GUI 上的每一步判断都是弱保证的。
• 稳定性不可控：PalmClaw 论文对 GUI 路线的三连击很致命——超长操作序列在页面改版后必然失效、读不到底层传感器与文件、权限宽泛缺乏单任务边界。社区情报中"短信发送按钮定位困难""布局微调即流程失效"都是这条路的日常。
• 隐私边界不可控：截图即上传，意味着整屏数据（含通知、相册预览）都过云端。这与端侧"数据不出设备"形成鲜明对比。

一张决策表：按场景给结论

维度	官方技能库	端侧框架	云端 GUI
典型代表	Android CLI + Skills	AppFunctions + LiteRT + Gemini Nano	Open Minis / KnowAct-GUIClaw
核心优势	输出确定、令牌开销低、贴合工程最佳实践	数据不出设备、延迟可控、可离线	通用性强、跨 App 无死角、无需改造 App
核心短板	只服务开发场景，面向用户的操作能力为零	机型门槛高、模型下载大、开发复杂度陡增	每一步都依赖网络与模型，成本延迟双高
隐私等级	中（本机为主，模型可云端）	高（全本地）	低（截图上传）
资源门槛	低（安装 CLI 即用）	高（targetSdk 36+ / minSdk 24+ / 特定 SoC）	中（需常驻后台与无障碍/ADB 权限）
适用人群	Android 开发者、CI 自动化	对隐私敏感的垂直 App、旗舰机用户	尝鲜玩家、跨应用自动化爱好者

落到具体选择上：

• 你是开发者，想提升 AI Coding 效率——官方技能库是唯一正确答案。android skills add 一键落地，layout --diff 控制上下文开销，产出是确定性的工程结果，几乎没有替代品。
• 你要做"数据不出手机"的垂直智能体（本地相册整理、离线助手、隐私敏感场景）——端侧框架值得投入，但务必先做机型矩阵评估：Gemini Nano 的配额与机型支持、LiteRT 的 GPU 回退、AI Pack 的 1.5GB 上限都会直接决定产品形态。
• 你要追求"什么都能干"的通用助手——云端 GUI 现阶段最务实，但请把"失败重试、超时降级、敏感信息脱敏后再截屏"当成第一优先级工程，而不是功能本身。

三条路线并不互斥。仓库的布局暗示了未来形态：AppFunctions 为 GUI 智能体提供"走后门"的原生通道（绕过点击），prefix caching 把云端 GUI 的长提示词固化到端侧，AI Pack 则让大模型越来越容易"落机"。务实的选择不是押注某一条，而是让 AI 尽量走确定性的接口，只在没有接口的地方才用屏幕——这正是"手机端智能体"接下来一年最值得观察的收敛方向。