端側大模型最佳化如何改變手機 AI Agent：速度、本地推理與 FoneClaw 工作流

為什麼手機 AI Agent 的品質先看體感速度

手機 AI Agent 的第一個考驗通常不是模型懂不懂，而是你等不等得下去。當你說「幫我回覆他 10 分鐘後到」或「打開地圖看下一段路線」時，理想體驗是手機很快理解你的意圖、開到正確 App、確認目前畫面，再把可執行的下一步呈現出來。如果這個過程卡住 5 秒、10 秒，或因為記憶體壓力被系統回收，使用者很快就會回到手動點按。

所以端側大模型最佳化 手機 AI Agent 的討論，要從體感延遲、電量、前景可用性和確認節奏開始，而不是只看每秒產生多少字。手機代理需要處理的不是長篇作文，而是短指令、畫面理解、意圖改寫、通知摘要、訊息草稿和下一步判斷。這些任務常常很短，但要求回應穩定。模型越能在本機快速完成初步理解，FoneClaw 就越能把支援的 Android 動作接到可見結果上，例如開啟對話、顯示提醒時間、準備草稿或等待使用者確認。

Android Developers 的 Gemini Nano 文件把 Gemini Nano 放在 Android AICore 裡，重點包含裝置端生成式 AI、較低推理延遲、注重隱私的使用情境，以及在支援情況下不依賴網路的體驗。這代表手機 AI Agent 可以把一部分理解與生成工作放在本機，讓常用動作更即時。對 FoneClaw 來說，本地 AI 推理的價值不是炫技，而是讓「說完就看到下一步」更接近一般手機操作的節奏。

延遲也不只來自模型本身。喚起模型、載入權重、讀取上下文、等待 App 畫面、檢查權限、確認收件人，都會讓使用者感覺變慢。好的手機代理體驗會把這些等待拆開：能在本機處理的先處理，需要使用者決定的就顯示清楚，需要網路或更大模型的再安排。若你想先理解手機代理能操作哪些 Android 層級，可以接著看 AI Agent 如何控制手機，這篇則專注在端側 LLM 為什麼會改變速度和穩定性。

模型大小、量化與小模型分工怎麼影響手機任務

模型越大通常越有推理能力，但手機不是資料中心。手機有有限的記憶體、電池、散熱空間和前景工作時間。端側大模型最佳化的實務目標，是把足夠好的模型放進能長時間使用的手機體驗裡，而不是把最大模型硬塞進每一次指令。對手機 AI Agent 來說，很多任務不需要大型推理：判斷「這是不是要開地圖」、把一句話改成簡短訊息、摘要幾則通知、辨認畫面上可點的下一步，通常適合小模型或本機模型先處理。

模型壓小有幾個常見方向。量化可以把模型數值用更省空間的方式表示，降低記憶體和運算成本；adapter 可以讓模型在特定任務上更貼近應用需求，而不必每次載入完整大型模型；小模型分工則是把簡單、頻繁、低風險的任務交給本機模型，把需要更深推理或更長背景的任務交給更強的模型。Apple 在 Apple Foundation Models 2025 技術更新中提到量化、adapter、KV cache 分享，以及本機與伺服器模型分工，這些方向都反映同一個現實：行動端 AI 要靠取捨與分工，而不是單一模型包辦一切。

把這個概念放回 FoneClaw 的 Android 工作流，就會很具體。當使用者說「幫我把這則訊息改得客氣一點」，本機模型可能足以產生草稿；當使用者要求「根據這 20 封郵件整理出週報並安排後續」，就可能需要更大的推理能力。FoneClaw 的產品範圍會把支援的手機動作做成看得見的步驟：先準備內容、顯示目標 App、呈現草稿或提醒，再由使用者確認。模型分工的結果不應該讓使用者感到流程破碎，而是讓每個步驟都更快進入可操作狀態。

也因為模型有大小和任務分工，離線體驗要看裝置、功能和模型是否可用。支援的本機能力越完整，常用手機任務就越能在網路不穩時繼續進行；需要雲端推理的任務，則可以在畫面上保留進度、等待網路或讓使用者選擇下一步。這就是行動端 LLM 最佳化和手機代理體驗的交會點：不是追求單一路徑，而是把每個任務放到合適的處理方式。

