1000 TPS 大模型與手機 AI Agent：MiMo UltraSpeed 代表什麼

速度不是完整 Agent，但會改變等待感

1000 TPS 大模型與手機 AI Agent 的關係，不能簡化成模型越快，手機就越會自己做事。高速推理確實重要，因為手機任務很少只有一次回答。使用者可能先問路線，再要整理訊息，接著確認收件人，最後才送出或切到下一個 App。每一步都要理解、規劃、檢查與回應；如果模型慢，整個流程就像卡在門口。

但速度不是完整 Agent。1000 tokens/s 代表模型輸出與推理節奏可能大幅縮短等待時間，卻不代表它已經具備手機端權限、App 支援、可見確認或可靠回退。模型可以更快產生計畫，卻不能因此跳過使用者授權；模型可以更快判斷下一步，卻不能保證每個 Android App 都有可用入口。

對手機 AI Agent 來說，速度的真正價值在於縮短計畫和行動之間的空白。比如你要清理通知、整理明天行程、把地址開到地圖、草擬回覆訊息，模型如果能快速理解和調整，使用者就比較不會覺得自己在等一個遠端客服回答。它更像即時協助，而不是慢半拍的聊天工具。

我們在 FoneClaw 會把高速推理看成上游能力，而不是整個產品。模型越快，越能支援更密集的 plan-act-check 節奏；但真正落到手機上，仍然要有清楚的 Android 手機執行層。這也是本文的核心：速度會改變手機 Agent 的手感，但不會取代權限、支援動作和確認流程。

MiMo UltraSpeed 證明了什麼，又沒有證明什麼

截至 2026-07-15 查核，Xiaomi MiMo 官方頁面將 MiMo-V2.5-Pro-UltraSpeed 描述為 MiMo-V2.5-Pro 的 UltraSpeed 體驗模式，背後是 1T 旗艦模型。官方頁面主張其最高推理速度突破 1000 tokens/s，並列出文字輸入輸出、tool calling、streaming、cache 支援等能力。

同一頁也把 MiMo-V2.5-Pro-UltraSpeed 的輸出 TPS 放在約 500 到 1000 的範圍，並對比 MiMo-V2.5-Pro 約 50 到 100 的範圍。官方提到的推薦場景包括量化交易、即時風控、科學研究和即時程式輔助。這些資料說明一件事：高速推理已經不只是實驗室口號，而是模型產品開始主打的使用體驗。

不過，這仍然是小米官方說法，不是獨立第三方基準測試。它不能被延伸成所有大模型都能到 1000 TPS，也不能被延伸成每個手機 Agent 都會立刻具備同樣速度。更不能說 FoneClaw 使用 MiMo 或和 MiMo 有直接技術關係；本文不做這種宣稱。

這個訊號真正值得關注的地方，在於模型能力的競爭正在從單次答案品質，走向即時、多步驟、可連續修正的工作流。若你想看更大的模型能力選型，可以參考AI Agent 模型能力指南；這裡我們只處理一個窄問題：高速推理對手機 Agent 的長序任務有什麼實際影響。

延遲真正影響的是長序任務

單次聊天裡，延遲只是等幾秒或少等幾秒；長序任務裡，延遲會不斷疊加。手機 Agent 幫你處理一天的通知，可能要先分辨哪些重要、哪些可以忽略、哪些需要回覆、哪些需要轉成提醒。每一步慢一點，整個流程就會變得不值得用。

再看導航和行程。你收到一個會議地址，想知道什麼時候出門，是否要通知同事，是否要把路線貼到訊息裡。這不只是一個回答，而是多個小判斷：辨識地址、推估交通時間、理解你接下來的安排、準備訊息內容、等待確認。高速推理在這裡的價值，是讓每個小判斷像自然對話一樣接上，而不是讓使用者看著轉圈圈。

訊息情境也很明顯。手機 Agent 如果要幫你整理三個對話、找出需要回覆的人、草擬不同語氣的回覆、再逐一確認，慢速模型會讓流程斷裂。高速模型則能讓草擬、修正、重排優先順序的過程更流暢，使用者才會願意讓 Agent 參與更多日常步驟。

但速度改善的是節奏，不是判斷責任。即使模型能即時產生回覆，送出訊息前仍需要看收件人和內容；即使模型能快速整理通知，也不能自行決定所有通知後果；即使模型能迅速規劃路線，也要尊重使用者的位置權限和 App 可用性。長序任務需要速度，也需要停下來確認的能力。

快模型與慢模型的協作節奏

