起點課堂會員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會特權(quán)
個人IP打造特權(quán)
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導(dǎo)直播
12場專業(yè)技能直播
會員專屬社群
榮耀標(biāo)識00后大模型實習(xí)生「扒光」豆包手機！千字實測揭秘
爆火的「豆包手機」，到底藏了什么狠活？一篇熱帖，LLM工程師通過黑盒測試和論文推演，扒出了它的技術(shù)機密。
一部AI手機，火爆全網(wǎng)。
張嘴一句話，它在短短幾秒內(nèi)，就完成了跨APP自動比價下單、回微信、預(yù)約機票、規(guī)劃旅行路線……
海外創(chuàng)業(yè)大佬Taylor Ogan驚呼，「這簡直是另一個DeepSeek時刻！這是世界上第一款真正的智能手機」。
不用多說，它就是最近一機難求的——「豆包手機」。
B站博主「六分超超」體驗后大感驚艷，贊嘆「是今年令自己印象最深的產(chǎn)品」。
更猛的是，即便是在鎖屏的情況下，「豆包手機」也能在后臺絲滑操作。
在「電丸科技AK」的測試中，「豆包手機」不僅可以輕松通過B站「大考」，而且速度奇快——
3秒答完1道題，5分鐘100道題！
那么問題來了，到底是什么黑科技讓「豆包手機」，一夜之間火遍了全世界？
正巧，我們在小紅書上吃瓜的時候，意外發(fā)現(xiàn)了一篇十分有趣的帖子——《我沒有逆向「豆包手機」，但我想說點什么》。
小紅書原帖地址：http://xhslink.com/o/93GCQttMFgO
更新版博客地址：https://www.notion.so/GUI-Agent-2c17a860b5e680e3b6e4efece19d1457
一篇爆帖，工程解密「豆包手機」
這篇帖子的博主「宵逝」，目前是大模型方向的實習(xí)工程師，純從學(xué)術(shù)角度聊了聊感受。
他上手測試后，通過黑盒測試和arXiv邏輯推演，從工程學(xué)角度給出了比較科學(xué)的解釋。
一上來，他便戳中了「豆包手機」的核心：
這不僅僅是一個App，字節(jié)是在Android Framework層做了一套OS級的影子系統(tǒng)。
接下來，博主從以下七個方向，給出了自己的洞察。
1. 兩套模式：System 1（直覺）vs. System 2（推理）
字節(jié)將Agent拆分成兩套棧（Stack）：一個是標(biāo)準(zhǔn)模式，另一個是Pro模式。
這不僅僅是模型大小的區(qū)別，而是兩套完全不同的Pipeline，類似于人類認知中的System 1和System 2。
這里，作者在測試中，設(shè)下一個「陷阱」——
選擇一張京東首頁全屏截圖，給豆包下達指令「點擊搜索按鈕」。
標(biāo)準(zhǔn)模式（快）：Naive Simulation
它主要依賴淺層視覺語言模型（VLM），響應(yīng)極快，體感延遲小于500ms。
他推測，可能使用了Doubao-1.5-UI-TARS蒸餾版，Prompt簡短可通過壓縮IO token實現(xiàn)更快效果。
不過，缺陷在于它的典型「直覺」反應(yīng)，會傻傻地點擊圖片中的按鈕。
Pro模式（慢且魯棒）：深度推理+工具調(diào)用
在同樣的測試中，Pro模式明顯會有一個「暫停+思考」的過程——拒絕點擊，建議切換瀏覽器。
他推測，這可能走的是Doubao-1.5-UI-TARS完整版路線，并且做了更多后訓(xùn)練對齊。
同時，也說明Planner進行了介入，且具備了自我反思能力。
并且，只有在Pro模式下，才能觀察到復(fù)雜的多跳檢索和System API的直接調(diào)用。
補充信息：據(jù)我們最新了解，豆包手機助手使用了UI-TARS 2.0閉源版本，性能大幅優(yōu)于開源版，且針對手機使用場景進行了專門優(yōu)化。
2. 混合感知路由（Hybrid Perception Router）
環(huán)境噪聲的干擾，是當(dāng)前Agent落地的核心挑戰(zhàn)。
XML+Vision動態(tài)路由，不管是UI-TARS的標(biāo)準(zhǔn)版還是Pro，是豆包給出的最直接的解法。
在高德/百度地圖首頁，呈現(xiàn)了多種復(fù)雜圖標(biāo)/道路狀態(tài)情況下，博主要求豆包「點擊深紅色最堵路段旁邊的施工圖標(biāo)」。
這是一個在OpenGL渲染界面中，執(zhí)行復(fù)雜指令的測試場景。
令人欣喜的是，AI優(yōu)雅地完成了這個任務(wù)。
在這種場景下，安卓的「無障礙樹」往往是空的，或只有一個SurfaceView容器，且不包含任何子節(jié)點信息。
這就坐實了，背后視覺路線的存在，因為VLM具備像素級的「開放詞匯定位」的能力。
它真正理解了「深紅色、旁邊、施工圖標(biāo)」，包含了顏色語義、空間關(guān)系、物體檢測復(fù)雜信息。
由此，他推測這可能構(gòu)成「路由動態(tài)」選擇：標(biāo)準(zhǔn)UI走XML，非標(biāo)UI走視覺（截屏但費電）。
3. OS級的虛擬化：并行運行時（Parallel Runtime）
這一點，想必許多上手實操過的網(wǎng)友，都已有深刻的體會——
一邊讓豆包比價購物，另一邊刷視頻、接電話照樣不誤。Agent可以在后臺跑長任務(wù)，即便手機切換到別的應(yīng)用也不會中斷。
博主推測，Agent極有可能跑在「影子屏幕」上，實現(xiàn)了「輸入隔離」：物理屏打電話，邏輯屏在跑Agent。
這種「雙并行宇宙」結(jié)構(gòu)，徹底解決了Agent搶前臺，手機卡死的痛點。
4. 啟發(fā)式工程：提示「等等」
Agent會在每一操作結(jié)束后，無論當(dāng)前頁面渲染多快，都會在系統(tǒng)Prompt中強制引入1000ms~5000ms的固定延遲。
這種設(shè)計，類似于Cursor CLI中「等待輪詢」。
從工程學(xué)角度看，這種做法是為了對抗APP中常見的異步加載/骨架屏，用時間換取「成功率」，妥協(xié)但有效。
5. 隱私設(shè)計的「物理隔離」：任務(wù)層級（Activity Hierarchy）
回到多數(shù)人最關(guān)切的隱私問題，擔(dān)心豆包Agent會24小時錄屏監(jiān)控，但博主測試后發(fā)現(xiàn)——
視覺管道是過濾的。
若是豆包真的在用VLM分析屏幕，恐怕手機早就燙到不能用了。
他開啟了B站畫中畫模式，然后讓Agent操作主屏，中途再截屏，結(jié)果發(fā)現(xiàn)，AI截到的畫面只有主應(yīng)用的界面，完全沒有懸浮窗。
這證明了，它不讀物理屏幕輸出流，而是基于「任務(wù)層級」針對性抓取。也就是說，從物理層面上，豆包隔離了視頻通話、金融APP安全鍵盤，是一種精心設(shè)計的安全功能。
博主認為，豆包手機助手的代碼邏輯是安全、可靠的設(shè)計，其包含了隔離機制、熔斷策略和本地化處理。
代碼可以透明，但編寫與掌管代碼的人呢？這種擔(dān)憂，可以理解。
但這個問題本真難以徹底解決。在博主看來，如果Agent可以代替自己解決80%日?，嵤?，是可以交出經(jīng)脫敏、不涉及核心隱私的數(shù)據(jù)。
6. 記憶與工具使用：關(guān)于MCP協(xié)議的猜想
在Pro模式下，數(shù)據(jù)的調(diào)用精準(zhǔn)。
工具調(diào)用架構(gòu)
測試中，博主給出一個模糊指令「驗證碼有什么數(shù)學(xué)特征」，Agent沒有暴力做OCR全屏，而是Client向Server發(fā)起請求，整個系統(tǒng)授權(quán)部分，可能形成了一個RAG-MCP。
列表記憶（Sliding Window）
在滾動長列表（List View）時，Agent行為非常像E2E測試框架Playwright： 滾屏→DOM Diff→提取增量信息→拼接。
這種方式，解決了跨屏上下文的問題。
7. 韌性（Resilience）
最后一個測試中，博主讓Agent讀取Outlook最新郵件，結(jié)果失敗。
此時，Agent沒有報錯退出，而是自動降級讀取第二封，并嘗試提取第一封在列表頁的預(yù)覽信息，然后做出合并匯報。
這說明了，它的規(guī)劃器關(guān)注的是「任務(wù)目標(biāo)」，而不是規(guī)定的操作序列。這種動態(tài)規(guī)劃的能力，才是推理應(yīng)做的事兒。
博主體驗后道出了真實的感受——它讓我真切地感受到「推理」走出了論文。
當(dāng)看到Agent在Outlook閃退后，自行思考片刻，轉(zhuǎn)而讀取郵件列表預(yù)覽時，那種感覺很奇妙。
它不再是一個機械執(zhí)行click(x, y) 的簡單腳本，而是開始展現(xiàn)出某種韌性。
他表示，對于做研究的人來說，這臺手機更像一份來自工業(yè)界的SOTA級Demo。它并不完美，但真正跑起來了。
總而言之，「豆包手機」在速度上做了很多妥協(xié)，但從架構(gòu)角度看，可能是目前移動手機最靠譜的解法。
從博主的這篇分析中，讓我們對「豆包手機」背后工程實現(xiàn)獲得了關(guān)鍵一瞥。
當(dāng)我們再扒開字節(jié)開源庫，發(fā)現(xiàn)「豆包手機」助手GUI操作能力，已經(jīng)通過UI-TARS模型的開源版本開放給業(yè)界。
開源地址：https://github.com/bytedance/UI-TARS
簡單來說，UI-TARS是一個將屏幕視覺理解、邏輯推理、界面元素定位和操作整合在一個模型中。
它能實現(xiàn)搜集信息、處理文檔、訂票、比價等各種復(fù)雜操作，甚至能在游戲中進行思考和行動。
值得一提的是，UI-TARS的更新速度超快，光今年一年就迭代了三次：
2025年1月，第一代UI-TARS；
2025年4月，UI-TARS-1.5；
2025年9月，UI-TARS-2。
GUI Agent覺醒，「努比豆」重寫未來
豆包AI助手，是當(dāng)前GUI Agent浪潮的典型代表。
GUI Agent代表著AI與人類交互的「新前沿」，可以讓模型看屏如人，操作如手。
在不需要切換API的情況下，可自動化一切GUI軟件。
在早期，API和GUI是分化的兩派。比如OpenAI Tools提供的API速度快，但不適應(yīng)動態(tài)的UI。
傳統(tǒng)的GUI雖可視化強，但對于大模型來說，描述UI信息噪聲大，理解成本高，還不穩(wěn)定。
因此，早期階段的LLM要么走API路線，要么走GUI路線，難以統(tǒng)一。
而端側(cè)小模型的出現(xiàn)，讓GUI可以被結(jié)構(gòu)化理解，再與API融合，就出現(xiàn)了「統(tǒng)一的智能交互層」。
幾個月前，蘋果團隊曾發(fā)布了Ferret-UI Lite，一款GUI Agent小模型，實現(xiàn)了精準(zhǔn)的控件定位能力。
論文地址：https://arxiv.org/pdf/2509.26539
真正讓GUI Agent走向大眾的，還是得益于近兩年，多模態(tài)原生大模型躍遷式的迭代升級。
諸如Gemini 3、GPT-5.1等頂尖AI模型，都在朝著多模態(tài)方向發(fā)展。
這意味著，LLM不僅可以看文字，還能看懂圖片、視頻、UI元素。同時，LLM具備了更長上下文，可以記住跨越多步的任務(wù)。
大模型Agent開始用多模態(tài)感知界面，再配上RL，可以在GUI、網(wǎng)頁等真實環(huán)境中，操作游刃有余。
在題為「Large Language Model-Brained GUI Agents: A Survey」的論文中，團隊做了一個直觀的GUI Agent流程：
Agent在接收指令后，會在多個應(yīng)用程序中無縫協(xié)作。
它會從文檔中提取信息，在Photos中觀察內(nèi)容，在瀏覽器中總結(jié)網(wǎng)頁，在Adobe Acrobat讀取PDF，并在PPT中創(chuàng)建文件，最后通過Teams發(fā)送。
論文地址：https://arxiv.org/pdf/2411.18279
2023年之前，以O(shè)penAI WebGPT為代表。從2023年之后，類似的GUI Agent全面爆發(fā)。
這一年最具代表性，當(dāng)屬OpenAI Operator和字節(jié)UI-TARS。
真正高階的基操，是把Agent深入嵌入OS系統(tǒng)級的能力。
「豆包手機」便可以照見行業(yè)脈絡(luò)，讓Agent從可操作界面，邁向了深度的系統(tǒng)集成。
這種OS級的植入，必須處理巨大的隱私、安全、權(quán)限問題，這是系統(tǒng)級GUI Agent向前邁進不可避免的陣痛。
字節(jié)雖未明確具體工程細節(jié)，從博主「疊甲」分析中，可以得知他們采用了「任務(wù)級過濾」（Activity-level Filtering）機制。
也就是說，系統(tǒng)會把每一次Agent行為抽象成一個「任務(wù)」，進行逐一過濾。
因此，Agent截圖才不會截到「畫中畫」浮窗。本質(zhì)上，這就像是OS級的權(quán)限中間層。
Hugging Face亞太生態(tài)負責(zé)人Tiezhen Wang點評，它證明了手機使用可以成為OS級原生能力，并將定義下一代AI手機
「豆包手機」的出現(xiàn)，證明了OS級可行性，真正定義了AI原生手機的形態(tài)。
昔日針鋒相對的宿敵，老羅和王自如在「豆包手機」上，立場罕見地一致。
不得不說，在GUI Agent時代，「豆包手機」才是劃時代的標(biāo)志。
參考資料：
http://xhslink.com/o/93GCQttMFgO ?
https://www.notion.so/GUI-Agent-2c17a860b5e680e3b6e4efece19d1457
新智元報道 編輯：桃子 好困
本文由人人都是產(chǎn)品經(jīng)理作者【新智元】，微信公眾號：【新智元】，原創(chuàng)/授權(quán) 發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于 CC0 協(xié)議。
- 目前還沒評論，等你發(fā)揮！