Android 上的 AICore、Gemini Nano、ML Kit 與 LiteRT-LM

對一般使用者來說，模型怎麼被呼叫不需要每天理解；但對手機 AI Agent 體驗來說，Android 提供哪些本機 AI 路徑非常關鍵。AICore、Gemini Nano、ML Kit GenAI、Google AI Edge、LiteRT 和 LiteRT-LM，都是讓行動端 AI 不只停留在展示影片裡的基礎。它們決定了 App 能不能檢查功能可用性、下載模型、初始化模型、管理配額、處理本地輸入，並在裝置條件允許時提供更快的回應。

Google ML Kit GenAI Prompt API 說明提到，開發者需要檢查支援裝置與功能可用性，必要時下載 Gemini Nano，並可使用 warmup 降低第一次呼叫的延遲；文件也描述 token 限制和每個 App 的配額。這些看起來像開發細節，實際上會直接影響使用者體驗。若模型尚未下載，第一次使用就可能需要等待；若配額或輸入長度受到限制，App 就要把任務切得更清楚；若可以事先 warmup，常用手機任務就更容易在使用者開口後快速回應。

Google AI Edge 文件把裝置端機器學習與 AI 放到跨平台工具脈絡中，包含 MediaPipe task APIs、LiteRT 與 LiteRT-LM。LiteRT-LM 概覽則把本機 LLM 的例子和效能面向講得更接近工程實作，例如 prefill、decode、time to first token、CPU/GPU 後端、記憶體與離線本地模型執行。這些能力讓手機不只是把所有請求送到雲端，也能在本機處理一部分語言與判斷工作。

FoneClaw 的角色是把這些底層能力轉成使用者感覺得到的 Android 動作。當手機支援本地 AI 推理，我們可以讓短指令、訊息草稿、通知摘要、畫面狀態判斷更快進入下一步；當某項功能需要雲端或 App 權限，我們會把它放在明確的可見流程裡。若你想看更大的作業系統與代理分層脈絡，可以閱讀 OS Agent 三層基礎；本文的重點，是這些本機 AI 路徑如何落在手機代理的速度、穩定性和確認流程上。

KV cache、prefill、decode 與 warmup 對重複工作流的影響

很多人談手機 LLM 速度時，只看模型每秒輸出多少 token；但手機 AI Agent 的體感速度常常卡在第一個回應。你說完一句話後，模型要先讀進提示、理解上下文、建立中間狀態，然後才開始輸出。prefill 可以理解為模型先處理輸入內容的階段，decode 則是逐步產生輸出的階段。time to first token 越短，使用者越快感覺手機有反應；decode 越穩，草稿、摘要和回覆越不容易中途卡住。

KV cache 則像是模型在處理上下文時留下的可重用狀態。對手機代理來說，許多工作流會重複出現：同一個對話裡連續修改訊息、同一個 App 裡反覆確認畫面、同一段通勤中多次查通知、同一個購物清單裡新增幾項物品。如果系統可以有效重用部分上下文狀態，使用者感覺到的速度就可能更接近「連續操作」，而不是每次都重新開始。

warmup 也是手機體驗中很重要的一環。模型第一次被呼叫時，可能需要載入和初始化；若 App 能在合適時機先準備好本機模型，使用者第一次真正下指令時就不會等太久。ML Kit GenAI 的文件提到 warmup 可以降低第一次呼叫延遲，LiteRT-LM 也把 prefill、decode、time to first token 和記憶體列為重要效能面向。這些細節會影響 FoneClaw 如何安排工作流：常用、短程、重複的 Android 動作最適合用本機能力加速；長上下文或需要更大推理的任務，則要有清楚的等待、摘要或後續確認。

上下文長度也會帶來取捨。越長的上下文能保留更多資訊，但也消耗更多記憶體和時間。手機代理不應該把所有歷史都塞進每次請求，而是要取出與當下任務相關的內容：目前畫面、使用者剛剛說的話、待確認的收件人、正在編輯的草稿、可見的按鈕或提醒時間。FoneClaw 會把這些上下文用在支援的手機動作上，讓系統更快進入下一步，也讓使用者在螢幕上看到它準備做什麼。

本地推理與雲端推理如何分工到 FoneClaw 動作

