OS Agent 基礎架構：手機 AI Agent 需要的三層能力

手機 OS Agent 的三層基礎

OS Agent 基礎架構的重點，不是把一個聊天機器人放進手機，也不是把手機變成完全自動駕駛。實用的手機 AI Agent 至少需要三層：第一層是 agent model 或 agent runtime，用來理解意圖、拆解任務、保留上下文；第二層是具權限邊界的 App 與裝置介面，讓 Agent 能在允許範圍內讀取狀態、準備操作或呼叫功能；第三層是使用者看得見的信任介面，用來批准敏感行動、查看狀態、取消任務、回顧紀錄。

只靠大型語言模型，手機 Agent 會停在「回答問題」；只靠自動化腳本，又會缺少理解與判斷。真正的手機 AI Agent 必須把模型的推理能力、Android 的權限與 App 狀態，以及人的確認流程放在同一個架構裡。這也是為什麼 手機代理型 AI 和一般助理不同：它不只是說明怎麼做，而是要在手機上協助完成支援範圍內的操作。

FoneClaw 應該被誠實定位為 Android 手機 AI Agent，用於支援的手機操作。它不應被描述成 OS、Android 替代品、萬能控制層，或能繞過 Android 權限的工具。好的手機 Agent 感覺像可靠的控制介面：它能理解你想做什麼，也知道哪些動作必須停下來請你確認。

判斷一個手機 Agent 是否真的成熟，可以先問三個問題：它是否能把自然語言轉成具體任務？它是否知道哪些 App 或系統功能可被安全呼叫？它是否讓使用者在敏感步驟前看見狀態並做出選擇？如果答案只停在「模型很會回答」，那還不是完整的 OS Agent 基礎架構。

第一層：把自然語言變成可執行計畫

第一層是模型與 runtime。使用者說「幫我整理早上的通知，挑出要回的訊息」，模型不能只寫一段摘要；它要判斷通知來源、重要程度、是否牽涉工作或私人訊息，並把任務拆成步驟：讀取通知、分類、產生候選回覆、等待使用者檢查。使用者說「看一下我今天有沒有會議衝突」，模型也不該直接改行事曆，而是先理解時間、帳戶、會議來源和可能衝突。

這一層把自然語言轉成任務計畫，負責意圖、上下文、優先順序與風險判斷。它可以決定哪些步驟只是資訊整理，哪些步驟會碰到敏感資料，哪些步驟需要 human approval。舉例來說，準備一封訊息草稿可以先由 Agent 產生，但送出前必須確認收件人、內容與使用的 App；檢查手機狀態可以讀取系統資訊，但調整設定前應清楚告知影響。

模型層也要知道「不做」何時比「自動做」更合理。如果使用者說「把這封信寄給主管」，但目前有兩個相同姓名的聯絡人、附件來源不明，或訊息內容可能外洩敏感資料，Agent 應該停止並要求澄清。這種停頓不是能力不足，而是把風險放回使用者可判斷的位置。

模型層的限制也要明講。它可能誤解指令，可能被惡意內容引導，也可能在上下文不足時做出錯誤推斷。因此，agent runtime 不能只追求流暢，還要有 guardrails：敏感動作分級、資料最小化、危險指令拒絕、狀態不明時停止，以及讓使用者確認。手機 AI Agent 的價值不是自動做最多，而是在需要自動化時仍保留清楚邊界。

第二層：App 與裝置要有可被呼叫的安全介面

第二層是執行介面。模型知道計畫後，仍需要可靠方式和 App、系統設定、通知、檔案或裝置功能互動。最脆弱的做法是靠畫面猜測：看見一個按鈕就推斷可以點、看見一段文字就推斷可操作。這種方式容易被 UI 改版、語言差異、彈窗、廣告、登入狀態或廠商客製影響。更穩定的方向，是讓 App 提供明確可呼叫的動作介面，讓 Agent 知道哪些操作存在、需要哪些參數、會造成什麼結果。

Android 權限與無障礙服務提醒我們，手機行動本來就不是任意開放的。讀取位置、通知、聯絡人、相機、檔案或輔助操作，都應該由平台權限與使用者啟用狀態來限制。Android App Functions 與 Apple App Intents 類型的模式，則展示了另一個方向：App 可以把某些功能變得更結構化、更適合被系統或 Agent 呼叫。這是可被機器呼叫的 App 核心思路，也可延伸閱讀 可被機器呼叫的 App 如何讓 Agent 不必只靠猜畫面操作。

這一層的實務標準，是讓 Agent 能清楚區分「可查詢」「可草擬」「可執行」與「不能做」。例如，讀取一則通知摘要和刪除一封郵件不是同一種風險；開啟地圖搜尋路線和直接替使用者分享即時位置，也不是同一種權限需求。好的介面會把動作類型、必要參數、可能影響與回復方式說清楚，讓模型不必用猜測填空。

但不能因此宣稱所有 App 都已經有乾淨的 agent API。現實是，不同 Android 版本、廠商介面、App 權限、登入狀態和地區功能，都會影響 Agent 能不能完成任務。permissioned automation 的正確態度，是先檢查支援範圍，再要求必要權限，最後才執行。若某個 App 沒有可靠介面，手機 Agent 應該說明限制，而不是假裝可以控制每個 App。

第三層：使用者必須看得見、能批准、能接管

