PokeClaw 與 FoneClaw 比較：本機推論、端側手機代理與 Android 動作控制
從本機模型推論、資料路徑、手機動作迴圈、權限核准、硬體成本與可逆測試，完整比較 PokeClaw 與 FoneClaw 適合的 Android 手機代理場景。
- PokeClaw 與 FoneClaw 比較的核心不是誰一定更好，而是本機模型推論和受治理 Android 執行各自解決不同問題。
- PokeClaw 是開源、local-first 的 Android 原型，Local mode 讓模型在手機端執行；啟用雲端模型供應商時，資料路徑會跟著改變。
- FoneClaw 是獨立 Android phone-agent runtime，重點放在懸浮入口、目前畫面脈絡、任務連續性、核准、停止、權限復原與能力路由。
- 第一個測試應該選可逆任務：開啟 App、讀取可見狀態、準備不送出的草稿，並記錄權限、延遲、動作可見性、停止、驗證與復原。
先用適合度看 PokeClaw 與 FoneClaw 比較
PokeClaw 與 FoneClaw 比較的短答案是：如果你最在意開源、裝置端模型推論、可檢視原型和本機 AI 手機代理實驗，先看 PokeClaw；如果你更在意 Android 手機上的受治理執行、可見任務狀態、核准、停止、權限復原和較完整的動作路徑，先看 FoneClaw。這不是一場單純功能數量比賽，而是兩種「local」的差別。
第一種 local，是模型推論發生在手機端。根據 PokeClaw 官方 GitHub 專案與 PokeClaw 官方網站，PokeClaw 是 open-source、local-first 的 Android prototype，Local mode 會在手機上透過 LiteRT-LM 執行 Gemma 4。這條路線適合想研究模型在裝置上如何看畫面、推理和選工具的開發者。
第二種 local，是動作執行與使用者控制常駐在手機上。FoneClaw 是獨立 Android phone-agent runtime，我們做它時更關注一件事：模型理解只是開始，真正難的是把手機動作放進可核准、可停止、可驗證、可復原的流程。若你想先理解本地控制與雲端安全的取捨，可延伸讀 AI Agent 信任指南：本地手機控制與雲端安全怎麼取捨，本文則聚焦 PokeClaw 與 FoneClaw 的產品選擇。
比較模型與資料路徑：本機推論不等於所有動作都離線
討論 PokeClaw 能不能完全在手機端執行，要先把模型路徑和功能路徑拆開。PokeClaw 的 Local mode 是它最鮮明的定位：模型在手機上執行，設定完成後不需要帳號或 API key 才能使用本機模式。對重視實驗透明度、資料最小外送和開發者可控性的讀者來說，這是 PokeClaw 的主要吸引力。
但 local-first 不代表每一種設定、每一個功能、每一次操作都一定完全離線。PokeClaw 官方資料也列出 optional cloud providers；一旦使用者啟用雲端模型供應商，資料路徑就會依供應商、設定和請求內容改變。比較時不要只看「local」這個字，而要問：目前模式是哪一種？模型在哪裡跑？畫面或文字是否送出？是否需要外部帳戶？失敗時是否能退回本機模式？
FoneClaw 的邊界不同。我們不把 FoneClaw 描述成所有推論都在裝置端完成；我們把它定位為 Android 上的受治理執行 runtime。也就是說，讀者應該把 FoneClaw 評估在手機動作層：它如何取得使用者觸發的目前畫面脈絡、如何提出下一步、如何要求核准、如何停止任務、如何在權限不足時復原，以及如何把支援能力路由到合適的工具或外掛。
| 比較面向 | PokeClaw | FoneClaw | 你該驗證什麼 |
|---|---|---|---|
| 核心定位 | 開源 local-first Android 原型 | 獨立 Android phone-agent runtime | 你要研究本機模型，還是要跑受治理手機動作 |
| 模型路徑 | Local mode 在手機端透過 LiteRT-LM 執行 Gemma 4 | 公開能力重點放在 Android 執行與控制，不宣稱全推論離線 | 模型在哪裡跑、哪些資料會離開手機 |
| 雲端選項 | 可選雲端模型供應商，資料路徑會改變 | 依產品設定與相容模型形成任務路徑 | 每個模式是否有清楚說明與使用者選擇 |
| 適合問題 | 本機推論、開源檢視、原型實驗 | 手機端動作、核准控制、復原與能力路由 | 不要用同一把尺量兩種不同目標 |
如果你的重點是端側大模型效能、啟動延遲、記憶體與加速硬體，建議搭配 端側大模型最佳化如何改變手機 AI Agent：速度、本地推理與 FoneClaw 工作流 一起看，因為模型能否在手機上跑得順，會直接影響實驗體感。
比較端側手機代理如何看畫面與採取動作
端側手機代理的核心迴圈可以簡化成四步：觀察目前狀態、理解使用者目標、選擇可用動作、檢查結果。PokeClaw 官方專案描述的做法，是讀取目前 UI 的文字表示，再由代理選擇工具。官方列出的工具包含 touch、text、open app、screen reading、screenshots、messaging、auto-reply 和 finish 等能力。這讓 PokeClaw 很適合觀察一個本機模型如何在 Android 畫面上做決策。
這種 accessibility-tree 工具迴圈有研究價值，也有現實邊界。Android App 的 UI 結構、可讀文字、按鈕標籤、權限彈窗和動態內容都可能影響結果。某個 App 在一次測試中可操作，不代表每個 App、每種語言、每個版本都能穩定執行。PokeClaw 官方也把公開 build 稱為 prototype，讀者應該用原型心態測試，而不是把它當成已覆蓋所有日常任務的消費級助理。
FoneClaw 的動作迴圈從另一個角度設計。我們把使用者觸發的目前畫面附加放在入口層，讓讀者在看到某個 App 或頁面時，主動把當前脈絡交給任務。接著 FoneClaw 透過任務連續性、能力路由和受控工具執行，把「看見畫面」連到「可以做什麼」。截至本文更新時可取得的最新產品資訊，FoneClaw 支援 100+ built-in tools，涵蓋多種受支援的 Android 動作類型；最新能力範圍可查看 FoneClaw 功能頁。
我們在建構 FoneClaw 時，刻意避免把「能點螢幕」當成唯一答案。手機代理需要知道什麼時候開啟 App、什麼時候讀取畫面、什麼時候改用系統工具、什麼時候要求使用者核准，還要在結果不明確時做狀態檢查。若你想深入理解懸浮入口與目前畫面脈絡，可以讀 Android 懸浮 AI 助手與目前畫面：提問、核准、執行與復原指南，那篇文章會把 FoneClaw 的使用者觸發路徑拆得更細。
| 動作與控制面向 | PokeClaw | FoneClaw |
|---|---|---|
| 觀察方式 | 讀取目前 UI 的文字表示，並可使用截圖等工具 | 由使用者觸發目前畫面附加，並把畫面脈絡放入任務流程 |
| 動作方式 | 透過工具選擇觸控、輸入、開啟 App、訊息與 auto-reply 等行為 | 透過能力路由呼叫支援的 Android 工具、外掛、技能與工作流程 |
| 可靠性重點 | UI 可讀性、工具選擇、模型推理與原型限制 | 權限、核准、狀態檢查、停止、復原與任務連續性 |
| 不要假設 | 不要假設它能控制所有 App | 不要假設它支援任意 GUI 點擊或所有外部 App 流程 |
比較權限、核准、停止與復原
哪個手機代理的動作控制較完整，不能只看它能不能成功點到按鈕。真正要看的是：它要求哪些權限、哪些動作會先停下來讓使用者確認、執行中能不能停止、失敗後能不能復原、結果能不能被驗證。手機代理碰到訊息、通知、聯絡人、系統設定與跨 App 任務時，這些控制比「自動完成」更重要。
PokeClaw 需要 Accessibility 來讀取畫面並執行手勢，官方文件也討論 rules、guards、stuck detection 和 clean failures 等方向。這些設計讓開發者能看到原型如何避免卡住或失控。不過，open source 本身不等於安全保證；Accessibility 權限也不等於使用者已理解每個後續動作。測試 PokeClaw 時，尤其要檢查 auto-reply、messaging 和 app navigation 這類可能影響他人的場景。
FoneClaw 的控制設計來自我們持續處理 Android 任務執行時遇到的實際問題。使用者希望助理幫忙，但不希望助理在高影響動作上跳過確認；使用者希望任務能繼續，但也需要隨時停止；權限不足時，產品不能只回報失敗，還要把人帶回可恢復的路徑。FoneClaw 目前把 approvals、stopping、state checks、permission recovery、capability routing 和 plugin activation review 放在受治理執行裡，讓任務不只追求完成，也追求可控。
這也是我們比較 PokeClaw 與 FoneClaw 時最看重的分界：本機推論保護的是模型資料路徑的一部分；受治理執行保護的是手機動作造成的結果。兩者可以同時重要，但不能互相替代。若你正在找 PocketClaw 替代方案，請不要只問哪個更會自動化，而要問哪個更容易讓你看見提案、確認風險、停止動作、回復權限並驗證最後狀態。
比較 PokeClaw Android 代理的安裝與硬體成本
PokeClaw 對硬體有何要求，是評估本機 AI 手機代理時一定要面對的問題。PokeClaw 官方網站列出 direct APK、Android 9+ arm64，並說明 Local setup 首次會下載約 2.6 GB，且需要約 4 GB free RAM。官方展示也提到 CPU warmup 可能約 45 秒，而支援加速的硬體可以更快。這些資訊很實用，但不是保證：實際體驗仍會受 SoC、記憶體、散熱、背景程式、模型設定與 Android runtime 影響。
本機推論的成本通常集中在下載、儲存、記憶體、啟動延遲和耗電。對開發者來說，這是值得付出的成本，因為你能在手機上直接觀察模型與工具迴圈；對一般使用者來說，等待時間與裝置負擔可能會影響是否願意天天用。因此，PokeClaw 比較適合先在你願意實驗的 Android 裝置上跑，而不是直接拿主要手機承擔所有日常自動化。
FoneClaw 的安裝評估則應該問另一組問題：你的 Android 裝置是否支援目前需要的權限？懸浮入口是否順手？目前畫面附加是否符合你的任務？核准卡、停止和權限復原是否清楚？截至本文更新時可取得的最新下載資訊，請以 FoneClaw 下載頁為準。比起背一組靜態規格，我們更建議讀者用低風險任務在自己的手機上測體感。
把本機 AI 手機代理放回真實工作流
產品比較最容易失焦的地方，是把所有功能放進一張表後宣告勝負。PokeClaw 與 FoneClaw 的合理選擇，要回到你的工作流。PokeClaw 官方資料展示了 WhatsApp auto-reply 和 generic app navigation 等方向，也以 Apache 2.0 授權提供程式碼，並在專案中描述商標使用限制。這對想檢視程式、修改原型、研究本機模型行為的人很有價值。
FoneClaw 的工作流則更偏向已上手機的受治理任務。我們把 100+ built-in tools、工具核准、權限復原、狀態檢查、外掛與技能能力路由放在一起，是因為真實 Android 任務通常不只是一個按鈕。使用者可能先在目前畫面提出問題，再建立提醒、準備草稿、查詢行程、開啟設定或接續另一個 App；產品需要在每一步讓人看得懂、停得下來、回得去。
| 你的主要目標 | 較適合先測 | 原因 | 仍要檢查 |
|---|---|---|---|
| 研究手機端模型推論 | PokeClaw | Local mode、開源專案與可觀察原型更適合實驗 | 硬體負載、延遲、資料路徑與原型限制 |
| 測試訊息回覆或 App 導航原型 | PokeClaw | 官方文件涵蓋 messaging、auto-reply 與 app navigation 方向 | 是否會送出、是否可停止、是否適合你的 App |
| 在 Android 上跑可控的日常工具任務 | FoneClaw | 任務連續性、核准、狀態檢查與權限復原是產品核心 | 該任務是否在目前支援範圍內 |
| 比較工具、外掛、技能與工作流程 | FoneClaw | 能力路由適合把不同 Android 動作放進同一條受治理路徑 | 哪些能力需要使用者啟用或核准 |
如果你想深入 FoneClaw 的能力層，而不是只看本文的比較摘要，可以看 FoneClaw 工具、外掛、技能與工作流程指南：Android Agent 能力層怎麼選。我們會把工具、外掛、技能和工作流程分開，是因為讀者需要知道自己在授權哪一類能力，而不只是看到「AI 可以幫你做事」。
選擇後先跑一個可逆測試
應先測試哪一個？如果你想看 Gemma 4 經由 LiteRT-LM 在手機上如何推理、如何讀 UI、如何選工具，先測 PokeClaw。若你想看 Android 手機代理如何把目前畫面、工具、權限、核准、停止和復原串起來，先測 FoneClaw。兩者都不應從高風險任務開始。
建議用同一個可逆測試流程：
- 選一個低風險任務，例如開啟 App、讀取目前畫面、建立可取消提醒，或準備一則不送出的草稿。
- 記錄啟動方式、是否需要帳號或 API key、是否啟用本機或雲端模型路徑。
- 觀察權限要求是否具體，動作提案是否可見，送出或修改資料前是否停下來確認。
- 在執行中按停止，記錄是否立即停止、是否說清楚已完成與未完成狀態。
- 最後檢查手機上的實際結果，並撤回一個必要權限後重試，看產品如何復原。
第一輪不要測付款、刪除、正式送出訊息、修改帳戶或大量資料操作。一次成功只能代表那次條件下可行，不能代表長期可靠。真正有用的 PokeClaw 與 FoneClaw 比較，應該留下六項證據：權限、延遲、動作可見性、停止行為、最後狀態驗證和失敗復原。這些證據會比任何單句口號更能告訴你，哪一個端側手機代理適合你的手機、任務和風險承受度。