AI Agent Token Cost 怎麼算：為什麼本地手機操作能降低隱藏成本

Token 成本不是只有聊天字數

很多團隊第一次估 AI Agent 成本時，只會拿模型單價乘上大概的輸入輸出字數。這樣算聊天機器人勉強可以，但算手機任務就太粗。當使用者說「幫我整理通知、找出重要訊息、準備回覆，先不要送出」，Agent 不只要理解一句話，還要讀取情境、判斷哪些通知相關、規劃步驟、呼叫工具、等待確認，最後還要回報結果。每一段都可能消耗 token，也可能因為狀態不清楚而重來。

公開的 OpenAI API pricing 和 Google Cloud Vertex AI pricing 都反映一個基本事實：生成式 AI 的雲端成本通常會受模型、模態、輸入量與輸出量影響。本文不引用或推算任何特定方案價格，因為價格會變，也會依供應商和模型而不同；更重要的是，手機 Agent 的總成本常常不是單次呼叫，而是任務完成前的整段往返。

我們在 FoneClaw 看待 AI agent token cost 時，會把它拆成兩層：一層是模型理解與規劃所花的 token，另一層是手機端能不能把支援動作穩定完成。如果後者不穩，前者就會一直膨脹。這也是為什麼 用一句話完成 Android 任務自動化：FoneClaw 多步驟手機操作指南 裡談到的支援動作很關鍵；任務越能被清楚拆解並在手機端可靠完成，就越不需要每一步都丟回雲端重新猜。

手機任務最容易燒 token 的地方

真正昂貴的 Agent 往往不是因為它回答很多，而是因為它失敗很多次。手機任務會產生幾種常見的 token 流失：把整段聊天歷史帶進下一輪、把工具說明重複塞進提示、把截圖或畫面描述轉成大量上下文、每次確認都重新解釋任務，以及使用者說「不是這個，重來」後，模型又把前面內容全部讀一遍。

以通知整理為例，若 Agent 每次都把所有通知、App 名稱、使用者偏好和完整對話一股腦送上雲端，成本會很快堆高。更糟的是，若它沒有辦法在手機端真正標記、開啟或準備回覆，最後仍要使用者手動處理，那些 token 只是把任務講得更詳細，卻沒有降低完成成本。手機 Agent 的成本問題，常常是「理解很多，完成很少」。

截圖也是容易被低估的項目。畫面理解對某些任務有用，但若每一步都依賴截圖分析，就會把原本可由明確動作完成的流程，變成高成本的視覺推理。確認也一樣：使用者需要確認敏感動作，但確認內容應該精準，不該每次都用長篇文字重新說明全部背景。好的設計會把必要資訊留給使用者，把可重用的狀態交給手機端記錄，而不是把所有歷史都塞回模型。

只靠雲端理解，常會把成本花在原地打轉

雲端 AI 很適合處理開放式理解、長文本摘要、複雜推理和跨資料來源分析，但手機操作不是只有理解問題。使用者要的是「幫我打開正確 App」、「把草稿準備好」、「把設定切到某個頁面」、「提醒我確認這則訊息」。若雲端 Agent 只能描述步驟，卻無法在裝置上完成支援動作，就會把 token 花在教使用者自己點。

這種成本有時不會出現在模型帳單裡，卻會出現在使用者時間裡。Agent 說了十行操作指引，使用者還是要自己切 App、找按鈕、回到聊天視窗、貼上結果，再請 Agent 判斷下一步。每一次來回都消耗上下文，也增加錯誤機會。若使用者截圖給 Agent 看，成本又往上加；若畫面和 Agent 預期不同，就再來一輪。

這不是說雲端 AI 不重要，而是雲端理解和手機端動作要分工。關於信任和雲端風險，我們在 AI Agent 信任指南：本地手機控制與雲端安全怎麼取捨 有更完整的討論。放到成本問題上，同一個原則仍成立：能在手機端明確完成的支援步驟，就不應該每次都變成雲端推理題；需要雲端智慧的部分，才值得花更高的模型成本。

