豆包限制 GUI 操作？解析 SAEP 如何定義 App 存取權限

豆包限制 GUI 操作？2026 年 9 月 16 日，Nubia NaviX Ultra 智慧型手機正式開賣，並搭載了消費者版本的「豆包手機助理」，然而實機測試顯示，針對包括微信、淘寶、美團與 京東 在內的主要第三方平台，自動化圖形使用者介面（GUI）操作皆遭到阻擋。此前兩天，即 9 月 14 日，豆包發布了《螢幕自動化執行協議》（Screen Automation Execution Protocol, SAEP），建立了一套正式的協商框架，用於管理外部 AI 代理如何與 Android 應用程式介面互動。對於作業系統架構師、行動安全團隊與平台開發者而言，此部署瓶頸揭示了系統級多模態代理（追求無縫螢幕遍歷）與獨立應用程式執行環境（守護安全邊界與交易完整性）之間，在流量與交易管控商業層面上的根本結構性衝突。

行動代理的商業現實：深入 NaviX Ultra 發布與 GUI 僵局

Nubia NaviX Ultra 的問世——在中國科技媒體圈常被戲稱為「豆包手機二代」——承載了市場的高度期待。該裝置售價 5,999 元起（在政府消費電子補貼後降至 5,499 元），相較於 2025 年 12 月提供給開發者的 M153 工程機（售價 3,499 元），溢價達 2,500 元。在商業發布後，Nubia 宣布開賣首秒銷售額即突破 1 億元。

儘管硬體行銷主打「端到端智慧代理工作流」，但媒體與獨立工程師的實機評測顯示，操作上存在斷層。雖然內建的豆包手機助理能透過語音指令啟動指定的應用程式，但目前的 SAEP 政策與第三方平台的限制，導致應用程式內的自動遍歷、模擬點擊與多步驟結帳功能皆無法運作。使用者發布微信朋友圈、在淘寶比較產品規格、在 京東 完成零售結帳，或在美團點餐的要求均無法執行。實際上，自動化 GUI 操作僅支援系統級應用、中興核心工具、字節跳動內部組合（如抖音、飛書、汽水音樂），以及少數已明確對接的合作夥伴（如曹操出行），而常見的第三方消費者工作流則仍處於暫停或需手動處理的狀態。

重點摘要

• 現階段功能瓶頸：儘管裝置可透過語音開啟第三方 App，但針對主流數位生態系中的應用內遍歷、模擬點擊與後台結帳功能目前仍受限制。
• SAEP 協議簡介：2026 年 9 月 14 日，豆包公布了 SAEP 協議，並開啟 30 天的公眾審閱期（至 2026 年 10 月 15 日止），在此期間，第三方應用預設免受自動化 GUI 互動干擾。
• 系統權限與商業護城河：儘管截至 2026 年 6 月，豆包擁有超過 3.82 億行動 App 月活躍用戶，但純粹的流量規模無法凌駕於應用層的安全沙盒或商業流量治理規則之上。
• 架構典範轉移：行動工程領域正快速從未經許可的螢幕抓取，轉向以宣告式的「代理對代理」（A2A）介面、細粒度權限清單與互惠平台協定為主的模式。

此現狀反映了該平台首代預覽版的技術發展歷程。2025 年 12 月 1 日發布的 Nubia M153 工程機，曾透過具備特權的系統級輸入注入（包括 INJECT_EVENTS 權限）展示了 GUI 自動化能力。然而僅 48 小時內，就有用戶回報微信帳戶出現安全異常及會話異常終止。12 月 3 日，豆包全面關閉了微信的自動化執行功能。12 月 5 日，該團隊正式收緊助理的運作範圍，禁止在遊戲環境、積分農場介面與金融機構類 App 中進行自動化操作。從 M153 原型機到量產版 NaviX Ultra 的演變證明，單靠視覺語言模型（VLM）對螢幕的理解，無法取代結構化的雙邊平台授權。

底層架構治理：解析 SAEP 規則與通知期

2026 年 9 月 14 日推出的豆包 SAEP 協議，標誌著業界嘗試標準化作業系統代理如何宣告、請求與執行螢幕自動化的努力。SAEP 並未將第三方應用的視圖層級視為被動的視覺目標，而是引入了明確的互動同意生命週期。2026 年 9 月 17 日，豆包手機助理發布了一份正式問答說明，解釋為何目前無法透過 GUI 操作常見第三方 App，並詳細說明了 30 天通知期與應用程式自主權框架。

