一夜間，豆包手機助手變成「豆包手機，住手！」

前段時間，字節跳動豆包團隊和中興合作，發布了搭載豆包手機助手技術預覽版的手機——努比亞 M153。在 M153 上，豆包團隊基于其 GUI-Agent 的能力，打造了一系列「替用戶操作手機」的功能，讓我們有機會在 2025 年一覽未來 AI 手機應該有的樣子。

豆包手機助手

但很快，問題就出現了。有用戶反饋稱，豆包手機助手在某些金融 App 里會觸發風險提示，指出手機當前開啟了「屏幕共享」「無障礙」等服務，要求用戶注意資金安全；部分 App 更是因觸發風控直接停用了相關服務。

隨后，微信確認了這一點，表示沒有對豆包做任何特殊攔截，用戶遇到的情況更像是觸發了既有的通用風控策略。豆包方面隨即下線了相關場景的操作能力，并對受影響用戶開啟解封流程，同時進一步公開說明其權限調用方式、數據處理方式和安全邊界，重申不存在任何黑客行為或隱私侵入。

至于外界爭議最多的 INJECT_EVENTS 權限，豆包也給出了正面回應：

INJECT_EVENTS 確實是系統級權限，技術實現依賴 Android 系統級權限，有更嚴格的使用限制。擁有該權限許可，相關產品才能跨屏、跨應用來模擬點擊事件，完成用戶操作手機的任務需求。
豆包手機助手需要用戶主動授權，才可以調用該權限，使用操作手機功能。該權限的使用，我們也在權限清單中進行了明確的披露。據我們了解，目前行業的AI助手，均需要使用該權限（或與其類似的無障礙權限）才能提供操作手機的服務。

從雷科技的角度看，豆包這一解釋確實合情合理；這種不避諱關鍵爭議的做法，也值得肯定。但在雷科技看來，這場關于 AI 手機助手權限的討論，雖然由風控誤傷引發，但也是 AI 手機行業發展必將面臨的問題；處于風暴中心的豆包，也只是把這個需要行業共同打磨的細節，提前帶到了公眾面前。

AI Agent 的三部曲

要理解這場爭議背后的行業背景，我們必須先理解 AI 是怎么「用」手機 App 的。從技術的角度看，「AI 操作 App」可以拆解成兩個步驟：

1. 讓 AI 看懂 App；
2. 讓 AI 操作 App。

但問題是，Android 系統原本從未設想過讓「一個智能體來控制另一個 App」。為了讓 AI 能從系統（而不是 App）的層面控制其他 App，手機行業提出了三種不同的「AI 操作」路線。

第一條路線是基于 App 無障礙標簽和 Android 系統無障礙服務，打造的「模擬用戶」操作路線。我們知道，現代智能手機都有無障礙服務，比如為視障群體準備的文字標簽服務：開發者在開發 App 時，會為每一個按鈕添加「無障礙標簽」；手機開啟無障礙讀屏功能后，手機系統會讀取「無障礙標簽」并朗讀對應內容，讓視障用戶知道當前選中的按鈕的作用。

smartisan.com

AI Agent 只要讀取 App 內部的標簽結構，就能理解軟件界面元素、知道每個按鈕的作用；看懂 App 后，AI Agent 再利用無障礙服務的模擬觸控功能（手機鍵精靈的同款原理），就能自主操作 App。

但我們知道，國內移動互聯網發展日新月異，主流 App 每隔幾周就要上線一個新功能，而無障礙標簽往往是開發流程里最容易被忽略的步驟——很殘酷的現實是，無障礙群體在互聯網幾乎沒有聲量。這導致某些頁面、按鈕可能根本沒有標簽，或是只有「按鈕」「窗口」這種幾乎沒有意義的字樣。面對這樣的標簽，即使再聰明的 AI 也無能為力。

既然糟糕的無障礙支持讓 AI 搞不懂 App 結構，那為什么不讓 AI 像人一樣「直接看屏幕」呢？這也引出了 AI 交互的第二條路線：AI 通過系統提供的屏幕捕捉能力，實時獲取手機屏幕當前的畫面，然后用視覺大模型去理解畫面中每個元素的功能含義。

理解當前屏幕內容后，AI Agent 會利用無障礙（模擬點擊）或 INJECT_EVENTS （應用注入觸發）來操作 App，把 AI 鏈路跑通。豆包手機助手此次引起的爭議也在這個「INJECT_EVENTS」上。

豆包手機助手

