小米 MiClaw 與 FoneClaw 比較：現況查證、APK／GitHub 判讀與 Android 手機代理選擇
用目前可查證的 Xiaomi Agent 生態招募與發布文件，釐清 MiClaw 是否公開推出、是否有官方 APK 或 GitHub，並比較 Xiaomi 系統整合路線與 FoneClaw 受治理的 Android 手機代理路線。
- MiClaw 是 Xiaomi 以 MiMo 為基礎的系統級 AI Agent；目前可查證的公開資料顯示，它有消費者限量封閉測試與邀請制開發者生態招募，但這兩件事要分開判讀。
- 搜尋 MiClaw APK 或 MiClaw GitHub 時，應先核對 Xiaomi 官方開發者平台、發布指南、分發位置與簽署來源；目前引用資料支持的是 MiClaw 內部分發與開發者流程，不是公開消費者 APK。
- MiClaw 的優勢是 Xiaomi 系統、MiMo、HyperOS 與 Agent 生態整合；FoneClaw 的優勢是獨立 Android 路線、可設定模型、100+ built-in tools、可見任務狀態、核准、停止與權限復原。
- 買機或導入前，請用真實手機任務測試兩條路線：目前畫面追問、訊息或電話草稿、系統設定、權限缺失與失敗復原，比單純比較 AI 名稱更可靠。
先回答 MiClaw 是什麼，以及誰適合選哪條路線
如果你想知道小米 MiClaw 與 FoneClaw 比較的直接答案，可以先這樣判斷：MiClaw 是 Xiaomi 以 MiMo 為基礎、面向 HyperOS 與 Xiaomi 裝置生態的系統級 AI Agent；FoneClaw 則是我們打造的獨立 Android 手機代理路線，使用者可配置支援的模型，由模型理解與規劃，再由 FoneClaw 透過受治理的 Android 工具完成支援動作。
已深度使用 Xiaomi 手機、平板、智慧裝置與官方帳號服務的人，會更想追蹤 MiClaw，因為它的價值來自系統、模型、裝置與 Agent 生態整合。使用非小米 Android 手機、或希望用可設定模型搭配可見任務狀態、核准、停止與權限復原的人，則更適合先評估 FoneClaw 的 Android 手機代理流程。
MiClaw 目前的重點不是「網路上有沒有某個 APK 檔」，而是 Xiaomi 官方是否提供你的帳號、裝置與地區可用的入口。FoneClaw 的重點也不是宣稱能包辦所有 Android 操作，而是把已支援的手機動作、目前畫面脈絡、任務狀態、權限與復原做成使用者能檢查的流程。若你只想先釐清 MiClaw 的基礎定位與狀態，可以先看 小米 MiClaw 是什麼？先看懂手機 AI Agent、HyperOS AI 與安全邊界；本文則把 MiClaw 和 FoneClaw 放在同一張買方決策表裡比較。
查證 MiClaw 開放狀態、APK 與 GitHub 說法
MiClaw 是否已公開推出，要分成消費者測試與開發者生態兩條線。Xiaomi HyperOS Developer Platform 的 Agent 生態招募公告把 MiClaw 描述為基於 MiMo 的系統級 AI Agent，並說明 MiClaw 已啟動限量封閉測試。這能證明 Xiaomi 已公開描述產品方向與測試狀態，但不能直接推導成一般消費者已可自由下載、所有機型可用或特定地區全面開放。
同一份官方招募資訊也說明，開發者可以上傳 MCP、Skill 與 Agent，並採邀請制參與。這是開發者生態的證據，和消費者端產品可用性不同。開發者被邀請建立 Agent，不代表每位 Xiaomi 使用者都能立即安裝 MiClaw；消費者拿到封閉測試資格，也不代表具備發布第三方 Agent 的權限。
查 MiClaw APK 時，請用四步驗證。第一，看來源是否來自 Xiaomi 官方系統更新、官方開發者平台或明確的測試邀請。第二，看檔案是否只是第三方轉載、重包裝或名稱相似的 Android 安裝包。第三，確認該檔案是否能對應官方發布指南中的分發流程。第四，避免把「雲手機預覽」、「手機端除錯」或「開發者測試包」當成一般消費者版。
查 MiClaw GitHub 時也一樣。官方文件目前把 Agent 應用建立、Skill／MCP 上傳與 MiClaw 內部分發放在 Xiaomi 開發者平台脈絡裡；若你看到 GitHub 專案，應先核對維護者、授權、發布來源、是否被 Xiaomi 官方文件引用，以及是否只是範例或第三方實驗。Xiaomi Agent 應用發布指南明確描述 Agent 應用在開發者平台建立，並在 MiClaw 內分發；這比搜尋結果頁上的 APK 或 GitHub 名稱更適合作為判斷基準。
看懂 MiMo、MiClaw、Agent Skill 與 MCP 的分層
比較 MiClaw 和 FoneClaw 前，要先把 Xiaomi 這邊的幾個層次拆開。MiMo 是模型基礎，負責理解、推理與生成等能力。MiClaw 是系統級 AI Agent 入口，承接使用者任務、系統能力與可分發的 Agent 應用。Agent Skill 與 MCP 則是開發者把外部能力或特定任務接入 MiClaw 生態的方式。
這種分層的好處是深度整合。當模型、系統、裝置、帳號與開發者平台都在 Xiaomi 生態裡，理論上能把手機、系統應用、智慧裝置與第三方 Agent 串得更緊。但這也代表可用性、審核、發布、除錯與裝置條件都由 Xiaomi 生態決定。開發者文件中提到的 AI 生成版本與回滾，也說明 Agent 應用需要被管理、檢查與更新，而不是單純把一段提示詞丟給使用者。
MCP 在這裡不是「無限制控制手機」的同義詞。它更像一組可被 Agent 呼叫的工具或服務接口，仍需要身份、權限、資料處理與平台規則。Skill 則可封裝更具體的能力。當 Agent 應用串接 Skill 和 MCP 時，真正的品質取決於任務描述是否清楚、工具是否可靠、權限是否最小化、失敗是否能回復。
FoneClaw 的分工方式更直接面向 Android 手機任務：使用者選擇支援的模型做理解和規劃，FoneClaw 透過受治理的工具承接 Android 上的支援動作。這讓我們可以把模型輸出和手機執行分開檢查，並把目前畫面、核准、任務停止、重試與權限復原放進流程。若你還想把 MiClaw、OpenClaw 與 FoneClaw 三種路線一起比較，可以延伸閱讀 MiClaw vs OpenClaw vs FoneClaw：三種手機 Agent 路線怎麼選。
用決策條件比較 MiClaw 與 FoneClaw
買方或團隊導入時，不應只問「哪個 AI 比較強」。手機代理真正影響日常使用的，是裝置範圍、模型選擇、任務狀態、可見結果、權限復原、擴充路線與取得方式。下面這張表用目前可查證的官方資訊與 FoneClaw 目前公開產品能力整理。
| 決策條件 | Xiaomi MiClaw 路線 | FoneClaw 路線 |
|---|---|---|
| 產品定位 | 以 MiMo 為基礎、整合 Xiaomi 系統與 Agent 生態的系統級 AI Agent | FoneClaw 是 Android 手機代理執行環境，承接支援的手機動作 |
| 裝置與入口 | 依 Xiaomi 測試資格、系統版本、裝置與地區入口決定 | 依 FoneClaw 支援的 Android 環境與官方安裝資訊使用 |
| 模型選擇 | 由 Xiaomi MiMo 與平台路線承接 | 使用者可配置支援模型，模型負責理解、推理與規劃 |
| 手機動作 | 透過 Xiaomi 系統整合與 MiClaw 內分發能力執行 | 透過 100+ built-in tools 與支援的 Android 工作流執行 |
| 權限與核准 | 依 Xiaomi 平台規則、Agent 發布、服務與裝置權限治理 | 以工具政策、可見核准、任務停止、重試與權限復原管理 |
| 目前畫面任務 | 看 Xiaomi 系統入口、Agent 能力與裝置支援 | 支援使用者選定的目前畫面脈絡，協助跨 App 規劃與可見結果 |
| 開發者擴充 | 透過邀請制開發者平台上傳 Agent、Skill 與 MCP | 透過 FoneClaw 的工具、Skills、Workflows 與 Plugins 分層擴充 |
| 適合使用者 | 已投入 Xiaomi 生態、重視系統整合與官方分發的人 | 使用 Android 並重視模型彈性、任務可見性與復原流程的人 |
FoneClaw 的產品設計經驗讓我們很清楚：手機代理不是模型回答得漂亮就夠了。它還要知道目前畫面在哪裡、哪個工具能做事、哪一步需要核准、失敗後能否回復。讀者若想看更聚焦於「非小米手機如何選替代路線」的角度，可以閱讀 MiClaw 最佳替代方案：FoneClaw 給 Android 使用者的手機 Agent 路線。在本文裡，我們把 FoneClaw 放在獨立 Android 手機代理路線上比較，而不是把它寫成 Xiaomi 生態的一部分。
用真實手機任務測試兩條 Android 手機代理路線
最可靠的比較，是拿同一組低風險任務測試。第一個任務是目前畫面追問：打開一個設定頁、郵件或網頁，請代理說明目前畫面可以做什麼，並要求它只準備下一步，不直接改變資料。MiClaw 路線要觀察系統入口是否能讀到正確情境；FoneClaw 路線要觀察目前畫面脈絡、任務狀態與後續動作是否清楚。
第二個任務是通訊草稿：請代理準備一段訊息或郵件回覆，要求送出前顯示收件人與內容。這能測出模型理解、聯絡人解析、App 狀態、權限與核准流程。FoneClaw 在支援的通訊流程中，會把草稿、結果和使用者確認放在可檢查位置；MiClaw 則要看當前測試資格、系統應用整合與 Agent 能力是否能承接同樣流程。
第三個任務是裝置設定：例如查看音量、勿擾模式、亮度或電池狀態，然後只調整一個可逆設定。這類任務適合測試「建議」和「執行」是否分開。成功的手機代理應該先說明將改變什麼，再執行，最後回報結果。它也應該能在權限不足、頁面不在前景或裝置狀態不符合時，提供可操作的復原步驟。
第四個任務是失敗復原：故意關閉某項權限、切到錯誤頁面或取消一次核准，看代理如何處理。FoneClaw 的路線會把權限復原、停止、重試與可見結果納入任務流程；MiClaw 路線則要觀察 Xiaomi 系統是否把 Agent 狀態、授權與失敗原因顯示清楚。這四個測試比單純搜尋 MiClaw APK 或比較截圖更能反映日常可用性。
開發者如何選擴充與發布路線
開發者選 MiClaw，重點是進入 Xiaomi 管理的 Agent 生態。依官方招募與發布指南，開發者可以在平台中建立 Agent 應用，串接已上傳的 Skill 與 MCP，使用開發和檢查工具，完成後在 MiClaw 內分發。這條路線適合想服務 Xiaomi 生態、需要系統級入口、願意配合邀請制和審核流程的團隊。
開發者選 FoneClaw，重點是 Android 手機任務能力的分層。FoneClaw 將工具、Skills、Workflows、Plugins 和核准流程分開管理，讓支援能力可以在使用者可見的權限與任務狀態中運作。能力被匹配到任務，不等於已經自動執行；使用者仍能透過工具政策、核准、停止與復原控制任務。若要深入理解 FoneClaw 的能力層，可以看 FoneClaw 工具、外掛、技能與工作流程指南：Android Agent 能力層怎麼選。
兩條開發路線都需要安全與分發思維。MiClaw 開發者要準備平台審核、依賴、服務與授權資料；FoneClaw 開發或部署時，則要明確區分內建工具、工作流、技能與外掛，不把擴充能力當成繞過 Android 權限的方式。好的手機代理擴充，應該讓使用者知道它會讀什麼、做什麼、何時需要確認，以及失敗後如何回到可控狀態。
最後用裝置、生態與任務做選擇
如果你使用符合條件的 Xiaomi 裝置、重視 HyperOS 深度整合、希望跟著官方 Agent 生態走，MiClaw 是值得追蹤的路線。判斷時請看官方測試資格、裝置端入口、開發者平台文件、Agent 內部分發方式，以及 Xiaomi 對 APK、Skill、MCP 與權限的正式說明。
如果你使用非小米 Android 手機，或你更看重可設定模型、支援 Android 動作、目前畫面脈絡、可見任務狀態、核准、停止與權限復原，FoneClaw 是更直接的評估入口。你可以先查看 FoneClaw 功能頁確認支援能力，再到 FoneClaw 下載頁取得目前可用安裝資訊，並用低風險任務測試。
最終選擇可以用一句話收斂：要 Xiaomi 生態內的系統級整合，就追蹤 MiClaw 的官方資格與分發；要在支援 Android 環境中用可設定模型完成可檢查任務，就測 FoneClaw。兩者的價值都應由真實手機工作、權限透明度、復原能力與官方來源來驗證。