端側大模型最佳化不是要把所有 AI 都關在手機裡，也不是把所有任務都交給雲端。對手機 AI Agent 來說，更務實的做法是分工：本地推理負責快速、常見、需要即時回應的手機任務；雲端推理負責更長內容、更複雜推理、跨資料整合或大型生成。使用者不需要知道每次走哪條路，但應該感覺到流程清楚、回應穩定、結果可確認。

本地推理適合處理幾種情境。第一，短語音指令，例如「開啟行事曆」、「把這句話改短」、「幫我整理這三則通知」。第二，對隱私感較高但任務範圍清楚的內容，例如在本機產生訊息草稿或摘要目前可見文字。第三，網路不穩時仍能執行的手機側任務，例如離線準備提醒或整理待辦。Gemini Nano 透過 AICore 提供裝置端生成式 AI 能力，在支援情況下能帶來低延遲與不依賴網路的使用情境；Apple 的 Foundation Models framework 文件也顯示行動平台正在把本機語言模型、結構化輸出和 App 內工具呼叫放進開發者可用的方向。

雲端推理仍然有位置。當任務需要很長的上下文、複雜規劃、多來源資料或更高品質長文生成時，雲端模型可以提供更大的能力。FoneClaw 的做法是把這種分工轉成使用者看得懂的流程：能本機完成的先快速準備，需要雲端協助的就保持進度與結果可見，需要敏感動作的就保留確認。這不是把手機當成黑盒，而是把 AI 推理和 Android 動作串成清楚步驟。

因此，FoneClaw 支援的手機代理動作會優先落在可見結果上：開啟正確 App、檢查螢幕狀態、草擬訊息、設定提醒、整理通知、協助多步驟流程，並在送出、分享、刪除、付款或涉及個人資料時讓使用者確認。若你想比較本地與雲端在隱私、速度與可用性上的大方向，可以看 雲端與本地 AI Agent；本篇的重點，是混合分工如何讓手機代理更快走到可執行結果。

評估端側 LLM 手機功能的實用清單

當一支手機或 App 宣稱支援端側 LLM，不要只問模型名稱，也要問它能不能改善你的手機任務。對手機 AI Agent 來說，真正有感的地方是：能不能快速理解短指令、能不能在支援裝置上離線處理部分任務、第一次呼叫是否等待太久、長時間使用會不會耗電、遇到配額或模型不可用時有沒有清楚後續、需要確認的動作是否呈現在畫面上。

• 裝置支援：確認功能是否需要特定 Android 版本、晶片、記憶體或 Google Play services，並檢查 Gemini Nano、AICore 或相關模型是否可用。
• 首次回應：觀察第一次開啟功能時是否需要下載模型、初始化或 warmup；常用功能應該在準備完成後快速回應。
• 離線行為：測試網路不穩時，哪些任務仍能在本機完成，例如草擬、摘要、提醒或簡短分類。
• 配額與長度：留意 token 限制、每個 App 配額和輸入長度，因為這會影響長訊息、長通知或多步驟任務。
• 電量與溫度：本機推理會使用手機資源，好的功能應該把高頻小任務和重型推理分開安排。
• 畫面復原：App 跳轉、權限視窗、網路中斷或畫面變化時，手機代理應能回到可見狀態，而不是讓使用者猜它做到哪一步。
• 確認設計：訊息送出、共享、刪除、付款和資料變更等敏感步驟，應該讓使用者看到內容、對象與結果。

對 FoneClaw 而言，端側大模型最佳化的最終價值，是讓 Android 手機代理更接近自然操作：你說出需求，手機快速理解，FoneClaw 把支援的動作準備好，畫面顯示下一步，重要動作由你確認。模型大小、量化、KV cache、warmup、AICore、LiteRT-LM 都是達成這個體驗的技術路徑；使用者真正感受到的，是手機少卡一下、少重試一次、少點幾下，且每個結果都看得見。

如果你正在評估一個 on-device LLM 功能，最簡單的測試是拿真實手機任務來試：開 App、整理通知、改寫訊息、建立提醒、從目前畫面找下一步、在網路變差時繼續處理可支援動作。能在這些日常步驟裡穩定發揮，才是端側大模型最佳化 手機 AI Agent 最值得關注的方向。