剛剛提到，無障礙的點擊本質是「AI 代點」，但無障礙并不能穩定覆蓋所有交互方式，很多界面仍需要更底層的事件注入。在這一場景下，INJECT_EVENTS 不是「破解 App」，而是用一種更底層、更原生的交互模擬方式，讓 AI 能在任何 App 上執行更完整的操作。就目前 Android 系統本身的發展情況來說，「豆包路線」也是現階段 Android 體系里唯一能讓 AI 真正操作 App 的路線。

但歸根結底，剛剛提到的兩條技術路線，本質仍是讓 AI 模擬人的操作；而真正的 AI 手機，應該去掉低效的圖形界面（GUI）中間層，讓 AI 直接調用 App 的功能組件。在這種理念下，第三條路線——MCP 路線誕生了。

不了解 AI 的朋友對 MCP（Model Context Protocol，模型上下文協議）可能比較陌生。簡單來說，MCP 是一種標準化的能力協議，它能「對齊」App 與 App 之間的功能，讓 App 功能（組件）變成可被 AI 跨應用調用的模塊。

modelcontextprotocol.io

舉個例子，如果我們把點餐功能封裝成「能力組件」，叫外賣時 AI 就不再需要靠圖形或文字去理解商家菜單里的選項，可以直接從組件后臺中找到「隆江豬腳飯」的選項并添加到購物車里，再調用支付的 MCP 模塊直接完成支付。

「豆包路線」為什么更領先？

事實上，在雷科技看來，豆包選擇的「GUI-Agent + INJECT_EVENTS」方案，確實也是現階段 AI Agent 體驗最好、最完善的技術路徑。不同于讀取無障礙標簽的「路線一」，GUI-Agent 能充分發揮大模型在多模態方面的優勢，吃到國內 AI 模型飛速迭代的技術紅利。

和 MCP 路線相比，「豆包路線」也不需要苦等第三方 App 的 MCP 支持：要知道 MCP 允許 AI 繞過 App 的圖形界面，意義等同于讓 App 放棄自己的流量入口。即使我們都知道 MCP 方案必然成為主流，但 GUI 到 MCP 的轉化注定是一個漫長的過程。可以肯定的是，大量 App 會在相當長的一段時間內維持傳統形態，GUI-Agent 仍無法取代。

除此之外，豆包的 GUI-Agent 雖然被視為「過渡方案」，但它也提前為 MCP 時代打好地基。無論未來標準協議多么成熟，AI 想要可靠地完成任務，都必須先學會在真實 App 環境中運行，而其中的操作路徑和數據傳遞算法只能從 GUI 操作里優化出來，而不是從 API 文檔里學出來。

可以說，豆包通過 GUI-Agent 大規模積累的經驗，必將成為豆包在 MCP 時代領先的關鍵。

MCP 才是 AI 手機的最優解？

當然了，就像剛剛提到的那樣，盡管現階段 MCP 生態的發展還處于初期階段，GUI-Agent 依舊是 AI 手機的主流方案；但就像觸屏手機用更豐富的交互方式取代按鍵手機、更通用的 USB-C 統一多種結構那樣，可以肯定的是，體驗更好、潛力更大的 MCP 方案，未來必然會取代 GUI-Agent 方案，成為 AI 時代的「默認路線」。

而隨著「MCP 時代」的到來，AI 手機與 App 的線性關系也將發生改變：App 將直接向 AI 暴露結構化的能力組件，系統也能對每一次調用進行統一的權限管理，其安全性反而比現在的「屏幕捕捉+GUI Agent+替代點擊」還要高。

豆包手機助手

與此同時，MCP 的開放性也讓跨 App AI 協作成為可能。現階段不同 App 之間的聯動還離不開鏈接跳轉、剪貼板數據寄存等「歪門邪道」，而在 MCP 時代，AI 可以在同一上下文窗口中調用不同 App 的能力，實現真正意義的「流程化」。

12 月 4 日，羅永浩在微博指出「技術革命是誰都攔不住的」，同時也對字節在 GUI-Agent 路線邁出的這一步點贊：「AI 助手一定會遍地開花，我們的生活也會完全離不開它，將來的人們會記住這歷史性的一天。」

微博

就目前的情況來看，豆包手機助手已經讓我們「預覽」了未來 AI 手機的樣子；而即將到來的 2026 年，AI 手機行業必然會加大在 GUI-Agent 賽道的投入，用實打實的市場需求推動 App 生態的 MCP 轉型進程。

從這個角度來看，豆包手機助手，才是開啟 AI 手機黃金時代的鑰匙。

CES2026開幕在即！（1月6日-1月9日）
作為中國報道科技展會最悠久、最深入、最專業的新媒體，雷科技CES2026報道團正在進行緊張的前期籌備。屆時雷科技將派出史上最大規模的CES報道團，并由雷科技創始人兼總編輯羅超帶隊，對CES2026進行一線、專業和立體報道，敬請期待！