30 天公告期結束，主要 App 仍無法使用
豆包手機助手於 10 月 14 日宣布，在《螢幕自動化執行協定》（SAEP）完成 30 天公開公告期後，將逐步開放第三方應用程式的螢幕自動化操作權限。公告期結束後，開發者仍可拒絕授權；明確拒絕自動化操作的應用程式，助手將不會代為操作。
目錄
拒絕名單涵蓋許多能讓手機助手處理日常任務的服務。阿里巴巴生態系應用程式包括淘寶、天貓、菜鳥、支付寶、釘釘和餓了麼。騰訊生態系應用程式包括微信、QQ、《王者榮耀》和《英雄聯盟：激鬥峽谷》。其他列入名單的服務包括美團、拼多多、快手、小紅書、知乎、招商銀行和中國工商銀行。
因此，這次調整是擴大存取範圍，而非不受限制地控制手機。它將原本要求開發者主動同意自動化操作的臨時規定，改為逐步開放符合條件的應用程式；除非開發者已拒絕，或設定了限制政策。系統安全規則、使用者授權，以及應用程式本身的業務檢查仍然適用。
豆包表示，開發者可隨時提出拒絕，平台將在三個工作天內回應。這項回應承諾不等於保證每項申請都會在期限內完成處理。公告指出，相關操作將盡快關閉，但未另行訂定適用於所有情況的統一處理期限。
對使用者而言，實際問題在於助手能完成任務的哪些步驟。應用程式可能完全無法使用，敏感頁面可能受到封鎖，或最後一步仍須由使用者接手。SAEP 提供了因應這三種情況的機制。
公告期結束後有哪些變化？
公開公告期間，豆包僅允許自動化操作系統應用程式、字節跳動旗下應用程式，以及透過 SAEP 或官方電子郵件明確同意參與的第三方服務。其他應用程式原則上不會由助手操作。
公告期結束後，未透過官方管道提出拒絕，也未設定停用政策的應用程式，將列入逐步開放的候選範圍。9 月公布的計畫說明指出，開放將依風險等級進行，而不是一次切換所有應用程式。
這項區別有助於理解任務未能完成的原因。10 月 14 日之前，應用程式無法操作，可能只是因為開發者尚未主動同意參與。調整之後，操作仍可能因開發者拒絕、頁面限制、身分驗證、要求使用者確認，或應用程式自身的安全控管而失敗。
豆包消費者版於 9 月 14 日推出，手機操作功能當時仍處於測試階段。豆包智慧服務、購物助理、錄音摘要和工作任務等其他功能，則與個別外部應用程式是否允許螢幕自動化操作無關。
開放進程如何走到 10 月 14 日
政策調整源於手機自動化操作與應用程式安全系統先前的衝突。2025 年 12 月，豆包手機技術預覽版首次推出後，遇到微信登入問題、淘寶驗證挑戰，以及部分銀行應用程式偵測到風險環境後停止登入或付款操作。
隨後推出的消費者版，則在擴大開放前設立正式申報流程。主要進展如下：
- 2025 年 12 月：努比亞 M153 推出豆包手機自動化功能，之後多款大型應用程式祭出限制與安全驗證。
- 2026 年 9 月 14 日：消費者版助手推出手機操作測試功能，30 天公告期也自此開始。部分 M153 使用者表示，原先可用的自動化任務已無法使用。
- 9 月 16 日：搭載消費者版助手的努比亞 NaviX Ultra 上市。相關報導將這一天稱為發表日或開賣日。
- 9 月 17 日：豆包說明，公告期結束後，開發者仍可拒絕自動化操作。
- 10 月 14 日：豆包宣布公告期結束，符合條件的第三方應用程式將逐步開放操作。
對既有使用者而言，9 月實施的限制可能讓人感覺功能縮水。報導指出，部分 M153 使用者已無法使用熟悉的自動叫車、訂餐等任務。這些限制反映的是暫行授權規則，不能據此認定所有受影響的開發者都已拒絕助手存取。
哪些應用程式拒絕開放存取？
10 月 14 日公布的拒絕名單不只涵蓋阿里巴巴和騰訊。報導也列出 DeepSeek、WPS 和唯品會，以及購物、社群媒體、銀行和本地生活服務應用程式。中國移動、中國聯通和中國電信旗下應用程式也被指拒絕開放存取。
這些限制影響努比亞 M153 和努比亞 NaviX Ultra。重要的不是應用程式數量，而是所涵蓋的服務類型。購物任務可能遇到無法使用的購物平台，通訊任務可能卡在訊息應用程式，金融任務則可能同時面臨開發者拒絕和系統安全要求。
目前公布的說明並未完整統計所有可使用和無法使用的應用程式。較早前有報導宣稱，九成常用應用程式已逐步支援豆包的 GUI 智慧代理，但未說明統計方法或完整統計範圍。這項數據無法證明 10 月新規下可存取的應用程式比例。
9 月公布的支援服務名單包括曹操出行、汽水音樂和飛書妙記。某項服務出現在手機操作支援名單中，並不代表其開發者已完成 SAEP 所有技術整合。支援特定任務與採用該協定，兩者相關但並不相同。
SAEP 實際管控哪些事項
豆包的官方整合指南將 SAEP 描述為一套協定，讓 Android 應用程式為 GUI 智慧代理設定操作界線。GUI 智慧代理能理解圖形化使用者介面並執行點擊按鈕、輸入文字等操作，而非只透過應用程式專用的軟體介面運作。
指南指出，SAEP 支援 ObricUI 2.2 以上版本。這不代表 SAEP 能在所有 Android 手機上運作。開發者必須確認目標裝置是否具備並啟用這項功能。若檢查未通過，應用程式仍須依賴自身的安全控管機制。
限制分為三個層級：App，涵蓋整個應用程式；Activity，涵蓋特定 Android 畫面或頁面；Intent，涵蓋發布或刪除內容等業務操作。此處的 intent 指的是操作目的，不只是助手點擊的可見按鈕。
這種架構讓應用程式可以允許部分自動化協助，同時保護敏感步驟。應用程式可透過 global_disable 禁止所有代理操作、透過 screenshot_disable 禁止擷取螢幕畫面，或透過 input_disable 封鎖模擬點擊和文字輸入。其他控制項則涵蓋內容修改、最終發布、刪除，以及獎勵或促銷優惠。
操作獲准仍須取得授權
官方指南特別區分應用程式設定的權限與系統最終決策。結果取決於代理的身分與信任狀態、系統安全基準、應用程式設定的政策，以及使用者對當前任務的授權。
應用程式不能放寬系統安全基準。若系統要求封鎖操作或由使用者介入，應用程式不能將結果改為允許。若多項適用規則彼此衝突，則採用限制較嚴格的結果。若政策解析失敗，系統會退回應用程式可用的預設政策，並記錄原因。
指南說明三種主要結果。ALLOW 允許使用相關系統功能，但不會免除應用程式的身分驗證或使用者授權要求。BLOCK 會停止操作，助手不得另尋方式繞過限制。CALL_USER 則會暫停自動化，等待系統確認或使用者手動接手。
使用者確認僅適用於畫面上顯示的特定步驟，不是對所有後續操作的概括授權。付款、轉帳、帳戶驗證、發布、刪除和變更權限等敏感操作，系統可能要求使用者確認、手動接手，或拒絕操作。
文件中也出現第四種標示 CLARIFY，用於要求釐清或施加較寬鬆的限制。其確切意義和是否適用，取決於目標軟體套件。指南也提醒開發者，不應假設 App、Activity 和 Intent 規則的先後順序，能讓後續規則推翻先前限制。
限制不能只靠助手承諾遵守
SAEP 最重要的技術主張，是限制應透過系統控制點落實，而非只仰賴代理自行遵守。螢幕擷取、無障礙功能讀取、點擊和模擬輸入，都應透過受控的執行路徑進行。
指南列出具體做法。例如，應用程式禁令可以阻止目標應用程式進入代理的虛擬螢幕；螢幕擷取限制可透過安全顯示圖層實施；輸入限制則可在 Android 輸入管理路徑中阻止模擬操作。
但有一項重要限制：業務意圖限制能否完整落實，取決於目標系統版本。開發者不應只憑代理聲稱已遵守規定，就認定發布、刪除或獎勵限制已獲得技術性落實。
指南建議的基本整合方式，是將靜態政策隨應用程式一併封裝。系統會在安裝或更新應用程式時讀取並快取政策，不必等待應用程式程序執行。開發者也可選擇動態更新，依使用者狀態或業務條件變更規則。這類更新必須使用遞增的版本號；若更新失敗，則須保留先前有效的政策。
稽核記錄可供查閱，但保存期限有限
此協定提供介面，讓應用程式查看已註冊的代理，並查詢與自身應用程式相關的稽核記錄。身分資訊可能包括代理識別碼、套件名稱、簽章、類型、信任狀態和版本。完成註冊不代表代理獲准執行所有業務操作。
稽核設計會同時記錄政策決策與實際執行結果，讓開發者區分「已獲准但執行失敗」和「操作遭拒後仍嘗試繞過」兩種情況。記錄可將代理與工作階段、任務步驟、目標應用程式、頁面、操作類型、政策版本及原因代碼連結起來。
指南要求限制資訊揭露：稽核記錄不應包含原始螢幕截圖、使用者輸入的敏感個人資訊，或完整的介面控制項樹。應用程式只能查詢與自身套件相關的記錄，不得查看其他應用程式的操作紀錄。
記錄存放於裝置上的安全區域，預設保存 60 天。資料庫超過 100 MB，或記錄數量超過 100,000 筆時，也會開始輪替刪除。因此，裝置使用頻繁時，較早的記錄可能在 60 天前就被刪除。實際查詢、匯出和保存能力取決於系統版本。
豆包另曾表示，敏感資訊原則上優先在裝置端處理。團隊稱，必須傳送至雲端的資料會先在本機加密，並在工作階段結束後銷毀相關金鑰。這些是其宣稱採用的設計做法，並非獨立驗證所有已部署流程都符合這些做法。
使用者選擇權與開發者控制權仍有拉鋸
SAEP 提供一套結構化方式，讓開發者拒絕或限制自動化操作，但這仍未解決法律上的爭議：代表使用者行動的助手，是否需要另外取得每個應用程式的許可。協定的操作規則與使用者授權的法律地位，是兩個不同問題。
復旦大學法學院副教授葛江秋認為，代理本質上是協助使用者或代表使用者行動，其行為的法律效果應由使用者承擔。浙江大學光華法學院研究員吳培成支持使用者一次授權的做法，並主張若還要求平台另行許可，將限制日常使用並增加產業成本。
華東政法大學競爭法研究中心執行主任翟巍，從個人資料的可攜權與刪除權等面向，探討應用程式之間的存取問題。中國人民大學法學院副教授黃尹旭也認為，只要代理能準確執行使用者指示，取得有效的系統授權後，就不應再反覆向外部平台申請許可。
這些都是學界觀點，並非法院裁決，也未因此取消開發者設定的限制。實務上，豆包宣布的做法仍尊重明確拒絕。因此，依照助手的操作規則，使用者指示無法凌駕應用程式的禁令。
使用者接下來可以期待什麼
NaviX Ultra 的 12 GB 記憶體、512 GB 儲存空間版本定價為 5,999 元，扣除國家補貼後起售價為 5,499 元，便宜 500 元，約為標價的 8.3%。購買裝置不代表所有應用程式都能使用，或所有任務都能完成。
豆包展示的使用情境呈現了預期體驗：助手利用相機畫面，在指定尺寸和預算範圍內尋找櫥櫃，或根據已知地址安排叫車。這些展示說明的是規劃中的操作流程，並不能證明所有購物或交通服務目前都允許這類操作。
豆包尚未公布 10 月 14 日之後個別應用程式開放存取的詳細時程。已公布的說明也無法確認明確的接受比例、完整開放時間表，或所有受支援版本都能以一致方式落實每項意圖限制。
接下來的實際考驗，是任務中止時，使用者是否能獲得清楚一致的說明：是開發者拒絕、頁面受到保護、系統安全規則介入，還是需要使用者確認。逐步開放擴大了助手可能觸及的範圍，而 SAEP 則界定這個範圍必須止於何處。
重點整理
- 豆包在 30 天公告期結束後，於 10 月 14 日宣布逐步開放第三方應用程式的螢幕自動化操作。
- 明確拒絕開放存取的應用程式，不會由助手代為操作。
- 拒絕名單包括阿里巴巴和騰訊旗下大型服務、銀行、購物平台及其他熱門應用程式。
- 開發者仍可拒絕開放存取，豆包承諾在三個工作天內回應。
- SAEP 支援針對整個應用程式、個別頁面及特定業務操作設定限制。
- 即使應用程式允許自動化操作，仍須符合系統安全要求並取得使用者授權。
- 官方指南指定支援 ObricUI 2.2 以上版本，部分功能則取決於目標系統版本。
- 目前尚未公布個別應用程式的詳細開放時程。