本地手機操作能省下哪些重複推理

本地手機操作的省錢價值，不是「完全不用雲端」，也不是「所有任務都離線完成」。更務實的說法是：當某些 Android 動作已經被支援、權限已經取得、流程已經能被清楚驗證，就不必每次都讓模型重新理解畫面、猜下一步按鈕在哪裡。這能降低重複上下文、重複工具說明和失敗重試。

例如「開啟某個支援 App 的指定入口」和「草擬一則回覆但先不送出」是不同類型的任務。前者若能透過手機端明確完成，雲端只需要理解使用者意圖；後者可能需要語意生成，也可能需要使用者確認內容。把兩者混在同一個大型雲端推理流程裡，會讓簡單步驟也承擔高成本。把可確定的手機動作留在裝置附近，則能讓模型專注在真正需要判斷的部分。

Android 的 隱私與安全文件 也提醒我們，手機端操作仍必須尊重權限與使用者控制。換句話說，本地不等於無限制，省成本也不能靠繞過安全。對 FoneClaw 而言，local AI agent cost 的核心不是把所有資料都鎖在手機上這句口號，而是把支援動作、權限請求、結果回報和人工確認安排清楚，減少無效雲端往返。

FoneClaw 的成本觀：支援動作應該可預期

我們設計 FoneClaw 時，不希望每個手機動作都像一次全新的研究題。使用者說「幫我準備回覆」、「打開導航」、「整理通知」時，系統應該先判斷這是不是支援範圍內的任務，再用可預期的方式處理。可預期代表幾件事：需要哪些權限要講清楚，哪些步驟可以自動準備，哪些步驟必須停下來讓使用者確認，完成後要能看見結果。

這種設計也會影響 token 成本。若每次都由模型重新規劃所有細節，就會產生大量不必要的輸入輸出。若支援動作能被穩定封裝，模型只需要處理目標理解、例外判斷和必要說明。當任務失敗時，也不應該無限重試；系統應該回報失敗原因，請使用者補充資訊，或把控制權交回使用者。

企業或高敏感場景更需要這種成本與安全一起看的方式。不是所有省 token 的做法都值得採用，因為省掉確認可能帶來更高風險；也不是所有安全說明都要變成超長提示，因為過度冗長會讓使用者忽略重點。延伸到團隊治理，可以參考 企業 AI 代理安全：手機層級代理該如何在本地、權限與稽核之間落地。我們的原則是：支援動作要穩，敏感動作要停，紀錄要清楚，模型不該為同一個可確定步驟反覆花錢。

估算 Agent 總成本時該看什麼

要評估 phone agent token usage，不能只看模型價格表。第一，要估每個任務平均會走幾輪：一次完成和三次修正，成本差很多。第二，要看上下文長度：是否每次都帶入完整歷史、工具說明和畫面資料。第三，要看工具呼叫是否有效：如果工具不能真的改變手機狀態，模型就會用更多文字補救。

第四，要把使用者時間算進去。Agent 要求使用者截圖、貼上結果、手動切換 App，再回來確認，表面上是省了模型能力，實際上是把成本轉嫁給人。第五，要估支援與錯誤處理：若 Agent 常常做出不完整結果，客服、教學、退回重做都會變成產品成本。第六，要看敏感步驟是否有清楚確認；省掉確認看似快，出錯後的代價通常更高。

我們會建議用三個問題做最後檢查：這個步驟真的需要雲端模型判斷嗎？這個動作能不能在支援範圍內由手機端穩定完成？如果失敗，系統是否能用短而清楚的方式告訴使用者原因？當答案越明確，AI agent cloud cost 就越容易控制；當每一步都靠模型猜，成本就會被上下文、重試和人工補救慢慢吃掉。FoneClaw 的方向，是讓 Android agent local execution 承擔它能穩定承擔的部分，把昂貴的推理留給真正值得推理的地方。