1. 为什么 Android 上的 AI Agent 不是“把大模型搬进手机”那么简单
“Android 平台 AI Agent 技术架构深度解析”——这个标题里藏着一个巨大的认知陷阱。很多人看到“AI Agent”，第一反应就是：找一个轻量版大模型（比如 Gemma 或 Phi-3），用 TensorFlow Lite 封装一下，塞进 APK，再配个聊天界面，完事。我去年在某电商 App 的内部技术分享会上就亲眼见过这样的 POC 演示：模型加载耗时 8.2 秒，首次推理响应 4.7 秒，连续问三个问题后手机表面温度飙升到 42℃，电池掉电 15%。台下掌声很热烈，但没人问一句：“这东西真能推给千万用户吗？”
真正的难点从来不在“能不能跑”，而在于“能不能稳、能不能省、能不能藏”。Android 是一个资源高度受限、碎片化极其严重、用户容忍度极低的平台。它不像服务器端可以堆显卡、加内存、开散热风扇；也不像 iOS 有统一的硬件生态和严格的审核机制来兜底。在这里，一个 AI Agent 的成败，取决于你是否愿意为每一毫瓦功耗、每一毫秒延迟、每一字节内存去抠细节。
关键词里出现的Private Compute Core和Gemini Nano就是 Google 给出的破局思路，但它们不是银弹，而是两套截然不同的设计哲学。Private Compute Core 是一套系统级的隐私沙箱，它不提供模型能力，只提供安全执行环境；Gemini Nano 则是首个真正意义上为移动端深度定制的轻量级模型，但它必须运行在 Private Compute Core 提供的受信环境中，二者是“能力”与“容器”的关系。很多团队误以为只要集成了 Gemini Nano SDK 就万事大吉，结果在 Android 12 设备上直接崩溃——因为 Private Compute Core 是 Android 13+ 才原生支持的系统组件，低版本需要厂商定制适配，而市面上 30% 的活跃设备仍停留在 Android 12。
更现实的挑战来自应用层。你写的那个“智能日程助手”Agent，它要读取日历、分析邮件、调用地图 API、生成待办事项，还要在后台持续监听通知栏关键词。这些操作在传统 App 开发里是分散的、按需触发的权限请求；但在 Agent 场景下，它们必须被抽象成可组合、可编排、可中断的Skill单元。而 Skill 的生命周期管理，恰恰是 Android 原生框架最薄弱的一环。Activity 和 Service 的启动限制、JobScheduler 的调度精度、WorkManager 的执行窗口，全都在和你的 Agent “抢资源”。我见过最典型的案例：一个新闻摘要 Agent 在后台使用 WorkManager 每 15 分钟拉取一次 RSS，结果在 Android 14 上被系统判定为“高耗电行为”，三天后自动禁用——因为它的唤醒间隔低于系统允许的最小阈值（30 分钟）。
所以，这篇文章不讲“如何调用 Gemini Nano API”，那只是 5 分钟就能查到的文档内容；我们要拆解的是：当你要在一个真实世界的 Android 设备上，让一个 AI Agent 既聪明又安静、既强大又省电、既灵活又可靠时，你必须亲手搭建的那套底层骨架。它由四个不可分割的支柱构成：隐私可信的执行边界、模型与设备的协同调度、技能驱动的行为编排、以及面向碎片化的降级策略。接下来，我们就从这四根支柱出发，一层层剥开 Android AI Agent 的真实技术肌理。
2. Private Compute Core：不是“沙箱”，而是 Android 系统的“可信根”
很多工程师第一次听说 Private Compute Core（PCC），会下意识把它等同于一个更高级的 Android App Sandbox。这是个危险的误解。App Sandbox 是 Linux kernel 层面的 UID 隔离，它解决的是“不同 App 之间不能互相读写数据”的问题；而 PCC 是一个运行在 TrustZone（或类似安全 enclave）中的独立操作系统微内核，它解决的是“连操作系统本身都不能窥探我的数据”的问题。你可以把 App Sandbox 想象成一栋公寓楼里的各个房间，门锁是 Linux 权限；而 PCC 则是这栋楼地下 10 米深的一个独立金库，连物业管理员的钥匙都打不开。
PCC 的核心价值，在于它定义了 Android 平台上 AI 计算的“信任锚点”。当你调用 Gemini Nano 进行本地推理时，输入的文本、图像、语音特征向量，全部在 PCC 内存中完成处理，计算结果以加密形式返回给主系统，原始数据永远不会离开安全区域。这意味着，即使你的 App 被恶意软件劫持，或者系统被 root，攻击者也无法窃取用户刚刚输入的健康咨询记录或财务分析草稿。这不是靠代码逻辑实现的“软防护”，而是靠硬件隔离实现的“硬边界”。
但 PCC 的部署远非“开箱即用”。它的启用依赖于三个层级的严格对齐：
| 层级 | 关键组件 | 对齐要求 | 常见失败场景 |
|---|---|---|---|
| 硬件层 | SoC 安全模块（如 Qualcomm Secure Processing Unit, Samsung Knox Vault） | 必须支持 ARM TrustZone 或等效安全 enclave，并通过 Google 的 CTS-Verified 认证 | 某国产中端芯片虽标称支持 TrustZone，但未通过 CTS 认证，PCC 初始化失败 |
| 系统层 | Android OS 内核与 HAL（Hardware Abstraction Layer） | Android 13+ 原生集成，但 OEM 厂商需在 vendor 分区提供定制的pcc_serviceHAL 实现 | 某品牌 Android 14 定制 ROM 中，pcc_serviceHAL 版本过旧，导致 Gemini Nano 加载超时 |
| 应用层 | Google Play Services 与 Private Compute SDK | 必须通过 Google Play Services 更新至最新版，且 App 需声明android.permission.USE_PRIVATE_COMPUTE_CREDENTIALS权限 | 用户禁用 Google Play Services 自动更新，SDK 调用PrivateComputeClient.create()返回UNAVAILABLE |
我亲身踩过的一个坑，是在一台 Pixel 7a（Android 14）上调试时发现，同样的代码在开发机上运行正常，但在测试机上始终无法初始化 PCC。排查了三天，最终发现是测试机的 Google Play Services 版本比开发机低了两个小版本（24.24.13 vs 24.26.15）。官方文档里只写了“需要最新版”，但没明确说哪个小版本号是分水岭。后来翻到 Google 的 AOSP issue tracker，才找到一条被标记为fixed-in-next-release的 patch，修复了一个在特定 HAL 版本下pcc_service的 IPC 序列号校验 bug。
更关键的是，PCC 并非万能。它只为计算提供安全环境，但不负责模型本身的轻量化与优化。Gemini Nano 的 .tflite 模型文件，如果未经量化压缩，体积可能超过 120MB。而 PCC 的内存空间是严格受限的（通常不超过 512MB），过大的模型会直接导致OutOfMemoryError。因此，实际工程中，我们必须在模型交付前完成三重瘦身：
- INT8 量化：使用 TensorFlow Lite 的
TFLiteConverter，将 FP32 权重转换为 INT8，模型体积减少约 75%，推理速度提升 2-3 倍，精度损失控制在 1.5% 以内（经我们实测，在新闻摘要任务上 BLEU-4 分数仅下降 0.8）； - 算子融合：将
Conv2D + ReLU + BatchNorm等常见组合算子合并为单个高效内核，避免中间张量在 PCC 内存中反复拷贝； - 动态形状裁剪：Gemini Nano 支持可变序列长度，但默认配置会为最大长度（如 2048）预留内存。我们在初始化时根据用户设备的 RAM 容量（通过
ActivityManager.getMemoryClass()获取）动态设置max_sequence_length=1024或512，将 PCC 内存占用降低 40%。
提示：PCC 的初始化是一个异步、高成本的操作。不要在主线程
onCreate()里直接调用PrivateComputeClient.create()。我们采用的方案是：在 App 启动时，用WorkManager提交一个一次性后台任务，提前初始化 PCC 并缓存PrivateComputeClient实例。这样当用户首次触发 AI 功能时，响应时间从 1.2 秒降至 180ms。
3. Gemini Nano 的“非典型”集成：模型即服务，而非模型即库
Gemini Nano 的官方集成方式，是通过 Google Play Services 提供的PrivateComputeClient接口。但如果你把它当成一个普通的 Java/Kotlin 库来用，很快就会撞上一堵墙：它不提供Model.load()、Interpreter.run()这样的底层 API。你无法直接访问模型权重、无法修改网络结构、无法插入自定义算子。它是一个彻头彻尾的Model-as-a-Service（MaaS）封装。
这种设计是 Google 的深思熟虑。它牺牲了开发者的“绝对控制权”，换取了系统级的稳定性与安全性。试想，如果每个 App 都能自由加载任意 .tflite 模型到 PCC，那么一个恶意 App 就可能通过精心构造的模型触发 TrustZone 内存越界漏洞。因此，Gemini Nano 的模型文件（.tflite）是经过 Google 签名认证的，只有签名匹配的模型才能被 PCC 加载。你无法用自己的模型替换它，也无法绕过签名验证。
但这并不意味着你失去了定制能力。Nano 的能力是通过一组预定义的、语义化的API Contract暴露出来的。目前公开的 Contract 主要有三类：
TextGenerationContract：用于通用文本生成，如续写、摘要、翻译。它接受TextGenerationRequest（含 prompt、temperature、max_output_tokens），返回TextGenerationResponse。ImageUnderstandingContract：用于多模态理解，如图像描述、视觉问答。它接受ImageUnderstandingRequest（含 Bitmap 或 URI），返回ImageUnderstandingResponse。SpeechRecognitionContract：用于离线语音识别，返回文本结果。
这些 Contract 的背后，是 Google 在模型层面做的深度优化。例如，TextGenerationContract的 prompt 工程并非由你完成，而是由 Nano 内置的、针对移动端微调过的 tokenizer 和 prompt template 自动处理。你传入的"请总结这篇新闻"，会被自动补全为"You are a helpful assistant. Summarize the following news article in no more than 100 words: [ARTICLE_TEXT]"。这种“黑盒式”封装，让开发者免于陷入复杂的 prompt engineering 泥潭，但也意味着，如果你的需求超出了 Contract 的语义边界（比如需要模型输出 JSON 格式，或进行特定领域的实体抽取），你就必须另寻他路。
我们的解决方案是：构建一个混合推理引擎（Hybrid Inference Engine）。它由两层组成：
- PCC 层（高信任、低自由度）：严格遵循 Google 的 Contract，处理所有涉及用户隐私、需要强保证的核心任务，如健康咨询、财务分析、敏感对话摘要。
- APK 层（低信任、高自由度）：在主应用进程中，使用 TFLite 或 ONNX Runtime 加载我们自己训练和优化的轻量模型（如一个 15MB 的领域专用 BERT 变体），处理非敏感、高定制化任务，如 App 内 UI 元素识别、本地文档关键词提取、个性化推荐排序。
这两层之间通过一套严格的Data Boundary Protocol进行通信：
- 所有从 PCC 层传出的数据，必须经过
AES-256-GCM加密，并附带HMAC-SHA256签名； - 所有传入 APK 层的数据，必须经过
ContentProvider的 URI 权限校验，并在接收端进行二次解密与签名验证； - 任何跨层调用，都必须记录完整的审计日志（
Log.d("AI_Boundary", "PCC->APK: TextGen, size=245B, sig_valid=true")），日志存储在Context.getNoBackupFilesDir()下，确保即使设备丢失，日志也不会泄露。
这套混合架构，让我们在合规性与灵活性之间找到了平衡点。上线三个月后，用户对 AI 功能的“可信度”评分（NPS）达到 72，远高于纯 PCC 方案的 58，也高于纯 APK 方案的 41。数据证明，用户既需要“我知道我的数据是安全的”这种确定性，也需要“它真的懂我在说什么”这种体验感。
4. Skill 编排引擎：让 AI Agent 从“玩具”变成“工具”
一个能回答问题的聊天机器人，和一个能帮你订机票、查快递、回邮件的 AI Agent，本质区别是什么？答案是：Skill（技能）。Skill 是 Agent 的原子能力单元，它封装了特定领域、特定目标、特定副作用（Side Effect）的一组操作。BookFlightSkill不仅仅是一个函数，它是一套状态机：它需要获取用户出发地/目的地、查询航班 API、解析返回的 JSON、处理网络错误、在 UI 上展示选择列表、等待用户确认、调用支付 SDK、最后发送成功通知。整个过程，跨越了网络、UI、存储、系统服务等多个 Android 组件。
在 Android 上构建 Skill，最大的陷阱是试图用传统的ViewModel或Repository模式去承载它。ViewModel的生命周期绑定于 UI，而一个SendEmailSkill可能在用户切到后台后才真正开始执行；Repository是数据访问层，它不该承担业务流程编排的职责。我们需要一个全新的、专为 Agent 设计的Skill Lifecycle Manager（SLM）。
SLM 的核心设计原则是：Stateful, Resumable, Observable。
- Stateful：每个 Skill 实例必须持久化其完整状态（
SkillState），包括当前步骤、已获取的参数、临时数据、错误信息。我们使用Room数据库，为每个 Skill 创建一张表，主键为skill_id（UUID），状态字段为state_json（Gson 序列化的 JSON 字符串）。这样，即使 App 被系统杀死，重启后也能从数据库中恢复 Skill 的精确断点。 - Resumable：SLM 必须能响应 Android 系统的各种生命周期事件。当
SendEmailSkill正在等待用户授权邮箱账户时，用户按了 Home 键，SLM 会自动将 Skill 置为PAUSED状态，并注册一个ActivityLifecycleCallback。当用户再次回到 App，SLM 检测到onResume()，便会检查数据库中该 Skill 的状态，若为PAUSED，则自动恢复到等待授权的 UI 页面。 - Observable：外部（如 UI）必须能实时观察 Skill 的状态变化。我们采用
LiveData<@JvmSuppressWildcards SkillState>作为标准接口。UI 层只需observe(this, state -> updateUI(state))，无需关心 Skill 是在前台运行、后台执行，还是被系统挂起。
一个典型的CheckPackageStatusSkill的执行流程如下：
class CheckPackageStatusSkill( private val packageRepo: PackageRepository, private val notificationManager: NotificationManager ) : BaseSkill<CheckPackageStatusInput, CheckPackageStatusOutput>() { override suspend fun execute(input: CheckPackageStatusInput): Result<CheckPackageStatusOutput> { // Step 1: Validate input if (input.trackingNumber.isBlank()) { return Result.failure(SkillException("Tracking number is required")) } // Step 2: Query logistics API (resilient with retry) val result = withTimeoutOrNull(30_000) { packageRepo.getStatus(input.trackingNumber) } ?: return Result.failure(SkillException("Network timeout")) // Step 3: Persist result and trigger notification val output = CheckPackageStatusOutput(result.status, result.lastUpdate) database.skillDao().insertOutput(skillId, output.toJson()) // This runs even if app is in background notificationManager.sendStatusNotification(output) return Result.success(output) } }这里的关键细节在于withTimeoutOrNull(30_000)。它不是简单的try-catch，而是利用 Kotlin 协程的结构化并发特性，确保即使网络请求卡死，整个 Skill 也不会无限期阻塞。30 秒后，协程自动取消，SLM 捕获到CancellationException，将 Skill 状态更新为FAILED，并记录错误原因。用户下次打开 App，看到的不是“转圈圈”，而是清晰的提示：“查询物流信息超时，请检查网络后重试”。
注意：Skill 的
execute()方法必须是suspend函数，且所有 I/O 操作（网络、数据库、文件）都必须使用协程挂起函数（如Retrofit的suspendAPI、Room的@Query注解方法）。这是 SLM 能够实现Resumable的前提——只有挂起函数才能被协程调度器在任意时刻暂停和恢复。
5. 面向碎片化的降级策略：没有“完美”的 Agent，只有“可用”的 Agent
Android 的碎片化，是所有移动开发者心中的痛。它不只是屏幕尺寸和分辨率的差异，更是 CPU 架构（ARMv7, ARM64, x86_64）、GPU 能力（Adreno, Mali, PowerVR）、系统版本（Android 11 到 15）、甚至厂商定制 ROM（MIUI, ColorOS, One UI）的千差万别。一个在 Pixel 8 Pro 上丝滑运行的 AI Agent，在一台三年前的 Redmi Note 10 上，可能连模型加载都失败。指望用户都升级旗舰机，是不现实的。
因此，“深度解析”的最后一环，是必须建立一套渐进式降级（Progressive Degradation）策略。它不是“要么全有，要么全无”的二元选择，而是一条从“最佳体验”到“基础功能”的平滑光谱。我们的策略分为四级，每级都有明确的触发条件和替代方案：
| 降级等级 | 触发条件 | 核心能力 | 替代方案 | 用户感知 |
|---|---|---|---|---|
| Level 0 (Full) | Android 14+, ARM64, RAM ≥ 6GB, PCC 可用 | Gemini Nano 全能力（文本、图像、语音）+ 混合推理引擎 | 无 | “智能得像真人” |
| Level 1 (Lite) | Android 13+, ARM64, RAM < 6GB 或 PCC 初始化失败 | 仅TextGenerationContract，禁用图像/语音 | 使用 APK 层的 15MB BERT 模型处理简单文本任务 | “响应快，但功能少一点” |
| Level 2 (Basic) | Android 12, ARM64 或 ARMv7, RAM ≥ 4GB | 仅TextGenerationContract的简化版（max_output_tokens=64,temperature=0.3） | 使用 TFLite 的 MobileBERT 模型（8MB），纯 CPU 推理 | “有点慢，但能用” |
| Level 3 (Fallback) | Android 11 或更低，或 ARMv7 且 RAM < 4GB | 完全禁用本地 AI，所有请求转发至公司私有云（HTTPS + JWT 认证） | 云端 Gemini Pro 微服务，带 500ms 延迟补偿动画 | “需要联网，但功能最全” |
这套策略的落地，依赖于一个轻量级的Device Capability Probe（DCP）模块。它在 App 启动时，用不到 200ms 的时间，完成一系列无害探测：
- 系统探测：
Build.VERSION.SDK_INT、Build.SUPPORTED_ABIS、ActivityManager.getMemoryClass()； - 硬件探测：
NeuralNetworks.isAvailable()（判断 NNAPI 是否可用）、GraphicsEnvironment.isVulkanAvailable()（判断 Vulkan 是否可用，影响 GPU 推理）； - 服务探测：
PrivateComputeClient.isAvailable()（同步调用，不初始化，仅检查服务是否存在）； - 存储探测：
context.getExternalFilesDir(null)?.usableSpace ?: 0L（确保有足够空间缓存模型）。
DCP 的结果被缓存到SharedPreferences中，并设置一个 24 小时的过期时间。这样，用户每次打开 App，都能获得一个精准匹配其设备能力的 AI 体验，而不是一个“一刀切”的、在低端机上卡顿、在高端机上浪费性能的妥协方案。
我们曾做过一个 AB 测试：A 组用户强制使用 Level 0（全功能），B 组用户启用 DCP 降级。结果令人惊讶：B 组的 7 日留存率高出 22%，用户平均单次使用时长高出 35%。数据说明，对于绝大多数用户而言，“稳定可用”比“炫酷强大”重要得多。一个在低端机上 3 秒就能给出答案的 Agent，远胜于一个在旗舰机上需要 8 秒、还可能因过热而被系统杀掉的“神级”Agent。
6. 实战复盘：从零搭建一个“会议纪要助手”Agent 的完整路径
理论终须落地。现在，让我们把前面五章的所有要点，揉进一个真实的项目：“会议纪要助手”。它的需求很简单：用户在会议中开启录音，结束后，Agent 自动将语音转为文字，并提炼出关键结论、待办事项和负责人，生成一份 Markdown 格式的纪要，保存到本地并推送通知。
6.1 架构选型与模块划分
我们摒弃了“一个 Activity 扛所有”的传统做法，采用清晰的分层架构：
- Presentation Layer（UI）：一个
MeetingRecorderActivity，包含录音控件、进度条、结果预览。它只负责展示，不持有任何 AI 逻辑。 - Orchestration Layer（编排）：
MeetingSummaryOrchestrator，一个单例对象，负责协调整个流程。它不直接调用模型，而是向 SLM 提交TranscribeAudioSkill和SummarizeTextSkill两个 Skill。 - Skill Layer（技能）：
TranscribeAudioSkill：负责音频转文字。在 Level 0/1，调用SpeechRecognitionContract；在 Level 2，使用 TFLite 的 Whisper Tiny 模型；在 Level 3，上传音频到云端 ASR 服务。SummarizeTextSkill：负责文本摘要。在 Level 0/1，调用TextGenerationContract；在 Level 2，使用 MobileBERT + 自定义摘要头；在 Level 3，调用云端 LLM API。
- Data Layer（数据）：
MeetingRepository，封装对 Room 数据库和FileProvider的访问，确保所有会议数据（原始音频、转录文本、摘要结果）都安全存储。
6.2 关键代码片段与避坑指南
Skill 提交与状态监听（UI 层）：
// 在 MeetingRecorderActivity 中 private fun startSummaryProcess(audioUri: Uri) { // 1. 创建 Skill 输入 val input = TranscribeAudioInput(audioUri = audioUri) // 2. 提交 Skill，获取唯一 ID val skillId = skillManager.submitSkill( TranscribeAudioSkill::class.java, input ) // 3. 观察状态变化 skillManager.observeSkillState(skillId).observe(this) { state -> when (state.status) { SkillStatus.RUNNING -> showLoading() SkillStatus.SUCCESS -> { // 成功后，自动提交下一个 Skill val transcript = state.output?.getTranscript() submitSummarizeSkill(transcript) } SkillStatus.FAILED -> showError(state.error?.message ?: "Unknown error") } } }避坑指南 #1：永远不要在
observeSkillState()的回调里直接调用submitSkill()。这会导致竞态条件。正确做法是：在SUCCESS状态下，先removeObservers()，再submitSummarizeSkill()，并在新 Skill 的observe中重新注册。否则，当第一个 Skill 失败时，第二个 Skill 可能已经提交，造成状态混乱。
TranscribeAudioSkill 的 Level 2 实现（APK 层 TFLite）：
override suspend fun execute(input: TranscribeAudioInput): Result<TranscribeAudioOutput> { return try { // 1. 使用 FFmpegKit 解码音频为 PCM val pcmBytes = ffmpegKit.decodeToPcm(input.audioUri) // 2. 使用 TFLite Interpreter 进行推理 // 注意：Whisper Tiny 模型的输入是梅尔频谱图，不是原始 PCM val melSpectrogram = AudioProcessor.computeMelSpectrogram(pcmBytes) interpreter.run(melSpectrogram, outputBuffer) // 3. 解码输出的 token IDs 为文本 val text = Tokenizer.decode(outputBuffer) Result.success(TranscribeAudioOutput(text)) } catch (e: Exception) { Result.failure(SkillException("Transcription failed: ${e.message}")) } }避坑指南 #2：
AudioProcessor.computeMelSpectrogram()是一个 CPU 密集型操作。在低端机上，它可能耗时 5-8 秒。必须将其包裹在withContext(Dispatchers.Default)中，确保不阻塞主线程。我们曾因忘记这一点，导致录音界面在转录时完全卡死，用户误以为 App 崩溃。
降级决策的优雅实现（DCP 模块）：
fun getTranscribeCapability(): TranscribeCapability> { val sdk = Build.VERSION.SDK_INT val memory = activityManager.memoryClass val pccAvailable = PrivateComputeClient.isAvailable(context) return when { sdk >= 34 && memory >= 6144 && pccAvailable -> TranscribeCapability.PCC_FULL sdk >= 33 && memory >= 4096 -> TranscribeCapability.PCC_TEXT_ONLY sdk >= 30 && memory >= 4096 -> TranscribeCapability.TFLITE_WHISPER_TINY else -> TranscribeCapability.CLOUD_ASR } }这个函数的返回值，直接决定了TranscribeAudioSkill的具体实现类。我们使用 Kotlin 的sealed class来定义TranscribeCapability，并在SkillManager的工厂方法中，根据 capability 创建对应的 Skill 实例。这种基于能力的工厂模式，让降级逻辑完全透明，UI 层无需关心底层是哪种技术在工作。
6.3 性能与体验的终极打磨
最后一步，是那些让产品从“能用”到“爱用”的细节：
- 冷启动优化：将
TranscribeAudioSkill的 TFLite 模型（12MB）和SummarizeTextSkill的 MobileBERT 模型（8MB）打包进 APK 的assets目录，并在 App 首次启动时，用WorkManager后台解压到context.getFilesDir()。这样，用户第一次使用时，无需等待漫长的模型下载。 - 热身（Warm-up）：在用户进入会议录音界面的 5 秒后，如果检测到设备处于 Level 0/1，就预先调用一次
PrivateComputeClient.create()并缓存实例。实测将首次转录的延迟从 1.8 秒降至 0.3 秒。 - 用户体验补偿：在 Level 3（云端）模式下，当用户点击“生成纪要”按钮后，UI 立即显示一个带有进度动画的“正在思考…”占位符，并同时发起网络请求。动画的持续时间，根据历史平均延迟（我们统计为 1.2 秒）进行设定，让用户感觉“它一直在工作”，而不是“它卡住了”。
这个“会议纪要助手”项目，从立项到上线，历时 11 周。它没有使用任何花哨的前沿算法，所有的技术选型，都源于对 Android 平台特性的深刻理解和对真实用户场景的敬畏。它证明了一件事：在移动端做 AI，真正的深度，不在于模型有多深，而在于你对系统、对硬件、对人的理解有多深。
我在实际项目中发现，最有效的沟通方式，往往不是告诉别人“你应该怎么做”，而是展示“我曾经在哪里摔倒过，又是如何爬起来的”。希望这份解析，能成为你搭建自己 Android AI Agent 时，手中那份带着温度、沾着灰、却无比可靠的施工图纸。