治理架構分為兩個階段。在 2026 年 9 月 14 日至 10 月 15 日的 30 天公眾通知期內，執行層對所有支援硬體（包含 NaviX Ultra 與 M153）實施「預設阻斷」策略。除非第三方開發者明確提交同意宣告，否則豆包手機助理將不會在該 App 的 UI 層級內執行模擬點擊或自動化任務。通知期結束後，協議將轉向風險分級框架：正式登記拒絕的應用將保持豁免，未明確表達立場的應用則將根據功能風險等級進行評估與開放。第三方開發者隨時保有拒絕權利，一旦拒絕，助理將立即終止自動化操作。

在 SAEP 框架的範疇內，應用開發者可針對不同功能控制項宣告操作邊界：

1. 一般螢幕自動化權限：宣告應用程式是否允許外部代理在視窗介面內啟動自動化工作流。
2. 螢幕截圖與檢視：控管助理在執行任務時，是否有權截圖或檢視已許可的視圖內容。
3. 模擬使用者輸入：規範代理是否可將合成觸控座標、手勢或自動化文字字串輸入至原生視圖中。
4. 內容修改：定義助理是否獲准更改、編輯或清除應用程式狀態中的文字、表單欄位或用戶草稿。

此正式協議回應了實測中暴露的操作現實。2026 年 5 月，AndroidDaily 研究基準測試評估了 350 個標準行動任務在 94 個 Android 生產環境應用中的表現。在嚴格的多步驟測試下，最強大的多模態代理端到端任務完成率僅為 62.0%，而自動化評估架構（GRADE）與人工標註者的一致性為 87.37%。

+--------------------------------------------------------------------------+
|            ANDROIDDAILY 基準測試：多步驟代理損耗率                        |
+--------------------------------------------------------------------------+
|                                                                          |
|  評估任務：350 個現實的多步驟工作流                                       |
|  評估環境：94 個 Android 生產環境 App                                     |
|                                                                          |
|  頂尖多模態代理完成率：62.0%                                              |
|  [====================================>                          ]       |
|                                                                          |
|  基準測試識別出的主要失敗模式：                                           |
|  1. 延遲導致的 UI 未對齊                                                  |
|  2. 記憶體引發的重複操作迴圈                                              |
|  3. 協定限制導致的能力衰減                                                |
|                                                                          |
|  實際執行摩擦範例：                                                       |
|  - 推論延遲期間發生的非同步 UI 更新與彈窗                                  |
|  - 針對模糊視覺狀態的冗餘來回座標循環                                     |
|  - 動態表單驗證規則與區域服務邊界                                         |
|                                                                          |
+--------------------------------------------------------------------------+

識別 UI 元件與成功完成端到端工作流之間的落差，源於非決定性的應用環境。生產應用常透過動態伺服器端 UI 框架更改版面配置、插入臨時促銷彈窗、執行反爬蟲驗證，並在 SKU 或座位無效時要求條件判斷。當助理僅透過視覺座標推論而非直接與應用互動來解析這些狀態時，執行管線即會崩潰，導致任務會話中斷、錯誤下單或安全例外。

解耦系統與威脅模型：安全沙盒、流量護城河與決策主權

第三方平台抗拒不受限制的 GUI 自動化，背後是基礎的安全工程原則與商業護城河防禦。若將此衝突簡單視為反競爭行為，則忽視了外部程序在經過驗證的應用邊界內模擬互動時所帶來的嚴重操作與法律漏洞。

從應用安全角度看，無頭 GUI 自動化跨越了應用視圖邊界。在 Android 架構中，應用程式位於隔離的 Linux UID 進程沙盒中，透過驗證過的 Binder IPC 與明確的 Intent 進行通訊。當 AI 助理利用系統級 AccessibilityService 鉤子或自訂顯示注入層來操作介面時，它是在未突破進程沙盒的情況下，從外部與應用程式暴露的視圖層級進行互動。然而，這種特權互動層帶來了巨大的操作摩擦。

