豆包發布了 SAEP？2026 年 9 月 14 日，字節跳動正式宣布推出豆包手機助理消費者版本，並與硬體製造商努比亞 (Nubia) 合作，於努比亞 NaviX Ultra 手機首發（預計 2026 年 9 月 16 日上市）。除了多模態螢幕識別與專用 AI 硬體按鍵外，字節跳動還推出了「螢幕自動化執行協議」(Screen Automation Execution Protocol, SAEP)——這是一個進入 30 天公開意見徵詢期的應用層治理框架。SAEP 賦予第三方 App 開發者明確宣告是否允許 AI 代理在其 App 內執行螢幕自動化操作的權限。對於移動軟體架構師、安全主管與遙測工程師而言，豆包 SAEP 治理框架的出現標誌著一個重要轉變：從不受約束的視覺化 UI 自動化，轉向一種新興的宣告式治理模型，重新定義了移動軟體如何管理自動化互動。
硬體整合與 SAEP 宣告式模型
豆包手機助理消費者版本的發布，標誌著從對話式螢幕助理轉向主動任務執行引擎的演進。根據 IT 之家 與 OSCHINA 的報導，此次消費者版本聚焦於日常穩定性、多模態上下文保持，以及透過 Beta 版「手機操作」功能實現跨應用執行。
重點概覽
- 商業硬體載體：於 2026 年 9 月 16 日在努比亞 NaviX Ultra 首發，並計畫為努比亞 M153 等舊機型提供更新路徑。
- 實體輸入與螢幕感知：結合支援指紋驗證的專用實體 AI 按鍵，無需手動截圖即可進行即時螢幕問答。
- SAEP 宣告式協議：引入應用層操作宣告標準並設置 30 天公開徵詢期，允許第三方 App 明確許可或限制 AI 驅動的螢幕自動化。
- 代理保護框架：建立多層級代理保護機制，旨在強制執行分層的操作邊界、用戶可控的安全機制及操作安全。
如官方公告及 北京市人民政府 報導所示，實體互動模型將意圖與授權綁定。專用 AI 按鍵整合了指紋驗證，將經過身分認證的設備端調用與啟動助理綁定，確保在操作發起點即完成身分確認。
除了基礎的視覺問答外，該系統還能解析螢幕上下文並跨多個第三方工具執行序列化任務。為防止未授權操作，該版本引入了 SAEP 協議。SAEP 不再將自動化邊界留給隨機的 AI 模型行為或作業系統預設值，而是將自動化限制的定義權交還給 App 開發者。
豆包手機助理與 SAEP 發布里程碑
| 里程碑日期 | 運作事件 | 工程範疇 |
|---|---|---|
| 2026 年 9 月 14 日 | 消費者版本與 SAEP 公告 | 正式發布豆包手機助理；開啟 30 天 SAEP 公開徵詢期 |
| 2026 年 9 月 16 日 | 努比亞 NaviX Ultra 上市 | 首批搭載實體 AI 按鍵的商業硬體上市 |
| 2026 年 9 月至 10 月 | SAEP 產業諮詢期 | 收集關於宣告式應用層自動化邊界的生態反饋 |
| 後續 OTA 更新 | 舊機型推送 | 計劃透過系統更新將助理功能擴展至努比亞 M153 裝置 |
解構 GUI 代理範式：為何操作手機需要應用層治理
在科技媒體 愛范兒 (Ifanr) 的技術分析中，系統級代理驅動的轉變被形容為將智慧型手機轉變為「行動終端」。傳統行動作業系統運作方式為功能目錄：App 處於被動狀態，直到人類用戶打開它們、導航其視覺階層並手動輸入數據。
系統級多模態 GUI 代理透過引入自動化感知-執行循環改變了此流程：
- 螢幕與上下文捕捉：代理透過獲授權的系統能力讀取活動顯示與上下文資訊，無需開發者額外標記即可讀取視覺與文字內容。
- 多模態意圖規劃：基礎模型將自然語言命令（如「檢查我的日曆，根據天氣規劃通勤路線，並設置出發鬧鐘」）翻譯為離散的執行序列。
- 模擬動作執行：代理使用獲授權的系統級能力，依序在安裝的第三方應用中執行點擊、滑動與文字輸入。
雖然跨 App 執行簡化了複雜流程，但也帶來了嚴峻的安全、商業與責任挑戰。如果自動化代理進入銀行應用，它是否能未經額外認證發起財務交易？如果代理遍歷社交應用，它是否能自主發布內容？
歷史上，作業系統缺乏讓 App 將自動化姿態傳達給外部 AI 代理的細粒度機制。在標準 Android AccessibilityService 架構下，權限是用戶授權的系統開關，與宣告的功能綁定——例如指定 canRetrieveWindowContent 以獲取活動視窗節點，或配置 canPerformGestures 以分發觸控輸入。儘管功能強大，但這些能力是從「輔助服務被允許做什麼」的角度出發，而非讓目標應用定義對外部 AI 工具的細粒度限制。
從概念上講，SAEP 反轉了這種治理方向：正如 21 世紀經濟報導 所述，目標應用可以明確宣告是否允許 AI 驅動的自動化在其 App 內執行或限定操作邊界。根據該協議，豆包手機助理承諾尊重這些開發者宣告，確保明確限制的互動不會被自動化。
操作化宣告式邊界：受 SAEP 啟發的參考架構
螢幕自動化執行協議 (SAEP) 在第三方軟體與系統級自動化代理之間建立了應用層治理合約。與其依賴視覺啟發式演算法來猜測互動是否安全，宣告式框架使應用程式能直接發布其操作姿態。
雖然字節跳動已建立第三方許可/拒絕宣告與分層代理保護系統的核心原則，但正式技術規範、模式定義與整合 API 仍處於 30 天公開徵詢期內。下方的架構與程式碼列出了參考概念模型，展示了工程團隊如何在客戶端 App 內操作宣告式策略邊界。
工程範疇說明：以下控制項與參考實作代表了受 SAEP 公開治理方向與豆包分層保護模型啟發的工程設計模式；它們並非公開的官方 SAEP API 要求或最終技術規範。
+-------------------------------------------------------------------------+ | 概念性代理策略解析架構 | +-------------------------------------------------------------------------+ | | | [ 用戶意圖 ] | | 自然語言命令（例如：「從 App 訂購居家用品」） | | | | | v | | [ 系統代理協調引擎 ] | | - 解析目標意圖、規劃任務圖並指向應用程式 | | | | | v | | [ 應用程式策略解析層 ] | | - 檢查目標 App 的宣告自動化清單 / 策略註冊表 | | -（概念模型；實際 SAEP 表示可能有所不同） | | | | | +---------------------------------------+ | | | (自動化宣告：已許可) | (宣告：受限) | | v v | | [ 代理執行路徑 ] [ 操作已暫停 ] | | - 執行模擬輸入 - 代理中止執行 | | - 高影響任務觸發用戶接管或裝置重認證 - 向用戶提示人工接管以完成操作 | | | | | v | | [ 應用程式溯源記錄 ] | | - 應用程式記錄會話上下文以供內部審計 | | | +-------------------------------------------------------------------------+
1. 概念性應用層宣告
在受 SAEP 原則啟發的宣告式模型中，應用程式可以區分操作區域：
- 公開 / 資訊視圖：專用於目錄瀏覽、產品探索或資訊閱讀的頁面可被標記為開放自動化導航。
- 受限 / 敏感視圖：高影響表面——如結帳授權、帳戶憑證或資金轉帳——可被標記為受限，指示代理停止自動執行並提示直接的人工接管。
2. 多層級保護考量
為了支援安全自動化，運行環境依賴於分層防禦考量：
- 最小權限範疇：作為一般安全建議，自動化操作應按任務進行評估，防止後台流程獲取全域執行權限。
- 明確人工接管：在已報導的商業安全工作流程中，敏感交易會暫停自動化執行，提示用戶手動完成付款或敏感資訊輸入。實體設備特性（如 NaviX Ultra 的指紋 AI 鍵）在設備級互動期間充當硬體驗證檢查點，而非通用的協議級生物識別欄位。
- 應用側溯源記錄：在平台暴露互動溯源訊號的情況下，應用側記錄是推薦的工程實踐，用於記錄代理中介的會話以供內部安全與審計審查。
// 說明性的 Android / Kotlin 實作，展示受宣告式協議原則（如 SAEP）啟發的應用側參考架構。
// 注意：官方 SAEP 規範與清單模式仍受公開審查影響；
// 以下程式碼代表說明性的工程設計模式，非官方 SDK 實作。
package com.example.app.security.automation
enum class OperationalScope {
INFORMATIONAL_READ, // 內容瀏覽、產品詳情、目錄探索
INTERACTIVE_INPUT, // 搜尋查詢、表單輸入、篩選應用
RESTRICTED_OPERATION // 結帳處理、憑證輸入、帳戶配置
}
data class ClientAutomationPolicy(
val scope: OperationalScope,
val isAutomationPermitted: Boolean,
val requiresManualTakeover: Boolean
)
object ApplicationPolicyRegistry {
private val policyMap = mutableMapOf<String, ClientAutomationPolicy>()
init {
// 在範例應用路徑中註冊說明性宣告邊界
registerRoutePolicy(
routePath = "catalog/browse",
policy = ClientAutomationPolicy(
scope = OperationalScope.INFORMATIONAL_READ,
isAutomationPermitted = true,
requiresManualTakeover = false
)
)
registerRoutePolicy(
routePath = "cart/review",
policy = ClientAutomationPolicy(
scope = OperationalScope.INTERACTIVE_INPUT,
isAutomationPermitted = true,
requiresManualTakeover = false
)
)
// 將敏感交易介面指定為不可自動化
registerRoutePolicy(
routePath = "checkout/payment",
policy = ClientAutomationPolicy(
scope = OperationalScope.RESTRICTED_OPERATION,
isAutomationPermitted = false,
requiresManualTakeover = true
)
)
}
fun registerRoutePolicy(routePath: String, policy: ClientAutomationPolicy) {
policyMap[routePath] = policy
}
fun resolvePolicy(routePath: String): ClientAutomationPolicy {
return policyMap[routePath] ?: ClientAutomationPolicy(
scope = OperationalScope.RESTRICTED_OPERATION,
isAutomationPermitted = false,
requiresManualTakeover = true
)
}
}
class AgentExecutionGuard {
sealed class EvaluationOutcome {
object Allowed : EvaluationOutcome()
object ProhibitedByPolicy : EvaluationOutcome()
object RequiresHumanTakeover : EvaluationOutcome()
}
/**
* 評估自動化操作是否應在指定路徑上繼續進行。
* 在發生模擬觸控動作前諮詢應用程式策略宣告。
*/
fun evaluateAction(routePath: String, isAgentDriven: Boolean): EvaluationOutcome {
if (!isAgentDriven) {
return EvaluationOutcome.Allowed
}
val policy = ApplicationPolicyRegistry.resolvePolicy(routePath)
if (!policy.isAutomationPermitted) {
return EvaluationOutcome.ProhibitedByPolicy
}
if (policy.requiresManualTakeover) {
return EvaluationOutcome.RequiresHumanTakeover
}
return EvaluationOutcome.Allowed
}
}
對移動遙測與用戶意圖的新興影響
隨著系統級 GUI 代理變得普及，其影響超出了作業系統安全，延伸至移動分析、產品遙測與互動度量。
過去十多年來，許多產品分析工作流程隱含地將 App 內互動事件視為直接用戶互動的代理指標。
GUI 代理為此分析基礎引入了細微差別：
- 委派與直接意圖：當代理為了滿足用戶目標而瀏覽目錄或點擊介面元素時，該行為反映了真實的用戶意圖，但缺乏對中間 UI 狀態的人類視覺監察。
- 會話節奏與時間：自動化任務執行可能跨越非同步任務隊列或多步驟工作流程，產生與手動瀏覽模式不同的互動速度與事件間隔。
- 遙測解歧義：隨著宣告式標準的演進，產品分析平台可能更需要區分人工互動與代理中介操作，以確保行為隊列分析的準確性。
將 App 內代理治理與外部安裝邊界解耦
雖然 SAEP 等協議框架管理 AI 代理在已安裝應用內的執行，但用戶獲取與產品發現頻繁發生在應用安裝前的獨立生命週期中。
在多管道行銷中，潛在用戶透過移動端網頁著陸頁、聯盟促銷或搜尋活動發現服務。如果 AI 代理協助用戶發現需要安裝原生 App 的新服務，互動便會跨越開放網路並透過應用商店進行。
+-------------------------------------------------------------------------+ | 獨立的下游移動獲取旅程 | +-------------------------------------------------------------------------+ | | | [ 外部觸點：移動網頁著陸 / 活動頁面 ] | | 捕獲上下文：?channel=ai_discovery&campaign_id=cmp_804&ref=partner | | | | | v | | [ 用戶發起安裝 / 導航至應用商店 ] | | | | | v | | [ 安裝邊界：標準商店分發不會將網頁查詢參數傳遞至編譯後原生二進位檔 ] | | | | | v | | [ 用戶首次打開原生 App (冷啟動) ] | | | | | v | | [ 延遲深度連結 (DDL) 引擎：伺服器輔助上下文匹配 ] | | | | | v | | [ 符合資格的管道 / 活動上下文恢復並應用路由 ] | | | +-------------------------------------------------------------------------+
標準應用商店安裝流程不會在下載時將網頁查詢參數或推薦元數據轉發至 App 二進位檔中。在首次冷啟動時，應用程式無法原生識別是哪個具體活動或網頁內容促成了此次安裝。
為了跨越此安裝邊界，工程團隊使用了不同的連結處理架構：
| 路由架構 | 目標 App 狀態 | 安裝後的參數保留 | 操作擁有權模型 |
|---|---|---|---|
| 自訂 URI Schemes | 目標 App 已安裝 | 無 App 時無原生目的地；需要明確的後備處理 | 應用擁有 (高維護負擔) |
| 已驗證通用連結 | 目標 App 已安裝 | 解析為後備網頁；無法在隨後商店安裝後原生重建來源網頁上下文 | 網域 + 應用擁有 (需要託管 AASA) |
| 延遲深度連結 (DDL) | 目標 App 未安裝 | 在首次冷啟動時恢復符合條件的預安裝參數 | SDK 輔助 (託管歸因與路由引擎) |
在企業移動架構中，開發團隊部署了如 Branch、AppsFlyer、Adjust 或 Opoinstall 等延遲深度連結 (Deferred Deep Linking) 框架。像 Opoinstall 這樣的平台會在用戶轉向應用商店前，記錄符合條件的預安裝網頁點擊元數據（如行銷管道標籤或產品 SKU 參考）。
在 App 首次冷啟動時，客戶端 SDK 會向後端查詢以檢索與預安裝互動關聯的延遲上下文。根據 Opoinstall 首頁 的官方平台文件，此延遲參數傳遞框架可在高達 98% 的符合案例中於首次啟動時恢復參數，提供了一種替代手動促銷碼的自動化方案（消除了手動邀請碼的需求）。
架構邊界必須保留：延遲深度連結嚴格跨越 App 安裝邊界運作。它不管理運行時 AI 代理權限，也不取代 SAEP 等應用層協議。相反，DDL 確保上下文活動參數在從外部網頁發現轉向原生冷啟動序列時得以保留，而 SAEP 等運行時治理框架則定義了代理在 App 安裝後如何與應用程式進行互動。
常見問題 (FAQ)
隨豆包手機助理推出的 SAEP 協議是什麼？
SAEP 與標準 Android 輔助功能權限有何不同？
GUI 代理如何影響移動產品分析？
給移動架構師與工程主管的關鍵建議
字節跳動豆包手機助理的商業發布與 SAEP 的引入，凸顯了移動軟體工程領域的重大發展。隨著 AI 代理從對話式覆蓋層演進為自動執行引擎，App 開發者必須從被動觀察者轉變為積極的策略定義者。
為準備系統級 GUI 代理的擴張，工程團隊應優先考慮三項架構計畫：
-
準備宣告式自動化策略：審查應用表面區域以識別敏感交易工作流程，準備符合 SAEP 等新興標準的宣告式配置，為 AI 助理定義明確的操作邊界。
-
針對委派意圖調整遙測：評估 App 內分析管道以監測新興的代理中介導航模式，確保行為指標能準確反映真實的商業價值。
-
維護獨立的獲取基礎設施：確保外部獲取漏斗與運行時代理治理解耦，透過部署已驗證的通用連結 (Universal Links) 與延遲深度連結，以在安裝邊界前後保留用戶引導上下文。
參考資料
-
IT 之家. (2026). 豆包手機助理消費者版發布：推出 GUI 合作協議，讓第三方 App 可許可或限制 AI 自動化 .
-
21 世紀經濟報導. (2026). AI 助理能進 App 嗎？豆包將選擇權交給第三方 App .
-
OSCHINA. (2026). 「豆包手機助理」消費者版本正式發布 .
-
愛范兒. (2026). 豆包手機助理上手體驗：智慧型手機如何成為「行動終端」 .
-
北京市人民政府. (2026). 豆包手機助理消費者版本正式發布 .
-
Android Developers. (2026). AccessibilityService API 參考. Android 文件.
-
Android Developers. (2026). AccessibilityServiceInfo API 參考. Android 文件.
-
Apple Developer. (2026). 在 App 中支援通用連結. Apple 文件.
-
Opoinstall. (2026). 延遲深度連結與參數化 App 安裝概覽.
Share this article
