Android AI Agent 安全圍欄是什麼？App Functions、權限閘門與 FoneClaw 執行邊界
「Android AI Agent 安全圍欄」是外界對 Google App Functions 與 Agent 權限邊界的形象說法，不是官方產品名稱。本文說明 AppFunctionManager、EXECUTE_APP_FUNCTIONS、應用功能啟用、使用者權限與 FoneClaw Android 執行模型。
- 「Android AI Agent 安全圍欄」是報導語境中的形象說法，不是 Android 官方命名的單一安全產品，也不是所有手機都看得到的一個使用者開關。
- Google 官方文件中的具體機制是 App Functions：應用程式暴露特定功能，AppFunctionManager 負責探索與執行，跨元件執行需要受限制權限與目標功能啟用。
- 平台權限閘門、App 功能啟用、一般 Android 權限與使用者可見核准是四層不同控制；任何一層都不能單獨取代其他層。
- FoneClaw 不把自己描述成 Google EXECUTE_APP_FUNCTIONS 持有者；我們採用自己的受治理 Android 工具與按需權限模型，讓支援動作、結果與確認保持可見。
Android AI Agent 安全圍欄其實在說什麼
「Android AI Agent 安全圍欄」不是 Google 官方命名的一個獨立安全產品，也不是每台 Android 手機上都會出現的一個可切換開關。這個詞更適合理解為外界對 Google 正在建立 Agent 執行邊界的形象說法：當 AI Agent 想在 Android 上替使用者完成工作時，系統不應讓它任意碰到所有 App、所有資料和所有動作。
真正可落地的官方機制，要看 Android 的 App Functions。依 Android appfunctions 套件文件，App Functions 讓應用程式以明確形式暴露可被呼叫的功能；依 AppFunctionManager 文件，系統提供探索與執行這些功能的入口。這比「AI 想做什麼就直接操作螢幕」更可控，因為每個可呼叫的功能都需要由應用程式提供並被系統識別。
這也代表安全重點不是一個籠子把所有 Agent 都關起來，而是多層閘門共同工作：應用程式要先公開特定功能，目標功能要處於可用狀態，呼叫端要具備合適權限，使用者仍要面對資料存取、一般 Android 權限與高影響動作確認。Google 在Android Developers Blog 對 intelligent OS 與 AI agents 的說明中，也把 Agent 能力放在系統、App 和使用者控制逐步協作的脈絡裡。
因此，本文會把「安全圍欄」當成新聞語境中的比喻，真正討論的是 Android 上可驗證的 App Functions、受限制權限、App 功能啟用，以及使用者仍然需要的權限與核准。這樣理解，才不會誤以為所有 Android Agent 都已被同一個可見控制面板管理，也不會誤以為任何 AI App 都能申請一個權限後執行所有跨 App 動作。
App Functions 如何讓 Agent 呼叫應用功能
App Functions 的核心，是把「應用程式可以被外部呼叫的能力」變成更明確的系統介面。應用程式不是把整個 App 開放給 Agent，而是暴露具體功能；系統再透過 AppFunctionManager 讓合適的呼叫端探索與執行。這個模型讓 Android Agent 的跨元件工作更接近「呼叫已宣告、已啟用、受權限約束的功能」，而不是任意模擬使用者點擊。
權限部分尤其重要。依 Android 官方 API 文件，跨元件執行 App Functions 需要 EXECUTE_APP_FUNCTIONS 或 SYSTEM 權限，且目標功能必須啟用。EXECUTE_APP_FUNCTIONS 是受限制的權限，不是一般第三方 App 可以隨意要求、取得後就橫掃所有 App 功能的通行證。這點是本次修正最重要的事實邊界：App Functions 提供的是受控框架，不是泛用跨 App 自動化授權。
也要分清 App Functions 和其他執行路線。Android 上仍有使用者介面操作、Accessibility、ADB、App 內 API、分享表單、通知動作等不同路徑。App Functions 是 Google 正在推動的系統框架之一，不等於所有手機 Agent 都會經過同一個閘門，也不等於 UI／Accessibility／ADB 類操作都被這個框架取代。當你評估一個 Agent 產品時，必須問清楚它到底走哪條執行路徑。
| 層級 | 它控制什麼 | 容易誤解的地方 |
|---|---|---|
| App Functions | App 明確暴露哪些可被呼叫的功能 | 不是把整個 App 都交給 Agent 操作 |
| AppFunctionManager | 探索與執行已暴露、可用的 App 功能 | 不是任意跨 App 自動化引擎 |
| EXECUTE_APP_FUNCTIONS／SYSTEM | 跨元件執行 App Functions 的權限閘門 | 不是一般 AI App 都能自由取得的權限 |
| 目標功能啟用狀態 | 該 App Function 是否可被執行 | 不是只要呼叫端有權限就一定能跑 |
這篇文章不重寫完整的沙箱分類。如果你想把 App 沙箱、模型沙箱、工具權限和手機權限逐層拆開看，可讀AI Agent 沙盒與手機權限：安全 Agent 為什麼仍需要邊界。本文聚焦 App Functions 這個更具體的 Android Agent 機制，說明它如何把「能做什麼」變成平台權限和 App 功能啟用共同決定的問題。
為什麼手機 Agent 權限仍然重要
就算 Android 逐步建立 App Functions 這類平台機制，手機 Agent 權限仍然決定使用者面對的實際風險。平台權限閘門回答的是「這個呼叫端能不能跨元件執行 App Function」；App 功能啟用回答的是「目標 App 是否提供且允許這個功能」；一般 Android 權限回答的是「這個 App 能否讀取相機、通知、位置、聯絡人等資料」；使用者核准回答的是「這次高影響動作是否真的應該執行」。
四層控制不能互相取代。舉例來說，一個 App Function 可能只是建立草稿，風險較低；另一個功能可能會送出訊息、建立正式紀錄或修改資料。即使平台層允許呼叫，產品仍應讓使用者看見內容、對象與影響範圍。反過來說，使用者同意某次操作，也不代表 Agent 從此可以任意呼叫所有功能。
我們在 FoneClaw 內採用的權限思路，也是把權限放回任務流程中，而不是把它當成一次性設定。當任務需要特定 Android 能力時，流程會引導使用者理解為什麼需要這個權限；當工具或動作可能造成外部影響時，使用者應看到結果或確認點。這是產品層對使用者負責的方式，和 Google App Functions 的平台權限閘門屬於不同層級。
也因此，手機 Agent 安全不能只問「有沒有安全圍欄」。你還要問：資料來源是什麼？工具能改變什麼？誰能啟用或停用？動作是否需要確認？任務過程是否可見？失敗或部分完成時能否停止、復原或交回人工？需要更完整的治理框架，可延伸閱讀AI 代理身份與權限治理：逐工具核准、稽核紀錄與 FoneClaw Android 控制。 評估時可以逐項核對。
FoneClaw 的受治理 Android 執行模型
FoneClaw 是我們打造的 Android phone-agent runtime。這裡要說清楚：FoneClaw 不把自己描述成 Google EXECUTE_APP_FUNCTIONS 權限持有者，也不把 App Functions 當作我們產品能力的前提。FoneClaw 的路線，是由設定模型理解需求與規劃步驟，再由 FoneClaw 透過自身受治理的 Android 工具執行支援動作。
這套模型和 App Functions 討論可以並行理解。Google 的 App Functions 是平台和 App 之間逐步建立明確功能介面的方向；FoneClaw 的重點則是把目前支援的 Android 動作做成使用者看得見的流程。能力範圍以FoneClaw 功能頁列出的 100+ 內建工具方向為準，涵蓋螢幕與 App、裝置狀態、通訊、行事曆、郵件、Memo、位置與工作流程等支援場景。
我們不把「模型能理解」直接等同於「手機就該執行」。模型可以理解自然語言、判斷目標、規劃可能步驟；真正進入手機狀態改變時，仍要看支援工具、Android 權限、目前畫面、資料來源與使用者確認。這條界線能幫使用者分清：助理給出建議、工具準備動作、手機完成結果，是三個不同階段。
FoneClaw 也把等待、取消、復原與完成狀態放進手機任務體驗。依本文更新時可用的最新產品資訊，長時間任務的等待與復原可見性已更清楚；這對安全很實際，因為使用者需要知道任務正在等什麼、已做什麼、是否能停下、結果在哪裡。當 Agent 可以使用更多工具或技能時，執行中的權限與核准比安裝前檢查更重要。若你想深入看技能層風險，可讀AI Agent 技能安全：為什麼手機 Agent 不能只靠安裝前掃描。 使用者可依任務風險決定是否繼續。
2026 年評估手機 Agent 安全性的清單
評估 Google Android Agent 安全或任何手機 Agent 產品時，不要只問「有沒有沙箱」或「是不是用了安全圍欄」。更好的方法，是把平台能力、產品執行路徑和使用者控制分開檢查。
先問執行路徑。它走 App Functions、App 內 API、分享／通知動作、Accessibility、ADB，還是產品自己的支援工具？不同路徑有不同邊界。
看平台權限。若產品宣稱使用 App Functions，是否說明跨元件執行需要受限制權限，以及目標功能必須啟用？
看 App 功能範圍。目標 App 暴露的是哪一個具體功能？是讀資料、建立草稿、建立紀錄，還是直接送出或修改？
看一般 Android 權限。Agent 是否會接觸通知、位置、聯絡人、相機、郵件、行事曆或檔案？是否能按任務縮小範圍？
看使用者核准與證據。高影響動作前是否顯示內容、對象與影響範圍？任務中能否看到用了哪些工具、結果在哪裡？
看停止與復原。任務跑錯、卡住、權限不足或使用者改變主意時，是否能停止、說明狀態並交回手動接續？
這份清單不能保證任何系統零風險，但能幫你把風險從抽象名詞變成可驗證問題。若你正在比較 Claw-like Agent 或開放式手機控制工具，也可以閱讀OpenClaw 安全風險：Claw-like Agent 與更安全的 Android 手機 Agent 邊界，用具體邊界來看不同產品路線的差異。
Android 使用者下一步：先看能力、權限與結果
「Android AI Agent 安全圍欄」這個詞提醒我們：Agent 越能做事，越需要明確邊界。不過真正落到今天的 Android 使用者，請把焦點放在可確認的機制上：App Functions 是否相關、產品走哪條執行路徑、需要哪些 Android 權限、什麼動作需要使用者核准，以及結果能不能被核對。
如果你想在 Android 手機上評估 FoneClaw，建議先從一個可復原的小任務開始，例如整理一段低風險通知、建立可刪除待辦、檢查行事曆或準備不立即送出的訊息草稿。觀察它是否清楚說明需要什麼權限、會執行哪些支援動作、結果是否可見，以及是否能停止或修正。
下一步可以先到FoneClaw 功能頁確認目前支援的 Android 能力，再到FoneClaw 下載頁選擇適合的安裝入口。把平台閘門、App 功能、使用者權限和受治理執行一起看，會比只問「Agent 夠不夠聰明」更接近實際使用安全。