第三層是信任介面。對使用者來說，Agent 最可怕的不是不能完成任務，而是不知道它正在做什麼。當 Agent 要讀取通知、點擊按鈕、準備傳送訊息、變更設定或使用敏感資料時，手機上應該有可見狀態：任務名稱、資料來源、即將執行的動作、需要的權限、等待批准的步驟，以及完成後的紀錄。這不是裝飾，而是手機 AI Agent 能否被信任的基本條件。

批准流程也要有層級。低風險行動，例如整理通知摘要或產生草稿，可以用較輕量的確認；高風險行動，例如送出訊息、刪除檔案、改變付款或安全設定，就應該要求更明確的 human approval。使用者還需要取消、暫停、修改與接管能力。若 Agent 執行失敗，紀錄應說明是權限不足、App 不支援、裝置鎖定、網路問題，還是使用者取消，而不是只顯示一個模糊錯誤。

回復期待也很重要。不是每個動作都能完整復原，所以 Agent 在執行前就要讓使用者知道風險。例如產生草稿可以直接丟棄，修改系統設定通常可以改回，發送訊息或刪除資料則可能難以回復。信任介面應該把這些差異說清楚，而不是把所有確認都做成同一個按鈕。

這也是 手機 Agent 狀態介面 這類構想重要的地方：Agent 的狀態要被放到使用者能看見的地方，而不是藏在背景。當手機開始承擔更多代理操作，信任不可能只靠「相信 AI」。它需要可見狀態、權限提示、明確確認，以及完成後可回顧的操作紀錄。

本地、雲端與混合執行要說清楚

OS Agent 基礎架構還需要回答一個實際問題：哪些步驟在本地做，哪些步驟需要雲端？本地 AI Agent 的優勢，是能減少支援任務中的重複資料移動，讓某些狀態判斷、簡單分類、權限檢查或即時提示更貼近裝置。on-device AI 也能在網路不穩時保留部分功能，讓手機更像一個可反應的控制點，而不是每件事都等遠端模型回覆。

但 local-first 不等於零雲端，也不等於零風險。大型語言推理、長文本整理、複雜規劃或跨資料來源分析，仍可能需要雲端模型協助。混合系統的重點，是清楚揭露資料何時留在手機、何時送出、送出哪些內容、為什麼需要送出，以及能不能讓使用者選擇。更完整的本地與雲端取捨，可參考 本地 AI Agent 的討論。

設計上，最容易出問題的是把「本地」當成一句保證。即使某個分類或狀態判斷在手機上完成，只要下一步需要雲端摘要、跨服務查詢或外部模型推理，資料邊界仍然需要重新說明。使用者不需要知道每個底層模型名稱，但需要知道敏感資料是否離開手機、是否會被最小化、是否能關閉某些雲端功能。

對 Android 使用者來說，最有價值的不是聽到絕對隱私承諾，而是看到清楚邊界。產品應該說明哪些支援操作可以在手機端完成，哪些任務需要外部推理，哪些資料會被最小化，哪些敏感動作必須回到使用者確認。local AI、hybrid AI 和 cloud AI 都可以成為 OS Agent 基礎的一部分，但它們必須被放進透明的權限與信任流程裡。

這對 FoneClaw 與 Android 使用者代表什麼

對 FoneClaw 來說，這三層架構提供的是產品邊界，不是行銷口號。FoneClaw 可以被理解為 Android 手機 AI Agent，協助使用者在支援的手機操作中完成任務：理解意圖、形成計畫、檢查權限、準備動作、要求確認、保留狀態與紀錄。它幫使用者操作手機，但不取代 Android 安全模型、不替 App 開發者暴露未提供的介面，也不保證所有資料永遠只在本地。

這也說明為什麼手機應該成為 Agent 的控制入口。使用者不需要一個只會聊天的新奇助理，而需要一個可靠的操作層：知道哪些 App 可用，知道哪些權限未開，知道哪些動作高風險，知道何時應該停下來等人批准。若把手機視為 手機 AI Agent 控制中心，重點不是讓它變成萬能 OS，而是讓支援範圍內的代理行動可管理。

這個框架也能幫使用者評估產品承諾。如果一個手機 Agent 說自己能自動完成所有 App 任務，卻沒有說明權限、支援範圍、確認流程和操作紀錄，就應該提高警覺。相反地，一個成熟的產品會清楚說明能做什麼、不能做什麼、需要你批准什麼，以及失敗時怎麼回到安全狀態。

2026 年的手機 AI Agent 競爭，不會只看模型回答得多漂亮。真正能留下來的產品，需要同時處理三件事：模型是否能把自然語言轉成安全任務，App 與裝置是否有具權限邊界的執行介面，使用者是否能看見、批准、取消和回顧。FoneClaw 若要建立長期信任，就應該把這三層做清楚，而不是把自己包裝成能控制一切的 AI agent OS。

參考資料：本文參考 Android Developers 權限文件 與 Android Developers 無障礙服務文件 來說明平台介面與使用者啟用邊界；參考 Apple Developer Documentation 的 App Intents 與 Android App Functions 方向，說明 App 逐步變得更適合被結構化呼叫；並以 OWASP LLM Top 10 的 prompt injection、sensitive information disclosure、excessive agency 風險，以及 NIST AI RMF 的風險管理語言作為安全框架參考。這些來源用於界定風險與設計原則，不代表任何合規認證或產品保證。