最近很多團(tuán)隊開始做一件事把 AI Agent 接到一臺真實(shí)的手機(jī)上讓它像人一樣打開 App、點(diǎn)按鈕、填信息、下單、發(fā)消息。不是模擬器不是純接口調(diào)用是實(shí)實(shí)在在握住一臺手機(jī)操作。這件事在近兩年突然火起來原因很直接——模型能看懂屏幕了。過去移動端自動化只能靠控件定位和固定坐標(biāo)現(xiàn)在 Agent 可以直接“看”界面但這不意味著簡單。移動端自動化原本是測試工程師的主場規(guī)則清晰、環(huán)境受控AI Agent 一進(jìn)場把問題變成了“視覺理解 意圖推理 動作控制 失敗恢復(fù)”的綜合工程。這篇文章不聊概念直接拆移動端 Agent 操作真實(shí)手機(jī)時最值得關(guān)注的三個新考點(diǎn)從控件依賴到像素級理解、長任務(wù)的狀態(tài)恢復(fù)、異常處理與安全邊界。1. 為什么移動端自動化突然被Agent盯上了1.1 傳統(tǒng)自動化腳本的“玻璃天花板”先看看以前怎么操作手機(jī)。主流做法靠控件樹和坐標(biāo)兩種?？丶浞桨感枰?App 暴露界面層級測試框架通過選擇器找按鈕、輸入框坐標(biāo)方案更加粗暴記錄“在這個分辨率下點(diǎn)擊某個固定位置”。兩者都有一個共同點(diǎn)一旦界面重新布局、圖片素材替換、分辨率變化腳本就崩。App 版本更新后測試工程師要花大量時間修定位符這就是圈內(nèi)常說的“自動化維護(hù)地獄”。更麻煩的是很多界面根本不給你控件樹。比如某些用自繪引擎或游戲引擎開發(fā)的 App整個屏幕在系統(tǒng)看來就是一張圖傳統(tǒng)框架完全沒轍。這種情況下測試只能靠 OCR 識別文字位置再配合坐標(biāo)點(diǎn)擊準(zhǔn)確率全靠運(yùn)氣。傳統(tǒng)自動化的天花板在于它只能執(zhí)行“已經(jīng)被定義好的操作”不能理解“為什么操作”更無法處理預(yù)期之外的情況。彈窗出現(xiàn)、網(wǎng)絡(luò)延遲、推薦位變化任何一點(diǎn)意外都會讓腳本卡死。這也是為什么過去移動端自動化主要用于回歸測試很少用于復(fù)雜業(yè)務(wù)操作。1.2 AI Agent帶來的三個能力躍遷AI Agent 進(jìn)入移動端自動化后情況發(fā)生了質(zhì)變。第一是視覺理解能力Agent 通過截圖就能知道屏幕上有什么、按鈕在哪、狀態(tài)是什么不需要控件樹也不需要預(yù)先錄制坐標(biāo)。第二是意圖推理能力你給它一句“幫我把購物車?yán)镒钯F的商品刪掉”它能拆解成“打開購物車→識別商品列表→比較價格→找到最貴→執(zhí)行刪除”這樣的多步計劃并且在執(zhí)行中根據(jù)界面反饋調(diào)整。第三是容錯能力點(diǎn)擊沒反應(yīng)、頁面加載慢、彈窗出現(xiàn)Agent 可以觀察結(jié)果并重試而不是像老腳本那樣直接報錯退出。這三個能力疊加移動端自動化從“工具”變成了“操作者”。你可以讓 Agent 代做標(biāo)注數(shù)據(jù)、填寫表單、完成日常任務(wù)甚至探索 App 的未知功能。比起以前寫幾百行腳本用自然語言交付任務(wù)的方式把使用門檻拉低了一個數(shù)量級。1.3 考點(diǎn)一從控件依賴到像素級理解第一個新考點(diǎn)也是最核心的變化Agent 操作手機(jī)不再依賴控件而是直接理解像素。這個轉(zhuǎn)變帶來不少新問題。像素級理解意味著 Agent 需要回答幾個問題界面里有哪些可操作元素每個元素是什么類型它們的位置在哪哪些元素當(dāng)前可用哪些是廣告或裝飾如果模型把“廣告關(guān)閉按鈕”當(dāng)成“跳過頭像”就會做出一連串錯誤操作。實(shí)際工程中通用視覺語言模型對復(fù)雜界面的“元素粒度”把握并不穩(wěn)定。它可能識別出頁面中央有一個“確認(rèn)支付”按鈕卻分不清這個按鈕是置灰還是可點(diǎn)可能把彈出框里的“取消”看成頁面的主按鈕。這時候通常需要補(bǔ)充一個專門的 UI 元素識別層用目標(biāo)檢測或 OCR 先完成細(xì)粒度元素提取再把結(jié)構(gòu)化元素列表喂給 Agent 做決策而不是讓大模型直接對著原始像素推理。這一層看起來多余實(shí)際上是整個方案的穩(wěn)定基石。2. 移動端Agent的核心技術(shù)拆解視覺、動作與反饋閉環(huán)2.1 視覺感知截圖之后AI到底在看什么大多數(shù)移動端 Agent 基于“截圖—理解—行動”循環(huán)工作。第一步很簡單通過系統(tǒng)截圖拿到當(dāng)前屏幕的圖像。第二步最復(fù)雜模型需要從圖里提取三類信息空間信息即每個可交互元素在屏幕上的坐標(biāo)區(qū)域語義信息即這個元素是什么比如“返回按鈕”“搜索框”“商品卡片的加購按鈕”狀態(tài)信息即元素當(dāng)前是什么狀態(tài)比如選中、禁用、加載中、已選規(guī)格。這需要把通用視覺語言模型和一個細(xì)粒度 UI 識別模型配合使用。通用模型負(fù)責(zé)理解全局語義判斷當(dāng)前頁面屬于哪個流程階段細(xì)粒度模型負(fù)責(zé)把元素框出來、打上標(biāo)簽。兩者結(jié)果合并后Agent 才做出行動決策。這里有個容易被忽略的細(xì)節(jié)截圖分辨率必須與操作坐標(biāo)系嚴(yán)格對齊。很多手機(jī)默認(rèn)開啟了屏幕縮放或系統(tǒng) UI 調(diào)整截圖尺寸和實(shí)際觸摸坐標(biāo)之間不是簡單的等比關(guān)系。有的 Agent 在開發(fā)機(jī)上一切正常換到真機(jī)上點(diǎn)擊位置全部偏移原因就是忽略了系統(tǒng)顯示區(qū)域和截圖區(qū)域的坐標(biāo)換算。2.2 動作空間不是只有“點(diǎn)擊”和“滑動”Agent 能執(zhí)行的動作決定了它有多大本事。基礎(chǔ)動作包括點(diǎn)擊、長按、滑動、輸入文字、返回桌面、切換 App 等。這套動作的實(shí)現(xiàn)方式通常有兩種一種是通過系統(tǒng)級調(diào)試通道注入觸摸事件另一種是借助無障礙服務(wù)發(fā)送手勢。前者需要開啟開發(fā)者調(diào)試模式對絕大多數(shù)安卓設(shè)備有效后者不需要連接電腦但需要用戶在系統(tǒng)設(shè)置里授權(quán)且部分設(shè)備上性能受限。除了基礎(chǔ)動作真正高級的動作是“復(fù)合動作”。比如“在輸入框里輸入一段文本并觸發(fā)搜索”Agent 需要先點(diǎn)擊輸入框喚出軟鍵盤再逐字符輸入再點(diǎn)擊搜索鍵。這中間任何一步被輸入法的聯(lián)想詞攔截都會導(dǎo)致結(jié)果偏移。工程上通常會關(guān)閉或繞過輸入法聯(lián)想、禁用系統(tǒng)動畫甚至直接通過剪切板粘貼文本代替模擬鍵入以減少不確定性。動作層最忌諱的是“只會點(diǎn)”。很多真實(shí)任務(wù)需要雙指縮放、長按菜單、跨應(yīng)用拖拽如果 Agent 的動作空間只有點(diǎn)擊和滑動很多任務(wù)根本完不成。實(shí)現(xiàn)動作的時候還要考慮物理約束兩次點(diǎn)擊之間的最小間隔、滑動速度過快導(dǎo)致系統(tǒng)識別為快速滑動、長按觸發(fā)原生菜單等。2.3 狀態(tài)評估怎么判斷這一步真的做對了Agent 每一步操作之后必須判斷這次操作是否達(dá)到預(yù)期否則它可能在錯誤道路上越走越遠(yuǎn)。常用的校驗(yàn)手段有四種UI 文本斷言檢查頁面上是否出現(xiàn)預(yù)期的文字控件樹斷言檢查某個節(jié)點(diǎn)的屬性變化圖像對比對比操作前后的截圖判斷界面是否產(chǎn)生預(yù)期變化OCR/語義校驗(yàn)讀取界面上的關(guān)鍵信息判斷業(yè)務(wù)流程是否推進(jìn)。實(shí)際項(xiàng)目中單一校驗(yàn)手段經(jīng)常不夠。比如點(diǎn)擊“提交訂單”后屏幕上同時出現(xiàn)“訂單提交成功”和“支付頁面”Agent 如果只認(rèn)“成功”字樣可能會忽略后續(xù)支付步驟反過來如果網(wǎng)絡(luò)慢頁面還沒加載出來截圖里沒有“成功”字樣Agent 可能誤判失敗而重復(fù)提交。更穩(wěn)妥的做法是“后端狀態(tài) 界面狀態(tài)”雙重確認(rèn)既能查接口返回又看界面反饋兩邊都對才算成功。這里要提一個工程技巧給每次截圖蓋一個時間戳水印或者在日志里記錄操作前的狀態(tài)哈希。排查問題時能清楚知道每一步操作時屏幕真實(shí)長什么樣而不是依靠 Agent 事后回憶。2.4 考點(diǎn)二長任務(wù)的狀態(tài)記憶與中途恢復(fù)第二個新考點(diǎn)是長任務(wù)的狀態(tài)管理。移動端任務(wù)天然又長又碎比如“對比三家公司的小程序里同一款商品的價格然后告訴我哪家最便宜”。Agent 可能需要切換多個 App、回到桌面、再進(jìn)入另一個 App中間還可能被電話、通知、系統(tǒng)彈窗打斷。一旦任務(wù)超過五六步模型自身的上下文就開始吃緊。保持“目標(biāo)不變”比“記住每一步做了什么”更重要。工程上需要引入任務(wù)狀態(tài)機(jī)把大任務(wù)拆成階段每個階段遷移必須滿足前置條件把 Agent 的短期記憶放在獨(dú)立模塊里而不是全部塞進(jìn)模型上下文。很多 Agent 走到一半突然開始重復(fù)同一操作就是因?yàn)椤爱?dāng)前處于哪個階段”這個關(guān)鍵狀態(tài)丟失了。中途恢復(fù)是最容易翻車的場景。App 殺掉重進(jìn)后回到首頁Agent 的下一步計劃卻還停留在“上一個 App 的第三頁”這時候必須重新做視覺定位再決定動作。更嚴(yán)重的是某些任務(wù)本身帶有破壞性比如支付、刪除、發(fā)送消息一旦任務(wù)中斷又重啟可能導(dǎo)致重復(fù)執(zhí)行。這類任務(wù)必須設(shè)計冪等控制執(zhí)行前記錄任務(wù)的唯一 ID每次執(zhí)行前檢查是否已經(jīng)完成絕不盲目重復(fù)。3. 從Demo到可用移動端Agent的真實(shí)工程實(shí)踐3.1 環(huán)境準(zhǔn)備讓Agent拿到“手”和“眼睛”在真機(jī)上跑 Agent第一步是準(zhǔn)備一套可復(fù)現(xiàn)的運(yùn)行環(huán)境。硬件方面選一臺測試機(jī)最好是系統(tǒng)原生、沒有多余定制、分辨率固定的安卓設(shè)備開發(fā)階段建議固定豎屏、關(guān)閉自動旋轉(zhuǎn)、關(guān)閉系統(tǒng)字體縮放減少變量。連接方式上我習(xí)慣先通過無線調(diào)試或 USB 連接手機(jī)啟用開發(fā)者選項(xiàng)。為了讓 Agent 能模擬點(diǎn)擊還需要打開無障礙服務(wù)或調(diào)試通道的注入權(quán)限。注意系統(tǒng)級調(diào)試通道在部分高版本系統(tǒng)上需要額外配置否則截圖正常但點(diǎn)擊事件發(fā)不進(jìn)去。網(wǎng)絡(luò)方面測試機(jī)建議連一個可控網(wǎng)絡(luò)環(huán)境關(guān)閉所有系統(tǒng)更新的自動下載。手機(jī)里安裝目標(biāo) App建議固定版本不要開自動更新否則某一次任務(wù)跑到一半 App 升級了界面全變Agent 直接抓瞎。還需要準(zhǔn)備一個“狀態(tài)快照”機(jī)制任務(wù)開始前記錄當(dāng)前前臺 App、系統(tǒng)設(shè)置項(xiàng)、App 登錄態(tài)任務(wù)結(jié)束后恢復(fù)現(xiàn)場。沒有這套機(jī)制跑十次任務(wù)能八次撞上上一次的遺留狀態(tài)。3.2 任務(wù)拆解實(shí)例讓Agent完成一次外賣下單拿一個高頻演示場景來說讓 Agent 在某個外賣 App 里自動完成一次下單。注意這只是一個演示級任務(wù)真實(shí)生產(chǎn)環(huán)境必須增加人工確認(rèn)環(huán)節(jié)后面我會講安全邊界。把任務(wù)拆成六個階段第一打開 App等待首頁加載完成判斷登錄態(tài)第二在搜索框輸入“牛肉面”執(zhí)行搜索第三在結(jié)果列表里選擇評分最高的一家店進(jìn)入店鋪頁第四選擇第一個商品點(diǎn)擊加入購物車必要時選擇規(guī)格第五進(jìn)入購物車核對商品點(diǎn)擊結(jié)算第六在確認(rèn)訂單頁停留不實(shí)際支付輸出當(dāng)前訂單金額與收貨地址。每階段都有明確的完成判據(jù)。階段三的判據(jù)可以是“頁面標(biāo)題包含店鋪名”階段四的判據(jù)可以是“購物車角標(biāo)數(shù)字加一”。這些判據(jù)要寫進(jìn) Agent 的指令里否則模型會自由發(fā)揮比如搜索詞變了、商家選錯了、商品重復(fù)加購。這里不要追求“全自動代客下單”至少現(xiàn)階段不要。把任務(wù)邊界劃定到“完成支付前一步”既能驗(yàn)證整套自動化能力又不會因?yàn)檎`操作造成真實(shí)損失。3.3 給Agent寫操作說明書提示詞與參數(shù)設(shè)計Agent 不會平白無故知道你的業(yè)務(wù)規(guī)則需要一份“操作說明書”。這不是簡單一句“幫我去買個東西”而是要寫清楚任務(wù)目標(biāo)是什么、邊界在哪里、每步的判據(jù)是什么、遇到哪些情況必須停下來求助。一個有效的操作指令通常包含任務(wù)目標(biāo)必須明確、可驗(yàn)證比如“在某平臺找到評分最高的耳機(jī)截圖保存”邊界約束比如“不修改收貨地址”“不點(diǎn)擊任何廣告”“不安裝任何應(yīng)用”分階段指令每個階段給出輸入、動作、期望輸出、成功判據(jù)停止條件出現(xiàn)什么情況必須中止并報告比如“彈出了登錄框”“找不到商品”“余額不足”。參數(shù)方面需要配置每步操作的等待時間、失敗重試次數(shù)、單任務(wù)最大操作步數(shù)。等待時間太短頁面沒加載出來就開始下一步太長任務(wù)效率極低。我一般把頁面加載等待設(shè)為 5 到 8 秒每次截圖后給模型 2 到 3 秒推理緩沖重試次數(shù)不超過 3 次。最大操作步數(shù)建議設(shè)置為人工預(yù)期步數(shù)的 1.5 倍超過即判定異常。3.4 考點(diǎn)三異常處理與安全邊界第三個新考點(diǎn)也是最容易被忽略的一點(diǎn)Agent 操作真實(shí)手機(jī)時后果是真實(shí)的。點(diǎn)擊“支付”真的會扣錢點(diǎn)擊“刪除”真的會刪數(shù)據(jù)。安全邊界必須在架構(gòu)層強(qiáng)制約束而不是指望模型自覺。我建議至少做三件事。第一高風(fēng)險動作隔離涉及支付、刪除、發(fā)送消息、修改隱私設(shè)置的操作一律要求二次人工確認(rèn)Agent 只能做到“最后一步之前”然后在界面上高亮提示等待人類確認(rèn)。第二操作白名單在系統(tǒng)層面設(shè)置 Agent 可訪問的 App 列表不在白名單里的應(yīng)用一律不允許喚起防止 Agent 被惡意跳轉(zhuǎn)帶到奇怪的地方。第三預(yù)算與資源控制限制每輪任務(wù)的最大執(zhí)行時間、最大操作步數(shù)、最大網(wǎng)絡(luò)請求量超過閾值強(qiáng)制中止并生成報告。還有一個隱蔽風(fēng)險Agent 可能在任務(wù)過程中讀取到用戶隱私信息。比如執(zhí)行“查看訂單詳情”時屏幕上可能包含手機(jī)號、地址等敏感數(shù)據(jù)。工程上要建立敏感信息脫敏機(jī)制在截圖進(jìn)入模型前對手機(jī)號、姓名、驗(yàn)證碼區(qū)域做遮罩處理日志里也不得記錄明文敏感字段。這個約束不僅僅是為了合規(guī)更是為了避免在調(diào)試時把用戶隱私留在日志文件里。4. 踩坑與排查實(shí)錄移動端Agent最常見的5個問題4.1 坐標(biāo)偏差與分辨率適配真機(jī)環(huán)境下的第一個大坑是坐標(biāo)偏差。常見場景開發(fā)時用一臺設(shè)備調(diào)試Agent 所有動作都準(zhǔn)確換到另一臺分辨率不同的設(shè)備上點(diǎn)擊全部歪掉。原因一般是兩個坐標(biāo)系沒對齊截圖使用的是屏幕像素坐標(biāo)而動作注入使用的是設(shè)備邏輯坐標(biāo)不同設(shè)備對系統(tǒng)縮放的處理又不一樣。排查方法很直接在屏幕上人為放置幾個標(biāo)記點(diǎn)通過 Agent 截圖獲取坐標(biāo)再手動觸摸同一位置對比兩者偏差。如果偏差是線性的多半是縮放比例問題如果偏移只出現(xiàn)在屏幕下半部分要考慮軟鍵盤和系統(tǒng)導(dǎo)航欄的占位影響。解決方案是在框架層固定一個“參考分辨率”所有截圖先縮放到參考分辨率再做識別所有動作坐標(biāo)再換算回實(shí)際設(shè)備坐標(biāo)。不要讓 Agent 直接拿原始截圖尺寸做空間推理這是我在幾個項(xiàng)目里反復(fù)踩坑后總結(jié)出的第一條經(jīng)驗(yàn)。4.2 彈窗、權(quán)限請求與系統(tǒng)干擾真機(jī)操作的最大干擾源是彈窗。應(yīng)用內(nèi)彈窗包括廣告、升級提示、新功能引導(dǎo)、系統(tǒng)權(quán)限申請。Agent 識別到“跳過”“以后再說”這類文字后經(jīng)常出現(xiàn)兩種情況找不到按鈕的準(zhǔn)確位置或者誤把“關(guān)閉廣告”點(diǎn)成“點(diǎn)擊廣告”。系統(tǒng)級的干擾更棘手比如低電量彈窗、來電通知、SIM 卡錯誤提示。這些彈窗樣式不一樣坐標(biāo)不固定通用模型不一定認(rèn)識。我的處理方式是把彈窗檢測做成獨(dú)立的預(yù)處理模塊任務(wù)執(zhí)行前和每步操作后都做一次“前臺 App 檢測 窗口層級檢測”一旦發(fā)現(xiàn)當(dāng)前顯示的不是目標(biāo) App就進(jìn)入彈窗處理流程優(yōu)先嘗試點(diǎn)擊明確的安全關(guān)閉按鈕無法識別時直接終止任務(wù)而不是亂點(diǎn)。在實(shí)際跑任務(wù)時我會提前準(zhǔn)備好一批常見彈窗截圖用于回歸測試彈窗處理邏輯。彈窗處理不準(zhǔn)Agent 后面所有動作都白做。這個模塊一定要排在模型決策之前而不是讓模型臨時判斷要不要關(guān)掉彈窗。4.3 模型誤判界面對了不代表任務(wù)對了Agent 看似在執(zhí)行實(shí)際可能完全跑偏。典型表現(xiàn)每一步都能給出一個合理的動作但幾個步驟之后離目標(biāo)越來越遠(yuǎn)。問題通常出在“局部正確全局錯誤”——模型每一步都基于當(dāng)前截圖做決策卻沒有把“最終目標(biāo)”放在足夠高的優(yōu)先級上。我在日志里見過很典型的情況任務(wù)是找到某商品的用戶評價Agent 前幾步正常中間誤點(diǎn)了一個相似商品進(jìn)入詳情頁然后把“該商品詳情頁”當(dāng)成了目標(biāo)頁面繼續(xù)執(zhí)行“查看評價”最后輸出一套根本不相關(guān)的內(nèi)容。排查這種問題要把每一步操作前后的截圖、模型思考摘要、執(zhí)行動作三者關(guān)聯(lián)起來回放。如果發(fā)現(xiàn) Agent 連續(xù)三步以上沒有朝目標(biāo)推進(jìn)應(yīng)立即觸發(fā)“回到任務(wù)軌道”機(jī)制重新審視當(dāng)前頁是否偏離目標(biāo)必要時回到上一步重做。不要等到任務(wù)結(jié)束了才去檢查效果那樣既浪費(fèi)時間又浪費(fèi)模型調(diào)用額度。4.4 性能開銷與響應(yīng)時間預(yù)算移動端 Agent 不是免費(fèi)的截圖、模型推理、動作執(zhí)行、狀態(tài)校驗(yàn)每一步操作通常需要 1 到 5 秒長任務(wù)累計下來非常慢。我實(shí)測過一個 20 步的操作流程在主流配置的測試機(jī)上跑完大約需要 1 分半鐘在低端機(jī)上可能超過 3 分鐘。如果你要跑批量任務(wù)性能瓶頸會直接變成成本問題。優(yōu)化方向有三個一是減少不必要的模型調(diào)用能用文字?jǐn)嘌越鉀Q的問題就不要調(diào)用視覺模型二是降低截圖頻次狀態(tài)穩(wěn)定時直接復(fù)用上一次的識別結(jié)果三是讓模型只處理關(guān)鍵區(qū)域比如只裁剪出按鈕區(qū)域做識別而不是每次全屏送進(jìn)去。另一個辦法是把“重識別”和“輕校驗(yàn)”分開輕校驗(yàn)用規(guī)則和 OCR 快速過濾明顯錯誤重識別才走大型模型。很多團(tuán)隊在 Demo 階段不在意延遲進(jìn)入批量生產(chǎn)后被速度卡死回頭再優(yōu)化就晚了。性能預(yù)算應(yīng)該從一開始就寫入設(shè)計文檔。4.5 環(huán)境恢復(fù)與狀態(tài)隔離跑任務(wù)之前最容易被忽略的是環(huán)境殘留。上一次任務(wù)留下的購物車、搜索歷史、通知角標(biāo)都會影響下一次任務(wù)的執(zhí)行結(jié)果。比如你在測試“將商品加入購物車”第一次執(zhí)行成功后沒有清空購物車第二次執(zhí)行時購物車就多了幾個舊商品Agent 可能因此誤判“加購失敗”。我建議每個任務(wù)跑完后執(zhí)行環(huán)境清理清空目標(biāo)應(yīng)用數(shù)據(jù)或重置到初始狀態(tài)關(guān)閉所有后臺應(yīng)用恢復(fù)默認(rèn)系統(tǒng)設(shè)置必要時重啟設(shè)備。如果任務(wù)之間需要保留登錄態(tài)也要明確哪些狀態(tài)允許保留哪些必須重置。不要把環(huán)境清理交給 Agent 自己執(zhí)行把它設(shè)計成獨(dú)立的編排模塊由調(diào)度端在執(zhí)行前、執(zhí)行后分別觸發(fā)。否則 Agent 很可能因?yàn)榍謇韯幼鞅旧碛|發(fā)新的視覺判斷導(dǎo)致狀態(tài)更加混亂。我見過一個項(xiàng)目把清理邏輯寫進(jìn)提示詞里結(jié)果 Agent 每次清理時都會“順便”打開幾個無關(guān)頁面復(fù)盤任務(wù)越跑越臟。4.6 快速排查速查表問題典型現(xiàn)象首選排查方向點(diǎn)擊偏移點(diǎn)到的位置和預(yù)期不一致截圖坐標(biāo)與動作坐標(biāo)換算、屏幕縮放彈窗干擾任務(wù)中途被廣告或系統(tǒng)彈窗打斷窗口層級檢測、彈窗預(yù)處理模塊模型誤判連續(xù)動作但偏離目標(biāo)操作回放、階段判據(jù)、目標(biāo)偏離檢測執(zhí)行緩慢單步耗時過高不必要的模型調(diào)用、全屏推理、等待時長狀態(tài)殘留第二次任務(wù)結(jié)果異常環(huán)境清理、App 數(shù)據(jù)重置點(diǎn)擊無效看到按鈕但點(diǎn)不動控件被遮擋、按鈕置灰、動畫未結(jié)束這張表不是標(biāo)準(zhǔn)文檔是我自己調(diào)試時常用的排查起點(diǎn)。遇到問題先判斷屬于哪一類再按對應(yīng)方向處理比盲目改提示詞有效得多。實(shí)際排查時我還會額外加一個步驟把 Agent 每一步的截圖和動作日志導(dǎo)出成 HTML 回放頁面肉眼過一遍整個操作序列。這個習(xí)慣幫我發(fā)現(xiàn)了大量單點(diǎn)日志看不出來的連續(xù)誤判強(qiáng)烈建議你也搭一個類似的可視化回放工具。真把 Agent 接到真實(shí)手機(jī)上之后我最大的體會是這活兒最大的瓶頸不在模型而在工程。模型能力已經(jīng)夠讓 Agent“看懂”屏幕難的是讓它在千百種意外里穩(wěn)定輸出、不越界、不重復(fù)、不泄密。剛開始做的時候我把大量精力花在提示詞和模型選型上后來發(fā)現(xiàn)真正決定項(xiàng)目能不能跑下去的是狀態(tài)管理、坐標(biāo)轉(zhuǎn)換、異常隔離、環(huán)境清理這些看似不起眼的模塊。如果你也要做類似的事我建議先別急著追求“一鍵完成所有任務(wù)”從一個小范圍、高校驗(yàn)、可回退的任務(wù)開始先把工程骨架搭穩(wěn)再慢慢放開 Agent 的操作邊界。這個方向這兩年演進(jìn)很快但越是能力強(qiáng)的工具越需要把護(hù)欄做扎實(shí)。