+--------------------------------------------------------------------------+
|               潛在風險面：代理 vs. 執行環境                               |
+--------------------------------------------------------------------------+
|                                                                          |
|  作業系統特權層                                                          |
|  +--------------------------------------------------------------------+  |
|  | 多代理助手（豆包手機助理 / 系統 VLM 引擎）                           |  |
|  +--------------------------------------------------------------------+  |
|         |                                                      |         |
|   (特權輸入注入 /                                (顯示幀緩衝 /         |
|    合成事件派發)                                 視覺佈局解析)        |
|         v                                                      v         |
|  +--------------------------------------------------------------------+  |
|  | 主機應用程式視窗與視圖層級                                          |  |
|  |                                                                    |  |
|  |  [ 潛在威脅與穩定性向量 ]                                            |  |
|  |  * 敏感視圖暴露：攝入未遮蔽的餘額/SMS                              |  |
|  |  * 反欺詐訊號扭曲：自動化改變行為特徵                               |  |
|  |  * 非決定性輸入：誤觸按鈕/訂單執行                                  |  |
|  |  * 授權模糊：自動化步驟的責任歸屬不明                               |  |
|  +--------------------------------------------------------------------+  |
|                                                                          |
+--------------------------------------------------------------------------+

此互動模型產生了多個潛在風險面：

• 反欺詐遙測失效：部分欺詐與機器人偵測系統評估互動計時、手勢模式、裝置訊號與其他行為指標來驗證人類身份。合成點擊注入會改變這些行為特徵，促使平台風險引擎標記帳戶、終止會話或強制執行二次驗證。
• 敏感視圖狀態暴露：具備螢幕緩衝區攝入能力的代理，可能無意間截取敏感文字欄位、個人交易帳目、身份證明文件與私密對話內容，並將其納入本地上下文緩衝區或傳輸至遠端推論連線。
• 交易授權模糊：當助理根據機率性自然語言解析觸發操作狀態變更（如下單或修改偏好設定）時，若使用者未直接執行確認步驟，將難以釐清非預期結果的責任歸屬。

除了技術安全，商業護城河也扮演關鍵角色。大型數位生態系的獲利引擎極度依賴交易前的探索階段。路透社 2026 年 8 月 12 日報導，騰訊第二季總營收成長 11%，其中行銷服務營收成長 22%，主要得益於微信生態內的 AI 廣告效率提升。平台投入大量資源於搜尋排名、推薦演算法與促銷資訊，旨在影響消費者選擇。

當外部助理繞過應用程式的視覺發現路徑（自主定位產品、評估商家並應用折扣）時，會降低該平台在廣告、贊助搜尋與交叉銷售等領域的曝光機會。對競爭平台而言，賦予字節跳動旗下的助理不受限存取權，形同商業自殺。第三方平台自然尋求保留對消費者參與及交易路由的統治權。

這種動態解釋了為何僅靠消費者 App 規模無法保證作業系統的話語權。根據 QuestMobile 統計，豆包於 2026 年 6 月在行動 App 端達到 3.82 億月活，領先競爭對手如阿里的通義（1.67 億 MAU）。然而，應用程式熱度僅是硬體控制的下游。在中國市場，IDC 2026 Q2 數據顯示前六大 OEM（華為、蘋果、OPPO、vivo、小米與 Honor）掌握了約 96.4% 的出貨量。中興佔比 0.3%，Nubia 未列入前十。由於主機廠積極開發自有助理生態系來達成硬體差異化，跨平台代理在試圖爭取系統級支配地位時，必然面臨嚴重的平台邊界阻礙。

從無頭抓取到治理介面：邁向結構化對接的轉變

NaviX Ultra 的部署摩擦與 SAEP 的引入，凸顯出無結構視覺抓取僅是行動 AI 助理演進中的過渡階段。透過模擬視覺來操作任意軟體，存在持續的維護成本、高操作失敗率與不可調和的平台抗性。

行動產業正日益轉向以「代理對代理」（A2A）介面與正式能力共享協議為特徵的協商式結構化執行框架。在此典範下，應用程式不再將視覺介面暴露於不受控的座標導航；相反地，它們會向作業系統執行環境直接暴露已驗證的參數化功能端點。

近期產業的實踐凸顯了這一趨勢：

• 結構化終端生態：2026 年 7 月 13 日，階躍星辰（StepFun）發布了 STEPX 終端品牌與 STEPX Neo 裝置解決方案，以及 Step AOS 平台。據財新報導，階躍星辰宣布與支付寶、百度、美團、京東、滴滴、攜程與高德地圖等達成合作，透過預先協商的協議介面來執行外部服務，而非依賴不受限的 GUI 操作。
• 雙邊 A2A 合作：2026 年中，騰訊與華為、榮耀、小米、OPPO 與 vivo 等國內主流硬體製造商建立授權 A2A 能力合作。該機制使系統級助理（如榮耀 YOYO 或 OPPO 小布）能透過驗證過的雙邊授權流程，發起微信語音視訊通話或傳送訊息給特定聯絡人，而不需存取私人聊天視窗的特權。

