端侧大模型优化与手机 Agent：速度、缓存、本地推理和 FoneClaw 动作体验

手机 Agent 体验先看等待时间，而不是只看跑分

用户对手机 Agent 的耐心很短。说一句“帮我回复这条消息，发送前让我确认”，如果手机迟迟没有反应，或者先弹出一堆看不懂的中间状态，体验就已经断了。端侧大模型优化 手机 Agent 的第一层价值，是把等待时间、内存压力、电量消耗和可见确认放在同一个体验里看。

模型速度当然重要，但手机场景更复杂。一个手机 Agent 要理解语音或文本、判断当前屏幕、准备下一步、打开应用、生成草稿、等待用户确认。任何一步卡住，用户都会觉得“这个助手不顺手”。所以评价本地 AI 推理时，要看首个响应、连续交互、后台切回前台、低电量表现和失败后的恢复路径。

Android Developers 的 Gemini Nano 文档介绍，Gemini Nano 通过 Android AICore 提供端侧生成式 AI 能力，面向低延迟、隐私友好和支持设备上的无网络体验。对手机 Agent 来说，这意味着一些短任务可以在本机更快准备结果，例如摘要、分类、短回复和局部理解。

在 FoneClaw，我们把速度转化为用户能看见的 Android 手机动作：应用是否打开、消息草稿是否出现、提醒是否创建、确认是否清楚。想看手机动作本身如何工作，可以延伸阅读 AI Agent 如何控制手机。

模型大小、量化和小模型分工怎么影响手机任务

手机不是云端机房。模型越大，通常越需要内存、计算和电量；模型越小，响应更轻，但理解复杂任务的能力也要靠设计补足。移动端 LLM 优化的核心，是把合适的模型放到合适的任务上。

量化可以把模型用更紧凑的数字表示，减少存储和计算压力；适配器可以让基础模型适配特定任务；小模型分工则适合做“先判断、再执行”的前置工作。比如识别“这是消息回复”“这是提醒”“这是导航请求”，并不总需要一个巨大的模型。

Apple 在 Apple Foundation Models 2025 更新中提到端侧模型效率相关工作，包括 KV cache 共享、量化、适配器，以及本地和服务器模型分工。这里对 Android 用户也有启发：手机 Agent 的成熟体验往往来自多种模型和路径的配合，而不是单个模型包办所有任务。

FoneClaw 的产品体验会把这些底层选择落到任务层：短指令、本地分类、草稿准备、提醒创建和可见确认适合快速处理；需要长推理、复杂上下文或跨资料判断时，可以进入更强的思考路径。用户感受到的应该是“下一步清楚”，而不是模型术语。

AICore、Gemini Nano、ML Kit GenAI、LiteRT-LM 的 Android 路径

端侧大模型要在手机上可用，不能只靠模型文件，还需要系统服务、开发接口、运行库和设备能力。Android 生态里，AICore、Gemini Nano、ML Kit GenAI、Google AI Edge、LiteRT 和 LiteRT-LM 都在承担不同层面的角色。

Google ML Kit GenAI Prompt API 文档说明，开发者需要检查设备功能可用性，可以下载 Gemini Nano，并使用 warmup 来降低首次调用延迟；文档也写到 token 限制和每个应用的额度。对用户来说，这会表现为：有些功能需要等待模型准备，有些任务有输入长度或调用频率限制。

Google AI Edge展示了跨平台端侧 ML 和 AI 工具，包括 MediaPipe task APIs、LiteRT 和 LiteRT-LM。LiteRT-LM 概览进一步呈现本地 LLM 示例，以及 prefill、decode、首 token 时间、CPU/GPU 后端、内存和离线本地模型执行等性能维度。

这些路径决定了手机 Agent 的“实际可用感”。同样是本地 AI，有的适合短摘要，有的适合结构化输出，有的适合多轮对话，有的适合离线小任务。与操作系统、芯片和应用的关系，可以参考 OS Agent 三层基础，本文重点放在手机 Agent 的体感结果。

KV cache、预填充、解码和预热为什么影响体感速度

用户看见的等待，背后常常来自几个环节。模型先读取上下文，这可以理解为“预填充”；然后逐步生成输出，这就是“解码”。KV cache 用来保存已经处理过的上下文信息，连续或重复任务中如果能合理复用，体感速度会更稳定。

比如你每天早上都让手机整理通知、准备上班路线、生成一条 ETA 消息。这样的重复流程里，系统如果已经知道任务结构、常用联系人、常用应用和短指令格式，就能更快进入下一步。缓存不是魔法，它更像把前面已经做过的理解保留下来，让后续同类任务少绕路。

warmup 也很关键。首次调用模型时，系统可能需要准备模型、加载资源或初始化运行环境。ML Kit GenAI Prompt API 文档提到 warmup 可用于降低首次调用延迟。对用户而言，最明显的差别就是第一次点开某个 AI 功能时是否慢，第二次是否更顺。

上下文长度也要适量。手机 Agent 不需要把所有历史都塞进一次请求。更好的方式是保留当前任务需要的信息：屏幕上可见内容、用户刚说的目标、即将执行的应用动作和确认状态。FoneClaw 会围绕这些可见状态组织 Android 手机动作，让缓存和上下文服务于用户当前任务。

本地推理和云端思考怎样配合 FoneClaw 手机动作

本地 AI 很适合短、快、重复、隐私敏感或无网络也要处理的任务：通知分类、短回复草稿、简单摘要、指令识别、屏幕可见状态判断。云端推理适合更长、更复杂、更开放的问题，例如多资料比较、长文分析、复杂计划和需要更强模型能力的推理。

Apple Foundation Models 框架展示了另一条系统级路径：应用可以使用端侧语言模型完成 Apple Intelligence 任务、结构化输出和工具调用。不同平台实现不同，但共同趋势是：本地模型承担更多即时任务，复杂任务再进入更强路径。

在 FoneClaw，我们把本地和云端的组合落到可见 Android 动作。比如本地快速判断“这是消息回复”，生成短草稿；需要更复杂表达时，再走更强推理；发送前仍然让用户看到收件人、正文和确认按钮。提醒、导航、应用打开、屏幕检查也是类似逻辑。

关于云端与本地路线的取舍，可以看 云端与本地 AI Agent。本文的重点是：无论模型在哪里运行，手机 Agent 都要把结果变成用户看得见、能确认、可恢复的 Android 手机动作。

评估端侧 LLM 手机功能的实用清单

看到一项“端侧 AI”或“本地大模型”功能时，可以按这份清单判断它是否适合手机 Agent 使用。

• 设备支持：功能是否需要特定 Android 版本、芯片、内存、AICore 或模型下载状态。
• 离线行为：无网络时能完成哪些短任务，哪些任务会等待网络或更强模型。
• 延迟：首次调用、连续调用、从后台回到前台时是否稳定。
• 额度和长度：是否有 token 限制、每应用额度或输入长度限制。
• 电量和发热：长时间使用后，手机是否仍能维持正常交互。
• 隐私和权限：哪些数据在本机处理，哪些操作需要应用或系统权限。
• 可见结果：草稿、提醒、应用打开、状态检查是否清楚显示。
• 恢复路径：模型未准备好、额度用完或网络变化时，是否能保存草稿、设置提醒或改走手动确认。

端侧大模型优化 手机 Agent 的最终价值，不在于把术语堆满页面，而在于让日常 Android 动作更快、更省电、更清楚。FoneClaw 会继续围绕受支持的手机动作设计体验：把意图转成可见步骤，把本地推理放到适合的位置，把确认保留在用户需要掌控的地方。