高速推理會讓一種設計思路更重要：快模型處理低風險、即時、反覆的小判斷，較深的推理模型處理複雜、昂貴或高風險決策。這不是某個 FoneClaw 內部架構宣告，而是一種常見的 Agent 設計方向。速度讓系統可以更常檢查狀態，而不是每次都等一個大模型完整思考。

在真實手機任務中，快模型可能負責判斷使用者意圖是否清楚、是否需要補問、目前畫面是否符合預期、下一步是否只是低風險轉換。較深模型則可能在任務含糊、資料衝突、內容敏感或需要長距離推理時介入。這樣的分工，能讓 Agent 在日常任務中保持反應速度，同時避免把所有判斷都交給最輕量的模型。

以即時對話為例，使用者可能一邊走路一邊說：幫我看一下晚餐地點，順便告訴 Alex 我可能晚到。快模型可以先解析意圖、識別地點與聯絡人需求；較深模型可以在路線、語氣、時間估算或衝突資訊出現時提供更慎重的推理。最後，手機端仍要呈現訊息內容與導航選項，讓使用者確認。

因此，1000 tokens/s 的意義不只是快，而是讓更多小型檢查成為可能。Agent 可以更頻繁地問自己：目前計畫還正確嗎？工具回傳結果是否一致？是否該停下來請使用者確認？這種快慢配合，比單純炫耀一次輸出速度更接近手機 Agent 的日常需求。

手機動作仍需要可靠的 Android 執行流程

模型推理再快，也只是把意圖和計畫推得更快。手機上的真實動作仍要面對權限、App 支援、畫面狀態、系統限制和使用者確認。這就是為什麼高速模型不能直接替代 Android 手機動作流程。理解使用者要做什麼是一回事，把它安全地落到手機上是另一回事。

例如模型可以快速知道你想把截圖裡的地址傳給朋友，但手機端仍要處理截圖內容是否可讀、聯絡人是否明確、訊息內容是否需要修改、使用者是否允許送出。模型可以快速規劃整理通知，但手機端仍要知道哪些通知可以讀、哪些涉及隱私、哪些動作需要跳回原 App。

我們在 FoneClaw 將這個差異視為產品邊界。高速模型可以讓上游理解更快、更流暢；我們的角色是把明確意圖轉成支援的 Android 手機動作，並在需要時顯示結果、要求確認、或在不支援時回退。這與手機作為 AI Agent 承載位置的更大趨勢有關，延伸背景可看AI 手機載體層，但本文不重寫那個框架。

手機 Agent 的可靠度，不只取決於模型每秒輸出多少 token，也取決於能否在正確地方停住。送出、分享、刪除、設定變更、權限授予，這些都不是速度可以單獨解決的問題。速度讓計畫更快出現，執行流程讓計畫變得可用、可控、可被信任。

我們在 FoneClaw 從高速推理學到什麼

我們在 FoneClaw 看待 MiMo V2.5 Pro UltraSpeed 這類訊號時，不會把它解讀成模型速度已經解決手機 Agent。相反地，我們會把它視為一個上游能力加速的明確訊號：未來的模型可能更適合即時、多步、可修正的 Agent 流程，而手機端產品必須準備好承接這種節奏。

這也已經進入 FoneClaw 的實際產品體驗優化。FoneClaw 已取得 MiMo V2.5 Pro UltraSpeed 的內測帳號，並正在使用這個小米官方稱最高突破 1000 TPS 的萬億參數大模型來優化 FoneClaw 的使用體驗。對手機 Agent 來說，價值不是抽象跑分，而是更快理解使用者意圖、更快修正步驟，並讓支援的手機動作回應更迅速。

對我們來說，速度帶來三個產品教訓。第一，等待時間會影響使用者是否願意讓 Agent 參與日常任務。第二，快速推理讓更多中途檢查變得可行，例如任務是否仍然正確、權限是否足夠、結果是否需要確認。第三，模型越快，越需要清楚的手機動作邊界，否則錯誤也會更快發生。

因此，我們的重點不是宣稱 FoneClaw 達到 1000 TPS，也不是宣稱使用 MiMo。FoneClaw 的產品位置是 Android 支援動作層：把使用者意圖轉成可見、可確認、可回退的手機步驟。更快的模型會讓上游推理更順，但我們仍要確保每個支援動作有合理權限、清楚結果和安全停止點。

最實用的結論是：1000 TPS 代表 AI Agent 的等待感可能被重新定義，但手機 Agent 的成功仍取決於速度之外的部分。對 Android 使用者來說，好的體驗不是模型一直快速輸出文字，而是它能在正確時候理解、在正確地方行動、在必要時停下來確認。我們在 FoneClaw 的路線，就是把這個速度趨勢接到可靠的手機動作體驗上。