+--------------------------------------------------------------------------+
|            行動代理互動：架構轉型                                          |
+--------------------------------------------------------------------------+
|                                                                          |
|  [ 使用者語音指令：「幫我訂一杯附近咖啡店的冰拿鐵」 ]                     |
|                                |                                         |
|                                v                                         |
|  [ 系統代理編排器：語意意圖與參數提取 ]                                    |
|                                |                                         |
|         +----------------------+----------------------+                  |
|         |                                             |                  |
|         v                                             v                  |
|  [ 不受限視覺路徑 ]                 [ 治理型能力路徑 ]                    |
|  - 透過視覺 VLM 解析螢幕               - 查詢宣告式 SAEP 政策              |
|  - 注入合成觸控事件                  - 派發結構化 A2A                    |
|  - 動態 UI 下失敗率高                 - 程式化狀態檢查                    |
|  - 受風險與安全規則阻擋                 - 應用程式受控的權限                |
|         |                                             |                  |
|         v                                             v                  |
|  [ 執行暫停 / 失敗 ]                 [ 已驗證的執行結果 ]                 |
|                                                                          |
+--------------------------------------------------------------------------+

對於軟體工程團隊而言，此轉變徹底改變了行動架構。開發者不應將應用安全僅視為防範機器人的被動混淆，而必須隨著系統智能化程度提升，評估平台如何暴露可定址的功能、建立機器可讀的權限邊界，以及守護敏感的交易狀態。

行動工程團隊的策略建議

為因應系統級 AI 助理的興起與不斷演進的螢幕自動化協議，行動開發與安全團隊應考量以下工程實踐：

1. 制定 App 專屬的代理存取政策：評估自動化 GUI 互動對用戶安全、平台條款與業務工作流的影響。開發團隊應決定是否參與 SAEP 等治理框架、登記明確的拒絕宣告，或尋求協商式的雙邊對接路徑。
2. 在交易邊界執行階段性驗證：確保敏感變更（如訂單下達、資金轉帳、個人資料修改或憑證更新）需經過明確的人工確認。實施生物辨識、雙重驗證或密碼學證明，可有效防止或大幅降低因自動化完成而帶來的風險，確保驗證過程包含獨立的使用者出席或硬體級確認。
3. 監控合成輸入與自動化互動訊號：在安全監控堆疊中加入行為遙測與輸入驗證，以偵測關鍵工作流中異常的互動計時、重複的座標模式、自動化專屬事件序列及其他異常風險訊號。
4. 準備模組化的無頭能力端點：將核心數位服務從僵化的、深度嵌套的視覺導航路徑中解耦。設計可定址且通過結構化驗證的 API 介面，使應用程式能安全地與結構化代理框架（如 A2A 協定）對接，而不需將視覺視圖層級暴露於未經驗證的爬蟲中。

參考資料

• 36Kr. (2026). 豆包手機？夢裡才有的事. 36Kr 科技報導。
• IT 之家. (2026). 為何常見應用無法 GUI 操作？豆包手機助理回應. IT 之家行動生態組。
• 經濟觀察報. (2026). 豆包手機助理啟動 GUI 合作協議 SAEP，第三方 App 自主選擇. 經濟觀察報科技組。
• 第一財經. (2026). Nubia 豆包 AI 手機實測：支付交還用戶自己. 第一財經金融科技組。
• QuestMobile. (2026). 2026 中國行動網路半年度報告. QuestMobile 行業觀察。
• Zhang, C., et al. (2026). AndroidDaily: 實景閉源應用行動 GUI 代理的可驗證基準測試. arXiv 電腦科學儲存庫。
• IDC. (2026). 2026 年 Q2 中國手機市場衰退背景下的華為與蘋果成長分析. IDC 研究室。
• 路透社. (2026). 中國騰訊第二季營收成長 11%，獲利低於預期. 路透社科技新聞。
• 財新. (2026). 階躍星辰發布 Step AOS 及首款 AI 手機 STEPX Neo. 財新科技。
• IT 之家. (2026). OPPO ColorOS 小布助手整合微信，透過 A2A 實現語音通話與傳訊. IT 之家智慧行動組。